AVR boot loader question

Share unrelated electronics stuff, ideas, rants, etc!
Post Reply
User avatar
mapes
Posts: 147
Joined: Sun Feb 13, 2011 7:04 am
Location: Seattle

AVR boot loader question

Post by mapes » Sat Sep 07, 2013 9:25 pm

I'm working on an arduino project that uses the Atmega328 chip which is limited to 2K ram but run into an issue were I run out of RAM, however I have available PROGMEM space.

The program uses an LCD screen to display real time information from sensors but also has menus for changing configurations using buttons.

Is there a way to split up the individual sketch into 2 sketches which would both reside in the program memory and load only the 1 sketch based on holding a button? (similar to the Uzebox bootloader starting when holding a button)

I haven't seen anything like this out there in the wild, but I want to know if someone who knows enough about this could tell me if its feasible.

The big problem I could see is trying to upload the 2 different sketches without erasing the first.

V/r,

-Mapes

User avatar
uze6666
Site Admin
Posts: 4487
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: AVR boot loader question

Post by uze6666 » Sun Sep 08, 2013 12:38 am

Hi,

I may help on that, however can you elaborate on what's a sketch?

User avatar
mapes
Posts: 147
Joined: Sun Feb 13, 2011 7:04 am
Location: Seattle

Re: AVR boot loader question

Post by mapes » Sun Sep 08, 2013 5:07 pm

uze6666 wrote:Hi,

I may help on that, however can you elaborate on what's a sketch?
A sketch is alot like an .uze or .hex file for the arduino platform. Usually, the arduino is loaded with an 'adruino' standard boot loader on an Atmega328 chip that allows it to flashed via a usb cable instead of an ICSP cable. Check our http://arduino.cc for some more details.

You can find Atmega328 chips with the boot loader pre-loaded on them all over the internet (amazon, ebay, etc).

I was thinking of possible solutions and one may be to run the menu first and then clear all of the RAM from the menu before proceeding to the main program, however that may not be possible. I'm slightly confused on freeing RAM on the Atmega / the arduino platform, or if it is not possible.

V/r,

-Mapes

CunningFellow
Posts: 1192
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: AVR boot loader question

Post by CunningFellow » Sun Sep 08, 2013 9:44 pm

mapes,

The two obvious solutions are

1, Get a bigger chip.
2, Be more frugal with RAM.

number 2 might be as simple as storing statics in flash and using "heap" variables rather than globals.

User avatar
mapes
Posts: 147
Joined: Sun Feb 13, 2011 7:04 am
Location: Seattle

Re: AVR boot loader question

Post by mapes » Sun Sep 08, 2013 11:09 pm

CunningFellow wrote:mapes,

The two obvious solutions are

1, Get a bigger chip.
2, Be more frugal with RAM.

number 2 might be as simple as storing statics in flash and using "heap" variables rather than globals.
I am well aware of option 1, however I would prefer staying with the Atmega328 architecture because it is a PDIP configuration and small size. I have considered the 644, but it would take alot of room on a PCB and require us to our redesign our existing the PCB.

Option 2: I'm trying this one right now.

But I'm still looking at alternative solutions such as the multi sketch boot loader or RAM dumping the menu after it's complete. That's what I'd like to try to do.

V/r,

-Mapes

CunningFellow
Posts: 1192
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: AVR boot loader question

Post by CunningFellow » Mon Sep 09, 2013 12:15 am

Mapes,

You might do well to drop the "sketch" thing and just learn to use GCC. You can use same hardware and the same boot loader still. You just don't have to use the awful crippled ardweeno libraries.

In vanilla C if you just define a variable inside the scope of a function, then the variables are destroyed automatically at the end of the function and the RAM is free.

Code: Select all

int ShowMenu(void) {

int MenuOption;

blah();
blah();
blah();

return(MenuOption);
}

void ShowRealTimeDate(void) {

int DataSomething;

blah();
blah();
blah();

}
In the code above MenuOption and DataSomething do not take up 4 bytes of RAM. They only take up 2 bytes of RAM.

2K is a lot of RAM for state variables. The UzeBox only has RAM issues because of its 4K a lot of the time 3K + of it is used for the video display.

What kind of things are taking up your 2K of RAM? How much is being used for state variables, how much is being used for sensor data? How much is being used for LCD control?

User avatar
mapes
Posts: 147
Joined: Sun Feb 13, 2011 7:04 am
Location: Seattle

Re: AVR boot loader question

Post by mapes » Mon Sep 16, 2013 7:48 pm

I did some code and variable optmization and I can get the program to work now without needing to split it up.
CunningFellow wrote: You might do well to drop the "sketch" thing and just learn to use GCC. You can use same hardware and the same boot loader still. You just don't have to use the awful crippled ardweeno libraries.
I'm working off of someone elses project, so I'm trying to keep it pretty true to the original form. You can see the original project here :http://dangerpants.com/labs/adi.
CunningFellow wrote: 2K is a lot of RAM for state variables. The UzeBox only has RAM issues because of its 4K a lot of the time 3K + of it is used for the video display.

What kind of things are taking up your 2K of RAM? How much is being used for state variables, how much is being used for sensor data? How much is being used for LCD control?
The main consumption of SRAM is rolling FLOAT buffers for barometric pressure and the incoming air pressure.

I freed up enough SRAM by transferring many of the strings into PROGMEM instead of them sitting in RAM, also I reviewed the code and changed any variables to CHARs when I could. It seemed to free up about 200 to 300 bytes of SRAM which gives me enough to work with and maintain overhead.

V/r,

-Mapes

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest