Searching \ for '[OT:] Vapourware finite state machine compiler' 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=vapourware+finite
Search entire site for: 'Vapourware finite state machine compiler'.

Exact match. Not showing close matches.
PICList Thread
'[OT:] Vapourware finite state machine compiler'
2004\03\13@101323 by Anthony Toft

flavicon
face
A ways back there was some discussion on the use of finite state
machines (FSM) in designing software for the PIC.

I have been thinking about writing a compiler for the PIC basically
since I started messing with them, but there are several out there or in
the works...

So I have decided to make an FSM compiler, you define the FSM in a
structured language, and the resulting ASM makes the pic behave as
described.

Is there any need for this? If there is and you'd use it, what would you
like to see in it? What language would you like to see it modeled on (C,
Pascal)? How would you like it to look (file structure)? What features
would you like to see?

Anthony
--
Anthony Toft <spam_OUTtoftatTakeThisOuTspamcowshed.8m.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

2004\03\13@103555 by Jim Tellier

picon face
Anthony Toft wrote:
> A ways back there was some discussion on the use of finite state
> machines (FSM) in designing software for the PIC.
> I have been thinking about writing a compiler for the PIC basically
> since I started messing with them, but there are several out there or in
> the works...
> So I have decided to make an FSM compiler, you define the FSM in a
> structured language, and the resulting ASM makes the pic behave as
> described.
> Is there any need for this? If there is and you'd use it, what would you
> like to see in it? What language would you like to see it modeled on (C,
> Pascal)? How would you like it to look (file structure)? What features
> would you like to see?

