Mixing
Increase memory of an ATmega32
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
1
down vote
favorite
1
I bought an ATmega32 IC recently, but now I found out the program I wrote in Atmel Studio reports an error due to an overflow of memory. It is 134.1% over the recommended memory of this chip. Are there alternatives that exist?
I don't want to go and buy another chip as they are quite expensive.
atmega atmel
edited Aug 21 at 21:30
Peter Mortensen
1,56231422
asked Aug 21 at 11:42
Joey
468
 |Â
show 2 more comments
up vote
1
down vote
favorite
1
I bought an ATmega32 IC recently, but now I found out the program I wrote in Atmel Studio reports an error due to an overflow of memory. It is 134.1% over the recommended memory of this chip. Are there alternatives that exist?
I don't want to go and buy another chip as they are quite expensive.
atmega atmel
edited Aug 21 at 21:30
Peter Mortensen
1,56231422
asked Aug 21 at 11:42
Joey
468
13
If you insist on using that chip then your only option is to improve your code.
– Transistor
Aug 21 at 11:49
8
32KB is a lot of program memory, which suggests either you have a very complex application or you should be able to find a lot of ways of reducing size. Are you using any add-on libraries or an RTOS, if so can you try rewriting without them? If you're using floating point, can you rewrite to only use integer arithmetic?
– Jules
Aug 21 at 11:52
5
Do you have -Os optimisations turned on?
– Jon
Aug 21 at 11:59
2
It's also handy to minimize the amount of strings you (say) would want to print over the serial. Those can get pretty large fast. Also, you could also store some large, not too often accessed constants in the EEPROM, if you have any space left there.
– Richard the Spacecat
Aug 21 at 12:04
4
Program memory or RAM? The latter is a lot smaller and easier to fill with e.g. constant data, which the compiler has to arrange to appear in RAM, since you can't access the program memory with the same instructions as RAM.
– ilkkachu
Aug 21 at 15:26
 |Â
show 2 more comments
up vote
1
down vote
favorite
1
up vote
1
down vote
favorite
1
1
I bought an ATmega32 IC recently, but now I found out the program I wrote in Atmel Studio reports an error due to an overflow of memory. It is 134.1% over the recommended memory of this chip. Are there alternatives that exist?
I don't want to go and buy another chip as they are quite expensive.
atmega atmel
edited Aug 21 at 21:30
Peter Mortensen
1,56231422
asked Aug 21 at 11:42
Joey
468
I bought an ATmega32 IC recently, but now I found out the program I wrote in Atmel Studio reports an error due to an overflow of memory. It is 134.1% over the recommended memory of this chip. Are there alternatives that exist?
I don't want to go and buy another chip as they are quite expensive.
atmega atmel
edited Aug 21 at 21:30
Peter Mortensen
1,56231422
asked Aug 21 at 11:42
Joey
468
edited Aug 21 at 21:30
Peter Mortensen
1,56231422
edited Aug 21 at 21:30
Peter Mortensen
1,56231422
edited Aug 21 at 21:30
Peter Mortensen
1,56231422
1,56231422
asked Aug 21 at 11:42
Joey
468
asked Aug 21 at 11:42
Joey
468
asked Aug 21 at 11:42
Joey
468
468
13
If you insist on using that chip then your only option is to improve your code.
– Transistor
Aug 21 at 11:49
8
32KB is a lot of program memory, which suggests either you have a very complex application or you should be able to find a lot of ways of reducing size. Are you using any add-on libraries or an RTOS, if so can you try rewriting without them? If you're using floating point, can you rewrite to only use integer arithmetic?
– Jules
Aug 21 at 11:52
5
Do you have -Os optimisations turned on?
– Jon
Aug 21 at 11:59
2
It's also handy to minimize the amount of strings you (say) would want to print over the serial. Those can get pretty large fast. Also, you could also store some large, not too often accessed constants in the EEPROM, if you have any space left there.
– Richard the Spacecat
Aug 21 at 12:04
4
Program memory or RAM? The latter is a lot smaller and easier to fill with e.g. constant data, which the compiler has to arrange to appear in RAM, since you can't access the program memory with the same instructions as RAM.
– ilkkachu
Aug 21 at 15:26
 |Â
