CFW for KSGER/Quicko STM32 Soldering Stations

[AUTOMOTIVE SOLUTIONS]

we have a faint image on 18 and 500.i will fit the encoder now

now in a dark room trying

just resting eyes a second eye strain really so faint 
update got it

contrast 40
offset 0
x flip on
y flip off
ratio 5


contrast 38 best


after 1 min screen go's black but if you change contrast by 1 starts working
powering off and on will not bring it back you have to change contrast by 1 and back working
powering off and on with display working go's back black change by 1 and back working



contrast 25
offset 0
x flip on
y flip off
ratio 6

could this be a problem my end should i test on the other screen?

[DavidAlfa]

We're getting there 
After 1 min? hmm strange. Let me check if I didn't disable all power-saving functions used for oled screen.

I updated the build script. Couldn't be easier now! Just install CubeIDE, download the code in ZIP from Github, extract it anywhere and run "Building_script.bat"

[AUTOMOTIVE SOLUTIONS]

thank you that's a nice layout. you are starting to make it to easy.

on the old v.03.bin lcd screen go's corrupted in about the same time then black

is this problem my end ?

i will install ide tonight and have a play=press any button stab any key it's all a lottery
jk

[DavidAlfa]

Unless you modify the code, compiling yourself won't change anything, as you'll get the same result.
I the code that makes the soft-start code was still enabled.
But all it makes is a contrast increasing ramp from 0 to the defined value for about 1 second, then nothing else touched the contrast or the power except the display controls.
I disabled that part. Yet, it's strange that it dies after a minute, these things either work, or not. That's weird!
Keep testing the settings!

Pushed the latest code to github.

[AUTOMOTIVE SOLUTIONS]

dam was hoping was like Arduino ide 

[DavidAlfa]

Do you think this firmware can coded in 4 arduino lines? 

Code: [Select]

magic.create(soldering firmware)
display.begin()
menu.show()
do.workmagic()

[AUTOMOTIVE SOLUTIONS]

ammmmmm no lol

screen starts well just flipped stm32 logo then shows ion for 1 second then screen corrupted for 1 second then black

and sorry for delay lifted a track 

i am starting to feel sorry for a pcb its been throw so much just need to hang on in there just a bit longer 

[DavidAlfa]

You must fix everything in the way you can handle it without wires breaking every 5 minutes, ex. mounting everything and only handling the programmer USB connection.
Otherwise it's adding more possible sources of trouble!
I've had such display issues when I reverse engineered the board, removing almost everything.
Any damaged track will make the display randomly go nuts!

[Marvomat]

One question.

Why are buying so many people the KSGER version of the T12 soldering station and not the Quicko Version, which has a much better build quality?
Even the Youtube videos are mostly about the KSGER version.

[AUTOMOTIVE SOLUTIONS]

 track is fixed and i glued in to the bench lol it was like i was one step ahead 

Ksger_v3_ST7565R_test_v0.03_18MHz

contrast 10
offset 0
x flip on
y flip off
ratio 7


stays working with this settings until you restart then have to go to contrast and adjust and its back

ok as i was typing it went black


last update the original 0.3 stays on screen stays good  mmmmm

ok went out come back and black screen

[DavidAlfa]

Keep testing the 1mhz version?

[wickated]

Code: [Select]

SYSTEM |-> etc
       |-> RESET MENU
       |-> DISPLAY |-> Offset
                   |-> X flip
                   |-> Y flip
                   |-> Ratio (Enabled only when using ST7565 display)
                   |-> Dimmer
                   |->  Delay
                   |->  In sleep


Code: [Select]

SYSTEM |-> etc
       |-> RESET MENU
       |-> ЭКРАН  |-> Сдвиг
                   |-> X Зерк.
                   |-> Y Зерк.
                   |-> Усиление
                   |-> Затемнение
                   |-> Задержка
                   |-> Реж.Экрана

anyway i still see no photos of progress with those displays here. is it worth ?

[wickated]

One question.

