seeking USB Tutorial for C series

As an example of my confusion:
The Tiva ware USB Library users guide includes this statement with the explanation of USBDCDCInit() function regarding the return value.
"The value returned by this function is the psCDCDevice pointer passed to it if successful. This
pointer must be passed to all later calls to the CDC class driver to identify the device instance."

However, in the usb_dev_serial.c file (in that Tiva example project), the return value is not saved.

George

Hi George, USB is not a simple thing and is also not a real standard so to do something useful you need a tons of information too.
TIVA Library is not more different from other nor PC side, you need some reference, try a book or online information if this help example:
www.amazon.com/.../1931448086

this is an online tutorial simple to follow:
www.beyondlogic.org/.../usb1.shtml

or if this is not what are you seeking try google yourself to adapt material to your level or ask again what you exactly need.

Hello Roberto,
I've studied USB on-and-off since about 10 years ago. I read the USB and HID specification (yawn!). I've read Jan's book and John Hyde's book (the first additions) and have e-mailed with both of them back then. I've consulted with a few companies to help them design USB on their products. So I'm not a newcomer.
My confusion is using Tiva's APIs for USB and other things. I've had this problem with other Tiva APIs. The API books are references. I've tried to follow the API books, the example projects and videos as best I can, but still have questions (like my last post). What I think I need is a book that teaches, in depth, how to use them, like Jan and John do. Why don't chip manufactures do that?
Thanks George

george dorian said:

Why don't chip manufactures do that?

Having (past) worked for large, chip-vendor - I can report that there exist, (other means) - to skin that, "in-depth knowledge cat!"

Should your firm rise to 100K, MCU, EAU class - normally a skilled FAE will be assigned - will guide your efforts.  This is deliberate - you'll often "bond" - and be hard-pressed to "migrate" away from such a helpful vendor.

Creating a book - and confining key guidance to just, "that vendor's" product - proves problematic.  You don't want to aid/abet the enemy (competing chip firms) - after all.   And - spend any time here - you'll see that (too many) invest far too little time/effort - in reading the MCU manual & related examples, forum notes etc.  Do you expect this "class" of user to invest 25, 35, 50 (USD) for a book?  (Ans: not in our life-time)

Jan's book was good - but has not the level of detail risen since its publishing?  Devil in the details - and Jan's book may require serious "updates" to become more effective today...

Thanks cb1,
That explains a lot! I should have know there was some marketing/politics to it.
This forum is a great thing and I am grateful to all who have helped me. I hope to return the favor once I get confidently up to speed. But for now I'm stuck on a number of points, namely the problem I mentioned in my second post. I'd be grateful for help on that.
George

You may consider (strong) doses of KISS - one unknown at a time - if possible.   Many, systematic, small battles often provide the best means to guide you to solution/victory!

You note pointer issues - yet your field of investigation appears limited - does it not?  Broadening your investigation - while not as direct/efficient as you'd like - may be the best (and only) means to "tease out" the exact issues which now plague.  (i.e. even though not (strictly) w/in your chosen USB class/category/mode - code examples may overlap your requirement - or better illustrate it's solution.)

Blasphemy for here - but no one vendor has a "lock" on best/brightest tech. explanations.  Our small tech firm uses ARM MCUs from (now) 5 vendors.  Each implement their peripherals a bit differently - yet similarities are apparent - and if you cannot get your answer here - widening your search seems to make sense.

As Roberto (so often) mentions - USB proves not, "walk in the park."   Many (hundreds) have struggled w/USB (this vendor & elsewhere - to be fair)   Yet - this forum (best imho) and others provide a repository of useful data - while providing the alternate function of, "sleep aid."

Never mentioned - but might you "escape" the details of USB by employing MCU's UART (far easier to master) and new FTDI (USB to UART) chip?  (it's smaller, better and cheaper than earlier versions - even may reside "embedded" w/in the USB cable!!)

Too many here "swing for the fences" when simple, "Single or Double" would do nicely.   (i.e. switch to UART & FTDI)  Later - if volume makes time/effort of MCU's USB mastery worthwhile (and that's a very big IF)  - experts can be harnessed to, "guide your path."  

Knowledge gaps - as you're encountering - have a tendency to, "sort themselves out."   (if the volume is there - a solution will be found.  More modest products/projects - usually do best w/less exotic/demanding methods - already resident - w/in your "toolkit!")  

Hi George, I am aware of all device application and I try stay away due to complexity USB has inside... I am using succesfully both HID and Mass storage Host services got as is, I hope they work and never I need do nothing in a so complex code. Best supporter can help you can be the greatest USB expert Tsuneo.
Example not saving device instance is probably a mistake library has and not discovered till now.
@AMIT is this a known issue?

Hi CB1, about KISS test, I am not able to find scientific information, Shannon guided me here:
www.goodreads.com/.../9311952-the-kiss-test
Is this referring as your KISS test or some Specialized Jargon file exists?

Hi Roberto,

KISS -> "Keep It Simple Smarty!" (some employ a less gentle word for that final "S")

Very small, tightly defined goal - usually operating upon only a single, "unknown."

KISS makes up the fundamental "building blocks" of, "Proceed by Refinement."

The opposite of KISS is, "Kitchen Sink" - Attempt complex task in ONE GO!   Multiple unknowns, new hardware, new software, new cables - failure almost guaranteed!

A good illustration of "Anti-KISS" would be "bundling a PWM Generator with a Wide-Timer - and having both operate under interrupts."   Failure of a single interrupt may hold the entire project, "hostage!"  KISS - in contrast - would bring up one MCU peripheral at a time - minimizing/avoiding the use of interrupts - allowing user's full attention to be very tightly focused.

Many "examples" - this forum and others - employ multiple MCU peripherals operating together - which adds grave complications to the project's "real" understanding & operation...KISS limits the size of the battlefield - enables far tighter control & focus - and (we find) most always proves, "best/brightest!"

