I think such a function that fires at ADC EOC would be handy.
Skimming through RM0008 and "nvic.h", I see that there are IRQ numbers NVIC_ADC_1_2 and NVIC_ADC_3, so an implementation should be possible. I'm keen to try and implement something (also to get to know better how the whole interrupt system works..) or does anything speak against implementing such a function (whether of a philosophical or technical nature...)?
mbolivar
LeafLabs
I think you're right that having such a function would be handy. Since libmaple doesn't have any ADC IRQ handler in place already, however, you can just make one for yourself by defining a function with the appropriate name.
For now (they're going to move to a slightly different location soon), the IRQ handlers are all defined via weak symbols in libmaple/stm32f1/isrs_performance.S. Though the names in that file aren't CMSIS compliant, they are in NVIC order, and you should be able to guess by the names what they're for. Whenever libmaple happens to have a useful default action (e.g. for USART, to push received bytes onto a ring buffer), we just define a non-weak handler with the same name (and hence the extra definitions of __irq_usartX() in usart.c).
Since there's no ADC handler, just make functions with the right name, like __irq_adc or __irq_adc3. Note that if you're writing an IRQ handler in C++, you need to give the function C linkage, or the compiler's name mangling will mean the linker won't pick up your function.
Here's an example:
extern "C" void __irq_adc(void) {
// Your ADC handler goes here
}In the future, we plan to have all the IRQ handlers that are part of libmaple be weak symbols, so you can override us whenever you want. Before we make that official and documented, however, we're going to tweak some of the IRQ handler names (some of the names are out of date, since they came out before high- and XL-density STM32F1 support, so they don't account for extra peripherals sharing some IRQs).
Ok. I've come up with the following tiny code, but it always crashes my maple_mini when calling "nvic_irq_enable(NVIC_ADC_1_2)" :-(
void (*adc12_irq_handler) (void) = NULL;
void
__irq_adc (void)
{
if (adc12_irq_handler)
adc12_irq_handler ();
}
void
adc12_attach_interrupt (void (*handler) (void))
{
adc12_irq_handler = handler;
nvic_irq_enable (NVIC_ADC_1_2);
}
void
adc12_detach_interrupt ()
{
nvic_irq_disable (NVIC_ADC_1_2);
adc12_irq_handler = NULL;
}
Here my non-working code
I have the feeling that my custom __irq_adc function does not properly replace the weak definition and then libmaple calls the __default_handler which is an infinite loop as I've read in the documentation somewhere.
Is there a way to check in the produced binary, whether my function was linked in correctly and will be called instead of the __default_handler?
mbolivar
LeafLabs
Is there a way to check in the produced binary, whether my function was linked in correctly and will be called instead of the __default_handler?
(I assume you're not using a JTAG or SWD debugger)
One way is to check the vector table in the disassembly file (in build/<your_board>.disas using libmaple from Git). In libmaple, the vector table symbol is __stm32_vector_table; it should be the first symbol in the text section (and hence will be at the top of the file). Look up the ADC handler address in the vector table, and make sure it's the address of __irq_adc (which you can also look up in the disassembly).
Here's a worked example.
This is the vector table from a disassembled program with __irq_adc() defined:
08000000 <__stm32_vector_table>:
8000000: 00 50 00 20 1d 23 00 08 71 08 00 08 75 08 00 08 .P. .#..q...u...
8000010: 79 08 00 08 7d 08 00 08 81 08 00 08 d7 1a 00 08 y...}...........
8000020: d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 ................
8000030: d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 09 04 00 08 ................
8000040: d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 d7 1a 00 08 ................
8000050: d7 1a 00 08 d7 1a 00 08 8d 01 00 08 ad 01 00 08 ................
8000060: cd 01 00 08 ed 01 00 08 0d 02 00 08 59 1d 00 08 ............Y...
8000070: 79 1d 00 08 99 1d 00 08 b9 1d 00 08 d9 1d 00 08 y...............
8000080: f9 1d 00 08 19 1e 00 08 1d 01 00 08 d7 1a 00 08 ................
8000090: 29 0a 00 08 d7 1a 00 08 d7 1a 00 08 2d 02 00 08 )...........-...
80000a0: c5 1f 00 08 f1 1f 00 08 1d 20 00 08 59 20 00 08 ......... ..Y ..
80000b0: b5 20 00 08 31 21 00 08 ad 21 00 08 cd 1e 00 08 . ..1!...!......
80000c0: e5 1e 00 08 d9 1e 00 08 f1 1e 00 08 d7 1a 00 08 ................
80000d0: d7 1a 00 08 e1 22 00 08 f5 22 00 08 09 23 00 08 ....."..."...#..
80000e0: 65 02 00 08 d7 1a 00 08 d7 1a 00 08 e...........This contains:
1. The initial stack pointer,
2. The addresses of the interrupt handlers, in the order specified by Table 63 in RM0008. (Starting with the reset vector, then NMI, etc.)
Each entry is 4 bytes long. The byte-order is little-endian. The first entry in the above example (the initial stack pointer value) is thus 0x20005000, and the reset vector is at address 0x0800231d. Note that the last bit in the reset vector address is set. This is the "thumb bit"; it's an ARM feature meaning that the address to be branched to contains thumb-2 (mixed 16- and 32-bit) instructions instead of 32-bit only (this is fine since instructions want 2 or 4 byte alignment). The actual address of the reset vector is thus 0x0800231c.
__irq_adc() is at offset 0x88 from the start of __stm32_vector_table, so in this example, the corresponding value is 0x0800011d. Masking out the thumb bit, the ADC handler address is 0x0800011c. And sure enough, when I search the disassembly file for "__irq_adc", this turns up:
0800011c <__irq_adc>:
800011c: 4770 bx lr(My handler is a trivial one that returns immediately, so it just contains a standard "return to caller" bx lr instruction).
thanks, but I've got the ADC DMA interrupt up and running in DUAL ADC SCAN mode, but I'd like to use an ADC interrupt, too, besides the DMA interrupt.
consider the following setup:
144 sensors -> 9x 16:1 channel multiplexer -> maple mini
So far I use a timer and in its interrupt I switch the mux channel and start a new ADC conversion burst. DMA is setup once at startup in circular mode and fires its interrupt after all 160 conversions (1 ADC channel is converted twice because dual adc mode requires an even number of channels).
This works fine for running things at fixed rates, but I'd like be able to run this as fast as possible. Simply replacing the timer interrupt with the ADC interrupt would just be the simplest change and I could even switch easily between the two modes (fixed-rate vs. as-fast-as-you-can).
Alternatively I'll try this now:
Set up DMA in non-circular mode and let it fire after each ADC burst (10 conversions), switch the muxes and start the next conversion. And then reset the DMA destination address after all the 160 conversions. For this I won't need an ADC interrupt.
davies46
Member
FWIW, building under the Maple IDE v0.0.12 I got my adc interrupt called when I changed the syntax slightly to:
extern "C" {
void __irq_adc(void) {
conversionInterrupts++;
ADC2->regs->SR = 0;
}
}since
extern "C" void __irq_adc(void) {/* Your ADC handler goes here */}
doesn't compile on that setup.
@davies46, that's because the IDE uses Wiring which is a subset of C++ iirc, and therefore does not support all valid C++ syntax. When using the code from within the unix toolchain, both syntax are valid and give the same object code.
Is your code shareable? It'd be nice to have a look at it...
mbolivar
LeafLabs
I've prepared a document explaining how interrupt handling in libmaple works:
https://github.com/leaflabs/libmaple/blob/master/notes/interrupts.txt
It's mostly useful as a developers' doc, but it attempts to archive a lot of the information discussed in this thread.
As it definitely meets the "generally useful" criterion, I'll try to get around to adding adc_attach_interrupt() (and something like a non-blocking adc_start_conversion(adc_dev* dev, int channel) to make it more useful) this week.
As you can see from the document, doing QA on foo_attach_interrupt() routines can be nontrivial given the variety of STM32s libmaple supports, so hopefully you'll forgive us for not having done it sooner. We don't mean to be an unfriendly "zomg RTFS N00b!"-style forum, and I do try to help, but we've got limited resources to devote to Maple, so these things can take a little while sometimes.
mbolivar
LeafLabs
OK, I've got some patches in a branch on my libmaple tree:
https://github.com/mbolivar/libmaple/tree/adc-api-expansion
They provide adc_attach_interrupt() and a variety of other convenience functions to make using it easier.
Here is an example program which shows how it all fits together:
https://github.com/mbolivar/libmaple/blob/adc-api-expansion/examples/adc-low-level-interrupts.cpp
The example shows how to start with a pin number, and end up with an interrupt that calls your handler each time ADC conversion on that pin finishes. You can try it out from libmaple like this (WARNING, this will delete any main.cpp you have):
$ git remote add -f mbolivar git://github.com/mbolivar/libmaple.git
$ git checkout mbolivar/adc-api-expansion
$ rm main.cpp
$ ln -s examples/adc-low-level-interrupts.cpp main.cpp
$ make clean; make installAny comments about the new API or the example code are very welcome. Here are the most important new functions:
- adc_set_conv_seq()
- adc_attach_interrupt()
- adc_start_conv()
- adc_get_data()
Some important new types, which you use in your interrupt handlers, are:
- enum adc_interrupt_id
- struct adc_callback_data
Barring any feedback which implies changes, I'll polish this up and merge it into master.
You must log in to post.