Why are buying so many people the KSGER version of the T12 soldering station and not the Quicko Version, which has a much better build quality?
Even the Youtube videos are mostly about the KSGER version.

there is board design that is same for both ksger and quicko. v2.1S with cutoff sides. anyway it uses i2c screen, it has some limits. i would suggest buying ane version with spi display

[AUTOMOTIVE SOLUTIONS]

do you mean KSGER_v3_ST7565_CurrentRevision_1MHz\STM32SolderingStation.bin this boots then icon then screen corrupted then black in about 3 seconds.

keeps working longer in first setup menu but end's up crashing

if you think its my end then can test the other lcd screen if you like. i can pop the stm32 off and put in on a blue pill pcb and just have a screen and encoder connected ?

[DavidAlfa]

Aren't the LCD settings being saved after a power cycle?
I mean, if you set contrast 40, isn't being stored on reboot
Yes, you can use a bluepill, follow the Ksger schematic to connect the LCD.
They're exactly the same, just the spi works at a slower speed. It's very strange that the slower performs worse!

Wickated, of course, I already wanted to make a display menu since long time ago, also screen mirroring feature has been asked several times. So that's it.

The display is the less important part of the station.
I2c..spi...meh, not critical, take the one with best power regulation, less signal noise, best stability.
What I really want are accurate temperature readings, not 5000fps LCD
So yeah I'd go with the older quickos.
Newer 956 and 958 seems good too, or at least nobody complained

[AUTOMOTIVE SOLUTIONS]

on Ksger_v3_ST7565R_test_v0.03_18MHz it keeps settings but have to adjust by 1 then it working reboot back not working adjust by 1 then working

its like it initializing the lcd when changing contrast if you get me even though is a faint screen to start with

i have to pop to work soon when i am back i will redo all connections


i am back will give it a go


update i had to try. swap lcd just because what it been through ie 8v. same  just jumps in to life if you change contrast just 1 up then 1 down and staying working on and off same back to having to change by 1 back working and contrast setting are saving.

tell me to piss off but is there any test scripts like you get in arduino or a sketch from a stm32 project with the same screen ? just before lifting stm

[KocsisV]

Hi!

DavidAlfa thanks for this alternative fw for the stations!

I have started modifying the code a bit. Okay, maybe a lot. And I also started re-structuring the project and how the build is done.
I think some of the features I have added could be merged back to your repository after I update all the targets and finish a few more todos (like translations).

