7

I'm new to embedded C development and I'm looking for some general principals/guidelines for managing the size of the generated code.

In my specific example I'm using XC8 on a PIC18F4550. My code so far uses about 13% of the space. Once I use "time.h" and 1/2 functions from it, the usage jumps to 45%! I realise that the free XC8 compiler does not optimise but I'm still very surprised to see just how much space is used.

What I'm looking for a tips / staring points along the lines of

  • Alternatives to the standard libraries that implement on small targeted subsets of the functionality. E.g. a date/time lib. i.e. are there repositions I can get useful routines from?
  • How to see what is using all the space. (Listing/map files - and tips for analysing them)
  • Any other tips / resources.

EDIT: I found a nice implementation without using stdlib here: https://codereview.stackexchange.com/questions/38275/convert-between-date-time-and-time-stamp-without-using-std-library-routines

The general question still stands though. Are there guidelines, good repository sources etc

Community
  • 1
Andre
  • 267
  • 2
  • 11
  • Isn't opt level 1 allowed? For little more you can get one of the newish pic32 line with much more flash. It seems that xc8 is more limited than the 16 and 32 compilers. – Erik Friesen May 16 '14 at 15:18
  • 1
    @ErikFriesen Thanks I'll definitely try the pic32 range later on. For now I want to try get it to work with the pic18. I'm also interested in this in a general way though. I.e. there will always be some space restriction and I'd like to understand ways to improve things – Andre May 16 '14 at 16:03
  • 1
    We have one license of XC8 pro that our main firmware guy uses. The rest of us develop with the free version for smaller stuff, and he pulls and compiles if necessary for optimization. It seems to me that the compiler applies all the optimization in the free version, but inserts a bunch of branch instructions. So the disassembly from the pro and free versions looks the same, the free version just has a whole bunch of branches jumping around. You could take whatever functionality you need from the time library, and spin your own. There is almost always space savings to be had there. – Matt Young May 16 '14 at 16:24
  • Thanks @MattYoung, yeah I think the answer for the libraries is going to pretty much be just google for existing solutions / other stdlibs and modify from there. It seems that the space savings will be significant. I'm surprised that there are not more differences between the free and pro outputs. I have seen lots of comments/complaints to the contrary. Very interesting. – Andre May 16 '14 at 16:36
  • I've only extensively compared the two in a couple of applications where timing was critical, but those were my findings. It would definitely be worth reading into further. – Matt Young May 16 '14 at 16:39
  • @Matt Young. I think they say the older versions do the random jumps, are you on the latest version of xc8? – Erik Friesen May 16 '14 at 16:51
  • @ErikFriesen The last time I looked at it was 1.21. – Matt Young May 16 '14 at 16:54
  • Procedural abstraction is a standard technique for code density. Sadly such is less useful at the C language level because of standard ABIs. If function call overhead can be limited to one caller instruction and one callee instruction, even short instruction sequences can benefit with only a few callers. This means more instructions are executed (some potentially useless for certain paths), but by replacing the necessary instructions with a function call the static instruction count is reduced. –  May 16 '14 at 22:02
  • @ErikFriesen `For little more you can get one of the newish pic32 line with much more flash. It seems that xc8 is more limited than the 16 and 32 compilers` What are you talking about.. It's not about the microcontroller family. It's about the free version of the compiler which is limited for all types of PICs – m.Alin May 16 '14 at 22:47
  • @m.Alin. Have you used both compilers? If you want you can get an old version of c32 that will fully optimize your code, although not the mc libs. xc8 won't do that. – Erik Friesen May 17 '14 at 01:53
  • As well, xc32 will do 0 and 1 opt level, xc8 has only 0? It has some other oddities I didn't really love, so I helped push a migration away from the 18 line on one project. – Erik Friesen May 17 '14 at 01:55
  • One thing to consider is to switch away from the least code effective MCU on the market to something modern. Microchip are likely dead within 5 years anyhow, so the sooner you leave the sinking ship, the better. – Lundin May 20 '14 at 06:43
  • Nobody kicks a dead dog. – Erik Friesen May 26 '14 at 17:40

3 Answers3

3

I've done some looking around and here are the tips I can find

  1. Write better code. Code size and speed must be considered at each step of the way.
  2. C compiler/linker will only use the functions you actually use. So just including a .h should not increase code size (much)
  3. Standard functions are however often more generic than you require. It is possible to write smaller versions that only do what you required
  4. Shared strings as per @BrianK's answer

Then there are some alternatives that don't address the core issue of code size but may need to be considered if all else fails

  1. Use a PIC with more space
  2. Use an optimising compiler, e.g. MPLAB Pro
  3. Use assembler for some or all of the code

I would still like an easy way of seeing which functions and included functions are using the most space. I'll update here if I find an easy way to do so.

Andre
  • 267
  • 2
  • 11
2

Implementing your own version of standard functions instead of including the entire library can help. There are a million smaller, more specific optimizations that you can do, but a good reference collection of those kinds of tricks is the book Hacker's Delight. It's very practical (especially for bit twiddling like you often do on a microcontroller) and I recommend it.

aloishis89
  • 1,660
  • 3
  • 13
  • 20
  • 2
    I have the first edition of Hacker's Delight (and love it). Any ideas what the differences are in the second edition? Is it worth getting if I have the first one? – tcrosley May 16 '14 at 17:44
  • I don't have the first edition, but I believe the second edition adds a bunch of new material as well as some refinements of the original. – aloishis89 May 18 '14 at 15:26
  • There is no such thing as "including the entire library", only the functions you use will get linked to the program. Keep in mind that the std library for your compiler is perhaps optimized for the specific target. It seems unlikely that writing your own version of those functions will save space. More likely it will do the opposite. – Lundin May 20 '14 at 06:37
  • 2
    @Lundin that is true. I.e when I use strfmttime I see a large increase in size over just using gmtime etc. However I don't agree with the general statement that writing your own libs wont help. It is unlikely that I can create a more efficient feature for feature replacement. However I only need a small percentage of the functionality provided. (Timezone etc code *is* included as the gmtime etc assume that). I was able to write a small targeted sub-set of the functionality and save 20% of the space usage. So writing a minimal sub-set is feasible. Good point about linking though. Thanks – Andre May 20 '14 at 08:06
2

Here are some things I have done when using Microchips C18 compiler. Maybe the concepts will apply to your compiler: - declare each string one time. Put in a separate .c file and use a .h file to reference them. In other words don't duplicate display messages multiple times. - declare strings so that they go in rom. This wont help you with ROM (code space) but it will save memory. - write tight code. If several lines of code are duplicated, put them in a function. Copy / paste is not necessary an embedded programmers best friend. - like you already thought of, implement your own functions instead of including a library. I once saved a ton of space by creating my own itoa() function. Try not to use printf.

BrianK
  • 380
  • 1
  • 3
  • 9