Transfering ADC data to PC

Pablo Juanito said:

... if there's a way to transfer the data that I receive on TIVA's ADC to my PC

Amit's given several examples - all transfer in (near) real time.

That said - I don't believe "real time" is your (present) goal.

My small tech firm - in contrast - copies the ADC data to SRAM - carefully managed so as not to disturb any (other) MCU processes.   Under our pro IDE (IAR) we can simply copy/paste this RAM data (over 380KB w/our M4 MCU) into "Excel" - and benefit from the powerful capabilities of the program & PC in combination.  

Suspect this method will work well for you - too..

Hello @cb1_mobile, thanks for the feedback!

You said that this method would work for me - definitely! That's what I need. However, as I said before, I'm just a beginner. Do you think I could develop a code like yours by myself from scratch?

Hello @Amit Ashara. I'm looking for any kind of transfer, but UART. I mean, I'm not considering UART as transfering because I don't really have "access" to the values, that's just a command prompt being filled with the values I want. I would like to really have access to the values - either excel, .txt, .doc... whatever form. Is USB the only way I believe, so I'll take a look at the Serial Boot Loader that you mentioned.

As I'm working with TM4C1294XL, I have ETHERNET available (what I could use to transfer data), but reading a bit, that seems extremely hard for me. 

Any suggestion is super welcome!

Thank you both again! J.

:)

Pablo Juanito said:

Do you think I could develop a code like yours by myself from scratch?

From scratch - maybe - but if you do the bulk of the work - I'm quite sure Amit, Robert, f.m. and this reporter will provide tips & encouragement.

Firm/I believe (always) in KISS.   (don't interpret that negatively - last S stands for "Student.")   So - how do we simplify - break the big task into more manageable, smaller pieces?

• master the ability to write "fixed" test values into RAM, incrementing the RAM address after each write - while testing for, "Ram at its end"
• master the ability to achieve proper ADC operation w/in your desired channels
• then - and only then - combine these two - which should satisfy your expressed requirement

It is usual to employ pointers to write (or read) from RAM.   And following that write/read w/address increment enables you to place vast stores of data into RAM.

We're no fan of vendor's CCS (we work w/many ARM MCUs) and very much prefer "pro/real" IDEs (IAR & Keil).   Both of the pro IDEs enable the display of RAM data - and the retrieval of that data so that it may be "pasted" into Excel.   While "not" real time - your data rate is likely to exceed that of any "Live Transfer" and you'll find it very hard to beat the power of Excel for data analysis.

You'll have to experiment to see if CCS (if that's what your using) enables you to view and copy sequential data stored in RAM.   I know that the "free, code-size limited version of IAR (Kickstarter)" achieves this.   You may download IAR for ARM from IAR's website - again it's free.

Any attempt to use USB or (worse still) Ethernet will add weeks to your project - if it can even be done.   The KISS method should get you "On the Air" by this Friday - if you follow instruction and proceed w/care.

Greetings Amit,

Recall that poster's data is 12 bit ADC data - thus writing via UART becomes a non-trivial matter.   Writing 12 bit data to RAM is far easier - and "light-years" faster - is it not?

Using the UART or USB or other methods draws the poster's task out - violates KISS - and will extend this thread into (the usual) 50+ "back-forth."

Writing directly into MCU's RAM is a fast, eased, powerful technique - unwise to bypass!

Robert - this IS 12 bit data - easy to write to RAM - not so much to transfer via UART.   (or - have I missed something?)

The data quantity is also effectively unlimited.

The data rate, however, is not. And beginners often fail to realize the bandwidth requirements for such a data transfer.

And second, implementing such a data transfer to run concurrently with sampling is often over their head, too (not real KISS).

Thank you f.m. - KISS (practically banned here) {due to misguided "PC," I guess} receives too little (NO) emphasis.

Instead - "always & only" force the MCU into (other) than it's "sweet spot!"   (while leading eager posters (unwarned) to, "high cliff!")

