Controller Advice
mctrivia
Posts: 3,772
I have started a project that requires a lot of nodes talking to a few parallax propellers. Do to cost reasons I can't use propellers for everything so I was trying to find a cheaper controller for the nodes.
I was thinking of using the: PIC16F616T-I/SL
The chip is only $0.9159 each which would be a great price if it will do what I need.
I want to connect a SHT10, a 0 to 5V analog input, 2 digital inputs,1 digital output, and some kind of serial communication back to a prop(1 to 3 wire less wires is better as it means more sensors per prop)
I am pretty sure this chip can handle all the necessary io but I have never worked with pic chips before and was wondering if anyone can
1) confirm I am right about the io
2) suggest safe communication with prop since prop is 3.3V
3) suggest good prototype resources or any pcb quirks pics may have.
Unless I am bit banging communication I should not need anything fast as the chip is mostly just taking the inputs and sending any change of states over the serial link to the prop which will be doing the real work. Wish there was a small chip like this in the prop family so I could just stick with props but the eeprom alone is getting near the same cost as these chips.
I was thinking of using the: PIC16F616T-I/SL
The chip is only $0.9159 each which would be a great price if it will do what I need.
I want to connect a SHT10, a 0 to 5V analog input, 2 digital inputs,1 digital output, and some kind of serial communication back to a prop(1 to 3 wire less wires is better as it means more sensors per prop)
I am pretty sure this chip can handle all the necessary io but I have never worked with pic chips before and was wondering if anyone can
1) confirm I am right about the io
2) suggest safe communication with prop since prop is 3.3V
3) suggest good prototype resources or any pcb quirks pics may have.
Unless I am bit banging communication I should not need anything fast as the chip is mostly just taking the inputs and sending any change of states over the serial link to the prop which will be doing the real work. Wish there was a small chip like this in the prop family so I could just stick with props but the eeprom alone is getting near the same cost as these chips.
Comments
I want to connect a*SHT10, .....
This requires a clock and data line. To maximize the number of sensors per prop this should go in to the PIC and out on the serial line to the prop.
a 0 to 5V analog input,....
Requires one of the 8 available 10 bit ADC inputs.
2 digital inputs,.......
Requires 2 of the 11 available general purpose digital I/O lines on the PIC.
1 digital output, .....
Requires 1 of the 11 available general purpose digital I/O lines on the PIC.
and some kind of serial communication back to a prop (1 to 3 wire less wires is better as it means more sensors per prop).
Requires 1 or 2 of the 11 available general purpose digital I/O lines on the PIC and 1 or 2 on the Prop **. This will require bit banging serial data on the PIC and one or more copies of the quad serial driver on the prop. Depends on how many sensors you want to connect and if it requires full or half duplex comms. You could have as many as 24 PIC's connected to a Prop if the prop I/O pins are not needed for other things. Many more if you connect them as a serial bus.
Confirm I am right about the io.
So far 7 pins are required for half duplex comms, 8 for full duplex on the PIC , this requires 1 pin for half duplex and 2 pins for full duplex for each PIC that is connected to the prop.
Suggest safe communication with prop since prop is 3.3V
A 3.3K resistor for input pins and 120 ohms on outputs would work for full duplex, a 3.3K resistor and a small signal transistor, level translator or one of several other options for half duplex.
Suggest good prototype resources or any pcb quirks pics may have.
Follow standard layout practices for the digital portions of the circuit, and good analog layout practices for the ADC portion. With a 10 bit ADC this is not too critical.
'Can't answer your question, but 'just wanted to say "welcome back." 'Looks like you've moved since your last post, too: Calgary to Edmonton. (You must still enjoy bitter winters. )
-Phil
Thanks. Missed the 2k memmory. Should be fine but I should probably get a copy of the user manual and try to write the code first before I buy anything.
I was thinking 2 wire full duplex would be best because I need signal data to be seemingly instantaneous. However to human perception half duplex would be seemingly instantanious also and would require only 1 wire if I have enough room in the pic to handle. will have to consider that.
phiPi: Nice to be back. have not had much time for electronics since propmodule went under/daughter was born. moved to winnipeg, never lived in edmonton not sure why it would say that. Still usually bitter cold winters. I love my Wife not the weather Not sure how much time I will have to spend on electronics but hopefully enough to finish this project on time.
-Phil
Since anything that occurs in 1/10th of a second or less is pretty much instantaneous to human perception lets use that as the time constraint for sending/receiving the data.
The other consideration is the amount of data to be sent.
The SH10 uses an adc with a maximum resolution of 14 bits so a total of 4 bytes would be required, 2 each for temp. & humidity.
The PIC adc has a resolution of 10 bits, requiring 2 bytes to send, one of which will have 6 unused bits.
The data from the 2 digital inputs could be placed in either the 2 unused bits of the SH10 data, the 6 unused bits of the PIC adc data, or in a separate byte.
Finally, the Prop may need to send a byte to the PIC for the state of it's output pin and/or to command the PIC to send data to the Prop.
In total a minimum of 7 and a maximum of 8 bytes per transaction. Adding 1 start bit and 1 stop bit per byte that would be a total of 70 bits min, 80 bits max. To do so in 0.1 seconds would require 700 bits/sec min, 800 bits/sec max.
So far the only problem I can see is fitting all the software in 2K, and if you do only the bare minimum needed to acquire the data and send it to the prop for processing even that should not be too difficult.
I like the use of a PIC as a smart AtoD or other things such as a motor controller.
Yes they are cheap.
For the lowest cost one would like to run on the internal RC oscillator.
However, this oscillator is not very accurate, at +-8%, which is problematic when communicating using RS-232. Yes, it may usually work but the 8% thing doesn't guarantee it will work.
I once made a variation to RS-232, "PWM-232", to allow 2 of the 8 pin PICs to communicate. Basically this sent the bits as a PWM, Pulse Width Modulated, bit. Each bit had a width of about 1/3 or 2/3 bit time including the start bit. The stop bit is constantly low.
Each bit started with a falling edge. The rising edge risies early for a zero and later for a one. The required timing tolerance is much less stringent since each bit is self clocked with the bit read 1/2 bit time later.
This can tolerate a timing error of up to about +-33% or more. (0.5 +-0.166 bit times)
Conventional RS-232 is clocked off the start bit and the rest are just timed.
This can only tolerate a timing error of about +-6%.(8.5 +-0.5 bit times)
Better yet, bidirectional data could be done with a single pin on each end.
To be fair, the SH10 is not I2C so a special serial driver in the Prop would be required.
There are clear advantages to PWM-232 especially when timing tolerance is not very accurate.
Duane J
For the SH10, that data would be received by the PIC and forwarded to the prop over the same single wire as the rest of the data. The aim is to allow a prop to connect to as many PIC's (and their attached sensors) as possible.
BTW, the serial is just the "Physical Layer". In this case direct wire.
Conventional RS-232 doesn't allow multiple devices on a single line.
I propose the PWM-232 operate in open drain with a pullup resister mode similar to that used by I2C.
This would allow many devices on the line.
The "Link Layer" is how the bytes are sent.
The "Presentation Layer" would allow the master to send address and commands to the many PIC slaves on the line. And the other overhead things described by mctrivia.
Duane J