RS232 baud problem with 18F452

[gjm27n]

I'm trying to control a RS232 device with a 18F452 and having issues that seem to be baud rate related. I can communicate fine with other PIC chips but when I hook up to other serial devices, I can't communicate. I connected the PIC to my PC using PuTTY and verified it is garbage.

The PIC chips I can communicate with are PICSTEPs from jrkerr.com (PIC16C73 clocked at 20MHz with a default baud rate of 19,200, 1 start bit, 1 stop bit and no parity)

I have PuTTY set up for 19200, 8, 1, No parity, No flow control. Any thoughts?

Here are the relevant snippets of code

[Ttelmah]

What are you using to generate the actual RS232?.

You do understand that a PIC _does not_ generate 'RS232'?. It generates 'asynchronous TTL serial'. This has to be converted to the RS232 signalling standard using a device like a MAX232. The signal coming from the PIC will be inverted from what a PC expects, and at the wrong voltages.

I suspect this, since (obviously) two PIC's can talk to each other without such conversion, but to talk to a PC, you need the RS232 level converter.

As a further comment, you do realise that on all the ports where you have 'fixed_io' selected, setting the tris, is just a wasted instruction. You have told the compiler to _fix_ the TRIS at the patterns specified in the fixed_io statement, so when you set tris, then perform I/O, what happens is:

1) TRIS is set as you specify
2) TRIS is then set to the fixed value
3) Then the I/O occurs

Very pointless.

Honestly unless you have some specific need, get rid of all the I/O instructions (leave the compiler to default to standard I/O), and get rid of all the tris statements.

[gjm27n]

Thanks, the switch from PIC-PIC to PIC-PC was recent and I didn't realize the signals weren't correct. I must have known this years ago and forgot since I do have a stock of DS275 chips. I'll play with those and see if I can get it working.

I know there is some excess code from previous projects in here that needs to be cleaned up some point. I used an old project as a template. Hadn't gotten around to cleaning it up yet since it doesn't prevent it from working.

Again, thank you very much for the help. I believe this will solve my problem.

[guy]

PIC16C73 !? Is this for real???

[temtronic]

Yes, they are STILL available ! though 30% more than the flash versions !! I looked at the PIC-STEP boards and agree with the mfr....if it ain't broke WHY upgrade? $2 ain't going to damage the 'bottom line'.

What DOES show up in the PIC-STEP PDF is that it's an RS-485 device NOT an RS-232 device. Kinda like speaking French... it depends on whether it's Paris French or Quebec French....NOT quite the same !!

He really needs the PIC to be using proper RS-485 interface chips AND enabling RS-485 control in the software.

Jay

[gjm27n]

When I go PIC to PIC, I am converting to 485 (especially since I am talking with 4 of them), I just didn't want to throw too much information out there and cause confusion. I bought some small boards that convert the serial to RS232 and things seem to be working now although I do occasionally get some flaky results. Cleaning up the code now to (removing fixed_io and tris) to see if that helps. Thanks for all the information, hopefully I can get this finished.

[temtronic]

this line of code...
#use rs232(uart1, baud=19200, xmit=PIN_C6, rcv=PIN_C7, parity=N, bits=8)

ONLY sets the program to run RS-232 NOT RS-485 !

You NEED to add a 'control enable' option otherwise the 'RS-485 bus' an never figure out who is master, who's a slave and 'flakey' results will be the norm.

By not supplying us the 'detail', like the make/model of the serial> RS-232 boards( which will NOT work as RS485 boards BTW), you do make looking into the crystal ball 'fuzzy'.


Jay

[gjm27n]

The 485 was for when I talk to other PICs. I don't have them configured at this time and am only using RS232 to a piece of equipment that talks 232. I am testing using PuTTY and when I make changes that shouldn't seem to affect the serial, it occasionally puts out garbage. Works well most of the time.

I also use the interrupt B ports for reading and processing quadrature inputs and occasionally get garbage there (but was working perfectly a while ago). This new board and code was built to replace an old board I developed 15 years ago and coded in assembly.

I'm using an old version of CCS compiler (pchupd_4_015) with no optimization. Maybe it is time to update. I'll look at the list of compiler fixes since then.

[gjm27n]

In cleaning up the code, I've made progress with the port b interrupt code but am now having different issues with the serial data. It was working well for a while but one of the changes broke it, not sure which one. I send out positioning strings to the equipment I'm talking to every machine cycle and the first 2 characters of each command are always garbage but the remaining characters all look good.

I am still using some fixed_io for ports that are only one direction.
Port A - not currently used but will eventually be analog in
Port B - B0-B3 not used but will eventually be output, B4-B7 always interrupt input for quadrature encoder
Port C - C3, C5 always output, C6, C7 serial out
Port D - bi-directional data
Port E - always output, connected to a 74LS138 for addressing.

In my .h file

[Ttelmah]

Repeat Temtronic's questions.

Then some comments/questions:

#use rs232(uart1, baud=57600, xmit=PIN_C6, rcv=PIN_C7, parity=N, bits=8)

Change to:

#use rs232(uart1, baud=57600, parity=N, bits=8, ERRORS)

If using the 'UARTx syntax, the pins are automatically specified for you. UARTx is equivalent to specifying the pins, and 'FORCE_HW'.

If using the hardware UART, you _must_ always have 'ERRORS', unless you have your own error handling code. Otherwise the UART can become hung.

Unfortunately, a few of the old basic CCS examples omit this, since they pre-date this command being added.

Then you output a byte to port A, therefore setting the whole port to output, yet you comment that you intend to use this for analog inputs....

You do realise that '#PRIORITY' _only_ changes the order that the interrupts are polled in the global handler. Your PIC has no hardware interrupt priorities, and if your code spends any significant time in the handlers for the timers, INT_RB events _will_ be missed.

Now, you don't tell us whether you are now using RS232 or RS485?.

If the former, then it is common to have to wait for perhaps a second after power-on, for the charge pump capacitors on the MAX232 to charge fully. So garbage for a first character(s) is common. If the latter, then 'questions':

Does your bus have _bias_ on it's termination?.
Does it even have termination?.
If you are using a MAX485 or similar, does the PIC have a pull-up resistor on the input from the RO pin?.
How are you handling the timing of the bus turnaround?. You do realise that you have to wait for the PIC's hardware buffer to empty _before_ reversing the bus.

[gjm27n]

Thanks, I thought I had specified it but I don't see it there now. I'm only talking 232 in this project, not 485. Right now I'm using a small converter board (digikey 1286-1032-ND which uses a MAX3232) and I was getting good communication prior to cleaning up and modifying the code. I've got a short cable (6') connected to my PC running PuTTY. I will make the changes you recommend and see if that helps.

Actually, a lot of important info I had typed in seems to be missing, not sure why. Other relevant data is I'm using an older compiler (pchupd_4_015) with no optimization. I will be updating to the current version today in case it had problems. The change notices on the site don't go back that far.

The initialization of port A is from a previous project I used as a template from 10 years ago. Probably still needs a lot of cleanup but other than initializing, not using it.

I'll do some research on ERRORS and implement it.

[gjm27n]

I guess the fix is simple, I switched RS232 level converters and the problem went away. Looks like a hardware issue.