• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 32 subscribers
  • Views 1490 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123G UART Tx large amounts of data

Martin Cunningham
Prodigy 190 points
Other Parts Discussed in Thread: TM4C123GH6PM

Hello everybody,

I am currently programming a Tiva C series, TM4C123GH6PM Evaluation Board.

I need to send a relatively large amount of data to the PC. As you know, this board has an integrated virtual com feature (as soon as you plug the usb, and install the drivers, a virtual COM is generated). I've figured so far my best (and only perhaps) option is to send the data to this virtual COM port via the UART.

I've configured the UART0 peripheral, and used the UARTprintf command, and it works properly.

But, as far as I know, this is only for strings/chars types. I need to send an array of 300 elements, made by 16-bit registers.

I've read about the UART, and the uDMA feature. I don't know if activating the DMA is necessary in this type of transfers, or if it's enough with a while loop. I've seen a lot of code-examples, and read the TI forum, but I've found nothing like what I need so far. In every example I saw, they just use the UART to echo what is sent from the PC.

Can anybody give me a hint on where to start?
I'm not asking for anybody to solve this for me, only perhaps to point me in the right direction.
Thanks a lot for taking the time to read this.
Kind regards

Martín

  • 0
    TI__Guru**** 244400 points
    Hello Martin,

    The UARTprintf accepts integer types as well. Basically it would look like

    UARTprintf("%d",ui32Clock);

    You can use either DMA or CPU in a while loop. There is a udma_demo example to do the same in the TivaWare examples

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 190 points
    Hello Amit,
    Thanks for your support.
    I've got one more question. The data I've got to transmit is obtained by the ADC.
    As I understand it so far, the 12bit ADC should produce a 16-bit register for storing the data. Is this correct?
    My doubt arises because the "ADCSequenceDataGet()" function only seems to work with uint32_t types.

    So, does this mean every sample stored is 32 bit long?

    If this is the case, I may have to rethink my program. I've got to take samples of five different ADC channels. My original idea was to simply store everything on the 32 kb SRAM, and when the data collecting was over, transmit it via the UART.
    But If every data is 32bits long, that means I can only take 32768/32/5= approx 200 samples per channel before filling the SRAM memory.
    That may be insufficient for what I need.
    Is there any other way of making this "first I store all the data, and THEN I transmit it" approach?
    Or do I have to rethink the program so that I start transmitting every sample inmediatly after it's taken?

    Again, thanks for your help. It's greatly appreciated.
    Kind regards.

    Martin.
  • 0 in reply to Martin Cunningham
    TI__Guru**** 244400 points
    Hello Martin,

    Yes, when read into a uint32_t it is stored as a 32-bit value. You can however type cast it for a 16-bit to save SRAM.

    Since sending it over UART would use it in 8-bit format, the simplest of all solution would be to transmit it as soon as you read it from the ADC by using 2 UART transmissions. Make sure this is done in an ISR so that it is less interrupted. Also do keep in mind that the Baud Rate of UART would be slower than sample rate of the ADC.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    Surely (another) simple-minded approach follows. (my specialty)

    Perhaps Amit will agree - the 3 lsb of your MCU's ADC are sure to contain jitter - prove of little value. (this is true for all makers of MCUs - not a knock upon this vendor)

    Even the 4th lsb is often suspect - thus the 8 msb are safest - most likely to be accurate.

    And - of interest to your programming effort...AND speed of data transfer - those 8 bits mate perfectly w/the MCU's UART data size!

    As a higher speed option - you may consider SPI - which may pass the entire 16 bit data field (via Amit's suggestion) with greater robustness and transfer speed than the unclocked UART...   (yet still - only those highest 8 ADC bits are of high accuracy)

  • 0 in reply to Amit Ashara
    Expert 2415 points
    I would add a note on transferring binary values over a serial port; you need a method to have the sender and receiver agree on which byte is what. If you just blindly send the values of the variables in memory, you'll be having a hard time distinguishing high and low bytes, sample borders etc, as the valid range of values uses up all the available code points of the 8-bit transfer channel.

    I suggest to encode the values for example in HEX/ASCII, so that each sample would consist of 3 hex characters - nicely adding up to the full 12 bits of the ADC sample. Then you could use ascii characters outside the HEX range (0-9, a-f) to mark the beginning of the sample burst, for example.

    You will lose on bandwidth, but save on hair & fingernails.
  • 0 in reply to Veikko Immonen
    Guru 47900 points

    Surely valid points Veikko - yet (our posts crossed) the "promotion" of those 4 lsb seems (tad) unworthy as (especially) those last 3 are highly suspect.

    Eight bit transfer "removes" most of your (rightful) concerns of, "Who's who!"

    Should 12 bits (or even 10) be demanded - perhaps vendor's "real" ADCs should be reviewed by poster...   (free lunch (or ADC) not always best/brightest)

  • 0 in reply to cb1
    Expert 2415 points
    I was just about to edit my post after seeing yours - you're absolutely correct. If the lowest 4 bits are not needed and the samples are from a single source (ie. it doesn't really matter which sample is which, as their order will be preserved in any case), there's no need for any special encoding.
  • 0 in reply to Veikko Immonen
    Guru 47900 points

    Indeed - posters (sometimes) must (know) "real-world" performance/behavior - to enable "proper" design decisions.

    As marketing "reaches" for higher speeds - more bits - "real usage, engineering reality" often intrudes.

    As you/I (and possibly) Amit agree - baseless to undergo extra/special/speed-slowing efforts to "harvest" a suspect last nibble...

  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello cb1, Veikko,

    Yes. removing the lower 4 LSB's will cause an error of ~12 mV unless this is non-acceptable for the application.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points

    If not mistaken - and if "V_ADC Reference" exists - & can be reduced in value - that ~12mV (12.9) may be (even) further reduced.

    Again - this "real-world" observation (use 8 msb) substantially reduces the poster's work-load while speeding & easing his data transfers...

  • 0 in reply to cb1
    TI__Guru**** 244400 points
    Hello cb1

    Indeed. I was putting the numbers out for 3.3V Reference

    Please do note that I haven't used the ADC below 3.0V reference.

    Regards
    Amit