another weird USB thing

Our little USB interfaced thing is doing something else that I don't understand.

We use an LPC1768 to manage DACS and stuff. It has a USB interface, which we program such that it enumerates as a serial port. Sometimes, when we talk from a PC to the box, we get extra junk characters in the ascii data coming back from our box. This happens with Windows and Linux, using standard terminal programs or our own test programs.

There is a baud rate parameter in the ARM usb driver, and we set that to 115K baud and compiled the app. Turns out that the software running on the PC has to have its baud rate set high, 38K or more, or we get the garbles. A serial port opened at, say, 9600 has the junk characters.

What's weird is that, to me, the baud rate shouldn't matter. There is no actual serial data anywhere in the system.

I wonder if the OS attempts to throttle data into applications or something, based on the fake declared baud rate. But why *extra* junk characters?

--

John Larkin         Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro   acquisition and simulation
Reply to
John Larkin
Loading thread data ...

There are Universal SERIAL Bus data, regardless of baud rate. The CDC data stream is not error proof. We usually build framed data with CRC or checksum on top of USB-CDC. Bare VCOM CDC is not good enough.

Reply to
me

I have ideas, but I'm sure you have at least as many, so I'll just ask a tangential question.

I never heard of that uC family before, so I'm thinking about the old days when we learned about such things in trade magazines or in junkmail. Now that those magazines have gone downhill and lots of people dropped them, where does one get news of new stuff?

--

Reply in group, but if emailing add one more
zero, and remove the last word.
Reply to
Tom Del Rosso

a

Right here. NXP's LPC family is not new. We have discussed this many times here. FYI, it's ARM Cortez M3 with OTG USB.

Reply to
me

I cruise the big semiconductor web sites regularly, to see what's new. But for something like a uP, you have to google for suppliers, or call a distributor, or ask guys that you know. SED or CAE are good places to ask about stuff like this.

Agree, the electronics mags are getting really bad.

--

John Larkin         Highland Technology, Inc

jlarkin at highlandtechnology dot com
http://www.highlandtechnology.com

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom laser drivers and controllers
Photonics and fiberoptic TTL data links
VME thermocouple, LVDT, synchro   acquisition and simulation
Reply to
John Larkin

Sounds to me like your LPC1768 code might be using the wrong byte count for the IN pipe packet. If you can, fill the buffer with some pattern before you start loading data from the DACS. You can look for the pattern at the end of the data string on the host and maybe get a clue as to what is going wrong.

--
Chisolm
Republic of Texas
Reply to
Joe Chisolm

There is no

I have seen similar problems with missing bytes, extra bytes and/or changed bytes. I could be wrong, but the USB bulk end pipes does not seems to be checking for errors.

Reply to
me

What USB format are you using ?? Are you using the CDC virtual COM port ?? pointing device ? Audio device ?? We use CDC with the LPC2366 and it doesn't care on the PC side what the baud rate is set to.

boB

Reply to
boB

(...)

formatting link

--Winston

Reply to
Winston

For me it is still Circuit Cellar and EETimes. EET has lots of little newsletters that waste my time, but does give out new product announcements that I occasionally find interesting...

Charlie

Reply to
Charlie E.

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.