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

Re: serial hw and serial sw problem [SOLVED]

Expand Messages
  • pendor2k
    Yes they were, checked and rechecked. BUT... the Rx/Tx (4550 side) lines needed to have their directions declared... stupid me, but I mixed my memories of the
    Message 1 of 16 , Jun 1, 2011
    • 0 Attachment
      Yes they were, checked and rechecked.
      BUT...
      the Rx/Tx (4550 side) lines needed to have their directions declared... stupid me, but I mixed my memories of the old libraries that did this thing by themselves in init routine.
      Nevertheless, thanx again!

      Fabián


      <sebastien.lelong@...d> wrote:
      >
      > Are your RX/TX wire crossed-over between 4550 and 628 ?
      >
      > Cheers,
      > Seb
      >
      > 2011/5/31 pendor2k <pendor2k@...>
      >
      > >
      > >
      > > Hi people!
      > > I´ve got (among other stuff I´m struggling with) a board with a 18F4550 (at
      > > 48 MHz) and a little one with a 16F628 (at 20 MHz).
      > > If I try to communicate serially sending chars from the 4550 to the 628 it
      > > fails utterly, but when I connect the 628 to the PC (same settings, of
      > > course) via a MAX232 it works flawlessly.
      > > I´m using serial_software (at 9600, 8N1) at the 4550 side (can´t use serial
      > > hardware because of USB and SPI on the same board, by the way).
      > > The 628 side uses serial hardware at 9600.
      > > I´ve made every combination I could think of and there´s still no
      > > communication between the 4550 and the 628. I´ve even used serial software
      > > at the 628 side to no avail.
      > > The PICs are connected pin to pin, with nothing in between.
      > > Any ideas?
      > > Thanx in advance.
      > >
      > > Fabián
      > >
      > > P.S. jal v2.4n, jallibs 0.6
      > >
      > >
      > >
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • zz
      Greetings, ... Correct on both counts -- I never came up with a decent algorithm to decide what goes in, ``shared, v. what goes into data. Since the original
      Message 2 of 16 , Jun 1, 2011
      • 0 Attachment
        Greetings,

        --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:

        > as we could see JAL really does not allocate from the range
        > defined in the "pragma shared" - you only could use it for based
        > variables (you actually could use ANY address as base, strangely
        > JAL does not verify if it is legal one or not).

        Correct on both counts -- I never came up with a decent algorithm to decide what goes in, ``shared,'' v. what goes into data. Since the original code was based on the 16f877, and there are only 16 shared bytes there, it wasn't an issue. Certain things had to be placed in the shared area. The rest was scratch for the programmer to use as he so chooses.

        The, `shared,' bit in variable definition isn't documented because I forgot about it. I'll update the docs.

        You can use any address as a base for a reason -- otherwise all of the SFRs would have to exist in some definition, but be marked, `unallocatable.' `pragma data,' simply defines data areas that can be used with dynamic allocation. The documentation here is reasonably clear. I'll work on cleaning it up, and need to add `pragma shared' to the documentation.

        --kyle
      • zz
        Greetings, ... Sorry, no, JAL is correct here. The only way you could jump to zero would be inline assembly, and that s dangerous enough as is. Much as if you
        Message 3 of 16 , Jun 7, 2011
        • 0 Attachment
          Greetings,

          --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
          >
          > Now JAL allocates in this area, and we see no any bank bits
          > (those bits are set to 0 at reset and then _main assumes so -
          > which is WRONG - if I restarted the program by jumping to 0).

          Sorry, no, JAL is correct here. The only way you could jump to zero would be inline assembly, and that's dangerous enough as is. Much as if you go about mucking with the bank or page bits directly, JAL won't notice and the various optimizers will be confused.

          If you have a need to jump to 0, it's your responsibility to make sure the compiler's assumptions are met.

          --kyle
        • a_b_aldus
          ... Kyle, but those compiler assumptions are not described anywhere! I do not see why prologue code should not setup PIC into known state - it does it for some
          Message 4 of 16 , Jun 7, 2011
          • 0 Attachment
            --- In jallist@yahoogroups.com, "zz" <kyle@...> wrote:
            > If you have a need to jump to 0, it's your responsibility to make sure the compiler's assumptions are met.

            Kyle, but those compiler assumptions are not described anywhere!
            I do not see why prologue code should not setup PIC into known
            state - it does it for some other bits. If someone does not need
            this "extra" code (I do not see why those two+ words could be of
            any importance) then is could be options controllable, like other
            bootloader features. As the much discussed mul/div routines problem
            this could be addressed as well when time comes to extend code
            generator again.

            Arcady
          • zz
            Greetings, ... Because the implicit assumption is you re using JAL, and are only going where JAL takes you. If, for example, there s some looping structure
            Message 5 of 16 , Jun 7, 2011
            • 0 Attachment
              Greetings,

              --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
              >
              > --- In jallist@yahoogroups.com, "zz" <kyle@> wrote:
              > > If you have a need to jump to 0, it's your responsibility to make sure the compiler's assumptions are met.
              >
              > Kyle, but those compiler assumptions are not described anywhere!

              Because the implicit assumption is you're using JAL, and are only going where JAL takes you. If, for example, there's some looping structure that takes you back to 0, JAL will make sure everything is set up correctly. Alternately, when some non-JAL construct is used (aka, inline assembly), the compiler doesn't know what you expect it to do!

              > I do not see why prologue code should not setup PIC into known
              > state - it does it for some other bits. If someone does not need
              > this "extra" code (I do not see why those two+ words could be of
              > any importance) then is could be options controllable, like other
              > bootloader features.

              Indeed, if a request comes in this would be easy enough to implement. The request hasn't been made. Which brings the question -- where does it end? Should there exist a preamble that brings the entire chip to a known state? That could be quite lengthy, yes? I'll let Rob address it as it really falls into his device file domain.

              > As the much discussed mul/div routines problem
              > this could be addressed as well when time comes to extend code
              > generator again.

              Absolutely! I'll work on documenting the assumptions. As I'm constantly told at my other job, everything else is just software!

              --kyle
            • a_b_aldus
              ... What do you mean non-JAL construct - inline assembler ? Asm is part of the compiler - compiler is assembling and then reassembling those codes, isn t
              Message 6 of 16 , Jun 8, 2011
              • 0 Attachment
                --- In jallist@yahoogroups.com, "zz" <kyle@...> wrote:
                > Alternately, when some non-JAL construct is used (aka, inline assembly), the compiler doesn't know what you expect it to do!

                What do you mean "non-JAL construct - inline assembler"? Asm
                is part of the compiler - compiler is "assembling" and then
                "reassembling" those codes, isn't it? So compiler knows exactly
                what user is doing (except one could use dw instruction). After
                all, you wrote this code!

                > > I do not see why prologue code should not setup PIC into known
                > > state - it does it for some other bits. If someone does not need
                > > this "extra" code (I do not see why those two+ words could be of
                > > any importance) then is could be options controllable, like other
                > > bootloader features.
                >
                > Indeed, if a request comes in this would be easy enough to implement. The request hasn't been made. Which brings the question -- where does it end? Should there exist a preamble that brings the entire chip to a known state? That could be quite lengthy, yes?

                All perif registers are available to user and could be set based on
                user preferences - compiler have no use for those (except FSR and
                such). Bank bits are kind of intimate compiler resources and
                better keep them so, but still set to known state. For me
                question is: could program execution be legitimately restarted
                from the very beginning w/o reset that sets bank bits to "proper"
                state? Answer is Yes - use "asm goto 0", and I clearly know that
                this kind of "reset" is used by programmers. Could one who does
                this, expect that those parts of CPU state would be setup properly
                by the prologue code? Answer is Yes, one could expect this.

                > I'll let Rob address it as it really falls into his device file domain.

                I do not see how it comes there except that device file provides
                compiler definitions for some registers/bits compiler uses
                internally. But it cannot (may be this requires some thinking)
                to tell what to generate for prologue/epilogue.

                Arcady
              • zz
                Greetings, ... Yes, and my attitude has always been once one ventures into inline assembly, all bets are off. For example, if one twiddles STATUS
                Message 7 of 16 , Jun 8, 2011
                • 0 Attachment
                  Greetings,

                  --- In jallist@yahoogroups.com, "a_b_aldus" <a_b_aldus@...> wrote:
                  >
                  > --- In jallist@yahoogroups.com, "zz" <kyle@> wrote:
                  > > Alternately, when some non-JAL construct is used (aka, inline assembly), the compiler doesn't know what you expect it to do!
                  >
                  > What do you mean "non-JAL construct - inline assembler"? Asm
                  > is part of the compiler - compiler is "assembling" and then
                  > "reassembling" those codes, isn't it? So compiler knows exactly
                  > what user is doing (except one could use dw instruction). After
                  > all, you wrote this code!

                  Yes, and my attitude has always been once one ventures into inline assembly, all bets are off. For example, if one twiddles STATUS<rp0> directly, the compiler does not catch it. This is noted in the manual:

                  Chapter 10. Assembly: ``Note that when using inline assembly you should not modify the bank or page registers, FSR, or BSR. If these are modified, it is the programmers responsibility to return them to their original states.''

                  > Bank bits are kind of intimate compiler resources and
                  > better keep them so, but still set to known state. For me
                  > question is: could program execution be legitimately restarted
                  > from the very beginning w/o reset that sets bank bits to "proper"
                  > state? Answer is Yes - use "asm goto 0", and I clearly know that
                  > this kind of "reset" is used by programmers. Could one who does
                  > this, expect that those parts of CPU state would be setup properly
                  > by the prologue code? Answer is Yes, one could expect this.

                  I trust you mean, `asm page goto 0,' and I'm not convinced, but have modified the optimizers such that they will now follow the direct CALLs and GOTOs, which guarantees the bank bits are set correctly.

                  --kyle
                Your message has been successfully submitted and would be delivered to recipients shortly.