• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 32 subscribers
  • Views 1021 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.

TM4C129ENCPDT: Designing data acquisition device with the tm4c129

Josue Pareja
Expert 1605 points
Part Number: TM4C129ENCPDT


Hi, I have been working with the tm4c129 in order to create a data acquisition device, using 8 channels of the ADC0 and USB 2.0 HS (ULPI). The data acquisition (DAQ) must  send the data to my PC without any  cuts, but I am having a problem with that. I have configurate de ADC to work with 30 KHz of sampling frequency per channel ( as I said I am using 8 channels) and the USB is working with an ULPI device in order to obtain more speed, but it seens to not be enough.

Please watch the figure an you will understand what is the problem:

To obtain the data from the TM4c129 I am just sending at the begining a command to start the analog to digital conversion, the ADC data goes through a DMA channel directly to the USB transmitter buffer "g_pui8USBTxBuffer" then the data is sended to the PC, the command of the begining is not sended again, the DMA channel fills the USB buffer and continue with the sendings, the packet size contains 2000 values from the ADC, so that means 250 values from each channel.

What I would like to know is a way to find out wich of the devices (PC or MCU) is generating this problem, in other words, wich of them is the slower, I know that a PC is obviusly a faster devide, but maybe is a code problem, because, maybe is not very optimized (I am using the commands from the USB bulk device example from TIVA ware). Also, does anyone knows any other way for data acqsitioning?? is really bulk trasmition the fastest way??

Thanks

  • 0
    Guru 117855 points

    I've no experience w/your 129 series MCU - nor w/that USB to PC transfer mechanism.    That said - a "KISS" inspired/directed method - surely can aid & advance understanding.

    From your neat graphical data histogram - we note that the readings you claim to be "in error" - appear to be 16 measurements apart.    (your 4 red highlights yield 3 such 16 measurement deltas - do they not?)

    You should be able to test for the ADC's "data integrity" by (also) logging each conversions value to MCU's SRAM - either just prior to - or as part - of your µDMA to PC transfer process.   You may then - after the fact - compare "data in SRAM" vs. "data in the PC" - to confirm that "data transfer" is the culprit.

    The fact that your graph reveals the "16 measurement periodicity" deserves your consideration - don't you think?     It would appear that your "error issue" may reside within:

    • your ADC, or your code implementation
    • your µDMA, or (again) code implementation
    • your µDMA to MCU USB "handoff"
    • the PC end

    It is possible - but perhaps unlikely - that such errors will originate from "more than one" of the above sources.     If that is agreed - then follows an attempt to, "identify the error source."

    One "quick/dirty" test (i.e. cb1's favored test) would be to send a known - yet "fixed" data value - via your (unchanged) µDMA to PC transfer process.  Should the "fixed data" then vary - you have likely confirmed that your MCU's  "µDMA to USB" transfer process - or the PC - is the likely source.    If the "fixed data" test runs error free - does not your ADC (or coding) rise on the "suspect list?"

    You may then both (systematically) slow and raise transfer speeds - in the effort to discover the highest transfer rate which executes "error free." (or with an acceptable percentage of errors.)

    You may be able to discover existing, commercial products - which provide high speed data to the PC via USB - and glean information as to (both) your (combined) PC/USB data rate's acceptance.   Employing such a "known good" device is a standard, "KISS" troubleshooting technique - minus that - you likely remain in a quandry - as the number of "unknowns - and total absence of knowns" surely delays & clouds analysis...

  • 0
    Guru 27665 points

    Josue Pareja said:
    I have configurate de ADC to work with 30 KHz of sampling frequency per channel

    By what method?

    Josue Pareja said:
    Please watch the figure an you will understand what is the problem:

    That's of no help.

    • The arrows point to one section of the plot
    • You have a different section circled
    • There's no indication of what the signaled being sampled should look like

    If that's a Fourier transform of the data and you're primary frequency is 14kHz then the off-peak values aren't especially surprising, you aren't sampling much more than twice per cycle.

    Robert

  • 0 in reply to Robert Adsett
    Guru 117855 points

    Forum "weekend, abandoned greetings" Robert.

    Interesting that we chose (almost) far different aspects of poster's presentation.

    I sense a fairly "common theme" in play - that is the seeming, "passage of "live data" acquired by the MCU - to a PC - as fast as possible."    And - as always - never is the need for such "live data capture & immediate passage to the PC" explained, nor justified.

    Surely the PC brings "extended data handling, processing & storage capabilities" - yet is the "absolute immediacy" of such so vital?     (I don't know - yet I do know that in, "Vital System Monitoring" (i.e. defense/medical) we most always task the "Data Acquisition System" to make "most all critical/impacting decisions" - rather than, "add the risk" (always introduced) by, "data passage/transfer."

    When posters "withhold all support for their design decisions" - yet suffer impacted performance - have they not (unnecessarily - possibly mistakenly) restricted the "scope & power" of design review (beyond) limited (perhaps miscast) diagnostics?

    If/when posters' cannot satisfy their objectives - are we to "always & only" agree with their (unexplained/unjustified) fundamental design decisions?     Is it not (so often) true that "bad initial design decisions/paths" - despite feverish (after the fact) corrective "chiseling" - may (still) not yield optimal outcomes?

  • 0 in reply to cb1_mobile
    Guru 27665 points

    cb1_mobile said:
    I sense a fairly "common theme" in play - that is the seeming, "passage of "live data" acquired by the MCU - to a PC - as fast as possible."    And - as always - never is the need for such "live data capture & immediate passage to the PC" explained, nor justified.

    That  a common theme, although the OP did state they were constructing a data acquisition system. That is likely to require considerable storage somewhere

    Whether or not they need an acquisition system or a controls system (with possibly data acquisition as well) is a valid question.

    Robert