show 2 more comments
13
If you insist on using that chip then your only option is to improve your code.
– Transistor
Aug 21 at 11:49
8
32KB is a lot of program memory, which suggests either you have a very complex application or you should be able to find a lot of ways of reducing size. Are you using any add-on libraries or an RTOS, if so can you try rewriting without them? If you're using floating point, can you rewrite to only use integer arithmetic?
– Jules
Aug 21 at 11:52
5
Do you have -Os optimisations turned on?
– Jon
Aug 21 at 11:59
2
It's also handy to minimize the amount of strings you (say) would want to print over the serial. Those can get pretty large fast. Also, you could also store some large, not too often accessed constants in the EEPROM, if you have any space left there.
– Richard the Spacecat
Aug 21 at 12:04
4
Program memory or RAM? The latter is a lot smaller and easier to fill with e.g. constant data, which the compiler has to arrange to appear in RAM, since you can't access the program memory with the same instructions as RAM.
– ilkkachu
Aug 21 at 15:26
13
13
If you insist on using that chip then your only option is to improve your code.
– Transistor
Aug 21 at 11:49
If you insist on using that chip then your only option is to improve your code.
– Transistor
Aug 21 at 11:49
8
8
32KB is a lot of program memory, which suggests either you have a very complex application or you should be able to find a lot of ways of reducing size. Are you using any add-on libraries or an RTOS, if so can you try rewriting without them? If you're using floating point, can you rewrite to only use integer arithmetic?
– Jules
Aug 21 at 11:52
32KB is a lot of program memory, which suggests either you have a very complex application or you should be able to find a lot of ways of reducing size. Are you using any add-on libraries or an RTOS, if so can you try rewriting without them? If you're using floating point, can you rewrite to only use integer arithmetic?
– Jules
Aug 21 at 11:52
5
5
Do you have -Os optimisations turned on?
– Jon
Aug 21 at 11:59
Do you have -Os optimisations turned on?
– Jon
Aug 21 at 11:59
2
2
It's also handy to minimize the amount of strings you (say) would want to print over the serial. Those can get pretty large fast. Also, you could also store some large, not too often accessed constants in the EEPROM, if you have any space left there.
– Richard the Spacecat
Aug 21 at 12:04
It's also handy to minimize the amount of strings you (say) would want to print over the serial. Those can get pretty large fast. Also, you could also store some large, not too often accessed constants in the EEPROM, if you have any space left there.
– Richard the Spacecat
Aug 21 at 12:04
4
4
Program memory or RAM? The latter is a lot smaller and easier to fill with e.g. constant data, which the compiler has to arrange to appear in RAM, since you can't access the program memory with the same instructions as RAM.
– ilkkachu
Aug 21 at 15:26
Program memory or RAM? The latter is a lot smaller and easier to fill with e.g. constant data, which the compiler has to arrange to appear in RAM, since you can't access the program memory with the same instructions as RAM.
– ilkkachu
Aug 21 at 15:26
 |Â
