uC 'network' reset circuitry

[rockin_rick]

I am creating a general purpose (mainly robot) controller board for my personal use that includes a 'network' interface for connecting multiple copies of this board together along with anything else that I may want to connect to it in the future. I want this to be flexible for future unknown applications. I am trying to determine the reset circuit for the board (and thus network).

My design REQUIREMENTS are:

-One single hardware design
-A single master, one or more slave network arrangement
-PIC uC (most likely 16F877A, but perhaps 18Fxxxx)
-Software is customizable for each board
-Use RA4 for controlling the network reset signal since it is open collector only (in other words - save the more useful I/O for other purposes)
-Config jumpers are fine since it is for personal use, but avoid if possible for convience
-A single header pinout for the master and the slaves
-Each board have a reset button

My PERCEIVED goals are:

-Master is in charge of asserting the network reset
-Network reset is active low (/RESET)
-Slaves can enable or disable the external reset signal
-Master holds all attached devices (that choose to enable the external reset) in reset until master is ready
-The maximum number of these identical boards connected together will not exceed 3 (1 master, 2 slaves)
-Whatever 'other' unknown devices that accept an active low reset signal may be on the reset circuit (max 5-10)
-Allow devices to have different VCC's and still respond to the network reset and not effect other nodes
-Assume that slaves have pullups for their reset circuit

These are PERCEIVED goals since this is what I currently think is best, however, if someone thinks that I should do something differently, I will certainly consider changing.

Attached is my proposal of the circuit (with circuitry unessential to this topic ommited). JP1 will allow the board to be either: the master and assert the /RESET (jumper over 1-2), slave and accept the /RESET (jumper over 2-3), or neither assert or accept the network /RESET (no jumper connected). JP1 pin 2 is the network reset circuit (that is brought out to a header).

My circuit theory:

For the master: On powerup, the master's RA4 will be in a high-Z input state, and that will allow T1 to be biased on and asserting the network reset. All attached devices will be held in reset. Once the master is up and running and ready, it will change RA4 to an output and assert a low thus turning off T1 which allows attached devices to startup. Pushing S1 to reset the master will cause RA4 to go high-Z and cause T1 to turn on and hold attached devices in reset.

For slaves: S1 will reset only that individual node, not any other device on the network. An active low on the network reset line (/RESET) will reset the device and hold it in reset until it goes high.

Will this work? Should I change components or values? I suppose that D2 (5.1V zener diode) is not really necessary since D1 shouldn't allow a higher voltage to pass, huh? I suppose that I'd like to have the ability to connect nodes that have different VCC's.

Should I consider some other arrangement completely? Perhaps having each 'slave' have it's own pulldown transistor? Something else?

I appreciate any advice or critisism.

Thanks,
Rick

 

[dknguyen]

I am designing something like that right now...I don't know what tasks you plan to use it with...but for me it is for robotics and each board is like a "co-processor" that deals with different aspects, like navigation, motion control, osbtacle avoidance.

I was not so concerned with the reset configuration across the boards and the ability for one board to reset the other. The way I thought about it was that slave boards would be coded for specifics tasks so that they start up and would set themselves (and their periphreals devices ie. set servos to center) to a safe steady state and just wait. The master board would then send the slave parameters on how the task needed to be performed (ie. set servo to 90 degrees).

The task would perform the task in one of two ways depending on the nature of the task:

-The slave continues to perform the task based upon the last defined parameters that the master provided for an infinite amount of time pending the update of these task parameters should the master decide it is necessary.

-The slaves performs the task based upon the last defined parameters. However, a periodic watchdog signal would be required from the master to indicate that the master is still functional for the slave to continue operation (much like a watchdog timer watches for crashes).

If something happened to the master and it was no longer able to provide the watchdog signal, the slave reverts to a safe steady-state until further communications from the master (ie. after the master recovers).This would prevent the slave from unsafley continuing a task.

For example, the master relays obstacle avoidance information to a motor controlling slave. If the master crashes and can no longer relay obstacle information to the slave, you obviously want the motor controlling slave to stop the vehicle because it would be travelling blindly. If the master recovers, it will use the scanners to scan for obstacles and then tell the motor controlling slave which direction to make the motors travel in and everything would proceed normally.

THe safe steady state that the slave goes to if something happens to the master may or may not be the same as safe state the slave achieves on startup. THe "crashed master" safe state would work best if it was based on the present state of the slave.

For example, upon start-up the slave opens the robot arm gripper and raises the arm pending further instruction from the master. Upon a master crash, the robotic arm reverts to startup position if it is holding nothing but if it is holding something heavy, it places the item on the ground, if it is holding something light it continues to keep holding it.

