Searching \ for 'Command Parser' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=command+parser
Search entire site for: 'Command Parser'.

Truncated match.
PICList Thread
'Command Parser'
1999\05\12@061225 by Tjaart van der Walt

flavicon
face
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?

At a  fraction of the cost, such a parser would emulate
a real mean micro. Your PC becomes the ICE, and the
RS232 port the programmer. On-the-fly program updates
will be real easy too.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
spam_OUTtjaartTakeThisOuTspamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : .....tjaartKILLspamspam@spam@sms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\12@082650 by g.daniel.invent.design

flavicon
face
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?

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.

Realtime clock chipz usually have general purpose ram also.

regards,
Graham Daniel.


{Quote hidden}

--
Steam engines may be out of fashion, but when you consider that an
internal combustion engine would require recovery of waste heat by
transfer just before top dead centre then fashion becomes rather
redundant, USE STRATIFIED HEAT EXCHANGERS ! and external combustion.

You heard it first from: Graham Daniel, managing director of Electronic
Product Enhancements.
Phone NZ 04 387 4347, Fax NZ 04 3874348, Cellular NZ 021 954 196.

1999\05\12@085404 by Tjaart van der Walt

flavicon
face
Graham Daniel wrote:
>
> 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?
>
> 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...

> 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
sell for? (in USD).

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

What sort of real nasties should be avoided?

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
EraseMEtjaartspam_OUTspamTakeThisOuTwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : tjaartspamspam_OUTsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\12@094614 by g.daniel.invent.design

flavicon
face
Tjaart van der Walt wrote:
> > 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
> sell for? (in USD).

2Mbit & up:dual buffers
4Mbit D'flash $8.95 NZ
8Mbit D'flash $16.98 NZ
16Mbit D'flash $28.68 NZ
REC prices, halve for USD

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

-PC front end
-parser/interpreter
-BIOS, BIOS options at compile time for memory/pin optimisations
-simulator

The Atmel micro has (IIRC) better pointer operations and can work with
SRAM, if you need speed then this + the D'flash would be far more
powerful as the extra ram would act as a large cache, Mega probably
already has sufficient cache on board for most apps.

As soon as you multitask memory bottlenecks are going to cause major
slowdowns.

I would probably optimise for a certain amount of multitasking by
a) giving maximum standalone capability to each operation (multiple
parameter passing, queued macroinstructions.)
b) Split D'flash pages for multiple task updating per access.
c) Designated frequent tasks stay in RAM
d) Try to align task code tokens with time aligned same page accesses

speed still needs RAM

If you used the ATMEGA then you could fill part of the memory with an
OS, and another part with the command tokens, updating would require ISP
cable and program intervention.

>
> What sort of real nasties should be avoided?
If it is going to be easy to use then try to do a GUI front end like the
STM Actum solutions Realiser, on monitor PLC schematic compiles to ASM
and then hex, wires correspond to data transfer, devices correspond to
dedicated subroutines.  You will probably need multitasking, this will
require dynamic variable space allocation for multiuser tasks. I am not
sure if the Scenix is up to major pointer type operations, Atmel might
be better.  I have considered a CPLD/Scenix/Atmel embedded processor to
provide a kind of DMA function

regards,
Graham
--
Steam engines may be out of fashion, but when you consider that an
internal combustion engine would require recovery of waste heat by
transfer just before top dead centre then fashion becomes rather
redundant, USE STRATIFIED HEAT EXCHANGERS ! and external combustion.

You heard it first from: Graham Daniel, managing director of Electronic
Product Enhancements.
Phone NZ 04 387 4347, Fax NZ 04 3874348, Cellular NZ 021 954 196.

1999\05\12@101138 by Andy Kunz

flavicon
face
>an SPI RAM chip I can use for scratch memory/variables.
>Has anyone seen anything like this?

RAMTRON has SPI parts now, I believe.  It's about as close to RAM as you'll
find.

       http://www.ramtron.com

Andy

==================================================================
  Montana Design Tech Support - http://www.montanadesign.com
==================================================================

1999\05\12@114456 by Walter Banks

picon face
They are not hard to write quite fun actually.

> What sort of real nasties should be avoided?

