Re: Function Block / Schematic Editor
- From: R Adsett <radsett@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 5 Jun 2005 12:39:05 -0400
In article <dmooe.86968$J25.56281@xxxxxxxxxxxxxxxxxxxxxx>,
> 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
> 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
- 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
> 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
> 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
> 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.
- Prev by Date: help regarding creating peripheral in xilinx EDK(XPS) 6.3i
- Next by Date: Re: Does free RTOS Object file can fit in ARM7 (Philips 2106) microcontroller?.
- Previous by thread: Re: Function Block / Schematic Editor
- Next by thread: Re: Function Block / Schematic Editor