I was actually writing on a post for this list along the same theme when I saw your message. The main reason I see for removing the busy waits is that you can lower the power consumption if you can let the CPU core sleep while the peripheral is working, either using interrupts or DMA for the transfer.
I was thinking I could use `thread_sleep()` inside the part of the driver called from the application thread and `thread_wakeup` from an ISR for the relevant status flag. Will this introduce any noticeable extra delays from the context switching or otherwise? (Except for the function calls to `thread_sleep()`, `thread_wakeup()` which obviously are an extra overhead) Has anyone measured the cost of the thread context switching on the different platforms? I'm mainly interested in Cortex-M4 (Kinetis). This would be a good indication of how "slow" an I/O device has to be before it is worth it to manually yield a thread while waiting. I think ADC and UART (depending on baudrate vs. core clock frequency) are good candidates for this, as well as I2C in normal or fast mode when running on a fast MCU. SPI may not be very useful for small transfers, but DMA of larger blocks will definitely save some power/decrease CPU usage with such a change. Best regards, Joakim Gebart Eistec AB www.eistec.se On Sun, Feb 8, 2015 at 11:47 AM, Frank Holtz <frank-riot2...@holtznet.de> wrote: > Hello, > > i have looked into periph drivers and found a lot of single line "while" > statements waiting for finishing things. > > stm32f4 -> 26 statements > nrf51822 -> 4 statements > atmega2560 -> 8 statements > cc2538 -> 4 statements > sam3x8e -> 13 statements > ... > > Slow devices like ADC, Flash, UART or Random number generation are > wasting a lot of CPU cycles while waiting to finish an action. This > blocks task switching(right?) and preventing to go into sleep mode. > > What about an architecture for asynchronous drivers? > > An asynchronous driver can be initialized, but it brings hardware into > sleep mode. The hardware is powered on when an process is added to queue > and powered off when noting listens to queue. It should be possbile to > add more than one process to an queue. This gives the availability to > debug things, implement an work flow to decrypt or route radio packages > or use ADC values to generate better random data when ADC is enabled. > > An queue can be centralized and handle an event-type, the priority and > an pointer to an call back function. > > When an event is triggered any function with same event type is called > with an identifier like pin number and an value or pointer to expected > data structure. Every function can determine with return code if other > functions with same event type are called. This is needed for random > numbers to make sure that an random number is not used twice. > > When it's possible to change an event type and re queue an event an work > flow can implemented. > > Regards, > > Frank > _______________________________________________ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
