Printable View
Has anyone here used the 2nd hardware UART on a PIC processor before? Are there any tricks to it? I, for the life of me, can't get the 2nd one working at all. 1st UART works fine, but no joy with the 2nd. Tried both the suggested PBPs defines and doing it manually with register settings suggested in the datasheet. Processor is a PIC18F26K83. Says it's supposed to have 2 (the way I read it)???
Thanks for any tips,
Troy
my tipQuote:
Thanks for any tips,
it works just fine if you do it properly
You might want to post what you've tried so we can give you some 'tips'
Quote:
Originally Posted by tumbleweed
Code:OSCFRQ = %1000 '64Mhz
Define OSC 64
' Set receive register to receiver enabled
' Set transmit register to transmitter enabled
DEFINE HSER_RXREG PORTC
DEFINE HSER_RXBIT 4
DEFINE HSER_TXREG PORTC
DEFINE HSER_TXBIT 5
DEFINE HSER_BAUD 9600
' Set receive register to receiver enabled
' Set transmit register to transmitter enabled
'DEFINE HSER2_RXREG PORTB
'DEFINE HSER2_RXBIT 3
'DEFINE HSER2_TXREG PORTB
'DEFINE HSER2_TXBIT 0
'DEFINE HSER2_BAUD 9600
'This works
hSerout ["Test",13,10]
'This doesn't
hSerout2 ["Test",13,10]
Apologies, here is the actual code:
Code:OSCFRQ = %1000 '64Mhz
Define OSC 64
PRECISION CON 8 SYSTEM '8 byte = 64 bit precision
INCLUDE "N-Bit_Math.pbp"
DEFINE HSER2_RXREG PORTB
DEFINE HSER2_RXBIT 3
DEFINE HSER2_TXREG PORTB
DEFINE HSER2_TXBIT 0
DEFINE HSER2_BAUD 9600
DEFINE HSER_RXREG PORTC
DEFINE HSER_RXBIT 4
DEFINE HSER_TXREG PORTC
DEFINE HSER_TXBIT 5
DEFINE HSER_BAUD 9600
ANSELA = %00000000 'Everything Digital
ANSELB = %00000000 'Everything Else Digital
ANSELC = %00000000 'Everything Else Digital
TRISB.0 = 0
TRISB.3 = 1
TRISC.4 = 1
TRISC.5 = 0
'works
hSerout ["Test",13,10]
'doesn't work
hSerout2 ["Test",13,10]
you don't appear to have set the portb pins used to digital [anselb =$f6]
or not
mcc sets the involved registers like this to match your settings
TRISB = 0xFE;
ANSELB = 0xF6;
U2RXPPS = 0x0B; //RB3->UART2:RX2;
RB0PPS = 0x16; //RB0->UART2:TX2;
U2P1L = 0x00;
U2P1H = 0x00;
U2P2L = 0x00;
U2P2H = 0x00;
U2P3L = 0x00;
U2P3H = 0x00;
U2CON0 = 0xB0;
U2CON1 = 0x80;
U2CON2 = 0x00;
U2BRGL = 0x82;
U2BRGH = 0x06;
U2FIFO = 0x00;
U2UIR = 0x00;
U2ERRIR = 0x00;
U2ERRIE = 0x00;
I'm guessing this is a reply to my 1st code post which I inadvertently cut the TRIS settings in my (hastily) attempt for reader friendly pruning, but I can assure you every port was set to digital all the time. What's more, the 2nd UART was originally configured to the same pins as the 1st. When my head was too sore from banging against that wall, I switched the 1st UART to those pins and voila, they worked.
Troy
Quote:
Originally Posted by richard
I'm far from an expert in this space. And haven't used the second USART port on a PIC
But maybe PMD5 register for UART2 isn't being set correctly by picbasic??
bit 5 U2MD: Disable UART2 bit
1 = UART2 module disabled
0 = UART2 module enabled
bit 4 U1MD: Disable UART1 bit
1 = UART1 module disabled
0 = UART1 module enabled
extremely unlikelyQuote:
I'm far from an expert in this space. And haven't used the second USART port on a PIC
But maybe PMD5 register for UART2 isn't being set correctly by picbasic??
note power on defaults for PDM5
Attachment 9707
did you try setting uart regs like mcc suggests ?
note uart registers
Attachment 9708
Regarding setting the regs directly: this is what I've tried (note this is set to 115200 baud as that was the original objective)
That doesn't provide any joy either.Code:OSCFRQ = %1000 '64Mhz
Define OSC 64
PRECISION CON 8 SYSTEM '8 byte = 64 bit precision
INCLUDE "N-Bit_Math.pbp"
'Use for hardware serial comms to SD card module
'******************************************************************************
'Configure UART Control Register 0
U2CON0.7 = 1 'BRGS = 1 (high speed baud generator)
U2CON0.6 = 0 'ABDEN = 0 Auto-baud Detect Disabled
U2CON0.5 = 1 'TXEN: Transmit Enabled
U2CON0.4 = 1 'RXEN: Receive Disabled
U2CON0.3 = 0 '0000 = Asynchronous 8-bit UART mode
U2CON0.2 = 0 '0000 = Asynchronous 8-bit UART mode
U2CON0.1 = 0 '0000 = Asynchronous 8-bit UART mode
U2CON0.0 = 0 '0000 = Asynchronous 8-bit UART mode
U2CON1.7 = 0 'Turn Serial port 2 off for baud setting
U2BRGL = 138 'Baud Divisor low byte
U2BRGH = 0 'Baud Divisor high byte
U2RXPPS = %1011 'Assign UART RX pin to RB3
RB0PPS = %010110 'Assign UART2 TX pin to RB0
U2CON1.7 = 1 'Turn Serial port 2 on
'******************************************************************************
'Configure AN2 as Analog Inputs (PortA2)
ANSELB = %00000000 'Everything Digital
TRISB.0 = 0 'SD_Card_TX Hardware UART
TRISB.3 = 1 'SD_Card_RX Hardware UART
hSerout2 ["Test",13,10]
I was going to say that you need to unlock the PPS before trying to configuring it but reading the datasheet it looks like it is unlocked at POR - I've always thought it was the other way around.
Anyway, here's the relevant parts from a project of mine which uses both UARTS, in this particular case I even use the PPS peripheral to switch UART2 pins around to two different devices. Using HSEROUT / HSEROUT2 in the code it worked out fine. This is for a 67K40 so it won't match your setup but perhaps it can provide some pointers./Henrik.Code:'----------------------------------------------------
' PPS Unlock
PPSLOCK = $55
PPSLOCK = $AA
@ BCF PPSLOCK, PPSLOCKED
RC6PPS = $0C ' We want PORTC.6 as EUSART1 TX
RX1PPS = %00010111 ' We want PORTC.7 as EUSART1 RX
RG7PPS = $0E ' We want EUSART2 TX on PortG.7
RX2PPS = %00110010 ' We want EUSART2 RX on PortG.2
' Since we're switching UART pins around during runtime we need to leave the PPS lock open.
'PPSLOCK = $55
'PPSLOCK = $AA
'@ BSF PPSLOCK, PPSLOCKED
'----------------------------------------------------
ANSELA = %00110000 ' RA4, 5 analog, rest digital
ANSELB = 0
ANSELD = 0
ANSELE = 0
ANSELF = 0
ANSELG = 0
' Setup for EUSART1
RCSTA1 = $90 ' Enable serial port & continuous receive
TXSTA1 = $24 ' Enable transmit, BRGH = 1
SPBRG1 = 64 ' 19200 Baud @ 64MHz, 0,04%
SPBRGH1 = 3
BAUDCON1.3 = 1 ' Enable 16 bit baudrate generator
' Setup for EUSART2
RCSTA2 = $90 ' Enable serial port & continuous receive
TXSTA2 = $24 ' Enable transmit, BRGH = 1
SPBRG2 = 138 ' 115200 Baud @ 64MHz, -0,08%
SPBRGH2 = 0
BAUDCON2.3 = 1 ' Enable 16 bit baudrate generator
TRISC.6 = 0 ' UART1 TX
TRISC.7 = 1 ' UART1 RX
TRISG.7 = 0 ' UART2 TX
TRISG.2 = 1 ' UART2 RX
mcc suggests different baud-gen figures that what you have used
mcc
U2BRGL = 0x82;
U2BRGH = 0x06;
Yes Richard, I realise that *if* I was operating in 9600 baud, but I noted at the top of that register post I was setting everything to 115200 originally and that pruned snippet of the register setting code was copy-&-pasted from my original attempts at getting this to work. Apologies for not updating those values to make them consistent with the previous posts utilising PBP defines for the config. I did have my terminal receiver running on the correct baud for the settings irrespective.Quote:
Originally Posted by richard
One thing I've noticed since is the Hserout2 statement is hanging/crashing my code.
Sending a character to the U2TXB register directly *does* work - at least at 9600 baud.
Troy
Thanks Henrik,
I'll see if there's anything there that I've maybe missed.
Cheers,
Troy
and just another update to clarify:
I can send characters through the 2nd UART by sending them directly to the 2nd UARTs transmit register (even at 115200 baud).
To achieve that, I need to manually set the UART control registers, using PBP defines doesn't seem to work for that.
Hserout2 seems to be crashing my programs on this processor (PIC18F26K83)
Everything is dandy with the 1st UART. I can configure it both ways and utilise hserout without issue.
Troy
ps: these current tests are being done on a PIC that's completely isolated from all other components. The only connections is the x5 inline serial wires and the minimum 2 serial test wires to the output.
In my experience the PBP HSER Defines doesn't generate any output (ie ASM code) code unless there's also a HSEROUT statement in the code - which seem to match what you're seeing. So you can't use the DEFINE directive to configure the UART unless you're also using HSEROUT.
The fact that you CAN spoonfeed the UART and get data out means you DO have PPS and the UART itself configured properly so HSEROUT2 "should" work. Like I said, I've successfully done it on a K40 series so it must be something specific to this device or device series.
And....looking at the generated code for HSEROUT2 on a K83 here's part of it:U2TXIF has the value of 5 which is correct (U2TXIF is bit 5 in the register) but it's looking at bit 5 in PIR6 which is wrong. U2TXIF is in PIR7.Code:000004 02884 HSEROUT2 ;movlb 15 ; Set bank select to 15 to pick up any SFRs not in Access bank
000004 0139 02885 banksel PIR6 ; Set bank for PIR3
000006 0004 M clrwdt
000008 ABA6 02887 btfss PIR6, U2TXIF ; Wait till ready
00000A D7FD 02888 bra hserout2loop
00000C 013D 02913 banksel U2TXB ; Set bank for TXREG2
00000E 6FD2 02914 movwf U2TXB ; Send the char
000010 80D8 02915 bsf STATUS, C ; Set no timeout for Serout2mod
000012 EF0B F000 02916 goto DUNN ; That's it
At this point I'm not sure where the actual error comes from and if it's something you or me can fix by simply editing a file or if it's buried in the exectuable of the compiler.
/Henrik.
EDIT: I think the compiler is using the pbp_pic18FxxK42.lib library file when compiling for the K83 as well because in IT is the reference to PIR6 in the HSEROUT2 function (and HSERIN2 as well) which, for the K42, is correct. For K83 it is not.
I guess we can bodge this by editing the K42.lib file but then it won't work for K42 devices so, yeah... :-(
good catch Henrik.
I wouldn't do that. There are a lot more differences between the K42 and the K83 than just the U2IF flag... the K83 should really have its own set of libs.Quote:
I guess we can bodge this by editing the K42.lib file but then it won't work for K42 devices so, yeah... :-(
You can specify which library to use for a device in the *.pbpinc file.
For example PIC18F26K83.PBPINC specifies
LIBRARY "pbp_pic18FxxK42_Long"
LIBRARY "pbp_pic18FxxK42"
Aah, right, now that you mention it I remember seeing that information somewhere - which turned out to be in post #8 in a thread on MeLabs forum. Things like this really should be in the manual.
Anyway, that means that we have a chance of fixing issues like these in case MeLabs won't. Thanks tumbleweed!
Thanks Henrik,
As Tumbleweed said: good catch! Okay, it's probably a bit beyond my paygrade to fix, but at least that sheds some light on the root cause.
Cheers,
Troy
Charles promissed that he would try to fix any issues found with the exixting version of PBP.
Maybe you can report that to him or the melabs forum.
Ioannis
Thanks Ioannis,
I'll endeavour to contact Charles and pass on the issue. As this is pretty much my go-to processor these days, it would be nice to have the issue fixed.
Cheers,
Troy
Then you may report back,
Ioannis
I've started email dialogue with Charles, but to this point raised by Tumbleweed: I will say I've used this processor a lot and I reckon I've used close to 90% of its peripheral functionality (without issue), so the K42 libraries must be very close to being a perfect match I would think.Quote:
Originally Posted by tumbleweed
edit: although on further reflection, a lot of that was done in a more direct (register access) sense.
Cheers,
Troy
There are a few slight peripheral differences between the two, but most of the changes have to do with the location and layout of the interrupt bits in the various PIE, PIR, and IRP regs.
Okay, thanks, that's good to know.Quote:
Originally Posted by tumbleweed
I've received some modified or new libraries from Charles with the required include files. Initial testing is showing no issues with transmitting on the 2nd UART. I've only cranked the baud up to 38400, but so far, so good. I only mentioned the 2nd UART issue to him, so I don't know how broadly he looked at the other interrupt registers with making the mods.
Troy
if it worked at 38400 then problem is solved. Speed is irrelevant to the issue of wrong FSRs.
I am pretty sure Charles won't object in posting the corrected library file(s) on the forum.
Ioannis
Attachment 9728
I think I've done this correctly. Thanks Charles for this.
Cheers,
Troy
Oh, and special thanks again to Henrik for pinpointing the particular code. That helped a lot.
Troy