USB CDC Timeout Control

Go To Last Post
4 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using Atmel Studio 7 to write code for the atxMega64B1.  The USB port is configured as a CDC with stdio and is generally behaving, but I have one problem I can't sort out.

The USB port will be used primarily for manufacturing calibration and test, so it won't always be connected to a host.  It will be plugged into a charger most of the time.

I want to stream measurement data out the USB port as the device operates using .  This works fine as long as it is connected to a host and a terminal program (I use teraterm) is running.

If there is no data sink like teraterm, eventually the transmit buffer on the xmega fills up.  At this point my software hangs, waiting for more room in the buffer.  This is bad.

 

I see two options: 

1) Detect that there is or is not a data sink of some kind and then choose whether to send data.

2) set the USB port so that it does not hang if the buffer is full.

 

I've not been able to find any clues about how to do either of those.  I've searched both this forum and the Atmel ASF docs, such as they are.

 

Any ideas or pointers?

 

Many thanks,

 

Keith Payea, Bryant Labs

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There should be values in the USB registers that would indicate if it is attached to the host.  For instance I think the device address should be zero if plugged into a charger, and non-zero if attached to a host.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, I can tell if the device is connected to a host.  The problem is that if there's no application running on the host that is pulling characters through the CDC protocol then the transmit buffer on the device end fills up.  I'm outputting fairly complex strings with floats in them via printf.  If the ASF/USB/CDC stdio driver encounters a full transmit buffer it just stops and waits stupidly.  I could use sprintf and then send characters one at a time, checking for TX buffer full before each write, but I was hoping that there was a way to either detect that nothing is drawing characters out or tell the driver to not wait and bail out with an error code.

 

I guess I can estimate the length of each string and then check before each printf to make sure there's at least that many spaces left in the buffer.  That just seems really "brittle" to me.

 

Another idea is to write one string wait a little and then check to see if the TX buffer is emptying at all.  Again, that seems like a problem if the host gets busy temporarily.

 

Thanks,

Keith Payea, Bryant Labs

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know your driver.  There should be a way to tell if the driver can accept more data.  

 

The busnack0 bit will be clear in the status register for the bulk in endpoint if you are trying to send and the host ain't taking it.

 

By the way,  I never use printf, sprint, or any thing like it in the AVR.   I send a class/struct with binary data to the host, and let the host figure it out.

 

EDIT  I see you mention floats.  I don't use them.  I don't know if they are portable from AVR to host.

Last Edited: Mon. Nov 12, 2018 - 06:07 PM