Searching \ for '[PIC] Architecture suggestion' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Architecture suggestion'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Architecture suggestion'
2005\02\18@154814 by Padu

face picon face
Hi folks, I'm about to start on my thesis project and it will involve lot's of PIC action. The project is a robotic autonomous rover, that will input data from sensors (GPS, gyro, accelerometer, compass, CCD camera), send it to a host computer through a wireless link that will process all the information in real time and then send kinematics commands back to the rover (which is controlling 2 servos).

Let me first expose what I thought as an architecture, then I ask you for suggestions and if my idea is something feasible to implement using PICs.

1. Sensors (PICSensor) - Each sensor will have one PIC attached to it that will be responsible for sampling the sensor at pre-determined intervals and encode it into a proprietary binary protocol. When the encoded message is ready to be sent, this PIC will drive one port high (I'll explain why in a few secs)
2. Message Manager PIC (MMP) - Is a PIC MCU that is responsible for reading messages from different PICSensors (a PIC that is responsible for a sensor) and then sending it through RS232 to the wireless modem. Each PICSensor will be connected to one IO pin in the MMP. Internally, the MMP will cycle through a set of IO pins and when it finds one that is high, then it commands a MUX to point to the corresponding PICSensor and starts a USART communication in order to retrieve the message that is awaiting to be sent. After the message is received by the MMP, it sends another message (ACK) signaling that the message was received successfully. The MMP starts a USART communication with the wireless modem and sends that message. This cycle repeats for every PICSensor in the system.


I thought about this architecture for the following reasons:
-I have some experience with USART, while none experience with other methods such as CAN, SPI, I2C, etc.
-For the MMP I only need two USART ports, and one in each PICSensor
-While I'll probably have one baud rate for everybody, the architecture allows that each PICSensor communicates at one specific speed

What do you guys think? Is there another way to do that? How this problem is usually solved in more traditional designs?


Thanks

Padu

2005\02\18@155844 by Herbert Graf

flavicon
face
On Fri, 2005-02-18 at 12:48 -0800, Padu wrote:
> Hi folks, I'm about to start on my thesis project and it will involve lot's of PIC action. The project is a robotic autonomous rover, that will input data from sensors (GPS, gyro, accelerometer, compass, CCD camera), send it to a host computer through a wireless link that will process all the information in real time and then send kinematics commands back to the rover (which is controlling 2 servos).
>
> Let me first expose what I thought as an architecture, then I ask you for suggestions and if my idea is something feasible to implement using PICs.
>
> 1. Sensors (PICSensor) - Each sensor will have one PIC attached to it that will be responsible for sampling the sensor at pre-determined intervals and encode it into a proprietary binary protocol. When the encoded message is ready to be sent, this PIC will drive one port high (I'll explain why in a few secs)
> 2. Message Manager PIC (MMP) - Is a PIC MCU that is responsible for reading messages from different PICSensors (a PIC that is responsible for a sensor) and then sending it through RS232 to the wireless modem. Each PICSensor will be connected to one IO pin in the MMP. Internally, the MMP will cycle through a set of IO pins and when it finds one that is high, then it commands a MUX to point to the corresponding PICSensor and starts a USART communication in order to retrieve the message that is awaiting to be sent. After the message is received by the MMP, it sends another message (ACK) signaling that the message was received successfully. The MMP starts a USART communication with the wireless modem and sends that message. This cycle repeats for every PICSensor in the system.
>
>
> I thought about this architecture for the following reasons:
> -I have some experience with USART, while none experience with other methods such as CAN, SPI, I2C, etc.
> -For the MMP I only need two USART ports, and one in each PICSensor
> -While I'll probably have one baud rate for everybody, the architecture allows that each PICSensor communicates at one specific speed
>
> What do you guys think? Is there another way to do that? How this problem is usually solved in more traditional designs?

Is there another way to do it? Well, that's a dangerous question which
almost always has an answer of "yes".

Now, is there a BETTER way to do it? That depends more on you.

Personally I like the idea of multiple PICs, it allows for alot of
flexibility.

However, one area I'd change is the communication between PICs. I would
personally use I2C. Why? I2C can be used in a single master multiple
slave structure, which is exactly what you're looking for. It's
bidirectional (only 2 wires which can be shared with all devices). It
removes the need for the MUX and allows you to daisy chain sensors (if
you want). I2C also allows you to increase the number of sensors without
hardware mods (just add another device to the bus, the rest is
firmware).

CAN is also a very good option (many cars these days have a CAN bus as
the main com platform between modules). I have no experience with CAN,
so that's a minus for me. If you're new to both it might offer some
benefits I'm not aware of. One problem is CAN is FAR less common as a
peripheral on PICs then I2C is.

Aside from that I think you're on the right track. TTYL


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\02\18@161056 by Jan-Erik Soderholm

face picon face
Hi.
Just a minor point...

Padu wrote :

> -I have some experience with USART, while none experience
> with other methods such as CAN, SPI, I2C, etc.

If you're happy wih the limited (as compared with the other) speed
of the USART, I'd guess that it will be OK.

> -For the MMP I only need two USART ports,...

Why two ?
Will the MMP talk both the the wireless modem *and* one of
the sensors at the same time ? If not, I'd guess that the
modem could be run thought them same mux as the sensors.
So the MMP might be run using only one USART.

/Jan-Erik.



2005\02\18@162709 by Vic Fraenckel

flavicon
face
Padu,

Interesting because it is the same general approach to my project. I only
have two sensors, a ADXL being used as a tilt sensor and a CMP03 digital
compass. I have both sensors attached to a "Sensor Board" driven by a
16F876. The ADXL is attached to the CCP ports (one for each axis) and the
compass attached via I2C. The sensor board is attached via the USART/RS232
setup to my message manager which in my case is a JKMicro Flashlite 186. The
Flashlite requests information from the sensor board every 15 seconds then
handles the response from the sensor board.  I think this is a good
architecture. Let us know how it works out,

Vic Fraenckel
________________________________________________________

Victor Fraenckel - The Windman
victorf ATSIGN windreader DOTcom
KC2GUI

     Home of the WindReader Electronic Theodolite
                              Read the WIND

"Dost thou not know, my son, with how little wisdom the world is governed?"
-Count Oxenstierna (ca 1620) to the young King Gustavus Adolphus

"People sleep peacefully in their beds at night only because rough
men stand ready to do violence on their behalf."
-George Orwell

"When a true genius appears in the world you may know him by this sign: that
all the dunces are in confederacy against him."   -Jonathan Swift



2005\02\18@162943 by Harold Hallikainen

face picon face
I'd be tempted to use CAN. Or use a IEEE485 bus in a master/slave
configuration. It's pretty easy to do with the uart on the pic. Just form
packets with a header including a flag, ToAddress, FromAddress,
PacketType, PacketLength, variable length data, CRC or checksum.

I've also done Aloha networks with open collector opto-couplers where the
PICs are not ground referenced. When the PIC has something to say, it just
sends it thru the opto. The LED of the opto is between Vcc and the UART
output (with a current limit resistor). The phototransistor drives an open
collector bus with a pull-up at the pic that is gathering the info. Here
we're counting on packets being very short compared to the amount of time
available. Further, packets are sent randomly. Now and then you'll get a
collision resulting in an invalid packet. Those get thrown out.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...