On Wed, 11 Jul 2012 17:17:55 -0700, John Larkin
<jlarkin@highlandtechnology.com> wrote:
>On Wed, 11 Jul 2012 19:53:57 -0400, "Tom Del Rosso"
><td_03@verizon.net.invalid> wrote:
>
>>
>>John Larkin wrote:
>>>
>>> We use an LPC1768 to manage DACS and stuff. It has a USB interface,
>>
>>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?
>
>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.
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 by Winston●July 12, 20122012-07-12
On Wed, 11 Jul 2012 19:53:57 -0400, Tom Del Rosso wrote:
(...)
> Now that those magazines have gone downhill and lots of
> people dropped them, where does one get news of new stuff?
On Wed, 11 Jul 2012 23:23:12 -0500, Joe Chisolm
<jchisolm6@earthlink.net> wrote:
>On Wed, 11 Jul 2012 15:49:37 -0700, John Larkin wrote:
>
>> 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?
>
>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.
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 by ●July 12, 20122012-07-12
On Wednesday, July 11, 2012 9:23:12 PM UTC-7, Joe Chisolm wrote:
> On Wed, 11 Jul 2012 15:49:37 -0700, John Larkin wrote:
>
> > 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?
>
> 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.
>
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 by Joe Chisolm●July 12, 20122012-07-12
On Wed, 11 Jul 2012 15:49:37 -0700, John Larkin wrote:
> 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?
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 by John Larkin●July 11, 20122012-07-11
On Wed, 11 Jul 2012 19:53:57 -0400, "Tom Del Rosso"
<td_03@verizon.net.invalid> wrote:
>
>John Larkin wrote:
>>
>> We use an LPC1768 to manage DACS and stuff. It has a USB interface,
>
>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?
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 by ●July 11, 20122012-07-11
On Wednesday, July 11, 2012 4:53:57 PM UTC-7, Tom Del Rosso wrote:
> John Larkin wrote:
> >
> > We use an LPC1768 to manage DACS and stuff. It has a USB interface,
>
> 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?
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 by Tom Del Rosso●July 11, 20122012-07-11
John Larkin wrote:
>
> We use an LPC1768 to manage DACS and stuff. It has a USB interface,
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 by ●July 11, 20122012-07-11
On Wednesday, July 11, 2012 3:49:37 PM UTC-7, John Larkin wrote:
> 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.
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 by John Larkin●July 11, 20122012-07-11
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