NOTICE: The Processors Wiki will End-of-Life on January 15, 2021. It is recommended to download any files or other content you may need that are hosted on processors.wiki.ti.com. The site is now set to read only.

Talk:StarterWare USB

From Texas Instruments Wiki
Jump to: navigation, search
For technical support please post your questions at http://e2e.ti.com. Please post only comments about the article StarterWare USB here.

Comments on StarterWare USB


Walter R said ...

In the "Running the Application" section:

Should the text say, "Type in either terminal window on the host PC. [When you push <enter> your] text should appear on the other terminal screen." (The text in brackets is mine.)

I need software that will send "bulk" data, not just a single ASCII byte, and the current WIKI page is ambiguous on this point. That is, does the example software send a *single* byte of data (one ASCII byte), or can it send *many* bytes of data all together in a single USB communication event? I need the latter.

--Walter R 16:45, 4 February 2012 (CST)

Walter R said ...

Though I'm exceedingly excited about (finally) getting a promising approach for developing USB applications, I have an additional question.

The StarterWare is advertised as useful for (among other things) the c6748 DSP alone, and the OMAP-L138 (which is a c6748 DSP plus an ARM part). I desire for the USB handler to run on the ARM part, while the DSP simultaneously does its signal processing. However, this Wiki page does not reveal a clear path for developing USB handling on the DSP versus the ARM. This Wiki page could use some clarification on this point, together with a link to other Wiki pages that explain the broader issue of developing for the OMAP part (DSP + ARM).

--Walter R 16:57, 4 February 2012 (CST)

Walter R said ...

Long into my USB StarterWare project, I discovered -- to my surprise and lament -- that the USB StarterWare library issues a compile-time "warning" about the "packed attribute" used within the StarterWare software itself. It further recommends that we upgrade to compiler version 5.x -- which is NOT YET available! <arrrgggh> It offers to other work-arounds -- no other compilers that will work. And it is vague of the depth of its "warning". That is, does the warning merely mean, "Go ahead and run the executable file because it compiled/linked fine, but the debugger won't yet properly display the packed data structures." ? Or does the warning mean, "Stop! Don't run the executable file, because it will crash."  ? Or does the warning mean something else. These matters need to be cleared up within this Wiki-page -- rather than leaving it for us users to discover late into our projects.

--Walter R 02:11, 6 March 2012 (CST)

Walter R said ...

I'm reading the StarterWare documentation on how to use the USB APIs. (This documentation is apparently comprised mainly, if not solely, by the .chm help file that accompanies the StarterWare package. In almost all cases, the .chm file gives good insight into each function call and the required parameters. However, what is absent, in my view, is a helpful overview of how to use the various functions reliably.

Let me first assert that I (as a USB API programmer) want to know as little about USB as possible. I only want to know what I need to know to get the job done. I want the USB APIs to do the job of object-oriented programming by HIDING trivial details from me that I don't need to know.

That said, I need to know that certain details are being taken care of in a reliable manner.

Let me give a particular suite of examples: error-detection and error-recovery. There are occasions when the USB APIs signal an error of some kind. Great! NOW WHAT AM I SUPPOSED TO DO WITH THAT? I need some insight on the proper handling of the errors. I need to know what I'm expected to do, and in turn, what the USB APIs can be relied upon to do. I need to know that my handling of a given error will not result in a lock-up (where I'm waiting for the APIs to do something, and the APIs are waiting for me to do something, for example). If the host disconnects, or an idle-timer times out, or an over-run occurs, I need some insight on the proper error-handling. AND I'M NOT GETTING THAT INSIGHT FROM THE .CHM FILE. (Am I supposed to decode and interpret the innards of the StarterWare API source codes? Ugh!) Something additional is needed. Perhaps in these Wiki pages? Perhaps an additional help file that accompanies the StarterWare package?

--Walter R 04:51, 6 March 2012 (CST)

Ypeels said ...

@Walter R,

Have you tried CodeSourcery gcc? This free compiler toolchain is mentioned briefly as a workaround for OMAP here:

http://processors.wiki.ti.com/index.php/StarterWare_01.10.03.03_Release_Notes#Known_Issues_and_Limitations

I've only tried with AM1x, but I could not get TI's built-in compilers to work correctly, in either CCSv4 or CCSv5. To get the usb_dev_bulk example to enumerate correctly, I had to migrate to CodeSourcery:

http://e2e.ti.com/support/embedded/starterware/f/790/t/151682.aspx?PageIndex=2#584582

Watch out for possible compiler version variation - for newer CodeSourcery compilers, I had to add the flag -fno-zero-initialized-in-bss

TI staff are pretty good at replying on forums <e2e.ti.com> - have you tried asking there? If you have any questions about what I posted, let's continue the discussion there - I go by the screen name "Jonathan Chen"

Sincerely, ypeels

--Ypeels 11:15, 6 April 2012 (CDT)

Jcoombs said ...

I wanted to comment briefly on some topics mentioned in other comments. For OMAP-L138, the TI codegen tools will not produce working ARM USB binaries unless you use compiler version 5.x or later. This is mentioned various places in the wiki documentation and in a printed warning statement when you attempt to build the USB libraries and applications. In the meantime, we also support using CodeSourcery GCC to build the USB libraries and applications. GCC makefiles are included for all libraries and applications. In the OMAP-L138 StarterWare package, look in the build/armv5/gcc folder tree to find the makefiles I am referring to.

(Note: I want to explicitly state that there are only issues with the TI codegen tools version 4.x for ARM9. The TI codegen tools for C6000 DSP and ARM Cortex-A8 do not have any issues with StarterWare.)

Regarding ARM+DSP, StarterWare provides a lightweight IPC package called ipclite to facilitate communication between the ARM and DSP. That package is documented on the OMAP-L138 StarterWare user guide. There also three example applications (actually three pairs of ARM+DSP example applications) included with StarterWare. On a related note, the StarterWare bootloader for OMAP-L138 supports booting to ARM and DSP applications out of device reset. For more information, please refer to the OMAP-L138 StarterWare booting and flashing guide.

If anyone has further questions about these topics, I recommend searching and posting on the StarterWare forum on the TI E2E site.

--Jcoombs 13:53, 3 May 2012 (CDT)