Interrupts : }}

W..

1999\05\12@140355 by Dave VanHorn

flavicon
face
> They are not hard to write quite fun actually.
>
> > What sort of real nasties should be avoided?
>
> Interrupts : }}


How are interrupts nasty?  I wrote one recently for an F84, had a 1mS timer
int and IIRC a couple others, no trouble at all.

1999\05\12@172044 by Craig Lee

flavicon
face
I've just completed a neato display module to show formated position
data from any NMEA gps receiver.  It works quite well in a 16F84, and
uses a software UART with interrupt support.

For sale if any interest contact me off-list.

I have had difficulty with interrupts in the past.  Particularily stay
away from the interrupt on change stuff, be careful with the capture/
pwm setup, and SSPI2C stuff is a bitch!  Also, make sure your read all
the application notes on interrupts and make sure you are mindful of
your stimulus signal rise times, period, etc. when coding.

Craig

> {Original Message removed}

1999\05\12@172623 by Andy Kunz

flavicon
face
At 11:50 AM 5/12/99 -0400, you wrote:
>They are not hard to write quite fun actually.
>
>> What sort of real nasties should be avoided?
>
>Interrupts : }}

You're bad, Walter!  I love it - a Scenix without any virtual peripherals!
That'll save him a lot of coding time <G>

Andy

==================================================================
  Montana Design Tech Support - http://www.montanadesign.com
==================================================================

1999\05\12@220409 by Antonio L Benci

flavicon
picon face
Command parsers, easy as pie...

Wrote one for the FED BASIC 16C74 chip. Used to control two stepper
motors over a serial interface. Basically all I did was to read the
command string into a buffer till the appropriate line terminator was
seen. Then the string in the buffer was parsed for the appropriate
command string block, fixed format for ease of programming...

The string block was then sent to an If/Then/Else table to select the
operation required with respect to the the two byte string...

Nice and easy. If anyone would like a copy of the code a request via
private email will be only be accepted...

Tjaart van der Walt wrote:
{Quote hidden}

Nino.
--
******************************************************
* Antonio (Nino) Benci                               *
* Electronic Services Manager                        *
* Monash University - Dept of Physics                *
* Wellington Rd, Clayton. 3168                       *
* Victoria, Australia.                               *
* TEL    - 61 3 9905 3649, FAX - 61 3 9905 3637      *
* Mobile - 0414 764 763 (private and ah only)        *
* EMAIL  - @spam@nino.benciKILLspamspamsci.monash.edu.au (work)       *
*        - KILLspamfleatechKILLspamspamexcite.com (private)             *
* WWW    - http://www.physics.monash.edu.au/                *
******************************************************

1999\05\12@224115 by Tony Nixon

flavicon
picon face
> Tjaart van der Walt wrote:

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

I'm having a go at writing an interpreter based program at the moment.
It's not all that hard, but when Windows becomes involved in the
equation things can get a bit tricky. Nice challenge though :-)

--
Best regards

Tony

PicNPoke - Multimedia 16F84 Beginners PIC Tools.

http://www.picnpoke.com
Email RemoveMEpicnpokeTakeThisOuTspamcdi.com.au

1999\05\13@004249 by Tjaart van der Walt

flavicon
face
Tony Nixon wrote:
>
> > Tjaart van der Walt wrote:
>
> > I haven't written a parser/interpreter before, but
> > methinks it will be quite a nice challenge.
>
> I'm having a go at writing an interpreter based program at the moment.
> It's not all that hard, but when Windows becomes involved in the
> equation things can get a bit tricky. Nice challenge though :-)
>
> --
> Best regards
>
> Tony

You *are* going to call it PICnParse, aren't you? ;)

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
spamBeGonetjaartspamBeGonespamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : TakeThisOuTtjaartEraseMEspamspam_OUTsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\13@004915 by Tjaart van der Walt

flavicon
face
Andy Kunz wrote:
>
> At 11:50 AM 5/12/99 -0400, you wrote:
> >They are not hard to write quite fun actually.
> >
> >> What sort of real nasties should be avoided?
> >
> >Interrupts : }}
>
> You're bad, Walter!  I love it - a Scenix without any virtual peripherals!
> That'll save him a lot of coding time <G>

<G> Virtual coding!

I am looking at building up a few 'standard' routines first.
Stuff like 16*16, 16 div 16, PortOut, PortIn, BitOut, BitIn etc.

A collegue pointed out that Boolean variables (I love 'em) will
be real hard to optimise. SOme of the variables like loop counters
etc. will have to be local (SX) memory. Arrays and variables used
less often will go into the RAM. This is a good time to perfect
the 'dirty flag' with regards to the code memory.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
RemoveMEtjaartspamTakeThisOuTwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : tjaartEraseMEspam.....sms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\13@005120 by Tjaart van der Walt

flavicon
face
Antonio L Benci wrote:
>
> Command parsers, easy as pie...
>
> Wrote one for the FED BASIC 16C74 chip. Used to control two stepper
> motors over a serial interface. Basically all I did was to read the
> command string into a buffer till the appropriate line terminator was
> seen. Then the string in the buffer was parsed for the appropriate
> command string block, fixed format for ease of programming...
>
> The string block was then sent to an If/Then/Else table to select the
> operation required with respect to the the two byte string...
I wrote a scaled-down 'script' parser for communications on a 16C77
(reads stuff from i2c) which works well, but I have never attempted
a full-scale job.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
EraseMEtjaartspamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : RemoveMEtjaartEraseMEspamEraseMEsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\13@020711 by William Chops Westfield

face picon face
Speaking of compiler classes flunked, and command parsers, and such,
there were a couple things I did aside my compiler class that I found
particularly useful for building an understanding of such things.

One was learning about the FORTH language.  Aside from other strengths and
weaknesses, FORTH has an extremely trivial parser, andd it's very
instructional.  (learning how to operate an RPN based calculator, or program
postscript, is probably equivilent.)  I'm led to believe that LISP is
similarly trivial to parse.  (This is why lisp dialects are such common
extension languages for editors (like emacs and clones) - not much effort
needs to go into the interpretter itself.)

The second was an article in (showing my age) "Best of Byte Volume 1" on the
"My Deat Aunt Sally" algorithm for parsing arithmatic expressions and
getting the precedence right (Multiply Divide Add Subtract.)

I actually went so far as to write a function compiler that you could call
from a fortran program.  This was for the classic 3-d function plot code
that was around at the time - since it was a big pain to keep recompiling
and linking the thing every time you wanted to draw a new picture, I wrote
some neat-o assembler that parsed a numeric expression (including fortran
functions) and built up rather less neat-o machine code that looked like a
fortran function, and did your basic FP math (calling the real fortran
library for all the functions, of course.)  Worked great.  Since this was FP
math, and generally with pretty complex functions, the fact that the
equation code itself was, um, a forth-like implementation of a calculator
with not very optimal code was dwarfed by the time spent doing the math
itself anyway.  (gee, I wonder if it would have counted as the final project
in the compiler class.)

BillW

1999\05\13@102026 by Byron A Jeff

face picon face
{Quote hidden}

You can pick up the 8Mbit part from Marshall (http://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

1999\05\13@104312 by Byron A Jeff
face picon face
>
> They are not hard to write quite fun actually.
>
> > What sort of real nasties should be avoided?
>
> Interrupts : }}

Shouldn't be a big deal. Interrupts should save the current state, do whatever
they need to do, set a flag in the interpreter, and return. The interpreter
can finish up interrupt processing by checking the flag at the top of the
instruction fetch loop.

BAJ

1999\05\13@111426 by Tjaart van der Walt

flavicon
face
Byron A Jeff wrote:
>

>
> 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.

At 50 MIPs I think it could compensate for the fact that it will be bit-banged.

> 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.
It surely will. The development is for a commercial application however, so
we'll have to develop it ourselves so we can own the code.

> 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.

It is a very interesting topic (for me, anyway), so I'd like to pick
your brain a bit... Hey, it isn't even off-topic.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
RemoveMEtjaartspam_OUTspamKILLspamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : RemoveMEtjaartTakeThisOuTspamspamsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\13@133447 by Andy Kunz

flavicon
face
At 10:42 AM 5/13/99 -0400, you wrote:
>>
>> They are not hard to write quite fun actually.
>>
>> > What sort of real nasties should be avoided?
>>
>> Interrupts : }}
>
>Shouldn't be a big deal. Interrupts should save the current state, do whatever
>they need to do, set a flag in the interpreter, and return. The interpreter
>can finish up interrupt processing by checking the flag at the top of the
>instruction fetch loop.

WAKE UP GUYS!  It was a FUNNY!  WIthout interrupts, a Scenix is just a 4X
PIC16C57!!!!

No virtual peripherals!

Andy

==================================================================
  Montana Design Tech Support - http://www.montanadesign.com
==================================================================

1999\05\14@003226 by Byron A Jeff

face picon face
>
> Byron A Jeff wrote:
> >=20
>
> >=20
> > And unless the SX28 has SPI hardware built in, the serial loading of op=
> codes
> > is going to dominate timewise over the execution time of the bytecodes =
> anyway.
>
> At 50 MIPs I think it could compensate for the fact that it will be bit-b=
> anged.

It will. However I don't think you'll get the full 10 to 15 Mhz available
bandwidth bit banging.

>
> > 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.
> It surely will. The development is for a commercial application however, =
> so=20
> we'll have to develop it ourselves so we can own the code.=20

Understood. However you could possibly examine my bytecode set and design
decisions to get a basis for designing your own.

>
> > Let me know if anyone is interested and in the next week or so I can ge=
> t
> > sorted out enough to distribute what I currently have.
>
> It is a very interesting topic (for me, anyway), so I'd like to pick=20
> your brain a bit... Hey, it isn't even off-topic.

Pick away.

BAJ

1999\05\14@033802 by Tjaart van der Walt

flavicon
face
Byron A Jeff wrote:
>
> >
> > Byron A Jeff wrote:
> > >=20
> >
> > >=20
> > > And unless the SX28 has SPI hardware built in, the serial loading of op=
> > codes
> > > is going to dominate timewise over the execution time of the bytecodes =
> > anyway.
> >
> > At 50 MIPs I think it could compensate for the fact that it will be bit-b=
> > anged.
>
> It will. However I don't think you'll get the full 10 to 15 Mhz available
> bandwidth bit banging.

If I get 1 Mtip (million token instructions per minute), I'll be very happy.
I was thinking of 'pipelining' as many tokens as possible. Basically I'll
just load, say 10 tokens instead of 1. If the program branches out of the
cached tokens, I will have to reload.

I was thinking of running a reasonably transparent ISR in the SX that will
make the RS232 comms available as RX and TX registers 2 or 3 buffers deep each.
Maybe it will be worth implementing a task despatcher system in the SX with
multi-threading. Hmmmm. Hello semaphores, goodbye sleep ;)

{Quote hidden}

It will definitely help me. If you don't mind, I'd love to have a peek.

> Pick away.
I started in the first paragraph already. Hehehe.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
EraseMEtjaartspamspamspamBeGonewasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
| Mobile : RemoveMEtjaartKILLspamspamsms.wasp.co.za  (160 text chars) |
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\14@084750 by Walter Banks

picon face
> >
> > At 50 MIPs I think it could compensate for the fact that it will be
> > bit-banged.
>
> It will. However I don't think you'll get the full 10 to 15 Mhz available
> bandwidth bit banging.

A two or three byte cache and a software SPI would likely give
surprising performance on any processor using some form of
byte code interpreter.  This can be organized as the logical
equivalent to pipelining on a microcoded processor. (A new
instruction set is born) If the SPI is implimented as a interrupt
driven backgound task then fetches are interleaved with
byte code interpretation.

We have directly supported user defined memory devices
for quite a while in our products. Small buffers an offer a
termendous performance boost.

Walter Banks
http://www.bytecraft.com

1999\05\14@143849 by Byron A Jeff

face picon face
{Quote hidden}

Now that's a good idea. This is similar to the plan I had for higher
performance NPCI (Nano-Pseudo-C-Interpreted) boards. In short read the
entire program into a parallel RAM then run the program from the RAM. My
prototype was going to use a 32k static RAM and a 74HC573 latch just like
the 875X series does. I can live with a 19 pin memory interface when the
objective is to process tokens as quickly as possible. The reason for
continuing to load from the EEPROM is programming consistency. That way the
programming board can program both small low power boards and the bigger
high performance boards.

I think the advantage of your approach is that typically the serial interfaces
to the EEPROMS allow for sequential access without having to reload the address
of the byte read. So by setting up one address then reading 10 tokens you can
save up to 30 bytes of command/address loads.

> > Understood. However you could possibly examine my bytecode set and desi=
> gn
> > decisions to get a basis for designing your own.
> It will definitely help me. If you don't mind, I'd love to have a peek.

I think I wrote up a summary for my students. Will have to go looking for it
though. Will let you know...

BAJ

1999\05\16@091602 by Claudio Rachiele IW0DZG

flavicon
face
Antonio, pls send me a copy of your parser. I use FED BASIC 74 too.
TIA

                      Claudio Rachiele IW0DZG

1999\05\16@141935 by Mark Willis

flavicon
face
Andy Kunz wrote:
>
> At 10:42 AM 5/13/99 -0400, you wrote:
> >>
> >> They are not hard to write quite fun actually.
> >>
> >> > What sort of real nasties should be avoided?
> >>
> >> Interrupts : }}
> >
> ><snipped>
> >instruction fetch loop.
>
> WAKE UP GUYS!  It was a FUNNY!  WIthout interrupts, a Scenix is just a 4X
> PIC16C57!!!!
>
> No virtual peripherals!
>
> Andy

 <G>  But, Andy, isn't having a sense of humor OT on the PICList?  <G>

 One thought I'd add in this thread (beside from teasing everyone!) is
that if you parallel several AT45D081's (for example) and use each one
for a separate task, you can use one buffer as a scratch RAM buffer in
each unit.  !CS is a good pin to use here <G>

 Another Atmel DataFlash clue:  You can interconnect SO and SI;  Saves
one PIC pin.

 Mark

1999\05\17@012303 by Tjaart van der Walt

flavicon
face
Byron A Jeff wrote:

> I think the advantage of your approach is that typically the serial interfaces
> to the EEPROMS allow for sequential access without having to reload the address
> of the byte read. So by setting up one address then reading 10 tokens you can
> save up to 30 bytes of command/address loads.
I also want to use the IO for digital&analogue IO, and maybe a soft UART or two.

>
> > > Understood. However you could possibly examine my bytecode set and desi=
> > gn
> > > decisions to get a basis for designing your own.
> > It will definitely help me. If you don't mind, I'd love to have a peek.
>
> I think I wrote up a summary for my students. Will have to go looking for it
> though. Will let you know...
Aaaaah. This is great! I hate to go some else's code trying to figure
out what they did, if what I really want to know, is *why* they did it.

Sample code wastes time. Pseudo code, or text explanations save time.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
tjaartSTOPspamspamspam_OUTwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|             Cellpoint Systems SA                 |
|             http://www.cellpt.com                |
|--------------------------------------------------|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\17@065816 by Peter van Hoof

flavicon
face
[big snip]
>Aaaaah. This is great! I hate to go some else's code trying to figure
>out what they did, if what I really want to know, is *why* they did it.
>
>Sample code wastes time. Pseudo code, or text explanations save time.
>
>--
>Friendly Regards          /"\



This all depends on how the code is documented and with what other purpose
you look at the code. for someone inexperienced it can be enlightning to see
HOW someone else codes a particular structure. the neat tricks etc.

also ....well documented code should be easy reading.

1999\05\17@093742 by Andy Kunz

flavicon
face
>  <G>  But, Andy, isn't having a sense of humor OT on the PICList?  <G>

No, talking seriously about PICs is OT.

Andy

==================================================================
  Montana Design Tech Support - http://www.montanadesign.com
==================================================================

1999\05\17@183123 by John Payson

flavicon
face
> If I get 1 Mtip (million token instructions per minute), I'll be very hap=
> py.=20
> I was thinking of 'pipelining' as many tokens as possible. Basically I'll=
> =20
> just load, say 10 tokens instead of 1. If the program branches out of the=
> =20
> cached tokens, I will have to reload.

|I think the advantage of your approach is that typically the serial interfaces
|to the EEPROMS allow for sequential access without having to reload the address
|of the byte read. So by setting up one address then reading 10 tokens you can
|save up to 30 bytes of command/address loads.

If you're using bit-banged access to the code-store EEPROM, I don't see
any real advantage to prefetching data.  It would certainly be worthwhile
to take advantage of I2C sequential access, but this could simply be done
by having the read_memory routine check the current address against the
requested address.  If they match just do a read_byte rather than doing
the full addressing sequence.  Beyond that, though, what do you save?

By contrast, if one is using a PIC with built-in SPI hardware to help
with the EEPROM accesses (and even SPI hardware could help if data-in and
data-out were tied together) having a one-byte readahead could be quite
useful since 8 of the 9 clocks for each byte could be handled in hardware
while software was processing the previous byte.

BTW, another suggestion for speeding up the interpreter: use four I2C
devices with a shared clock wire and seperate data wires.  This would
allow 32 bits of data to be read much faster than with a single device.
The one caveat would be that all accesses (reads and writes) would be
32 bits wide (for fastest access, each byte would be stored as two bits
on each device).  This caveat aside, though, the much-improved data
speed should make that method pretty quick.



Attachment converted: wonderland:WINMAIL.DAT (????/----) (00006F11)

1999\05\18@004515 by Tjaart van der Walt

flavicon
face
John Payson wrote:
> By contrast, if one is using a PIC with built-in SPI hardware to help
> with the EEPROM accesses (and even SPI hardware could help if data-in and
> data-out were tied together) having a one-byte readahead could be quite
> useful since 8 of the 9 clocks for each byte could be handled in hardware
> while software was processing the previous byte.

Hmmm. The original gist of it got lost somewhere...;)
I want to bit-bang an *SPI* memory from an *SX*. I2C is
nice&easy, but SPI is faster. I'll run the SX at full
50Mips. I want to get away from the hardware peripherals.
If I manage to do that, future projects will be immune to
lack of it ("but it only has one UART, snif, snif")

I am looking at Ramtron's FRAM at the moment (thanks, Andy),
because it can read and write at 2.1Mbits. The only disadvantage
is the max memory size (4kbits) of these parts.

> BTW, another suggestion for speeding up the interpreter: use four I2C
> devices with a shared clock wire and seperate data wires.  This would
> allow 32 bits of data to be read much faster than with a single device.
> The one caveat would be that all accesses (reads and writes) would be
> 32 bits wide (for fastest access, each byte would be stored as two bits
> on each device).  This caveat aside, though, the much-improved data
> speed should make that method pretty quick.

It is definately a good idea. It could even be expanded further.
The bottleneck of the project at the moment is the SPI RAM.
It seems that it can be pretty pricey...


>                   Name: WINMAIL.DAT
>    WINMAIL.DAT    Type: unspecified type (application/octet-stream)
>               Encoding: x-uuencode
Hey John, do you know about this little cyber turd dragging behind your mail?

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
spamBeGonetjaartSTOPspamspamEraseMEwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|             Cellpoint Systems SA                 |
|             http://www.cellpt.com                |
|--------------------------------------------------|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\18@220911 by ShadeDemon

picon face
Tjaart van der Walt wrote:
>
> I am looking at Ramtron's FRAM at the moment (thanks, Andy),
> because it can read and write at 2.1Mbits. The only disadvantage
> is the max memory size (4kbits) of these parts.
>

 Hmm, I thought the other major drawback to these was that
reads cause wear as well as writes.  May have been improved
and not be a problem now, but at 50 MHz you could run into
that wall if it's still there..
Alan

1999\05\19@004959 by Tjaart van der Walt

flavicon
face
Alan King wrote:
>
> Tjaart van der Walt wrote:
> >
> > I am looking at Ramtron's FRAM at the moment (thanks, Andy),
> > because it can read and write at 2.1Mbits. The only disadvantage
> > is the max memory size (4kbits) of these parts.
> >
>
>   Hmm, I thought the other major drawback to these was that
> reads cause wear as well as writes.  May have been improved
> and not be a problem now, but at 50 MHz you could run into
> that wall if it's still there..

They are rated for 1E10 write cycles! Walter suggested that
the SPI reads be done by the ISR in the background, so it
will interleave with the execution of it. I don't think
I'll be able to read the SPI at much more than 1Mbit/s.
Maybe even less.

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
KILLspamtjaartspamBeGonespamwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|             Cellpoint Systems SA                 |
|             http://www.cellpt.com                |
|--------------------------------------------------|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\19@152112 by ShadeDemon

picon face
Tjaart van der Walt wrote:

> >   Hmm, I thought the other major drawback to these was that
> > reads cause wear as well as writes.  May have been improved
> > and not be a problem now, but at 50 MHz you could run into
> > that wall if it's still there..
>
> They are rated for 1E10 write cycles! Walter suggested that
> the SPI reads be done by the ISR in the background, so it
> will interleave with the execution of it. I don't think
> I'll be able to read the SPI at much more than 1Mbit/s.
> Maybe even less.

 That's writes **AND READS**, not just writes.  With a
tight wait loop, you could probably run into that.  10
billion may not be that large if you're starting from the
100kHz+ range.  At 1 MHz reading one location that's 10,000S
or ~3 hrs before you are past their rating.  Spread across
10 locations for a tight loop and that's a little more than
a day.  Or even 100 for a small program (or the commonly
executed parts of a larger program) would have an even
better chance of one out of the 100 failing within 10 days.
And that's assuming that their guesstimate of 10B is
correct.  Wouldn't be too surprising if one out of the 100
died before that.  Even a 1k not looping program would only
get 100 days.  At first I was going to say that "Long as you
cache tight loops in the Scenix you should be ok, but it's
not indefinite use like RAM..", but after thinking about it
more that 1k hits hard.  That's not a tight loop, but you
can still expect it to fail in <6 months at 1 MHz.
Definitely not RAM!
Alan

1999\05\20@004822 by Tjaart van der Walt

flavicon
face
Alan King wrote:
>
> Tjaart van der Walt wrote:
>
> > >   Hmm, I thought the other major drawback to these was that
> > > reads cause wear as well as writes.  May have been improved
> > > and not be a problem now, but at 50 MHz you could run into
> > > that wall if it's still there..
> >
> > They are rated for 1E10 write cycles! Walter suggested that
> > the SPI reads be done by the ISR in the background, so it
> > will interleave with the execution of it. I don't think
> > I'll be able to read the SPI at much more than 1Mbit/s.
> > Maybe even less.
>
>   That's writes **AND READS**, not just writes.  With a
> tight wait loop, you could probably run into that.  10

I RTFM'ed, and you are perfectly right. It is a feature
carefully hidden in one of the datasheets. Oh well.

I wondered why everybody wasn't using the technology....

--
Friendly Regards          /"\
                         \ /
Tjaart van der Walt        X  ASCII RIBBON CAMPAIGN
EraseMEtjaartspamEraseMEwasp.co.za  / \ AGAINST HTML MAIL
|--------------------------------------------------|
|             Cellpoint Systems SA                 |
|             http://www.cellpt.com                |
|--------------------------------------------------|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

1999\05\20@132719 by ShadeDemon

picon face
Tjaart van der Walt wrote:
> >   That's writes **AND READS**, not just writes.  With a
> > tight wait loop, you could probably run into that.  10
>
> I RTFM'ed, and you are perfectly right. It is a feature
> carefully hidden in one of the datasheets. Oh well.

 Yeah they do stress the "high endurance" a lot even though
it isn't exactly apples to apples vs eeproms.  But then
again they are superior for almost every other use..  Still
might even be the best thing for what you're doing, just
keep the read speed down a bit to make the life reasonable.
Only real question then is the stats on failure, is one
location likely to fail long before the others, or do they
all make it to 10B and then fall apart?
 About a year away, but at abcnews.com in the tech section,
Hitachi and Cornell U have apparently got something using a
transistor and a second transistor instead of cap like DRAM,
and got leakages etc down enough that it's NV.
Alan

More... (looser matching)
- Last day of these posts
- In 1999 , 2000 only
- Today
- New search...