Changing Parity and Stop Bits on the FLY, #use RS232 no work

[Got PIC]

I'm banging my head against the wall trying to switch from XX, N,8,1 to some other Parity or STOP bits, on the fly. I tried using the #use rs232, using several streams, nothing seems to work?

I made some very simple code. I used SIOW test everthing. No matter what I configure the SIOW to, with respect to Parity and Stop bits, the char's are echoed???? ...as if the parity and stop bits don't matter??

It look likes the #use 232 defined, is the one used??

#use rs232(baud=115200,PARITY=N, BITS=8,xmit=PIN_G1,rcv=PIN_G2,ENABLE = PIN_F7, stream=COMM_PORT2,errors)

Is there another way without using #use rs232. You would think that set_baud() would allow you to set the Parity and stop bits...???@#$%^&*


#use rs232(baud=115200,PARITY=N, BITS=8,STOP=2, xmit=PIN_C6, rcv=PIN_C7,ENABLE = PIN_A5,stream=_N_2_COMM_PORT1,errors)

#use rs232(baud=115200,PARITY=O, BITS=8,STOP=2, xmit=PIN_C6, rcv=PIN_C7,ENABLE = PIN_A5,stream=_O_2_COMM_PORT1,errors)
#use rs232(baud=115200,PARITY=E, BITS=8,STOP=2, xmit=PIN_C6, rcv=PIN_C7,ENABLE = PIN_A5,stream=_E_2_COMM_PORT1,errors)
#use rs232(baud=115200,PARITY=O, BITS=8,STOP=1, xmit=PIN_C6, rcv=PIN_C7,ENABLE = PIN_A5,stream=_O_1_COMM_PORT1,errors)
#use rs232(baud=115200,PARITY=E, BITS=8,STOP=1, xmit=PIN_C6, rcv=PIN_C7,ENABLE = PIN_A5,stream=_E_1_COMM_PORT1,errors)

#use rs232(baud=115200,PARITY=N, BITS=8,STOP=1,xmit=PIN_C6, rcv=PIN_C7,ENABLE = PIN_A5,stream=COMM_PORT1,errors)
#use rs232(baud=115200,PARITY=N, BITS=8,xmit=PIN_G1,rcv=PIN_G2,ENABLE = PIN_F7, stream=COMM_PORT2,errors)


#int_rda //poop
void serial_isr()
{
rda_t=fgetc(_E_2_COMM_PORT1);
fputc(rda_t,_E_2_COMM_PORT1);
}

[piripic]

I do not understand why CCS has made so little flexibility in the management of the hardware UART.
My advice is to write yourself your "UART driver management" because ccs does not offer a lot of flexibility in this.

Claudio

[Matro]

#use is a preprocessor directive that hasn't on-the-fly capabilities.
So the result you have is just ... logical.
It's true that there is no built-in function to change parity but that is so simple to do that you can change it very easily : just declare a #byte or #bit variable and assign directly the new settings.

Matro.

[Ttelmah]

Changes to 'stop bits', generally, won't stop characters being echoed. Think of the stop bit like a gap between characters. Extending it on a device 'sending', just leaves a longer gap. Normally a device receiving, won't error on a character arriving with a 'short' stop _unless a second character starts before the extended time_. So it is almost impossible to force an error with incorrect stop bit settings, if you are simply typing characters manually. See also the comments two paragraphs down.

On parity, again the character will echo. All that is done, is that the parity error bit is set in RS232_ERRORS. So unless you test this, the charater will be sent back.

Now on the lack of flexibility in hardware UART handling, it is worth realising that the hardware UART can't actually 'do' much in the way of parity handling. If you want (for instance) to send 8 bit data with even, or odd parity, and send it 'on the fly', then the best way, is to setup the chip to use 9 bit data, and simply generate the parity yourself. This is what the CCS code has to do anyway, since the UART has no parity support built in. This is the reason for the lack of flexibility, since there is no simple 'bit change' type setting to alter the parity, instead different code is needed to calculate the required bit. This is also why the stop bit settings, won't trigger any hardware errors. The UART _only_ supports one stop bit. All the two stop bit setting does, is generate an extra bit time delay between sending characters. The receive settings are not changed at all (since receiving early, won't matter).

The hardware UART on the PIC, only actually supports a very small 'subset' of normal UART settings. Everything else, has to be done in software by cheating, and some of these 'cheats', do not give the level of checking that a normal UART would achieve. I you want more flexibility, then I'm afraid you need to consider adding an external UART.

Best Wishes

[Got PIC]

The only thing I want to support is 8bit, (N)o Parity, (E)ven Parity, (O)dd Parity. Maybe 1 and 2 stop Bits. I'm sure this can be done some how. It's silly that CCS doesn't support this in the "set_uart_speed"

Something like set_uart_speed(baud,parity,stop,[stream])..

[PCM programmer]

Parity generation and checking is done in software by CCS library code.
That's because the PIC doesn't have the capability to do it in hardware.
To do what you want, CCS would have to change the parity code so it
was permanently resident, and also make it configurable. This would
take up additional ROM, and also some RAM.

The basic philosophy of the CCS compiler is to only generate code if it's
needed. This philosophy comes from the early days, in which ROM and
RAM space was very limited. Since then, PICs have gotten larger.
To incorporate your idea, they would have to change their whole
philosophy. This might irritate some other people, who would complain
that there was "dead" code taking up badly needed space in their PIC.

[Got PIC]

PCM programmer,

Thanks for the response.
Your code space concerns could be addressed by supporting a seperate function...maybe something like the "set_uart_speed()" function.
set_uart_parity(int8 parity, int8 stopbits).

If a user doesn't want to use it, then they can exclude the function from code.

I think if you ask other CCS users, the vote would be over-whelming, to add such support.

[Ttelmah]

Read what I have posted.
Your existing code, _is_ working. You need to check RS232_ERRORS, before you will see any error as a result of parity changes. Unless you check this, and don't echo the character if there is an error, the character _will_echo.
The ability is already there (as far as it can be done within the limitations of the hardware).

Best Wishes

[Got PIC]

Ttelmah,

What I'm I checking "RS232_ERRORS" for? And what do I do on error?