[<<][staapl][>>][..]
Thu May 21 18:09:28 CEST 2009

usb

After three years maybe it's time to finally write the damn driver,
no?

Funny how this has been problematic for a while.

Using picstamp.fm from app/ to get it going.

First: getting old code to compile.

Simply invoking "load usb.f" gives:
 include "/data/safe/tom/darcs/brood-5/staapl/pic18/usb.f"
 include "/data/safe/tom/darcs/brood-5/staapl/pic18/shift.f"
reference to undefined identifier: macro/device-descriptor

This identifier is present in pic18/usb.ss but still uses an old
symbolic interface.  Let's see if that module can be revived on its
own.

The main function is 'usb-compile-device
I have one description file: pic18/cdc.usb

Let's change the interface such that this file becomes a module which
includes some scheme code and used the 'define-usb-device form.

OK, it generates this:
(: device-descriptor f-> 18 |,| 18 |,| 1 |,| 16 |,| 1 |,| 0 |,| 0 |,| 0 |,| 64 |,| 216 |,| 4 |,| 1 |,| 0 |,| 0 |,| 0 |,| 4 |,| 3 |,| 2 |,| 1 |,| : string0 f-> 23 |,| 23 |,| 3 |,| 68 |,| 101 |,| 102 |,| 97 |,| 117 |,| 108 |,| 116 |,| 32 |,| 67 |,| 111 |,| 110 |,| 102 |,| 105 |,| 103 |,| 117 |,| 114 |,| 97 |,| 116 |,| 105 |,| 111 |,| 110 |,| : string1 f-> 19 |,| 19 |,| 3 |,| 68 |,| 101 |,| 102 |,| 97 |,| 117 |,| 108 |,| 116 |,| 32 |,| 73 |,| 110 |,| 116 |,| 101 |,| 114 |,| 102 |,| 97 |,| 99 |,| 101 |,| : string2 f-> 5 |,| 5 |,| 3 |,| 48 |,| 46 |,| 48 |,| : string3 f-> 10 |,| 10 |,| 3 |,| 85 |,| 83 |,| 66 |,| 32 |,| 72 |,| 97 |,| 99 |,| 107 |,| : string4 f-> 28 |,| 28 |,| 3 |,| 77 |,| 105 |,| 99 |,| 114 |,| 111 |,| 99 |,| 104 |,| 105 |,| 112 |,| 32 |,| 84 |,| 101 |,| 99 |,| 104 |,| 110 |,| 111 |,| 108 |,| 111 |,| 103 |,| 121 |,| 44 |,| 32 |,| 73 |,| 110 |,| 99 |,| 46 |,| : config0 f-> 25 |,| 9 |,| 2 |,| 25 |,| 0 |,| 1 |,| 0 |,| 0 |,| 160 |,| 50 |,| 9 |,| 4 |,| 1 |,| 0 |,| 1 |,| 3 |,| 1 |,| 1 |,| 1 |,| 7 |,| 5 |,| 128 |,| 160 |,| 8 |,| 0 |,| 0 |,| : string-descriptor 5 route/e string0 |;| string1 |;| string2 |;| string3 |;| string4 |;| string-error |;| : configuration-descriptor 1 route/e config0 |;| config-error |;|)


OK, now to make the code a bit more modern.

I need an abstraction for building tables.  Something that can
interleave a bunch of atoms with a compile function.  I.e.:

begin-table ,
  1 2 3 4 5
end-table

Maybe with a more concise syntax?

Something like { , 1 2 3 4 5 }

Wait, since "[" and "table[" are independent tokens, square brackets
could be used for any kind of structured data, allowing s-expressions
to occur in Forth style code.  Alternatively, "scheme" and "table"
could be prefix parsers that allow arbitrary s-expression
transformation.

  scheme: [ define foo [ + 1 2 ] ]     \ scheme expression
  table: , [ 1 2 3 4 5 6 ]             \ constant table
  [ 1 2 + ]                            \ quoted function

Actually, why invent new syntax if s-expressions do just fine..  The
reason to not have s-expressions in Forth is that then you don't need
to represent them at compile time.  Additionally, Forth control words
allow to be composed in strange ways by themselves.. I don't like to
throw that away.

But in scheme it's really easy to do this:

(define-syntax-rule (table: separator (item ...))
  (macro: ,(macro: item separator) ...))

So for defining tables I do think that Forth-style prefix parsers
might not be the right way to go.  It's probably easier to write
Scheme macros and provide some s-expression based syntax to access
them from flat Forth.

So, what is necessary is a generic way to create prefix parsers that
take an s-expression as an argument and pass it to a scheme macro to
produce an opaque coma macro.  (with "{" and "}" reserved for module
level expressions)

(snarf-prefix-macro macro:)



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