Hardware UART parameter settings

[kmp84]

Hi All,

I can't setup parity and data bits parameters for HW uart .

Only this works :
"#use rs232(baud=9600,xmit=PIN_C6,rcv=PIN_C7,PARITY=N,BITS=8,STOP=1,errors,RESTART_WDT,STREAM=rs_485)"

I want to change parity and data bits parameters for hardware uart.

Anybody have an idea?

[temtronic]

According to the Help files(F11), 'Bits' can only be 8 or 9 for the hardware UART which makes sense.Parity can be Even,Odd or None.
These are hardware constraints set by Microchip as 'UARTs' are 99.9999% 8 bit devices.

If you require some other combination you need to force the 'software UART' option if using a PIC.

If you tell us why you need to select 'nonstandard' hardware options, perhaps there's another solution.3rd party UART, custom FPLGA,special PIC,discrete logic,etc. You should also tell us the other spec like speed.

It's normal to set once and forget the options so do you need 'dynamic' configuration of the UART?

hth
jay

[Ttelmah]

Let's ask one critical question.
Compiler version?.

Now, the PIC's UART, _does not support parity at all_.

To generate '8bits with parity', the compiler sets the UART to 9bit mode, and adds a software generated parity bit. This only works in some compiler versions. Since it is trying to be compact, it generates the code just for the one selected parity option.
9bits with parity, is then impossible (since the UART can't develop 10 bit data).
You can change parity 'on the fly', by setting up two streams, one for even, and one for odd parity, and selecting the one you want to use. So one for 8bit even, and one for 8bit odd.
The easiest way to change things on the fly, is to just set the UART to 9bits, no parity, and have your own routines to generate 7 or 8bit data with parity, in the 9bit output. When sending 7 bit data you will get an extra stop bit, but this doesn't matter at all.

Best Wishes

[kmp84]

[temtronic]

Ok... I have to ask...
HOW do you test and confirm the communications parameters of the slaves?
Different baud rates/parity.etc. will give 'interesting' data to the host.
Normally all device in a network share the same UART settings.

jay

[kmp84]

[Ttelmah]

If it is only going to be 8n, or 7e, then just stick with 8bit data and calculate the parity bit yourself.
Look at the find_parity function at the end of this thread:

<http://www.ccsinfo.com/forum/viewtopic.php?t=21363>

Best Wishes

[kmp84]

[ckielstra]

The topic in this thread still doesn't make any sense to me.

Why do you want to be able to make so many different configurations? Choose one that fits your business and then stick to it. Keep things simple!!!
The more options you implement, the more testing you will have to do and users will make configuration errors and not to forget documenting all these options. Implementing more options in software seems cheap but costs you a lot of time/money in the long run.

There is a good reason why all new devices in the last 30 years don't use parity. In an 8 bit system an extra parity bit causes 12.5% extra overhead but can only detect an odd number of errors in the byte, i.e. when there are a multiple of 2 bits flipped then this goes unnoticed.
CRC codes are way more efficient in terms of bandwidth and depending on the chosen parameters can detect more errors than a simple parity bit.

Please choose the 8N1 format so you are compatible with the rest of the world and you can use the hardware UART. Software UART is flexible but comes with severe limitations like: no buffering, no interrupts, requires high speed polling or you will miss incoming data.

[kmp84]

[temtronic]

Well I know about 'old and expensive' equipment! I've got a $100,000 68K based system in the basement collecting dust. Still works,even the 170Meg SCSI drives.....sorry I digress....

A possible solution it to have a PIC based 'protocol translator' on the old devices.While most will say the 18F46K22 is way overkill,the idea is to have PIC with 2 hardware UARTS and some RAM,cut code to have ISRs and circular buffers(ex_sisr.c).This way the device is happy and the 'outside world' would see a 'normal' 8-n-1 serial device.
Hardware is simple, PIC,MAX232,5 caps,powered from the 'device'.

A benefit of this solution is that the 'host' code is greatly simplified as all devices communicate the same way.

Just another idea to ponder....

hth
jay

[kmp84]

Thanks for your help Ttelmah and temtronic!

Any flexible code to change parity control and speed for hardware UART in runtime (i.e keyboard and LCD for example)?
I tried with switch case construction and #use rs232 ..... , but it didn't work!

[temtronic]

I haven't tried as I've never needed to ...
but...
you 'should' be able to access the registers directly and 'diddle' the bits are required.
I'd 'reset'( clear) the UART after that though to flush xmt and rcv buffers.
Be real careful though..one wrong bit and you've lost communications !!

Please try and report back
hth
jay

[Ttelmah]

Except there aren't any bits for parity (at least on the PIC16/18...).

As I pointed out earlier, the PIC does not generate or handle parity at all. It has to be done in software. Hence it is much easier to just generate and test the parity bit yourself.
Quote from the manual for the 4520 for example:

RX9D: 9th bit of Received Data
This can be address/data bit or a parity bit and must be calculated by user firmware.

The parity routine I pointed to earlier in the thread is very efficient indeed.

Best Wishes

[ckielstra]