Small Device C Compiler suite

What does the code look like before the packihx command?


-----Original Message-----
From: Brandon Fosdick <bfoz@...>
To: sdcc-user@...
Sent: Wed, 21 Jan 2009 5:01 pm
Subject: [Sdcc-user] Nordic nRF24LE



I'm trying to use sdcc with the Nordic Semi 8051-based parts, but I'm 
not having much luck. The Nordic rep dropped a pile of dev boards on me 
and said to use Keil, but that's just too expensive. Anyone have any 
experience with these parts?

I started by writing a very simple test program to light the LEDs 
attached to P0...

---
#include <8051.h>

__sfr at (0x93) P0DIR;

void main()
{
     P0DIR = 0x0;   // All pins are outputs
     while(1)
    P0 = 0xFF;
}
---

...and built it with both sdcc 2.8.0 and with the eval version of keil. 
Keil produces a very short hex file that does the right thing. sdcc 
produces a much longer file that doesn't work. After programming the 
sdcc version the LEDs flash twice and then go dark.

Here's how I built it with sdcc...
sdcc --no-xinit-opt --opt-code-speed main.c
packihx main.ihx > main.hex

the resulting main.hex...
:03000000020008F3
:03001B00020003DD
:0500030012001E80FE4A
:08001E007593007580FF80FB63
:06001500E478FFF6D8FDBF
:0D000800758107120026E5826003020003E7
:0400260075820022BD
:00000001FF

and the keil output for comparison...
:08080C00E4F5947580FF80FB08
:03000000020800F3
:0C080000787FE4F6D8FD75810702080C33
:00000001FF

sdcc is generating an awful lot of instructions just to set some pins. 
Keil is putting the bulk of the code at 0x800 with a jmp at 0x0, but I 
don't see any reason it has to be that way. Nor do I see a way to get 
sdcc to do the same thing.

Did I do something wrong? Am I missing some magic command line options?


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Sdcc-user mailing list
Sdcc-user@...
https://lists.sourceforge.net/lists/listinfo/sdcc-user

main.ihx:
:03000000020008F3
:03001B00020003DD
:0500030012001E80FE4A
:03001E00759300D7
:050021007580FF80FB6B
:06001500E478FFF6D8FDBF
:03000800758107F8
:0A000B00120026E5826003020003E4
:0400260075820022BD
:00000001FF


ronnym581@... wrote:
> What does the code look like before the packihx command?
> 
> 
> -----Original Message-----
> From: Brandon Fosdick <bfoz@...>
> To: sdcc-user@...
> Sent: Wed, 21 Jan 2009 5:01 pm
> Subject: [Sdcc-user] Nordic nRF24LE
> 
> I'm trying to use sdcc with the Nordic Semi 8051-based parts, but I'm 
> not having much luck. The Nordic rep dropped a pile of dev boards on me 
> and said to use Keil, but that's just too expensive. Anyone have any 
> experience with these parts?
> 
> I started by writing a very simple test program to light the LEDs 
> attached to P0...
> 
> ---
> #include <8051.h>
> 
> __sfr at (0x93) P0DIR;
> 
> void main()
> {
>      P0DIR = 0x0;   // All pins are outputs
>      while(1)
>     P0 = 0xFF;
> }
> ---
> 
> ...and built it with both sdcc 2.8.0 and with the eval version of keil. 
> Keil produces a very short hex file that does the right thing. sdcc 
> produces a much longer file that doesn't work. After programming the 
> sdcc version the LEDs flash twice and then go dark.
> 
> Here's how I built it with sdcc...
> sdcc --no-xinit-opt --opt-code-speed main.c
> packihx main.ihx > main.hex
> 
> the resulting main.hex...
> :03000000020008F3
> :03001B00020003DD
> :0500030012001E80FE4A
> :08001E007593007580FF80FB63
> :06001500E478FFF6D8FDBF
> :0D000800758107120026E5826003020003E7
> :0400260075820022BD
> :00000001FF
> 
> and the keil output for comparison...
> :08080C00E4F5947580FF80FB08
> :03000000020800F3
> :0C080000787FE4F6D8FD75810702080C33
> :00000001FF
> 
> sdcc is generating an awful lot of instructions just to set some pins. 
> Keil is putting the bulk of the code at 0x800 with a jmp at 0x0, but I 
> don't see any reason it has to be that way. Nor do I see a way to get 
> sdcc to do the same thing.
> 
> Did I do something wrong? Am I missing some magic command line options?

