Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
6 years, 3 months ago.
Timer interrupt
I am accustomed to programming PIC microcontrollers, so please pardon my ignorance here. When I am wanting to interrupt my main routine at particular intervals I usually use one of the many timers (8, 16 32 bit). The time of the interrupt is based on the particular oscillator in use at the time. For example, if I am using an 8MHz crystal oscillator with a 16-bit timer, then my overflow will occur at 32.768mS (the tick on most timers is set to the frequency of oscillation divided by 4 = 2MHz). From the datasheet I know how many instruction cycles it will take for the interrupt and can therefore make very precise timing interrupts (down to 100 nanosecond range using a 40MHz oscillator).
I don't see this kind of functionality in the Mbed system. I see the inclusion of timers but they appear to be limited to counts of microseconds. This would probably suffice for most applications, but if the timing needs to be very precise, how does a person get access to the actual timer? For instance, if the chip is running at 120MHz like the LPC4088, I would hope that the timer would have a much finer resolution than 1 microsecond, but it seems I cannot get a finer resolution using the Mbed system. Am I missing something? Is there a way to get access to the actual tick of the onboard timers? Is the Mbed timer system based on interrupt counting of the actual timer to produce the microsecond/second interrupts? If so, is the overhead of the interrupt taken into account within the Mbed system? In other words, how precise is the 1 microsecond tick of the Mbed timer?
1 Answer
6 years, 3 months ago.
It depends a bit on the platform, since some mbeds don't have a proper timer to get 1us resolution up till 32-bit, so some have 16-bit timers running at 1MHz, and with an interrupt everytime it overflows it is extended till 32-bit, some have a 32kHz timer used (so about 30us resolution), and some are yet different. But the majority, including the LPC4088, uses a 32-bit hardware timer running at 1MHz (using a prescaler) to get the Ticker interrupts. So that does not give any overhead.
Then if you want to use a better resolution you will need to setup a timer yourself. On some targets this will cost you either PWM outputs or the normal Timer/Ticker behaviour, but the LPC4088 has plenty of spare timers. As example on how to get started, here is the mbed source code for the LPC4088 timer (so you can directly also see Timer 3 is used for this): https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NXP/TARGET_LPC408X/us_ticker.c
So, if I read this code right (comparing it to the datasheet), the pclkdiv is effectively ignored and the prescale is used t set the tick value to the 1 uS. So, I could use the pclkdiv = 1 for a 1:1 tick. Since the lpc4088 board has a 12MHz crystal, I should get an 83.3nS tick on a 16-bit timer. Is this right? Then using the timer in capture mode (I'll have to read up on the data sheet to know which registers to set) I should be able to get very fine resolution for timing intervals. The syntax of the commands is a little confusing to me, but that is easy enough to overcome.
What are the ramifications if I were to remove the existing 12MHz crystal and replace it with a 25MHz version and using the PLL = 4 to get a 100MHz board? Would this screw up the bootloader etc of the Mbed board?
posted by 03 Jan 2018The board, and also the Timer, already runs at a higher speed using the PLL. Generally at the SystemCoreClock, but some have a different speed, for the LPC4088 it runs at the PeripheralClock variable apparently. So I would first check at which speed it runs and what you need before you start changing the board ;).
You can change the clock setup here if you use the full source code version: https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NXP/TARGET_LPC408X/device/system_LPC407x_8x_177x_8x.c, however clearly they didn't optimize that file for easy changing of settings :P. In principle changing the crystal for something else (and preferably changing also definitions in that startup file) should work fine, assuming the interface chip has its own crystal (I assume it does). One of the reasons a 12MHz crystal is popular, is that USB requires a 48MHz clock which can be easily generated from that crystal. So with a 25MHz crystal you won't have USB on the LPC4088 itself.
posted by 03 Jan 2018That's a good point. I hadn't really thought about the USB as my current project does not use that, but future projects certainly may. Perhaps a 24MHz crystal. I believe I read where the USB has a separate PLL so I can get a nearly 100MHz system and still have the USB available. I'll look deeper before I alter the board.
Anyway, thank you for all the info. This will make some of my coding a bit more cumbersome, but for me, much more functional.
posted by 03 Jan 2018