3 ms·

Often enough, writing a byte from a buffer to an I/O port and incrementing an index is OK.

adrian_b 4y ago
You are right when the interrupt handling is so simple. However I cannot remember how many years have passed since the last time when I had the opportunity to write something like that. Nowadays even the simplest microcontrollers costing a fraction of a dollar include DMA controllers or hardware FIFO queues so that for most I/O interfaces it does not make sense to handle one interrupt request for every transferred byte. So you have fewer interrupt requests, but with more complex handling, which should be executed outside the interrupt context.
- moloch-hai 4y ago
  There are microcontrollers that cost a penny. Admittedly, even some of those have DMA. But it is wholly legitimate for a main program to be a two instruction loop "a: sleep; jump a", and all the work is done in interrupt context. That is not to claim it is better; rather, in a microcontroller, whatever works, works.
  - sgtnoodle 4y ago
    Indeed. It doesn't really matter as long as the firmware reliably does what it needs to do. A lot of MCUs only have one CPU, and so interrupts are one of the features to allow multi-tasking in a predictable way. If you only have one thing to do, then go ahead and stick it in a main loop. If you only have two things to do, then spending a bunch of CPU cycles in an interrupt handler might not be a problem at all. If you're working on a sufficiently complex embedded system with a bunch of competing real-time goals, you learn to be very careful with what your CPU is doing at any given time. Quite often, "inefficient" interrupt based or bit-banged peripheral drivers are the right answer, even if the hardware supports DMA. It all depends on the complexity of the application and how much time and money you have.
the__alchemist 4y ago
You'd generally use DMA instead of this. This lets a dedicated peripheral handle that, freeing the CPU.

You are right when the interrupt handling is so simple. However I cannot remember how many years have passed since the last time when I had the opportunity to write something like that. Nowadays even the simplest microcontrollers costing a fraction of a dollar include DMA controllers or hardware FIFO queues so that for most I/O interfaces it does not make sense to handle one interrupt request for every transferred byte. So you have fewer interrupt requests, but with more complex handling, which should be executed outside the interrupt context.

moloch-hai 4y ago
There are microcontrollers that cost a penny. Admittedly, even some of those have DMA. But it is wholly legitimate for a main program to be a two instruction loop "a: sleep; jump a", and all the work is done in interrupt context. That is not to claim it is better; rather, in a microcontroller, whatever works, works.
- sgtnoodle 4y ago
  Indeed. It doesn't really matter as long as the firmware reliably does what it needs to do. A lot of MCUs only have one CPU, and so interrupts are one of the features to allow multi-tasking in a predictable way. If you only have one thing to do, then go ahead and stick it in a main loop. If you only have two things to do, then spending a bunch of CPU cycles in an interrupt handler might not be a problem at all. If you're working on a sufficiently complex embedded system with a bunch of competing real-time goals, you learn to be very careful with what your CPU is doing at any given time. Quite often, "inefficient" interrupt based or bit-banged peripheral drivers are the right answer, even if the hardware supports DMA. It all depends on the complexity of the application and how much time and money you have.

the__alchemist 4y ago

You'd generally use DMA instead of this. This lets a dedicated peripheral handle that, freeing the CPU.