Not really an answer to your question, but an example of a similar approach
is LabView from National Instruments. Worth having a play with the free
demo, at least, to get an idea of how to hang things together.
Cheers,
Alf.
Reply by Lanarcam●June 5, 20052005-06-05
Michael N. Moran wrote:
> R Adsett wrote:
> > I've done almost exactly this using Eagle. I used the schematic to
> > develop a communication flow with the built in check making sure that
> > inputs and output were properly matched. The built in scripting language
> > was used to generate an output table of the netlist. The netlist was
> > parsed to produce an XML description that contained additional
> > information and finally the XML was parsed to produced C code.
> >
> > The XML intermediate step allowed combining multiple sources and the
> > equivalent of an include facility.
>
> I would be interested to hear your experiences with
> this approach.
>
> As one of those guys that started as a digital hardware
> engineer during the early days of schematic capture and
> then moved later into the software (dark ;-) side of the
> game, the thought of a component based approach to software
> development and visual modeling has always been appealing.
> (purty picture envy probably ;-)
>
> Seems to me that the digital hardware world benefited
> greatly from the use/reuse of standard components and
> interfaces.
As I see it, it looks like a function diagram, what you
find in the IEC 1131 standard for function blocks.
This is often used in industrial control, technicians
can read it easily.
This is, IMHO, very different from UML which has a
OOps approach. Components in UML are objects, not
functions, and from what they say this is a different
paradigm.
It should not be really impossible to do in softawre
what you can do in hardware with components. You
need well defined protocols.
NI Labviews has achieved something similar.
> As a start:
>
> Did you find this approach useful?
>
> Can you describe the "communication flow" across a "wire"?
>
> Did you model a wire as a fifo byte stream or what?
>
> What kind of semantics were associated with the "wire"?
> o Flow control
> o Delivery (Exactly Once, At Least Once, At Most Once?)
>
> How did you implement the broadcast semantics of a "wire"
> (one output to many inputs?)
>
> Are components/blocks independent in time (threads?)
>
> How do you contrast your approach to UML?
>
> What did you learn?
>
> Maybe I ask too many questions ;-)
>
> --
> Michael N. Moran (h) 770 516 7918
> 5009 Old Field Ct. (c) 678 521 5460
> Kennesaw, GA, USA 30144 http://mnmoran.org
>
> "So often times it happens, that we live our lives in chains
> and we never even know we have the key."
> The Eagles, "Already Gone"
>
> The Beatles were wrong: 1 & 1 & 1 is 1
Reply by R Adsett●June 5, 20052005-06-05
In article <dmooe.86968$J25.56281@bignews6.bellsouth.net>,
mike@mnmoran.org says...
> R Adsett wrote:
> > I've done almost exactly this using Eagle. I used the schematic to
> > develop a communication flow with the built in check making sure that
> > inputs and output were properly matched. The built in scripting language
> > was used to generate an output table of the netlist. The netlist was
> > parsed to produce an XML description that contained additional
> > information and finally the XML was parsed to produced C code.
> >
> > The XML intermediate step allowed combining multiple sources and the
> > equivalent of an include facility.
>
> I would be interested to hear your experiences with
> this approach.
>
> As one of those guys that started as a digital hardware
> engineer during the early days of schematic capture and
> then moved later into the software (dark ;-) side of the
> game, the thought of a component based approach to software
> development and visual modeling has always been appealing.
> (purty picture envy probably ;-)
>
> Seems to me that the digital hardware world benefited
> greatly from the use/reuse of standard components and
> interfaces.
>
> As a start:
>
> Did you find this approach useful?
I had two goals when I started with it.
- The first was to come up with a way of showing the internal
logic in a way that would allow non-programmers to follow it and maybe
suggest flaws. It wasn't necessary for them to be able to use it but if
they could read it feedback on behaviour might be available earlier. On
this front it was a resounding failure. It ended up that the main reason
no-one would comment on the code before they could see it operating was
not because they didn't understand the code well enough for a simple
review but that they simply couldn't be bothered. So much for early
feedback.
- The second was to provide a way of abstracting the data flow
from external sensors and actuators to/from the control logic including
over the network. This was a qualified success but needed some more work
and refinement. Before moving on from the company I had enough
experience with it to be intrigued at the possibilities but hadn't had
enough time to rework it into a more usable form.
> Can you describe the "communication flow" across a "wire"?
A fairly simple model. The output/source was simple scalar value that
the attached inputs used as needed. There was no attempt to deal with
streams of data, although I had support for arrays and booleans. The
arrays were used as lookup/calibration tables. On a rewrite I'd probably
dispense with the arrays since they were used in the logic rather than
communications.
> Did you model a wire as a fifo byte stream or what?
See above. Really I thought of it a piece of Cu carrying a voltage :)
On a programming level it ended up being a reference to a value in a
table.
> What kind of semantics were associated with the "wire"?
> o Flow control
> o Delivery (Exactly Once, At Least Once, At Most Once?)
No flow control, the value was simply there as far as the program was
concerned. In fact that was more or less part of the abstraction. It
removed any considerations of delivery to outside of the context of the
schematic. Delivery was similarly outside of the scope of the schematic
but was effectively at least once. The schematic would execute in a
cyclic timed fashion using whatever inputs were there and propagating
them through to the outputs. The outputs would then end up either
operating physical outputs or travelling via a network to some other
process. The underlying network was CAN based so it had at-least once
characteristics and critical values could be watchdogged although I
hadn't got as far as testing that.
> How did you implement the broadcast semantics of a "wire"
> (one output to many inputs?)
Ah, but if a wire ends up simply being a value in a table anything can
just read the value. Simplicity itself.
> Are components/blocks independent in time (threads?)
Schematics are. Components were generally not nearly complex enough for
that to be useful in any case.
> How do you contrast your approach to UML?
It bore much the same relationship that ladder diagrams do.
> What did you learn?
- Many who specify a system don't care to check your understanding of the
specification until they see it (not) working. I'd still like to find a
way of getting this feedback back I'm a lot less optimistic about it. It
appears to be less a technical problem than a human one. Basically "Just
go away and make it do what I want and don't bother me until you're
done." It's not really that they don't care, it's just they don't see
the need to repeat what they believe they've already told you.
- If you want to have a simply programmable core for the logic it makes
sense to invest (time and/or money) in a PLC core rather than re-invent
the wheel. I knew that going in but didn't have the go-ahead to buy the
core and tried to work around it.
- I think this would have been a reasonble way of setting up
communication over a network for control purposes but I didn't get enough
systems up to give it a try.
- Error handling doesn't fit in very well. In fact the only way I could
get real error handling was to hide it behind the scenes. Luckily in the
abstraction I was using the only real place for run time errors was in
the communications layer and most of them could be watchdogged, i.e. if
critical values didn't arrive quickly enough go to some sort of safe
mode.
> Maybe I ask too many questions ;-)
Well, I wasn't going to volunteer without some sort of expression of
interest. This post is all your fault for asking ;)
It sounds like you are looking to set up a more complex abstraction than
I attempted. Good luck.
Robert
Reply by Michael N. Moran●June 4, 20052005-06-04
R Adsett wrote:
> I've done almost exactly this using Eagle. I used the schematic to
> develop a communication flow with the built in check making sure that
> inputs and output were properly matched. The built in scripting language
> was used to generate an output table of the netlist. The netlist was
> parsed to produce an XML description that contained additional
> information and finally the XML was parsed to produced C code.
>
> The XML intermediate step allowed combining multiple sources and the
> equivalent of an include facility.
I would be interested to hear your experiences with
this approach.
As one of those guys that started as a digital hardware
engineer during the early days of schematic capture and
then moved later into the software (dark ;-) side of the
game, the thought of a component based approach to software
development and visual modeling has always been appealing.
(purty picture envy probably ;-)
Seems to me that the digital hardware world benefited
greatly from the use/reuse of standard components and
interfaces.
As a start:
Did you find this approach useful?
Can you describe the "communication flow" across a "wire"?
Did you model a wire as a fifo byte stream or what?
What kind of semantics were associated with the "wire"?
o Flow control
o Delivery (Exactly Once, At Least Once, At Most Once?)
How did you implement the broadcast semantics of a "wire"
(one output to many inputs?)
Are components/blocks independent in time (threads?)
How do you contrast your approach to UML?
What did you learn?
Maybe I ask too many questions ;-)
--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org
"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"
The Beatles were wrong: 1 & 1 & 1 is 1
Reply by R Adsett●June 4, 20052005-06-04
In article <aSYne.22909$j51.3526@tornado.texas.rr.com>, xxx@yyy.com
says...
> Hi :
>
> I am writing a software system that is configured by the user using function
> block diagram - basically a schematic.
>
> I will provide a library of blocks, then compile the net list into a list of
> pointer assignments and function calls - you get the idea.
>
> What I need is a relatively simple and cheap schematic capture package, that
> can generate a netlist of "parts", their arbitary attributes and the
> interconnections.
>
> Does anyone have any suggestions of a program I could use ?
I've done almost exactly this using Eagle. I used the schematic to
develop a communication flow with the built in check making sure that
inputs and output were properly matched. The built in scripting language
was used to generate an output table of the netlist. The netlist was
parsed to produce an XML description that contained additional
information and finally the XML was parsed to produced C code.
The XML intermediate step allowed combining multiple sources and the
equivalent of an include facility.
Robert
Reply by Stef Mientki●June 3, 20052005-06-03
LabView perhaps ?
AFAIK, SoftWire is still not released, but the guy is very willing to
help, and it's running, so ask him.
Another package could be KiCAD (free).
At the moment I'm testing Diagram Designer from MeeSoft (free),
for generating code (JAL, PICbsc and Delphi) from graphical Statemachine
designs and probably also from flowcharts.
(For the other thread, Flowcharts are just as structured as NS-diagrams,
and not only technician can read them, but every human being ;-) ;-)
My first attempts for statemachine design, can be seen here:
http://oase.uci.kun.nl/~mientki/pic/diagram.html
Stef Mientki
Gary Pace wrote:
> Hi :
>
> I am writing a software system that is configured by the user using function
> block diagram - basically a schematic.
>
> I will provide a library of blocks, then compile the net list into a list of
> pointer assignments and function calls - you get the idea.
>
> What I need is a relatively simple and cheap schematic capture package, that
> can generate a netlist of "parts", their arbitary attributes and the
> interconnections.
>
> Does anyone have any suggestions of a program I could use ?
>
> Thanks
> Gary
>
>
Reply by Rich Walker●June 3, 20052005-06-03
"Gary Pace" <xxx@yyy.com> writes:
> Hi :
>
> I am writing a software system that is configured by the user using function
> block diagram - basically a schematic.
>
> I will provide a library of blocks, then compile the net list into a list of
> pointer assignments and function calls - you get the idea.
>
> What I need is a relatively simple and cheap schematic capture package, that
> can generate a netlist of "parts", their arbitary attributes and the
> interconnections.
>
> Does anyone have any suggestions of a program I could use ?
gEDA/gschem? Has a whole bunch of developer tools for massaging
netlists, attributes, schematics; is GPL, so you can modify it to fit
your presentation goals.
cheers, Rich.
--
rich walker | Shadow Robot Company | rw@shadow.org.uk
technical director 251 Liverpool Road |
need a Hand? London N1 1LX | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml
Reply by antedeluvian●June 3, 20052005-06-03
Gary
I have come across a product called SoftWIRE which may be what you ar
looking for. I have only paged through a manual so I cannot answer an
questions. The URL is
http://www.softwire.com/
It does require a VB environment (although perhaps not at run time) and i
free.
-Aubrey
>Hi :
>
>I am writing a software system that is configured by the user usin
function
>block diagram - basically a schematic.
>
>I will provide a library of blocks, then compile the net list into a lis
of
>pointer assignments and function calls - you get the idea.
>
>What I need is a relatively simple and cheap schematic capture package
that
>can generate a netlist of "parts", their arbitary attributes and the
>interconnections.
>
>Does anyone have any suggestions of a program I could use ?
>
>Thanks
>Gary
>
>
>
This message was sent using the comp.arch.embedded web interface o
www.EmbeddedRelated.com
Reply by Gary Pace●June 3, 20052005-06-03
Hi :
I am writing a software system that is configured by the user using function
block diagram - basically a schematic.
I will provide a library of blocks, then compile the net list into a list of
pointer assignments and function calls - you get the idea.
What I need is a relatively simple and cheap schematic capture package, that
can generate a netlist of "parts", their arbitary attributes and the
interconnections.
Does anyone have any suggestions of a program I could use ?
Thanks
Gary