>
> Graham Daniel wrote:
> >=20
> > Tjaart van der Walt wrote:
> > >
> > > I am looking at writing a command parser for an SX28.
> > > Flying at 50 or 100 MIPS, the program will execute from
> > > external SPI memory (like a Stamp, just faster). There
> > > are plenty of SPI EEPROMs out there, but I haven't noticed
> > > an SPI RAM chip I can use for scratch memory/variables.
> > > Has anyone seen anything like this?
> >=20
> > The new Atmel "Dataflash" has twin buffers for read/write of flash data.
> > These buffers could also be used for scratch memory.  Clock frequencies
> > vary from 1 to 15 MHz, size is mega +
> > Buffers are mostly just over 256 bytes each.
>
> 256 bytes of scratch will do nicely...
> =20
> > Realtime clock chipz usually have general purpose ram also.
>
> ...and the RTC will be a bonus.
> Do you have any idea what the smallest Dataflashes=20
> sell for? (in USD).

You can pick up the 8Mbit part from Marshall (www.marshall.com) for $12 in
singles. I'm planning on buying a couple for some projects I want to get
off the ground.

Another possibility for memory is the Dallas Semicondutor DS1380 and DS1381.
They are parallel parts, but they duplicate the 8 bit parallel port. So it
ends up being a 3 bit interface in cost. Can't remember if the port can be
configured as input/output on a bit by bit basis.

You get 2K of RAM with the parts the DS1381 has it battery backed.

I was looking at it to do the same task.


>
> I haven't written a parser/interpreter before, but=20
> methinks it will be quite a nice challenge.

It is. I've been working on my on and off for the last 4 years. I'd gotten
it to a usable state, then realized I had a flawed design in my bytecode that
made local variables real difficult to do. So I updated the compiler but I
haven't gotten around to updating the bytecode interpreter yet.

>
> What sort of real nasties should be avoided?

Specialization of bytecodes. Keep everything real simple. Using a computation
stack simplifies everything because since all computation happens on the stack
none of your computation bytecodes require any extensions. For example a
typical PIC sequence to perform the statement i=j+k would be:

        movf    j,W
        addwf   k,W
        movwf   i

Compact yes, but referring to all the registers makes the opcodes between 12
and 16 bits wide. On a stack machine the sequence would be.

        push    j       ; Push the address of j, not its value
        getval          ; Get the value of the address on the top of the stack
        push    k       ; Same for k
        getval
        add             ; Add the two
        push    i       ; Push the address of I
        assign          ; Assign the value of j+k to the address on the top
                        ; of the stack.

I know that separating the push of the address and the getting of the value
may seem wasteful, and that a specialized instruction to do both is warrented,
but this is where I got bit, because global variables, which reside out in
main memory, and local variables, which are in fact on the stack, makes the
specialized instruction too specialized.

And while the first sequence looks a lot shorter, because you won't have the
PIC luxury of 12,14, and 16 bit words, just 8 bit ones, each of those
instructions in fact will take up 2 bytes, whereas my bytecode sequence takes
one byte per bytecode (hence the name ;-). So the code savings is in fact
only a single byte.

And unless the SX28 has SPI hardware built in, the serial loading of opcodes
is going to dominate timewise over the execution time of the bytecodes anyway.

My bytecode interpreter is far from a kernel of an idea, it's a nearly working
full blown project. Time constraints and licensing issues have prevented my
making it publicly available. The licensing issue is simple but sticky. I'm
a Open Source code advocate. However I believe it's quite fair that if
someone uses your work in a commercial product, then for the author(2), there
should be compensation involved. This is complicated by how to distribute
royalties when multiple folks contribute.

I can delay figuring this out for folks who are willing to agree not to sell
and for now, not to distribute. It'll give you a rather large boost in trying
to get this done.

Let me know if anyone is interested and in the next week or so I can get
sorted out enough to distribute what I currently have.

BAJ