LiPro ImaxB6 80W clone STM32f030c8t6
Alex Go
Any chance to port cheali to stm32 platform ?
diggit
TBAmax
What would be the good ways to go about this?
I understand that the cheali code was highly optimized at some point to fit into the 8bit micros and some other micros that only have C but not C++ compiler. This included the conversion from C++ to strictly pure C. Conversion from classes to namespaces, etc.
The workflow: Code -> optimize.
The optimized version in turn is very hard to work with in regards to modifications and porting.
So in my mind it would require some de-optimization. Because the flash and ram resources are not that scarce resource on stm32.
Can not just use the pre-optimized version for starters because many modifications and fixes to the algorithms also have happened after the optimizations.
But the best UI and the fact of having it in modifiable open source code is definitely the motivation to go.
Roberto García-Ramírez
--
You received this message because you are subscribed to the Google Groups "cheali-charger" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cheali-charge...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/cheali-charger/5857ab76-8460-45e8-a0ca-e36ca09c9e94n%40googlegroups.com.
diggit
Modern MCUs offer better ADCs and space for future development.
I would then consider modernizing codebase and porting it to some charger with graphical sceen. But that is my opinion. I don't have motiovation nor time to work on this stuff anyway. :)
Dieter Mayer
Yes, the codebase is structured to make this practical. The src/hardware/ tree is cleanly separated from src/core/, and there are already two working ARM Cortex-M0 ports in the tree (nuvoton-M051 and nuvoton-NUC029xAN) that you can use as a template. STM32F0 is the same Cortex-M0 class, so most of the work is register-level mapping, not algorithmic.
Quick question first: which specific charger or board are you targeting? That determines effort more than the chip choice. If you can share the model name and ideally a photo of the PCB, it helps narrow the path. Somebody may have already documented the pin map, or it might mirror a known clone.
For an existing STM32-based charger, the actual work breaks down roughly as follows:
- Reverse-engineering the pin map (MCU to LCD, keyboard, ADC frontend,
SMPS PWM out): around 3 to 5 days. This is the real time sink.
Multimeter continuity from chip pins to peripherals. - Toolchain setup (arm-none-eabi-gcc, OpenOCD or ST-Link, CMake
additions): 2 to 3 days. - Porting src/hardware/stm32fX/cpu/ from the Nuvoton template
(Timer, ADC, GPIO, USART, NVIC): about 1 to 1.5 weeks. - EEPROM emulation in Flash (STM32 has no dedicated EEPROM):
2 to 3 days. Standard library, but you have to deal with
wear-leveling. - PROGMEM compatibility layer (cheali-charger uses PROGMEM heavily
for menus, strings, vtables; STM32 has unified Flash via const):
1 to 2 days. Just a thin wrapper. - Bring-up and calibration against real hardware: about 1 week,
iterative. Multimeter and dummy loads.
Total: roughly 3 to 4 weeks of focused work if you have the hardware sorted and some ARM-GCC experience.
Practical prerequisites:
- SWD access. Most STM32 chargers have an unpopulated 5-pin SWD
header somewhere near the MCU. If not, you have to solder directly
to PA13 and PA14. An ST-Link V2 clone from AliExpress is about
3 EUR. - Read-protection check. If the factory firmware was flashed with
RDP, you cannot read it for analysis, but you can still overwrite.
Worst case for you, best case for them.
Worth knowing: matiaschamu has an in-progress port of cheali-charger to the CMS32L051 (Chinese Cortex-M0 used in newer iMaxB6 clones). See:
https://github.com/matiaschamu/cheali-charger/tree/Support-cms32l051
Same architecture class as STM32F0, so looking at that branch gives you a concrete sense of what changes are needed.
One more pointer: I have my own fork at https://github.com/DieterMayerOSS/cheali-charger where over the past few weeks I have been doing maintenance work that would be useful to anyone starting a port. Highlights, in case any of it saves you time:
- Eight firmware bug fixes in src/, all small and contained. ETA
calculation was reversed since 2013 (uint32_t underflow), the
isCalibrationRequired guard was missing for an empty connection
mask, a div-by-zero in calibrateValue, a dead state in
TheveninMethod, etc. Worth picking up before you carry the code
forward to a new MCU. - Pb/AGM float charging (cherry-picked from gromdar's fork) plus
three smaller Iggnus features (chemistry-aware capCutoff
defaults, long-press STOP to prevent accidental aborts, frozen
V/I display after charge completes). - Three written audits under docs/ covering SMPS.cpp, the watchdog
situation (spoiler: there isn't one), and the EEPROM corruption
handling. These document undocumented design intent that would
otherwise need to be rediscovered during a port. - Public-API Doxygen annotation on AnalogInputs.h, Strategy.h, and
Calibration.h. Helps when you're mapping interfaces to a new HAL. - A host-side sim under sim/ with about 110 unit tests covering
the algorithmic core (Thevenin model, balancer logic,
calibration, monitor safety checks). If you port the firmware
to STM32, you can keep running these tests to confirm the
algorithm code still behaves identically on the new architecture. - API typo cleanup (intterrupt, Mesurment, Ballancing, procent,
etc.) which makes the code easier to navigate, though it does
create merge friction with the original upstream.
It is on a branch called sim, version bumped to 3.0. There are also rebuilt .hex files under hex/ for the 20 atmega32 targets in case you want a known-good baseline before swapping to STM32. Feel free to cherry-pick anything that is useful.
Which board are we talking about?
Rob Keij
Hi,
In 2017 I ported the cheali-charger firmware to an ATmega644, and
it worked well.
I am currently considering porting the cheali firmware to an
ESP32, or possibly to an STM32 platform.
If there is enough interest, I could design a new schematic and
PCB, build a prototype, and work on the firmware port.
For me, porting the firmware to STM32 or ESP32 is possible, but I
would only start such a project if there is
enough interest from other users/developers. Since this would be a
hobby project, it would take a considerable amount of time.
Best regards,
Rob
