Page 3 of 3
Re: ADCv2
Posted: Tue Sep 20, 2016 2:04 pm
by neums
Hi,
can you give me a short feedback please?
Thanks

Re: ADCv2
Posted: Tue Sep 20, 2016 2:05 pm
by Giovanni
hi,
I have not examined that code yet. It is in queue, don't worry.
Giovanni
Re: ADCv2
Posted: Wed Sep 21, 2016 8:04 am
by neums
Hi,
thank you. I tested it with the STM32F4 and it works fine. I implemented a regular conversion sequence triggered by TIM2 and a injected sequence triggered by TIM4.
I defined the HOOK in osal.h to a function call:
Code: Select all
#define STM32_ADC_ADC1_IRQ_HOOK if(osal_adc_1_jeoc_callback != NULL)\
osal_adc_1_jeoc_callback()
and i declared the osal_adc_1_jeoc_callback() as extern:
Code: Select all
typedef void (*osal_adc_jeoc_callback_t)(void);
extern osal_adc_jeoc_callback_t osal_adc_1_jeoc_callback;
So i can define the specific callback function in my application code everywhere where osal.h is included.
I whould like to have a switch in halconf.h like ADC_USE_INJECTED_CONVERSION (Maybe ADC1,2,3 specific) but the problem is, that osal.h is included in hal.h before the hal_conf.h is included. Is this order fix? I thougt that the hal_conf.h is only a configuration so that the osal.h may be dependent from this file. Does it make sence to change the inclusion order in hal.h?
Thanks.
Re: ADCv2
Posted: Wed Sep 21, 2016 10:39 am
by neums
Hi,
one more open point. In ADCv1 and ADCv2 the hook is named STM32_ADC_ADC1_IRQ_HOOK but in ADCv3 it is named different (STM32_ADC_IRQ_HOOK). I whould be more plattform indepented due to STM if this naming is the same in all versions.
There is also no dispatching of the interrupt source in the ADCv3 but in ADCv1 and ADCv2 there is such a dispatching. A unified method should be better, isn't it?
Thanks
Re: ADCv2
Posted: Mon Oct 03, 2016 11:05 am
by Giovanni
neums wrote:Hi,
i whould be very useful if the ADCDriver pointer is proceeded to the STM32_ADC_ADCx_IRQ_HOOK by evaluating the JEOC of the SR in the OSAL_IRQ_HANDLER(STM32_ADC_HANDLER) defined in hal_adc_lld.c:
Code: Select all
#if defined(STM32_ADC_ADC1_IRQ_HOOK)
#if STM32_ADC_USE_ADC1
sr = ADC1->SR;
ADC1->SR = 0;
/* Note, an overflow may occur after the conversion ended before the driver
is able to stop the ADC, this is why the DMA channel is checked too.*/
if ((sr & ADC_SR_OVR) && (dmaStreamGetTransactionSize(ADCD1.dmastp) > 0)) {
/* ADC overflow condition, this could happen only if the DMA is unable
to read data fast enough.*/
if (ADCD1.grpp != NULL)
_adc_isr_error_code(&ADCD1, ADC_ERR_OVERFLOW);
}
/* TODO: Add here analog watchdog handling.*/
#if defined(STM32_ADC_ADC1_IRQ_HOOK)
if(sr & ADC_SR_JEOC)
STM32_ADC_ADC1_IRQ_HOOK(&ADC1)
#endif
#endif /* STM
In this implementation the hook is only called if the ADC module really is the source of the interrupt. E.g: if ADC2 throws the interrupt the ADC1 hook whould not be called this way.
This way the hook would be dedicated to injected conversions only, it is meant to be a generic hook and the "if" can be placed inside without problems.
Re: ADCv2
Posted: Mon Oct 03, 2016 11:11 am
by Giovanni
neums wrote:Hi,
one more open point. In ADCv1 and ADCv2 the hook is named STM32_ADC_ADC1_IRQ_HOOK but in ADCv3 it is named different (STM32_ADC_IRQ_HOOK). I whould be more plattform indepented due to STM if this naming is the same in all versions.
There is also no dispatching of the interrupt source in the ADCv3 but in ADCv1 and ADCv2 there is such a dispatching. A unified method should be better, isn't it?
Thanks
Hi,
Implemented this.
Giovanni
Re: ADCv2
Posted: Tue Oct 04, 2016 12:28 pm
by neums
Hi,
thanks for replying. Did you think about the inclusion order in hal.h?
Re: ADCv2
Posted: Tue Oct 04, 2016 2:00 pm
by Giovanni
Hi,
In the architecture HAL depends on OSAL but not vice-versa, you can use OSAL without HAL. Including OSAL first reflects the architecture.
Giovanni
Re: ADCv2
Posted: Tue Feb 14, 2017 10:01 am
by neums
Hi,
is there something missing why this feature didn't move from trunk to 16.1.7 stable?
Thanks
Re: ADCv2
Posted: Tue Feb 14, 2017 10:04 am
by Giovanni
Hi,
Stable branches only receive bug fixes, new features will happen in the next major release (17.2 or 17.3).
Giovanni