Assembler vs C vs Flowcode ..3..2..1..Fight!

I briefly want to go over some of the upsides and downsides to programming based on the popular embedded languages assembler and C, show how they are used in the field and then compare these to Flowcode.

Assembler

This is basically writing code down at the machine level, you essentially get one line of code per instruction on the processor which gives you full control over the device down to the instruction. This allows you to create very optimised programs to do simple tasks. As your having to write each and every operation the code can get very messy even to do some simple things like control a standard alphanumeric LCD. This means that as a program grows in complexity the complications surrounding the assembler code increase exponentially leading to incredibly hard to find bugs in systems that quite honestly should be easy to pull off.

I remember being back in college and beating my head against a bit of assembler code that worked well until I tried to do anything meaningful with it. The coder had made the program so optimised that it was actually a very precise balancing act and the slightest change sent the code crumbling down.

When I speak about writing assembler I talk from the point of view of writing it for a Microchip PIC device. These are basically designed to simplify assembler by having limiting mechanisms like register banking to simplify the code. On the other hand AVR and ARM chips are basically designed for C so writing assembler for these is much more complex and I wouldn’t even attempt it unless forced to.

C code

C code is a way of coding using more human recognisable syntax like if, else and while to achieve a higher level of abstraction from the underlying machine code. The C commands have to be run through a compiler which uses libraries to efficiently convert the code into the machine code. Larger, more complicated programs can now be achieved and in large left to the compiler to do the heavy optimisations. By creating libraries of C function you can easily call in advanced routines to your program without having to reinvent the wheel each time you move projects. The downside to C is that the code is often highly compiler specific meaning code that works on one compiler isn’t likely to work with another. The task of moving between compilers is often referred to as “porting”.

Again going back to my college days I remember thinking so how do you know what is valid syntax for the specific compiler your using. You might be lucky enough to find example code for what you want to do but with all the different compilers out there it is hard to know if it is going to work or if your going to struggle getting someone else’s code to compile. Even if you have the code compiling you then have to read through and make sense of what it’s doing to allow you to use it correctly.

Arduino use C code and a built in library of functions along with an active community to do their Sketch programming. A downfall with this is that simple mistakes like typo’s can throw a novice user, discouraging them from reaching their goal. Even when doing my master course in embedded engineering it was surprising how many people were completely thrown by a C compilation error caused by a typo.

Typo’s aren’t the only problem with C, there is no fixed way of doing things which means some compilers may be better or worse at doing a specific task and means that you get weird syntax like in some of the Microchip examples where they like to occasionally throw in a pragma or weird built in macro.

Flowcode

Flowcode is built on top of standard embedded C compilers so provides pretty much all of the positive aspects of the C language. On top of this you have features like syntax checking to ensure you cannot enter a typo without knowing about it. There is also the CAL (Code Abstraction Layer) which was introduced in version 5 and then taken further in version 6 which basically allows the Flowcode generated C to compile and work with any of the built in compilers allowing one program to run on a wide range of devices. This makes it much easier to share examples and to get straight down to coding rather than worrying about the specifics of the chip and compiler.

Flowcode also has a wide range of fully documented built in components to do a wide range of the things that you would want to do with your microcontroller. With the introduction of version 6 there is now the ability to convert a Flowcode program into a component basically allowing you to replicate the C type library approach but in a much easier way.

Flowcode version 6 also comes with an documented API of commands to do things in the Flowcode simulation. This allows you to wrap your code libraries with test environments allowing you to double check your code before it gets anywhere near a microcontroller. Take for example our 3D printer demo, we can take a file from a SD card (file located on the PC in simulation) Parse through the file and control stepper motors (movement on 3D models in simulation) to create a component that both simulates a 3D print and works on an embedded target to drive an actual 3D printer. That component can then be shared as an example and someone else looking at the file can use it in their own way without having to know all the internal complications required to build the component.

Flowcode also creates the C and Assembler versions of the project file allowing you to view them and gain a better understanding of what is going on behind the scenes. As well as this there is a C icon allowing you to enter C or Assembler code directly into the program should you wish.

One key downside to Flowcode over C and Assembler is price, however some C compilers alone can run up to thousands of pounds so we feel it is as competitively priced as we can achieve without selling too low for this somewhat niche area and becoming bankrupt.

Another downside is that Flowcode tries to be all things for all components on all devices. Now this is really hard to pull off though we do a good job of it. We add newer devices as soon as they are supported by the compiler but it means that we sometimes cannot test all devices as thoroughly as we would like. If you find a device related issue then let us know and we will do our best to jump on it and get it resolved.

Summation

All three programming languages have their own strengths and weaknesses. I have come from a C and assembler background and love to program in C. However I now find myself using Flowcode more and more as it just saves a dramatic amount of debugging time and comes with other advantages like being able to properly simulate the code. My last few projects Infinity Table (Shown Below), MIAC Underfloor Heating System, LED Cube etc have all been written entirely in the Flowcode software. I even wrote an ARM bootloader using Flowcode though this did involve playing around with header files etc.

From speaking to other expert C programmers I feel a similar thought process going on in their heads as I explain the situation. A typical conversation will start with “I’ve seen flowcode and like the looks of it but I’ve been coding in C for years so why should I move away from this”. After pointing out the ability to interact, simulate, syntax check and graphically debug the code they are starting to come around. I then start to show some of the other features like the project explorer pane, the scope and console windows and the XML based language behind the Flowchart and definition files. Usually by the end of the conversation they are sold and looking forward to having a play with the software to see what new things they can pull off.

We are currently offering a free 30-day unrestricted trial of the Flowcode 6 software which can be found here:

You can sign up for a matrix account to activate your copy:

Got an opinion? Then we would love to hear it, either here on the Blog, on our User Forums or even via an email if you don’t want your comments to be public.

36,316 total views, 4 views today