i am writing a library to talk to the hitachi LCD controller. I see that i would need to assert signal for some ns, even at 48MHz that is hardly worthy of doing any timer based go aways and come back's as it's a couple of clock cycles.
There is i see no standard delay function for ARM. I expect i need to write my own. Anything to be aware of? I take it I need to run some sort of loop that just goes round in circles "x" amount of times based on F_CPU.
Anything to be aware of? I take it I need to run some sort of loop that just goes round in circles "x" amount of times based on F_CPU.Yes:
At the end of this thread: https://www.eevblog.com/forum/programming/while-(youre-down-there-)/ (https://www.eevblog.com/forum/programming/while-(youre-down-there-)/)
two of us gave a solution for what you need.
I take it I need to run some sort of loop that just goes round in circles "x" amount of times based on F_CPU.That won't be very precise, and might not compile as intended everywhere. Not that you need it to be, you probably need to have "at least some ns".
You can use DWT->CYCCNT as suggested above, but it's not enabled by default since uses the DWT, a debug feature, and is missing on the M0.
Plus you'd need to consider rollovers, and will have jitter from event to comparison.
__attribute__((noinline, section(".ramfunc")))
static void delay_ms(int ms)
{
uint32_t cycles = ms * F_CPU / 3 / 1000;
asm volatile (
"1: sub %[cycles], %[cycles], #1 \n"
" bne 1b \n"
: [cycles] "+r"(cycles)
);
}
__attribute__((noinline, section(".ramfunc")))
void delay_cycles(uint32_t cycles)
{
cycles /= 4;
asm volatile (
"1: sub %[cycles], %[cycles], #1 \n"
" nop \n"
" bne 1b \n"
: [cycles] "+l"(cycles)
);
}
Here are busy-wait .....That is also IMO a good approach although portability can become an issue and colleague "c only " programmers might object.
SysTick is good, but better used for the actual system time than delays.http://infocenter.arm.com/help/topic/com.arm.doc.dui0662b/Babieigh.html (http://infocenter.arm.com/help/topic/com.arm.doc.dui0662b/Babieigh.html)
QuoteSysTick is good, but better used for the actual system time than delays.http://infocenter.arm.com/help/topic/com.arm.doc.dui0662b/Babieigh.html (http://infocenter.arm.com/help/topic/com.arm.doc.dui0662b/Babieigh.html)
SysTick is usually used for the relatively slow system tick timer, like the millisecond tick used by Arduino.It's a really simple 24bit down-counter that you can set up with a reload value ("N") that will then cause an interrupt every N clock cycles. So on your 48MHz system, you'd set the reload value to 4800, and you'd get an interrupt every 1ms.
I've seen some examples that use SysTick to do a delay, but they usually monopolize it and prevent it from being used more normally. One of my examples linked in the earlier thread showed how to use a free-running systick to do "cylces" delays, as long as the number of cycles was somwhat smaller than the reload value that was being used...
So that stuff from arm basically complements the Atmel/Microchip datasheet and will be valid on any M0+ core device?Yes, the hierarchy of documents from less detailed to more detailed:
QuoteSysTick is good, but better used for the actual system time than delays.http://infocenter.arm.com/help/topic/com.arm.doc.dui0662b/Babieigh.html (http://infocenter.arm.com/help/topic/com.arm.doc.dui0662b/Babieigh.html)
SysTick is usually used for the relatively slow system tick timer, like the millisecond tick used by Arduino.It's a really simple 24bit down-counter that you can set up with a reload value ("N") that will then cause an interrupt every N clock cycles. So on your 48MHz system, you'd set the reload value to 4800, and you'd get an interrupt every 1ms.
I've seen some examples that use SysTick to do a delay, but they usually monopolize it and prevent it from being used more normally. One of my examples linked in the earlier thread showed how to use a free-running systick to do "cylces" delays, as long as the number of cycles was somwhat smaller than the reload value that was being used...