I've also toyed with this idea, but never had the time to carry it out.
Some time ago, I used a VHDL-generating tool that had FSM description as one
of its input schemas.  (can't recall the product name at the moment, but
it's not that important).  It provided a simple graphic capability for
drawing "bubbles" and "arcs", attaching labels to them, etc.  You'd click
the "OK" button, and voila--- instant VHDL module.
Personally, I think this is the way to do state-machine design: you *need*
the graphic representation so you can visually relate to the functionality
you are trying to define.  If you try to describe FSMs in some form of
procedural "code" (C, Pascal, asm, etc), your brain has to perform the
"mapping" (from bubbles & arcs) to code.  It's error prone and tedious
coding, no matter what the language.
 If you're not in a super big hurry to get this done, I might be willing to
collaborate on such a project.   Contact me offline if you want to
brainstorm a bit!
 Jim
.....jimtellierKILLspamspam@spam@cox.net

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

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

2004\03\13@225253 by Jake Anderson

flavicon
face
I'd be interested in knocking up a GUI (i always want to write gooey ;->)
for it



-----Original Message-----
From: pic microcontroller discussion list
[PICLISTspamKILLspamMITVMA.MIT.EDU]On Behalf Of Jim Tellier
Sent: Sunday, March 14, 2004 2:33 AM
To: .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
Subject: Re: [OT:] Vapourware finite state machine compiler


Anthony Toft wrote:
{Quote hidden}

I've also toyed with this idea, but never had the time to carry it out.
Some time ago, I used a VHDL-generating tool that had FSM description as one
of its input schemas.  (can't recall the product name at the moment, but
it's not that important).  It provided a simple graphic capability for
drawing "bubbles" and "arcs", attaching labels to them, etc.  You'd click
the "OK" button, and voila--- instant VHDL module.
Personally, I think this is the way to do state-machine design: you *need*
the graphic representation so you can visually relate to the functionality
you are trying to define.  If you try to describe FSMs in some form of
procedural "code" (C, Pascal, asm, etc), your brain has to perform the
"mapping" (from bubbles & arcs) to code.  It's error prone and tedious
coding, no matter what the language.
 If you're not in a super big hurry to get this done, I might be willing to
collaborate on such a project.   Contact me offline if you want to
brainstorm a bit!
 Jim
EraseMEjimtellierspam_OUTspamTakeThisOuTcox.net

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

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

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

2004\03\14@054705 by Stef Mientki

flavicon
face
hi Anthony,

I love the idea, not only for PICs, but also for all kind off other
programm generating (PICs, Windows, Delphi, PHP, Java, ASP,
hardware-design, process-flow in organizations ,...).
When I think of FSM, a graphical user interface is a *must* in my opinion.

Without graphical user-interface / presentation FSM it's just another
tool for technician,
not any better then the current programming languages.

With a graphical user interface / presentation, FSM becomes a tool that
brings a technician and the end-user much closer to each other. A
graphical FSM can be understood and made by non-technicians !
(Oh oh, ... now no one in this newsgroup will favor for FSM anymore ;-)
Besides that, with a graphical FSM, documentation of a project is almost
done automatically.

There will always be some (small) parts which are not covered very well
by FSM,
so you still have to dig into the language/structure below. But that
yields for every higher abstraction level.
For PICs I use JAL, and I always write the complete functionality first
in JAL. Then when resource demand is too high (either time or spcae), I
convert small parts into streamlined assembler.

Making my own FSM is still on my wishlist (because I cann't find the
tool I would like to have),
so maybe I could be of some help.
What operating systems should the FSM work on ?
What kind of license are you thinking of ?
(What kind of tools do you have in mind for developping the FSM ?)

Stef Mientki

Anthony Toft wrote:

{Quote hidden}

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

2004\03\14@094106 by Sergio Masci

picon face
Anthony Toft wrote:

> A ways back there was some discussion on the use of finite state
> machines (FSM) in designing software for the PIC.
>
> I have been thinking about writing a compiler for the PIC basically
> since I started messing with them, but there are several out there or in
> the works...
>
> So I have decided to make an FSM compiler, you define the FSM in a
> structured language, and the resulting ASM makes the pic behave as
> described.

This is like defining a high level language based on the capabilities of the
machine code of the processor, when what you really want to do is define a high
level language based on the needs of the human programmer. In the first instance
you end up with an assembler, in the second you end up with a high level
language like PASCAL, LISP or SQL.

FSM is one of the few programming techniques that really should be implemented
in a graphical programming language. State diagrams cut through all the BS and
hard to visualise interactions in an FSM. Trying to visualise a non trivial FSM
without the use of state diagrams is like trying to read with your eyes closed.

There are many state machine compilers, libraries and tools available on the
net. I strongly recommend you play with a few and find out what their strengths
and weaknesses are before you decide to embark on this. If your tool is not
going to be at least as good as these you may as well use one of these instead.

>
> Is there any need for this? If there is and you'd use it, what would you
> like to see in it? What language would you like to see it modeled on (C,
> Pascal)? How would you like it to look (file structure)? What features
> would you like to see?
>
> Anthony

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

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

2004\03\14@094108 by Sergio Masci

picon face
Jim Tellier wrote:

{Quote hidden}

Go for it Jim! You really need to use state diagrams as a programming method for
state machines. But don't forget if this is to be a proper programming system
you will also need some kind of debug support. You will want to be able to trace
events and state transitions on the diagram - source level debug your state
machine.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

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

2004\03\14@094727 by Wouter van Ooijen

face picon face
> FSM is one of the few programming techniques that really
> should be implemented in a graphical programming language.

I disagree:

1. A non-trivial state machine contains, beside the state-stuff itself,
a lot of plain and (not so) simple code. I don't see how anything but a
HLL (for asm lovers: assembler) would be usefull for that part.

2. A non-trivial state machine contains far too many states, events and
transitions to be reasonably represented in a graphical way. Think
10..20 states, same number of events.

Wouter van Ooijen

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

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

2004\03\14@131648 by Jim Tellier

picon face
> > FSM is one of the few programming techniques that really
> > should be implemented in a graphical programming language.
>

Wouter van Ooijen wrote:
> I disagree:
> 1. A non-trivial state machine contains, beside the state-stuff itself,
> a lot of plain and (not so) simple code. I don't see how anything but a
> HLL (for asm lovers: assembler) would be usefull for that part.
>
Of course, once you get down into the *implementation* of what each
particular state represents and how it processes each "event" or condition
that it's supposed to react to... you'll have to deal with code (C, C++,
asm, whatever); that's a given.   But the _design_ of the FSM absolutely
doesn't have to be done at such a low level as to be tedious!  I've done
many such designs, and only proceed to write code after I've debugged the
"logic" on paper, with "bubbles" and "arcs" and "labels", using my brain
before getting near the simulator/emulator.  Sure, you can take what's in
your head and map it directly to code; but it's much more tedious and error
prone.

> 2. A non-trivial state machine contains far too many states, events and
> transitions to be reasonably represented in a graphical way. Think
> 10..20 states, same number of events.
 I will beg to differ on this, having developed many pieces of software
using FSM approaches.  The most recent that I did was a piece of
photographic equipment with interfaces to several buttons, sensors, display
and timers.  The state machine consists of 9 major states, each of which
breaks down into it's own FSM, some of which have 3 or 4 states, others up
to 8 states.  So there you've got about 60 unique states.  It's all
represented on about 10 pages of Visio documentation.  By careful choice of
naming convention, I can go from the diagram directly to the piece of code
that implements it.   It would have been VERY difficult (for me, anyway) to
"directly" capture this design in PIC asm without drawing it out very
methodically and debugging on paper first.
 In the pure "software" realm, I was a principal developer of a logic/fault
simulation tool when I was at DEC.  The kernel was designed as a FSM, with
30 major states and 256 event types.   Implementation was a HLL.  The
documentation (since we didn't have fancy tools then) covered 4 walls of a
12x12 room; without the visual representation, we'd *still* be there arguing
about how it should work! :^)
 The ASIC design groups I've worked with in the past have all used graphic
input tools rather than directly coding, even VHDL... which is in its own
right very adept at representing FSMs.  Why? because it's easier to draw
pictures and validate them (esp. as a team) and have the code generated by
the tools, than it is to plod throught it "manually".

I'm enthused about the idea that Anthony put forth!  I think there's a lot
of merit in "abstracting" those pieces of the design process that lend
themselves to it: FSM design is definitely one of those!

Jim

>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: http://www.voti.nl
> consultancy, development, PICmicro products
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

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

2004\03\14@143033 by Sergio Masci

picon face
Wouter van Ooijen wrote:

> > FSM is one of the few programming techniques that really
> > should be implemented in a graphical programming language.
>
> I disagree:
>
> 1. A non-trivial state machine contains, beside the state-stuff itself,
> a lot of plain and (not so) simple code. I don't see how anything but a
> HLL (for asm lovers: assembler) would be usefull for that part.

I agree with you on this. I did not mean that every aspect of the programming
proceadure should be done using diagrams. Yes write A=B+2 where it is
appropriote but use diagrams to program the relationships between the states and
events. The event transition and monitor functions can be written in anything
you like.

>
> 2. A non-trivial state machine contains far too many states, events and
> transitions to be reasonably represented in a graphical way. Think
> 10..20 states, same number of events.

I disagree here. A large system consisting of hundreds of states and thousands
of events can be much more easily managed using an appropriate tool. Think of a
large silicon chip with huge numbers of features. scroll around, zoom in. Same
with a huge state diagram. Also with the right tools you can build small state
machines, test them then use them as components in larger state machines.

I have worked on systems that have had tens of states and hundreds of events
which although they were described as state machines - were anything but. Large
state machines are very hard to verify and often people take short cuts because
they need a quick fix. These systems degenerate into a collection of hacks and
the documentation becomes almost useless. If you use the right tools you don't
have to resort to short cuts, you can add a few more states and events in the
time it takes you to draw a few boxes, add a couple of lines and type in the
names.

Have a look at
www.xcprod.com/titan/ZMECH-DOC/generate/state-machine/block-indx.html
34 states and 88 events. The diagram shows a multimaster I2C system. It would
look better on the screen if you shrank it down and scrolled and zoomed but that
defeats the objective of presenting it as a html image with anotated hot spots.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising structured PIC BASIC compiler

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

2004\03\14@150636 by Peter L. Peres

picon face
I have been working on ideas wrt $SUBJ on and off. The first step was to
see what is available. There are three tools mentioned in the Magic
documentation that do what you want (they actually go till synthesis in
silicon using Magic). The syntax is also exemplified there.

The problem is, you have the syntax, you make code from it, then what ?
Due to optimization each state machine must be practically rewritten by
hand for each micro it runs on. Also requirements are different, input
sources can change, you usually can't afford to read all inputs and mask
what is not needed etc etc.

Peter

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

2004\03\14@152952 by Jim Tellier

picon face
Peter L. Peres wrote:
>...
> The problem is, you have the syntax, you make code from it, then what ?
> Due to optimization each state machine must be practically rewritten by
> hand for each micro it runs on. Also requirements are different, input
> sources can change, you usually can't afford to read all inputs and mask
> what is not needed etc etc.

This is completely analogous to writing a <insert-language-of-choice-here>
compiler that targets multiple devices and/or architectures.  It's generally
attacked by having good modularity and separation of the "front end" (e.g.
syntax, parsing or graphic input, etc) from the "back end" (code-generation
and optimization).  Standard stuff.  To handle most of what would be
required for state machine execution in the PIC domain, I'd suggest that a
very small common instruction subset could be employed that would "cover"
multiple families (perhaps not "all", but what couldn't be common should be
addressed by a "choice" of back-end module.
As far as "input sources could change", I'm not sure what you meant by that.
Jim
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

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

2004\03\14@154239 by Wouter van Ooijen

face picon face
>   I will beg to differ on this

And I still don't agree with you, but I am always open to new insights.
I am not a fan of any 'tooling' on top of my HLL, but I will at least
give it a try when it is available :)

Wouter van Ooijen

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

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

2004\03\14@164338 by David P Harris

picon face
Hi All-
Well, if you are going to write it, I suggest that you keep the
structure in XML.  The GUI would translate this to the display, and
manipulate it.  Any compilers could use XSLT to transform the XML in the
appropriate language.
David
PS- I only know a tiny bit about all this, but it is a nice standard to
aspire to.
XML = "Extensible Markup Language", like HTML except you can define your
own tags. For example OpenOffice uses XML as its document format, which
is cool because it a) has an open document format specification so you
can work with it, and b) you can use XML tools to work with it.
XSLT = "XML Stylesheet Language Transformation". XSL is a language that
is used to transform documents in XML into some other form, like HTML or
PDF or whatever you want.




