Program/Code Size

For Flowcode users to discuss projects, flowcharts, and any other issues related to Flowcode 8.

Moderator: Benj

Post Reply
User avatar
AbhijitR
Posts: 299
Joined: Fri Nov 07, 2014 12:48 pm
Location: Pune, India
Has thanked: 280 times
Been thanked: 79 times
Contact:

Program/Code Size

Post by AbhijitR »

Hello! Everybody

There is a small confusion in my mind regarding the code/program size after compilation to *.hex in between a program written in Flow Code and any other "C" language software. Does that really make a big difference in memory utilization if compared between FC and other software.

If there is a big difference is it possible to imitate the same thing written in "C" language software using a "C" block (insert C Code) in FC (no doubt I know nothing about "C" language) to allocate/assign one of the ADC pins as analog input and reading that input as GetByte, instead of using the Component Macro.

I hope I was clear to explain my doubt. :)

Thank you.

Regards
Abhi

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Program/Code Size

Post by Benj »

Hi Abhi,

We try to make Flowcode generated code as efficient as possible and in my opinion we don't do too badly. No doubt if you were using hand crafted C the code would be slightly more efficient, but not by much.

It really depends on what you want to do. For example the Flowcode ADC routine allows you to read any of the analogue pins on the device. If you hand crafted an ADC routine using C you might only want one specific channel which would likely reduce the ROM usage. Not using a function call would again save more ROM space. Flowcode claws back some ROM space by using the pre-processor to detect which ADC channels are being used in the program and only generating code for these in the ADC routines. IN some cases we inline code so as to avoid the function call hit.

The real efficiency would come from hand crafting assembler but this is very lengthy and tedious and hard to debug, hence the use of higher level languages such as C and Flowcode.

For me the real saving is the speed you can create code using Flowcode, it would take much longer to do the same thing using C code and much much much much longer doing the same thing in assembler. When I create my own projects that are ROM critical I start with Flowcode and then if required see which bits I can hack away to get the code really streamlined for the specific application.

User avatar
AbhijitR
Posts: 299
Joined: Fri Nov 07, 2014 12:48 pm
Location: Pune, India
Has thanked: 280 times
Been thanked: 79 times
Contact:

Re: Program/Code Size

Post by AbhijitR »

Hi! Ben
Good morning

Kindly excuse for the delayed reply, it was indeed a long weekend for me.

Ben many many thanks for the explanation, I appreciate your time, no doubt it is only flowcode which has helped me to progress so fast in a short time.

My purpose behind asking this doubt was from commercial point of view, but I think it should matter when the volume will increase.

Once again thanks for your word, I count on that.

Regards
Abhi

User avatar
QMESAR
Valued Contributor
Valued Contributor
Posts: 1287
Joined: Sun Oct 05, 2014 3:20 pm
Location: Russia
Has thanked: 384 times
Been thanked: 614 times
Contact:

Re: Program/Code Size

Post by QMESAR »

Hi Abhi.

Out of many years experience developing Firmware for Production stuff this is what I learned and has been following this rule for at least 15 years.

For prototyping and first tests we always use the micro with the largest memory ,then at the B sample stage ( at this time your Firmware should be completed right)(B samples are just before the production intend samples) then you check your code size and select the micro with just the right memory and 5-10% spare
this reduce micro cost in the-end product and you can select the correct micro for your application
memory is money in micro's and this rule works perfect if you are a microchip user as their families are 1:1 pin compatible not so sure this is so well organized at other suppliers :D

Post Reply