ADCv2 Topic is solved

[neums]

Hi,
can you give me a short feedback please?

Thanks

[Giovanni]

hi,

I have not examined that code yet. It is in queue, don't worry.

Giovanni

[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.

[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

[Giovanni]

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.

[Giovanni]

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

[neums]

Hi,
thanks for replying. Did you think about the inclusion order in hal.h?

[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

[neums]

Hi,
is there something missing why this feature didn't move from trunk to 16.1.7 stable?

Thanks

[Giovanni]

Hi,

Stable branches only receive bug fixes, new features will happen in the next major release (17.2 or 17.3).

Giovanni