FlowCode Graphical Programming

If you’ve ever been curious if there’s a way to program microcontrollers without actually writing software, you might be interested in FlowCode. It isn’t a free product, but there is a free demo available. [Web learning] did a demo of programming a Nucleo board using the system. You can check it out below.

The product looks slick and it supports a dizzying number of processors ranging from AVR (yes, it will do Arduino), PIC, and ARM targets. However, the pricing can add up if you actually want to target all of those processors as you wind up paying for the CPU as well as components. For example, the non-commercial starter pack costs about $75 and supports a few popular processors and components like LEDs, PWM, rotary encoders, and so on.

Price aside, we have serious concerns about building applications with GUIs. It sounds seductive and for simple projects, it is easy and intuitive. However, complex problems get messy quickly when you have flowcharts. This is the same reason complex logic designs moved away from schematics — another form of graphical representation — and went to Verilog and VHDL.

Still, looking at how this is done might give you some ideas and it might be just the ticket for the right application. It isn’t the only graphical game in town, of course. There’s ArduBlock, for example. Another one we’ve looked at is MiniBloq. You can even use Scratch on the Arduino or Raspberry Pi.

49 thoughts on “FlowCode Graphical Programming

  1. “Price aside, we have serious concerns about building applications with GUIs. It sounds seductive and for simple projects, it is easy and intuitive. However, complex problems get messy quickly when you have flowcharts. This is the same reason complex logic designs moved away from schematics — another form of graphical representation — and went to Verilog and VHDL.”

    Unreal Blueprints.

    1. Having once had to work on a Labview test program, I have to agree that large programs tend to turn into jumbled messes in graphical languages. In fact, that already tends to happen with text based languages.

      1. At work there is a huge multi-board, multi-core server running lots of processes, communicatin with each other in a huge realtime OS. Some of these are written using an UML tool. Now that is a giant spaghetti! :D Everybody hates it.
        For small projects or educational purposes it is great. But when it comes to bigger programs, all hell beaks loose.
        So yup, agreed 100%!

      2. Where I work, everything is either LabView or VB6, and everything is stored in an Access database.

        It’s awful. I’ve been slowly pushing things to Python, C++, C#, PHP, and SQL where applicable.

    2. i think that is more a matter of tradition and momentum than anything else, most people in computer science uses text based languages and that is how they are used to process information.

      i think graphical languages allow for a different way of processing said information, for some it might be better, for others not.
      i don’t think graphical languages make any more of a mess, it’s just that people aren’t used to graphical representation, i will bet that most people who were introduced to the two at the same time and with the same effort would find it more dependant on their specific preference than any real objective difference.

      graphical languages allow for more refined ways of showing information, abstraction also makes a lot more sense in a graphical system, that said most graphical languages are built directly on top of a text based one, in reality we should be combining the two, the main obstacle to that at the moment seems to be prejudice and opinion.

      1. It’s been over 30 years since computers with enough speed and display resolution to run graphical programming environments have been widely available. Numerous attempts have been made, with limited success at best. I doubt it’s just tradition, momentum, prejudice, and opinion that is holding graphical programming back.

        What has happened instead is that textual programming environments have evolved from mere editing; they now include intelligent code completion and automated refactoring.

        At the same time, as noted in the article, complex logic design has moved away from graphical and toward textual representation.

      2. I’ve been in IT for a long time, and every few years a company comes along with a graphic programming platform and a sales pitch that the business can now implement some program instead of having to go through the technology department and all the paperwork and expense that entails. The problem is, it is not the textual syntax for a loop, for example, that is hard, but understanding that you would need a loop in this part of the code, and you need to know the conditions to look for to exit that loop.

        There are analytical skills you need to be able to program, and you just can’t hide them behind a pretty GUI.

        1. i don’t know why the base assumption when someone mentions graphical representation is that it should make programming easily accessible to the layman or trouble free, it is just a way of representing information.

          i don’t think graphical representation will ever replace text based programming entirely, it probably shouldn’t even if it was possible, the point i am trying to make is that the concept of graphical representation is sound and we have acted with that in mind for some time now, in various forms, from text colouration to denote argument type over error highlighting and visual link representation, all in modern text IDE’s.
          if there was truly no merit then it wouldn’t be the de facto standard for programming dozens of different brands of PLC’s.

          but as long as we have a large core of programmers falling for the “real programmers” syndrome (https://xkcd.com/378/) we wont get anywhere and i really do think that that has far more to do with why we don’t have more serious attempts at graphical representation or why the ones that have been there haven’t been taken as seriously as they perhaps should have been.

          don’t get me wrong there have been plenty of bad examples and implementations, i have tried a few and i am still writing code, but i can see how a properly done visual language could complement current ways of programming and representing structure without inherently subtracting from it.

        2. Well the thing about your example is their motivation is economic, not advancing the state of the art. And with that being said, ivory tower solutions need to meet reality.

    3. No doubt you have seen the references to LabView — a graphical system that is hardly limited to small problems.

      To that, I’d like to add Simulink, a graphical system that probably generated the code for every digital system in your car, or the airliner you last rode on, or your cellphone.

      It’s true, graphical solutions don’t tend to scale up … _IF_ they’re written by idiots.

      But that’s true for any programming language. Any program design can be FUBAR’d by a determined but incompetent programmer. What else is new?

      At least with a graphical interface, he can’t create an if with no endif, or a loop with no endloop.

      1. What I’ve seen from LabView is the difficulty of discussing the functions outside the graphical editor. This, with the lack of alternative editors and compilers for the same source code, are the greatest limitations to general adoption.

        There’s no reason an ide for textual development is unable to enforce any other data structure the same as LabView does. Underneath the LabView interface there has to be a text based compiler.

    4. Are you suggesting that BPs get messy quickly, or they are a counter-point to this?
      Personally I find that the ability to use inheritance, wrap things in functions, visual debug/flow visualisation etc etc, helps greatly with organisation and code re-use in Blueprint. In my experience it is significantly quicker for developing most functionality, even complex functionality, than jumping into the code directly, both in teaching (my day job) and production. It’s difficult to see on the Flowcode website if you can write your own nodes easily, but with BP you can always hybridise and push longer or more complex functions into custom nodes with C++ or more BP.
      I guess I’m just saying that if all you do is string more and more nodes together you end up with spaghetti, right enough, but if the system has enough additional functionality to help you simplify graphs it doesn’t have to be that way. At a casual glance it is quite difficult to see if Flowcode has any of those features, though.

  2. It looks like it can also go from code to flowchart form as well. This could be quite handy for some who want to quickly figure out logic errors in large blocks of code.

  3. It takes many pages of schematic diagrams to represent an algorithm. Textual representations are compact and concise, and using symbols and parsing rules is very reasonable when a programming language is a fundamentally a mathematical representation.

    If I wanted to draw lines between many layers of schematics I would have finished my op-amp courses and built some analog computers.

    1. i think you have misunderstood the basic issues, textual representation may be short and concise, but the structure it represents is what is actually important, it is also in many cases very obscure, requiring the exact same or similar information basis to understand, if graphical languages allows someone a better understanding of the structure then it reality it doesn’t matter that text representation is more concise or compact, it would ideally be abstracted anyway.

      even after all that there is nothing to prevent you from using those compact and concise text representations in tandem with graphical representation.

      this either or and the other doesnt even matter attitude in computer science hurts far more than it ever helped.

  4. can any engineer in here post short verilog code for 74HC123 dual retriggerable monostable multivibrator with clear
    ……………………….i didnt think so
    I can do it faster with a schematic

  5. after having tried to avoid learning to program by using various graphical tools i’ve come to the conclusion that they are only usefull if you can actualy write code. Apart from scratch, scratch is a graphical way of writing code.
    They can be usefull, same time, or be less intimidating, but you really cant avoid actually learning how computing works by using them.

    Almost everything that is simple enough to be created by a”Non programmer” using these graphical languages probably already exists as a standalone program written by somebody who could.

    My experience is with PureData, MAX and vvvv, never used labview.

  6. Reminds me very much of Function Block Diagram or Sequential Function Chart programming for PLCs. Even in those applications a skilled programmer is often faster using structured text. Though a lot of the PLC applications lend themselves very well to using just SFC or FBD.

  7. I actually think that it has future, not necessarily this particular product, but the idea as such is not really dead. We’re used to code in text because we always want to be able to go down to the lowest possible level, and we’re used to that and it’s hard to give that up, and text-based coding usually gives that commodity. At the same time we struggle to create libraries that allow operating complex things with APIs as simple as possible (most often it’s a disaster though). But wouldn’t it be neat to be able to build everything out of simple LEGOs, where every connection and linkage is visible and obvious ?

    I’m half asleep and I have some dreamy ideas of representing FORTH words as graphical pieces. FORTH is very graphical-representable I think. Can a different representation make FORTH code more transparent or not is an open question.

  8. ive always found these graphical programming systems to be more trouble than they are worth. you could in theory make execution as fast as any interpreted language or even compile to machine code if you were so inclined. performance wise the “ide” (if you can call it that) itself ends up slowing down to the point of unusability when designing the equivalent of a complex c++ class or function, the gui itself simply becomes sluggish as the number of objects it needs to keep track of increases. it also slows the user down as they have to do a lot of point and click to change variable names or values, and simply scrolling through the program where the same volume of textual code would fit on one screen. their only real value is in education in how programming works. once one understands the basics of “hello world” and how to work with memory, they are better off shedding the gui and starting to write code actual.

    1. a lot of your criticisms are problems of implementation, not concept.

      a slow IDE is nothing new, plenty of text based systems suffer from what to them is arguably relatively worse slow down, considering that they are glorified text editors, well or are at least naively portrayed as such;
      many IDE’s today are already hybrid graphical text systems, the highlighting system of some IDE’s is essentially graphical so i find it weird that people are questioning the value of representing information graphically in a programming context.

    2. But think of it this way, would you rather draw a schematic using symbols for the various gates and logic, or draw each resistor, capacitor, and transistor the symbol represents?

  9. Have been using LabView off and on for over 25 years. ‘Graphical’ programming tools are an effective tool for once-off test systems; and are a nightmare to support in any sane production setting. Meh, computer science wiz-kids have been trying for about 20 years to implement something other than C/C++ (ardy crap not considered in my industry sector), but have only been able to offer Python. My Scons/C based tool chain will beat up your graphical stuff for all, other than blinking some LEDs. But if all you want is to blink LEDs (actually had a millennial engineering applicant use that as example work), feel free to use your slow, non stand-alone, embrittled with race conditions, wonderous graphical programming environment.

    And yes, boys and girls, have used Rust, Swift, and Go. Now get off of my dirt.

    1. People like to see results, and stupid people can’t tell the difference.

      Thus, the dynamic skill range is about 400:1, and people who are tired of repeating themselves retired early.

  10. This would be excellent in Grade School to teach beginning code. The plastic templates and a pencil eraser were so clumsy…

    It’s great… but it’s being applied in the wrong place which is why it’s gettting dissed so much.

  11. In my EE studies, our programming 101 was wirh Flowcode. After initial rejection (I have web programming background), I tried to keep an open mind. Maybe it would be useful as quick prototyping tool? Well, no such luck. Built in component library is severely limited and outdated. Even relatively simple projects with case switches and the like soon become incomprehensible mess of lines. Also the generated C is bloated and hard to read.

  12. You have to laugh (or cry) at the comments (negative) of the protectionist luddites’. Before C et al, there was assembly and C was “slow” , before assembly was hex machine code the ultimate efficiency. Everyone needs to fess up to welcoming the next generation language (which itself will be superseeded). Text is a graphical symbol programming itself (you are reading this program now). The faster to recognise the programming symbols, the greater the productivity. Arm chips are faster and have less instruction choices. Life is simple, your just making it complicated for your own purpose.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.