BasicMicroUK - Forums

www.basicmicro.co.uk
It is currently Sat Jan 20, 2018 7:51 pm

All times are UTC [ DST ]




Post new topic Reply to topic  [ 11 posts ] 
Author Message
 Post subject: weird inconsistencies with main loops and interrupts
PostPosted: Wed Sep 01, 2010 1:32 pm 
Offline
Citizen

Joined: Fri May 14, 2010 1:47 pm
Posts: 6
Hi,

I have a piece of code on the basic atom 24m that generates a square wave with the help of the hpwm function. I have an interrupt set up that halts the hpwm by setting ccp1 to 0 when an external signal is generated on P0. when my LOOP routine is empty as follows:

Code:
ONINTERRUPT EXTINT, halt               ;optocoupler sensor interrupt: used for calibraion and position error
ONINTERRUPT TMR0INT, acceleration         ;TMR0 interrupt used for acceleration / deceleration

MAIN:
DIRA = 0
DIRB = 0
DIRC = 0
DIRD = 0
DIR0 = 1
;DIR8 = 1

clear_b var byte                     ;read the RB ports to clear interrupt flag
period var word
err var byte

SETEXTINT EXT_L2H                       ;P0 external interrupt for optocoupler sensor
ENABLE EXTINT

SETTMR1 TMR1ASYNC1                     ;counter clock mode for counting motor pulses
RESETTMR1 0
ENABLE CCP2INT

err = 0
period = 3000
HPWM 0, period, period/2

SETTMR0 TMR0INT256
ENABLE TMR0INT

LOOP:
GOTO LOOP

step_control:
resume

halt:                              ;halt the motor, continue calibration or send error message
   clear_b = INA
   INTF = 0
   CCP1CON = 0
   ENABLE EXTINT
resume

acceleration:                        ;accelerate / decelerate the motor on TMR0 period
resume


the program runs as expected. However if i add something to the LOOP routine as follows:

Code:
ONINTERRUPT EXTINT, halt               ;optocoupler sensor interrupt: used for calibraion and position error
ONINTERRUPT TMR0INT, acceleration         ;TMR0 interrupt used for acceleration / deceleration

MAIN:
DIRA = 0
DIRB = 0
DIRC = 0
DIRD = 0
DIR0 = 1
;DIR8 = 1

clear_b var byte                     ;read the RB ports to clear interrupt flag
period var word
err var byte

SETEXTINT EXT_L2H                       ;P0 external interrupt for optocoupler sensor
ENABLE EXTINT

SETTMR1 TMR1ASYNC1                     ;counter clock mode for counting motor pulses
RESETTMR1 0
ENABLE CCP2INT

err = 0
period = 3000
HPWM 0, period, period/2

SETTMR0 TMR0INT256
ENABLE TMR0INT

LOOP:
        if err = 1 then
        endif
GOTO LOOP

step_control:
resume

halt:                              ;halt the motor, continue calibration or send error message
   clear_b = INA
   INTF = 0
   CCP1CON = 0
   ENABLE EXTINT
resume

acceleration:                        ;accelerate / decelerate the motor on TMR0 period
resume


the interrupt no longer seems to fire. am i doing something wrong?

thanks, greets wernher


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Wed Sep 01, 2010 5:24 pm 
Offline
Site Admin
User avatar

Joined: Thu Mar 01, 2001 7:00 pm
Posts: 1316
Location: Temecula, CA
Basic Interrupts on Atom modules are not true interrupts. They are flagged when they happen, but they will not execute except between commands. I think your empty "if then" may be causing the problem. Have the "if...then" do something(eg toggle an LED on/off or something).

_________________
Tech Support
Basic Micro - Robotic Technology Evolved


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Thu Sep 02, 2010 8:55 am 
Offline
Citizen

Joined: Fri May 14, 2010 1:47 pm
Posts: 6
nope, still no go with code in the if statement.

If you look at the 2 pieces of code i posted you will see that the first one has nothing in the main loop, this one works. the second one doesn't and it has an if statement. But anyway, adding code to the if statement doesn't help either. anymore ideas :? ?


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Thu Sep 02, 2010 9:49 am 
Offline
Citizen

Joined: Fri May 14, 2010 1:47 pm
Posts: 6
Please be so kind and publish a working piece of software running these 2 interrupts simultaneously.
(Timer 1 and extint on p0)

