Suart module with parity bit

[yolk]

Trying to interface with an old device that works with a serial protocol 8E1. it's a firmware that cannot be changed.
also, the device is not directly available for tests
I've tried unsuccessfully to modify the suart.bas module adding the 9 parity bit
Is there any chance to have the suart.bas module with the 9th parity bit option added?

[Jerry Messina]

I've tried unsuccessfully to modify the suart.bas module adding the 9 parity bit

Could you show what you tried?

Which pic are you using? Does it have to be a software uart?
Some of the newer devices like the Q43 have hw parity support builtin, but pretty much any of the hardware uarts can be setup to handle parity by using 9-bit mode for 8bits+parity.

Software uarts are notoriously unreliable, especially for reception.

[yolk]

I'm using a 26K20, actually dealing with the 2 hardware uarts and one suart that is the one that communicates with the other board. Other board is a yacht air conditioner controller, board has been changed and there is no more compatibility with the wifi control module I've made some years ago. the new board seems to refuse the bytes sent probably (i suppose) as it expects the 9th parity bit. old board uses a very old ST processor while the new one has a renesas. board maker is in china d communication is very difficult. I've tried to add the parity bit in the assembler part of the writebyte function but I'm not so good in assembler and it does not work..

[Jerry Messina]

Here's a copy of suart.bas that I modified to add parity.
It'll do 8N1, 8O1, or 8E1, which you set using '#option SUART_PARITY'

Code: Select all

// SUART_PARITY options: 0=none (8N1), 1=odd (8O1), 2=even (8E1)
#option SUART_PARITY =2
include "suart_parity.bas"

This should compute the parity and add the ninth-bit to the WriteByte() routine.
For RX, the parity bit is ignored.

I threw this together from some other stuff I had but didn't really test it other than to make sure it compiles.

[yolk]

Thanks Jerry

I'll give it a try asap and let you know..

[yolk]

Hello Jerry

Tested the module but it seems not to work properly

Set to work with EVEN parity (2)

I send the string EVEN 8,1 and I receive EWWO 8,1

any ideas?

[Jerry Messina]

I guess I'll have to actually try it and see what's going on.
What clock are you using for the K20?

Also, when you say you sent that string, you do mean you sent it from the pic to your external device, right?

I'm not going to be able to get to it until the weekend though.

[yolk]

Hello Jerry

I'm using 16 MHz but I've tried also other baudrates with the same result

I send the string from the PIC to the pc using the swordfish serial terminal to receive data.

[Jerry Messina]

I had a chance to test suart_parity.bas on some real hdw and it worked ok for me.
I used an 18F26K22 at 16MHz (close enough to the K20) , and tried baudrates from 9600-38400 with no parity, even, and odd settings.
The test program I used is below.

The problem you're having may be due to the way a software UART works... there are a lot of restrictions, especially when it comes to receiving data. With a pure software UART your program must always be sitting in the UART.Receive routine when the external device sends data. Unlike a hardware uart there's no buffering at all, so you must always be waiting for a START bit. If the external device transmits data when you're not ready you'll lose sync. That means you'll have a problem if your program uses interrupts, as that will effect things as well.

If you need something a little more flexible, I have some hardware-assisted suart routines on the wiki at https://www.sfcompiler.co.uk/wiki/pmwik ... er.HWSUART . Look those over, and if any of them seem usable I can add parity to whichever implementation you think would work best for you. They have some hdw restrictions, and unfortunately the K20 you're using doesn't have PPS to be able to remap anything.

edit: I tested this using the SF SerialCommunicator, but to be honest you might try another serial terminal emulator such as teraterm (http://www.teraterm.org/) as I find it easier to send individual chars, lines, set char pacing, etc.

Code: Select all

program test_suart_parity

device = 18F26K22
clock = 16

include "intosc.bas"
#option DIGITALIO_INIT = true   // automatically call SetAllDigital at startup
include "setdigitalio.bas"

// SUART_PARITY options: 0=none (8N1), 1=odd (8O1), 2=even (8E1)
#option SUART_MODE = 1     // umTrue for FTDI serial USB-UART, default is 2 (umInverted)
#option SUART_INIT_TX = true
#option SUART_PARITY = 2
include "suart_parity.bas"

const 
    CR = $0D,
    LF = $0A

dim b as byte
dim buf(32) as byte     // input rx buffer
dim ix as byte          // input rx index
dim ox as byte          // output tx index

main:
UART.SetMode(umTrue)    // using FTDI USB-TTL UART cable

UART.SetTX(PORTB.4)     // TXD output pin
UART.SetRX(PORTB.5)     // RXD input pin
UART.SetBaudrate(sbr38400)

// this delay allows time for the device you're connect up to
// to see a proper idle level on its RX input since our TX output 
// may have been "invalid" at startup causing the receiver to see
// garbage for the first character or a serial BREAK 
delayms(10)

// echo chars until CR
// (this will fail if chars come in too fast)
UART.write(CR, LF, ">")
repeat
    b = UART.ReadByte()
    UART.WriteByte(b)
until (b = CR)

// buffered line input (terminates on CR)
getline:
UART.write(CR, LF, ":")
ix = 0
repeat
    b = UART.ReadByte()
    buf(ix) = b
    if (ix < bound(buf)) then
        ix = ix + 1
    endif
until (b = CR)

// send received line
sendline:
ox = 0
while (ox <> ix)
    UART.WriteByte(buf(ox))
    ox = ox + 1
end while
goto getline

end program

[yolk]

Hello Jerry

Thanks for all of your efforts.

I've tested the routine only for sending characters, received by a PC running swordfish serial plugin.
I will test also with teraterm (which I have) and I'll check what happens.
So that case the receiver is the PC and I'm pretty sure it has a buffer, so seems strange I get only some strange characters.
To be more precise, it seems that the first 4..5 characters are received bad, than it goes better.
Anyway if you say that it works, I will move focus on other things (maybe baudrate, which unfortunately I can't change)

Thanks a lot, I'll let you know

[Jerry Messina]

It should work OK for transmitting... that part's easier.
I don't think you'll see anything different using teraterm since it's a hardware function.

Are you allowing time at startup for the osc to stabilize? If the first few chars are bad and then it gets better that could be the issue. Do you have a scope or logic analyzer where you could measure the bit times?

[Jerry Messina]

Well this is sort of embarrassing...

I send the string EVEN 8,1 and I receive EWWO 8,1

So, I just tried to transmit the string "EVEN 8,1" and I got exactly what you did... "EVEN" became "EWWO".

Code: Select all

    uart.write("EVEN 8,1")

It works ok when you compile for N81 (#option SUART_PARITY = 0), so it's something I did when I added the parity options.
Let me check into it...

[Jerry Messina]

Try this version of suart_parity.bas (it should clear up the "EWWO" issue)

I changed the attributes of the parity functions to use 'access', which appears to be required since they're called from functions with that attribute. Without that it was overlaying variables. I wasn't aware of that since 'access' isn't something I've used much, so I didn't think to check.

It *seems* to be ok now, but let me know if you run across anything else that seems odd.