Crystals/Resonators

[YAN-1]

Hello everyone. I am building a controller board for a car project. The board invloves 7 16F877A PICs. The first prototype involved several boards, one for each system. The PICs commuicate through I2C and the boards were connected through wires. There were problems with that design, however, as the I2C loop got stuck sometimes and I felt that there were many problems resulting from the wires and the vibration of the car, which I think affect the crystals. Is it right that car vibrations could have caused the crystals to mal-function? In an attempt to make things better, the new PCB I'm doing has all PICs on one board to avoid using wires and the I2C master and slaves are close together. I was wondering if it is also better to replace the crystals I'm using with ceramic resonators. I am using 20MHz crystals now but the PIC datasheet says that the maximum ceramic resonator frequency is 16MHz. If I go with the resonators, I will have to change my delay functions and other things, right? Your comments and advice are much appreciated. Thanks a lot.

Nichola V Abdo

 

[picbits]

I'd personally use a single canned oscillator to drive all Pics simultaneously rather than one per PIC. You can pick up a 20Mhz 5v oscillator for a couple of £ or $ - they have an output which can drive many inputs.

 

[Kyle-s4h]

I'm no expert, but I'd have to say "no", vibrations of an automobile are not going to cause problems. I just opened up a couple of pics of boards I have in my truck -- crystals can be clearly seen in at least 4 of my pics.

I wonder if you've tried your setup with the "new design" -- with all PICs on the same board. I have been reading up on making a "modular" type system and, from what I have read, I2C is not the protocol of choice for such a task. It doesn't like communications that have to travel over a few inches of wire (everything I seem to read says to keep the wires under 6 inches, and even then it may be sporatic).

I can't tell you what to go to as I am still researching that for myself, but IMHO I would look at changing the protocol.

 

[Nigel Goodwin]

I agree with Kyle-s4h, there's no problem with using crystals in a car, your car stereo probably have two or three of them - and the EMU (Engine Management Unit) will have at least one, plus others in the rest of the cars electronics.

I also agree that I2C is a REALLY bad idea, it's not a very good protocol, unless you're using I2C IC's (usually on the same board) which is what it's intended for. A simple RS232 system would be simpler, faster and easier (and more reliable) - or you could use protocols specifically designed for cars, isn't that the CAN bus? - or have I got the worng one?.

As with anything, a LOT really depends on what you're doing, seven 16F877's is a hell of a lot of processing power and I/O - NASA put men on the moon with a fraction of that power!.

 

[3v0]

You may want to go with a RS485 setup for two reasons. First it uses differential* lines so it is can stand more noise then non-differential methods. Second it is a multi drop system so you can put all you devices on one bus.**

The down side is that you need more complex protocol (IE CAN bus) to communicate.

Use the newer RS485 drivers that have ESD and over voltage protection built in.

* A differential driver uses 2 lines to send a signal. When one line is driven high the other is driven low. The receiver looks at the difference between the voltages on the two lines. This is much more robust then RS232 where only one line is used.
** If you do not want to use a multi-drop system you can go with RS422 which uses the same drivers as RS485 but is point to point like RS232 and does not require a fancy protocol.

 

[YAN-1]

Thank you for your replies. I realize 7 PICs is a lot but this is what my system requires so please listen. Here's the situation: There is a Master PIC. It communicates with a computer through the RS232 port to receive all orders for the sub-systems. It also returns feedback information to the computer from the sub-systems. Now there are 3 I2C slave PICs connected to this Master: the speed control PIC, the Orientation PIC, and the steering control PIC. The speed control slave PIC receives the desired speed of the car and sends orders to 2 different PICs; each controlling the motor pressing each pedal of the car. The Orientation PIC communicates with an electronic compass through the RS232 protocol, calculates the heading and distance travelled by the car, and sends it back to the I2C master upon request. The last slave, the steering control slave, receives the desired steering from the I2C master and controls the h-bridge driving the steering motor while getting feedback information through A-to-D from a potentiometer at RA0. Now that makes 6 PICs. The seventh is one that continuously calculates the speed of the car by counting the pulses of an optical encoder attached to the car's wheel. It then provides speed and relative displacement information to the speed control and orientation slaves in a parallel data manner.

Now each system has to be doing its job and calculations at all times and this is why the I2C is implemented in interrupt mode in the 3 slaves. I don't think that I can reduce the number of PICs used. Even the pedal controllers (having nothing to do with the I2C bus) have to be devoted for the sequence of the (stepper) motors.

Now there are 3 slaves and one master involved in the I2C on the new PCB. The largest distance between any slave and the master in terms of track length is about 30 cm (total length with bends). The other 2 slaves are much closer to the master, and the complete PCB is a bit less than an A4 sheet in size. Now I can redraw a huge part of the PCB to make that slave closer to the master. These distances are MUCH better than the way the boards used to be. Each slave was connected through wires (around 40 cm in length) to the bus. Now it's just tracks and the SDA and SCL lines are pulled high through 2K resistors.

The reason I chose the I2C is that it was perfect for the arrangement. Each slave has to be dedicated to a certain task for real-time control, and each one provides feedback to the master upon request. With this new PCB, I have also introduced proper opto-isolation between the motor-drive PICs and the high-current parts to avoid VCC spikes that can affect the I2C. If you say the crystals aren't an issue, don't you think this new design will be better than the first one? The project is approaching the deadline and it really wouldn't be easy to change the whole thing. Sorry for the long reply. Your assistance is always appreciated.

Nichola V Abdo

 

[donniedj]

PIC datasheet says that the maximum ceramic resonator frequency is 16MHz...

16F9XX are supported for 20MHZ ceramic resonators.
Can you make use of the 16F9XX series? 16F917 is equivalent to F877. I do not use F877 purely for price reasons because F9XX is 1/2 the cost of F8XX.