How nodes reset should be accomplished when flashing (new PCB too)?

[szafranski]

So hello - especially to devs. I have a question according to nodes flashing "system" that I developed (big word, but what do you do). As you may know that approach was proven to be working on few platforms. In a nutshell: Raspberry sends "flashing data" via UART and Arduino that was recently reset is being programmed - because that's how bootloader works. Right now each node is being reset using Raspbery GPIO. So every Arduino has a reset pin connected to some of the GPIO pins of R-Pi. I even designed a new PCB with those changes in mind - and it can be achieved with proper cabling etc. So it just works. But I was thinking recently - are all those cables necessary? And I came up with an idea, that I2C bus can be utilized for reset purposes. (I performed some prototyping and it looks promising). I will paste my discussion with Michael (few messages):

My idea:
Arduinos may be reset via "themselves" by a command from a I2C bus. How?
If some command on I2C shows (may be anything, depends of the code on the Arduino as you know) it would perform digitalWrite D2 (or any other pin) LOW - and that would be connected to the reset pin of the NEXT Arduino. Why next and not to it's own reset pin? Redundancy. After some poweroloss or any error during programming, the "resetting" Arduino would still have ability to reset the "next" Arduino and Raspberry could program it again. That way only first Arduino would require connection between reset pin and Raspberry. So resetting would be "software based" but still safe.

Michael idea (good tbh) - Arduinos should be "paired", so Arduino 1 should perform a reset on Arduino 2 etc, 2 on 1, 3 on 4 and 4 on 3. Etc.
I agree.

Conclusion:
GPIO resetting:
Pros:

• Simpler to understand
• No changes in node code (besides disabling serial)
• Already coded and tested
• If 1 nodes totally fails 1 node can’t be flashed
• Odd number of nodes is supported
  Cons:
• Much more cables
• Spare LED data pin to be solved

I2C:
Pros:

• WAY less cables and “ports” required (especially important if someone won't use PCB with this feature implemented)
• Easier PCB designing and implementing
  Cons:
• Odd numbers aren’t supported
• Arduino node code change required
• If 1 node totally fails 2 nodes can’t be flashed

So, devs, what do you thinks?
Cheers

[szafranski]

More like "enhancing question" :)

[szafranski]

I don’t know if I will have ability to perform much tests after a week or so for sometime. If you have any ideas/insights, even small - will be glad :)

Nice day!

[HazardCreative]

The "pairing" strategy could make this easier to manage because it would be built into a PCB with no user intervention. However, such a strategy would not be effective should a timer be built with an even number of nodes.

The "chain" strategy allows any number of nodes to be used, but makes the system more complicated to wire up.

Either way, if a node goes down, you lose the ability to self-update two of them (the broken one and the one it signals).

[szafranski]

Agree. Idk if you get that above I was comparing i2c resetting and gpio based resetting. Not i2c and “chain”. “Chain” has no benefits over i2c - I agree.

[HazardCreative]

I think setting up resets via node commands makes a lot of sense, and pairing makes a lot of sense to me as well. Even with an odd number, you could still fall back to manual updating as the project has always been. I don't really like how much of the GPIO your current working implementation requires. New node command code should be pretty minimal.

Interested in thoughts from @ethomas997 and @pulquero on this.

[szafranski]

Agree. Actually we can implement „backup” option which would be beneficial with odd number of nodes too. 1 node can be reset via gpio. Actually that’s all. Right? W dniu pon., 9.03.2020 o 14:01 Hazard Creative <notifications@github.com> napisał(a):

…

I think setting up resets via node commands makes a lot of sense, and pairing makes a lot of sense to me as well. Even with an odd number, you could still fall back to manual updating as the project has always been. I don't really like how much of the GPIO your current working implementation requires. New node command code should be pretty minimal. Interested in thoughts from @ethomas997 <https://github.com/ethomas997> and @pulquero <https://github.com/pulquero> on this. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#262?email_source=notifications&email_token=AFUHCAFYKOC6447GRDWRG43RGTZCJA5CNFSM4LCVL622YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOHAN2I#issuecomment-596510441>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFUHCAEIEKB4LW47DUNOZS3RGTZCJANCNFSM4LCVL62Q> .

[HazardCreative]

That's a really good idea, actually. I like it.

[szafranski]

Meantime I will write what should be figured out:

1. What pins should be used as reset ones
   (And if those pins should be same on both nodes in a pair or 1 should utilize D12 and second D2 due to physical placement etc)
   *** Answer is D12 on both - just figuread it out. Why? Cause it has another "input" on the ICSP header so it will be easy to access in "back-up"/"odd-number" case.
2. What command should be send to make the node entered reset mode (just pulling 1 pin low for a sec - resetting another node)
3. Who will provide that functionality to the code - few lines to send/receive some command via I2C.
4. Be sure that this command won’t be sent any other time. During prototyping some byte value was sent via server start causing 1 node to reset etc - minor challenges.

Anything else?

[szafranski]

