I’m currently coding up some major improvements (IMHO) to the modules’ communication.
- variable-sized messages, so short messages travel faster (and most are short!)
- send packets along as soon as the header has been received, instead of store-and-forward: faster and needs less RAM
- no more floating point code in the modules
- adjust the balancer PID parameters without re-flashing
There’s more (for instance, my controller is a Raspberry Pi 2040, running MicroPython, and the “real” master is the Victron GX controller), but that’s a different topic.
As I don’t have ESP32 controllers, I also re-enabled ESP8266 support, which at least seems to compile even if I haven’t tested it lately. :-/
The code is at GitHub - M-o-a-T/diyBMS-code: diyBMS v4 code for the ESP32 and new controller hardware
Am certainly curious about your work, especially since you mentioned using RP2040 as a controller.
Is your RP2040 configuration designed simply and only to be an interface between the modules and the “real” controller (e.g. Victron GX) or do you also have plans to use just a RP2040 as controller by itself …maybe with some sort of display attached or possibly use one of the newer wireless RP2040?
It’s certainly possible to use it as a controller by itself. If nothing else you can write a hardware adaption layer for it and otherwise use the existing ESP controller code and the C API.
Or you could link a couple of the required Python modules into ROM along with MicroPython, to free up some RAM space, and then add a basic HTTP(S) server. Problem is, most of these aren’t exactly written with MicroPython in mind and also take up too much RAM
That being said, yes my configuration is a “simple” interface, though I’m working on converting it to a “not-so-simple” frontend. However my basic tenet is that a BMS is a safety critical system, thus the non-safety-critical parts of managing the battery should be segregated off, and the link between the two should be as simple as possible.
My own roadmap is
- clean up the code
- refactor the cell serial stuff back into the controller, now that I know it works reliably
- design a board for it, with a 72-to-12V downconverter, and most likely with a TinyRP piggyback instead of discrete RP2040 components to make it more accessible