Sharing one ESP8266 between multiple STM32s
- johu
- Site Admin
- Posts: 6318
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 249 times
- Been thanked: 1309 times
- Contact:
Sharing one ESP8266 between multiple STM32s
Now I got a dual motor Prius Gen3 board from Damien that I finally put together and it looks working well.
Because I'm a cheapshit I would like to deploy only one ESP module instead of 2 (or maybe 3 on boards to come). then change the STM that you want to talk to on the fly with a button/custom command. This would also be easier then changing between wifi networks.
So, first thing I did was some recognition code. The MG1 MCU on the dual motor board can be spotted because its throttle input is floating. So it shows up as "PriusMG1" in hwver. (If this is to be applied to a 3-inverter board, all 3 MCUs must somehow be distinguished)
Next, all STMs uart outputs would have to be tied together, maybe with some series resistors on TX to avoid them fighting each other in the boot loader phase.
Now, when a board starts up and detects as MG1 (MG2 is considered primary, MG1 secondary) it disabled its UART TX line by simply configuring the pin as floating. The RX line still listens!
All commands that change something (e.g. set, start, reset) are ignored by the disabled MCU, all others can be executed, just that their output never shows up on the TX pin.
Then there is a special command like "enableuart 1/2/x". When MG2 receives "enableuart 1" it DISABLES its UART in the same way as above, and MG1 ENABLES its UART by configuring the TX pin as UART_TX.
This should even work for a firmware update on the selected MCU, the inactive one just sees the reset command come by and also the binary pages and doesn't react, while the active one actually receives the update.
The reason why I write about it is because it is a breaking change. The board with two ESP modules would always start into an inactive MG1 MCU.
Any comments?
Because I'm a cheapshit I would like to deploy only one ESP module instead of 2 (or maybe 3 on boards to come). then change the STM that you want to talk to on the fly with a button/custom command. This would also be easier then changing between wifi networks.
So, first thing I did was some recognition code. The MG1 MCU on the dual motor board can be spotted because its throttle input is floating. So it shows up as "PriusMG1" in hwver. (If this is to be applied to a 3-inverter board, all 3 MCUs must somehow be distinguished)
Next, all STMs uart outputs would have to be tied together, maybe with some series resistors on TX to avoid them fighting each other in the boot loader phase.
Now, when a board starts up and detects as MG1 (MG2 is considered primary, MG1 secondary) it disabled its UART TX line by simply configuring the pin as floating. The RX line still listens!
All commands that change something (e.g. set, start, reset) are ignored by the disabled MCU, all others can be executed, just that their output never shows up on the TX pin.
Then there is a special command like "enableuart 1/2/x". When MG2 receives "enableuart 1" it DISABLES its UART in the same way as above, and MG1 ENABLES its UART by configuring the TX pin as UART_TX.
This should even work for a firmware update on the selected MCU, the inactive one just sees the reset command come by and also the binary pages and doesn't react, while the active one actually receives the update.
The reason why I write about it is because it is a breaking change. The board with two ESP modules would always start into an inactive MG1 MCU.
Any comments?
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
-
- Posts: 827
- Joined: Tue Oct 29, 2019 2:48 pm
- Location: France
- Has thanked: 453 times
- Been thanked: 45 times
- Contact:
Re: Sharing one ESP8266 between multiple STM32s
I like that, there is a duel motor Prius Gen2 in the pipeline with 2 Adapter boards....Good for diagnosis whilst testing on the road too.
Re: Sharing one ESP8266 between multiple STM32s
So much work ... for just a few $(dosh)
What about control from ESP side? Don't think Olimex has two UART channels. Other ESP modules (like WeMos) have two UART channels -> TX1/RX1 and TX2/RX2
Code: Select all
Serial.swap(); //Swaps UART Channel
- johu
- Site Admin
- Posts: 6318
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 249 times
- Been thanked: 1309 times
- Contact:
Re: Sharing one ESP8266 between multiple STM32s
Ah you know I'm always on the quest to replace hardware by software
Yes ESP side would work as well but would also require some work, most of all redesigning boards for WeMos. I think my forum post about this has more lines than lines of code necessary to implement this
Yes ESP side would work as well but would also require some work, most of all redesigning boards for WeMos. I think my forum post about this has more lines than lines of code necessary to implement this
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
Re: Sharing one ESP8266 between multiple STM32s
You can upgrade to MOD-WIFI-ESP8266-DEV with "solder yourself" onboard option.
Re: Sharing one ESP8266 between multiple STM32s
I am keen to see this happen, and am willing to do some work towards it. Have you tried the idea out or done any of the software changes? If so could you send me what you've got please and I will try and take it a step further. Don't worry if not. I have agreed with Damien that I will (attempt to) maintain the Prius/Yaris boards so once we have a working prototype I will update the PCB design. Possibly also do a retrofit bridge board for those that already have a dual motor logic board with two ESP headers.
If it works well I think it will be a good improvement over having to disconnect and reconnect all the time. The only downside I can see is if you wanted to plot both MG1 and MG2 simultaneously that would no longer be possible.
- johu
- Site Admin
- Posts: 6318
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 249 times
- Been thanked: 1309 times
- Contact:
Re: Sharing one ESP8266 between multiple STM32s
I finally got back to this and I have a new plan. Basically every STM32 can be assigned a node id (which will also be used for SDO addressing). Assigning a node id will be the only step where you need to individually need to talk to every processor without the other ones listening.
So say you have a board with 3 STM32 processors all sharing a UART "bus" and thereby an ESP8266. You have assigned node ids 1, 2 and 3. Upon powerup node 1 is always active, i.e. allowed to send something via its UART. The other ones just listen.
Now you can send a command "uartenable 2" which would enable the UART of node 2 and disable it for all others (1 and 3).
That way it is not a breaking change because you could happily use separate ESP modules and assign node id 1 to both processors.
Now, for the hardware. On existing boards, once you have assigned the node id you can connect the two UARTs with a jumper wire. Done.
For newer boards it would be cool to have just one ESP socket and some solder jumpers (or actual jumpers) that initially select which device you're talking to. With id assignment done those jumpers can all be closed.
I'm writing the code for this right now.
So say you have a board with 3 STM32 processors all sharing a UART "bus" and thereby an ESP8266. You have assigned node ids 1, 2 and 3. Upon powerup node 1 is always active, i.e. allowed to send something via its UART. The other ones just listen.
Now you can send a command "uartenable 2" which would enable the UART of node 2 and disable it for all others (1 and 3).
That way it is not a breaking change because you could happily use separate ESP modules and assign node id 1 to both processors.
Now, for the hardware. On existing boards, once you have assigned the node id you can connect the two UARTs with a jumper wire. Done.
For newer boards it would be cool to have just one ESP socket and some solder jumpers (or actual jumpers) that initially select which device you're talking to. With id assignment done those jumpers can all be closed.
I'm writing the code for this right now.
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
- johu
- Site Admin
- Posts: 6318
- Joined: Thu Nov 08, 2018 10:52 pm
- Location: Kassel/Germany
- Has thanked: 249 times
- Been thanked: 1309 times
- Contact:
Re: Sharing one ESP8266 between multiple STM32s
Support R/D and forum on Patreon: https://patreon.com/openinverter - Subscribe on odysee: https://odysee.com/@openinverter:9
- EV_Builder
- Posts: 1200
- Joined: Tue Apr 28, 2020 3:50 pm
- Location: The Netherlands
- Has thanked: 17 times
- Been thanked: 35 times
- Contact:
Re: Sharing one ESP8266 between multiple STM32s
The can-bootloader with latest node selection option comes in handy. You only need to learn one time who is who. Then you update over CanBus each node.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
see http://www.wdrautomatisering.nl for bespoke BMS modules.
Re: Sharing one ESP8266 between multiple STM32s
It wasn't until I got to the last post that I realized this thread is 10 months old. The thought I had is that CAN and I2C both use addressing protocols. Whether it's CAN, I2C, or UART, a custom protocol can use addressing schemes to get unaffected MCUs to ignore transmissions (software instead of hardware). If you already invested hundreds of hours chasing one rabbit, you're not likely to change course and chase a different rabbit (approach). Just sharing thoughts.
I'm betting on the future!
- EV_Builder
- Posts: 1200
- Joined: Tue Apr 28, 2020 3:50 pm
- Location: The Netherlands
- Has thanked: 17 times
- Been thanked: 35 times
- Contact:
Re: Sharing one ESP8266 between multiple STM32s
The can-bootloader is new. So just an update. On this subject.
And sometimes I get carried away by the topics behind another subject/thread.
And sometimes I get carried away by the topics behind another subject/thread.
Converting an Porsche Panamera
see http://www.wdrautomatisering.nl for bespoke BMS modules.
see http://www.wdrautomatisering.nl for bespoke BMS modules.