RS232 BAUD Rate Problem

[BigMunki]

Hi there


I have started a project with a 16F877a using the hardware UART port (and later the software one too)

Unfortunately the component i am interfacing it with requires the handshake to occur at 9200baud, but after this the speed must be increased as fast as the system can maintain.

i cant find a macro in Flowcode V4 which will allow me to change the baud rate on the fly,is there any way to use a C module or custom code to do this?

Many Thanks

[BigMunki]

I have had a bit of a look into this, still non-the-wiser..

From a couple of other threads ive read, you can edit the component to manually specify the delay time (which calculates the rate)..

Is there any way to use a C block to set it to 9200bps at the start of the program and then another C block to set it to 38400bps after ive sent the "handshake, and change baud" commands to the device...?

Any help with this would be great- im very stuck at the moment (otherwise i would just muddle through it myself), im using the UVGA II graphics engine (SGC), at 9200 you can clearly make it out regenerating the screen, at a higher data rate you wouldnt..

For further info, im using 2 UVGA II modules, one on either software serial port...

Thank You

[Sean]

The register values for the hardware uart Baud rate are calculated by the RS232 component and defined in the C code (9600 Baud):

#define RS232_2098342_TXSTA_VAL 4
#define RS232_2098342_SPBRG_VAL 127

Note:
RS232_2098342_ is a unique component ID that changes with each compilation.

The values are loaded into the appropriate registers at the start of the C main() function:

txsta = RS232_2098342_TXSTA_VAL;
spbrg = RS232_2098342_SPBRG_VAL;

These two lines of code can be used in C code blocks, with appropriate constant values, to change the Baud rate of the UART anywhere in a Flowcode program - Example for 38400 Baud:

txsta = 4;
spbrg = 31;

I used a trial compilation with the RS232 component Baud rate set to 38400 to allow the component to calculate these values, and read them from the C code.



Software mode is a little more difficult to modify.

Bit timing is carried out by the macro RS232_Delay() - which can be viewed, and edited, via the Custom Code feature.

The delay variable is initialised to a defined value, calculated by the component for the selected Baud rate. This could be changed to a Flowcode variable that could be controlled by the program:

The line:

unsigned short delay = %m_SW_BAUD;

could be changed to:

unsigned short delay = (unsigned short)FCV_SW_BITTIME;

The Flowcode program would need to contain a global byte or integer variable called SW_BITTIME that could be set to the appropriate bit time period, in micro-seconds, on-the-fly, from anywhere within the program (104 for 9600; 26 for 38400).

Note:
The values 104 and 26 are the ideal values for the two Baude rates. These values might need to be reduced slightly to compensate for the function call/return overhead (eg. 100 and 22).

[BigMunki]

Sean


Thanks so much for getting back to me so quickly!!

I decided to use both outputs as software, just to keep both methods similar.

To test it I ran the same program ive been using to build a simple image again. If i set the delay code as you stated, with the variable declared. I set a calculation block with SW_BITTIME = 104. Unfortunately it wouldnt work.. If i restored the code to normal it worked as before.

Even trying with different values between 100 - 104 it was the same result, no activity whatsoever on the unit. Unfortunately the usb-ttl converter is broken so i cant actually examine what is happening on the serial port yet..

Is there something i am not doing properly?? I actually did notice where you said the original line should read "unsigned short delay..." it actually read "unsigned int delay..." i tried both wordings with no luck.

When you said global variable, i assume that is the section accessed through "EDIT > Variables"


Thanks again and im sorry for being a pain!

[BigMunki]

Oh- update


I set the code back to the function which worked... Except i told it to make the global variable = the built in calculaton.

This printed the calculated delay for 9200 on the screen. It came to 37..

When i used your code, i set the value to 37 instead of 104 and it works perfectly. Unfortunately i cant do the same to calculate the value for any higher speeds..

When you said 104, was that a mistake, or is it a quirk of my setup..? Is it possible for you to give me a calculated delay for 38000 and 115200??

Thanks again!

[medelec35]

Hi BigMunki,
To calculate delay time is just 1/baud rate.

E.g for 9600 delay = 1/9600 = 104us
for 38000 = 1/38000 = 26uS
for 115200 = 9uS (I would be surprised if sw RS232 will work anywhere near this value)

With software delays, if running interrupts, that tends to add more of a delay, so a lower value will be required.

Regards

Martin

[BigMunki]

Martin, Sean,

Thanks very much for all your help, its sorted..


I didnt realise that the baud rate was actually the period of the frequency..

Knowing that the period calculated was 37 to compensate for my 75hz interrupt, i worked out that the highest frequency i could get was 58k with a register value of 5 (with error %)

This works perfectly.. But it looks like this is the limiting factor of the software serial port.. But this is fine for one of my two graphics outputs..

Can anyone tell me, if this is causing such a problem (that the interrupt is causing the calculated value to be reduced), will running a faster pic such as an 18F at 40mhz (10x 4pll) reduce the effect of the interrupt??

Many Thanks again!

[BigMunki]

Actually sorry, just one more question..


If;
txsta = 4;
spbrg = 31;

is true for 38k

Could you please give me the values for 115.2k??

Thanks again!

[medelec35]

Value of SPBRG_VAL = ((fosc/baud)-16)/16
so for 115.2k and assuming fosc is 19.66MHz
then
SPBRG_VAL=10 (act val =9.66 recurring)

I believe you keep the TXSTA_VAL the same


Martin