Notes on converting Keil 8051 C to SDCC C

A project log for Adventures with a STC89C52 development board

Quick way to start with MCUs

ken-yapKen Yap 05/06/2020 at 23:567 Comments

After having converted 30 odd sample programs from Keil C to SDCC, here is a summary of the differences I encountered.

struct fontentry {
} f = { "AB", 0x00, 0x01, … };

 The initialisers for the second uchar array needs to be surrounded by braces according to the standard.

If I remember any other differences I'll edit this log.



[this comment has been deleted]

Ken Yap wrote 02/19/2024 at 07:24 point

Hmm, looks like the person asking the question found their problem and deleted their question. Oh well.

Works for me. I wrote this short program:

__sbit __at(0x88+0) TCON_IT0;


       TCON_IT0 = 0;
       TCON_IT0 = 1;


I compiled it with sdcc -mmcs51 sbit.c and looked at sbit.lst which shows that the correct instruction was generated:

                                   131 ;       sbit.c:5: TCON_IT0 = 0;
                                   132 ;       assignBit
     000000 C2 88            [12]  133         clr     _TCON_IT0
                                   134 ;       sbit.c:6: TCON_IT0 = 1;
                                   135 ;       assignBit
     000002 D2 88            [12]  136         setb    _TCON_IT0
                                   137 ;       sbit.c:7: }

So check your C program for syntax errors.

Incidentally you don't have to define TCON_IT0, there is already a special bit location called IT0 in the include file 8052.h in the SDCC distribution.

  Are you sure? yes | no

Mian Qi wrote 02/29/2024 at 00:26 point

Yes, I found the errors and deleted my problem post, thanks.

  Are you sure? yes | no

Thomas wrote 05/10/2020 at 09:29 point

Thanks for the useful summary :-) I've done my share of Keil C programming, and I told myself not to touch MCS51 anymore. But hey, with all the Nuvoton N76E003AT20 chips from modules converted to STM8S003F3P6 lying around I might as well solder one to a breakout board and try if SDCC MCS51 programming is any better ;-)

  Are you sure? yes | no

Ken Yap wrote 05/14/2020 at 01:04 point

I'd be interested in how you progress. As you may remember I investigated the Nuvoton MCS51 descendants a while back at and concluded that the development tools weren't as cost effective and convenient as those for the STM8. A NU-Link programmer, similar to the ST-Link one is needed, and there is no open source equivalent to stm8flash, though the Nuvoton ICP tool works under Wine. On the other hand the STC chips can be programmed using the onboard serial loader.

Chinese manufacturers make a lot of cheap MCUs (I'm still interested in those 3¢ Padauk MCUs) but it's a pity they don't leverage the power of open software and hardware to disseminate their products wider. I guess they have a sizeable domestic market.

  Are you sure? yes | no

Thomas wrote 05/14/2020 at 06:05 point

Well, I didn't progress any further than you did - there is no open source way to replace a programmer that uses a microcontroller's 2nd UART for programming. Normally the process of recording and replaying serial data shouldn't be that complicated, provided that it's not encrypted, requires an elusive timing or actually isn't serial port data. Buying yet another programming box would maybe be OK but using a miserable Windows GUI tool for playing with those chips? Now way Jose!

Padauk: their take on building a controller is really interesting. Their IDE not. SDCC has initial support but the interesting architecture of the controller makes the task of building a standard-compliant C compiler also "interesting" :-) It might be something for Forth but the clean Harvard architecture and the lack of self-programming capabilities makes limits it to non-interactive programming.

  Are you sure? yes | no

Ken Yap wrote 05/14/2020 at 08:46 point

From what I understand SDCC for Padauk is closer to C than the Padauk's own offering, which is more like a glorified macro processor, doesn't even have a real for statement. I think SDCC used the same trick as for MCS51 small model, put local variables in a private static area, ruling out recursive calls, not a big loss. The freepdk devs still have to nut out the code that's tuned to each OTP unit.

Anyway enough of MCS51 for now for me. Time to pivot to other round tuits. Pandemic time can be productive time. :)

  Are you sure? yes | no

Thomas wrote 05/15/2020 at 06:02 point

Yes, SDCC is as standard compliant as it gets considering the constraints of the target. When programming something like the MCS51 the data flow gets intractable fast when a Keil-C "Fortran style" memory management approach is combined with "smart" mapping of RAM to the bit addressable IRAM area (I've worked with one old-hand programmer who had a habit of moving memory between XRAM and that area at the begin of a routine/task/whatever so that he had a choice of the addressing modes BIT, IRAM, IRAM indirect, XRAM and XRAM with the DP of the MCS51-variant-of-the-day. Try cleaning up that mess ;-)

  Are you sure? yes | no