View previous topic :: View next topic |
Author |
Message |
kmp84
Joined: 02 Feb 2010 Posts: 354
|
Hardware UART parameter settings |
Posted: Mon Nov 18, 2013 7:56 am |
|
|
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
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Mon Nov 18, 2013 8:11 am |
|
|
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
Joined: 11 Mar 2010 Posts: 19538
|
|
Posted: Mon Nov 18, 2013 8:29 am |
|
|
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
Joined: 02 Feb 2010 Posts: 354
|
|
Posted: Mon Nov 18, 2013 8:35 am |
|
|
temtronic wrote: | 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 |
I've just built communication controller which communicate with PC on same phisical rs485 line with other slave devices with different UART parameters i.e 9600/7/even/1;9600/7/odd/1;4800/7/odd/1 e.t.c
and a want to make my controller to be able for setting these options!
My Compiller ver. PCWHD 4.104
Thanks for reply! |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Mon Nov 18, 2013 8:54 am |
|
|
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
Joined: 02 Feb 2010 Posts: 354
|
|
Posted: Mon Nov 18, 2013 9:29 am |
|
|
temtronic wrote: | 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 |
Sorry for my mistake !
All devices work at same UART settings : 9600/8n/1 or 9600/7/e/1 .. e.t.c
and I want to change. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19538
|
|
Posted: Mon Nov 18, 2013 10:30 am |
|
|
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
Joined: 02 Feb 2010 Posts: 354
|
|
Posted: Tue Nov 19, 2013 7:00 am |
|
|
Ttelmah wrote: | 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 |
Hi again,
I changed my code to work with software uart (#use rs232(baud=9600,xmit=PIN_B3,rcv=PIN_B2,PARITY=E,BITS=7,STOP=1,STREAM=rs_485)) ,but I havn't success with 7 bits data format (9600/7/E/1) only with 7 bit data format . Eight bit data format works fine (9600/8/E/1,9600/8/O/1,9600/8/N/1) |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Tue Nov 19, 2013 7:48 am |
|
|
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
Joined: 02 Feb 2010 Posts: 354
|
|
Posted: Tue Nov 19, 2013 8:29 am |
|
|
ckielstra wrote: | 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. |
As I said before some post "I had devices which are manufacture befor 20-30 year ago they still work , usefull and are EXPENSIVE!"
I can't throw at trash ! I've to adapt my devices to their communication protocol !
Thanks again . |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Tue Nov 19, 2013 9:30 am |
|
|
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
Joined: 02 Feb 2010 Posts: 354
|
|
Posted: Wed Nov 20, 2013 4:15 am |
|
|
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
Joined: 01 Jul 2010 Posts: 9243 Location: Greensville,Ontario
|
|
Posted: Wed Nov 20, 2013 7:25 am |
|
|
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
Joined: 11 Mar 2010 Posts: 19538
|
|
Posted: Wed Nov 20, 2013 8:51 am |
|
|
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
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Wed Nov 20, 2013 4:33 pm |
|
|
kmp84 wrote: | ckielstra wrote: | The topic in this thread still doesn't make any sense to me.
... |
As I said before some post "I had devices which are manufacture befor 20-30 year ago they still work , usefull and are EXPENSIVE!"
I can't throw at trash ! I've to adapt my devices to their communication protocol !
Thanks again . | Sorry but you didn't mention all this in this thread so how am I to know?
Starts to make sense, but when all these devices are communicating with your PC, then why not use the PC to do the conversion? You are talking about adding a keyboard and display when all these are already available on your PC.
If you want to continue with your 'communication controller', then be my guest but I'd keep it as simple as possible: no display or keyboard, just use some rotating switches, one for parity (N, O, E) and another for the baud rates.
You didn't mention the PIC you are using but I would choose one with USB connection to the PC instead of RS232 as the PCs with RS232 are becoming rare.
Remember that 7-bit + parity communication can be implemented on a 8-bit hardware UART. The 8th bit is then the parity bit.
7-bit no parity can be sent as 8-bit with the LSB always 1, this creates 7-bit with two stop bits but the extra stop bit should never be a problem.
Receiving 7 bits with an 8-bit UART is more tricky. Perhaps here use the software UART. Or, you know the devices you communicate with and can skip this option. |
|
|
|