Funny NYPD wrote:
> It is not I don't want to use the USB based PICs or Microchip software
> stacks. It is I cannot afford for a loss of business due to PIC silicon
> errata or SW stack bugs. (When I released a product, I want to make
> sure I will have a nice sleep in the night.)

Then you should consider our USB firmware.  We've used this in close to a
dozen products by now, our own and those of our customers.  Our USBProg,
USBProg2, and LPROG PIC programmers use it, for example.  It was written in
assembler to be careful with resources to maximize the applications it can
support.  It deliberately doesn't use interrupts so as not to get in the way
of low interrupt latency a application may require.

The driver that comes with it exports pipe 1 as a bi-directional stream of
bytes.  To the host application and the firmware application, it therefore
looks a lot like UART or TCP communication.

The firmware uses the ping-pong buffering mode of the USB hardware with
three rolling software buffers, although this is all under the hood and
"just works" from the application's point of view.  The app calls PUT and
GET byte routines.  There are also control options availble, like hold
buffer until full, flush, and others.  Unless you are doing something
unusual, device enumeration is taken care of and all you have to do is fill
in a include file with your static information.  The code is carefully
documented, even if I say so myself.

The version on the web site is for applications that use the main event loop
model.  This version requires the app to call USB_RUN and USB0_RUN to let
the background USB handler and the endpoint 0 logic run.  We also have a
version that uses our cooperative multi-tasking system, where the USB
backround functions are performed in their own task.  This is the version we
used, for example, in our USB to CAN adapter.

The firmware source code, driver, and host example code is available from
http://www.embedinc.com/pic/dload.htm.  Note that there is some cost for
commercial products, but that's the case too if you roll your own or live
with the Microchip problems.  Everything is generally free for hobbyists.
See the license for details.

By the way, we also have other robust firmware subsystems like CAN and a
network stack that actually works without mysterious hangs, and that has
much less onorous restrictions on the application than the Microchip stuff.
The network stack includes a ENC28J60 driver for the packet layer, enough of
ICMP to reply to ping requests, ARP with configurable number of cache
entries, IP, and TCP.  UDP and a DHCP client will likely be added in the
near future.  The TCP layer presents a put byte and get byte interface for
each connection.  Unlike with the Microchip stack, the application does not
need to be aware of packet boundaries or whether other connections have a
receive or transmit packet open at the time.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist