Searching \ for '[PIC] My version of visual programming' 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/devprogs.htm?key=programming
Search entire site for: 'My version of visual programming'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] My version of visual programming'
2003\06\19@132802 by Tim Webb

flavicon
face
Has anyone ever seen or heard of a program where your can create PIC assembly code by using a flow chart like program with visual symbols that represent all PIC commands, simulate the results and then compile the program for the PIC.  I am thinking about what is would take to use a program like HP/Agilent VEE and create a user function for each command.  This would make designing a program like playing with Lego's.  Each command would have a function you call and then you create a flow chart by connecting the functions like a flow chart.

Does this sound unrealistic or like a cool idea?

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

2003\06\19@133713 by Herbert Graf

flavicon
face
> Has anyone ever seen or heard of a program where your can create
> PIC assembly code by using a flow chart like program with visual
> symbols that represent all PIC commands, simulate the results and
> then compile the program for the PIC.  I am thinking about what
> is would take to use a program like HP/Agilent VEE and create a
> user function for each command.  This would make designing a
> program like playing with Lego's.  Each command would have a
> function you call and then you create a flow chart by connecting
> the functions like a flow chart.
>
> Does this sound unrealistic or like a cool idea?

       IIRC there is already something like this for BASIC stamps. Personally I
really don't think it's a worthwhile endeavor, the amount of overhead you
introduce with a visual system means you pretty much loose the ability to do
anything really interesting with a resource limited PIC. TTYL

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

2003\06\19@134938 by Stef

flavicon
face
Tim,

very good idea !! at least in my view !!

There are already several programs available:

Zmech has a good loking tool, but unfortunatly I never managed to get
it to work
see  http://www.xcprod.com/

There is also a package from a German company, but I can't find the link
anymore.
There wasn't a tryout version and then it stops for me there

Sometimes I even play with the idea of building one ;-)
But too many projects at the moment.

Stef Mientki

Tim Webb wrote:

{Quote hidden}

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

2003\06\19@135137 by Stef

flavicon
face
>>Does this sound unrealistic or like a cool idea?
>>
>>
>
>        IIRC there is already something like this for BASIC stamps. Personally I
>really don't think it's a worthwhile endeavor, the amount of overhead you
>introduce with a visual system means you pretty much loose the ability to do
>anything really interesting with a resource limited PIC.
>

I don't see the difference between "translating" a C-code line into assembly
or "translating" a visual design into assembly.

Stef Mientki

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

2003\06\19@141231 by Sergio Masci

picon face
----- Original Message -----
From: Tim Webb <tim_webbspamspam_OUTAGILENT.COM>
To: <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Thursday, June 19, 2003 6:26 PM
Subject: [PIC] My version of visual programming


> Has anyone ever seen or heard of a program where your can create PIC
> assembly code by using a flow chart like program with visual symbols that
> represent all PIC commands, simulate the results and then compile the
> program for the PIC.  I am thinking about what is would take to use a
> program like HP/Agilent VEE and create a user function for each command.
> This would make designing a program like playing with Lego's.  Each
command
> would have a function you call and then you create a flow chart by
> connecting the functions like a flow chart.
>
> Does this sound unrealistic or like a cool idea?

There is a tool called ZMech that allows you to visually program and debug
complex PIC systems using the state machine principle.

ZMech is derived from IPAD-Pro which is a meta CASE tool. You can use this
tool to build other visual programming tools to program the PIC (or any
other processor) in way that you described.

However your description of using low level flow charts for visual
programming would be a bit of a waste of capabilities for a visual
programming system. What you should really consider is building libraries of
components that can be bound together like complex macros. Unlike macros
however your components would be aware of the context in which they are
being used so that they can tailor their output depending on their
relationship to other components. For example you could have a serial
component connected to an I2C component or an RS232 component and the code
generated by both of these components would depend on each other. You could
also throw in an I2C EEPROM component and the generated code would also take
this into account.

When you program in assembler you tend to have to define lots of symbols to
communicate information between different components of the source. These
symbols drive the assembler to generate a specific executable (conditional
assembly, constants, included modules, code placement, etc). A simple
example would be an assembler symbol called S1_BAUD. One component would
require that this symbol be defined and set to a value, another component
would actually define it and set it. If you use a visual programming tool,
you can connect components together without worrying about creating a symbol
that communicates information between the components, the underlying tool
uses the pictorial link to connect components together and exchange
information with each other. In the case of the S1_BAUD example, you would
not need to create a symbol called S1_BAUD, you would simply connect a link
from a BAUD object to your component that need a setting for it.

More information on ZMech, IPAD-Pro and other related tools can be found at
http://www.xcprod.com

Regards
Sergio Masci

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

2003\06\19@141645 by Herbert Graf

flavicon
face
> >        IIRC there is already something like this for BASIC
> stamps. Personally I
> >really don't think it's a worthwhile endeavor, the amount of overhead you
> >introduce with a visual system means you pretty much loose the
> ability to do
> >anything really interesting with a resource limited PIC.
> >
>
> I don't see the difference between "translating" a C-code line
> into assembly
> or "translating" a visual design into assembly.

       The difference is bloat. C was originally designed to be "as close" to
assembly as can be, and if you think about common C routines that tracks,
many routines (aside from complex math routines) can almost be translated
line for line to assembly. Have you ever looked at the listing for a C
program compiled to ASM? Most of it is line for line, in fact there are many
sections where the C program is LONG then the actual assembly
implementation.

       A visual design, OTOH is far more complex, and can contribute to
significant bloat. I won't bother with an example, it's easy enough to come
up with one. Aside from just this, visual designs tend to promote
programming styles that waste resources, in a 1GHZ PC that isn't an issue,
the extra cycles are there, waiting to be used, for a PIC every single word
can count.

       Personally even going to C might create more bloat than it's worth.

       All in all, as a Prof once drilled into our heads, you NEVER get something
for nothing. By decreasing the complexity of development you are most
definitely giving something up. And in many cases one of the things you are
giving up is efficiency. TTYL

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

2003\06\19@155944 by Daniel Serpell

flavicon
face
On Thu, Jun 19, 2003 at 11:26:46AM -0600, Tim Webb wrote:
> Has anyone ever seen or heard of a program where your can create PIC assembly code by using a flow chart like program with visual symbols that represent all PIC commands, simulate the results and then compile the program for the PIC.  I am thinking about what is would take to use a program like HP/Agilent VEE and create a user function for each command.  This would make designing a program like playing with Lego's.  Each command would have a function you call and then you create a flow chart by connecting the functions like a flow chart.
>
> Does this sound unrealistic or like a cool idea?

