LiPro ImaxB6 80W clone STM32f030c8t6

[Alex Go]

Hello 
Any chance to port cheali to stm32 platform ?

[diggit]

Hi,

well it is doable, but there would have to be a developer with enough time and motivation. My time is already stretched too thin among multiple other projects. I can review the code and do some testing in case somebody decides to work on this.

[TBAmax]

It would be a logical way to go of having the stm32. I have been thinking of doing the custom hardware with better microcontroller. Stm32 is the most likely candidate.

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]

//

As a user of this imax b6 charger, the main problems are not related to processor quality.

The operations problems are related to quality control on powered components inside the charger and calibration issues. 

So., processor, voltage regulator, multiplexor, balance resistors, capacitors, operational IC, LCD screen, coils, buzzer, diodes never fail. 

OK but, what is the problem? 

Well, mosfet and transistors inside and human errors. 

Yes. The charger is weak on human errors like reverse polarity connections on the input and also on the output. 

Some user complains on voltage/amps reading. So, it is not the same 12,50 volts compare to 12.498735 volts.

So, on this problem we have the culprits, the processor and the code. 

I understand you are looking for this improvements... 

/

--
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]

Hi TBAmax,

Cheali is written in C++. I remember some discussions and efforts to rewrite it to C, but it fortunately did not happen. At least in the mainline.

Before developing new HW, I'd rather try to port it to some other existing Cortex M based MCU first (STM32 or similar).

The only peripherals needed are PWM, ADC, UART, GPIOs and some eeprom emulation and I think that's it.
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?