We seriously doubt if that is possible with the current studio/atom-24 combination.
We spent also a few days in getting this running and an unfinished manual does not help.

I also suggest that you stop using the word "interrupt" for the process that simulates real interrupts in Basic Micro.
Many users with experience in assembler and interrupts are expecting performance it cannot deliver.

I have read about inline assembly. If that would allow us to make use of the PIC real interrupts, please be so kind to present us a working example of interrupt implementation (or a link).

I also noted the use of the disable stament in font of the interrupt handling software, and in some cases of
an enable statement after the resume. There is nothing about this in any manual. is this some kind of compiler directive, and what is it's use ??
I found an article of Chuck Hellebuyck (USING ThE PIC EXTERNAL INTERRUPT) about interrupts using one example of disable/enable and one example without the latter. What to use ?? I also noted that he did not use 2 ints simutaneously


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Thu Sep 02, 2010 4:56 pm 
Offline
Site Admin
User avatar

Joined: Thu Mar 01, 2001 7:00 pm
Posts: 1316
Location: Temecula, CA
Interrupt hardware is used, which is why it's still called an interrupt. The interrupts are simply disabled during execution of basic commands and then allowed to execute between commands. Your opinion is an interrupt that is defered is not an interrupt? But that doesn't really matter.

The new manual will not be documenting Basic interrupts for Atom/Nano. We will not be supporting interrupts on these processors for new customers. This is because these processors are simply too slow and don't have enough resources to properly run interrupts (eg without delaying them) which means they don't work as many people expect (eg: they won't interrupt in the middle of a long pause). ISRASM interrupts will remain available for these processors because they can run the way they are expected to run. We made this decision several months ago when we started the new manual.

ENABLE and DISABLE with no arguments are simply compile time directives telling the compiler to start or stop including the code from that point for reenabling interrupts between each basic instruction. ENABLE/DISABLE with arguments are both compile time directives as described above and runtime commands that enable/disable a specific interrupt enable flag.

An ISRASM handler is simply a PICmicro interrupt handler without the entry or exit code to save the context. All you have to do in an ISRASM block is clear your interrupt flag that caused the interrupt and then execute whatever asm code you want.

Here is a very simple exampel using ISRASM to use an Timer1 overflow interrupt.

Code:
T1CON = 0x01
TMR1IE = 1
PEIE = 1
GIE = 1

time var long
main
   serout s_out,i9600,[dec time,13]
   if time>38 then
      toggle p0
      time = 0
   endif
   goto main
   
israsm{
   bcf   PIR1,0
   banksel TIME
   incf TIME&0x7F,f
   skpnz
   incf (TIME+1)&0x7F,f
   skpnz
   incf (TIME+2)&0x7F,f
   skpnz
   incf (TIME+3)&0x7F,f
   banksel 0
}

_________________
Tech Support
Basic Micro - Robotic Technology Evolved


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Thu Sep 02, 2010 5:50 pm 
Offline
Citizen

Joined: Fri May 14, 2010 1:47 pm
Posts: 6
thanks for the reply. could you please point me to the documentation referencing israsm?


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Fri Sep 03, 2010 8:15 am 
Offline
Master

Joined: Mon Aug 18, 2008 1:26 am
Posts: 799
Location: CA bay Area
While you are waiting on that answer, I have a suggestion as how to deal with long pauses and BASIC interrupts.
Most people just turn on an LED, do a lengthy PAUSE to catch the LED's state, then shut the LED off. During that PAUSE, no interrupts are handled.
So, why not just do:
Code:
HIGH LED  ; set output pin CON'ed earlier as LED to high state, turning on LED
; The next routine does multiple PAUSEs, spanning 250 milliSeconds
FOR Looper = 1 to 250  ; start loop to containg multiple PAUSEs
    PAUSE 1  ; pause 1 millisecond
NEXT
LOW LED  ; LED pin goes to low state, turning off LED

Instead of no interrupt monitoring for 250 mS, you poll for interrupts 250 times in the delay loop while achieving a 250mS pause to see the LED.

Easy enough, if BASIC interrupts still work. If not, punt with ISRASM.
kenjj

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Sun Sep 05, 2010 7:21 pm 
Offline
Site Admin
User avatar

Joined: Thu Mar 01, 2001 7:00 pm
Posts: 1316
Location: Temecula, CA
As soon as I have some I'll point you to it. Right now I am the documentation on ISRASM. ISRASM tells the compiler to take your asm code that is in the block, add entry and exit code to save/restore the FSR,STATUS and W registers, and then it puts it at address 0x04 which is the PICmicro interrupt jumpto address.

So in your handler you must clear the interrupt flag for the interrupt you are handling(so it doesn't interrupt infinitely) and then execute any code for your particular interrupt(eg increment a timer variable or something). It must all be done in PICmicro asm code. You code must also exit through the end of the block. You should not use a rtfie to exit from the block. That is handled in the exit code that is added to your code by the compiler.

Basic interrupts on Atom/Nano still work, however we will not be supporting them except for legacy customers. We are pushing everyone new to the AtomPro if they need to use Basic interrupts. We have very few tech support calls for Basic Interrupts on the AtomPro and the few we get answered quickly. Basic interrupts on Atom/Nano have too many gotchas because they are defered while any basic command is executing. AtomPro interrupts and ISRASM block interrupts execute immediately so they don't have this extra level of complexity.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Sun Sep 05, 2010 10:54 pm 
Offline
Master

Joined: Mon Aug 18, 2008 1:26 am
Posts: 799
Location: CA bay Area
Look at it this way: The BMicro guys (one guy, actually) has to maintain several separate compilers.
One is for the early PIC parts, Rev B.
Another is for the newer PICs in the same series, Rev D.
Then there is the 18-pin Nano, which is yet another compiler (I'm guessing).
Then the BasicAtom Pros are an entirely different manufacturer, and THEY differ between the parts.
So, as you might imagine, maintaining all these must be a pretty hairy proposition.
AND he had to create an IDE from scratch, get it to work with a load of disparate compilers, and add requested features. And don't get him started about making it work with every twist and turn in every Windows version as they come up. ;)

Personally, I think it's a huge mistake on their part to NOT support BASIC interrupts. This is... after all... BASIC. It seems kinda backwards to sell the idea of simplifying people's efforts to use a processor in their project, and then say,"...except in the case of interrupts, that we leave difficult, if not impossible, for the beginner." Well, for PICs maybe, but there's always the Pro parts if you want to get serious and use interrupts.
On the other hand, they dropped all the set up parameters for the ADIN command, thereby making it a LOT simpler for the beginner to use.
Everything is a trade off. Ehh! :roll: I just hope they go to the trouble to point all this out in their sales literature so no one gets burnt later. I swear I have looked at every damn BASIC for PICs out there, and all of them leave something to be desired. Including the ones you pay for! :evil:

Just about every interrupt has been discussed in these forums at some time. Get familiar with the search function and use it. Or ask.
END RANT

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Sun Sep 05, 2010 11:04 pm 
Offline
Master

Joined: Mon Aug 18, 2008 1:26 am
Posts: 799
Location: CA bay Area
I just found a reply from Nathan in my emails about the use of ISRASM, and I share it here:
Quote:
ISRASM takes the code in the brackets and addes it to the 0x04 interrupt program memory location along with entry and exit code. This means you do not need to save/restore the FSR,STATUS or W registers in your ISRASM handle. All you have to do in your handler is clear the specific interrupt flag you are going to process and run any asm code you want for that interrupt. At the end of the ISRASM block exit code is automatically added and the FSR,STATUS and W registers will automatically be restored.

Hope this helps.

_________________
kenjj
http://blog.basicmicro.com/
http://kjennejohn.wordpress.com/


Top
 Profile  
 
 Post subject: Re: weird inconsistencies with main loops and interrupts
PostPosted: Mon Sep 06, 2010 5:16 pm 
Offline
Site Admin
User avatar

Joined: Thu Mar 01, 2001 7:00 pm
Posts: 1316
Location: Temecula, CA
I'd love Basic interrupts to work on the ATOM and Nano the way they do on the AtomPro. There just isn't any way for that and because of that we are no longer going to support them on Atom/Nano. Based on 10 years of experience with the Basic interrupts on PICmicro (Atom/Nano processors) we've come to the conclusion that most people just can't use them in a usefull manner because of the PICmicro limitations. The few that can are usually advanced users and can use ISRASM anyway. We recommend that those people that are not advanced users but still need Basic interrupts because asm interrupts are too complicated, use the AtomPro. Even then interrupts in general are not easy. They never will be. The only easy interrupts are those written for you (eg hserial, hservo) and even those have some gatchas.

_________________
Tech Support
Basic Micro - Robotic Technology Evolved


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

phpBB SEO