Hello.

I've been reading the discussion here and there and it would appear the mbed (LPC1768) is only capable of processing interrupts (using InterruptIn) at a maximum of approx. 300KHz given some library changes like this one:

https://mbed.org/users/mbed_official/code/mbed/issues/4

Of course this also depends on your ISR but how fast could we process a GPIO interrupt which executes a single clock cycle instruction using both the online C++ compiler and assembly language?

The ARM Cortex M3 runs at 96MHz so I'm assuming the ridiculously low interrupt processing speed is due to a combination of the C++ abstraction, the NVIC and the peripheral hardware?

Why am I wondering? Well given the thing runs at 96MHz I was under the impression servicing a 3MHz interrupt wouldn't be a problem. I shouldn't be such a lazy researcher.

So it looks like interrupts may be out of the window. Let's try polling. How fast could I poll an 8bit BusIn (or 8 GPIO pins) given use of the C++ Compiler and assembly language?

It may be me but I'm finding any detailed documentation (peripheral architecture and timings for instance) hard to find.

Thanks for your time.

If you just have one pin to use as interruptin you can redirect the interrupt vector and get it alot faster. Maybe 3MHz would be possible with a very simple interrupt routine, no idea actually. But the NVIC itself already does have quite some overhead.

Peripheral architecture you can mostly find in the relevant user manual of the microcontroller. Timings of the arm core are generally a bit harder to find, but with some googling you can find some numbers.

If you go polling preferably don't use busin, it is just an array of digitalins, better use portin if that is feasable for you. (They all need to be on the same port then). That should be very fast, but there are some issues there which apparantly aren't getting the attention they deserve: https://mbed.org/forum/bugs-suggestions/topic/4699/

Btw those library changes you mention are now in the main mbed branch.