Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I'm a beginning developer (i.e.: just a student) for the 8051 and I'm trying to find ways to devellop using Linux. In school we are using the SAB 80C515A (256B RAM).
The thing is though that even the simplest code like copying the bits from P4 (DIP-switches) to P5 (LEDs) just doesn't work using SDCC but is working with Keil.
When I viewed the HEX output I noticed that the file generated by Keil is just 4 lines long but the file generated by SDCC is 18 lines long.
Can anyone tell me what I need to change so it will work?
> Can anyone tell me what I need to change so it will work?
you didn't post the code... Still a good guess is that you
use an incompatible syntax for the SFR definitions in the
See manual sections
6.1 Porting code from or to other compilers
184.108.40.206 sfr / sfr16 / sfr32 / sbit
As you can see I only used headers that are prepackaged. I just used different includes that both define what P5 and P4 are. Even defining them manually didn't matter (as it shouldn't matter). My knowledge of C very limited, but besides a clear case of coding style torture it should work, right?
P5 = P4;
... so my guess was wrong ...
You could specify the option --no-xinit-opt so that
SDCC would skip xdata initialization (so you have to
check less lines). If you call your file sab.c then
sdcc --no-xinit-opt sab.c
would generate the following code, (see the sab.rst file:)
0000 02 00 03 469 ljmp __sdcc_gsinit_startup
0016 02 00 19 482 ljmp __sdcc_program_startup
0019 488 __sdcc_program_startup:
0019 12 00 1E 489 lcall _main
001C 80 FE 491 sjmp .
001E 504 _main:
513 ; sab.c:4: while(1)
001E 514 00102$:
515 ; sab.c:5: P5 = P4;
001E 85 E8 F8 517 mov _P5,_P4
0021 80 FB 519 sjmp 00102$
(probably SourceForge swallowed some white-spaces above)
The code looks fine.
Compare this to the assembly source generated by Keil:
do addresses also start with 0x0000 there?
Any special startup code used by Keil?
Just gessing here as I am not familiar with the '515, but before reading port 4, isn't it necessary to writes ones to it first?
P4=0xff; //Set port for input
P5 = P4;
As stated in the first post P4 is connected with some DIP-switches. This means that you can change them while the program is running and thus an easy way to test some basic stuff.
I just found out that the linedelay mentioned in the schoolbooks doesn't seem sufficient enough when using minicom. So I just increased it, and it works now.
But knowing about the --no-xinit-opt option is good anyway when I'm going to get short on space. Thanks for the help people.
> the linedelay mentioned in the schoolbooks doesn't seem sufficient
Yet another guess: If you pass the ihx file through packihx or
srec_cat as proposed in section
3.1.2 "Postprocessing the Intel Hex ﬁle"
then the linedelay proposed in the schoolbook would work?
That indeed seems to be working. That little tip just saved me a lot of time transferring. Thanks again.