Hi,

Brandon Fosdick schrieb:
> sdcc is generating an awful lot of instructions just to set some pins.

Strictly speaking Keil uses 4 instructions
whereas SDCC uses only 3 instructions for:

  P0DIR = 0x0;
  while(1)
    P0 = 0xFF;

Both compilers use 8 bytes of code memory and the
same number of cycles on a plain 8051 though.
The difference is in the startup code that is being linked.

Keil uses a clever scheme there.
SDCC links code that is not customized for your application
and uses generic code which f.e. includes code for an
external startup routine.

But you have (manual) control over this code (see Manual 3.12.1)
and if you f.e. link an adapted crtstart.asm
(empty section GSINIT2 so only setting the stackpinter is set)
then you'll have shaved off 14 bytes:)

  sdcc --no-xinit-opt --main-return --iram-size 0x80 crtstart.rel t.c

you arrive at:

:020000040000FA
:1A000000020006020012758107E4787FF6D8FD0200037593007580FF80FBAB
:00000001FF

which (passed through d52 disassembler with "d52 -pngd t.ihx") is:

        ljmp    X0006           ; 0000   02 00 06   ...
;
X0003:  ljmp    X0012           ; 0003   02 00 12   ...
;
X0006:  mov     sp,#0x7         ; 0006   75 81 07   u..
        clr     a               ; 0009   e4         d
        mov     r0,#0x7f        ; 000a   78 7f      x.
X000c:  mov     @r0,a           ; 000c   f6         v
        djnz    r0,X000c        ; 000d   d8 fd      X}
        ljmp    X0003           ; 000f   02 00 03   ...
;
X0012:  mov     93h,#0x0        ; 0012   75 93 00   u..
X0015:  mov     p0,#0xff        ; 0015   75 80 ff   u..
        sjmp    X0015           ; 0018   80 fb      .{

You could strip that down yet another 4-5 bytes using ajmp
and removing one ljmp.

Considering it's about 5 years ago from Erik Petrich's commit
2004-03-17 for the initialization code it's strange that
noone yet (seems to have) posted a minimized crtstart.asm :^)




> Keil is putting the bulk of the code at 0x800 with a jmp at 0x0, but I 
> don't see any reason it has to be that way.

It's because Keil's evaluation version is code size
limited to 2k(**) (for other limitations see Keil's website).
For target devices with 2k code memory (0x800 bytes)
this limitation would not have an effect so Keil locates
the bulk of the code to above 0x800.

>                                             Nor do I see a way to get
> sdcc to do the same thing.

See option --code-loc if you need to do the same thing
with SDCC.




Also use D51 (Manual 6.4) to disassemble both Intel Hex Files.
You'll note a difference that can be changed with option --iram-size.
And a different SFR address is used for port initialisation.

Greetings,
Frieder




(**) Keil evaluation versions which allow for 4k code are
shipped with some low cost 8051 development kits.

Thanks, that got me a little further.

I created a minimal crtstart.asm based on the manual...
---
.area GSINIT0 (CODE)
__sdcc_gsinit_startup::
     mov sp,#__start__stack - 1

.area GSINIT2 (CODE)
;    lcall __sdcc_external_startup
;    mov a,dpl
;    jz __sdcc_init_data
;    ljmp __sdcc_program_startup
__sdcc_init_data:
---

Then I ran...
asx8051 -lo crtstart.asm
sdcc --no-xinit-opt --main-return --iram-size 0x80 crtstart.rel main.c
packihx main.ihx > main.tmp
d52 -pngd main.hex

Which gave me a main.d52 of...
---
	.org	0x0
;
	ljmp	X0006		; 0000   02 00 06   ...
;
X0003:	ljmp	X0012		; 0003   02 00 12   ...
;
X0006:	mov	sp,#0x7		; 0006   75 81 07   u..
	clr	a		; 0009   e4         d
	mov	r0,#0x7f	; 000a   78 7f      x.
X000c:	mov	@r0,a		; 000c   f6         v
	djnz	r0,X000c	; 000d   d8 fd      X}
	ljmp	X0003		; 000f   02 00 03   ...
;
X0012:	mov	93h,#0x0	; 0012   75 93 00   u..
X0015:	mov	p0,#0xff	; 0015   75 80 ff   u..
	sjmp	X0015		; 0018   80 fb      .{
;
	end
---

Which actually looks the same as yours, which is good. Unfortunately, it 
still doesn't run.

On a whim I took main.d52 and paired it down to the bare minimum, which 
gave me test.asm...
---
	.area HOME    (ABS)
	.org	0x0
	mov	0x93,#0x0	; 0012   75 93 00   u..
X0015:	mov	p0,#0xff	; 0015   75 80 ff   u..
	sjmp	X0015		; 0018   80 fb      .{
---

then ran...
asx8051 -lo test.asm
sdcc test.rel
packihx test.ihx > test.hex

and then downloaded test.hex to the board. Still no joy. The LEDs flash 
twice and go dark, same as before. So I'm thinking I must have a more 
fundamental problem somewhere.

Reading the code off the chip produces a file identical to the one that 
was written to it, so I don't think the problem is in the programmer.


Frieder Ferlemann wrote:
> But you have (manual) control over this code (see Manual 3.12.1)
> and if you f.e. link an adapted crtstart.asm
> (empty section GSINIT2 so only setting the stackpinter is set)
> then you'll have shaved off 14 bytes:)
> 
>   sdcc --no-xinit-opt --main-return --iram-size 0x80 crtstart.rel t.c
> 
> you arrive at:
> 
> :020000040000FA
> :1A000000020006020012758107E4787FF6D8FD0200037593007580FF80FBAB
> :00000001FF
> 
> which (passed through d52 disassembler with "d52 -pngd t.ihx") is:
> 
>         ljmp    X0006           ; 0000   02 00 06   ...
> ;
> X0003:  ljmp    X0012           ; 0003   02 00 12   ...
> ;
> X0006:  mov     sp,#0x7         ; 0006   75 81 07   u..
>         clr     a               ; 0009   e4         d
>         mov     r0,#0x7f        ; 000a   78 7f      x.
> X000c:  mov     @r0,a           ; 000c   f6         v
>         djnz    r0,X000c        ; 000d   d8 fd      X}
>         ljmp    X0003           ; 000f   02 00 03   ...
> ;
> X0012:  mov     93h,#0x0        ; 0012   75 93 00   u..
> X0015:  mov     p0,#0xff        ; 0015   75 80 ff   u..
>         sjmp    X0015           ; 0018   80 fb      .{
> 
> You could strip that down yet another 4-5 bytes using ajmp
> and removing one ljmp.
> 
> Considering it's about 5 years ago from Erik Petrich's commit
> 2004-03-17 for the initialization code it's strange that
> noone yet (seems to have) posted a minimized crtstart.asm :^)

Brandon Fosdick wrote:
> and then downloaded test.hex to the board. Still no joy. The LEDs flash 
> twice and go dark, same as before. So I'm thinking I must have a more 
> fundamental problem somewhere.

It turns out the problem was me. I had the datasheet for the 24LE1 but 
the chip on the dev board is a 24LU1P. Apparently P0DIR is at 0x93 on 
the LE and at 0x94 on the LU. I finally noticed the problem when I 
disassembled the keil output and compared it to the sdcc output. Thanks 
for pointing me at d52.

Oh well, I learned a lot. Thanks for the help.