Stef Mientki wrote:

{Quote hidden}

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

2004\03\14@201300 by D. Jay Newman

flavicon
face
> Hi All-
> Well, if you are going to write it, I suggest that you keep the
> structure in XML.  The GUI would translate this to the display, and
> manipulate it.  Any compilers could use XSLT to transform the XML in the
> appropriate language.

I've thought of making a behavioral description language for robotics
using XML.
--
D. Jay Newman           !
RemoveMEjayTakeThisOuTspamsprucegrove.com     ! Xander: Giles, don't make cave-slayer unhappy.
http://enerd.ws/robots/ !

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

2004\03\15@012312 by Jim Tellier

picon face
David P. Harris wrote:
> > Hi All-
> > Well, if you are going to write it, I suggest that you keep the
> > structure in XML.  The GUI would translate this to the display, and
> > manipulate it.  Any compilers could use XSLT to transform the XML in the
> > appropriate language.
>
and D. Jay Newman replied:
> I've thought of making a behavioral description language for robotics
> using XML.

Well, the XML notion was already in the back of my mind...I've been
targeting a lot of projects to use XML representation.  But the XSLT
variants to do the "back end" targeting--- that's a good idea!  This is
sounding like a fun project already!  I've not done anything significant
with XSLT, so I'll need to get past that learning curve, but the XML and XSD
aspect seems intuitive enough.   Anybody have compiler code-generator
experience & XSLT?  Let's talk!
Jim
--
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

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

