Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

Different size?

Help
Ruud
2006-11-14
2013-03-12
  • Ruud
    Ruud
    2006-11-14

    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
      header file.

      See manual sections
      6.1 Porting code from or to other compilers
      and
      3.4.1.7 sfr / sfr16 / sfr32 / sbit

       
    • Ruud
      Ruud
      2006-11-14

      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?

      Keil:

      ----------
      #include <reg515.h>

      void main(void){
      while(1)
           P5 = P4;
      }
      ----------

      SDCC:

      ----------
      #include <sab80515.h>

      void main(void){
      while(1)
           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?

          #include <sab80515.h>

          void main(void){
          P4=0xff; //Set port for input
          while(1)
               P5 = P4;
          }

           
    • Ruud
      Ruud
      2006-11-14

      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.

       
    • Ruud
      Ruud
      2006-11-15

      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 file"
        then the linedelay proposed in the schoolbook would work?

         
        • Ruud
          Ruud
          2006-11-15

          That indeed seems to be working. That little tip just saved me a lot of time transferring. Thanks again.