show 2 more comments
3 Answers
3
active
oldest
votes
up vote
3
down vote
accepted
Atmega32 is like a stripped down Atmega644x or Atmega1284P. Change the chip to get a lot more memory, more SRAM (up to 16K bytes), and dual hardware serial ports.
answered Aug 21 at 17:01
CrossRoads
3914
For some bizarre reason the atmega 1284 is priced alot cheaper than the atmega 32 but it has more memory. Wouldn't have expected that when I Google it. Thanks for the advice. This new chip does solve the whole problem
– Joey
Aug 25 at 9:40
add a comment |Â
up vote
9
down vote
Global variables/types
- Changing the type of global variables (e.g. use uint8_t or a similar 1 byte instead of long), or use bits to store boolean arrays.
- Remove static variables and replace them by dynamic (local) variables if possible. Passing them as arguments might be used to keep the scope longer.
Data/precalculated tables
- In case you now keep (fixed) data structures in your code (e.g. for pre calculated tables), than put these in external Flash. Executable code is hard to put in external Flash, but tables/data is not. Of course this comes with a performance loss. Another way is to calculate it on the fly (no calculated table needed at all).
- Instead of using pre calculated data tables at all, calculate them; this might cause a performance loss.
- In case you are using a lot of stored texts or data, 'compress' them if possible. The decompression code will cost some Flash, but if you have a lot of text, it might be worthwhile.
Executable code
- Using for loops instead of calling functions one by one.
- Check for repeated code and create functions of them, use parameters to differ between small changes; this will cause a (small) performance loss.
- Prevent 'inline' or long #define statements/code, these are substituted
(copied) wherever used.
Logging/tracing
logging strings can consume many bytes (e.g. for one log string like: "The current temperature is: " cost 29 bytes). Having many log strings can add up a lot. To prevent this you can:
- Use shorter strings ("CurTemp: " is only 9 bytes).
- Print an integer (cost 1 or 2 bytes, depending on the int size).
- Send this integer to another microcontroller which converts it to human readable text. It cost a bit of overhead/peripheral overhead.
- When debugging, put all logging in #ifdefs, and save Flash by reducing functionality you don't need for testing. When not debugging, all logging statements will not cost any bytes.
Libraries
- Finding alternative libraries which are implemented differently but with the functionality you need.
Compiler options
- Check compiler options to see if the code can be compiled in a different way; mostly it will be a trade off against performance.
What you should NOT do
- Make your code a few bytes smaller by using obscure code implementation. This will bite you later when you maintain your application.
- Removing unused functions does not help (the compiler is smart enough to do this for you).
answered Aug 21 at 12:17
Michel Keijzers
4,63742149
1
Remember to differentiate between data and program size. The question probably refers to program size (though it does not actually say which). Things like buffers won't really figure into that, but various ways of handling data can cost more program size.
– Chris Stratton
Aug 21 at 13:00
1
First point can be misleading: there's no guarantee (in general) that changing to a smaller variable size leads to savings. In this case, it should as it's an 8bit device. I would also avoid "char" for variables - use actual integer types like uint8_t, for example, rather than something that happens to be 8bits wide.
– awjlogan
Aug 21 at 13:01
1
@awjlogan uint8_t is indeed better, and with int I meant a bigger type, I adapted my answer, thanks for the notification.
– Michel Keijzers
Aug 21 at 13:49
2
@awjloganuint8_tis not "actual integer type": it's atypedef, and most likely tounsigned char(dunno what types ATmega actually has).
– Ruslan
Aug 21 at 15:34
1
@awjlogan I only use (u)int8/16/32t types for integer (like) types, to prevent microprocessor related issued. and char for characters like 'a'. For booleans I normally make an own type (bool_t which is defined as unsigned char_t).
– Michel Keijzers
Aug 21 at 15:56
 |Â
