CFW for KSGER/Quicko STM32 Soldering Stations

[DavidAlfa]

Well, I'm not a software engineer. Learned C, stm32 and all that by myself.
There must be some differences when comparing amateur vs everyday professional work!
And if course, this is not paid up software, but done in my free time to the extend I consider enough.
The screens need a lot of heap. Each widget is about 60-96bytes, although I made a lot of work to reduce the footprint.
So when you load a big screen, keep suming widgets, easily 3K.
+ When saving the Flash, it needs to store the 2K block before erasing and rewriting.
That's why automatic saving is disabled when certain screens are active.
+ Current profile settings
+ system settings
+ Screen buffer
+ ADC measure data

Everything sums ups really quickly!
You can always check the build report, showing where the ram usage goes.
Check the defines in main.h for debugging the heap usage! You can run the code, adding the heap usage variables to the watch window, checking the usage on any screen, also the absolute max heap usage. It's hard to keep track of everything, normally heap is handled by a OS and not heavily constrained like in a small embedded mcu.
But without the heap, all those screens would be impossible.
And the widget system is really useful and dynamic, provides a lot more flexibility, I don't feel like removing it.
You've seen yourself how easy is to setup a new screen!

For sure it could be optimized more, but I'm done, you can't imagine how much time I spent on it.
Actually splitting the screens in smaller sub-screens would be beneficial.
I had nightmwares when implementing the dynamic screen loading. It turns out syscalls.c was missing, no error generated at all, and there was no control on heap usage, I could allocate 3GB no problem! So heap and stack would collide and cause all kind of strange issues.
Why does X change to -2848583 when I write to Y? Oh man, I spent a lot of time until I found the root of the problem
Like I say all contribution is welcome, all I demand is to be responsible of your own work 

[KocsisV]

it needs to store the 2K block before erasing and rewriting

I was considering a solution for that. Could be reduced to 0 bytes on the heap (still needs a few bytes on stack, but not much more), but it needs +1k of flash allocated as a rotating data storage and a lot of effort to code it . Since the heap is allocated anyway it does not matter.

check the build report

I know about that, not checked it in details yet. BSS usage seems reasonable, stack is stack, then there is the 5k of heap which the static analyzer can't say anything about. i saw the debug defines too, but as I said something is misconfigured and I have not yet spent the time to debug why debugging isn't working. It does not stop at the breakpoint, but it sometimes grabs a few tens of bytes from the top of the stack when it's reached but that's about it.

how easy is to setup a new screen

I like the widget system, its great. If someone only needs what's already implemented and is ok with the default behavior then its super fast to use and intuitive. At first I was expecting something hard to use, requiring me to manually call rendering for text, scheduling ui handling calls and similar but its not the case.

heap and stack would collide

One solution for avoiding this is to define the stack so it grows toward an address range which causes an exception. Same goes to the heap. Eg one at the beginning of the RAM address range and one at the end, other sections in the middle. So it will raise an invalid memory address exception (if this MCU has it, and can enter the exception handler without stack) rather than silently corrupting the other. Easier to place a breakpoint to the exception handler, than to track down what wrote where. And to monitor both, at boot both need to be filled with a known pattern and in an interrupt check where the pattern ends / was overwritten. From that the runtime the max stack and heap use can be monitored. Not just the allocated/reported one, but the unintended writing too. If one counter says that the max was X but the pattern only starts at X + 2 then something wrote a byte in unallocated space. This is a common strategy in safety critical systems. Even when an MPU/MMU is present.

[ricktendo]

Why not store the temperature or other dynamic settings that may cause ware on the flash separately in the eeprom

[KocsisV]

Not all boards have an eeprom, nor all have a battery for the rtc (backup ram).

[DavidAlfa]

KocsisV, I debugged a moment while having breakfast. Heap debugging still works great!

- The "fixed" ram is ~4KB. Screens, buffers, different settings/structures...
- Then, the reserved heap is actually a lot larger than required, it peaked at about 2.1KB.

The options were very constrained at the beginning of development, as the original screen management wasn't dynamic.
I had to sacrifice lots of features until I later made the dynamic loading, while 10KB devices were still having issues with random stuff changing by divine intervention .

I repeat, the heap issue I mentioned was caused by "syscalls.c" and "sysmem.c" files missing.
Lost a lot of hair until I analyzed the disassembly code and I noticed _sbrk() was returning always a valid pointer, and quickly figured out the issue.

After more optimizations (Which were a lot!) widget space was reduced, then saving was allowed only in boot, main, settings, calibration and reset_confirmation screens, which use at most 356 bytes, keeping the stack under 2KB, almost halving the previous usage.

But to be safe, I allocated all the free ram to it, it doesn't hurt, that ram would be left unused anyways.
In any case, the system allocates all ram at boot to prevent heap fragmentation.

