Announcement

Collapse
No announcement yet.

18FxxQ43 support

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

  • Henrik Olsson
    replied
    Can confirm that changed .lib files work for HSERIN. Only tried with LONGs enabled and only with HSERIN, not HSERIN2 yet.
    I'll report further findings (if any) as I continue to play around with this chip - when time permits.

    Thank you Charles!

    /Henrik.

    Leave a comment:


  • Charles Leo
    replied
    I've made corrections to the lib files for the HSER commands. Replace two files from this zip:
    http://pbp3.com/downloads/q43_libs_20210907.zip

    Leave a comment:


  • Ioannis
    replied
    Originally posted by Henrik Olsson View Post
    No sure I understand what you mean.
    Yes, you can read U1RXB, that's what I'm doing in my first example posted yesterday (the one that works since it's not using HSERIN).

    HSERIN uses the UART receive interrupt flag to determine if there's a byte in the recevice buffer, problem is it looks at the wrong interruptflag.
    I missed that snipet that was based on U1RXB direclty. Sorry.

    Seems tumbleweed got it spot on!

    Leave a comment:


  • tumbleweed
    replied
    Originally posted by Henrik Olsson View Post
    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.
    You've got it right, and the right registers too.

    The library file pbp_pic18FxxQ43.lib has a number of errors for HSERIN, HSERIN2, and HSEROUT2:
    Code:
    HSERIN
    HSERINTO
    reference: PIR3
    should be: PIR4, U1RXIF (bit 0)
    
    HSEROUT
    reference: PIR4, U1TXIF (ok)
    
    
    HSERIN2TO
    HSERIN2
    reference: PIR6, U2RXIF (bit 0)
    should be: PIR8, 0
    
    HSEROUT2
    reference: PIR6, U2TXIF (bit 1)
    should be: PIR8, 1


    Leave a comment:


  • Henrik Olsson
    replied
    No sure I understand what you mean.
    Yes, you can read U1RXB, that's what I'm doing in my first example posted yesterday (the one that works since it's not using HSERIN).

    HSERIN uses the UART receive interrupt flag to determine if there's a byte in the recevice buffer, problem is it looks at the wrong interruptflag.

    Leave a comment:


  • Ioannis
    replied
    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...

    Leave a comment:


  • Henrik Olsson
    replied
    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.

    Leave a comment:


  • Henrik Olsson
    replied
    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.

    Leave a comment:


  • Henrik Olsson
    replied
    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 :-)

    Leave a comment:


  • Ioannis
    replied
    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.

    Leave a comment:


  • Henrik Olsson
    replied
    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.

    Leave a comment:


  • Charles Leo
    replied
    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.

    Leave a comment:


  • tumbleweed
    replied
    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?.

    Leave a comment:


  • Ioannis
    replied
    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

    Leave a comment:


  • Charles Leo
    replied
    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.

    Leave a comment:

Working...
X