2004\03\15@054950 by Walter Banks

picon face
It might be easier to compile to a language like C so that the implementation
details
of the target processor can be handled by the C compiler. That way the
implementation
can at least initially be focussed on the implementation of the FSM.

w..


Jim Tellier wrote:

>  To handle most of what would be
> required for state machine execution in the PIC domain, I'd suggest that a
> very small common instruction subset could be employed that would "cover"
> multiple families (perhaps not "all", but what couldn't be common should be
> addressed by a "choice" of back-end module.

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

2004\03\15@072403 by Alan B. Pearce

face picon face
I found about 3 good looking FSM compilers using "state machine compiler" as
search criteria in Google. One of them is a sourceforge effort, and I would
suggest hooking into that effort if going to do anything serious.

>XML = "Extensible Markup Language", like HTML except you can
>define your own tags. For example OpenOffice uses XML as its
>document format, which is cool because it a) has an open
>document format specification so you can work with it, and
>b) you can use XML tools to work with it.

<grin> when I first read this bit, I read it as "Microsoft Office" instead
of "Openoffice", and was going to comment on the M$O bit. It would seem that
the possibility is Microsoft Office will be using "Microsoft XML" the way
Frontpage generates "Microsoft HTML" and not be standard to anyone else. Now
looking at your comment as being Openoffice it probably is not a problem.

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

2004\03\15@224659 by David P Harris

picon face
Here is a description of XML for a state machine (for use in robotics):
robotflow.sourceforge.net/documents/FSMDescription.pdf
David

D. Jay Newman wrote:

{Quote hidden}

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

2004\03\16@130853 by Stef Mientki

flavicon
face
David P Harris wrote:

> Here is a description of XML for a state machine (for use in robotics):
> robotflow.sourceforge.net/documents/FSMDescription.pdf
> David

The example at the end, demonstates clearly the advantage of a graphical
interface.
For the text version (3.5 pages) I need at least 2 bottles of beer to
read and understand it,
while the graphical representation (1 page) is clear before I even can
open a bottle ;-)

Stef Mientki

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

2004\03\16@135953 by Walter Banks

picon face
That is clearly the problem. You need to read the documentation before opening the bottle :))

Stef Mientki wrote:
>

> The example at the end, demonstates clearly the advantage of a graphical
> interface.
> For the text version (3.5 pages) I need at least 2 bottles of beer to
> read and understand it,
> while the graphical representation (1 page) is clear before I even can
> open a bottle ;-)

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

2004\03\16@143935 by Stef Mientki

flavicon
face
Walter Banks wrote:

>That is clearly the problem. You need to read the documentation before opening the bottle :))
>
>
>
I'm just like most of us,
documentation is only to complain about if it isn't there,
but certainly not to read it ;-)
Stef Mientki

>
>

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

2004\03\16@170833 by David P Harris

picon face
Agreed, but then XML was never meant to be human-readable.

David

Stef Mientki wrote:

{Quote hidden}

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

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