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
Program/Code Size
Moderator: Benj
- 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
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.
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.
Regards Ben Rowland - MatrixTSL
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
Flowcode Product Page - Flowcode Help Wiki - Flowcode Examples - Flowcode Blog - Flowcode Course - My YouTube Channel
- 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
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
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
- QMESAR
- 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
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
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
https://www.flowcodexchange.com/
Regards QMESAR
Regards QMESAR