MC9S08JM16 Beginner Questions

[LiveMike]

Hello Forum,

I have been programming the MC9S08JM16 in Relocateable Assembly using CodeWarrior 6.2 for one month.  I have read the data sheet, browsed the forums, and done the occasional Google search.  I wanted to work through as much as I could on my own for one month BEFORE I made my first post.  (My background is Java programming and development for the last 12 years.)  Here are a few unanswered questions I still have:

1)  How can you keep an accurate clock?  I'm not so worried about being a second or two off every day, but from what I can tell any clock is an interrupt that calls an ISR to update a counter.  So if another interrupt happens, and takes 7 seconds to perform it's duty, won't the clock then be 7 seconds off?  Also, if within this other interrupt, I need to use my clock counter to count to 3 seconds, I won't be able to because the clock interrupt wont happen (the interrupt mask bit is clear).  I don't see using the TPM, MCG, or RTC as a solution to this problem.  Also, I know you can re-enable interrupts (by acknowledging the current interrupt flag and using the instruction CLI), but then before my clock interrupt happens, the original interrupt occurs again (ie someone holding down a button.)  I know you can software poll the interrupt flags in RTC and TPM, but that seems ridiculous to add that poll to then end of EVERY loop in my code that could possible last longer than my clock tick (which usually would be 1-10 ms.)  So what am I missing.  What keeps a fairly accurate time of day in the background, while my MC is performing its daily functions??  (Once again 'accurate' is not too relevant, as long as it can say it's within 2 or 3 minutes of 9PM or 7AM etc.)

2)  I believe the JM16 has a 24 MHz internal bus frequency.  Doesn't that mean each cycle count is 1/24 us?  So 24 cycles would be 1 us?  I have a subroutine that takes exactly 24 cycles and can be run 'x' amount of times, usually 20 or 50 as I often need to count 20 or 50 micro-second intervals.  So is 24 cycles 1 us (micro-second) on the JM16??

3)  Odd question, and maybe dangerous programmatically, but let's say my KBI calls a subroutine, that then calls another subroutine, that then calls a 3rd subroutine, so we are nested 3 deep.  I actually don't think this is too uncommon, with the lack of execution control in assembly.  Anyway, subroutine '3' doesn't like what it sees, so I set a bit, BSET, as a flag, call 2 RTS's reading/checking this flag, and eventually the original subroutine see's the flag and calls RTI.  Could I just have called an RTI from the third nested subroutine and the execution would have automatically "jumped" out and picked up where it left off when the original interrupt occurred??

Ok, three long questions is enough for now.  It's has been a challenge going from a HLL like Java to Assembly, but I'm starting to see the benefits.  A lot of what I'm 're-learning' is the program flow and control, and the use of variables.  I quick hints or tricks of the trade would be appreciated.  Thank you in advance for any answers, help, or suggestions.

-Mike

[kef]

1)

• ...So if another interrupt happens, and takes 7 seconds to perform it's duty...

ISR's should take as short as possible. Certainly you can make it 100x times shorter than it is currently.

•  Also, I know you can re-enable interrupts (by acknowledging the current interrupt flag and
• using the instruction CLI), but then before my clock interrupt happens, the original interrupt
• occurs again (ie someone holding down a button.

No, you should not acknowledge your interrupt, but disable it, CLI, and do the rest of those 7seconds. At the end of "forever" ISR you should clear interrupt flag and reenable "forever" interrupt.

2)

• So is 24 cycles 1 us (micro-second) on the JM16??

Yes, provided you set up clock module properly and are operating at 24MHz bus clock

3) No. Amount of JSR/BSR should match amount of RTS, else stack will be not restored and RTI will return into the weeds.

[LiveMike]

kef,

Thank you for your answers.  As far as the comment, "ISR's should take as short as possible. Certainly you can make it 100x times shorter than it is currently.", I don't understand this.  One type of KBI could be the user holding the button for 2 seconds to trigger an event.  Another type of interrupt could be receiving RF data for 3 seconds (albeit this is a ton of data.)  Is my option severely limiting my interrupt function and capabilities to ensure my clock is accurate because there is no "keep the time in the background" feature??  I know I'm brand new to Microcontrollers, but some of the program control makes no sense.  I appreciate your help and advice and any further help you may have.

-Mike

[kef]

• One type of KBI could be the user holding the button for 2 seconds to trigger an event. 

Instead of wasting CPU cycles looping for 2 seconds, on KBI interrupt you should register keyboard event and set specific flag variable, also you may register the time at which this event happened, and exit. Main loop checks flags, times, and makes decisions, was there single keypress, was there 2seconds keypress, or was there illegal user input. When there's nothing to do (no event flags are set), main loop may enter wait or other power saving modes.

• Another type of interrupt could be receiving RF data for 3 seconds (albeit this is a ton of data.) 

I don't see why would you need to stay looping in interrupt handler for 3 seconds. Instead sample some pin at equal time intervals, or maybe use pin interrupt. Then it't just a matter of analysing all those events and converting them to data you are receiving.

[LiveMike]

kef,

I understand what you are saying, but at that point, why even set these "inputs" as an interrupt?  If all my interrupt does is set a FLAG, well, that was already set in the IRQSC, or KBISC, etc.  I should at this point use software polling in my MAIN loop to check the FLAGS of IRQSC, KBISC etc., perform the neccissary taks, and continue to loop.  The only "INTERRUPT" to the execution/flow of my code is then just to "update the clock".  This makes sense, and maybe I was trying to uses interrupts as user input, where maybe interrupts should only by used as "DO THIS RIGHT NOW NO MATTER WHAT" lines of code.  I'm slowly wrapping my brain arround Assembly.  Thanks for your input kef

-Mike

[bigmac]

Hello Mike,

If you have lengthy processes within your main loop, the use of interrupts for keypress detection my give the impression of a greater responsiveness to the keypress.  However, the typical reason for interrupt usage is to wakeup the device from a low power mode.

For a mechanical contact there will be multiple closures, following the first closure, due to contact bounce.  This may also occur when the switch is released.  "De-bounce" measures are therefore required within your code.

1. Following detection of the first switch closure (and the ensuing KBI interrupt), further interrupts for this pin should be disabled, and a timeout period of typically 50-100ms started.  The action require by the closure would then be initiated, and the ISR would exit.
2. The timer state could then be polled from within the main loop, and after de-bounce timeout is detected, the next step is to wait until the contact opens.  If this condition requires a further action, an interrupt on the opposite edge may be enabled.  Otherwise the contact open condition could be determined by polling.
3. When the contact open condition is first sensed, a further debounce timing period should be started.  When this period elapses, when determined by polling, the KBI may be re-enabled for the next contact closure at the specific pin.

It is important to either disable the KBI pin or change the edge polarity, whilst the keyswitch remains closed, otherwise this will prevent closures from other keyswitches from being detected.

Regards,

Mac

[LiveMike]

Great info Mac!!  Much appreciated!