Announcement

Collapse
No announcement yet.

18FxxQ43 support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by mpgmike View Post
    If you're the religious type, include Charles in your prayers.
    Sure I will!

    Running my own business I sure can understand how difficult is to accomplish such a task when profit is low or does not exist.

    Appreciation is just a word, but I do mean it.

    Comment


    • #32
      I've posted a new version of PBP at: http://pbp3.com/downloads/PBP3_314_Setup.exe

      I would appreciate any feedback for use with the Q43 parts.
      Charles Leo
      ME Labs, Inc.
      http://melabs.com

      Comment


      • #33
        Thank you Charles!
        Surprise of the day! Installation went just fine. Waiting for the Q43 chips to put it through tortures!

        Regards,
        Ioannis

        Comment


        • #34
          Cool, thank you very much Charles!
          This prompted me to order a Q43 Curiosity Nano board from to have a play with.

          Is Q43 support the "only" change/addition?

          /Henrik.

          Comment


          • #35
            For many functions, I never use the PBP Commands, I manually manipulate the registers (UART for example). What sort of feedback would be valuable to you?
            We can crack this cotton PIC'n thang!

            Comment


            • #36
              Just report any bugs you encounter while doing what you normally do.. The bank-tracking mechanism for direct access to registers had to be changed for the first time since PBP's inception. The change wasn't huge, but it's fundamental to most operations in PBP.

              READ, WRITE, READCODE, WRITECODE, ERASECODE are working (I think), but I struggled with weirdness at times. It would help my confidence if those commands were tested.

              Also I found that none of MPLABX debugging tools work properly with this chip. The simulator pukes on the same access-bank issue that affected PBP. I'm sure they've corrected it in later versions, but we don't have access to those versions because of the assembler change that limits PBP to MPLABX 5.35. The PICKit4 had a different issue that I didn't try to diagnose.

              There may have been some minor fixes implemented in addition to the new chips. I'll summarize when I post the version history. It has occurred to me that I neglected to create a PPS guide file specifically for these chips. It's offering the K42 file, which may be accurate, but I forgot to check it. This doesn't affect compilation, it's only a user guide with clues.
              Charles Leo
              ME Labs, Inc.
              http://melabs.com

              Comment


              • #37
                Originally posted by Charles Leo View Post
                READ, WRITE, READCODE, WRITECODE, ERASECODE are working (I think), but I struggled with weirdness at times. It would help my confidence if those commands were tested.
                Especially on Q43 or all chips in general?

                Ioannis

                Comment


                • #38
                  Originally posted by Charles Leo View Post
                  I neglected to create a PPS guide file specifically for these chips. It's offering the K42 file, which may be accurate
                  I think the inputs are sort of similar, but the output settings are definitely different. The Q43 has 8 CLC's and 5 UART's which move everything around.

                  The simulator pukes on the same access-bank issue that affected PBP
                  What issue was that?.

                  Comment


                  • #39
                    I adapted a new library for the Q43, so I'm not worried about any other families. The weirdness was only on my specific Q43 test chips. The WRITE command didn't want to work in the first 10uS after power up. It would always write $FF, regardless of the data that I entered. I checked the errata, but didn't find anything. The thing is, I'm not 100% certain that the time is the relevant factor. If you observe similar behavior after the chip is up and running, please let me know.

                    The ACCESS bank on the Q43 is located half in BANK4 and half in BANK5. On all other PIC18 since the beginning of time, it's been half in BANK0 and half in whatever the highest bank, usually BANK15. When PBP is processing inline code in which multiple SFRs or variables are accessed, it tries to figure out if register is in the access bank and it omits the bank setting if it is. The test for the access bank had to be changed in several places.

                    MPASM also has to recognize when a register name is in ACCESS if you leave off the BANKED/ACCESS parameter. This appears to work ok.

                    The simulator also has to know, as it needs to handle the access bit in the instructions. As far as I could tell, it still thinks ACCESS spans BANK0.
                    Charles Leo
                    ME Labs, Inc.
                    http://melabs.com

                    Comment


                    • #40
                      Started to play around with the Q43 Curiosity board. Obligatory blinky running. Next step, UART output, got that working but at UART input I got stuck. To me it looks like something's up with HSERIN but I might be missing something crucial with this quite complex chip/setup.

                      This works:
                      Code:
                      DEFINE OSC 64
                      DEFINE HSER_RXREG PORTF
                      DEFINE HSER_RXBIT 1
                      DEFINE HSER_TXREG PORTF
                      DEFINE HSER_TXBIT 0
                      DEFINE HSER_BAUD 57600
                      DEFINE HSER_CLROERR 1
                      
                      Char VAR BYTE
                      
                      ANSELF = 0
                      WPUF.1 = 0
                      
                      TRISF.3 = 0
                      TRISF.0 = 0
                      TRISF.1 = 1
                      
                      Start:
                        HSEROUT["Start", 10,13]
                      
                      Main:
                        IF U1FIFO.1 = 0 THEN ' Receive buffer is NOT empty
                          HSEROUT [U1RXB]   ' Echo received char
                        ENDIF
                      
                        IF U1FIFO.0 = 1 THEN ' Recieve buffer is FULL
                          HSEROUT ["Buffer is full",10,13]
                        ENDIF
                      
                      Goto Main
                      And that tells me I've got the basics down, all it does is echo whatever I give it. However, replacing the meat of the code with this:
                      Code:
                      Start:
                        HSEROUT["Start", 10,13]
                      
                      Main:
                        IF U1FIFO.0 = 1 THEN ' Recieve buffer is FULL
                          HSEROUT["Buffer is full",10,13]
                        ENDIF
                      
                        HSERIN 2000, NoData, [Char]
                        HSEROUT [Char]
                      
                      Goto Main
                      
                      NoData:
                        HSEROUT["No data",10,13]
                      Goto Main
                      Makes it no longer work. It just times out, jumping to NoData and after two bytes received it detects buffer is full. It never echos the received character.

                      Am I overlooking something stupidly obvious or is there a problem with HSERIN?

                      /Henrik.

                      Comment


                      • #41
                        I have not yet the chips to test but maybe it has to do with the RXPPS? I could not figure out how this should be setup. It is a bit confusing to me right now.

                        Also in this link maybe of help https://github.com/microchip-pic-avr...t-to-pwm-part2

                        Ioannis
                        Last edited by Ioannis; 2 weeks ago.

                        Comment


                        • #42
                          Initially I tried to "manually" setupt the PPS for my particular pinout. HSEROUT worked but I could not get the HSERIN to work so I thought I had something strange with the PPS input selection going on. Then I read the K42_notes.txt and thought, OK I'll try the DEFINE method shown there. HSEROUT still worked, HSERIN still did not.

                          What's leading me to belive it's NOT something to do with the PPS (or anything else in my setup) is the fact that data DOES indeed end up in U1RXB as shown in my first example, it's just that HSERIN does not see it. I've yet to look at the generated ASM code but I would guess that the HSERIN assembly macro looks at the wrong register flag when determining if there's data to be read or not. Then again, I might be doing something really stupid - wouldn't be the first time :-)

                          Comment


                          • #43
                            Oh, the way I tried to "manullay" setup PPS for my setup was
                            Code:
                            RF0PPS = $20    ' UART1 TX mapped to PORTF.0
                            U1RXPPS = %00101001  ' UART 1 RX mapped to PORTF.1
                            For the U1RXPPS the way I understand is this: Bits 3-5 represents the port (A=0, B=1, C=2 etc), bits 0-2 represents the bit within that port. So, %00 101 001 is port 5/F, bit 1.

                            Comment


                            • #44
                              So, I took a look at the generated code from the non working example above, the one using HSERIN, and I see this:
                              Code:
                              000016 0104 02504 banksel PIR3 ; Set bank for PIR3
                              000018 0004 M clrwdt
                              00001A B0B1 02506 btfsc PIR3, U1RXIF ; 2 Check for char
                              00001C D00C 02507         bra     HSERINX         ; We're started
                              Now, in the datasheet I have they list U1RXIF at PIR4.0, not PIR3.0 and it looks to me like the error comes from the .lib file(s). Likewise, HSERIN2 seems to look at PIR6.0 when, according to my version of the datasheet U2RXIF is at PIR8.0

                              With that said I'm no expert at the ASM-level (which is why I have PBP) so it's quite possible I've got it all wrong.

                              /Henrik.

                              Comment


                              • #45
                                Is it possible to read directly the U1RXB register?

                                Sure the assembly macro will reveal any bug if there is. Unfortunately I still cannot fully understand the produced macros...

                                Comment

                                Working...
                                X