KISS extends far beyond tech world - good lawyers (never) ask a question - the answer to which is unknown.   This logic is long proven to best prevent "dead-ends and/or blind-paths" which muddies findings & distracts the jury.  (or the forum reader - struggling with a too brief, too vague MCU detail.)   We sell to the medical field - during surgery - patient is "draped" - so that only the area of operation is exposed.   Great illustration of KISS - there are many!  

KISS is everywhere (but for here) and that's a rather significant, "failure of forum mgmt."   Far more illustrative, better detailed, App Notes & code examples - supporting KISS - would greatly improve user understanding - and head off problems (introduced) by "rushed App Notes" & anti-KISS (too much, too soon) code examples & descriptions...

People, I think we are loosing focus.
At this point I have several questions. The first is the one I wrote in my second post. Does anyone have an answer?
Thanks George

george dorian said:

I think we are loosing focus.

I think not!

Suggestion was made to shift to FTDI chip in conjunction w/MCU's UART.  That's great focus - and a superior path - proven as predecessor vendor here did just that - to entice current vendor to "buy the farm."

Doubtful that you need to "squeeze pennies" (your volume cannot be that high) and FTDI solution is so powerful, so effective - used by THOUSANDS!

That type "focused thinking" enabled this reporter to co-found - take past tech firm public.  A better way (for you) exists - you've provided not one justifying fact to support your quest for MCU-only USB...  FTDI chips rule...

george dorian said:

This forum is a great thing and I am grateful to all who have helped me. I hope to return the favor once I get confidently up to speed. But for now I'm stuck on a number of points, namely the problem I mentioned in my second post. I'd be grateful for help on that.

 Hi George, Thank a lot for your kindness, I hope you can help after you lose apply some long time as was for me to have ENET working, so reading a lot of document, experimentation on silicon and comparing to Dataa sheet too...

CB1, Thank a lot for explain of KISS principle, I hear in a different form but it is forever the way. I agree many example are not simple, I remember the web server example interrupt driven....

 George after that I fear the only person can help you point examples and error can be our Amit that know in deep chip and examples too...

 @Amit are you reading here?^ Is a known issue or is a correct usage missing save the device instance pointer  on serial example?

Hi George,
I'm sorry but I can not help. However my answer is the most advisable person to help you be the AMIT. In this forum there are 2 supermen, or bright minds who think they are the biggest. They think they are the only ones with knowledge taken in chains for 50 years. Anyway ...
I hope you get some help,,,


Regards
Aquino

Be ever so careful you don't, "break focus!"

Hi CB1, no problem at all laser focus was perfect and again coherent to SPAM or ABUSE...
Blake TI Community , @Hamit please stop this one too, and please see if problem we are on has some solution too.
When someone ask to solve problem and scream about found himself lot wetty and smelling .. is not our trouble! I am so sorry this person in his arrogance included George too. So please all fire "ABUSE" and as other similar disappear till next...

 Not useful but just to fix what wrote to  possibly get at court.

Aquino said:

Hi George,
I'm sorry but I can not help. However my answer is the most advisable person to help you be the AMIT. In this forum there are 2 supermen, or bright minds who think they are the biggest. They think they are the only ones with knowledge taken in chains for 50 years. Anyway ...
I hope you get some help,,,


Regards
Aquino

Hi George,

george dorian:

As an example of my confusion:
The Tiva ware USB Library users guide includes this statement with the explanation of USBDCDCInit() function regarding the return value.
"The value returned by this function is the psCDCDevice pointer passed to it if successful. This
pointer must be passed to all later calls to the CDC class driver to identify the device instance."

However, in the usb_dev_serial.c file (in that Tiva example project), the return value is not saved.

But for now I'm stuck on a number of points, namely the problem I mentioned in my second post. I'd be grateful for help on that.

It's because the programmer of usb_dev_serial knows that USBDCDCInit() just returns the argument passed to it, at TivaWare_C_Series-2.1.0.12573. And then, (s)he applied the argument directly instead of the return value.

In usb_dev_serial.c, USBDCDCInit() is used in this way,

int
main(void)
{
    ...
    USBDCDCInit(0, &g_sCDCDevice);


In the stack code,

\TivaWare_C_Series-2.1.0.12573\usblib\device\usbdcdc.c

void *
USBDCDCInit(uint32_t ui32Index, tUSBDCDCDevice *psCDCDevice)
{
    ...
    pvRet = USBDCDCCompositeInit(ui32Index, psCDCDevice, 0);
    ...
    return(pvRet);
}

void *
USBDCDCCompositeInit(uint32_t ui32Index, tUSBDCDCDevice *psCDCDevice,
                     tCompositeEntry *psCompEntry)
{
    ...
    return((void *)psCDCDevice);
}

After all, USBDCDCInit() returns &g_sCDCDevice.
And then, g_sCDCDevice is (indirectly) passed to USBDCDC-APIs, like USBDCDCSerialStateChange()

This type of question deeply depends on the implementation of the stack. Stack source code is your friend ;-)

Tsuneo

@Tsuneo,