In the master branch of my fork (https://github.com/KocsisV/stm32_soldering_iron_controller/tree/master) I have added/fixed:
- Select the last added/copied tip automatically.
- Re-layout the settings storage, so the areas can be updated independently (changingthe layout of one area does not affect the others). This will also make automatical layout upgrades possible in the future.
- Apply temp restrictions on the current set temp if the user changes it in the settings (min max temp)
- Make the "iron.c/h" follow the c stucture object pattern. This resulted in a slightly smaller flash footprint. I have done this while I was understanding how it worked. It was in a middle state where some variables were accessed via getters and setters while some were accessed directly. Now its all getters and setters. This way its possible to intercept (debug/reject/overwrite) any call.
- Removed a few unused code parts, files.
- Separated the main.c/h into the generated parts + hooks and the user written one. This way its much easier to update those files.
- Moved some duplicated code to separate functions.
- Moved some code parts to different places because it was not related to the main purpose of the file.
- Added support for the backup memory: if a battery is present then the last selected profile and tip is stored there instead of writing the flash on every change. And also added the ability to save the last used temperature there. If no battery is present (compiler switch) then it behaves much like it did previously, except its possible to make it only affect the current power cycle -> on the next boot it defaults back to the stored one. The behavior is user selectable in the menu.
- Added an addons screen where people can add other functions.
- Addon for controlling a fume extractor.
- Addon which reminds (beeps at) the user to turn off the station if left in standby mode longer than the set amount of time.

Then I noticed that to port these changes to all the targets a lot of eclipse (stm32cube ide is eclipse based) projects need to be edited manually. And I'm a software engineer and spend a lot of time using (and developing plugins for) eclipse. So I restructured the whole project. Its not 100% done yet, as it is missing the automatic generation of the code from the ioc files (I have not looked into it at all how those are generated, currently it uses the stock method), but once those are generated there is no need for any silly batch file or similar. In eclipse you can just click build all then it builds the project for all targets. No need to copy paste stuff, there are no generated conflicting common files, etc. Each resulting artifact encodes the target name too, no more confusing "STM32SolderingStation.bin" / etc. As I said its not 100% done, as I have not yet added the pre-build step to generate the sources from the IOC files. I only spent today evening on this restructuring.
This can be found on the updateProjectStructure branch of my fork: https://github.com/KocsisV/stm32_soldering_iron_controller/tree/updateProjectStructure . I also removed the LFS because that is not fully supported on github if you don't have a subscription. It was only storing a 32kb pdf anyways.
To try this out: create a new eclipse workspace (file, switch workspace), then go to "window", "show view", "c/c++ projects" (maybe its in the "Other..." menu if you have never used this view). Then in the "c/c++ projects" window (it looks exactly the same as the "Project explorer") right click, "Import...", "General", "Existing Projects into Workspace", select the git repository as the "root directory", down in the options section tick (enable) the "Search for nested projects" and import all of them. You will see one project for each target (these are only used as a workaround due to the inability for the stm32cube plugin to use custom outputs for code generation). As you normally do generate code from the IOC files. Now right click on the STM32SolderingStation project and you can switch between the targets in the "Build configuration" menu. Or on the drop down triangle besides the build icon (hammer) in the upper toolbar (but you have to have the project active, aka click on it or any file within it in the c/c++ projects window, else it shows build targets for the other active project). If you build multiple targets and don't delete the other resulting artifacts for other targets (it will show up as a folder in the project), then the build analizer (which shows the ram/flash usage) won't work. But besides this everything else is fully functional. Keep in mind when you edit the build targets select the appropriate target or if it applies to all select "all configurations". There is no need to edit all the targets for eg adding a new source folder/include folder.

What's on my todo list (this is not an ordered list, and its not guaranteed that I will do any/all of these ) :
- Separate the settings screen source files to multiple ones, as it contains 3 (or more?) screens
- Add the source generation from the IOC files.
- Move the common files from the hardware targets (linker + startup script) into a separate "target MCU" folder, and make eclipse handle the rest based on the target CPU define.
- Move / generate the resources (languages, images).
- Make a better menu layout  This "settings" and "iron" is confusing a bit. I rather have a "global preferences", "profile preferences", "profile hardware config" layout or similar.
- Add option for multiple temperature sensors: there is one built in into the MCU, add one for the cold junction and plus the one currently onboard the pcb.
- Add an option to backup/export the settings, maybe a small tool which parses back the binary file then exports it as an XML or something. And the other way around so human readable -> binary.
- Add bootloader support on F103 (via the USB port)
- Add option to rename profiles.
- Move all default settings to a separate file (the constants), because now they are all over the place.
- Instead of using the git repository to store the release binaries, use the releases option in github. Using git to store the binaries just makes the git history huge (which it is now already).
- Add a method for a better "iron in the stand detection" feature, using an IR led + photodiode, so it will work with any shape stand + handpiece.
- Add some kind of auto PID tuning.
- Fix the readme to use relative links, and update it for the newer project structure.

I only started working on this for the fume extractor thing, but I got a bit carried away.

[AUTOMOTIVE SOLUTIONS]

sorry KocsisV nice work.

david this screen when you set the contrast it stays good (more than 5 min's its still working)until restart
15 min still working do i leave it running and see if it blacks out ? or pull stm32 off and pop it on the blue pill?
I am watching a flashing logo (X) for about 25 min now i think lcd not going blank/black 
30 min's still working. i would say screen dose not cut out anymore was it a damaged cog on the old lcd mmmmmmmm 1 problem down next
and tested KSGER_v3_ST7565_CurrentRevision_1MHz  =42,0,on,off and fully working even after restart. you have cracked it.will post pics tomorrow need sleep

looks really good in person
 

[DavidAlfa]

KcsisV, that's a lot of work, great to see someone contributing. I have a lot to review!

Just some thoughts:
-  Before doing so much work at your own, it might be a good idea to talk, it's not the first time I'm developing something, not published yet into git, and someone makes a PR for the same stuff!
   Also, there's some code you might think it's dirty or redundant, and while it might be true in some cases, others are actually small patches to address very specific issues that took a lot of effort to catch.
   I've tried to comment the code in the best way, otherwise I would forget myself how it worked! But not everything is properly described, so be careful when optimizing.

- Not sure about the separate main. The current main had very few lines of code, and didn't cause any issues. You still need a custom main to call the second one. To me, that's just overcomplicate things.

- I don't think IRON and SYSTEM are confusing, it's been clearly stated that IRON stores settings that are unique and private for each profile, while SYSTEM stores global settings applied at all times.

- The temperature was saved long time ago, later removed to reduce flash wear, actually you'll use the same temps for 99% of the time, ex. 350ºC. That was a real Flash punisher

- I don't understand what you did here?
  The used tip is currently saved in the profile itself. Each profile has it's own currentTIP. Then the current selected profile is saved in systemSettings.
  But now you're saving it globally to systemsettings.currentTIP, so if last T12 tip was "2" and you load C210, it will also load "2" ?.
  Anyways the profile type is a rarely changed setting, not nearly as often as the temperature does, so I don't think the "save last tip" option is necessary?
  But if saving to the external eeprom, then save currentTips for all profiles, not just current one.

- I *want* to preserve CubeMX code generation instead manually copying the HAL. Why? Because it's exactly that, a HAL, constantly being enhanced and fixed.
  Thus, that way I can always generate the latest fresh HAL. When a new one appears, all I need is to press "Migrate". If I hardcode it, updating the HAL will need to be done manually. More work!

- I'm not a big fan of hardware mods because interfacing new functions will usually require soldering to the small stm32 pins, which is not a thing for the 90% of the users.
  Sure, you can add anything, but please also add detailed instructions / explanations in the docs, I don't want to start answering questions every 5 minutes

- Yes, some screens are embeded in other files, because they're very small and sub-screens of the main one, also because it recycles several common variables.
  Otherwise, most screens use separate files.

- It's all nice to improve, it also keep in mind that I'm not going to debug your work, so take all the time you need to ensure everything works correctly.

- Yes, I know I should make releases, however, the few times I did, there were few firmware bugs, causing even further confusion between users on which to use, needing to explain everythig.
   So I just removed them, adding the latest binary instead. Doesn't work? Just use the latest version. I don't want to keep track of every single release!

- Picture generation etc? I have no idea. Given there're just a few images, I simply converted them manually. Converting them to XBM and copying the contents is nothing complicated.
  Of course if I had hundreds of pictures, it would be a heavy task.

- The best storing solution would be a FRAM, no wear issues!

- I though many times on adding usb OTG to export/restore the settings, wouldn't be hard. Again, it requires hw modifying, but also more RAM usage, which would be impossible for STM32F101 devices, they have only ~250 bytes left.

- Ensure to check latest code, there were several changes lately... there's a new batch building script, much easier to handle.
  Yes, it might still not that good as fully integrated project, but works, let's you build any or all profiles with a single keypress, not requiring to setup the ide, it finds and invoques everything by itself, making it *much* easier for people not used with this things.
  I just hate when someone publishes a project that requires a lot of intermediate steps, setting up the toolchain, dependencies, importing... 95% of the time there'll be issues before you can build anything! So I don't want that pain for anyone if it's not specifically required.
  Whenever I want to build new firmware, I simply open _Building_script-> Build all.  Three minutes later, I open git and upload the new binaries that were automatically placed in their folders. That's all the work it takes, and I don't want it to be more complicated!

looks really good in person

Is everything working with that screen? Is contrast, etc, being saved and restored correctly on boot?
Never corrupting/glitching? Sure, if 9V went into it, cannot trust it anymore!
Keep trying that one and ensure nothing breaks down.
Are these your definitive settings? 42,0,on,off ...
You forgot thet resistor ratio! What are the effect of adjusting it?

[AUTOMOTIVE SOLUTIONS]

contrast work boot working and can not get it to crash/glitch

last settings 34,0,on.off,5

ratio 6 over contrast white screen
ratio 4 nearly blank screen

i really stating to think it just working will keep pressing buttons but looking good still
(when i get time try the old screen) but 90% faulty

thank you david for all your hard work.

one question if you don't mind what schematic/pinouts should i base my pcb on staying with stm32f103 thanks andy

[DavidAlfa]

When changing resistor ratio causing it going blank, does it come back to life when restoring the value without requiring rebooting?
Well, that was a sneaky one, most ST7565 code used 6 or 7 ratio, it was just in latter tests where I changed it to 5 by default.
Does the contrast work as expected, increasing/decreasing the contrast in fine steps?

You can use any STM32F101/102/103, take the cheapest one, 36 or 72MHz isn't really critical here.
You could build a Ksger v3.1, but with decent routing, two-stage voltage regulation (24v->5V buck converter, 5V->3.3V LDO), proper ground planes, adding decoupling capacitors to every VDD pin, also filtering analog supplies (VDDA+op-amp) with a small chokes+more capacitors.

[AUTOMOTIVE SOLUTIONS]

screen comes back as you adjust so no black outs anymore or needing reboot i have not managed to find 1 bug.
contrast is a nice smooth control like my tv

thank you was just going to spin some pcb's up. i like the idea buck and ldo it is a lot of stress for a ldo.
let the games begin.

thank you for all you do for eev its very appreciated

[yelkvi]

How interesting are you. 
And I'm still waiting for a parcel with displays. 

And today I made brackets for my soldering station so that it can be fixed above the desktop on a shelf. It won't take up space on the table.

[AUTOMOTIVE SOLUTIONS]

thank you interesting most people  say 

david is the man i just brake stuff lol

that looks good in a case like the idea less bench space. i have a case on its way ie getting made and starting on pcb's

just a piss take not finished

update: really can not find any bugs

[KocsisV]

there's some code you might think it's dirty or redundant

Don't worry, this isn't the first thing I work on. I can differentiate between a workaround/corner case handling and actual duplicated/unnecessary code.

I've tried to comment the code

Yea, about that... I don't want to offend you but this code seems exactly like its coming from a one man army. Not much comment, lot of cross referencing, tightly coupled parts, not much logical separation inside the components either, and generally a "patchwork" code. Don't take this as a negative comment because well, you are working on this alone. And that results in this kind of code 99% of the time. Because you know your own work, you fail to see what's wrong with it from a different prespective. I have done this too, not once, not twice.
I don't really plan to organize/separate things much because I don't want to spend a lot of time on this project alone, but I will do a small amount of it. Eg doxygen comment the parts I touch, refactor the names of the functions to reflect where it comes from, separate constants, etc.

To me, that's just overcomplicate things.

It makes it cleaner overall. Common part are in a common file, target specific/generated ones are in another. The best would be to not even have a main.c/h with mixed manual and generated code. I have not deep dived into how the CubeMX templates work, but this hardcoded project structure is not great. Not the structure itself, but the "hardcoded" part.
For both adding the addons and the backup ram init I had to touch the main.c/h, and after code generation it would have been a mess in the git history if I commit the generated parts.

IRON and SYSTEM are confusing

It is in a way that its just a list of all settings, no logical separation between hardware configuration and user preferences. Eg adc/pwm timings, ntc settings, etc are in the same menu as max temperature. The first is a hardware config which ideally should be left at default (if one does not want to debug why it's not doing what it's expected), while the user is free to change the second. If you put these in the same menu then one can assume that its there to mess with it just like a max temperature setting.

don't understand what you did here?

The current tip/profile(/temp) setting stored in the flash become the default tip. It is applied on boot as the current tip (just like how it was done previously). If there is a battery present and the "remember last tip" option is enabled (and the backup mem actually contains the data), then it (the current tip variable) is overwritten by the backup memory on startup.
In the periodic background flash saving task:
- if the remember tip is ON and there is no backup battery -> default tip updated -> works just like before my modification
- if the remember tip is ON and there is a battery present -> last tip is stored in the backup memory -> no flash wear
- if the remember tip is OFF then the default tip setting is not updated
It's true the tip/profile is not changed often, but I see no downside to having an option to disable some behavior.
If you look a few commits further, you will see that I made it (tip selection) profile specific.
The profile/tip saving was just a side effect of the backup ram thing, why not reduce the flash wear if there is a way to do it without removing any previous features? And the current code is not using a "flash friendly" filesystem (eg some kind of copy on write fs), and who knows how durable the clone STMs will be in the future. I worked with 5k euro MCUs which had a guaranteed 100 erase cycles for their program memory. Yes, 100. There is a reason why a few hardware revisions include an eeprom. If they can spend 0,0001$ less by omitting the eeprom they would do it in a heartbeat to gain extra profit.

That was a real Flash punisher

With a proper c.o.w. filesystem it would not be. If the block size/dataset layout is properly setup then only the changed seciton is written every time (in case the temp this could would mean only a few bytes), no need to erase until the given page is full. But introducing a c.o.w. filesystem is in itself about that much code as the whole project is currently.

instead manually copying the HAL.

Good thing then that I'm not doing any manual copying The projects reference to each other. When you switch targets then that changes which project supplies a specific set of files. Updating the HAL/CubeMX code generation happens exactly the same as before. Only difference is that now you don't have to copy paste the project (or any) files at all, nor close/reopen anything. All contained within one single project and its subprojects.
I could even get rid of the separate main.h/.c via a pre-build step too and have one common just as before (which then gets copied to the target mcu's project in a pre-build step automatically, then CubeMX generating the code into it).
I would really like to get rid of these bat files. They don't really work on linux

hardware mods

This is why these addons are disabled by default. They won't show up in the menu, won't get compiled into the binary. I updated the operating instructions already
In theory the switch off reminder could be always enabled, as that does not require any hw mod.

because they're very small and sub-screens of the main one

See my previous comment about the one man army and code structuring/documentation
Either have all in one file, or have all separate. Don't mix and match.

I'm not going to debug your work

Hopefully you won't need to

I don't want to keep track of every single release!

That's not the point. If in the future a dataset migration is implemented (so the user don't have to re-calibrate 60 tips each time the layout changes), then versioned releases is a must. Then you can say "ok, version X supports automatic migration from Y and Z, upgrading from other versions wipes all data!".
This does not excludes having development builds. I already wrote a small tool for myself to migrate between the flash layouts, because I did not want to re-calibrate or re-enter 15 tips.

Picture generation etc?

The focus is not only picture generation, but "generation". Eg.: I rather write the translations in a domain specific language, than having to edit the source code and know exactly which define to update when a new one is added, etc. Let eclipse generate the source files and the required configuration from it.

usb OTG to export/restore

USB would be complicated in my opinion. I was thinking about dumping it out via UART or the SWD debugger console, as either one or both are already wired out on the PCB. Then a script to convert them to layout X. But this not only needs this feature to work, but a properly described dataset layout, not just a struct in the c code.

STM32F101 devices, they have only ~250 bytes left

That's plenty for this feature.
Btw, what consumes this much heap? I have not looked into how the GUI works, but all I saw was the 20 byte windows and similar smaller objects in the BSS area, then 5k heap. I planned to print out what's the max heap usage, but for some reason debugging does not work properly... I even have a genuine J-Link Plus with all the required licenses but somewhere something is misconfigured. The controller does not stop at the breakpoints, but the J-Link dumps the RAM when one is hit so I can see the details, just not step in the code. It is literally the first time I used the j-link plus since I got it like 2 years ago.
Does splitting the menus to smaller sub-menus bring down the heap usage?