I have found only one downside of this “new” way of resetting. Nodes should be flashed just once via PC before inserting in the timer. Nothing life changing - just to be aware of.

[HazardCreative]

They could be done one at a time through the single GPIO reset (or at least one per pair). I expect the board would have jumpers for each nano to be temporarily connected to the GPIO reset. The user would move the jumper across one at a time during initial setup, and then leave it on the odd-numbered node if appropriate afterward.

Let's avoid D12, otherwise we would need to set up an alternate when ARDUVIDRX wiring is used. (Rare but occasionally useful for some developers). Could D8 be used? Boards using this system should not be designed to the legacy hardware address selection spec, but I'm not sure if this would mess with the initial detection of pin grounding. If not, perhaps A1.

At this point I'm pretty comfortable with this and ready to move it forward as a spec to be integrated into PCB and nano code.

Give me a bit of Arduino code that accomplishes the task and I'll make sure it gets into the current nano code in the right place. The command sent to the node could be 0x73. Obviously a different method is used for the GPIO reset, but the existing work here can be used as a guide.

[szafranski]

I will carefuly read through your message later - about another points - but for now: Consider using D12 anyway cause if it is in icsp header, user could absolutely easily connect D12 to the reset of another nano - it is provided in icsp too. So if someone would like to use this functionality without dedicated PCB or on old Delta5 PCB - jumper wires and soldering ICSP should be enough - besides connecting uart pins below the board. Also without the special PCB, resetting via GPIO should be accomplished easily - just move the wire from gpio from one icsp header to another. What do you think? It is kind of worthy for me.

…

Wiadomość napisana przez Hazard Creative ***@***.***> w dniu 10.03.2020, o godz. 03:23:  They could be done one at a time through the single GPIO reset (or at least one per pair). I expect the board would have jumpers for each nano to be temporarily connected to the GPIO reset. The user would move the jumper across one at a time during initial setup, and then leave it on the odd-numbered node if appropriate afterward. Let's avoid D12, otherwise we would need to set up an alternate when ARDUVIDRX wiring is used. (Rare but occasionally useful for some developers). Could D8 be used? Boards using this system should not be designed to the legacy hardware address selection spec, but I'm not sure if this would mess with the initial detection of pin grounding. If not, perhaps A1. At this point I'm pretty comfortable with this and ready to move it forward as a spec to be integrated into PCB and nano code. Give me a bit of Arduino code that accomplishes the task and I'll make sure it gets into the current nano code in the right place. The command sent to the node could be 0x73. Obviously a different method is used for the GPIO reset, but the existing work here can be used as a guide. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[szafranski]

Why board with this system could not utilize legacy numbering system? No idea why that’s might be the case.

[szafranski]

And yet another thought - I am not editing previous messages so you can reply via email:
Do I get it right, that right now serial won’t have to be disabled permanently? If code would look like:

if Arduino got the resetting message (
Disables serial as for a 2 minutes or till next boot

If arduino got resetting message dedicated for it (
It resets another node in a pair
) )

So effectively 2 messages would be sent - general reset and specific reset.

[szafranski]

I was writing from mobile - sorry for edits

[HazardCreative]

Why board with this system could not utilize legacy numbering system? No idea why that’s might be the case.

Because no boards should be designed to the legacy spec in the first place.

[szafranski]

Ok. So it is not related to this from hardware point. I get it though. Is there any new recommended way to make auto selection? Any definitive conclusions?
And what do you think about those D12 pin pros?

[HazardCreative]

Refer to #252 for the auto-numbering discussion, which seems to be narrowing in.

I haven't had the time to fully understand the implications of using D12.

[HazardCreative]

To clarify, the proposed spec is this:

• One GPIO is connected to all nodes' reset lines, but each has a normally-open jumper in the line
• Only ONE jumper is allowed to be closed at a time
• Node pairs connect an output pin the the paired node's reset line
• On a PCB, the jumpers should be standard header pins and not solder bridges.
• For timers with an odd number of nodes, the jumper is left in place on the last node (the one without a mate in the pairing)

For the Arduino pin, D12 can be the default if we require the alternate ArduVidRx wiring to move this assignment as well. I think this is reasonable.
For the Pi pin, GPIO 17 (pin 11) has been suggested.

I propose the above as the official spec for this.

Any final objections?

[szafranski]

Sounds reasonable.

[sl33pydog]

No objections from me

[szafranski]

Idea: connecting RXes VCC line (usually about 3V3) to the AREF pins of Arduinos + enabling AREF as external based.

Advantages - readings "scaled" better and higher resolution of readings - if I get it right?
Also readings will be independent of Arduinos supply voltage.

Disadvantages - 4 more PCB traces

What do you think?

[HazardCreative]

Unrelated to node reset spec.

[HazardCreative]

Specification is final and published here. https://github.com/RotorHazard/RotorHazard/wiki/Specification:-Node-hardware-reset

[szafranski]

Unrelated to node reset spec.

Right, will open new issue

[HazardCreative]

#277 contains I2C write command with function stub only. Requires code to perform reset of other node and testing.