I agree with your primary premise that dedicated indicators can convey critical data in concise, non-dependent ways that are likely more focused than an LCD, OLED, or screen... What I'm questioning however is the mCU overhead trade off?
Will you not have mCU overhead (firmware and I/O) to drive these dedicated indicators (LED's aside) for multi-segment content?
The overhead is really low with just the LEDs annunciators as I already have the data as I need it for other things so I just have to send it, about 20 bits. If I add the numeric display it would be another 20-25 bits, so even at 10 kHz it's plenty fast (off course I'll send it at the max speed the MCU can do it) and I plan to update the display only 2 or 3 times per second as there's no point updating it faster beside loosing MCU time for other tasks.
The two major tasks taking most of the MCU time will be reading the the ADC and handling the ethernet comm.
The I/O overhead is non-existent as I need to send data to the balancing board anyway and they share the same wires.
I scraped this thread to find what you're calling the "HMIB", but missed it in a quick review, and I've not been following all the details regarding design choices and trades. Forgive my ignorance here which may make my question/statement herein non-relevant.
Sorry, I tend to use more acronyms than I should. The whole BMS has 5 boards:
- the BMSB (BMS board)
- the HWPB (hardware protections board)
- the DPB (disconnect and precharge board)
- the HMIB (human machine interface board)
- the RBB (resistive balancer board)
The BMSB is the main board.
The HWPB is a redundancy to the software protections (excepted the short circuit one, SW is too slow for that one so it's only available with the HWPB) and is optional.
The DPB handles all the high current stuff and is the one I just finished routing.
The HMIB has the LEDs annunciators for all the warnings and faults and maybe the numeric display; all the other data (and those ones too of course) is accessible via the ethernet port. So it's optional as you have access to everything via ethernet but is nice to have to see all the status at a quick glance.
And the RBB is a resistive balancer, 1.5 A per board, stackable up to 3 boards for 4.5 A total. It's optional too
The HWPB plugs on the top fo the BMSB and the RBB(s) plugs in the back of it. The DPB and HMIB are connected to the BMSB with ribbon cable to be able to put them some distance away from the BMSB if needed.
TFT touch screens like the the Nextion devices offer complete IDE's that allow you to build all of the static screen content and offload that data and it's management to the host mCU, leaving your devices mCU to simply service the dynamic content.
This feels like it could almost be a virtual push in overhead, albeit I'd give the overhead nod to dedicated indicators... the positive trade in this case is the virtual nature of your HMI using a screen.
Yes but it still has lower clarity, lower constrast, higher power consumption, higher cost and lower reliabilty than just LEDs. You can have the biggest screen you want with all the features you want via the ethernet comm. The HMIB is just a really simple display for the main info in addition to that.
The ethernet port is the main communication means, the HMIB is just nice to have and secondary.