[<<][staapl][>>][..]
Sun Feb 15 18:19:41 CET 2009

old usb driver

It works "a bit"..  I got stuck in may 2008 when trying to get it to
work on a tight schedule..  The problem then was probably a compiler
bug that I hope has made it out now..

The files I have are:

~/darcs/brood-4/prj/USBPicStamp/usb.f
~/darcs/brood-4/prj/USBPicStamp/cdc.usb
~/darcs/brood-4/host/usb.ss

These are now in staapl/pic18

The architecture is as follows:

  * Each usb driver starts from a .usb file containing a high level
    version of the configuration data structure that will be queried
    by the host.  From this a "compiled" version of this data
    structure is generated.

  * Next to this there is a driver library that implements the USB
    logic and state machine.


There is one big decision to be made up front though: use the extended
instruction set or not?  In this mode, there is a "frame pointer".
The first 0x60 bytes of the first page are interpreted relative to
FSR2.

The thing is: these might be convenient for c-style local variables or
objects, but I'm not sure if this deserves a whole new architecture /
ABI.  Is it possible to make this just a simple extension?  Or can we
do without?  I did use it extensively before..

At first sight, this does intruce a new problem: namespaces.  When
objects are used, they behave as namespaces, and the language simply
doesn't have any straightforward mechanisms for it..

So.. Let's just keep this as an experiment and solve it using dynamic
variables.  Together with cooperative multitasking and clear data
separation of the preemptive parts (interrupts) dynamic binding should
work just fine.



[Reply][About]
[<<][staapl][>>][..]