analog watchdog in adc

https://jeelabs.org/article/1619b/

it seemed to be there in stm32f103 (i.e. all the BP & MM etc), has anyone played with it?
it seemed like an underutilised useful stuff

anyone got a 4th to english translator
srp

You should just think about it as a high resolution analog comparator with programmable threshold.

[ag123 – Sun Jan 07, 2018 8:21 am] –
<…>
it seemed to be there in stm32f103 (i.e. all the BP & MM etc), has anyone played with it?
it seemed like an underutilised useful stuff

I have seen mention of the capability in the ST PDF AN2834

However, I have not personally implemented this on the bench. Sounds promising.

Ray

actually i’m looking for a comparator and in stm32f103, the simple analog comparator isn’t there. instead st substituted the comparator with 2 digital threshold comparators hide it in the adc and called it ‘analog watchdog’, that sounds good as well

a conventional LC meter circuit based on the ne555 uses 2 analog comparators as trigger and threahold detectors and configured as an astable multivibrator and have a 8051 cpu counting the pulses to deduce frequency
https://www.electronicshub.org/lc-meter … 555-timer/

i’m thinking that these digital thresholds / triggers could work just as well as those conventional analog ones, and i save the trouble of needing an additional comparator etc
but i’m thinking perhaps there are other / better ways such as setting a timer to trigger/fire the ADC to sample after a fixed interval
take a couple of samples and i’d be able to work out the inductance or capacitance

but i’d think this ‘analog watchdog’ would have many more use cases than a simple LC meter use case, it could for instance be used as sensing triggers from capacitive or inductive sensors or for instance it could be made to trigger when the temperature from the build in temperature sensor reaches a particular temperature

[ag123 – Sun Jan 07, 2018 8:21 am] – has anyone played with it?

I just used the analog watchdog to implement an adapter that captures the irDA-formatted data in a PalmOne folding wireless keyboard and converts it to USB HID. It was kind of hard to figure out how to use it, but it seems to work. The incoming data has a high level of about 1.53v, so I use the ADC rather than GPIO to capture it. (Interestingly, the data also has levels reversed from standard irDA, because of where I capture the data.)

The code is really messy, but maybe it will help somebody with using the analog watchdog:
https://github.com/arpruss/palmirkeyboard_stm32f1

interesting !

i found some better codes for using the STM32ADC, it is actually part of the libmaple core distribution for F1
https://github.com/rogerclarkmelbourne/ … s/STM32ADC
seem like the codes may have been contributed by stevestrong etc.
i saw some codes that aid the use of the analog watchdog, i’ve not used it personally though

I started by using that library, but it looks unfinished, so I just ended up doing things directly with the core functions.

[arpruss – Tue Jan 23, 2018 2:05 pm] –
I started by using that library, but it looks unfinished, so I just ended up doing things directly with the core functions.

The community would be very happy to see your development, this would be a minimum contribution from your side.

[stevestrong – Tue Jan 23, 2018 3:34 pm] –

[arpruss – Tue Jan 23, 2018 2:05 pm] –
I started by using that library, but it looks unfinished, so I just ended up doing things directly with the core functions.

The community would be very happy to see your development, this would be a minimum contribution from your side.

Maybe eventually. I am still polishing my USBHID library to make it more developer friendly. (It’s already quite developer friendly if you just want to use the Keyboard/Mouse/Joystick/X360 controller, but it’s not very friendly if you want to implement new HID devices. And the feature/output report support is still a bit of a mess.)

Does anyone know if I can have two analog watchdogs, one on each ADC, each watching for a different condition on a different channel?

As the ADCs have different registers, you can setup different WDs.
But be aware, that ADC1 and ADC2 interrupts are mapped onto the same interrupt vector.

Can I tell in the handler which one was triggered?

It looks like the current version only supports ADC1 interrupts.
ADC2 does not even have ISR handler table defined.
https://github.com/rogerclarkmelbourne/ … e/adc_f1.c

[stevestrong – Fri Feb 16, 2018 2:20 pm] –
It looks like the current version only supports ADC1 interrupts.
ADC2 does not even have ISR handler table defined.
https://github.com/rogerclarkmelbourne/ … e/adc_f1.c

I assume you mean the current version of the core, but one can still do it by direct register manipulation?

Looking at the core code, one would have to override the irq handler vector, and unfortunately the core defines __irq_adc() as a strong symbol.

I suppose I could just make a second copy of the interrupt vectors somewhere in RAM (so I can ensure the requisite alignment) and call nvic_set_vector_table()?

Perhaps the core could be changed to make this IRQ weak.

The ISR definition is fine, only the code has to be extended to handle ADC2 registers, too.

The handlers have to be defined for ADC2, similar to ADC1:
adc_dev adc1 = {
.regs = ADC1_BASE,
.clk_id = RCC_ADC1,
.handlers = {[3]=0}, //added by bubulindo. EOC, JEOC, AWD
.irq_num = NVIC_ADC_1_2,
};
/** ADC1 device. */
adc_dev *ADC1 = &adc1;

adc_dev adc2 = {
.regs = ADC2_BASE,
.clk_id = RCC_ADC2,
.handlers = {[3]=0}, // --- this must be added to handle ADC2 interrupts ---
};