Convert Timer interrupts interval from Cycles to milliseconds... On MSP430F5438

Well, there are a few differences between writing code for a microcontroller and writing JAVA code for a PC.

The most important concept to understand here is that you set the clock frequency yourself when you work with micros so your clock cycle may take 83us when running at 12kHz VLO or it may take 62.5ns when running at 16MHz DCO. Once you know what speed you're running at, you load a register with a value which is the number of cycles that you want to time. When timer runs, it decreases this register by one on each clock cycle and when it reaches 0, then it triggers.

So if you want to trigger after some number of ms then you need to probably configure your timer to trigger after 1ms and then count the trigger times and do whatever you need to do when you've counted enough.

Getting it to trigger after 1ms is a timer configuration that depends on your selected clock speed and clock source and that's usually well documented in the data sheet of your MCU. Look at timer configuration and clock source and speed configuration.

Hi Java developer :),

if you are not use to hardware timer things, this link offers you a good explanation about what you are asking:

http://karve.in/?p=1408

There are some examples there for timing things, based on delays but this is NOT optimum, but it can help  you out if you are just trying to simulate something :) Good luck!

PS: I do not understand your signature at all,  the teachers and students thing.

You did not tell if you are trying to time a incoming signal or your are trying to use the msp counter to generate a constant time interval.

Should not be to much problem with racing. If you set up the counter to count to 1ms,
if you are in a different interrupt while this count matches, you could enable interrupt inside the interrupt.

Or as long the interrupts job is not to restart the counter, any response delay will get cought up to next time.

Hello,

I am using following solution that works for my purposes without nested interrupts.

It is possible to allow nested interrupts on MSP430, but the usual interrupt handling on MSP430 is to handle the highest priority interrupt if two interrupt flags are set at the same time. After the highest priority ISR  has finished, the next highest interrupt is handled immediatly. The main loop is reached again, if no further interrupts are pending anymore. Interrupt priorities on the MSP430 are fixed.

To be able to handle all interrupts in time without missing the next interrupt for each module, the ISR has to be non blocking and as short as possible. E.g. if you have a timer in up mode to throw an interrupt each 50 us and the ISR of the Timer requires 210 us to execute, you will lose a lot of Timer interrupts in between. As all other pending interrupts are scheduled in a sequential manner, all ISRs (including the Timer ISR) are not allowed to take more than 50 us in this case (independend from clearing the Timer IRQ flag at the beginning of theTimer ISR or the end of the Timer ISR ( I use to clear it at the beginning of the ISR).

So it is important to keep all ISRs as short and catchy as possible. 

I use to increase an uint64_t (8 bytes of RAM!)  time stamp counter (that will not overflow the next 100+ years) each Timer IRQ.

This TSC is used as time reference for non critical (non real time) purposes in the main loop. You can also derive other software timers from it (also each 8 bytes of RAM!)

The error for waiting t_TSC is from t_ISR to t_TSC. t_ISR can be assumed as 0, if t_TSC >> t_ISR.

E.g. if you got a TSC tick of 100us, the main loop waiting time for 100us  is from 0 (t_ISR) to 100us (t_TSC).

If you want to wait for 1ms, the error is smaller in relation to the waiting time ... 900us to 1ms.

The access to the TSC has to be atomic (in case of doubt, make it interrupt safe).

Indeed 100us is a very short time if you do not have a high  MCLK, thus you will have to define the TSC time base for your system very carfully if you got a low MCLK.

Regards 

Marco

Hello kazola,

why you would recommend a main loop blocking method?

Regards 

Marco

Thank you all for your responses, I've been very busy and did not have time to response earlier.

Before reading your posts, and understanding a couple of more things about the interrupts, I've been able to configured the sleep interval correctly, and now able to simulate 1ms. However, I did not use clock calculations, I've averaged over a specific event, to conclude the proper sleep interval for the interrupt.
This method of setting the sleep interval is not generic, and pretty dirty (but it works for now).

I would like to be able to calculate the sleep interval for the interrupt dynamically. I would actually want to compose a formula for that.  I understand the up down trigger setup for the timer and the conversion from hz to ms should be simple enough, what I'm missing is the values, I don't understand the effect each clock definition (SMCLK, ACLK, INCLK,) has on the main clock, and what would be the final  Y hz = f(x), that would be used in the formula...

I hope this makes sense...

Hello,

"Before reading your posts, and understanding a couple of more things about the interrupts, I've been able to configured the sleep interval correctly"

Sleep is a forbidden word for me.

Sleep in an ISR (interrupt service routine) is more forbidden than in the main loop, as you may lose more interrupts in between during your sleep.

Regards 

Marco

Marco said:

Sleep is a forbidden word for me.

I know what you mean... its 2:10 in the night, and I'm still at it... ;)
Thinking about it, these are my best & favorite working hours in the day...

Marco said:

Sleep in an ISR (interrupt service routine) is more forbidden than in the main loop, as you may lose more interrupts in between during your sleep.

I never meant sleep in the ISR, I meant the (sleep interval == timer cycles), in which the timer would trigger the interrupt...