This is awesome!
Just one thing I'm curious about, is the 'adc_callback_data' struct needed?
What about adding an 'adc_irq_cause' function instead of passing the 'irq_flags' in the 'adc_callback_data' struct? This would make it more inline with the DMA IRQ framework.
What is the usage scenario for the 'arg' argument in the 'adc_callback_data' struct?
Most|all other interrupt handlers in libmaple have no attached user data.
mbolivar
LeafLabs
What about adding an 'adc_irq_cause' function instead of passing the 'irq_flags' in the 'adc_callback_data' struct? This would make it more inline with the DMA IRQ framework.
As far as I'm concerned, dma_get_irq_cause() is broken, and there's no good way to fix it. See this thread for why:
http://forums.leaflabs.com/topic.php?id=2624
Providing all the bits is more confusing at first, but it's the only way to avoid the kind of confusion that hacks like dma_get_irq_cause() will cause when you stress the implementation.
What is the usage scenario for the 'arg' argument in the 'adc_callback_data' struct?
Most|all other interrupt handlers in libmaple have no attached user data.
I think this is a deficiency. We're trying to backwards-compatibly add user data to callbacks in other areas as well; see this pull request for external interrupts for another example and usage scenario:
Is this going to be merged into main line?
You must log in to post.
