Loading ...
Sorry, an error occurred while loading the content.

problem with 16F505 if code > 512

Expand Messages
  • oudshoorn.bert
    As soon as the code reaches the 2nd code page, I encounter problems. It looks as if branchlo_set and branchlo_clr (status bit pa0) are activated, but ? Used a
    Message 1 of 11 , Mar 1, 2009
    • 0 Attachment
      As soon as the code reaches the 2nd code page, I encounter problems.
      It looks as if branchlo_set and branchlo_clr (status bit pa0) are
      activated, but ? Used a recent (end 2008) 10f505.jal incl of Rob
      Hamerling. Reduced the code to a small test program:
      include 16f505
      pragma target OSC INTOSC_NOCLKOUT
      pragma target clock 4_000_000 -- oscillator frequency 4 Mhz
      pragma target WDT disabled -- WatchDog Timer
      pragma target MCLR internal -- pin_b3 input (future)
      --enable_digital_io() -- disable analog I/O (if any)
      OPTION_REG = 0b1100_0000 -- psa on tmr0, ps2/1/0=000
      pin_b4_direction = output -- pin 3
      _usec_delay(200_000) -- 01 -- just to reach the page-2
      _usec_delay(200_000) -- 02 -- etc
      _usec_delay(200_000) -- 03
      _usec_delay(200_000) -- 04
      _usec_delay(200_000) -- 05
      _usec_delay(200_000) -- 06
      _usec_delay(200_000) -- 07
      _usec_delay(200_000) -- 08
      _usec_delay(200_000) -- 09
      _usec_delay(200_000) -- 10
      _usec_delay(200_000) -- 11
      _usec_delay(200_000) -- 12
      _usec_delay(200_000) -- 13
      _usec_delay(200_000) -- 14
      _usec_delay(200_000) -- 15
      _usec_delay(200_000) -- 16
      _usec_delay(200_000) -- 17
      _usec_delay(200_000) -- 18
      _usec_delay(200_000) -- 19
      _usec_delay(200_000) -- too much.. total code > 512
      _usec_delay(200_000) -- too much.. total code > 512
      forever loop
      pin_b4 = high
      _usec_delay(500_000)
      pin_b4 = low
      _usec_delay(500_000)
      end loop
      Thank you, Bert
    • Rob Hamerling
      Hi Bert, ... I copied your code and it compiles here without errors! Please provide more info, such as compiler version, compiler console log. One positive
      Message 2 of 11 , Mar 1, 2009
      • 0 Attachment
        Hi Bert,

        oudshoorn.bert wrote:
        > As soon as the code reaches the 2nd code page, I encounter problems.
        > It looks as if branchlo_set and branchlo_clr (status bit pa0) are
        > activated, but ? Used a recent (end 2008) 10f505.jal incl of Rob
        > Hamerling. Reduced the code to a small test program:
        > include 16f505
        > pragma target OSC INTOSC_NOCLKOUT
        > pragma target clock 4_000_000 -- oscillator frequency 4 Mhz
        > pragma target WDT disabled -- WatchDog Timer
        > pragma target MCLR internal -- pin_b3 input (future)
        > --enable_digital_io() -- disable analog I/O (if any)
        > OPTION_REG = 0b1100_0000 -- psa on tmr0, ps2/1/0=000
        > pin_b4_direction = output -- pin 3
        > _usec_delay(200_000) -- 01 -- just to reach the page-2
        > _usec_delay(200_000) -- 02 -- etc
        > _usec_delay(200_000) -- 03
        > _usec_delay(200_000) -- 04
        > _usec_delay(200_000) -- 05
        > _usec_delay(200_000) -- 06
        > _usec_delay(200_000) -- 07
        > _usec_delay(200_000) -- 08
        > _usec_delay(200_000) -- 09
        > _usec_delay(200_000) -- 10
        > _usec_delay(200_000) -- 11
        > _usec_delay(200_000) -- 12
        > _usec_delay(200_000) -- 13
        > _usec_delay(200_000) -- 14
        > _usec_delay(200_000) -- 15
        > _usec_delay(200_000) -- 16
        > _usec_delay(200_000) -- 17
        > _usec_delay(200_000) -- 18
        > _usec_delay(200_000) -- 19
        > _usec_delay(200_000) -- too much.. total code > 512
        > _usec_delay(200_000) -- too much.. total code > 512
        > forever loop
        > pin_b4 = high
        > _usec_delay(500_000)
        > pin_b4 = low
        > _usec_delay(500_000)
        > end loop

        I copied your code and it compiles here without errors! Please provide
        more info, such as compiler version, compiler console log.

        One positive side effect of your report (nothing to do with your
        problem). In the device file 16f505.jal OPTION_REG_PS should be bit*3
        (not 'byte'). Same error also in some other device files of 12-bit core
        PICs. Will be corrected!


        Regards, Rob.



        --
        Rob Hamerling, Vianen, NL (http://www.robh.nl/)
      • oudshoorn.bert
        ... problems. ... provide ... bit*3 ... core ... Hello Rob, Thank you for the fast response. Indeed it compiles correctly but the LED (pin_b4) does not flash
        Message 3 of 11 , Mar 1, 2009
        • 0 Attachment
          --- In jallist@yahoogroups.com, Rob Hamerling <robhamerling@...>
          wrote:
          >
          >
          > Hi Bert,
          >
          > oudshoorn.bert wrote:
          > > As soon as the code reaches the 2nd code page, I encounter
          problems.
          > > > etc
          > I copied your code and it compiles here without errors! Please
          provide
          > more info, such as compiler version, compiler console log.
          >
          > One positive side effect of your report (nothing to do with your
          > problem). In the device file 16f505.jal OPTION_REG_PS should be
          bit*3
          > (not 'byte'). Same error also in some other device files of 12-bit
          core
          > PICs. Will be corrected!
          >
          >
          > Regards, Rob.
          >
          Hello Rob,

          Thank you for the fast response. Indeed it compiles "correctly" but
          the LED (pin_b4) does not flash correctly anymore, or not at all, if
          statements 20, 21, etc (extra delays) are added.
          I noticed a problem in a different program, and tried to "isolate"
          the cause with this simple test case, and was surprised...
          The compiler version is 2.4i (compiled dec 1, 2008) and your include
          is from 27-10-2008 (or 2-1-2009?).
          By the way, first I encountered (sometimes) an "_irp" compiler error
          and added a dummy const on the status register bit 6 (not used). This
          PIC (and e.g. a 10f200) supports no interrupts. But could remove that
          statement with this test case. By the way, all the bits in the status
          register are bits (no bytes)? I guess.

          Regards, Bert
        • Rob Hamerling
          Hi Bert, ... Aha, I understood you had a compile time problem... I m afraid a compiler expert should jump in. ... Compiler OK, device file is probably OK too.
          Message 4 of 11 , Mar 1, 2009
          • 0 Attachment
            Hi Bert,

            oudshoorn.bert wrote:

            > Thank you for the fast response. Indeed it compiles "correctly" but
            > the LED (pin_b4) does not flash correctly anymore, or not at all, if
            > statements 20, 21, etc (extra delays) are added.

            Aha, I understood you had a compile time problem...
            I'm afraid a compiler expert should jump in.

            > I noticed a problem in a different program, and tried to "isolate"
            > the cause with this simple test case, and was surprised...
            > The compiler version is 2.4i (compiled dec 1, 2008) and your include
            > is from 27-10-2008 (or 2-1-2009?).

            Compiler OK, device file is probably OK too. But to be on the safe side
            download the latest Jallib package or the specific device file from the
            source tree. From time to time these files are improved!

            > By the way, first I encountered (sometimes) an "_irp" compiler error
            > and added a dummy const on the status register bit 6 (not used). This
            > PIC (and e.g. a 10f200) supports no interrupts. But could remove that
            > statement with this test case.

            The declaration of the constant '_irp' is a compiler requirement, not
            intended for 'public' use (hence the '_' prefix).
            When there is no IRP bit in the status byte it won't be declared in the
            device file (unless this is caused by an error in MPLAB from which the
            device files are generated). On the other hand when a specific PIC
            doesn't have interrupts, but there would be a const "_irp" be declared
            it should not harm. If you get a missing "-irp" message again from the
            compiler, please report it here! It will be picked up by Kyle (the
            compiler author and maintainer).

            > By the way, all the bits in the status
            > register are bits (no bytes)? I guess.

            With 'guessing' you cannot build reliable programs. STATUS_RP is a
            2-bits field for most baseline and midrange PICs and declared as such in
            the device file, see the datasheet. Why do you ask?

            Regards, Rob.

            --
            Rob Hamerling, Vianen, NL (http://www.robh.nl/)
          • oudshoorn.bert
            Hello Rob, ... the source tree. From time to time these files are improved! Tried it this morning, but the problem stays. ... not intended for public use
            Message 5 of 11 , Mar 2, 2009
            • 0 Attachment
              Hello Rob,

              > download the latest Jallib package or the specific device file from
              the source tree. From time to time these files are improved!

              Tried it this morning, but the problem stays.

              > The declaration of the constant '_irp' is a compiler requirement,
              not intended for 'public' use (hence the '_' prefix).

              Indeed, it was just a temporary fix to let the compiler continue...
              The compiler reported 0 errors, 0 warnings, an _irp message and no
              hex file was generated. Will report it, if I encounter it again.

              > By the way, all the bits in the status... are bits (no bytes)? "I
              guess".

              Forget my statement: Sorry for the confusion (came back from the
              tennisclub and perhaps the beer...).

              > You wrote OPTION_REG_PS must be bit*3 not byte

              Or it should be (setting low nibble PSA,PS2,PS1,PS0)?:
              procedure OPTION_REG_PS'put(byte in x) is
              pragma inline
              _OPTION_REG_shadow = (_OPTION_REG_shadow & 0xF0) | (x & 0x0F)
              asm movf _OPTION_REG_shadow,0
              asm option
              end procedure

              Regards, Bert
            • oudshoorn.bert
              Hello Rob, The 16f505.jal shows pragma target bank 0x0020 pragma target page 0x0200 Are that the sizes of a bank and page? If so: A bank of a 16f505 is
              Message 6 of 11 , Mar 2, 2009
              • 0 Attachment
                Hello Rob,

                The 16f505.jal shows
                pragma target bank 0x0020
                pragma target page 0x0200
                Are that the sizes of a bank and page?
                If so: A bank of a 16f505 is 16 bytes, 0x0010 ?

                Regards, Bert
              • Rob Hamerling
                Hi Bert, ... Well, I could agree that PSA and PS2..0 will frequently be used together, but these are separate entities, and the user should be able to handle
                Message 7 of 11 , Mar 2, 2009
                • 0 Attachment
                  Hi Bert,

                  oudshoorn.bert wrote:
                  >
                  >> You wrote OPTION_REG_PS must be bit*3 not byte
                  >
                  > Or it should be (setting low nibble PSA,PS2,PS1,PS0)?:

                  Well, I could agree that PSA and PS2..0 will frequently be used
                  together, but these are separate entities, and the user should be able
                  to handle these separately. So I don't think it is a good idea to
                  combine 'm in the device file.

                  Regards, Rob.

                  --
                  Rob Hamerling, Vianen, NL (http://www.robh.nl/)
                • Rob Hamerling
                  Hi Bert, ... Read the file JalPragm.txt which comes with the compiler for a description of all JalV2 pragmas. How did you conclude or where did you find that
                  Message 8 of 11 , Mar 2, 2009
                  • 0 Attachment
                    Hi Bert,

                    oudshoorn.bert wrote:

                    > The 16f505.jal shows
                    > pragma target bank 0x0020
                    > pragma target page 0x0200
                    > Are that the sizes of a bank and page?
                    > If so: A bank of a 16f505 is 16 bytes, 0x0010 ?

                    Read the file JalPragm.txt which comes with the compiler for a
                    description of all JalV2 pragmas.
                    How did you conclude or where did you find that the banksize of the
                    16F505 is 0x0010? Bank size is 32 bytes for all 12-bits core PICs.

                    Regards, Rob.



                    --
                    Rob Hamerling, Vianen, NL (http://www.robh.nl/)
                  • oudshoorn.bert
                    Hello Rob, ... The Microchips specification (2005) figure 4-5 shows 4 banks, but indeed 8 General Purpose registers cloned to each bank and 4x16 unique
                    Message 9 of 11 , Mar 2, 2009
                    • 0 Attachment
                      Hello Rob,

                      > How did you conclude or where did you find that the banksize of the
                      > 16F505 is 0x0010? Bank size is 32 bytes for all 12-bits core PICs.

                      The Microchips specification (2005) figure 4-5 shows 4 banks, but
                      indeed 8 General Purpose registers "cloned" to each bank and
                      4x16 "unique" registers (72 in total and each bank 32).

                      So, the problem is probably a page problem... Kyle?

                      >About the OPTION_PS
                      No, I do not need it.

                      Regards, Bert
                    • oudshoorn.bert
                      Hello Rob, A minor: The compiler says: Data area: n of 64 used, should be n of 72 used (this confused me 64/4 = 16...) Thanks you, Bert
                      Message 10 of 11 , Mar 2, 2009
                      • 0 Attachment
                        Hello Rob,

                        A minor: The compiler says: Data area: n of 64 used,
                        should be n of 72 used (this confused me 64/4 = 16...)

                        Thanks you, Bert
                      • Rob Hamerling
                        ... This is not a compiler error! The compiler works with the information about the PIC provided by the device file, which in the case of the 16f505 is 64 data
                        Message 11 of 11 , Mar 2, 2009
                        • 0 Attachment
                          oudshoorn.bert wrote:

                          > A minor: The compiler says: Data area: n of 64 used,
                          > should be n of 72 used (this confused me 64/4 = 16...)

                          This is not a compiler error! The compiler works with the information
                          about the PIC provided by the device file, which in the case of the
                          16f505 is 64 data bytes. Shared memory is used for special purposes (see
                          for example _pic_accum and _pic_isr_w), and is normally not available to
                          the application program.

                          Regards, Rob.



                          --
                          Rob Hamerling, Vianen, NL (http://www.robh.nl/)
                        Your message has been successfully submitted and would be delivered to recipients shortly.