Serial Comms and Crystals

[Scampy]

Hi Guys and Gals

Some years ago, with the help of DT and Henrik I worked on a 4 channel thermostat project which I'm now looking at upgrading to incorporate some new sensors and options. One of the problems that I'm still trying to resolve is the serial communications.

I've used PIC Multi Calc to give me the settings and defines for the serial port settings on both cases. I've also written a PC application in Liberty Basic to read and update the settings, but also tried communications by sending the commands via the terminal in MCS.

OK - I'm using an 18F4580 with an OSC val of 48 in both cases. Inserting a 12Mhz crystal in the development board with the USART settings to

'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 25  ' 115200 Baud @ 48MHz, 0.16%
'SPBRGH = 0
'BAUDCON.3 = 1         ' Enable 16 bit baudrate generator

Compile and load into the PIC and launch the application, which first checks the comm ports available and then scans for a response from the PIC by sending a "C" to the PIC which then responds with "R" and then on confirmation that it found the controller launches the application and sends "R again which instructs the PIC to send the data stream. This works fine when the 12 Mhz crystal is in place. I can also launch the serial monitor in MCS and replicate receiving the data stream.

But as I really wanted to use a 20 Mhz crystal as it make other processes run faster which in a PID thermostat is my preference, I get "no controller found" when the PIC is polled from the application. In the serial monitor it registers connection with the com port (I'm using a USB/ Serial module from Mikroelectronika) but again fails to respond to the manual TX codes. Here's the revised USART settings that the multicalc application gives

DEFINE HSER_RCSTA 90h ' Enable serial port & continuous receive
DEFINE HSER_TXSTA 24h ' Enable transmit, BRGH = 1
DEFINE HSER_SPBRG 25  ' 115200 Baud @ 0.16%
DEFINE HSER_CLROERR 1 ' Clear overflow automatically

RCSTA = $90 ' Enable serial port & continuous receive
TXSTA = $24 ' Enable transmit, BRGH = 1
SPBRG = 25  ' 115200 Baud @ 0.16%

Now I'm assuming that the reason it works with the 12 Mhz xtal is that the 48 OSC value is divisible by 4 to equal the crystal value. Where as using the 20 Mhz xtal, the OSC value is not directly divisible. So I changed the OSC value to 40, recalculated the USART settings for a 40 OSC and tried that, but to no avail.

Any suggestions on how to get this working with a 20 Mhz xtal

[HenrikOlsson]

Hi,
The fact that you're using a 12MHz x-tal and DEFINE OSC 48 tells me that you're using the PLL in the chip to increase the frequency from 12 to 48MHz. This by itself seems a bit strange since the maximum operating frequency of the 18F4580 is 40MHz so if you really ARE running at 48MHz you're operating the chip outside of it specifications.

Dropping in a 20MHz x-tal instead of the 12MHz means the PIC is trying to run at 80MHz - twice as fast as it's maximum rated speed.

If it really does use a 12MHz x-tal with the PLL enabled - thus running at 48MHz - and it's doing it reliably then that is as fast as you're going to get.

If it's actually running at 12MHz then what you want is to drop in a 10MHz x-tal and enable the PLL. Then you DEFINE OSC 40.

Please remember that DEFINE OSC never ever changes the speed which the PIC runs at. It only informs the compiler what speed YOU intend to run the PIC at.

/Henrik.

[Scampy]

Cheers Henrik,

10Mhz xtal, OSC set to 40 with HS PPL in the config and it works fine. I thought I was possibly on the right track, but didn't realise that I was in effect overclocking the PIC using the 12 and 20 Mhz crystals.

Now to look for a cheap I2C humidity sensor. The DTH11 that I was playing with uses pause statements which slow the rest of the code down.

[Demon]

...

Now to look for a cheap I2C humidity sensor. The DTH11 that I was playing with uses pause statements which slow the rest of the code down.

Don't you mean "you" use PAUSE in your code? (I'm not familiar with that sensor)

You could use DT INT instead to generate an interval.

Robert

[Scampy]

The code does include DT's INT file.

I've found an indepth data sheet which states that each two way communication process should take 4ms, so why it seems that the code runs slow might of been down to the use of the wrong crystals ??

Basically connection is via a single pin. This pin is kept high by pull up resistor. To get data, the PIC needs to make the pin go low for a minimum of 18ms then hight again and waits 20-40us for the response. The sensor then sends a response by taking the pin low for 80us and then back up high for a further 80us and then sends the data, which is a 40bit stream of high pulses with a duration of 20-28us to represent a 0 or 70us for a 1. Each pulse is preceded by a low pulse of 50us, with a final 50us low at the end of the data stream.

I've seen examples using pulseIN command, with pause xxUS to trick the sensor into sending data, but don't know if interrupts could be used here ?

here's the data sheet http://www.micropik.com/PDF/dht11.pdf

[richard]

dht11/dht22
http://www.picbasic.co.uk/forum/showthread.php?t=19800

[richard]

malcom
before you go too far down this track you might like to research some other devices or at least have a way to calibrate these things. I now have three sensors in the same room 2x dht22, 1 dht11. the dht 11 reads 60% the dht22's read 46.3 and 49.5 right now @19.6C (tis as close as they seem to get) . real hum is anyone's guess , the readings tend to converge @ around 20C but diverge wildly below 10C and above 30C. there is some info on the web about bedding these sensors in or "reforming them" . not sure how fussy reptiles are , I do know how fussy the cold blooded half of the human race is

[Scampy]

Richard,

Thanks for the suggestion. I've been having some issues and have to agree that these sensors are not really suitable where precision is required. I added tabsofts suggestion, and I got as many short errors as I did Longs... I've also got several not connected errors. I think I'll look at something that uses a standard communications interface such as those suggested by Tim.

The humidity requirements of the snakes I keep are not that critical, but this probe is intended to be used to monitor the humidity in the container containing eggs in an incubator, where the humidity needs to be kept at a set range so they don't dry out.

[Charlie]

According to the datasheets, for the DHT22:
Operating range humidity 0-100%RH;
Accuracy humidity +-2%RH(Max +-5%RH);
Resolution or sensitivity humidity 0.1%RH;
Repeatability humidity +-1%RH;
Humidity hysteresis +-0.3%RH
Long-term Stability +-0.5%RH/year
DHT22 should be fine for your application.

[AvionicsMaster1]

Just for my own edification what temp and humidity are you looking to maintain? Google implied both need to be tailored to type of snake egg.

[Scampy]

Just for my own edification what temp and humidity are you looking to maintain? Google implied both need to be tailored to type of snake egg.

Royal Python eggs are typically incubated at 32c and 90% humidity