The widgets design is also dynamic, glueing different elements using pointers.

- Screen (52 bytes). The only not dynamically-allocated part of the gui system.
    - Points to the next screen, first widget, current widget, customized handling functions...

-Main "widget_t" (28bytes)
    - "Content" linked to the widget type. Ex. in the system menu, it's linked to a comboBox_widget_t.
    - "next_widget" points for the next widget, only used in non-combo screens,  ex. boot screen, reset confirmation...

- comboBox_widget_t (28bytes)
    - "first" linked to the first "comboBox_item_t"
    - Then each "comboBox_item_t" contains "next" item and so on.

- comboBox_item_t (20bytes)
    - Linked to "action_screen", "action" or "editable_widget_t".
    - action_screen and action don't use additional space, they hold just integers or a pointer to a function.
    - editable_widget_t is linked to an additional widget, so it's also allocated when creating that combo type.

- editable_widget_t (64bytes)
    - Content can be can be:
         - Editable: "field_int32"(editable integer) or "field_string"(editable string)
         - Multioption: Editable integer but the integer is used as index to an array of strings, ex. value 0,1 -> char *opts[]={"OFF","ON"}

As you see, the ram usage is pretty modular, keeping it optimized for each widget configuration, but grows quickly!
Also, each allocation (malloc) adds 8 bytes to handle internal stuff.

SYSTEM menu has only "screen" combo options, doesn't attach editable widgets:
- Main screen widget: 28+8=36
- Combo widget:    28+8=36
- 6x non-editable items= 6*(20+8) = 168
- TOTAL: 240bytes

Now let's go with a larger screen. "SYSTEM"
- Main screen widget: 28+8=36
- Combo widget:    28+8=36
- 15x editable items: 15*((20+8)+(64+8))=1500
- 5x non-editable items= 5*(20+8) = 140
- TOTAL: 1712bytes

IRON is 2KB, and most remaining screens use ~1KB or less.

Nevermind: STM32F101/2/3 don't have USB OTG, so it's a dead end!

[DavidAlfa]

Bought another screen, found this seller, a lot cheaper:
https://a.aliexpress.com/_u7160L

[yelkvi]

I don't like that this seller has few orders sold.
I prefer to choose such sellers who have a lot of sales. Let it be more expensive.
I bought here: https://aliexpress.ru/item/1005001621784395.html
While I'm waiting. Promised to deliver in the second half of May.

[bozo]

My test with ST7565R.

[DavidAlfa]

Thanks for testing! What binary are you using?
I've just uploaded to git freshly compiled ones using latest code.
Have you tried to tweak Contrast/Voltage ratio settings in the menu?
That's the real picture quality or just the camera making it look worse? (Mine does that a lot!)

[bozo]

KSGER v3 ST7565 CurrentRevision 1MHz.

[bozo]

Latest update is not working. Black screen.

[DavidAlfa]

Might be the wires messing the high frequency signals.
What about this 1MHz version?
Anyways, I've spent too much time with this already, no more guesssing until I test it myself!

[bozo]

This version works well.

[AUTOMOTIVE SOLUTIONS]

really now testing


just downloaded and working are you using the script ?

sorry wrong screen  but new ST7565R still working lol

but do need to flip now but that's no problem

[bozo]

Last two updates for SSD1309.

[AUTOMOTIVE SOLUTIONS]

was you taking about ST7565R or ssd1309 not working

[bozo]

ST7565R runs on version - v3_st7565_current_1MHz.
SSD1309 not working properly v2.0 Apr 30 2022.

[AUTOMOTIVE SOLUTIONS]

ST7565R and working on new STM32SolderingStation using the new script ?

have you tried this version?

[bozo]

That version works.

[DavidAlfa]

ST7565R and working on new STM32SolderingStation using the new script ?
have you tried this version?

What's this? The latest build from git?

bozo,
Try these files, I wonder if the sh1106 charge pump command is causing conflict with the ssd1309.
Also, testing the ST7565 in a breadboard is anything but reliable, should be soldered with wires short as possible.

[bozo]

Test with SSD1309.

[DavidAlfa]

Ah! Great. Do the first two look the same or there's ani difference in brightness?
Please check the different st7565 frequencies too.

[bozo]

Identical first two. I'm also testing ST7565. Everything works ok.

[DavidAlfa]

Even the 18MHz version?? That's confusing, in your tests that was the only difference between getting it working or not.
Anyways, I lowered the SPI frequency to 3...4.5MHz in all controllers.
It's still fast enough and should work more easily with custom boards, wire connections...

AUTOMOTIVE SOLUTIONS, yeah I had enabled Y-flip(Copy&paste mistake), you clearly stated only X-flip was required, fixed.
Latest builds should have fixed everything entirely.
"Should", as I cannot test SSD1309 neither ST7565.

[bozo]

Version v3_1565_18MHz also works.