debug warning message question

Help
enghiong
2006-11-08
2013-03-12
  • enghiong

    enghiong - 2006-11-08

    I am new to using SDCC for PICs under Windows. When I compile using an example C pgm, eg p.c :
    c:\sdcc --debug -mpic14 -p16f628a p.c
    I get a warning message : p.asm:168:Warning [230] directive ignored when debug info is disabled
    But if I use:
    c:\sdcc -mpic14 -p16f628a p.c  the warning message does not appear.
    May I know what does "Warning [230] directive ignored when ... " mean. Can I just ignore it ?

    For both cases, the hex file of the same size is generated.

    Thanks

     
    • Anonymous - 2006-11-09

      What is in p.asm around line 168?

       
    • enghiong

      enghiong - 2006-11-09

      I tried a smaller program "u.c" :

      #include <pic16f628a.h>
      void delay();
      void main(void)
      {
      #define OUTPUT 0
      #define INPUT 1
      TRISA=OUTPUT;
      while(1)
      {
      PORTA = 0xff;
      delay();
      PORTA=0x00;
      delay();
      }
      }

      void delay()
      {
      unsigned int i;
      for(i=0;i<5000;i++)
      {}
      }

      The asm file showed those stated warnings at line 172, 188, ..as follows:

      ;;    1400  _TRISA   offset=0
          .line    10; "u.c"    TRISA=OUTPUT;  <-- line 172 of asm file; line 10 of u.c
          BSF    STATUS,5
          BCF    STATUS,6
          CLRF    _TRISA
      ...
      ...
      ; >>> /home/users/s/sd/sdcc-builder/build/sdcc-build/orig/sdcc/src/pic/gen.c:10095:genAssign
      _00106_DS_
          .line    14; "u.c"    PORTA = 0xff; <-- line 188 of asm file, line 14 of u.c
          MOVLW    0xff
      ...
      ...

      So it seems like for every instruction ending with ";" in the c file, the warning appears.

      I tried out the hardware connecting the pic to 4 leds at RA0 to RA3, using IC-Prog 1.05D programmer, with the configuration FUSES clicking PWRT and LVP only(have not learnt how to do it in the c file yet), crystal selection : IntRC I/O, ie using internal 4MHz. Only leds connected to RA2 and RA3 are permanently ON. There is no flickering as intended.

      Thanks for helping.

       
    • Anonymous - 2006-11-10

      First, I should mention that I don't work with PIC processors. But, unless I'm mistaken, your question is not directly related to PIC.

      I think that using the --debug switch when compiling you tell the compiler to insert debug information into the object files (check with the manual to make sure). That information includes - as you can see in the asm files - the ".line x" directive where 'x' is line number in the original C source. This directive just says "the following assembly code corresponds to C source code at line 'x'". So:

      1.) Yes, you can ignore those directives. They don't do anything in the processor. In fact, I guess they don't even get into the processor, they are for use by debugging tools only. That corresponds to what you said that hex file is of same size regardless of whether you use --debug or not.

      2.) The warning just says that the ".line" directive is meaningful only when you use debug information, which makes sense, since ".line" itself is for debug purposes.

      3.) I don't think the warning has anything to do with program functionality. So the led problem is caused by something else.

      >> So it seems like for every instruction ending with ";" in the c file, the warning appears.

      The ';' is a comment character. Anything after it in asm file is a comment. After the ".line" directives the comment includes a copy of the original C source at that line so that you can read the assembly plus see the C source without having to look into the .C file as well.

      As for the leds, someone who knows PIC will have to help you, I don't know PIC registers so I can't tell what's wrong in your code. General guidelines: 1. check that you have port direction set properly before accessing the leds, 2. check that you write to the port as intended and that the processor actually gets to the place where you do it. 3. check that you don't blik the leds too fast or else they'll seem to be lit all the time. I don't know how fast will your delay() execute - that depends on crystal and instruction set timing. Use calculator to make sure it lasts at least ~50ms or so.

      I hope that helps a bit.

       
    • enghiong

      enghiong - 2006-11-11

      Finally got it to work, but with strange behaviour.

      a. With code below, the "while loop" worked 1st cycle, then skipped "PORTA=0xff;" only thereafter. The asm file showed the correct "GOTO" back to label _00106_DS_ , so logically it should work.

      c-codes as follows:
      void main(void)
      {
      #define OUTPUT 0
      #define INPUT 1
      TRISA=OUTPUT;  // This is to configure PORTA as outputs
      while(1)
      {
      PORTA = 0xff;
      delay();
      PORTA=0x00;
      delay();
      }

      asm codes as follows:
      ;; Starting pCode block
      _main    ;Function start
      ; 2 exit points
      ;    .line    21; "u.c"    TRISA=0x00;
          BSF    STATUS,5
          BCF    STATUS,6
          CLRF    _TRISA
      _00106_DS_
      ;    .line    26; "u.c"    PORTA = 0xff;
          MOVLW    0xff
          BCF    STATUS,5
          MOVWF    _PORTA
      ;    .line    27; "u.c"    delay();
          PAGESEL    _delay
          CALL    _delay
          PAGESEL    $
      ;    .line    28; "u.c"    PORTA=0x00;
          BCF    STATUS,5
          BCF    STATUS,6
          CLRF    _PORTA
      ;    .line    29; "u.c"    delay();
          PAGESEL    _delay
          CALL    _delay
          PAGESEL    $
          GOTO    _00106_DS_
          RETURN   
      ; exit point of _main

      b. Inserted TRISA=OUTPUT; at start of loop. Does not work.
      while(1)
      {
      TRISA=OUTPUT;
      PORTA = 0xff;
      delay();
      PORTA=0x00;
      delay();
      }

      c. Inserted TRISA=OUTPUT; at end of loop. It worked.
      while(1)
      {

      PORTA = 0xff;
      delay();
      PORTA=0x00;
      delay();
      TRISA=OUTPUT;
      }

      Logically, I would think all 3 versions should work, but in practice only the code in part c worked. Appreciate your analysis. 

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks