TheBackShed.com

Forum Index : Microcontroller and PC projects : Firmware Code Size

Author

Message

bigmik

Guru

Joined: 20/06/2011
Location: Australia
Posts: 2914

Posted: 07:18am 03 Aug 2011

Copy link to clipboard

Print this post

Hi,

I am wondering if all these little `patches' that are being written into the firmware might tip the size of the firmware a bit too big to be practical if they were all included in the `official' firmware...

It seems silly to me that there be 10 different firmwares depending on the application that you want to use.

If this was indeed the case could it be re-written in such a way that various code enhancements can be dragged in via the SD card?

For instance a command like ENABLE (or some more suitable command)

ENABLE PWM
or
ENABLE I2C
or
ENABLE 'mik-code'

or

ENABLE PWM, I2C, 'mik-code'

This way there will be only one version of the firmware that can be tailored at the start of the program and the `special' code blocks applicable for the application can be dragged in off the SD.. they can be stored as I2C.BIN or similar convention..
New commands could just be added by this command without requiring a reflash of firmware.

This would minimise the impact on the 512k internal memory in the PIC32 and maybe allow use of things like color in the future..

I say this as I can see changes happening on a daily basis and this seems a sensible way (to me) to keep the releases of firmware to a minimum and be less confusing overall.

What is the general opinion here?

Is is feasible?

Regards,

Mik

Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<<

seco61
Senior Member

Joined: 15/06/2011
Location: Australia
Posts: 205

Posted: 07:54am 03 Aug 2011

Copy link to clipboard

Print this post

Hi Mik.

With the current version of the firmware, including the I2C and PWM code, we are still using less than 33% of the available 512K codespace. As a fair proportion of this is the required C runtime library, the increase caused by additions to the code is very minimal.

The available data memory is another story. There is only 128K to start with, and after the requirements of the C library, MMBasic programs, variables and buffers etc), we have a heap of 42000 bytes that has to contain program strings and arrays. Also we have a stack size of 6144 bytes - however the heap and stack are one area (6144 + 42000) with the stack at the top (growing down) and the heap at the bottom (growing up).

When additions are made to the firmware that require static data memory (ie buffers, arrays to hold custom fonts, arrays to hold colour information etc), the available heap will decrease. However, unless there is a need for very large program arrays, the current heap should be more than ample - even if it dropped to 35000 bytes (plus the 6144 bytes for the stack) this would still be OK for pretty much any implementation I can think of.

Also, it would be extremely difficult (if not impossible) to add "firmware functions" on the fly from an SD Card. Issues of relocatability and address resolution, adding the code to flash (to use a RAM code area will seriously reduce available heap), etc is not a trivial matter.

I do believe that there should only be one "master" version of the firmware - and that will be controled by Geoff. As people make modifications they can be submitted to Geoff for possible inclusion in the "master" firmware.

However, this should not stop anyone modifying the code - it is after all open source and if the modifications do not make it to the official firmware Geoff has created the custom.c and custom.h files where people can add there own commands, functions and operators. As these files will never be altered by Geoff you can place your custom code there and recompile the firmware when a new official release is available. Of course, if your modifications require changes to existing code, it does become a bit more difficult.

Regards

Gerard (vk3cg/vk3grs)Edited by seco61 2011-08-04

Regards

Gerard (vk3cg/vk3grs)

bigmik

Guru

Joined: 20/06/2011
Location: Australia
Posts: 2914

Posted: 08:16am 03 Aug 2011

Copy link to clipboard

Print this post

seco61 said Hi Mik.

With the current version of the firmware, including the I2C and PWM code, we are still using less than 33% of the available 512K codespace. As a fair proportion of this is the required C runtime library, the increase caused by additions to the code is very minimal.

Thanks Mate,

Obviously shows up my lack of knowledge of the `environment'.

Oh well was a good idea while it lasted, and it sounds like everything can be added with a minimum of fuss

Regards,

Mick

Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<<

Gadget
Regular Member

Joined: 22/06/2011
Location: Australia
Posts: 70

Posted: 03:21am 04 Aug 2011

Copy link to clipboard

Print this post

hi,

The way i see it the latest .HEX file posted is ~460k, this is in intel hex32 format
(details of format attached)2011-08-04_131834_hex32.zip

as this is an ASCII representation the actal data stored in the chip is much smaller, as Gerard says, appros 33% of the available storage is used, so there is plenty of room to add more features without the risk of running out of space.

(my 5c worth since they dont make 2c coins)

Terry

stuarts

Senior Member

Joined: 15/06/2011
Location: Australia
Posts: 199

Posted: 11:55am 04 Aug 2011

Copy link to clipboard

Print this post

Gadget, to avoid inflation, I have heaps of 2c pieces that I could sell you.

Time is nature's way of keeping everything from happening all at once.

wizard

Newbie

Joined: 29/07/2011
Location: United States
Posts: 38

Posted: 01:59pm 04 Aug 2011

Copy link to clipboard

Print this post

Not to say it again, but

Seems like RAM loadable 'kernel' module would be a pretty good answer.....

Wiz

Print this page

To reply to this topic, you need to log in.