Thanks for this - you are (quite clearly) best/brightest @ all things USB.  (no offense to Amit - but our small tech firm classes Tsuneo's (many posts - here/elsewhere) as required reading.)

That said - has poster not placed himself similarly to a man,  "Pushing a boulder - up a mountain - using only his nose?" 

As you know - complicating matters further - there are subtle variations in the handling of USB peripherals - by the many different, ARM vendors.  Some way/how you have the great skill, time & commitment to keep (most) of this straight - not so for the (great majority) of we mortals...   (surely to include moi)

I've suggested that newest/smallest FTDI USB chip may provide a far faster, easier and far more effective means for poster to "attach" his MCU to a PC's USB Port.  Might you comment?   It's doubtful that poster's volume will justify the significant time/effort/expense required for him to reach even a small fraction of your mastery.

I've been fortunate to enjoy some great tech success - and most always "KISS" has served as, "best friend."   Starting with the most complex - quite predictably -is not the "best/brightest" path to success!

Hello Tsuneo,

Thanks very much for taking the time to reply to my question!

I was diving into this yesterday evening and started coming to the same conclusion, but felt that I was partly guessing.  Thanks for confirming it!  I've see functions do this before, return there own parameter or NULL if the function failed, so am not to surprised.  At first I was thinking that USBDCDCInt() returned a handle needed by down stream USB functions, but now you've confirmed that I need to pass *psCDCDevice.

Thanks again, George

cb1:

I've suggested that newest/smallest FTDI USB chip may provide a far faster, easier and far more effective means for poster to "attach" his MCU to a PC's USB Port.

For personal projects, it's still fine suggestion.
But on the production scene, since MS has introduced restriction of driver package signing on Windows 8 [**1], we have to count in the extra cost of the signing and its maintainace (100-200 USD/yr). This extra cost brings "WinUSB Device" [**2] more attractive than CDC devices / FTDI USB-UART.

CDC devices / FTDI USB-UART require driver (INF) installation on Windows. TI and FTDI supply certified  driver for their VID/PID. When we would modify the VID/PID (at least PID) to make our products unique, the certificates should be broken. We have to buy new certificates for our VID/PID.

"WinUSB Device" doesn't require any driver package on Windows 8/8.1. Also, any driver certificate. Since Windows XP, WinUSB Device is supported [**3].

I believe the preference on new production should move to "WinUSB Device" quickly, when the development environment would be established.
- Firmware example for WinUSB Device
- PC Test console for WinUSB Device, like terminal software (TeraTerm, etc)
- Wrapper PC librafy for WinUSB

I suppose FTDI would also have a plan to release "WinUSB Device" chips.

[**1} Windows Driver Signing Tutorial
https://msdn.microsoft.com/en-us/library/windows/hardware/dn741537%28v=vs.85%29.aspx
Beginning in Windows 8 and later versions of Windows, installation will not proceed unless these driver packages are also signed.

[**2] WinUSB Device
msdn.microsoft.com/.../hh450799%28v=vs.85%29.aspx

[**3] MS-official "WinUSB class" driver for XP, Vista and 7
www.microchip.com/.../m790429.aspx

Tsuneo

Hello George,

I did look into the function and it seems that the application the way it was written, assumed that if the device fails, it will never connect with the right function call back. Hence the NULL was never used.

Regards
Amit

Tsuneo Chinzei said:

For personal projects, it's still fine suggestion. 

Above quote - by the "USB Master" - further documents the "focus" always intended by this reporter.  (i.e. alternative means to achieve USB connection)

Tsuneo - what to say other than (yet another) great post from the (many tech) forums' USB master!   Thank you.

While my small, tech firm is in the "biz" - USB is so complex - so demanding - and as your extraordinary post (now) illustrates - USB proves very much a, "Moving Target!"

Poster sought a detailed, "tutorial."   (that's unlikely to arrive - anytime soon!)  And - now some 20 back-forth posts in (here) he's made (at best) minimal progress.  (herd of turtles - if I'm not mistaken - "galloped" right by him - on the right...believe their "plate" read, "FTDI rules - NO tutorial required...")

The hundreds of caring, in-depth posts Tsuneo's authored have helped many - across multiple ARM MCU forums.  Without Tsuneo's help - it's extremely doubtful that many "would be" USB "intermediates" would have found success. 

FTDI has multiple, skilled, up to date, effective staff - many "focused" (to the delight of o.p.) on all matters - USB.  And they've very recently introduced a smaller, lower cost, and more user-friendly USB->UART converter IC - which effectively manages ALL of USB's arcane requirements.

Almost always - frustrated posters (as o.p. registers here) give no justification "whatsoever" for WHY they've "locked themselves" into an "imperfect" use decision.  And then they seek detailed, on-going (never-ending) help - as well.   And freely reject - w/out any proper consideration - a superior solution.  (presented upon "silver platter" - sometimes "special delivered" by this reporter...)

The cost adder - inflicted upon USB use by MS - appears to impact FTDI & this vendor's MCUs too - does it not?  (so that's a wash)   And - surely FTDI - with far more focused/impactful USB success/efforts than this vendor (apparently - for years USB was FTDI's dominate biz) should "win the race" to, "WinUSB Device's" successful introduction.

Compliance w/ "KISS" - and WinUSB Device status - surely dictates that (all here) turn their "focus" to FTDI - and employ MCU only if volumes are extreme enough to justify the significant, "blood, sweat & tears..." which (normally) result when Tsuneo is unable to grace us w/his (very skilled) kindness/presence.

For the record - this reporter has only "client-user" relationship w/mentioned firm - and is unrewarded for stressing the ease, speed & success resulting from that firm's device...

Hi CB1, just to see if application is simple or hard to use.
I loaded to CCS project, as usual example I have to confirm George feeling of a complex thing...
Uart echo is embedded on function where scope is imprecise and use this example get into a great pain.
Compiled and loaded to a LP on Linux MINT 17.1 64bit just to see what happen, connected two USB cables two ttyACMx device appeared.
Launching two instance of terminal connected to both port and is possible to transmit character from usb to serial and viceversa...
All is ok but IMHO a better approach to have UART and USBCDC separated to use as is instead of digging code to try understand how to use virtual device???
TIVAWARE has many point to address in a more usual manner.
Ok I can identify where uart buffer is sent to USB, write new function USBsend USBreceive... USB_USREventServe , better was have these at hand ready to use, this can only be good if someone require a ready to use expensive USB to serial...

TIRTOS is more api oriented and examples are good to use as they are, to insert on one or more task. API seems close to BSD and well commented. Good KISS model as CB1 style.
TIRTOS instead on serial client ( I am not using) has a good example, not complex two simple task:

one transmitting a forever timed a welcome message
and
one receiving -> just transmitting status as "received n char abc" to system console.

Then some TIVA examples well structured and simple as change some HTML code get here bad and offensive children.

Hi George,

I'm afraid my answer is already irrelevant as you've had enough time to sort this out.

But by reading this chain one can develop a suspicion that something is fundamentally wrong in the CDC-related example project you'd mentioned. I think this may not be the case so let's focus exactly on the matter.

You're correct, the code in usb_dev_serial.c does not save the result of USBDCDCInit() invocation. Because actually it's not necessary.

Read this again: "The value returned by this function is the psCDCDevice pointer passed to it if successful. ...". As the psCDCDevice pointer is the first input parameter of this function, it returns exactly the same value for success. No need to save it. The code does not check the returned value, perhaps with the intention to keep it simple.

After all, this is just an example project and its primary purpose is to communicate an idea about the business logic. Implementing all the things, which are mandatory in the production code (error handling, etc.) could make it less clear. For me, the example is just fine.

P.S. I've a mixed feeling on the new appearance of this forum...
---
regards,
Igor

In reply to cb1's remark about:

"Many "examples" - this forum and others - employ multiple MCU peripherals operating together - which adds grave complications to the project's "real" understanding & operation"

Yes, I agree.  The CDC USB example uses a CDC to UART bridge.  I do not consider this to be a good first example to show the newcomer to Tiva (like me) how to use the CDC class driver.  I've pored over that code for days and I can't figure out where CDC ends and the UART starts.  I would have made a CDC example that just echoes back characters (received) to the host. 

IT - are you listening?

George

Hello Tsuneo,
Just want to say thanks very much for your Jan 24 post. There's a lot of good leads on your post that I'll follow up on.
regards George

Hello Igor,
thanks for taking the time to reply. I think your post is very succinct. Seems to sum up this thread.
But what I still don't understand is how will my program know if USBDCDCInt() failed? Will it not pass psCDCDevice? Will it pass NULL instead? Or something else.
George

Igor Uspensky1 said:

I'm afraid my answer is already irrelevant as you've had enough time to sort this out.  

Alas Igor - if only that proved true.   But - (sigh) - appears it has not - George stands impacted (does he not?) - little's been, "sorted out."

When boulders block a known/safe path - what to do?  Under-equipped - we can struggle to (maybe) move the first, few boulders - but might others descend to replace?   What then?

Or - as past (repeatedly) suggested - might we (move) from the blocked path - to another - especially if that path is far more popular, illuminated and success laden?

Dead-ends are (rarely) well marked - require some sensitivity to detect and "steer around..."

 Hi CB1, about FTDI I was thinking about how much it can cost, low speed serial device has many time done just by Bit Banding so is more expensive one FTDI USB to serial or a crazy solution like this:

http://43oh.com/2013/01/msp430-usb-bit-banging-taking-it-to-the-next-level/

 It work very fine and it if fitted in small one still is smart enough to do some processing on received/transmitted data. I was thinking about this as Bootloader also if MSP has its one and work fine.

About example on first lines a disclaimer like

<<< This example is just a demonstration, refer to well documented CDC class for development. >>>

 can save a lot of trouble to who decide develop code on TIVA USB non RTOS based.

Hi Roberto,

Poster here - as many now confirm - does not stand alone in his frustration in achieving reliable USB communication.   Yet he (appears) to reject other paths - and never has justified his (seeming) "penchant for punishment."  

Recently one of our client's "raved' about his success w/new, priced-down, user-friendly (i.e. 8 pin soic) FTDI USB - > UART IC.   If not mistaken - USB was (and remains) the main area of focus by this firm.   (clearly not the case, here)

Beauty - and thus major appeal of this IC - is it's well-proven, efficient USB engine.  Masks the "heavy lifting" from the user - exactly what (appears) to be missing here!   Using such an IC eliminates any requirement for a, "tutorial!"   (although IC's data is very well described/detailed...)

Myself, my small tech firm - are nowhere near "smart/equipped enough" to qualify as "researchers."   Yet - we (often) design/sell our focused applications to these "ivory towers" usually because we can quickly/efficiently "tease out" a reasonable tech solution.   We choose to "steer around" rather than "ram ahead" when boulder blocks.   (I passed that advice to poster - to (ongoing) silence - and NO SIGN whatsoever of heralded tutorial!)   (although rumor has it - "on the heels - just after PF0/PD7 rewritten/corrected or band-aid highlighted...)  

Suggest that you check latest/greatest from "USB-focused" firm - I'd stick w/that - even over "crazy ones."   Dead-ends - as illustrated here - eat time, money, funds, morale - appeal little - best to avoid...

cb1_mobile said:

Suggest that you check latest/greatest from "USB-focused" firm - I'd stick w/that - even over "crazy ones."

 Hi CB1, thank for advice, I am not so USB centric and I just use as support for moving data between machines and PC too, also network is present in my application  so no trouble to use NFS or FTP but forever not many have network cabling on old plant.

 So I see Pen Drive and external USB-Floppy as substitute of old technology I still have to support. My USB knowledge was on HOST, here I learned a lot about device in stand alone mode.

 Again both free/TI RTOS support USB  host or Device in a more clean fashion and also example are neat.

 About USB new 3.0 and add on I have to say why not return to old good firewire, a solid standard, isolation on data and doesn't require have dedicated software nor fee to a de facto industry just based on money. I don't like 3.0 and I fell as a worst fake of old good firewire. Forever winner is not the best is the one imposing by monopoly...

Roberto Romano said:

why not return to old good firewire, a solid standard, isolation on data and doesn't require have dedicated software nor fee

Agreed - but beyond our control - mais oui?

That "TI RTOS" does in our use of vendor's USB device - we must choose from many ARM makers - single source is not allowed.  (by smart, key clients)

The volatility w/in USB especially justifies our choice of USB-focused chip vendor.   When do you "imagine" an adequate USB 3.0 "tutorial" will arrive (here)?

Hello George,

Still under the impression from excellent skiing in the winter forests on the weekend.

Regarding your initial questions about "big picture", etc. I've looked into the usb_dev_serial project example one more time and it seems the TivaWare USB library user's guide provides enough coverage. There are two related chapters in the document: 2.8 (CDC Device Class Driver Definitions), and 5.5 (USB Buffer and Ring Buffer APIs). Anyway this example is not more confusing that the other ones. Perhaps the following will help you to get the overall idea for how it works.

Flowchart for transfer one data character from UART to host:

1. The UART receives a character and generates interrupt;
2. USBUARTIntHandler invokes ReadUARTData;
3. ReadUARTData gets the char from UART using ROM_UARTCharGetNonBlocking and passes it to the USB Buffer object with USBBufferWrite;
4. The USB Buffer object, in turn, eventually passes it to the USB library with USBDCDCPacketWrite;
5. The USB library loads the char to the bulk IN EP of the usb controller;
6. The USB controller sends the packet to the host over the bulk pipe with nearest IN token occasion;
7. The host receives and acknowledges the packet;
8. The USB controller receives the acknowledge so the USB library invokes TxHandler callback in the app (that does nothing in that example). That's it.

Flowchart for transfer one data character from host to UART:

1. The host sends a packet to the device over the OUT bulk USB pipe;
2. The USB controller receives the packet so the USB library notifies the USB Buffer object invoking USBBufferEventCallback;
3. The USB Buffer object retrieves the packet from the USB library using USBDCDCPacketRead;
4. The USB Buffer object eventually passes the char to the application invoking RxHandler callback;
5. RxHandler passes the char down to USBUARTPrimeTransmit;
6. USBUARTPrimeTransmit writes the char to UART with ROM_UARTCharPutNonBlocking;
7. UART transmits the char to outside and generates interrupt on completion;
8. USBUARTIntHandler disables further Tx interrupt as there are no more data to send.

I'm hoping this contribution gives me some right to express my personal opinion.

USB usually implies communication with a computer. But UART is long time dead there. As such by now few reasons to stick with it (e.g. a retrofit applications or debug interfaces) demonstrating obsolete thinking. For a new applications, the HID class provides much better alternative. HID is supported by all popular OSes so no additional driver is required at the host side.

---

regards,

    Igor

 

 Hi Igor, well done, but this need not come from your analysis it have to be on every example with more care the ones are complex and tricky...

 If you search this forum "hacking exam" where I tryid a similar decoding of one example I am sure it scare all beginner evaluating to migrate on TIVA. I am no more beginner but first year was so painful on a so difficult to grasp... It refer to LCD example, to have an idea on how it work uncommented you need know in deep processor, search it and enjoy ;)

Again examples using some intermixed register access, and at last network example embedding web server on interrupt service where I think it can be impossible to use, how can I use API if they are not cleanly used?

 Examples need be cleaned a lot.

 USB expert Tsuneo wrote a very good report, the only wish I express about USB is to see M$ fail starving than collect money from all non standard and so I hate WINUSB and forever all is non well documented standard imposed just to steal time and money from others. I hate have a "Win" symbol on keyboard too and have to pay for using it? I buy keyboard then I don't have right to use?? Remove that unwanted symbol, IMHO reject WINUSB.

 When on old times of USB win95 was messing up users, [IBM] OS/2 and BSD supported quite seamless USB, we have to suffer again new pain just to pay M$?

 @CB1, USB 3.0 resemble old good firewire but has no isolation on high speed pair and just add another ground pin, 5 more pin.. So 9 pin to have what was better done with old good standard?

 again old firewire 4 pin was ground free, this was a must on Audio/Video devices and instrumentation too, 6 pin version added power to avoid sparse supply populating desk.

 On device there was a descriptor specifying how to use device, attaching a device after recognition was clear which command to use(Capability list). Ex a Video player has no record but all other STANDARD command work, so feature instead of driver, one program serve all class devices no specific driver at all.

 I still have somewhere all paper of Firewire I loved but just Apple world appreciated.

Igor Uspensky1 said:

For a new applications, the HID class provides much better alternative. HID is supported by all popular OSes so no additional driver is required at the host side.

I too wish to commend and thank poster Igor.

Yet - this vendor is not w/out resources - clearly they must have "known" the power/appeal of "HID."    Why then - was this CDC class so promoted?  

And what - if anything - is available to enable users to exploit and properly benefit from HID?

Igor - you've done a thorough job in listing a CDC progression.   Posters here wonder if a similar "HID" version (as you prefer) might be w/in you?

And - might some limitations exist w/in vendor's MCU which "steered" them toward CDC?

Hi Roberto,

I think everyone here are in your camp. The examples (I presume all that stuff was created early by the LM's guys) definitely needs to be improved with more comments and design documentation. What is currently available is not a ready-to-ship product, it's just a first internal draft. No doubt about that.

But does it mean we should stop sharing our findings and analyses as doing so stimulates to offload support work to the crowd (community)?

As for MS, ten years ago, when VoIP was in fashion, we've carried out several USB dongle designs (some sort of audio cards) for use with Windows. A lots of problems were encountered in the process but eventually it became clear that all the problems are caused by our misunderstanding rather than by Windows.

The latest designs facilitated automated software installation. When plugged for the first time, the device appears as a hard drive from which the system automatically starts the installer. When the installation is done, the application issues a vendor-specific SCSI command to that hard drive. Reception of this command causes the device to reset and to expose different USB descriptor set to the host. So this time the dongle is perceived as audio device and becomes visible for the application. It was interesting to watch the driver binding process in dynamic. Most of the drivers were standard (Audio, HID and Mass Storage), the only custom driver was for DFU.

The designs were extensively tested and all worked just fine. I'm still not aware about substantial USB-related problems in XP and later Windows versions.

The WINUSB is a new facility and currently might not be perfect. But it's not the only way to interface with a vendor-specific USB devices. It's still possible to implement a traditional WDM driver (and yes, to sign it with MS for $$$ :)

Your "hacking exam" is a solid work. And thanks for the good housekeeping advise to remove R9 and R10 from the 123 Launchpad design.

---
regards,
Igor

Hello cb1,

And - might some limitations exist w/in vendor's MCU which "steered" them toward CDC?

That's right, who knows what the application area is. HID is not designed for high data throughput. Usually, HID input reports are transferred over the Interrupt type USB pipe. This is a tightly scheduled delivery with known latency time and because of this the INT bandwidth is considered a scarce resource resulting in throughput limitation (I don't remember the exact number but the classic UART's 115200 bps is well within this limit).

Beside of that, the minimal polling interval (so the latency time) is 1 ms, for the full-speed anyway. It's reasonable to specify a greater value, say 5 - 10 ms, in order to do not demand too much from the host. That reduces the risk the host refused to welcome the device on the bus because no resources are currently available.

That's the known limitations.

There can be also OS-specific limitations, which are not always documented. The report structure definition allows for great flexibility but it makes the report parsing a difficult task for the host. No wonder there can be a cases the report structure seems perfectly legal to the HID spec but the host is unable to parse it so the HID device is not enumerated by the OS. Care should be taken to designing a data reports with all that vendor-specific limitations in mind.

And what - if anything - is available to enable users to exploit and properly benefit from HID?

Basically it's all of the public domain. All USB specs are open. The HID class specification defines some type of report description language while there is a tool on the usb.org (http://www.usb.org/developers/hidpage#HID Descriptor Tool) that "allows you to create, edit and validate HID Report Descriptors". This is a rudimentary tool but still it's quite useful.

Concerning the host platform, MS WDK contains tons of related documentation (https://msdn.microsoft.com/en-us/library/windows/hardware/ff543301(v=vs.85).aspx) and the example that "demonstrates how to write a user-mode client application that communicates with HID devices.." (https://msdn.microsoft.com/en-us/library/windows/hardware/ff554118(v=vs.85).aspx).

Igor - you've done a thorough job in listing a CDC progression.   Posters here wonder if a similar "HID" version (as you prefer) might be w/in you?

My USB experience is ten year old and by this time many details are well forgotten. Meanwhile For HID, it's more difficult to do as I have to refresh my knowledge first. Let's hope for the best

---

regards,

    Igor

Hi Igor,

Simply terrific - and so welcome by so many!   Thank you for such an interesting (and generous) narrative - very much a resource, "goldmine."

As you surmised w/in your response to (friend) Roberto - only the MCU's manual "write-up" of "uDMA" competes w/ "USB" for "inadequacy."  (as past tech writer @ semi-firm - I "smell" the heavy hand of marketing, "Ship the damn manual, NOW!)

I'm small, tech biz owner - may be more motivated/resourceful than many - we (constantly) review ARM MCUs from others.  (one vendor - all the time - never/ever best!)   It may be that needed data may be harvested by regular, "extra-vendor" search/study...

In general - much pain/suffering results in the attempt to harness USB.   And - a quite capable - "USB specific" dedicated IC does exist - and from all reports "escapes" most all such USB issues.

Forcing or bending a reluctant device into (some) usability may not make the most sense when a (viable) alternative stands ready/waiting...  (I don't get it...)

Hi cb1,

And also there are many offerings for commercial embedded USB stack..

---
regards,
Igor

Indeed Igor - but (unfortunately) too many here would rather invest 10K (USD) in fruitless, head pounding - than sub 2 (USD) for a, "Tested, ready, chip solution!"

Commercial offerings - costing much more - do not "ping" their radar. (nor does the lost time/effort of their stunted investigative folly...)

The ever/onward "push" of MCUs to become, "Kitchen Sink" is not (often) without serious "disconnects."   Rome burns while (some) await tutorials - not moi...

Igor Uspensky1 said:

As for MS, ten years ago, when VoIP was in fashion, we've carried out several USB dongle designs (some sort of audio cards) for use with Windows. A lots of problems were encountered in the process but eventually it became clear that all the problems are caused by our misunderstanding rather than by Windows.

How modest you are, like a Japanese!
If I were you, I would tell the story in this way (though I'm a Japanese ;)

- We had a requirement to swap configurations on a USB device on the fly.
USB spec supposes Set_Configuration to swap configurations on a device. This scenario worked on Linux and MacOS beautifully, but after considerable fight on Windows, we have realized that Windows wrongly assume just single configuration per device (VID/PID). And then, we had to work it around using this sequence,
- soft-detach / another configuration on another VID/PID / soft-attach.
Unfortunately, USB spec doesn't define soft-detach/attach so precisely. Therefore, we had to confirm this sequence intensively among all of major OS platforms.
The lesson was, we have to understand the way how MS would misunderstand USB spec.


One of the reason why I never recommend Windows CDC is, the in-box CDC driver, usbser.sys, is unreliable.
- no error recovery / no error report on bulk IN endpoint (**1).
Of course, the USB hardware on PC (host controller) recovers error on bulk transfers, up to three times retries. When host controller can't recover after the retries, it passes the error to the PC driver. Decent USB driver should do endpoint error recovery, such as Clear_Feature( ENDPOINT_HALT ). However, usbser.sys silently stops bulk IN polling, without reporting any error to the PC application.
Here is more detailed report on this issue.
www.microchip.com/.../m538194.aspx
100us burst noise on the bus is enough to drop usbser.sys into hang up.

Another reason is, usbser.sys has many known defects so long, but MS has left them unfixed even on the latest Win8.1. Discussed on these posts,
e2e.ti.com/.../371674
e2e.ti.com/.../1385054

There are many minor problems, also. And then, "CDC lost connection" helps have been repeated across MCU fora for these 10 years or more. usbser.sys is a dead end on Windows USB load map. The supposed application (by MS) of this driver is MODEM, which has declined so long. Just MCU developers are still fond of "COM port", based upon the practice of the last century.


(**1) Windows HID driver also doesn't have any error recovery / any error report on the interrupt IN endpoint. But it takes burst noise of 3 ms or more, to make it hang.

Tsuneo

@Forum Users and (tutorial seekers):

We mortals are among the presence of 2 GIANTS - are we not?

Great thanks is owed to both Tsuneo & Igor.

I'm buying more of the "real USB" vendor's stock - USB is so "insider" (just read these two) - effective "tutorial" is as likely as, "world peace."

Tsuneo Chinzei said:

(**1) Windows HID driver also doesn't have any error recovery / any error report on the interrupt IN endpoint. But it takes burst noise of 3 ms or more, to make it hang.

 Hi Tsuneo, I am very proud we started this conversation also if sometime OT, I learned why I experienced a lot of big troubles on debug sessions. So it explain also why it was perfect on linux and drop with so high frequency on M$. IAR IDE MSP based was dropping connection if motor powered but seldom if motor was unpowered. Same PC TIVA never crashed on linux side...

Hosting XP debugger on Linux VBOXED helped have a more stable system but slow and never fail safe. Spikes coming from motor control explain all I suspected and you addressed in more deepest details here!!

 Ti tools was based on TUSB3410,  better competitor on FTDI and Silicon Labs but forever issue where/are on the road. So having a good example can help solve hardware issue .. Using one of this devices expose forever to hard troubles on M$ platform.

 This also answer to CB1 FTDI bias instead of custom driver:

 - Windows hosted CDC forever has trouble on noisy environment.

 - Linux, OSX work fine.

 Using a specific USB maker chip raise the cost and forever expose to have risk when M$ decide burn you your firm is out... Remember FDD Serial Parallel port  now and competitor policy.

 So having a software CDC is a winner Idea one can reuse the hardware at expense of upgrade, having hardwired device forever thrash out all your devices...

 Uhm.. WINUSB.. I Don't  like nor idea nor name as it was for WinPrinter WinModem and other worst WinRubbish  item of the past!

Igor Uspensky1 said:

As for MS, ten years ago, when VoIP was in fashion, we've carried out several USB dongle designs (some sort of audio cards) for use with Windows. A lots of problems were encountered in the process but eventually it became clear that all the problems are caused by our misunderstanding rather than by Windows.

 Hi Igor, that time I bought a stand alone VOIP adapter then a full Networked phone  from Grandstream, more stable and less power angry than Winxzz platform I still Own and use.

 About M$ documentation I forever remember (it was about 20 Yr ago or similar time... ) how much pain was necessary to get a simple program to exchange some bytes working on Win$$ platform....

 All documentation was fuzzy and definitively erroneous sayng to use a number from 0 to 3 when really you must use 1 to 4 and viceversa, no correct definition of aparameter meaning and examples again not working...

 So What I remember from M$ is no reliable documentation nor support too...

 That time I was on OS/2, FreeBSD and VAX VMS plus some IBM Oses on mainframes.

  In this scenario my preferred interfaces are IEEE based so old Firewire was isolated and well documented, Ethernet is a good platform, Blue Tooth is becoming a solid interface well documented.

 USB still is a $$$$ based bad copy of old HPIL interface. (And another name for human interface I dont' remember, that interface on HP PARISC and instrument, it  was proprietary but fine, I still have on an old PARISC)

Hi Tsuneo,

Tsuneo Chinzei said:

- We had a requirement to swap configurations on a USB device on the fly.
USB spec supposes Set_Configuration to swap configurations on a device. This scenario worked on Linux and MacOS beautifully, but after considerable fight on Windows, we have realized that Windows wrongly assume just single configuration per device (VID/PID). And then, we had to work it around using this sequence,
- soft-detach / another configuration on another VID/PID / soft-attach.
Unfortunately, USB spec doesn't define soft-detach/attach so precisely. Therefore, we had to confirm this sequence intensively among all of major OS platforms.
The lesson was, we have to understand the way how MS would misunderstand USB spec.

Not the case because RTFM goes first (for me anyway). And back on that time I've also experienced a USB satori feeling (though I'm not a Japanese ;). The DDK documentation explicitly states that only one configuration for USB device is supported. It just makes no sense to cry about "bugs" in a not supported features.

Tsuneo Chinzei said:

There are many minor problems, also. And then, "CDC lost connection" helps have been repeated across MCU fora for these 10 years or more. usbser.sys is a dead end on Windows USB load map. The supposed application (by MS) of this driver is MODEM, which has declined so long. Just MCU developers are still fond of "COM port", based upon the practice of the last century.


(**1) Windows HID driver also doesn't have any error recovery / any error report on the interrupt IN endpoint. But it takes burst noise of 3 ms or more, to make it hang.

Indeed many findings are reported by a curious guys so far. Every complex design has multiple minor problems. Fortunately, I've no experience in Win CDC class driver (you're right it's a dead end). Our USB software modem uses Audio and CDC classes, but at the host side the driver is custom, so the problems with Win CDC class driver were avoided.

Anyway a USB errors of that level are very rare events (provided the device is well designed). Yes, the problems are reported about input packet error handling in INT input pipe by the HID class driver. But back on that time, I've used CATC TracerTrainer instrument for bus monitoring and never seen such errors. And there are no complains about problems with mouse/keyboard in Windows PC either :)

---

regards,

    Igor

Hi Roberto,

Roberto Romano said:

 Hi Tsuneo, I am very proud we started this conversation also if sometime OT, I learned why I experienced a lot of big troubles on debug sessions. So it explain also why it was perfect on linux and drop with so high frequency on M$. IAR IDE MSP based was dropping connection if motor powered but seldom if motor was unpowered. Same PC TIVA never crashed on linux side...

First of all I'd like to say sorry for lot of big troubles on your debug sessions. But something suggests me that perhaps it'll make sense to find the root cause elsewhere (i mean not in the Windows host driver).

I have an evidence that if everything is implemented correctly then there is no problem with interrupt IN endpoint in Windows. Simply because no error happens :).

My dongle designs incorporated a noisy DC-DC converter (to up to 120V) that has considerable in-rush current and the device was of high power type (500 mA), and the form factor was quite small, and the firmware implemented very complex HID reports structure and I've tried the device with apparently sub-standard USB cables and still no USB errors were discovered by hardware bus analyzer when operating with a Windows host.

The point: paying more attention to hardware usually pays back.

BTW, some USB-UART bridges (namely that from Silicon Labs) are HID-based which mean they uses INT pipe. How much Windows-specific complains about that bridges we can quote?

---

regards,

    Igor

Hi Roberto,

Roberto Romano said:

 About M$ documentation I forever remember (it was about 20 Yr ago or similar time... ) how much pain was necessary to get a simple program to exchange some bytes working on Win$$ platform....

 All documentation was fuzzy and definitively erroneous sayng to use a number from 0 to 3 when really you must use 1 to 4 and viceversa, no correct definition of aparameter meaning and examples again not working...

 So What I remember from M$ is no reliable documentation nor support too...

Just to be fair. The things has changed since that time. Just check it out. And I don't think a better alternative is currently available.

---

regards,

    Igor

Igor Uspensky1 said:

Fortunately, I've no experience in Win CDC class driver (you're right it's a dead end). Our USB software modem uses Audio and CDC classes, but at the host side the driver is custom, so the problems with Win CDC class driver were avoided.

I'm glad to hear from you, we meat in the agreement at least in this point.
Like your case, most of modem manufacturers have developed their own PC drivers, instead of using Windows built-in CDC driver (usbser.sys). Manufacturers of USB-UART chips, too.   Anyone has seldom apply usbser.sys for mass production. It is the major reason why it has been left in abandoned state.

Igor Uspensky1 said:

provided the device is well designed

Surprisingly, the weakest part of USB communication around noise immunity is the pierce crystal OSC on the USB MCUs. The high-impedance loop across the crystal catches noise "efficiently". Even if the MCU core would look like to run flawlessly, USB could fail. USB encoder/decoder are much more sensitive to extra-/missing- clock timing than MCU core.

It is known by the extreme cases, bread boarding, like this post.
Just by taking care of the layout of the crystal (and associated two capacitors), MCUs should exchange USB communication without any problem, even on a bread board.

As of the layout of the crystal, minimize/collapse the loop area enclosed by OSC0 pin - Xtal - OSC1 pin. TI gives good example for TM4C MCUs.

3.7.2 Crystal Oscillator Circuit Layout


When you would have doubt on noise immunity of your board, temporarily replace the crystal with an external OSC chip of the same frequency, and set the Main OSC to the no-crystal mode (MOSCCTL.NOXTAL). If this temporary treatment would solve the problem of USB, your board should require revision around crystal layout. Or, replacement to an external OSC, under heavy noise environment.

Igor Uspensky1 said:

And there are no complains about problems with mouse/keyboard in Windows PC either :)

Mouse/keyboard is low-speed device. The error retries by the host controller occur in much longer interval, 8 ms (while bInterval = 10 ms), than full-speed case (bInterval = 1 ms). It means much longer burst noise should be required to defeat hardware retries. If you would extend low-speed experience blindly to full-speed cases, you should easily get "unexpected" result.

Tsuneo

Igor Uspensky1 said:

I have an evidence that if everything is implemented correctly then there is no problem with interrupt IN endpoint in Windows. Simply because no error happens :).

 Why not??

 Native windows crash more and more times when native than is on drop box... This I think is due to underneath layer of linux driver.

 On Linux same device is stable on GCC and cannot connect on IAR under DropBox, so MSP FET is still active and running, what I need is to restart driver on windows side and after some restart you definitively need shut down windows. If Winzz is native mode this is more frequent and need power cycle or never run again.

 Same pc TIVA board (control panel) is alive, MSP debugger WINZZ  drop connection, MSPGDB connect flawlessy after it is disconnected from, the worst is software was on IAR...

 Same software now ported to CCS (linux) is still debuggable when motor run... this way I cannot debug both MSP and TIVA during communication phase. No trouble I learned about GUIComposer help me a lot tuning parameter on TIVA and single CCS instance.

 Over this stress test I cannot think issue is not on winzz, so MSPFET is TI driver and I have no control over it but it crash frequently... Old parallel port debugger was very fine!!!! If TI rewrote all system interfaces and changed the USB hardware of MSP FET the reason can be another than his driver.

 IMHO Winzz is FOREVER guilty and never well done. I am out of M$ business and I don't like have it embedded. I come from Mainframe era and I like work OSes done as I learned they must be done.

Tsuneo,

Excellent post!

Indeed crystal layout is very important matter for any design and the fact that it's especially important for USB controller (thanks for sharing your finding) may not be unique to TM4C MCUs, from my experience.

As the oscillator is not the only point of concern here, the other vendors provides dedicated application note addressing all hardware specifics of USB with more details. For instance http://www.silabs.com/Support%20Documents/TechnicalDocs/AN0046.pdf .

It's a pity that for TM4C the only related documents are the design guidelines that provides just a bare minimum information (as usual, unfortunately). Let's ask TI when the similar document for Tiva-C MCUs will be available.

Moreover, the USB controller implementation in Tiva-C does not look convenient. The MOSC is actually the only clock source for USB and that fact creates a problem as the MOSC (a power-hungry unit) can't be disabled for suspended mode. So each interested user have to invent, to try and to debug his/her own workaround and this is another reason for TI to come up with the AN discussing the "reference workaround". And yet another reason for the USB AN document is the fact that for Tm4C129x, very few documentation for the USB controller is provided. All is under NDA :(

---

regards,

    Igor