• About PSAS
• Get Involved!
• Schedule
• Projects
• Presentations
• Mailing lists
• Contact us

• Teams
  • Airframe
  • Avionics
  • Communications
  • Ground
  • Payload
  • Propulsion
  • Rocket Science
  • Safety
  • Software
  • Uncertainty
  • Regulation
  • PSU Student Club

Background

The LPC2148 must run software to transmit messages across the USB. Ideally, the USB stack would have the following properties:

• be open source
• support all USB transfer types (bulk, control, interrupt, and isochronous). Isochronous support is especially important, since that will be the main transfer type we use.
• support queueing and DMA
• fit in 40KB of RAM and 512KB flash with room to spare for other software.

There are three open-source options: the eCos USB interface, the Linux USB Gadget interface, and the LPCUSB library.

USB stack Options

The eCos option

eCos (an open source real-time operating system) has already been ported to the LPC2148. eCos has a built-in USB API that a developer can implement for a specific microprocessor.

Advantages

• since we're already using eCos, it should be easy to integrate the USB stack.
• bulk and control transfers can be used.
• five other microprocessors have implemented the eCos USB API, so there are examples to follow.

Disadvantages

• no interrupt or isochronous transfers
• no built-in queueing. This would have to be implemented in the driver, which means we have to implement it again if we ever switch microcontrollers.
• no specific implementation for the LPC2148

The Linux Gadget framework option

We could port the Linux USB stack to eCos.

Advantages

• supports all transfer types
• queueing
• well-defined, used in many devices

Disadvantages

• license issue - the USB gadget framework is GPL, and eCos is modified GPL. That means we can link the Linux gadget framework in our own code, but giving that work back to the eCos community is problematic. There are several options to work around this:
  • don't give the code back to the eCos community and make sure we mention the two licenses in our node driver.
  • if the eCos folks do want the code, they must mention both licenses in their license documentation. Non-GPL code will not be able to link to the ported gadget framework.
  • get the two creators of the gadget framework to re-license the code for eCos.
  • do a re-implementation of the gadget framework (same API, but with re-written code). This is probably the most work.
• the framework has a lot of code in it, and it will need to be stripped down to fit on the board.
• no specific implementation for the LPC2148

LPCUSB

We could also modify an open source USB stack written specifically for the LPC2148.

Advantages

• hardware specific calls (register twiddling) already implemented
• supports bulk, control, and isochronous transfers.
• code could be modified to allow queueing.
• could be integrated with eCos

Disadvantages

• some code in the repository is not under the GPL. The project owner copied some files from another tutorial. Although the files give credit to the person, it makes me nervous to redistribute these files.
• no isochronous transfer support
• no DMA support (yet)
• small project, not many developers working on it (how do we know it will stick around?)

Conclusions

While the Linux gadget framework is widely used, the license issues and amount of work to strip down the library makes it unattractive. The eCos USB API has structural flaws (such as no queueing) that also make it unattractive. The LPCUSB stack provides the most flexibility and much of the hardware specific code is already written.