TM4C1294NCPDT: ADC configuration

Ralph Jacobi said:

Harshel

3. Is it possible to configure different reference voltage for ADC sequencers sharing same base ?

No, you would need to use separate ADC bases to select different reference voltages. This is handled at the ADC base level and not the ADC sequence level.

There is 'no doubt' that vendor agent is 'correct' in his statement.     

However - it (may) be possible to (inventively),  achieve poster's requested, "Different  (i.e. switched) reference voltages applied to the (same) ADC base."

Proposed would be a suitably chosen 'Analog Multiplexer IC' - which under GPIO control - (may) be able to provide, 'Different Voltages to the MCU's analog reference input!'     

Long ago my small Tech Firm applied such method - w/Success - yet that does NOT guarantee 'Success here - and now.'    (Testing should quickly answer, however.)     Note too that it is certain that a, 'sufficient delay' must be applied after such 'voltage switching' has occurred - prior to 'attempting to access the ADC.'    Experimentation may also uncover the (likely) 'additional capacitance (likely necessary) at the 'analog reference input' (such that the previous reference voltage level does not fully decay) - along w/a 'Break before make' switching action and fast switching ANA MUX.

[edit]:  Thinking further - it is likely that we employed a, 'Pull Up Resistor' to our 'Highest, Precision Voltage' - to be applied to the Analog Reference Input.    The ANA MUX was then able to, 'force (swamp) the input to the desired analog voltage level - while 'preventing the input from excessively decaying!'

In addition - are there not highly stable (bordering upon 'precision') voltage references (and/or regulators) which may supply, 'Different Voltages upon Command?'    (sometimes a single resistor - pulled (switched) to ground by a GPIO - enables the voltage to 'quickly & precisely' change level!)     And again - allow sufficient time for the MCU's ADC  to 'accept this new reference voltage.'

Good luck to you Harshel - it has been awhile...

I need to define initialization sequence for hardware and software components in design also mapping of hardware and software needs to be decided.

I need best way to handle above things in TI-RTOS environment.

This is a good solution to use analog mux.

But there is dependency upon stabilization of external voltage source.

If application requirements provides enough time to switching voltage using analog mux.

Most 'all' Engineering Decisions/Selections - involve 'Trade-Offs.'

Indeed the ANA MUX implementation borders upon, 'inspired.'

Stabilization & Switching Time must be, 'Discovered & Dictated by you' - focused experimentation - informs & advises that process...

Hello Harshel,

You should then configure everything through TI-RTOS rather than before it starts. I was looking through the RTOS example offerings and I don't see one for the ADC, so let me pull-in an RTOS expert to see if they can help give you a starting point here.

Thanks Todd.

I have used Hwi module for interrupt and it's working fine.

Is their any document which specifies driverlib APIs to be used before and after BIOS_start() ?

Harshel said:

2. Is it possible to configure different clock for different ADC sequencers sharing same base ?

E.g. I am using ADC0 base for SS0 and SS1, is it possible to process SS0 and SS1 with different clock frequency ?

Yes it is possible via two dedicated GPTM calls to SSIO Trigger Processor configurations, SS0 & SS1.

Perhaps Todd can elaborate if installing the TM4C LM4 timer module adds better IOS control than driverlib for tasks that may handle the results of each SSIO capture.

There is no documentation on usage of driverlib with TI-RTOS. Basically, let the kernel manage the vector table (and that includes managing the BASEPRI register). Note: the kernel enables interrupts during BIOS_start.

Todd

ToddMullanix said:

Basically, let the kernel manage the vector table (and that includes managing the BASEPRI register). Note: the kernel enables interrupts during BIOS_start.

I think that point was well presented in your earlier post. I was referring about enabling/configuring TM4C LM4 timer module versus the alternative driverlib. The kernel in my mind would add hooks into TM4C timer module where making driverlib calls to configure GPTM may not do that?

The user can either use the Timer module in TI-RTOS or manage it themselves via driverlib. Note, the Clock module in the kernel by defaults configures one timer to drive the clocking mechanisms (e.g. Task_sleep and Semaphore_pend). If desired, the user can supply the Clock tick though. For more details, refer to the Clock module's documentation.

ToddMullanix said:

The user can either use the Timer module in TI-RTOS or manage it themselves via driverlib.

Well I tried TI-RTOS with 6 timers configured via Tivaware with clock module single timer. As I recall the tasks that invoked Tivaware SW interrupt semaphore to print IOT stats got the timing of calls mixed up, beside being turtle slow! The other bad symptom was Task load produced bouncing graphs, 0-100% CPU usage.

Another point being they were not RTOS configured timers and appeared as task related asynchronous CPU load cycles. Perhaps a dual core MCU (Delfino) would be better suited when TI-RTOS becomes heavily loaded with many enabled peripherals.

Edit: I was believing the LM4 timer module was the TM4C timer module and have it enabled with no instances configured. Seemingly LM4 timer module should be upward compatible with TM4C timers and to extend HWI interrupt handling of GPTM timers. Perhaps that would fix the CPU load monitor bouncing from Task calls where timers and SW interrupts assert. 

Edit: I was believing the LM4 timer module was the TM4C timer module and have it enabled with no instances configured. Seemingly LM4 timer module should be upward compatible with TM4C timers and to extend HWI interrupt handling of GPTM timers. Perhaps that would fix the CPU load monitor bouncing from Task calls where timers and SW interrupts assert.