1
\$\begingroup\$

I have to build a new hardware with a new 32bit microcontroller. I have a working project on an 8bit microconttroller.

When compiling the C program for my new target what will be the needed size of memory I should use on my new 32 bit microcontroller?

If my program is 30kbytes in 8bit, how much flash memory I should use in 32bit? 4 times bigger, or will the compiler store several 8bit bytes n one 32 bit block?

thanks for your help

\$\endgroup\$
4
  • 5
    \$\begingroup\$ There is no answer for this. It depends on what your old MCU was and what is the new MCU, how different are their architectures, and how much is the MCU specific code in each MCU and how much code is your application. Just because you changed from 8 to 32 bit MCU, you don't need four times as much memory. Your application code might even be smaller on the new architecture, but initializing and using the peripherals you need and their driver code can take more memory. You need to try it. \$\endgroup\$
    – Justme
    Nov 12, 2021 at 8:22
  • \$\begingroup\$ 30 kb are 30 kb, the architecture/buswidth does not matter. But the comment of @Justme is true: it is difficult to estimate how big a firmware will be when moved from a CPU to another. Unless you know them very very well. 8 bit MCUs, when used mainly for (simple) logic, tend to produce small code. But for other things a 32 bit MCU can be more space efficient (or maybe not...). You should state, coarsely, what your program does, and what MCUs are you talking about. \$\endgroup\$ Nov 12, 2021 at 8:38
  • \$\begingroup\$ It also depends how the software is written. If you wrote the C code so that you used a lot of 8-bit variables and otherwise did stuff so that things were efficient on the 8-bit MCU when using a specific compiler for that plaform, the code might not be tight and efficient on the 32-bit platform and also the compiler will be different. If it even compiles, as sometimes you need to adapt, port, or rewrite parets of the code to new compiler. \$\endgroup\$
    – Justme
    Nov 12, 2021 at 8:45
  • \$\begingroup\$ Thank you all, for your precious help. @justme you mentionned processor, i intend to port the small application from an 68HC11 8buts to a Risk-V MCU 32 bits. the first reason is that i am afraid of obsolescence and optimization \$\endgroup\$
    – Philippe
    Nov 13, 2021 at 11:49

2 Answers 2

1
\$\begingroup\$

A compiler for a 32 bit architecture will tend to produce 32 bit instruction words. However, those words are likely to be more capable than the words produced for an 8 bit architecture, so you may require fewer to do the same job.

The devil is in the detail, of the old architecture and compiler, of the new architecture and compiler, and of the resources your program needs. You will have to do a compile with both, and find out. There should be no need to have the real target hardware available to compile your program.

\$\endgroup\$
1
  • \$\begingroup\$ It's probably worth mentioning that modern (Arm, RV) 32bit ISAs for microcontrollers tend to also have 16 bit instructions available. This is Thumb/Thumb-2 in Arm and I think an extension to the base RV ISA. All the advantages of the 32 bit core, but reduced code size. \$\endgroup\$
    – awjlogan
    Nov 13, 2021 at 12:49
1
\$\begingroup\$

Instructions for 8 bitters are indeed smaller and generally have a smaller binary. So assume that the code will get bigger.

However, 8 bitters also produce much less efficient code than 32 bitters. So the key is how skilled the person who wrote the original program was. Have they streamlined the source to work well on an 8 bit MCU? Some things to look for:

  • Is it using uint8_t/uint_fast8_t where appropriate, or is it just PC slop with int all over the place?
  • Is it treating implicit promotions with great care, such as using casts back to uint8_t after an operation with implicit int promotions present?
  • Is it avoiding 16 or 32 bit arithmetic?
  • Is it avoiding PC programming nonsense such as stdio.h or floating point arithmetic?
  • Is it avoiding excessive standard library calls in general?

If you find no traces of a skilled C programmer, like in the above examples, then the code might actually end up more compact if ported to 32 bit, if it is calculation-intensive code. It's much easier to program professional C for 32-bit than for 8-bit.

Also - and this has a very big impact: almost all 8 bitters out there are archaic architectures from the 1980s and 1990s, that very often come with very bad C compilers. Compilers that do a really poor job at optimizing the code. Modern 32-bitters like Cortex M are almost certain to have much better compilers. So check if optimizations were at all enabled in the original source and if you plan to use them after porting - it's fairly common that embedded systems don't have optimizations enabled, particularly older ones - and this is because of bad old compilers with optimizer bugs.

On the other hand, if the code is mainly hardware drivers with lots of register writes, it will likely end up much larger on 32 bit, since hardware peripheral registers are 8 bit on 8/16 bit cores but 32 bit on 32 bit cores. But you'll have to rewrite these drivers anyway, so it's hard to compare.

In addition, you can look for explicit "ROM memory over execution speed" optimizations. For example, if there is a CRC, is it implemented with lots of loops and shifts rather than a fast look-up table? Such things might be indications of the programmer keeping the flash size down on purpose.

Then of course stuff like LCD fonts, string tables etc are big chunks taking up lots of flash, but they do so independently of 8 vs 32 bit core.

\$\endgroup\$

Not the answer you're looking for? Browse other questions tagged or ask your own question.