Black Moon wrote:
> Hi, I was wondering if anyone has an example of hardware 'ping pong'
> buffer code (double buffering) for the 18Fxx5x series of uC's? Iv tryed
> to port the microchip sample code to it, but never managed to get it to
> enumerate as I just ended up screwing up all the setup/ep0 code.
> if someone could just send me some C example code (perferabley for
> hitech PICC18 compiler, but I can port if needed) of ping pong
> buffering code (Mode 2, buffering on all endpoints) of even just the
> setup section, I could code my own for the data part.

I've got code but:

1 - It's in assembler, so you wouldn't care.

2 - I'm not finished with my device yet end to end so I can't be sure it's
working.  It does appear to enumerate properly up to the point where Windows
looks for a driver.  It stops there since I haven't written one yet.

3 - I'm not sure how much of this code I want to publicly release and under
what conditions.  I may eventually make it available for private use, but
not until I'm done and I feel confident that all is working.  I don't want
to do something now that prevents me from charging commercial users later.

However, the basic strategy is not that hard to understand.  I keep three
buffers for each endpoint/direction.  Two are always allocated to the two
hardware buffer descriptors and the third is allocated to the firmware which
is either filling or draining it depending on direction.  For an OUT
endpoint the buffers are rolled by one when the next hardware transaction
completed and the firmware buffer is empty.  For an IN endpoint, the buffers
are rolled by one when there is at least one byte in the firmware buffer and
the next hardware buffer descriptor is ready for a new transaction.

My low level USB module presents byte PUT or GET interfaces per endpoint
that hide all this complexity.  In addition there is USB_RUN which must be
called "often" from the main event loop.  It checks for and handles hardware
events, and possibly rolls the buffers if the firmware buffer is ready.  The
PUT and GET routines also roll the buffers if the hardware is ready.

I have a separate USB0 module that handles the endpoint 0 conversation and
performs setups requests.  This is mostly layered on the GET and PUT
interfaces for endpoint 0 exported by the USB module.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist