Searching \ for '[PIC]: 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/microchip/devices.htm?key=pic
Search entire site for: 'Parser'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Parser'
2003\05\28@103209 by Carlos Ojea

flavicon
face
Hello:

I want to implement a 'action table' stored in eeprom. PIC reads the
table in order to execute 'actions'.
Example of an action: If ((Var1 & Var2)&(Var3<0x0C)) Then DoSomething.

¿Someone knows where could I find a Lex&Yacc to do a parser for PIC18?

Thanks,
Carlos

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\05\28@104055 by Spehro Pefhany

picon face
At 04:28 PM 5/28/2003 +0200, you wrote:
>Hello:
>
>I want to implement a 'action table' stored in eeprom. PIC reads the
>table in order to execute 'actions'.
>Example of an action: If ((Var1 & Var2)&(Var3<0x0C)) Then DoSomething.
>
>¿Someone knows where could I find a Lex&Yacc to do a parser for PIC18?

Lex and Yacc (bison, flex, PCCS, etc.) just output vanilla C code, but it's
not likely to be ideal for microcontrollers.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\05\28@130527 by Ofer Saferman

flavicon
face
Hi,

Lex and Yacc are general parsers and can be made to output anything you want
in response to an input stream. I think there is a version for Windows that works
in DOS console mode. Try maybe simtelnet.

*********** REPLY SEPARATOR  ***********

On 28/05/2003 at 10:41 Spehro Pefhany wrote:

{Quote hidden}

~~~~~~~~~~~oOo~~~~~~~~~~~
Ofer Safeman, M. Sc.
Senior Design Engineer

Paragon Communications
6 Pal-Yam
Haifa, 33095
ISRAEL
Phone: +972-4-8642775
Fax: +972-4-8642737
E-Mail: oferspamKILLspamparagoncommtech.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\05\28@132604 by Spehro Pefhany

picon face
At 08:11 PM 5/28/2003 +0200, you wrote:
>Hi,
>
>Lex and Yacc are general parsers and can be made to output anything you want
>in response to an input stream. I think there is a version for Windows
>that works
>in DOS console mode. Try maybe simtelnet.

Lex, Yacc et al. are NOT parsers, they are parser generators.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam.....interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\05\28@185737 by Tal
flavicon
face
True with on correction, they can *generate code* that "can be made to
output anything you want in response to an input stream". In Carlos case, this
can be used compile off line the rules from a rule oriented language he
defines to the actual run time representation (either code or data).

Tal

> {Original Message removed}

2003\05\28@185743 by Tal

flavicon
face
Carlos, what are the requirements from your systems, are the rules
static and set once or are they dynamic and can change at runtime ?

If they are static, you want to do as much as possible off line and only
save a compiled version of the rules conditions and actions. This can be
represented as data (using the proper interpreter) or as code (more
efficient and probably simpler). In both cases, you can generate them by
hand or using some compiler for a rule language you can define (and
implement using Lex, Yacc, JavaCC etc).

Try to give a more detailed description of the requirements.

Tal

> {Original Message removed}

2003\05\28@194353 by Spehro Pefhany

picon face
At 03:55 PM 5/28/2003 -0700, you wrote:
>Carlos, what are the requirements from your systems, are the rules
>static and set once or are they dynamic and can change at runtime ?
>
>If they are static, you want to do as much as possible off line and only
>save a compiled version of the rules conditions and actions. This can be
>represented as data (using the proper interpreter) or as code (more
>efficient and probably simpler). In both cases, you can generate them by
>hand or using some compiler for a rule language you can define (and
>implement using Lex, Yacc, JavaCC etc).

Maybe the parser/lexical analyzer should emit tokens for the EEPROM.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
EraseMEspeffspam_OUTspamTakeThisOuTinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2003\05\28@212656 by Tal

flavicon
face
>
> Maybe the parser/lexical analyzer should emit tokens for the EEPROM.
>
> Best regards,
>
> Spehro Pefhany --"it's the network..."            "The
> Journey is the reward"
> speffspamspam_OUTinterlog.com             Info for manufacturers:

Or, generate C/assembly code that will evaluate the conditions and
activate the actions. One good side of this approach is that you can
have the power of C in your rule language without having to develop
much.

Tal

> {Original Message removed}

2003\05\29@041057 by Carlos Ojea

flavicon
face
>Carlos, what are the requirements from your systems, are the rules
>static and set once or are they dynamic and can change at runtime ?

Rules can change at runtime. The PIC will read the data stored in
eeprom, evaluate the conditions and activate the actions (as Tal said).
But values stored in eeprom could change at runtime and PIC should
evaluate the new conditions and activate new actions.

To do this I need to store the conditions in eeprom in some format, and
make the code to evaluate them (the parser).
I think Lex & Yacc could generate C code for the parser I need, and then
I will translate that C code to PIC18 assembler.

So I want to ask if this is a good idea. Also I am looking for a Lex &
Yacc (in windows) to generate the parser I need.

Thanks you all,
Carlos

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\05\29@043841 by David VanHorn

flavicon
face
>
>To do this I need to store the conditions in eeprom in some format, and
>make the code to evaluate them (the parser).

You might try an interpreted language.
I've done this in an F84, and in the AVRs, as well as Z-80 systems.

You define some number of commands, with optional trailing parameters.
ex (hex):

00      ;nop
01      ;Set output pin high
02      ;set output pin low
03,'HI';Send string to display
04,01,80;Set servo #1 to half scale
FF,11   ;skip -4

Hard to be more specific without details.

The interpreter starts with the extraction pointer looking at the first byte, and executes it as a command.
Each interpreter has two modes, execute, and scan.
In execute, it acts on it's parms.
In scan, it simply moves the extraction pointer past it's parms.
Next time, we want the second command, so we scan the first one, and execute the second.

Each command interpreter knows what it's parameters look like, so you don't need anything extra in memory.
You keep a variable that tells you what command you're executing

In the F84 code, I was controlling a transmitter with commands like Tune, and Wait, CW'text' etc, 16 commands in all.

The code can be self modifying, and I have been thinking for some time about doing some sort of robotic project where the bot would start off with an approximately correct program, and modify it's program over time, looking for better results.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\05\29@092738 by Tal

flavicon
face
Carlos,

A good source for Unix utilities for Windows/DOS is Cygwin
(http://sources.redhat.com/cygwin/).

Some packages may be optional and you may need to select them during the
install process.

The package list at http://sources.redhat.com/cygwin/packages/ shows
Flex (Lex) and Bisin (Yacc).

As for the runtime processing of conditions and actions, I am not sure
if the PIC supports self modifying code (that is, self reprogrmming of
the Flash or running code from Ram/EEProm). If not, you will need to
find/develop some rule interpreter. My first choice would be a simple
stack oriented machine with commands like puse var X, compare two top
elements on stack, call primitive action X with optional parameters on
the stack, etc.


BTW, the stack oriented interpreter may be a general PIC project that
other here in the list will want to contribute to or use in their own
projects.

Tal

> {Original Message removed}

2003\05\29@163252 by Peter L. Peres

picon face
> I want to implement a 'action table' stored in eeprom. PIC reads the
> table in order to execute 'actions'. Example of an action: If ((Var1 &
> Var2)&(Var3<0x0C)) Then DoSomething.
>
> Someone knows where could I find a Lex&Yacc to do a parser for PIC18?

Yow. lex&yacc will generate tables that will choke most pics. They will
also not parse an expression like you show without serious help from the
programmer and a huge grammar, and worst of all, they need huge amounts of
stack to work.

You can implement what you want as bytecode in the eeprom and a bytecode
interpreter that runs in the pic and executes it. Eg. for the expression
above it would be in byte code something like (after correcting the & in
the middle to && which is likely what you wanted):

!fetch var1 !fetch var2 !and !sgn !fetch var3 !literal
0x0C !sub !sgn !and !if !literal DoSomething !acall !fi

where each word would take one EEPROM cell or more (you can compress some
of it).

!sgn assumes the stack is signed. If the stack top is zero at !if then the
intrepreter steps instructions and eats arguments until it sees !fi when
it continues to intrepret as normal. This bytecode would be compiled by a
compiler which will probably not run in a pic.

Peter

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2003\05\30@061434 by Carlos Ojea

flavicon
face
> You can implement what you want as bytecode in the eeprom and
> a bytecode interpreter that runs in the pic and executes it.
> Eg. for the expression above it would be in byte code
> something like (after correcting the & in the middle to &&
> which is likely what you wanted):
>
> !fetch var1 !fetch var2 !and !sgn !fetch var3 !literal
> 0x0C !sub !sgn !and !if !literal DoSomething !acall !fi
>
> where each word would take one EEPROM cell or more (you can
> compress some of it).

Ok, It sounds cool!
Instead of coding a complex parser it would be a good idea to store in
eeprom some commands like you explained. To do 'If ((Var1 &
Var2)&(Var3<0x0C))' I will store in eeprom something like:

PUSH  Var1
PUSH  Var2
AND
PUSH  Var3
PUSHL 0x0C
<
AND
THEN  DoSomething

I think an interpreter for this kind of commands could be implemented in
a pic18 quite easy.

Thanks!!
Carlos.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\05\30@085548 by Spehro Pefhany

picon face
At 12:12 PM 5/30/2003 +0200, you wrote:
> > You can implement what you want as bytecode in the eeprom and
> > a bytecode interpreter that runs in the pic and executes it.
> > Eg. for the expression above it would be in byte code
> > something like (after correcting the & in the middle to &&
> > which is likely what you wanted):
> >
> > !fetch var1 !fetch var2 !and !sgn !fetch var3 !literal
> > 0x0C !sub !sgn !and !if !literal DoSomething !acall !fi
> >
> > where each word would take one EEPROM cell or more (you can
> > compress some of it).
>
>Ok, It sounds cool!
>Instead of coding a complex parser it would be a good idea to store in
>eeprom some commands like you explained. To do 'If ((Var1 &
>Var2)&(Var3<0x0C))' I will store in eeprom something like:

Yes, the parsing could be done off-line on a PC and a simulated stack
machine could be coded on the PIC using bytecodes/tokens stored in the
EEPROM. I've done this (not with a PIC, but it's no different).

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
KILLspamspeffKILLspamspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\05\30@124523 by Tal

flavicon
face
If you are implementing a stack oriented interpreter, you may want to
take look at the lagnuage Forth (used to be very hot about 15 ago). Take
a look at the operators they use for expressions, stack manipulation,
flow control, etc. This will give you some ideas. I presume you can also
get a free implementation of Forth and play with it.

http://www.forth.org/

Tal

> {Original Message removed}

2003\05\30@140349 by Tim Webb

flavicon
face
I even have forth running on my HP 200lx palm top


-----Original Message-----
From: Tal [spamBeGonetalspamBeGonespamZAPTA.COM]
Sent: Friday, May 30, 2003 9:45 AM
To: TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU
Subject: Re: [PIC]: Parser


If you are implementing a stack oriented interpreter, you may want to
take look at the lagnuage Forth (used to be very hot about 15 ago). Take
a look at the operators they use for expressions, stack manipulation,
flow control, etc. This will give you some ideas. I presume you can also
get a free implementation of Forth and play with it.

http://www.forth.org/

Tal

{Quote hidden}

http://www.trexon.com
Embedded software/hardware/analog  Info for designers:
http://www.speff.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us! email
RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\05\30@141638 by Dennis J. Murray

flavicon
face
Have you ever REALLY used Forth???  I did back in the early 80's and HATED
it!!  It was fine for small jobs, but larger applications were terrible!!  I
spent more time trying to get around the order things were on the stack than
I did productive work!

To me, it had the worst qualities of Assembler and high-level languages!  I
went to a FUG (Forth Users' Group) meeting once and they had a contest to
see who could write code that no one else could figure out what it did!  The
only rule was that it had to fit on one page and you had to prove it worked
and accomplished a specific function.  Not only was there a winner - there
were several!!  Talk about a dubious honor!!!

I'll stick with Assembler and C, thank you!!  More power to you if you have
to use Forth - not my cup of tea!

Dennis


----- Original Message -----
From: "Tim Webb" <EraseMEtim_webbspamspamspamBeGoneAGILENT.COM>
To: <RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Friday, May 30, 2003 2:02 PM
Subject: Re: [PIC]: Parser


> I even have forth running on my HP 200lx palm top
>
>
> {Original Message removed}

2003\05\30@142914 by D. Jay Newman

flavicon
face
> Have you ever REALLY used Forth???  I did back in the early 80's and HATED
> it!!  It was fine for small jobs, but larger applications were terrible!!  I
> spent more time trying to get around the order things were on the stack than
> I did productive work!

Maybe it's different personalities or styles of programming. Forth was
a popular language on memory-limited machines because the parsing was
so simple. I even wrote one for a 68000 board I had.

It's a very powerful language once you get your head into the right space.

Rick Cook wrote a series of books where a master hacker used Forth as
the basis for a magical system (a hacker was "kidnapped" from our world
into a fantasy world and built his own magic compiler; the sequal had
a bunch of more traditional programmers invited over to "fix" the compiler
and make it less of a kludge). The book is called _Wizard's Bane_ and
_The Wizardry Compiled_. Knowing Forth makes these books hillarious.
--
D. Jay Newman          ! Pudge controls the weather.
jaySTOPspamspamspam_OUTsprucegrove.com    !
http://enerd.ws/~jay/  ! Oh good. My dog found the chainsaw.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservSTOPspamspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2003\05\30@150442 by Tal

flavicon
face
Not just that I used it but I also wrote an interpreter for Motorola
MC6809. ;-)

Computer languages used to be my of my hobbys so I really appreciated
the simplicity of the language and the runtime envirnoment.

From software engineering view point it was a very poor language similar
to several other cool languages (e.g. Smalltak 80 and Prolog) but it had
interesting concepts such as code that you can executed at compile time
(a super set of the 'macro' facilities avaialble in languages such as C
and ASM).

The one page concept of Forth (I think they were called 'screens') was
very limited and I believe it was selected to eliminate the need of a
real file system (that is, the disk is modeled as an array of a fixed
size binary blocks).

I just visited http://www.forth.com and interesting enough, they are still in
business. They used to be very hot and I think they even came with Forth
processors but I was really surprised to see that they are still alive
and kikking.

As for Carlos' request, if he need to implement a small stack oriented
interpreter, I think he will be able to find in Forth good idea for
affective stack operators (e.g. rot or rot3).

Tal

> {Original Message removed}

2003\05\30@155911 by William Chops Westfield

face picon face
I have found forth-like languages very simple to implement, and very
useful as a sort of minimal interpretter.  Things are further simplified
if you you pair down the functions/keywords you define to a bare minimum,
rather than trying to do a full "standard forth" implementation.  This
winds up giving you something more like an HP calculator than "real forth",
but it can be just as useful...

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2003\05\30@160447 by D. Jay Newman

flavicon
face
> I have found forth-like languages very simple to implement, and very
> useful as a sort of minimal interpretter.  Things are further simplified
> if you you pair down the functions/keywords you define to a bare minimum,
> rather than trying to do a full "standard forth" implementation.  This
> winds up giving you something more like an HP calculator than "real forth",
> but it can be just as useful...

Even implementing a standard forth is fairly easy (as long as I don't have
to do floating point... -- I haven't seen the standard in ages). I
remembering it taking me four evenings to implement it from scratch on
a 68000. OK, I cheated: I had an assembler.
--
D. Jay Newman          ! Pudge controls the weather.
EraseMEjayspamEraseMEsprucegrove.com    !
http://enerd.ws/~jay/  ! Oh good. My dog found the chainsaw.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listserv@spam@spamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2003\05\30@160822 by William Chops Westfield

face picon face
   I went to a Forth Users' Group meeting once and they had a contest to
   see who could write code that no one else could figure out what it did!

There's an "obfuscated C" contest as well, not to mention languages like APL
and TECO.  FORTH is particularly easy to parse, because what would be
complex parser issues like forward references become ... inconvenient order
of things on the stack.  Most of the time things are simplified overall,
especially for very simple programs (which is what we're talking about
here.)  I gather that the other language with similarly trivial parsing is
LISP, but I've never implemented a lisp interpretter.

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body

2003\05\30@161643 by William Chops Westfield

face picon face
Of course, today's "Postscipt" language is essentially a Forth modified
for a particular purpose...

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspam_OUTspammitvma.mit.edu with SET PICList DIGEST in the body

2003\05\30@161646 by D. Jay Newman

flavicon
face
> There's an "obfuscated C" contest as well, not to mention languages like APL
> and TECO.  FORTH is particularly easy to parse, because what would be

Ahhh, TECO. A language that is indistinguishable from line noise. I've
seen some amazing things done in TECO, but even I stayed away from it.  :)
--
D. Jay Newman          ! Pudge controls the weather.
TakeThisOuTjay.....spamTakeThisOuTsprucegrove.com    !
http://enerd.ws/~jay/  ! Oh good. My dog found the chainsaw.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservKILLspamspamspammitvma.mit.edu with SET PICList DIGEST in the body

2003\05\30@180309 by Spehro Pefhany

picon face
At 04:09 PM 5/30/2003 -0400, you wrote:
> > There's an "obfuscated C" contest as well, not to mention languages
> like APL
> > and TECO.  FORTH is particularly easy to parse, because what would be
>
>Ahhh, TECO. A language that is indistinguishable from line noise. I've
>seen some amazing things done in TECO, but even I stayed away from it.  :)

I'm sure one could prove theoretically that the most efficient languages
in terms of keystrokes must resemble line noise. ;-)

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffspamRemoveMEinterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

2003\05\31@053111 by Peter L. Peres

picon face
> Have you ever REALLY used Forth???  I did back in the early 80's and
> HATED it!!  It was fine for small jobs, but larger applications were
> terrible!!  I spent more time trying to get around the order things were
> on the stack than I did productive work!

Imho forth is a good machine language, but not necessarily for human
consumption. It can be useful. You do not have to write programs in forth,
any structured higher level language can be translated into forth. For
example one can modify the code generator of a c compiler to generate
forth.

The only trick I know to remove the pain from forth programming is to
write strongly indented code (unlike most forth examples) and to keep the
number of items on the stack accessed by a subroutine under 10,
preferrably under 5. Also to use index instead or rot etc. This makes for
short subroutines and more readability.

Peter

--
http://www.piclist.com hint: To leave the PICList
spamBeGonepiclist-unsubscribe-request@spam@spamspam_OUTmitvma.mit.edu>

2003\05\31@093515 by Dave VanHorn

flavicon
face
>>
>>Ahhh, TECO. A language that is indistinguishable from line noise. I've
>>seen some amazing things done in TECO, but even I stayed away from it.  :)

B1.1GJ'BCAKE'RM

Or the first program written in this language for a customer:

MNL

Which could have been improved to MNV....1NL

--
http://www.piclist.com hint: To leave the PICList
TakeThisOuTpiclist-unsubscribe-requestspamspammitvma.mit.edu>

2003\05\31@203356 by Olin Lathrop

face picon face
> If you are implementing a stack oriented interpreter, you may want to
> take look at the lagnuage Forth (used to be very hot about 15 ago).

Forth has a single advantage in that the interpreter core is very small and
relatively easy to implement.  I've written two Forth interpreters, one on a
general purpose computer and one on an old fashioned graphics controller
("video card" for you young'uns, although back then it did 512 x 512, was
rack mounted, and cost around $20,000).  I started down this road because
the graphics box customers occasionally wanted to add some custom
programming to the box, and Forth sounded like a nice solution.

I've programmed in lots of different languages on lots of different
computers, and I think I'm pretty good at it.  However, I found Forth
cumbersome.  At first I thought it would just take some getting used to the
different stack-oriented mindset.  I wrote a few programs, like a prime
number generator and one on the graphics box to apply arbitrary transforms
to the mouse input (we thought it was great fun to rotate all the mouse
coordinates 15 degrees on the field service guy's machine and not tell him).

After playing with it a bit I came to the conclusion that a Forth
interpreter might be a good way to allow customer "programming" of embedded
equipment, but you don't want the customer to see the Forth.  Give him an
intuitive programming interface on a real computer, then "compile" into
Forth if necessary.  Of course if you do that, you could just as well
implement a pseudo code interpreter that maps better to the customer-visible
language.  The only place I know of where a Forth-like language is still in
common use is PostScript.  Note that you almost never write the postscript
yourself.  You generally edit a document is a way totally removed from the
PostScript details.  There's a good reason for that.

We eventually decided that the few extra sales we might lose by not having a
programmable graphics controller wasn't worth the support cost.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestEraseMEspammitvma.mit.edu>


'[PIC]: Parser'
2003\06\01@145949 by Peter L. Peres
picon face
A more small-lcd-on-crummy-cpu-with-tiny-keys way to do this would be:

- Use a menu style entry
- Each event would be selectable from a list
- With each event the user can:
1) add a condition between two variables or a variable and a constant
1a) enter the variable (by choosing from a list)
1b) enter the condition (by choosing from another list)
1c) enter the 2nd variable (by choosing from a list with a constant as an
extra option)
1c1) enter a constant if necessary
repeat at 1) to add more conditions
or
2) review conditions etc
3) delete ...

All the conditions for an event would be and-ed together, if the result is
a 1 then you do the action. You can use suitable logic for the conditions
(!= == > >= < <= & | ^) to achieve whatever goal you wish (using Moore's
laws etc). This of course requires that the user know how to program and
understands logic. This may be a tall order.

This should compress fairly well, assuming you have a few actions (say 16)
and up to 16 condition pairs one byte could compress the action and the
length of the condition vector and then assuming 16 variables, one byte
for the condition and the variable and the second for a variable or a
constant. This is fairly compact. Your example could be represented on 5
bytes of eeprom and the interpreter would be fairly compact and simple to
write.

You need to clarify who is going to use this. This looks like vcr timer
programming. vcr timer programming does not look good to normal humans
(or to me).

Peter

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2003\06\02@035608 by Wouter van Ooijen

face picon face
> I went to a FUG (Forth Users' Group) meeting once and they had
> a contest to see who could write code that no one else could
> figure out what it did!
>
> I'll stick with Assembler and C, thank you!!

Actually such contests in C are much more widespread, google for
'obfusciated C contest'. And in assembler it does not need any extra
effort ;)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

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