Quantcast
Channel: Forums - Recent Threads
Viewing all articles
Browse latest Browse all 262198

Identification of a (possible) 'Assert Conflict' w/in long-standing API file, adc.c!

$
0
0

Greetings,

In attempting to aid a poster - trying to implement, 'Hardware Oversampling' w/in the TM4C123 MCU - the following was discovered.    Credit  our (independent) firm's 'Jennifer' - w/this discovery - which intends to serve multiple others - if indeed the conflict proves 'real.'      (which both Jennifer & I believe - it is!)

The conflict appears w/in the ADC Function:  'ADCClockConfigSet()'  and is first described - then introduced below:

//*****************************************************************************
//
//! Sets the clock configuration for the ADC.
//!
//! \param ui32Base is the base address of the ADC to configure, which must  always be \b ADC0_BASE.

Yet - when this function is examined - the following reveals:

void
ADCClockConfigSet(uint32_t ui32Base, uint32_t ui32Config,
uint32_t ui32ClockDiv)
{
//
// Check the argument.
//
ASSERT((ui32Base == ADC0_BASE) || (ui32Base == ADC1_BASE));
ASSERT((ui32ClockDiv - 1) <= (ADC_CC_CLKDIV_M >> ADC_CC_CLKDIV_S));

It would appear - that the (expanded) acceptance of ADC1_BASE - occurred post this Function's (Preamble) or  Description...    And that this (new) broader ADC Module acceptance - negates the 'must always be' (restriction) - w/in the  function's description!


Viewing all articles
Browse latest Browse all 262198

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>