Avoid Busy waiting when waiting for a signal

Question

I am trying a write a code which can be easily ported to any MCU. This MCU will act as a host and communicate with another audio codec chip. When communicating with the chip, host MCU will write a request to chip and will wait for an interrupt line to go high and then read the response from the chip.

Currently, I am using a Raspberry Pi as a host and hence I can poll the sysfs entries of the interrupt line. How can I achieve this in a primitive system which may not have a poll method. I am thinking I can update a global variable in the interrupt ISR and check this global variable repeatedly. And herein lies the problem that I want to avoid. Main program loop itself may be getting called from one of the Timer interrupt handlers and busy waiting may not be a good option.

Any ideas?

Answer 1

Usually, microcontrollers have a variety of low-power "sleep modes". Each sleep mode has a different combination of things that are still running and a different combination of things that can wake up the microcontroller. For example, in one mode you may be able to leave the SPI peripheral transmitting data, and wake up with an interrupt, so you can give it some data to transmit and then enter sleep mode until it finishes. A different mode may shut down all peripherals except for the GPIO pins. A different mode might shut down everything and only let the microcontroller be woken up with the reset pin.

Since your code is designed to be ported to any microcontroller, you can't assume which sleep modes are available. But you can write a busy-wait loop with optional sleeping, something like this:

setUpInterrupt();
while(!interruptHappened) {
    enterAppropriateSleepModeIfAvailable(); // the person who ports the code implements this
}

If the microcontroller doesn't have an appropriate sleep mode, the porter will make it so enterAppropriateSleepModeIfAvailable doesn't do anything, and this will be a busy-wait. Otherwise, it will wait for the interrupt to happen.

Make sure that the microcontroller still wakes up - and doesn't get stuck in sleep mode - if the interrupt happens after while(!interruptHappened) but before enterAppropriateSleepModeIfAvailable().

Answer 2

One size fits all fits no-one well. Especially with mcus where space is limited and making a generic one size fits all library. So proceed with care.

Each mcu is different, how they handle the movement of data varies, some have buffers, some have dma, etc. One would expect an interrupt is possible within the design, but not what everyone wants to do.

You have left a significant amount of system information out, it sounds like this is an external codec chip but what does "response" mean. Most MCUs can handle a gpio input rising edge or level causing an interrupt, but you have not described the interface to the codec chip, if it is a common interface like i2c or spi, what kind of data you are moving and as a result how each mcu handles that, which is of course brand and family specific and difficult at best to make a generic (not bloated) library.

The library if any needs to instead focus on call back and processing functions, in no way should the library care about the interrupt nor movement of data, the user supplies that, the library instead focuses on the data. Worst case the library has function calls it makes that the user fills in to implement things, send command, send data, receive data, wait for event, etc.

if this is i2c then sure you can do the bit bang library as well and have a generic-ish list of drive high, drive low, float input, read input, delay half cycle, etc, wait for event, and then you implement the rest. (Well you could bit-bang spi as well and be independent of the mcu type).

Answer 3

You can try semaphores, mutex, locks, monitors. Lock, mutex, semaphore... what's the difference? this will tell you the basic differences between them.