One doubts that "massaging" each/every, 12 bit, binary, ADC value into, "4 digit ASCII" (required for UART/USB transfer) qualifies as, "easy." NO such "monkey motion" (especially such "monkey motion") is required under the (greatly eased) method I've (earlier) described...

I may not be the right person to opine, however I believe UART was "fair simple" to get the data. I don't know if I did correctly or the best way (at the end of the day I'll post the code so you could analyze).

What happens if one or more characters are corrupted and/or lost during transmission ? That happens frequently with UART/RS232 transmissions. For a stable and robust transfer, you should include such a kind of "rainy day" scenario.

Following upon (again) f.m.'s thoughtful posting - how do you send the 12 bit, ADC value - via UART? Do you first convert to 4 digit ASCII (i.e. convert 0xFFF to "0x34""0x30""0x39""0x35") and (only then) make a call to the UART send function?    That's four separate calls to "UART Send" - might that invite error/trouble?

Hasn't that slowed your conversion rate?    And hasn't the ADC data rate (some) importance to your measures?

Writing the ADC conversion values directly to SRAM (remains) the fastest, simplest and most robust means to achieve your objective...

Writing the ADC conversion values directly to SRAM (remains) the fastest, simplest and most robust means to achieve your objective...

As I understood it, getting this ADC data to a PC is one of his main objectives - which would not be achieved by sampling into RAM.

Sending the data per UART is easy at first glance, but achieving a stable and robust transfer is not that trivial.

First, the UART throughput must be higher than the ADC throughput (sampling rate), for obvious reasons. However, the data amount to pass through the UART is usually at least twice as large as that of the binary sampling data (see below).

Second, for robustness, one (usually) needs to introduce redundancy in the transfer protocol. Binary transmissions are a bad idea, and prone to fail quickly. Proved methods to improve transfer reliability are:

• conversion to ASCII
• splitting up into packets, with unique start/stop byte
• checksums

This allows the receiver to detect transmission errors and drop-outs, and to re-sync at (almost) any time. NMEA183, as used by GPS receivers, is a good example for such a (mostly) unidirectional transfer protocol. But as said, here the implementation starts to become non-trivial ...

f. m. said:

As I understood it, getting this ADC data to a PC is one of his main objectives - which would not be achieved by sampling into RAM.

May I disagree?   Nowhere does the poster state - nor limit - the "How" of, "Getting data to a PC."  

My first post described (just) how my firm does that - IAR enables the quick/easy copy of RAM memory - and then "ONE, simple mouse click" GETS that RAM stored, ADC Data - into a PC!   (ideally into the opened, properly prepared Excel file)   

Note that this method - though simple - avoids "all" communication delays and errors - while imposing NO/ZERO delays upon the ADC conversion process...

f. m. said:

The data rate, however, is not. And beginners often fail to realize the bandwidth requirements for such a data transfer.

Yep, OTOH they also usual considerably overestimate the analog bandwidth they nee and that their sensors are capable of..

And the low frequency simplifies the analog requirements as well.

Robert

I'm with f.m. on this one and conversion to ASCII is a simple and robust call to the standard library. And considering TIVAWare's support for serial I/O it really doesn't get much simpler.

Once you move into noisy environments or automatic collection then you have to consider more robust transfer methods but then the ICE method doesn't really suit either.

The downside to ICE (besides the limited data) is you need to add some sort of triggering method, where with the serial you can just send the data out and start collecting whenever you want.

Robert

Pablo Juanito said:

However, now, I'd like to do something "automatic", I mean, keep sending this data to Matlab for example

That's a significant step in complexity. You will need to follow whatever format Matlab requires. Make note of the bandwidth limits f.m., cb1 and I have noted.

Pablo Juanito said:

But regarding RAM writing, I'm not that sure if that would be a simple task for me.

Decidely not simple for this use. It may be necessary if you need bursts of high speed.

Continuous high speed will likely require moving to a different interface method entirely.

Robert