8 years, 9 months ago.

Are there interrupts that are not disabled with __disable_irq() ?

I have one simple InterruptIn which I set to trigger on rising edge of pin 20. Works fine but one thing mbed is doing is confusing me. Pseudo code of what I am doing in the ISR for above pin is:

ISR pseudo code where I am trying to measure the time duration of an ISR

disable_irq();

reset and start a timer ISR_Start_Time = read above timer uSec

do an fprintf to the mbed Local file system

ISR_End_Time = read above timer again uSec

compute ISR duration = ISR_End_Time - ISR_Start_Time

print ISR duration to PC screen using pc.printf

enable_irq();

When I loop on the above be feeding a square wave into the pin 20, nine times out of 10 (estimating) the ISR duration is in the order of 30 uS but every once in awhile, it measures a few thousand milliseconds. Is the mbed hardware using some other interrupt that I am not disabling with the disable_irq() function. What else could cause this time to every now and then grow from uS to many mS?

Thanks in advance, any input is much appreciated.

Question relating to:

I assume you mean thousands of microseconds? Thousands of milliseconds is several seconds.

posted by Erik - 20 Jul 2015

2 Answers

8 years, 9 months ago.

https://developer.mbed.org/handbook/LocalFileSystem

File access calls (fread, fwrite) will block, including interrupts, as semihosting is effectively a debug breakpoint

Accepted Answer

Was afraid of that. So same as above, but now to an SD card for example. Or a flash chip.

posted by Erik - 21 Jul 2015
8 years, 9 months ago.

Local filesystem will buffer what you write. That means sometimes it actually gots to write a new flash sector, and that takes alot of time (relatively). So when that happens your interrupts takes longer to handle.

Thank you Erik. Another question for you. Each time this interrupt triggers, I need to read a timer and save the time that the interrupt happens. Can do it very fast if I save to RAM, in the order of 4 microseconds. Problem is with a square wave driving the input pin for the interrupt, the available RAM on the mbed fills up very quickly. That is why I was trying to save to the local file system. Problem is that when as you say the file system needs to write a new flash sector, the long time that that takes makes me overrun the next edge of my square wave (square wave is actually the output of an optical quadrature encoder). This excessive time it takes to write the flash severely limits the RPM that I can run the motor / encoder assembly without missing encoder pulses. Is there any other approach besides:

1. Save timer to RAM which severely limits the number of interrupt edges I can save. or 2. Severely restrict the motor speed I can run at so that the encoder pulses do not occur more frequently than the time it takes the Local file system to do its occasional flash write?

Thanks again.

Mike Lang

posted by Mike Lang 20 Jul 2015

How many edges do you want to save? The LPC1768 has two extra 16kB RAM banks that you can use (if you dont use CAN, USB and ethernet).

In principle the localfilesystem is really handy, but also from technical pov really crap. So I am not sure if interrupts can interrupt writing to localfilesystem. What I would do is make two RAM buffers, which can hold all the interrupts which would happen during the time to write to localfilesystem (And then some extra as margin). Fill a RAM buffer, once filled set a flag, switch to other buffer. In your main loop if the flag is set write it to localfilesystem, in the meantime the other buffer is filled.

posted by Erik - 20 Jul 2015