RS232 I cant receive at 230400 bauds

[dax]

Hi, Im working in a proyect where i have to comunicate my PIC 18F4620 with a Bluetooth module working at 230400 bauds.

I´ve choosen a 3.686400 MHz ceramic resonator for the PIC, in order to reach that speed and to prevent power comsumption.

Comunication works fine at 57600. If higher the PIC sends ok, but it doesnt receives anything.

my settings are:


#use delay(clock=3686400)


#use rs232(STREAM=BT_id, baud=230400,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)

any help its welcome!

thanks!
_________________
dax

[Ttelmah]

I suspect your problem is hardware, not software, or software at a different level. You don't say what compiler version. However the current releases correctly set up the ports for this rate. First comment then is how you are checking that nothing is received?. If (for instance), you are running an interrupt based serial receive, and writing data to an array, then I'm afraid to say, you are probably just running out of processor time. There are only 40 instruction times between successive characters at this rate, and an interrupt takes typically about 25 instruction times to arrive at the handler, about 18 to return, plus the time in the handler, so the chip just won't be able to handle the data at this rate, and clock speed. Though it will cost a small amount in power, using the H4 fuse, would solve this. Even a direct polling loop for the data, will have trouble if using an array to store the data. A typical array access involves something like 20 instructions, and with a loop counter, and retrieving the data itself, times are going to get tight.
Add the 'ERRORS' statement to the RS232 definition, since this will keep things going, if individual characters are lost (otherwise the UART will hang). Unfortunately this adds a few more instruction times to the data fetch...
The other possibility, is that the device driving the serial input pin, is borderline on reaching the required voltage level. At the higher speed, this is leading to the data just not being seen.
Try with H4. If it starts working, then the problem is just that your code cannot handle the data at this speed, with this clock rate. If it still doesn't work, then the problem is hardware.

Best Wishes

[Paolino]

[Ttelmah]

No. The PLL, should work at 3.6864MHz. However he may need to insert a series resistor to lower the gain of the oscillator. Microchip answered this for me some time ago, when I wanted to run synchronised to a unit that ran at this same rate. The HS oscillator setting increases the gain of the internal oscillator block, and it'll run fine below 4Mhz, but may have so much gain that the waveforms clip, leading to erratic operation, especially if the PLL is used as well.

Best Wishes

[Gerrit]

Hi,

Wouldn't it be a problem with ceramic resonator.

I think that it is not accurate.


Gerrit

[Ttelmah]

A ceramic resonator, should be accurate enough for serial comms. The key is that he says it sends OK. If the resonator was badly off frequency, this wouldn't work either. However, I agree a crystal would be a much safer bet.

Best Wishes

[Gerrit]

Is it not that for receiving the pic samples 3 time's and
the PC samples 16 time's.

So a receive failure is done faster on a pic than on a PC.

I would measure the absolute bit time of the PIC an check if it is within specifications.


Gerrit.

[Barney]

I tried to do serial I/O comms (interrupt & polling) at 115KB using a 16F88 part at 20Mhz and ran out of cpu cycles. Even with H4 the clock rate will be only 14.7 Mhz. The code will need to be very tight, possibly written in assembly instead of C.

[Mark]

[Barney]

Depends on what you are doing with the data and how fast it comes in. During bursts of continual data there is very little time to do anything except store the data for later processing. If you need to turn off interrupts for time critical processing (as in my case), then you have a maximum of 3 character times before the UART buffer has a data overrun.

Given the original parameters of 230KB and 3.684Mhz, the timing works out to be ~40 instructions per character time. The interrupt delay, default CCS interrupt dispatcher, and the user written interrupt handler are going to eat that up real fast. At 20Mhz there are only about 217 instruction times per character. Better but still not a lot.

Anyway, I am always looking for a better way to skin a cat, here is my interrupt routine, efficiency suggestions welcome.