Osctune

[circuitpro]

I got a little rushed on this project, and didn't really consider some of the issues. I needed the space and ASSumed that the internal oscillator would be good enough. I dedicated the only hardware uart to a 9600 baud input because I need to use a DT-interrupt to receive the input character-by-character. Now I'm stuck trying to use DEBUG for a port that really needs to be faster than 9600. (Hence my earlier post inquiring as to how fast I could count on DEBUG to work). I should have either used a PIC with 2 uarts or gone ahead and plunked an oscillator down on the board. I MAY be able to use the prototypes using the internal oscillator, we'll know in a few days.

[Charles Linquis]

Don't be discouraged. I'm using an 18F8723 connected to any number of 18F2221s. The 2221's are remote sensors (temperature, humidity) and are very small. They couldn't generate any heat otherwise they would screw up the readings, so I run them on their internal oscillators at 4MHz to keep the power low. The sensors use the internal EUSART for receive, but have to shut the EUSART off to transmit, since I needed an open-collector transmitter, and the hardware (without an outboard FET, at least) is incapable of running open-collector. In order to meet my timing criteria, I needed to run 19.2Kbaud (for system timing reasons). Serout2 can't run 19.2 at 4Mhz, but DEBUGOUT does. The problem is - DEBUGOUT doesn't have an open-collector option, so I modified PBPPIC18.LIB to give me a debugout open-collector option. That works.

The sensors have a HSERIN interrupt running. When a character comes in, and there is an address match, the DEBUGOUT is invoked (it is also inside the ISR) and the response is sent. When not in the ISR, the PIC is continuously polling its temperature and humidity sensors.

The whole thing works very well, and has been tried with over 150' of cabling and 8 sensors.

[Charles Linquis]

Update:

I found a spool with 500' of Belden 8444 (unshielded, not twisted, 22Ga 4 conductor). I put a sensor at one end and hooked it to my PIC test board. It didn't work.

I lowered the Baud rate to 9600. It still didn't work. I lowered the pull-ups from 2.2K to 820 ohms. It worked perfectly! A scope showed the signals looked more than acceptable. This is driving directly from PIC pins.

[circuitpro]

Wow. Thats open-collector TTL, right? If you really needed more distance, you might try RS485. You can turn each driver off at the sensor when not transmitting, it's a great long-distance party line, and it likes 100-120 ohm hose.

[Charles Linquis]

The sensor is capable of RS-485, both half and full-duplex, and I have used that before. The sensor board (0.25" wide X 1.9" long) has stuffing options that allow all sorts of protocols - I2C,RS232,RS-485.

I have 8 or 10 different "Main" (or controller boards) already designed, any one of which that could control the sensor array. The particular feature set the customer wants, (SSH, SNMP, telnet, Real-Time Clock, Large event log) is on a board that doesn' t have an RS-485 chip. I don't want to design a new add on board at this time, so I'm going with the single-ended stuff. The customer will be using 30 sensors on 400' (total) of 4-wire cable. I think it will work!

[retepsnikrep]

18F2620 hserout baud rates off consistently.

I'm using hserout to send data to a PC running the old plx-daq excel data acquisition macro/control.
It's worked in the past but i haven't used it for a long time.

I have cranked up my pic speed to 32mhz using the PLL etc and that's confirmed by the simple flashing 1hz led trick.

I set the ESUART with data from PicMulticalc using 32mhz as osc speed.

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 20h ' Enable transmit, BRGH = 0
DEFINE HSER_CLROERR 1 ' Clear overflow automatically
DEFINE HSER_SPBRG 51 ' 38400 Baud @ 32MHz, 0.16%
SPBRGH = 0
BAUDCON.3 = 1 ' Enable 16 bit baudrate generator

The pic is transmitting data correctly but when checked with my logic probe I can see the baud rate is off.

At 38400 it is actually 40000
At 19200 it is 20000
At 9600 it is 10000

Seems very consistent and perhaps the windows serial port can't tolerate this error?

Do you thing this is a ESUART register setting problem or a wayward oscillator that needs OSCTUNE tweaking?

[HenrikOlsson]

I have a bunch of boards, all on a RS485 bus, all running the same code, and ONE board had to have its baudrate tweaked because it was off (I don't remember if I tweaked OSCTUNE or BAUDCON) so I'm leaning towards the oscillator not being quite where it should be.

Do you have another PIC of the same type to try with?

To verify if it's the oscillator, try generating a pulse with a known width and measure it.

/Henrik.