2nd hardware UART

[HenrikOlsson]

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:

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

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.

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... :-(

[tumbleweed]

good catch Henrik.

I guess we can bodge this by editing the K42.lib file but then it won't work for K42 devices so, yeah... :-(

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.

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"

[HenrikOlsson]

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!

[rocket_troy]

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

[Ioannis]

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

[rocket_troy]

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

[Ioannis]

Then you may report back,

Ioannis

[rocket_troy]

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.

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"

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.

edit: although on further reflection, a lot of that was done in a more direct (register access) sense.

Cheers,

Troy

[tumbleweed]

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.

[rocket_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.

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

[Ioannis]

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

[rocket_troy]

PBP_TEST.zip

I think I've done this correctly. Thanks Charles for this.

Cheers,

Troy