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

A challenge for JAL and it's basic libraries ?

Expand Messages
  • Stef Mientki
    hi All, I one of the discussions last week, someone wrote that he had a PIC program that sometimes worked well and sometimes didn t work. I confirmed this
    Message 1 of 6 , Dec 1, 2001
      hi All,

      I one of the discussions last week, someone wrote that he had a PIC
      program that sometimes worked well and sometimes didn't work. I
      confirmed this experience and told to come back on this issue.
      My program was performing the following behaviour:
      - sometimes it worked well all evening
      - sometimes it worked for a while
      - sometimes it worked a few times
      - sometimes it worked just once
      - sometimes it worked never

      After I noticed a particular behaviour, I could repeat that behaviour
      the whole evening by resetting the PIC and/or disconnecting the power
      supply. The next evening the behaviour was often different without
      having changed the program.

      Oh, I agree with Vasile (I don't believe in ghosts and vampires) so it
      had to do something with the environement in combination with some bad
      programming from my side.

      Investigating the problem and finding the cause, took me a whole
      evening. After that, the solution took only 10 minutes.
      I think that I and other beginners will run into this problem in the
      future again.

      The program consisted of
      - a matrix keyboard scanner
      - the software serial output routine from SERIAL.JAL
      Both routines separate worked well, but the combination of the 2 showed
      the strange behaviour mentioned above.
      The problem arises as both routines makes use of the same IO-port and at
      least one of them is using some IO-pins both as input and output. After
      I had located the error, I found that the problem also was well
      described in the datasheets of the 16F62x PICs (page 44, DS40300B ):
      "using read/modify write instructions (like BCF / BSF / etc) can
      change the output latch of portpins that are in input mode".

      So the solution:
      before switching a portpin from input to output, always first definine
      the state of the output latch.

      Wouldn't it be a nice idea, if this problem and it's solution would be
      encapsulated in JAL and/or its basic libraries.
      I cann't overlook all the implications of such a solution, but I gues
      that by keeping shadow registers of TRIS (already) and PORT it could be
      done solely in the basic libraries.

      Stef
    • Javi
      Hi Stef, If you find a solution to that embarrased bock diagram I/O pin I ll be very pleasant with you. Regards, Javi. [Non-text portions of this message
      Message 2 of 6 , Dec 1, 2001
        Hi Stef,

        If you find a solution to that embarrased "bock diagram I/O pin" I'll be very pleasant with you.



        Regards, Javi.


        [Non-text portions of this message have been removed]
      • wouter van ooijen & floortje hanneman
        Stef, could be more preciese about what caused your problem? When you use the Jal IO (pin_a0, port_a etc.) you never do bcf/bsf directly on the port so the
        Message 3 of 6 , Dec 2, 2001
          Stef, could be more preciese about what caused your problem? When you use
          the Jal IO (pin_a0, port_a etc.) you never do bcf/bsf directly on the port
          so the problem does not arise (this is exactly the reason pin_a0 etc exist
          and use a shadow register).

          Wouter
        • wouter van ooijen & floortje hanneman
          ... to ... I would say: don t mess with the RA etc file registers, nor with the TRIS regsiters and ditto instructions: use pin/port_* and *_direction! Wouter
          Message 4 of 6 , Dec 3, 2001
            > So the solution is: always set the output latch before changing from input
            to
            > output.

            I would say: don't mess with the RA etc file registers, nor with the TRIS
            regsiters and ditto instructions: use pin/port_* and *_direction!

            Wouter
          • Stef Mientki
            hi Wouter, maybe my conclusion was too premature. It was based on: if I disable the serial ouput, the circuit works perfect . ... Now you say this, I looked
            Message 5 of 6 , Dec 3, 2001
              hi Wouter,

              maybe my conclusion was too premature.
              It was based on: "if I disable the serial ouput, the circuit works perfect".

              jallist@yahoogroups.com wrote:

              > Stef, could be more preciese about what caused your problem? When you use
              > the Jal IO (pin_a0, port_a etc.) you never do bcf/bsf directly on the port
              > so the problem does not arise (this is exactly the reason pin_a0 etc exist
              > and use a shadow register).

              Now you say this, I looked again through my own code, and there it was/is :
              - RB0 is used in an interrupt routine, that directly changes the value of RB0
              (so that could be well the problem)
              - RB2 is used for the serial output
              - RB0,RB4,RB5,RB6,RB7 are used for a 20 key matrix
              For the keybord scan I set the output latches of (RB0,) RB4..RB7 at 0, only
              once.
              Then I scanned the keybord just by changing the TRISB values, so a logic "0"
              is placed on 1 of the scan lines.
              But randomly 1 or more output latches became 1 and stayed there.

              So the solution is: always set the output latch before changing from input to
              output.
              Now the circuit behaves well and stable.

              Thanks for the tip on the pragma fuses !

              Stef

              >


              [Non-text portions of this message have been removed]
            • Stef Mientki
              ... You are quiet right, that s a better solution, mea culpa. Stef
              Message 6 of 6 , Dec 4, 2001
                > > So the solution is: always set the output latch before changing from input
                > to
                > > output.
                >
                > I would say: don't mess with the RA etc file registers, nor with the TRIS
                > regsiters and ditto instructions: use pin/port_* and *_direction!
                >
                > Wouter

                You are quiet right, that's a better solution, mea culpa.
                Stef
              Your message has been successfully submitted and would be delivered to recipients shortly.