show 10 more comments
up vote
5
down vote
Unfortunately, adding external program memory is not usualy possible with this kind of chip. You could conceivably read and execute code from an external flash, but it would likely be slow and unstable.
You may be able to reduce the size of the compiled code, by eliminating static variables and removing unused libraries.
If you cannot find a way to to reduce the code size, you can look at MCUs of the same architecture here: https://www.microchip.com/design-centers/8-bit/avr-mcus
answered Aug 21 at 11:56
Tim Vrakas
1348
1
I wanted to add that an AVR controller can execute code only in its FLASH memory. Loading code from an external source would either require burning it into the internal flash, which is a stupid idea, or an emulator that parses the opcodes in software. A chip with more memory is the solution to go for if the code size cannot be reduced.
– GNA
Aug 21 at 14:07
add a comment |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
accepted
Atmega32 is like a stripped down Atmega644x or Atmega1284P. Change the chip to get a lot more memory, more SRAM (up to 16K bytes), and dual hardware serial ports.
answered Aug 21 at 17:01
CrossRoads
3914
For some bizarre reason the atmega 1284 is priced alot cheaper than the atmega 32 but it has more memory. Wouldn't have expected that when I Google it. Thanks for the advice. This new chip does solve the whole problem
– Joey
Aug 25 at 9:40
add a comment |Â
up vote
3
down vote
accepted
Atmega32 is like a stripped down Atmega644x or Atmega1284P. Change the chip to get a lot more memory, more SRAM (up to 16K bytes), and dual hardware serial ports.
answered Aug 21 at 17:01
CrossRoads
3914
For some bizarre reason the atmega 1284 is priced alot cheaper than the atmega 32 but it has more memory. Wouldn't have expected that when I Google it. Thanks for the advice. This new chip does solve the whole problem
– Joey
Aug 25 at 9:40
add a comment |Â
up vote
3
down vote
accepted
up vote
3
down vote
accepted
Atmega32 is like a stripped down Atmega644x or Atmega1284P. Change the chip to get a lot more memory, more SRAM (up to 16K bytes), and dual hardware serial ports.
answered Aug 21 at 17:01
CrossRoads
3914
Atmega32 is like a stripped down Atmega644x or Atmega1284P. Change the chip to get a lot more memory, more SRAM (up to 16K bytes), and dual hardware serial ports.
answered Aug 21 at 17:01
CrossRoads
3914
answered Aug 21 at 17:01
CrossRoads
3914
answered Aug 21 at 17:01
CrossRoads
3914
answered Aug 21 at 17:01
CrossRoads
3914
3914
For some bizarre reason the atmega 1284 is priced alot cheaper than the atmega 32 but it has more memory. Wouldn't have expected that when I Google it. Thanks for the advice. This new chip does solve the whole problem
– Joey
Aug 25 at 9:40
add a comment |Â
For some bizarre reason the atmega 1284 is priced alot cheaper than the atmega 32 but it has more memory. Wouldn't have expected that when I Google it. Thanks for the advice. This new chip does solve the whole problem
– Joey
Aug 25 at 9:40
For some bizarre reason the atmega 1284 is priced alot cheaper than the atmega 32 but it has more memory. Wouldn't have expected that when I Google it. Thanks for the advice. This new chip does solve the whole problem
– Joey
Aug 25 at 9:40
For some bizarre reason the atmega 1284 is priced alot cheaper than the atmega 32 but it has more memory. Wouldn't have expected that when I Google it. Thanks for the advice. This new chip does solve the whole problem
– Joey
Aug 25 at 9:40
add a comment |Â
up vote
9
down vote
Global variables/types
- Changing the type of global variables (e.g. use uint8_t or a similar 1 byte instead of long), or use bits to store boolean arrays.
- Remove static variables and replace them by dynamic (local) variables if possible. Passing them as arguments might be used to keep the scope longer.
Data/precalculated tables
- In case you now keep (fixed) data structures in your code (e.g. for pre calculated tables), than put these in external Flash. Executable code is hard to put in external Flash, but tables/data is not. Of course this comes with a performance loss. Another way is to calculate it on the fly (no calculated table needed at all).
- Instead of using pre calculated data tables at all, calculate them; this might cause a performance loss.
- In case you are using a lot of stored texts or data, 'compress' them if possible. The decompression code will cost some Flash, but if you have a lot of text, it might be worthwhile.
Executable code
- Using for loops instead of calling functions one by one.
- Check for repeated code and create functions of them, use parameters to differ between small changes; this will cause a (small) performance loss.
- Prevent 'inline' or long #define statements/code, these are substituted
(copied) wherever used.
Logging/tracing
logging strings can consume many bytes (e.g. for one log string like: "The current temperature is: " cost 29 bytes). Having many log strings can add up a lot. To prevent this you can:
- Use shorter strings ("CurTemp: " is only 9 bytes).
- Print an integer (cost 1 or 2 bytes, depending on the int size).
- Send this integer to another microcontroller which converts it to human readable text. It cost a bit of overhead/peripheral overhead.
- When debugging, put all logging in #ifdefs, and save Flash by reducing functionality you don't need for testing. When not debugging, all logging statements will not cost any bytes.
Libraries
- Finding alternative libraries which are implemented differently but with the functionality you need.
Compiler options
- Check compiler options to see if the code can be compiled in a different way; mostly it will be a trade off against performance.
What you should NOT do
- Make your code a few bytes smaller by using obscure code implementation. This will bite you later when you maintain your application.
- Removing unused functions does not help (the compiler is smart enough to do this for you).
answered Aug 21 at 12:17
Michel Keijzers
4,63742149
1
Remember to differentiate between data and program size. The question probably refers to program size (though it does not actually say which). Things like buffers won't really figure into that, but various ways of handling data can cost more program size.
– Chris Stratton
Aug 21 at 13:00
1
First point can be misleading: there's no guarantee (in general) that changing to a smaller variable size leads to savings. In this case, it should as it's an 8bit device. I would also avoid "char" for variables - use actual integer types like uint8_t, for example, rather than something that happens to be 8bits wide.
– awjlogan
Aug 21 at 13:01
1
@awjlogan uint8_t is indeed better, and with int I meant a bigger type, I adapted my answer, thanks for the notification.
– Michel Keijzers
Aug 21 at 13:49
2
@awjloganuint8_tis not "actual integer type": it's atypedef, and most likely tounsigned char(dunno what types ATmega actually has).
– Ruslan
Aug 21 at 15:34
1
@awjlogan I only use (u)int8/16/32t types for integer (like) types, to prevent microprocessor related issued. and char for characters like 'a'. For booleans I normally make an own type (bool_t which is defined as unsigned char_t).
– Michel Keijzers
Aug 21 at 15:56
 |Â
show 10 more comments
up vote
9
down vote
Global variables/types
- Changing the type of global variables (e.g. use uint8_t or a similar 1 byte instead of long), or use bits to store boolean arrays.
- Remove static variables and replace them by dynamic (local) variables if possible. Passing them as arguments might be used to keep the scope longer.
Data/precalculated tables
- In case you now keep (fixed) data structures in your code (e.g. for pre calculated tables), than put these in external Flash. Executable code is hard to put in external Flash, but tables/data is not. Of course this comes with a performance loss. Another way is to calculate it on the fly (no calculated table needed at all).
- Instead of using pre calculated data tables at all, calculate them; this might cause a performance loss.
- In case you are using a lot of stored texts or data, 'compress' them if possible. The decompression code will cost some Flash, but if you have a lot of text, it might be worthwhile.
Executable code
- Using for loops instead of calling functions one by one.
- Check for repeated code and create functions of them, use parameters to differ between small changes; this will cause a (small) performance loss.
- Prevent 'inline' or long #define statements/code, these are substituted
(copied) wherever used.
Logging/tracing
logging strings can consume many bytes (e.g. for one log string like: "The current temperature is: " cost 29 bytes). Having many log strings can add up a lot. To prevent this you can:
- Use shorter strings ("CurTemp: " is only 9 bytes).
- Print an integer (cost 1 or 2 bytes, depending on the int size).
- Send this integer to another microcontroller which converts it to human readable text. It cost a bit of overhead/peripheral overhead.
- When debugging, put all logging in #ifdefs, and save Flash by reducing functionality you don't need for testing. When not debugging, all logging statements will not cost any bytes.
Libraries
- Finding alternative libraries which are implemented differently but with the functionality you need.
Compiler options
- Check compiler options to see if the code can be compiled in a different way; mostly it will be a trade off against performance.
What you should NOT do
- Make your code a few bytes smaller by using obscure code implementation. This will bite you later when you maintain your application.
- Removing unused functions does not help (the compiler is smart enough to do this for you).
answered Aug 21 at 12:17
Michel Keijzers
4,63742149
1
Remember to differentiate between data and program size. The question probably refers to program size (though it does not actually say which). Things like buffers won't really figure into that, but various ways of handling data can cost more program size.
– Chris Stratton
Aug 21 at 13:00
1
First point can be misleading: there's no guarantee (in general) that changing to a smaller variable size leads to savings. In this case, it should as it's an 8bit device. I would also avoid "char" for variables - use actual integer types like uint8_t, for example, rather than something that happens to be 8bits wide.
– awjlogan
Aug 21 at 13:01
1
@awjlogan uint8_t is indeed better, and with int I meant a bigger type, I adapted my answer, thanks for the notification.
– Michel Keijzers
Aug 21 at 13:49
2
@awjloganuint8_tis not "actual integer type": it's atypedef, and most likely tounsigned char(dunno what types ATmega actually has).
– Ruslan
Aug 21 at 15:34
1
@awjlogan I only use (u)int8/16/32t types for integer (like) types, to prevent microprocessor related issued. and char for characters like 'a'. For booleans I normally make an own type (bool_t which is defined as unsigned char_t).
– Michel Keijzers
Aug 21 at 15:56
 |Â
show 10 more comments
up vote
9
down vote
up vote
9
down vote
Global variables/types
- Changing the type of global variables (e.g. use uint8_t or a similar 1 byte instead of long), or use bits to store boolean arrays.
- Remove static variables and replace them by dynamic (local) variables if possible. Passing them as arguments might be used to keep the scope longer.
Data/precalculated tables
- In case you now keep (fixed) data structures in your code (e.g. for pre calculated tables), than put these in external Flash. Executable code is hard to put in external Flash, but tables/data is not. Of course this comes with a performance loss. Another way is to calculate it on the fly (no calculated table needed at all).
- Instead of using pre calculated data tables at all, calculate them; this might cause a performance loss.
- In case you are using a lot of stored texts or data, 'compress' them if possible. The decompression code will cost some Flash, but if you have a lot of text, it might be worthwhile.
Executable code
- Using for loops instead of calling functions one by one.
- Check for repeated code and create functions of them, use parameters to differ between small changes; this will cause a (small) performance loss.
- Prevent 'inline' or long #define statements/code, these are substituted
(copied) wherever used.
Logging/tracing
logging strings can consume many bytes (e.g. for one log string like: "The current temperature is: " cost 29 bytes). Having many log strings can add up a lot. To prevent this you can:
- Use shorter strings ("CurTemp: " is only 9 bytes).
- Print an integer (cost 1 or 2 bytes, depending on the int size).
- Send this integer to another microcontroller which converts it to human readable text. It cost a bit of overhead/peripheral overhead.
- When debugging, put all logging in #ifdefs, and save Flash by reducing functionality you don't need for testing. When not debugging, all logging statements will not cost any bytes.
Libraries
- Finding alternative libraries which are implemented differently but with the functionality you need.
Compiler options
- Check compiler options to see if the code can be compiled in a different way; mostly it will be a trade off against performance.
What you should NOT do
- Make your code a few bytes smaller by using obscure code implementation. This will bite you later when you maintain your application.
- Removing unused functions does not help (the compiler is smart enough to do this for you).
answered Aug 21 at 12:17
Michel Keijzers
4,63742149
Global variables/types
- Changing the type of global variables (e.g. use uint8_t or a similar 1 byte instead of long), or use bits to store boolean arrays.
- Remove static variables and replace them by dynamic (local) variables if possible. Passing them as arguments might be used to keep the scope longer.
Data/precalculated tables
- In case you now keep (fixed) data structures in your code (e.g. for pre calculated tables), than put these in external Flash. Executable code is hard to put in external Flash, but tables/data is not. Of course this comes with a performance loss. Another way is to calculate it on the fly (no calculated table needed at all).
- Instead of using pre calculated data tables at all, calculate them; this might cause a performance loss.
- In case you are using a lot of stored texts or data, 'compress' them if possible. The decompression code will cost some Flash, but if you have a lot of text, it might be worthwhile.
Executable code
- Using for loops instead of calling functions one by one.
- Check for repeated code and create functions of them, use parameters to differ between small changes; this will cause a (small) performance loss.
- Prevent 'inline' or long #define statements/code, these are substituted
(copied) wherever used.
Logging/tracing
logging strings can consume many bytes (e.g. for one log string like: "The current temperature is: " cost 29 bytes). Having many log strings can add up a lot. To prevent this you can:
- Use shorter strings ("CurTemp: " is only 9 bytes).
- Print an integer (cost 1 or 2 bytes, depending on the int size).
- Send this integer to another microcontroller which converts it to human readable text. It cost a bit of overhead/peripheral overhead.
- When debugging, put all logging in #ifdefs, and save Flash by reducing functionality you don't need for testing. When not debugging, all logging statements will not cost any bytes.
Libraries
- Finding alternative libraries which are implemented differently but with the functionality you need.
Compiler options
- Check compiler options to see if the code can be compiled in a different way; mostly it will be a trade off against performance.
What you should NOT do
- Make your code a few bytes smaller by using obscure code implementation. This will bite you later when you maintain your application.
- Removing unused functions does not help (the compiler is smart enough to do this for you).
answered Aug 21 at 12:17
Michel Keijzers
4,63742149
edited Aug 21 at 21:54
answered Aug 21 at 12:17
Michel Keijzers
4,63742149
answered Aug 21 at 12:17
Michel Keijzers
4,63742149
answered Aug 21 at 12:17
Michel Keijzers
4,63742149
4,63742149
1
Remember to differentiate between data and program size. The question probably refers to program size (though it does not actually say which). Things like buffers won't really figure into that, but various ways of handling data can cost more program size.
– Chris Stratton
Aug 21 at 13:00
1
First point can be misleading: there's no guarantee (in general) that changing to a smaller variable size leads to savings. In this case, it should as it's an 8bit device. I would also avoid "char" for variables - use actual integer types like uint8_t, for example, rather than something that happens to be 8bits wide.
– awjlogan
Aug 21 at 13:01
1
@awjlogan uint8_t is indeed better, and with int I meant a bigger type, I adapted my answer, thanks for the notification.
– Michel Keijzers
Aug 21 at 13:49
2
@awjloganuint8_tis not "actual integer type": it's atypedef, and most likely tounsigned char(dunno what types ATmega actually has).
– Ruslan
Aug 21 at 15:34
1
@awjlogan I only use (u)int8/16/32t types for integer (like) types, to prevent microprocessor related issued. and char for characters like 'a'. For booleans I normally make an own type (bool_t which is defined as unsigned char_t).
– Michel Keijzers
Aug 21 at 15:56
 |Â
show 10 more comments
1
Remember to differentiate between data and program size. The question probably refers to program size (though it does not actually say which). Things like buffers won't really figure into that, but various ways of handling data can cost more program size.
– Chris Stratton
Aug 21 at 13:00
1
First point can be misleading: there's no guarantee (in general) that changing to a smaller variable size leads to savings. In this case, it should as it's an 8bit device. I would also avoid "char" for variables - use actual integer types like uint8_t, for example, rather than something that happens to be 8bits wide.
– awjlogan
Aug 21 at 13:01
1
@awjlogan uint8_t is indeed better, and with int I meant a bigger type, I adapted my answer, thanks for the notification.
– Michel Keijzers
Aug 21 at 13:49
2
@awjloganuint8_tis not "actual integer type": it's atypedef, and most likely tounsigned char(dunno what types ATmega actually has).
– Ruslan
Aug 21 at 15:34
1
@awjlogan I only use (u)int8/16/32t types for integer (like) types, to prevent microprocessor related issued. and char for characters like 'a'. For booleans I normally make an own type (bool_t which is defined as unsigned char_t).
– Michel Keijzers
Aug 21 at 15:56
1
1
Remember to differentiate between data and program size. The question probably refers to program size (though it does not actually say which). Things like buffers won't really figure into that, but various ways of handling data can cost more program size.
– Chris Stratton
Aug 21 at 13:00
Remember to differentiate between data and program size. The question probably refers to program size (though it does not actually say which). Things like buffers won't really figure into that, but various ways of handling data can cost more program size.
– Chris Stratton
Aug 21 at 13:00
1
1
First point can be misleading: there's no guarantee (in general) that changing to a smaller variable size leads to savings. In this case, it should as it's an 8bit device. I would also avoid "char" for variables - use actual integer types like uint8_t, for example, rather than something that happens to be 8bits wide.
– awjlogan
Aug 21 at 13:01
First point can be misleading: there's no guarantee (in general) that changing to a smaller variable size leads to savings. In this case, it should as it's an 8bit device. I would also avoid "char" for variables - use actual integer types like uint8_t, for example, rather than something that happens to be 8bits wide.
– awjlogan
Aug 21 at 13:01
1
1
@awjlogan uint8_t is indeed better, and with int I meant a bigger type, I adapted my answer, thanks for the notification.
– Michel Keijzers
Aug 21 at 13:49
@awjlogan uint8_t is indeed better, and with int I meant a bigger type, I adapted my answer, thanks for the notification.
– Michel Keijzers
Aug 21 at 13:49
2
2
@awjlogan
uint8_t is not "actual integer type": it's a typedef, and most likely to unsigned char (dunno what types ATmega actually has).– Ruslan
Aug 21 at 15:34
@awjlogan
uint8_t is not "actual integer type": it's a typedef, and most likely to unsigned char (dunno what types ATmega actually has).– Ruslan
Aug 21 at 15:34
1
1
@awjlogan I only use (u)int8/16/32t types for integer (like) types, to prevent microprocessor related issued. and char for characters like 'a'. For booleans I normally make an own type (bool_t which is defined as unsigned char_t).
– Michel Keijzers
Aug 21 at 15:56
@awjlogan I only use (u)int8/16/32t types for integer (like) types, to prevent microprocessor related issued. and char for characters like 'a'. For booleans I normally make an own type (bool_t which is defined as unsigned char_t).
– Michel Keijzers
Aug 21 at 15:56
 |Â