The master could also receive periodic polls from the slave to ensure the slave is operating normally. If the slave stopped operating, the master could tell other slaves related to the task to stop as well (ie. if the sensor slave freezes the master tells the motor slave to stop the vehicle).

This provides set-and-forget control between the master and slaves, but would also ensure that tasks requiring periodic master intervention would not be continued blindly if something happened to the master, but leaves open the possibility if it is required. It allows boards to individually reset and recover from crashes without interferring with the operation of functioning boards and allows the boards to power up and reset in any order that they wish. if done properly it could provide seamless operation in the event of a crash.

And the best part is, it's all done in code! And I suppose if you wanted something to rest, you could always send a software command from the master to reset the slave. The watchdog timer should take care of any of the boards in the event of a crash.

 

[rockin_rick]

I am designing something like that right now...I don't know what tasks you plan to use it with...but for me it is for robotics and each board is like a "co-processor" that deals with different aspects, like navigation, motion control, osbtacle avoidance.

I'm trying (perhaps foolishly) to fit everything I think I need into a single board, so that each robot only needs one. I'm trying to anticipate my future needs now and build in enough flexibility for projects I have in mind. However, I realize that the programming can get difficult to impossible for trying to do to much at once, so I'm planning ahead to allow the boards to be networked together like you said - master and co-processor. Or perhaps I'll attempt a more complex project in the future that I don't currently anticipate...

I'm planning on having PCBs made in quantity (OK... hobbiest quantity 10-20), and would like to do it only once. If the board doesn't later meet my needs, I want to be able to stack boards rather than redesign later.

The master could also receive periodic polls from the slave to ensure the slave is operating normally. If the slave stopped operating, the master could tell other slaves related to the task to stop as well (ie. if the sensor slave freezes the master tells the motor slave to stop the vehicle).

This is where my theory for hardware reset comes in. At this point the system is dead, and without a 'hard' network reset, will require user intervention. Since the master realizes that the slave has a problem, and can assert a 'hard' reset to the slave board(s) and have a chance of recovering the system without user intervention. The master itself will not reset, so it can intelligently recover the network (update the servo co-processor, etc.).

A 'soft' reset (a reset command sent across the network) is a good idea, and perhaps useful, but if a slave has stopped operating it cannot respond to a 'soft' reset message from the master.



I agree with all the functionality that you describe, thanks for taking the time to post. The hardware reset is not meant to replace that, but rather add another 'layer of protection'. Also, since I am unsure of future uses, I'd rather add the circuitry and never use it, than not have it and need/want it later. Plus it doesn't cost much, either in terms board space, coding, or money.

Rick

 

[dknguyen]

Reset

A soft reset would be best because it is more flexible and require no extra hardware. If the uC does not have have a software reset (for God knows what reason) you can always attach a digital IO pin to the reset pin and have the uC hold it in the appropriate state (or use pull up/down resistors to have it operating and have the uC pin pull it to the appropriate level to reset).

However, when something malfunctions...YOU DO NOT NEED TO BUILD YOUR OWN HARDWARE RESET...because it's already built in! Most uC have what is called a "watchdog timer". This timer runs independently of the uC and periodically checks a register which the uC must update periodically. If the register is not updated (ie. the uC has crashed) the watchdog timer resets the chip!

This is so that uC systems don't hang and might be able to recover if something isn't quite right with their code and continue operating.

Convenient huh? That's why I don't think you need to automate the manual reset. My board setup depends on this theory- that the crashed board will use the watchdog timer to reset itself.

I am also in your scenario of mass producing a single board and stacking them as needed. You might want to add a few filters onto your ADC pins if to decrease bandwidth (decreases noise at cost of response) if you are planning to do signal processing with your board from external sensors.

 

[Oznog]

I think this is a mistake. There is little reason to have a "network reset" signal because no reliable protocol should require that all the processors reset together.
You need to focus on protocol. I2C is great for bidirectional communication with a single master. Serial, not so good at bidir, good with a single master transmitter. CANBus, good but you need a transceiver chip and an advanced controller. SPI, also fine.

With all these protocols a receiving chip can "wake up" at any point in the data stream and get in sync with the transmitter within a byte or packet or so.

As said, WDT will do a great job of reliability. The only thing WDT can't fix is latchup, but even an external reset won't fix that.

Now just why do you need multiple processors? Just using a pkg with more pins can give you a lot of room for expansion. If you need another PWM channel you can get an external PWM chip.

 

[rockin_rick]

Perhaps the hard reset is unnecessary... I'll just do without and gain another I/O, which would be much more useful (and it's in short supply).

