• State Resolved
  • Locked Locked
  • Replies 29 replies
  • Subscribers 81 subscribers
  • Views 9187 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430 USB HID Java Demo App - Receive data 1kHz rate

Mihika Perera
Prodigy 105 points

Hi,

I'm developing a USB HID device which needs to send sensor data at a 1kHz rate continuously to the Host PC. Currently I'm reading the sensor values through ADC and using HID Datapipe to send data every 1ms ( My code is based on the H0 Simple Datasend example). When I view the data on the HID Demo App, I can see some chunks of data is missing inbetween, and the windows application hangs after about 10 seconds of receiving data. But the microcontroller is still working fine when I check through CCS Debug. Is there a limitation in the receiving rate or the maximum number of data lines for the Java Demo App?

I tried it at 1Hz rate as in the example code, and the system works fine, but I couldn't leave it so that it collects more than 10,000 data points to check if it hangs after that.

Would really appreciate if any one could help me to clarify if it's a problem with the Java App or my microcontroller code.

Many Thanks,

Mihika

 

  • 0
    Guru 227245 points

    Are you sure that windows application can handle 1000 datagrams per second? If not, it is possible that after 10 seconds, the internal buffer overflows with unprocessed data, adn if buffer size and data size don't match (integral multiple), the applicaiton will fetch broken datagrams and crashes while trying to interpret them.

  • 0 in reply to Jens-Michael Gross
    Prodigy 105 points

    Thanks a lot for your reply..The final windows application for the project is developed by someone else, and 1kHz data rate was the specification given to me. I'm trying to test whether this is possible from the hardware side using the MSP430F5529LP Launch pad &  TI USB HID Demo application. I really don't know whether windows can handle such a data rate, I've read somewhere that 10ms is the maximum it can handle. I couldn't find any data rates or data buffer size details for the HID Demo App. Would be great to know the limitations of the HID Demo App or Windows in general.

     

     

  • 0 in reply to Mihika Perera
    Guru 227245 points

    Mihika Perera said:
    I really don't know whether windows can handle such a data rate

    Well, the plain data transmissionshouldn'T be a problem. the question is whether the UI is capable of processing the incoming data and updating its display 1000 times a second.

    Adding a packet counter to the display and checking whether it really increments by 1000 per second would be a starting point.

    Mihika Perera said:
    using the MSP430F5529LP Launch pad &  TI USB HID Demo application. I really don't know whether windows can handle such a data rate, I've read somewhere that 10ms is the maximum it can handle.

    Of course it might be required to combine multiple data packets into one USB transmission, to minimize the USB protocol overhead. and/or switching from HID to VCP (serial data stream). THis includes rewriting part of the PC frontend.

    Mihika Perera said:
    I couldn't find any data rates or data buffer size details for the HID Demo App. Would be great to know the limitations of the HID Demo App or Windows in general.

    Probably try and error :) But it might be that the HID model has some limitations in the standard. Usually, HID updates are sufficient if in the range of the screen update frequency (in case of any visual feedback). 10ms means 100Hz which sounds reasonable for a 'human interface device'. I don't know of any human who would be capable of providing faster input than 100Hz or timing his input better than 10ms resolution.

  • 0
    Guru 46710 points

    Mihika Perera said:
    sensor data at a 1kHz rate

    As USB is asynchronous and far from realtime (as well as Windows and most std. Linux compilations) perhaps it's not that important to send one sample each 1ms. Maybe you can live with 100 samples each 100ms and still be fine.

  • 0 in reply to Ilmars
    Prodigy 105 points

    Thanks very much Jens & Ilmars... The project is developing a physical interface for a musical instrument, hence according to the given specs, the latency should be less than 4ms. I totally agree with your points, I think I should go back to the drawing board and rethink about the data rates..

    Thanks again for your help..

  • 0
    Guru 34453 points

    Mihika Perera said:

    I'm developing a USB HID device which needs to send sensor data at a 1kHz rate continuously to the Host PC. Currently I'm reading the sensor values through ADC and using HID Datapipe to send data every 1ms ( My code is based on the H0 Simple Datasend example). When I view the data on the HID Demo App, I can see some chunks of data is missing inbetween, and the windows application hangs after about 10 seconds of receiving data. But the microcontroller is still working fine when I check through CCS Debug. Is there a limitation in the receiving rate or the maximum number of data lines for the Java Demo App?

     

    I didn't play with HID on MSP430F5xx / PC so don't know much about it. Theoretical maximum HID rate is 64 KB/s, and your transfer is about 1 KB/s, so it should work.

    As noted by limars, better will be to collect data and store them temporary on MSP430F5xx buffer. When buffer become full, just send it at once over USB to PC. I was working on MSP430F5xx / PC with CDC (virtual COM port), and PC side implementation is much easier than HID, and transfer rate is about 800 KB/s .

  • 0 in reply to zrno soli
    Prodigy 105 points

    Thanks for your reply zrno..  You have pointed out an important fact that I overlooked, 64KBps maximum data rate. Even though I'm updating & transferring data at 1kHz rate, it's not just one byte of data as I'm sending 4 ADC values. I will calculate how long my data packet is, to check if I'm going over 64 KBps. Thanks again...

    P.S. In this application I have to use HID as the drivers need to be installed automatically on PC side, but I'm having problems with displaying actual name of the device when it gets installed... I will post about that problem in a different thread..

  • 0 in reply to Mihika Perera
    Guru 46710 points

    Mihika Perera said:
    The project is developing a physical interface for a musical instrument, hence according to the given specs, the latency should be less than 4ms

    No battery, USB powered - right? Why msp430 then? I would chose some ARM uC for such project.

    If it's musical instrument, then why HID and not USB-MIDI?

    http://www.usb.org/developers/devclass_docs/midi10.pdf

    1000Hz update rate is nothing special for USB in general or even USB HID devices, for instance gaming mouses happen to have 1000Hz update rate. Perhaps you are hitting either msp430 or java application performance limitations, but it's not about USB.

  • 0 in reply to Ilmars
    Prodigy 105 points

    Thanks for the clarification Ilmars.. I'm new to USB development, and after some research I thought MSP430 was the quickest  way to develop USB applications because of the well structured USB developer package & the newly introduced EXP430F5529LP USB Launch pad... maybe I'm wrong to choose MSP430 for the project, I will have a look at Tiva C series arm microcontrollers again.. At a later stage, there's a plan to make the device wireless & battery powered that was one other reason for using MSP430.

    Thanks for the link to USB-MIDI. HID was the requirement from the host side software developer, but  I will research on USB-MIDI and compare what's best for the project. 

  • 0 in reply to Mihika Perera
    Guru 46710 points

    Mihika Perera said:
    HID was the requirement from the host side software developer

    Weird. Please share more about your musical instrument, if possible. What kind of musical instrument it is and what kind of data it will send to PC?

  • 0 in reply to Ilmars
    Prodigy 105 points

    The device is not a conventional musical instrument, it only acts as the physical interface sending raw sensor data corresponding to human interaction with the device, all the data processing, sound production is done real time on the host PC. Sorry I'm not allowed to go in to more details about the project. A quick search revealed that MIDI is much slower than HID, but I need to research on that more, may be that's the reason for moving on to HID.

     

     

  • 0 in reply to Mihika Perera
    Guru 46710 points

    Mihika Perera said:
    I'm not allowed to go in to more details

    Sure you can tell sensor data resolution (how many bits) and channel count. Instrument will be digital termenvox/teremin, right?

  • 0 in reply to Mihika Perera
    Guru 227245 points

    Mihika Perera said:
    the latency should be less than 4ms.

    Then USB surely isn't the right way to transfer the data. USB isn't deterministic, even though isochronous transfer modes (does anyone use them?) have been developed for equidistant transfers. Also, data grouping is not an option.

    USB (unbelievably scrappy bus) is a non-deterministic monster regarding memory usage, CPU load and latency. You don't know what else might be connected to the USB subsystem (even internally, or on the mainboard) or to which hub port or with how many hubs in-between your device is connected.

    Believe it or not, a good old real serial port, even with a low baudrate, is by magnitudes better when deterministic behaviour (= low or at least constant and known) latency is required.

  • 0 in reply to Jens-Michael Gross
    Guru 46710 points

    Jens-Michael Gross said:
    USB (unbelievably scrappy bus) is a non-deterministic monster

    Not always best thing available is good for masses. We all know how ended VHS vs Betacam "war for consumers", USB vs FireWire is very similar if we talk about multimedia I/O. USB initially was just printer and serial port plug. Only later it became also storage, media and not only, interface. Actually close to nothing in (personal) computers today is really deterministic - besides deterministic appearance of bugs in software.

    If one is so stupid to not correctly plan his system so USB MIDI adapter has enough bandwidth and CPU has enough resources to handle MIDI events in time then perhaps he does not deserve to have responsible musical setup :D

    I am not advocating USB as best possible solution for realtime data transfers, however I know that USB MIDI adapters works quite well and their jitter is tolerable. Otherwise there would be no tons of USB MIDI i/o products.

    Back to subject: USB interface is actually bad idea for musical instrument due to cable length and EMI limitations. I would go with classic MIDI current loop. On PC side - MIDI-controllable VST and/or DirectX Instrument (DXI) plugin is way to go. No java program for god's sake.

  • 0 in reply to Ilmars
    Guru 227245 points

    Ilmars said:
    If one is so stupid to not correctly plan his system so USB MIDI adapter has enough bandwidth and CPU has enough resources to handle MIDI events in time then perhaps he does not deserve to have responsible musical setup :D

    Sometimes you don't know what you get. Today, onboard components are attached using USB. Teh USB controller and drivers are rather random etc.

    I prefer a dedicated system (specifically built for this purpose) for any critical task. For music, print industry etc, the MAC was the device of choice for a long time. Because it did have a well-known and fine-tuned hardware and thoroughly tested and tune software. It still is in some areas, btu the latest mass of new device releases has crippled this fien approach (in the hopes of gettign  amarket share in allround-devices).

    I wouldn't buy a MAC for a multy-purpose system. But if multi-purpose is not a requirement, and reliability and deterministic usage is important, I'd still prefer a MAC (one of the old ones, before it was going multimedia-PC)

    Ilmars said:
    Otherwise there would be no tons of USB MIDI i/o products.

    There have been tons of VHS recorders too :)
    Unfortunately, people don#t know what crap they are buying, if they never learned about the alternatives (and many people will prefer cheap crap over more expensive quality products).

    Ilmars said:
    I would go with classic MIDI current loop.

    I'll second that. And no USB/midi converter, please! :)

    Ilmars said:
    No java program for god's sake.

    for sure. If you know what you're doing, Java is astonishingly capable (Our metering server runs on Java, also good old Azureus is doing a good job), Same for Flash/Flex. But for deterministic or time-critical usage: no, please not.

  • 0 in reply to Ilmars
    Prodigy 105 points

    Ilmars said:
    Sure you can tell sensor data resolution (how many bits) and channel count.

    I need to send 6 ADC  (12 bit resolution) channel results over USB HID. With HID Datapipe, the report length would be 26 Bytes. So I think I will be sending information at a rate of 26KBps if I use the 1kHz data rate.

  • 0 in reply to Mihika Perera
    Guru 46710 points

    Mihika Perera said:
    I need to send 6 ADC  (12 bit resolution) channel results over USB HID.

    Yes, you can't send so much info using "oldskool" MIDI. So you need faster interface indeed, like Ethernet or USB :) Unfortunately HD-MIDI which could be perfect match is not yet ready: http://www.midi.org/aboutus/news/hd.php

  • 0 in reply to Mihika Perera
    Guru 34453 points

    Mihika Perera said:

    I need to send 6 ADC  (12 bit resolution) channel results over USB HID. With HID Datapipe, the report length would be 26 Bytes. So I think I will be sending information at a rate of 26KBps if I use the 1kHz data rate.

    Another option is to use some USB-UART bridges (UART on uC side, virtual COM port on PC side) with dedicated drivers (that taking care that all data are sent/received on time). For example PL2303HXD is able to work at 3.3V and up to 12 Mbps. MSP430G2xx or MSP430F5xx UART is able to work on max MCLK/4 clock, 16 MHz ~ 4 Mbps.
    Any special USB transfer (with critical timing) can be implemented on MSP430F5xx (without extra bridge) of course, but than both sides (uc code / PC drivers) must be done by yourself, and this is far away from simple.
  • 0 in reply to Mihika Perera
    Guru 227245 points

    Mihika Perera said:
    he report length would be 26 Bytes. So I think I will be sending information at a rate of 26KBps

    No, 260kBps.
    However, you can pack two 12 bit values into 4 bytes, reducing your package a bit. So for 6 ADC values, you only need 9 bytes instead of 12 (and why do you need 26 for a datagram?

    Sending with 115200Bd should be good enough if you do not waste bandwidth with superfluous data.

    Once again: I do not recommend any kind of USB when you need a low latency.

    Sending a truck with harddisks through the country gives you a throughput of several terabytes per second, but the latency is several hours. Same on USB: Teh throughput isn't the only limiting factor. If you want low latency, you need th edata sent as fast as possible. Which means sending a separate USB packet per datagram. No grouping. THis increases overhead etc. No, USB definitely isn't the bus of choice to get small amounts of data sent in time. (gamers still refuse USB mice or buy expensive ones with their own low-latency USB divers, even though a mouse datagram is only a few bytes and the required throughput is below few kB/s, which is next to nothing compared to 30MB/s maximum throughput supported by USB2.0)

  • 0 in reply to Jens-Michael Gross
    Guru 46710 points

    Jens-Michael Gross said:
    Sending with 115200Bd should be good enough if you do not waste bandwidth with superfluous data.

    The real problem here is that you need computer (still) having _hardware_ asynchronous serial rs232 port (16550 or similar) which is _not_ in form of USB adapter :) Well... and this is not enough - you need to know about RX FIFO settings which can greatly impact expected latency :) 11520 chars/sec divided by 14 chars FIFO irq mark = 822 IRQ/sec giving worse than 1ms latency :)

    I believe that most computers are capable of 1kHz USB packet rate so having right drivers you can have < 2ms latency. If this is not enough, then you can always use Ethernet.

  • 0 in reply to Jens-Michael Gross
    Prodigy 105 points

    Jens-Michael Gross said:
    No, 260kBps.
    However, you can pack two 12 bit values into 4 bytes, reducing your package a bit. So for 6 ADC values, you only need 9 bytes instead of 12 (and why do you need 26 for a datagram?

    Hi All,

    Thanks very much for your valuable advice. Currently I need to send 26 bytes, because the Texas Instruments HID monitor application can display only ASCII characters, so I need to send 4 bytes for each ADC value to see a readable value on the monitor application. But I agree with your points, and I will reduce my data packet and try to monitor using a different raw data monitoring application, or I will have to move on to a different protocol as  suggested.

    Jens, could you please verify if my data rate calculations are correct as I don't understand how 260KBps is derived? Say, I send 26 bytes ( including all the header packets) at a rate of 1000 times per second. So my data rate is 26 x 1000 bytes per second. If I convert it to KB, then 26000/1024 = 25.4 KBytes per second. Is this wrong?

    Thanks,

     

  • 0 in reply to Mihika Perera
    Guru 227245 points

    Mihika Perera said:
    26000/1024 = 25.4 KBytes per second.

    KBytes per second aren't kBps. KBps (or Baud, even though 'Baud' isn't exactly the same as Bps on multi-bit parallel transmission systems) is BITS per second.

    SInce a serial conenction takes 10 bits (including start and stop bit) per 1 byte...

  • 0 in reply to Ilmars
    Guru 227245 points

    Ilmars said:
    The real problem here is that you need computer (still) having _hardware_ asynchronous serial rs232 port (16550 or similar) which is _not_ in form of USB adapter :)

    Yes, that's the tricky part.
    On my development machine, I have two PCI cards with two serial and one parallel port each. because the mainboard didn't provide any.
    Buying the newest cheap hardware doesn't mean getting the best. :) (in my case, I was given the old server board, at least with a bigger CPU and more ram than my last development machine. Still much less of both  than my system at home, which has an older board with serial port)

  • 0 in reply to zrno soli
    Prodigy 125 points

    Hi zmo,

    i read, that you was working with MSP430F5xx/PC with CDC. I am actually to. I am very new to all system.

    i am testing the project example which send data over PC. My problem is: i am having this error:

    Error initializing emulator: COM4 is already in use. This happen when i connect the hyperterminal and try to run the application. I have also the error on the Hyperterminal side when the application is running and i try to connect the Hyperterminal.. Basically i can´t initiate a communikation betwenn USB and PC. Thanks for replying

    Claire

  • 0 in reply to yonkou claire
    Guru 34453 points

    yonkou claire said:

    Error initializing emulator: COM4 is already in use. This happen when i connect the hyperterminal and try to run the application. I have also the error on the Hyperterminal side when the application is running and i try to connect the Hyperterminal.. Basically i can´t initiate a communikation betwenn USB and PC. Thanks for replying

    You must close port (PC side), and open it again (PC side) after MSP430 restart / enumeration. You can't start terminal on PC side, open (for example) COM4 and leave it opened while restarting MSP430 CDC side.

    1. Close COM port on PC side (terminal)

    2. Run MSP430, and leave it to finish enumeration

    3 Open COM port on PC side (terminal)

  • 0 in reply to zrno soli
    Prodigy 125 points

    Hi zmo soli,

    thanks for your reply,

    may be i didn´t explain very good my problem.

    I'm trying to create a USB serial communication between my MSP-TS430PN80USB experimentor oard and the pc. Now, from the user experience demo, it seems simple, and actually it is.

    However, without changing anything, nothing seem to work these few days. My codes compiled correctly, no errors indicated, and it downloaded correctly into the flash memory. However, while running the programme, I was unable to use HyperTerminal or Putty on COM4 (that's where MSP-FET430UIF - VCP is).

    If I do the other way round, meaning that I start Hyperterminal or Putty on COM4 on 57600 bauds, and I compiled and tried to debug the project, an error message was displayed on CCSv4 "Error Initializing Emulator: MSP-FET430UIF is already in use".

    Thanks again for your help!

    Claire

  • 0 in reply to yonkou claire
    Guru 227245 points

    yonkou claire said:
    I was unable to use HyperTerminal or Putty on COM4 (that's where MSP-FET430UIF - VCP is).

    Well, that’s correct: you are unable to use this COM on HyperTerm because this COM port connects you to the FET, not to the MSP. And you don’t know what to say to the FET. Everyone is unable to use this COM port, except for the debugger. And the debugger can’t because HyperTerminal is blocking it.

    The FET430UIF COM port is only for debugger/FET communication. The FET430UIF does NOT provide a serial link to the target MSP (there are no RX/TX lines on the FET cable, nor is the JTAG connector connected to any UART pins of the target MSP.

  • 0 in reply to Jens-Michael Gross
    Prodigy 80 points

    We have a product that uses the CC3000 and we need to get the MAC address from each one in production.  We were hoping to use the FET430UIF to read a specific memory location for that address after the target microcontroller had downloaded it from the CC3000 (without having the production guys run IAR or other debug tool).  From what you are saying we will not be able to do that. 

    So, although the MSP430UIF uses JTAG (or SBW), we cannot use the JTAG commands to read a specific memory location directly, using RealTerm or similar terminal emulator connected to our target via the MSP430UIF.  Is this correct?  Sorry if this seems rather pedantic, but I need to know if this approach is worth pursuing at all.

    Thank you for your help...

    Steve

  • 0 in reply to Steve Brass
    Prodigy 80 points

    My apologies, I should have asked this in a new thread...  I will do so

**Attention** This is a public forum