My company actually tried something like this. We have a product
called Klon (see http://www.aplik.com/klon/info/techinfo/klonbrief.html ),
it's a SCADA like product that can be programmed visually.

We had the idea to extend this to microcontroller programming, using
an optimizing compiler that could generate very good code from
the visual description. It's feasible, but we weren't sure about
the comercial interest.

   Daniel.

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

2003\06\19@184147 by Tony Nixon

flavicon
picon face
Tim Webb wrote:
>
> Has anyone ever seen or heard of a program where your can create PIC assembly code by using a flow chart like program with visual symbols that represent all PIC commands, simulate the results and then compile the program for the PIC.  I am thinking about what is would take to use a program like HP/Agilent VEE and create a user function for each command.  This would make designing a program like playing with Lego's.  Each command would have a function you call and then you create a flow chart by connecting the functions like a flow chart.
>
> Does this sound unrealistic or like a cool idea?
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

I was thinking of doing this myself, but no time these days.

PICaxe ???

http://www.rev-ed.co.uk/picaxe/

regards

Tony

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

2003\06\19@193237 by David Huisman

flavicon
face
Take a look at WIZ C. http://www.fored.co.uk/prof.htm


Kind Regards

David
-----Original Message-----
From: Tony Nixon [tony.nixonEraseMEspam.....ENG.MONASH.EDU.AU]
Sent: Friday, 20 June 2003 8:35 AM
To: EraseMEPICLISTspamMITVMA.MIT.EDU
Subject: Re: [PIC] My version of visual programming


Tim Webb wrote:
>
> Has anyone ever seen or heard of a program where your can create PIC
assembly code by using a flow chart like program with visual symbols
that represent all PIC commands, simulate the results and then compile
the program for the PIC.  I am thinking about what is would take to use
a program like HP/Agilent VEE and create a user function for each
command.  This would make designing a program like playing with Lego's.
Each command would have a function you call and then you create a flow
chart by connecting the functions like a flow chart.
>
> Does this sound unrealistic or like a cool idea?
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email RemoveMElistservEraseMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

I was thinking of doing this myself, but no time these days.

PICaxe ???

http://www.rev-ed.co.uk/picaxe/

regards

Tony

--
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\06\19@195611 by Charles Craft

picon face
www.oopic.com


-------Original Message-------
From: Tim Webb <EraseMEtim_webbspamspamspamBeGoneAGILENT.COM>
Sent: 06/19/03 12:26 PM
To: RemoveMEPICLISTKILLspamspamMITVMA.MIT.EDU
Subject: [PIC] My version of visual programming

>
> Has anyone ever seen or heard of a program where your can create PIC
assembly code by using a flow chart like program with visual symbols that
represent all PIC commands, simulate the results and then compile the program for
the PIC.  I am thinking about what is would take to use a program like
HP/Agilent VEE and create a user function for each command.  This would make
designing a program like playing with Lego's.  Each command would have a
function you call and then you create a flow chart by connecting the functions
like a flow chart.

Does this sound unrealistic or like a cool idea?

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

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

2003\06\19@220413 by Bob Ammerman

picon face
Not if all the visual gook is on the PC front end. There is no reason you
couldn't 'compile' the pretty pictures into reasonably efficient code.

Bob Ammerman
RAm Systems

{Original Message removed}

2003\06\19@230608 by cdb

flavicon
face
Look at Flowcode from http://www.matrixmultimedia.co.uk , don't know how
good or bad it is, you can download  a demo program.

Colin
--
cdb, KILLspambodgy1spamBeGonespamoptusnet.com.au on 20.June.2003

I have always been a few Dendrites short of an Axon and believe me it
shows.

Light travels faster than sound. That's why some people appear bright
until they speak!

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

2003\06\19@232720 by Douglas Wood

picon face
You're essentially talking about a compiled ladder logic.

Douglas Wood
Software Engineer
@spam@dbwood@spam@spamspam_OUTkc.rr.com
ICQ#: 143841506

Home of the EPICIS Development System for the PIC
http://epicis.piclist.com

{Original Message removed}

2003\06\20@063317 by Peter L. Peres

picon face
> I don't see the difference between "translating" a C-code line into
> assembly or "translating" a visual design into assembly.

It's not the translating that is hard, it's managing the visual
representation while obeying rules imposed by the underlying model. This
is do-able in several ways but the effort for the data structures and
integrity ('synthetisability') is huge which leads to lots of debugging
work. The result will not be very optimal and it can easily have
difficulty fitting in a smaller pic.

Peter

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

2003\06\20@203505 by Sergio Masci

picon face
----- Original Message -----
From: Herbert Graf <.....mailinglistspam_OUTspamFARCITE.NET>
To: <TakeThisOuTPICLIST.....spamTakeThisOuTMITVMA.MIT.EDU>
Sent: Thursday, June 19, 2003 7:16 PM
Subject: Re: [PIC] My version of visual programming


{Quote hidden}

Sorry but I cannot agree.Your assertion that visual design leads to bloat is
only true because the tools or the users of the tools are crap.

Some of the tools available require that users build everything from the
most primitive component right up to what they really wanted in the first
place.

It's like a user trying to build a circuit with a solderless breadboard
being told that each of the chip he wants to use must in turn be built on
their own boards with other chips, and doing this recursively until he
finally reaches discreet transistors.

The visual design concept is not the issue.

>
> Personally even going to C might create more bloat than it's worth.

But again this depends on the quality of the tool (the C compiler and
linker) and the user of the tools. Typically these days a good C programmer
can get to within 90% of the code produced by a good assembler programmer.
When I think of bloat I normally think of a generated app that is hundreds
of times bigger than it needs to be not 10%

>
>  All in all, as a Prof once drilled into our heads, you NEVER get something
> for nothing.

You're not getting something for nothing, there is hidden input that you are
not considering. A highly advanced tool can incorporate the knowledge and
experience of the very clever people that built it AND it can better utilise
the number crunching capabilities of the development system to help find
hidden optimisations. Kind of like a chess program that looks at many
different combinations of moves to pick the best one. You're definitely not
getting something for nothing.

> By decreasing the complexity of development you are most
> definitely giving something up. And in many cases one of the things you are
> giving up is efficiency. TTYL

Again I disagree. Let's say you hired a consultant to build you several
systems that could be configured, possibly even used together. Let's also
say that this consultant is a genius, that he spends a great deal of time
building many versions of each function (together with conditional assembly
where appropriate) so that they are optimised for use in different
combinations. Now you would expect a really cool bloat free result.

Now imagine that the consultant also builds you a sophisticated menu driven
configuration system so that it automatically configures the systems for you
and builds the executable code. This way it is not possible for you to
configure the system incorrectly and obtain bloated code. Also development
complexity for the user of this tool has been greatly reduced. Now instead of a
menu configuration system imagine that you are allowed to configure the system
by dragging and dropping components onto a diagram and connect them with
graphical lines between specialised points on each component (kind of like
wiring the pins of ICs together). This is what visual programming should be
like. You should be able to pick up a printout and instantly see how the system
is configured.

What you need is a visual programming tool that can be modified at the tool
intelligence level rather than one that relies on you getting around the
short comings of the tool by building complex systems - the bloat factor.
This is like the difference between you implementing floating point as a set
of functions or building it into the language (one of the differences
between BCPL and C).

This is what a meta CASE tool is all about. You get to mould the tool so that
instead of it just knowing about "objects" you can teach it about widgets and
do-hickeys and thingy-me-bobs. If you want the tool to handle state
machines, you don't mess about building some complex state machine "class"
that impacts (bloats) your target system, you teach the tool about states
and events and get it to generate clean lean code in the target. In the
process, because your tool knows about state machines, you end up being able
to easily use it to design state machines. No strange objects cluttering up
your diagrams, no complex rules about which methods you need to build by
hand and interleave with generated code, no complex debugging as you wind
your way in and out of code generated to handle message objects and protocols.
Just clean efficient code.

Form an assembler point of view, think of this as the ability to be able to
create macros that can be directly connected to one another so that each
knows about the one it is connected to and how it is connected to it. Each
can generate code which is dependant on the others without the others
needing to publish explicit information about themselves, without them
needing to be invoked in a special order to influence the code generated by
subsequent macros. Put another way, when you write assembler and you invoke
macro A followed by macro B followed by macros C, macro A does not know that
it will be followed by macro B and macro B does not know that it is between
macros A and C. If macros A, B and C are to generate optimal code for this
specific combination, they must each generate something that the following
macro invocation can act on. However because macros B and C have not been
invoked before macro A has, the programmer must either inform macro A
somehow that it must take macros B and C into account or generate code that
is not optimal. When you configure a meta CASE tool you are more concerned
about programming the above macros so that they know about the context in
which they are used and generate one chunk of optimised code rather than
generating separate functions that must call each other at run time.

Ok, but why does this have to be visual? Because components need to be
informed somehow that they are connected together you need some mechanism to
identify them to each other and some protocol to allow them to communicate
(there are only so many ways you can physically locate text next to other
text on a two dimensional page). If this were non-visual you would be back
to creating symbols (strings of characters) and complex tables and assigning
values to them. The programmer would need to know about the names of objects
and the protocols used to communicate with them. In effect another
programming language. By using a visual system, the tool can pass values
back and forth between components without forcing the programmer to create
symbols for this purpose or knowing about the protocol. Of course the
programmer responsible for configuring the CASE tool would know about the
protocol (not the symbols - no need for that) but the programmer that used
the configured case tool would not.

Imagine how a small company with a niche market could benefit from such a
tool. It could use such a tool to capture the experience and product
expertise of its most senior engineers and use it to augment that of its
junior engineers. Even a one man shop could improve its ability to
customise its products.

ZMech is actually derived from IPAD-Pro (which is a meta CASE tool). To use
ZMech you don't need to know how state or event objects are built or handled
within IPAD-Pro, you don't have complex underlying classes or communications
objects living on the target (the resulting embedded system). All the comms and
interaction between screen objects is resolved before the executable is built
The resulting state machine code is very small and efficient and does run on a
PIC.

Regards
Sergio Masci

http://www.xcprod.com

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

2003\06\20@211318 by Herbert Graf

flavicon
face
> Sorry but I cannot agree.Your assertion that visual design leads
> to bloat is
> only true because the tools or the users of the tools are crap.
>
> Some of the tools available require that users build everything from the
> most primitive component right up to what they really wanted in the first
> place.
>
> It's like a user trying to build a circuit with a solderless breadboard
> being told that each of the chip he wants to use must in turn be built on
> their own boards with other chips, and doing this recursively until he
> finally reaches discreet transistors.
>
> The visual design concept is not the issue.

       OK, concede the point that the visual design concept is not the only issue,
however EVERY example of visual design I've seen has been fraught with the
bloat problem, so it seems that no one has figured out (or simply hasn't
bothered trying) how NOT to get bloat.

> >
> > Personally even going to C might create more bloat than it's worth.
>
> But again this depends on the quality of the tool (the C compiler and
> linker) and the user of the tools. Typically these days a good C
> programmer
> can get to within 90% of the code produced by a good assembler programmer.
> When I think of bloat I normally think of a generated app that is hundreds
> of times bigger than it needs to be not 10%

       Not really. With C there is automatic "close to assembly" in the design of
the language (which isn't a coincidence, that's what C was originally
created to be), that is why some find it so hard to understand, you have to
think more like an assembly language programmer then with other HLL tools
(i.e. VB, which should be stricken from the planet, but I digress...)

{Quote hidden}

       I agree that sort of system is possible, where I disagree is the existence
of this sort of product, the amount of work needed to do this far outweighs
the gains, which is why this sort of extreme optimization is rarely seen.

{Quote hidden}

       Interesting example, but I think you've limited things to much. Consider
this: what happens if I want a system with a subset of the features the
person created? That's the issue with many visual programming environments.
As an very simple crude quickie example, consider printf. Printf is a very
complicated routine. When I use it in a typical compiler what happens? THE
WHOLE routine is brought in. Even if I only use it once, to print a single
number, the whole routine, with all it's vast features, that I don't need,
are brought it. Now I know that this is exactly what you are taking about:
optimizing things so that only the needed parts of printf are introduced,
but I have yet to see one compiler that does this.

       All in all you make many interesting points, but from the real world view I
have never seen a visual tool that didn't heavily add bloat. Heck, just a
"hello world" type program on windows using a visual tool results in a 100k
executable and several required DLL, total size over 2MB. A visual tool CAN
be made as bloat free as possible, but I've never seen one. TTYL

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

2003\06\20@215119 by Jake Anderson

flavicon
face
it sounds like the PIC compilers you are speaking of don't even do dead code
removal. Take a look at JAL it has limitations sure but in general even
simple programs include hundreds of lines of files (I think my "flash an
led" program included something like 1500 lines from various libaries) the
end product is something on the order of 130 bytes, and you want to know the
best thing? I dont even really know how it works ;->. I could find out by
reading the lib's etc but I don't have to if I don't want to.

<rant>
As for knocking VB, I have used it to make a program that interfaced with a
mysql database to run almost all aspects of a telecomunications company in
around a day. From tracking faults through to resolution, "Instant
Messaging" between staff, Billing customers, checking wholesale rates, stock
managment, sales person "managment" and a whole heap of other stuff. Point
is unless you were some godlike C coder there is no way you could have done
that in a day and make it look nice to the users. VB has its place C has its
place. Get over it. </rant>
{Original Message removed}

2003\06\21@051204 by Peter L. Peres

picon face
Jake Anderson wrote:
<rant> As for knocking VB, I have used it to make a program that
interfaced with a mysql database to run almost all aspects of a
telecomunications company in around a day. From tracking faults through to
resolution, "Instant Messaging" between staff, Billing customers, checking
wholesale rates, stock managment, sales person "managment" and a whole
heap of other stuff. Point is unless you were some godlike C coder there
is no way you could have done that in a day and make it look nice to the
users. VB has its place C has its place. Get over it. </rant>

And how does that compare with other rad tools like vc++ vtcl python and
more ? Apart from the os and portability problems everyone knows and loves
? Or did you also write the libraries you used on the same day ?

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\26@160642 by Wouter van Ooijen

face picon face
> it sounds like the PIC compilers you are speaking of don't
> even do dead code
> removal. Take a look at JAL <snip>

One of the reasons for writing Jal was actually that I wanted to be able
to write libraries that were as (code-size) efficient as dedicated code,
adn that even the most simple case of dead code removal (removing
uncalled subroutines) was very difficult to achieve in assembler (Olin:
I am taling pre-linker time).

Wouter van Ooijen

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

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

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