I didn't really plan on it until I did some digging around and ran into the Brainstem controller from Acroname. They decided to have a /RESET signal on their network connector/bus, so I thought why not? I figured that they've got much more experience and done more research than me, so I'd just go with it and perhaps it would prove to be beneficial in the future.

I do plan on using I2C as a network protocol.

Now just why do you need multiple processors? Just using a pkg with more pins can give you a lot of room for expansion. If you need another PWM channel you can get an external PWM chip.

I'm trying (perhaps foolishly) to fit everything I think I need into a single board, so that each robot only needs one. I'm trying to anticipate my future needs now and build in enough flexibility for projects I have in mind. However, I realize that the programming can get difficult to impossible for trying to do to much at once, so I'm planning ahead to allow the boards to be networked together like you said - master and co-processor. Or perhaps I'll attempt a more complex project in the future that I don't currently anticipate...

I'm planning on having PCBs made in quantity (OK... hobbiest quantity 10-20), and would like to do it only once. If the board doesn't later meet my needs, I want to be able to stack boards rather than redesign later.

Rick

Through hole is also a design requirement, and the largest PIC that is available in DIP is 40 pin, which I am using. IOW - my uC pin count is already at max.

Also, I'm plan on genereating all of my own servo pulses with the main uC. (I already have code written and tested.) This eats away at I/O and CPU cycles/performance. I want a single controller that is GP enough to reuse for any robotic project that I may attempt.

Yes, the goal is a single board/uC setup, and I'm trying to design it as such to cover all 'current' anticipated projects. But who knows, perhaps some day I'll attempt a snake robot, and will need lots of servo ports. Then I could just stack a few together (perhaps with one as master and controller, with a few slaves setup as servo controllers). What it all comes down to is not having to redesign hardware with every project that I do. My projects take way too long to complete as I'm a perfectionist, and being able to skip the board design for each would help speed up projects. Up until now, I've always designed a dedicated, specific purpose board to each project (which I enjoy). However, I've got way too many projects in the hopper, and not enough time - it's time to go with a quicker 'design cycle' and get more done, even if that means that the board is not as optimized as possible.

FWIW- this project started out just being a dedicated robot arm controller. I was going to make the board so it was exactly what I needed, with just as many servo ports and inputs as were to be used. It didn't take long for me to realize that it wouldn't take much more to create a GP board and not have to design another for my next project. This could also allow me to purchase a larger quantity of boards from a boardhouse, and thus lower the cost of each.

Thanks for the insight,
Rick

 

[rockin_rick]

You might want to add a few filters onto your ADC pins if to decrease bandwidth (decreases noise at cost of response) if you are planning to do signal processing with your board from external sensors.

I do have 5 I/O that can be used as A/D. Unless more than 3 is needed, I'll assign 2 of them to monitor bat voltages - both main power and servo power. This will be selectable, so that if I need 4 or 5 A/D, I can disable the voltage monitoring, and use those 1 or 2 as GP A/D. I also am allowing the 5 A/D to be able to be used as digital I/O, if necessary.

I am interested in the filter idea, but am inexperienced in analog design. I don't really plan on signal processing (especially with my 16F PIC), but the filter is probably still a good idea. Perhaps a simple RC low-pass filter for each input (such as attached pic)? What would good values for the R and C be? How would this effect digital I/O when the A/D is not being used? It should just slow the digital transitions (softening the edges), and thus limit the switching speed, right? Should I not add the filters since these A/D could also be used as digital I/O? Or should I add them and accept the fact that these can only be used with slower digital signals?

Thanks,
Rick

 

[dknguyen]

Filter

An RC filter is fine to just get rid of high-frequency noise on the ADC line. If you are like me and need to do some complex signal processing on analog signals (like integrating the signal and stuff like that), I went with a Maxim IC filter chip where I can change the cutoff frequency very sharply. I actually need the filter to control the bandwidth of the signal, not just cut off noise.

Do not use an filter on a digital line unless you know exactly what you are doing- it isn't needed and the lowpass characteristics can mess up high data rate digital lines. I am dedicating pins to analog signals and only analog signals on my boards- only those ones will have the filter. It's all up to you how to organize your pins...

as for the low pass filter, Time Constant = Resistance * Capacitance where T is the lowest period of the signal that will be filter. So, 1/T will give you the cutoff frequency where the filtering will essentially start. Its up to you to decide the frequency. Too low a frequency will require components that are too large.

 

[Oznog]

Rin should not be over 2.5K ohms. That is the R plus the resistance of the voltage source it is measuring. You don't always need an RC filter though. I've done a lot of unshielded external sensors near engine ignition and didn't have a noise problem.