show 10 more comments
up vote
5
down vote
Unfortunately, adding external program memory is not usualy possible with this kind of chip. You could conceivably read and execute code from an external flash, but it would likely be slow and unstable.
You may be able to reduce the size of the compiled code, by eliminating static variables and removing unused libraries.
If you cannot find a way to to reduce the code size, you can look at MCUs of the same architecture here: https://www.microchip.com/design-centers/8-bit/avr-mcus
answered Aug 21 at 11:56
Tim Vrakas
1348
1
I wanted to add that an AVR controller can execute code only in its FLASH memory. Loading code from an external source would either require burning it into the internal flash, which is a stupid idea, or an emulator that parses the opcodes in software. A chip with more memory is the solution to go for if the code size cannot be reduced.
– GNA
Aug 21 at 14:07
add a comment |Â
up vote
5
down vote
Unfortunately, adding external program memory is not usualy possible with this kind of chip. You could conceivably read and execute code from an external flash, but it would likely be slow and unstable.
You may be able to reduce the size of the compiled code, by eliminating static variables and removing unused libraries.
If you cannot find a way to to reduce the code size, you can look at MCUs of the same architecture here: https://www.microchip.com/design-centers/8-bit/avr-mcus
answered Aug 21 at 11:56
Tim Vrakas
1348
1
I wanted to add that an AVR controller can execute code only in its FLASH memory. Loading code from an external source would either require burning it into the internal flash, which is a stupid idea, or an emulator that parses the opcodes in software. A chip with more memory is the solution to go for if the code size cannot be reduced.
– GNA
Aug 21 at 14:07
add a comment |Â
up vote
5
down vote
up vote
5
down vote
Unfortunately, adding external program memory is not usualy possible with this kind of chip. You could conceivably read and execute code from an external flash, but it would likely be slow and unstable.
You may be able to reduce the size of the compiled code, by eliminating static variables and removing unused libraries.
If you cannot find a way to to reduce the code size, you can look at MCUs of the same architecture here: https://www.microchip.com/design-centers/8-bit/avr-mcus
answered Aug 21 at 11:56
Tim Vrakas
1348
Unfortunately, adding external program memory is not usualy possible with this kind of chip. You could conceivably read and execute code from an external flash, but it would likely be slow and unstable.
You may be able to reduce the size of the compiled code, by eliminating static variables and removing unused libraries.
If you cannot find a way to to reduce the code size, you can look at MCUs of the same architecture here: https://www.microchip.com/design-centers/8-bit/avr-mcus
answered Aug 21 at 11:56
Tim Vrakas
1348
answered Aug 21 at 11:56
Tim Vrakas
1348
answered Aug 21 at 11:56
Tim Vrakas
1348
answered Aug 21 at 11:56
Tim Vrakas
1348
1348
1
I wanted to add that an AVR controller can execute code only in its FLASH memory. Loading code from an external source would either require burning it into the internal flash, which is a stupid idea, or an emulator that parses the opcodes in software. A chip with more memory is the solution to go for if the code size cannot be reduced.
– GNA
Aug 21 at 14:07
add a comment |Â
1
I wanted to add that an AVR controller can execute code only in its FLASH memory. Loading code from an external source would either require burning it into the internal flash, which is a stupid idea, or an emulator that parses the opcodes in software. A chip with more memory is the solution to go for if the code size cannot be reduced.
– GNA
Aug 21 at 14:07
1
1
I wanted to add that an AVR controller can execute code only in its FLASH memory. Loading code from an external source would either require burning it into the internal flash, which is a stupid idea, or an emulator that parses the opcodes in software. A chip with more memory is the solution to go for if the code size cannot be reduced.
– GNA
Aug 21 at 14:07
I wanted to add that an AVR controller can execute code only in its FLASH memory. Loading code from an external source would either require burning it into the internal flash, which is a stupid idea, or an emulator that parses the opcodes in software. A chip with more memory is the solution to go for if the code size cannot be reduced.
– GNA
Aug 21 at 14:07
add a comment |Â
Â
draft saved
draft discarded
Â
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f392041%2fincrease-memory-of-an-atmega32%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
13
If you insist on using that chip then your only option is to improve your code.
– Transistor
Aug 21 at 11:49
8
32KB is a lot of program memory, which suggests either you have a very complex application or you should be able to find a lot of ways of reducing size. Are you using any add-on libraries or an RTOS, if so can you try rewriting without them? If you're using floating point, can you rewrite to only use integer arithmetic?
– Jules
Aug 21 at 11:52
5
Do you have -Os optimisations turned on?
– Jon
Aug 21 at 11:59
2
It's also handy to minimize the amount of strings you (say) would want to print over the serial. Those can get pretty large fast. Also, you could also store some large, not too often accessed constants in the EEPROM, if you have any space left there.
– Richard the Spacecat
Aug 21 at 12:04
4
Program memory or RAM? The latter is a lot smaller and easier to fill with e.g. constant data, which the compiler has to arrange to appear in RAM, since you can't access the program memory with the same instructions as RAM.
– ilkkachu
Aug 21 at 15:26