Sat Apr 2 16:18:46 EDT 2011
The main problem for USB is handling a lot of struct data, i.e. the
endpoint registers used to control the USB hardware.
Let's assume the descriptors are just flash constants.
Just trying to load the usb code gives undefined words for:
Where do they come from?
What about this one? Nope it has some missing code.
Tue Jun 2 09:35:33 EDT 2009 email@example.com
* usb driver needs more abstraction
This one does have the EP0 macro definitions:
Mon Jun 1 02:56:40 EDT 2009 firstname.lastname@example.org
\ *WORD* means the current object context has changed: all literal
\ addresses below #x60 are relative indexes.
: EPn-OUT 3 <<< ;
: EPn-IN EPn-OUT 4 + ;
\ ( reladdr -- ) set object to buffer descriptor in bank 4
: *BD* al ! 4 ah ! ;
: *EP0-OUT* 0 EPn-OUT *BD* ;
: *EP0-IN* 0 EPn-IN *BD* ;
Basicly, each endpoint has count, buffer and a control register. I
was using a-relative addressing. Should this be maintained?
The main problem is getting this abstraction right. In C it would be
trivial but in Forth we need to be a bit clever.
Brodie's idea is to try to avoid structures: use code/commands
instead. Essentially what more does is to use global variables to
store a current state, and have words operate on the current state.
If combined with save/restore on a stack this is essentially dynamic
binding. The previous approach did exactly that, but using the index
register that's normally intended to hold the stack frame.
So it isn't much else than filling buffers either with fresh data or
from constants and sending acks, so let's build a proper abstraction