CFW for KSGER/Quicko STM32 Soldering Stations

[DavidAlfa]

There must be a big problem with human eyesight, I don't know how to make it more clear that it ALWAYS needs calibration, default is lower for safety, mainly because in 2 years only 5-6 people have reported calibrations, that's nowhere close enough.

Isn't going to magically improve with the actual fly-by technique:
- "I have a problem, urgent help"
- "Bye until my next problem"

This lazy behavior repeating over and over is really tiresome, PMs and messages whose matters are properly explained in the Readme will be ignored from now!

[KocsisV]

KocsisV, I've been trying (again) passing variables to the Makefile.
It should be possible to declare them in the Environment (Under Properties... C/C++ Build).

It is possible to pass env variables, that's not the issue at all. (See the examples later.)
The issue is still the when it gets executed and the what the eclipse internal builder state is. I explained in this post why its not working: https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4189318/#msg4189318

To provide examples:
https://github.com/KocsisV/stm32_soldering_iron_controller/tree/d8783b6743ef06fe6ce97db9e0d481d5a00da460
In this the code gen is called for each configuration separately -> it only runs for that specific hardware. It runs in the pre-build stage. The internal eclipse builder already generated the makefiles at this stage, it looked through the project and picked out the specified source files and include directories. Since the generated files were not yet present (assuming a clean build), the makefile what eclipse generated will not contain the generated files, and it is not possible to add them anymore. The targets are already "created".
To see where this is called: right click on the main project, properties, C/C++ Build, Settings, Build Steps tab, pre-build steps. This pre-build step is invoked by the already generated makefile.
It is also possible to extend the generated makefile by a "makefile.init" file in the project root but that basically achieves the same thing.

https://github.com/KocsisV/stm32_soldering_iron_controller/tree/49ad550da55d91a381d962cc7e79dcc9e60b1c65
In this the code gen runs before eclipse creates its makefiles -> the generated files will be included in the build. The issue with this is that this builder only runs once, regardless if you ask it to build one configuration or all. And from the variables eclipse provides its not possible to determine if its trying to build a single configuration or all of them. So it works if you only build one configuration at a time, but not for build all.
To see where this is done: right click on the main project, properties, Builders, there I added a new builder named GenerateSources, click on that and on the right click edit. Here it can be specified when to run this builder, what to invoke, etc etc. On the tool arguments section you can see how I pass the "active configuration" into make.

https://github.com/KocsisV/stm32_soldering_iron_controller/tree/02f01120f2284c266f30d4d062747c54ba6679ff
This one is almost the same as the previous, difference is that instead of the main project containing the builder which runs before eclipse's internal builder's makefile generation, each target hardware project has its own builder. The issue similar to the previous, building one configuration works, building all does not. But it fails because of an entirety different reason: CDT bug not triggering the dependency's build.
To see where this is done: same as before, when you import the main project click "search for nested projects", then you will see a project for each hw target. Right click props... on the hw projects.
The main project depends on these hw projects, to see: open the properties of the main project, C/C++ General, Paths and Symbols, References tab. There you will see that each configuration refers to the required hardware project's other config.

clean :
ifeq ($(BOARD_TYPE), KSGER_V1_5)

As I said, don't use IFs Forget that "IF" exists. Forget any and every conditional operator, loop, etc. Make is a declarative language, you don't define "code to run" you define targets and relationships between them. Construct the commands for a specific rule to depend on the target being built. See the current makefile
 for codegen for example: https://github.com/KocsisV/stm32_soldering_iron_controller/blob/updateProjectStructure/mcu/generate_sources.makefile. There is no "IF" in lines 24-29, yet it runs all the codegen. If in the future another hw target is added, these lines don't need to be changed at all, only the "all" target need to be modified with to add a new dependency, that the "all" target needs that new ./boards/XXXX/src/generated file. The rule between lines 24-29 will match this new name too.

So simply

Code: [Select]

clean : $(BOARD_TYPE)then another target with the name KSGER_V1_5 in this case does the same as your if-elif chain. And the if-elif chain will not work in most cases anyways, due to make assumes its a single target, it does not know it depends on env vars (and it builds multiple targets) if you don't include it in the target name or dependencies. You can even get rid of the concrete target name completely by constructing the rule in a way that the name is used to select the target in all cases. Eg

Code: [Select]

clean_% :
  ... instructions to clean on on $* ($* will equal %) ...

(Btw don't do this "clean : $(BOARD_TYPE)" thing, because this has the same issue as having a single target conditionally building something, use "clean_$(BOARD_TYPE) : " instead.)

Please use spaces instead tabs.

Ups. I already have eclipse configured to use spaces instead of tabs (and display tabs as 2 spaces wide). Is there any in the PR you just merged, or is this only an issue in the makefiles?

[islcom]

Working ok now.
Set PW multiplier to 20.

Thanks

[DavidAlfa]

Set PW multiplier to 20.

That's one of the reasons PWM multiplier exists.
Very long pulses exceeding rated power will quickly trip the power supply protection, but with the multiplier it divides the main PWM cycle into several small ones, it's less rude to the supply and might hold the power.
You'll hear the buzzing sound due the increased frequency, but that's the only way not requiring to buy a new power supply.

(Btw don't do this "clean : $(BOARD_TYPE)" thing, because this has the same issue as having a single target conditionally building something, use "clean_$(BOARD_TYPE) : " instead.)
(...)
Is there any in the PR you just merged, or is this only an issue in the makefiles?

I sad it for a reason, I remember opening something, finding it full of tabs... don't remember now, perhabs the Makefile?
Look at my older code... beginning of 2021 or so, when I realized the browser didn't like the tabs! Spent a lot of time fixing the formatting.
So I told you just in case, before you write anything huge
Edit: It seems my STM32 IDE uses tabs in the Makefile, but not in c/h files. Probably the formatting has rules applying only to certain files.

I found Eclipse Configurations to be extremely delicate. Selecting all profiles at once, then adding some variable or command caused all sort of issues.
At some point the Quicko F072 was taking the STM32_F1xx library, although the includes were right.
Cleared the include paths, completely empty, and it kept taking the paths, somehow it was taking the includes from other config.

The project became unusable, not even clearing the configurations and making new ones. Had to restore it several times!
When I modified profile-by-profile, things started to work.

I noticed the external builder only sees global variables... I thought this simple solution, seems working nicely here.

- Declare "BoardName" var in Environment (KSGER_V2, etc)
- Pre-build step (Use a temporal file to store the board name):

Code: [Select]

sh -c "echo ${BoardName} >../mcu/current"
- Modify the Makefile (Get the board from the file):

Code: [Select]

BOARD := $(shell sh -c "cat ./mcu/current")
clean :clean_$(BOARD);
all : ./boards/$(BOARD)/src/generated;

It's a lot faster now!

I made a PR in your github so you can test it.

[islcom]

Thanks, have sent a beer for you.

[KocsisV]

perhabs the Makefile?

That is definitely full of tabs 

Spent a lot of time fixing the formatting.

You know that there are automatic tools for this right  ?
I have not yet checked, but I plan to configure and activate either the build in formatter in eclipse, or the clang formatter if this eclipse build supports that. Then you don't need to care about formatting at all. You can just spit out code without any formatting, not even new lines, once you save the file it will automatically format it. Also this will make formatting consistent in all files and for all committers.

Eclipse Configurations to be extremely delicate

Sure, its easy to break them, they are misleading a lot of the times and totally does not do what you expect them to. At least in case of the build pipeline its quickly reveals itself 

external builder

The (external) builders only run once! Even if you ask it to build all configurations, it will be only executed one time and the active configuration set to the one you currently selected in the GUI. I have no idea how the built in builder receives the state that it shall build the makefiles then run them for all targets if it does it with simple builtin vars. Probably since its a plugin it can access variables not normally visible.
The env vars what you can define under the c/c++ build / environment settings is for the CDT Builder, this is why the "external program" does not see it. The "c/c++ build" only appears if you have the CDT Builder configured and enabled. That whole menu is supplied by it, the settings under that only affect it, nothing else.
You can supply arguments to custom builders under the arguments textbox. Click on the variables button, it will show you what can be passed to it. Eg the active configuration's name.
You can instead of passing the board as an env var, you can simply instead of asking make to build the "all" target, you can just as well ask it to build the "./boards/XXX/src/generated" target where you substitute XXX within eclipse with the active config. (Instead of calling "make all" you can just as well call "make ./boards/KSGER_V1_5/src/generated".)
But this will still only trigger once. And keep in mind, if you don't clean up the leftovers from the previous build before the next, then the CDT builder will include those and you will think that its working, but if you manually delete these files, refresh the project and try again it will fail.

I think you are currently trying to re-create this https://github.com/KocsisV/stm32_soldering_iron_controller/tree/49ad550da55d91a381d962cc7e79dcc9e60b1c65.
I passed the active config via arguments to make (see attached image). But as I said the builder is only triggered once, so "build all" will not work. And in all its wisdom, eclipse calls the "clean" builder after a "build all" for some reason...

[DavidAlfa]

Damn, I see. So, we must choose between being able to build all, or doing one at a time manually?Just ignore my PR then!

Thanks, islcom!

[KocsisV]

I made a PR in your github so you can test it.

While I made my previous comment you seem to made the PRs!

I tested it and it does not work sadly. The temporary file you create is created after the external build tool is executed. So when the GenerateSources builder runs the file is not there. As I said previously it is important when the builder runs and what state the build pipeline is.
This also results in a complete obliteration of all files within a repository during clean. I will fix this issue, this is the second time it happens...  Since the "./boards/$*/src/Core/Inc" does not exist the "cd" command fails, and "find . -not -name 'GENERATED_FILES_DO_NOT_MODIFY' -delete" deletes all files in the repository...

To test it on your machine:
- in your git client click "view ignored files" and delete them all, or clone the repository into a new place so no /mcu/current file exists, nor any previously generated files
- switch off the "Clean" external builder
- try build all (don't try to bulid anything else beforehand)

[KocsisV]

Damn, I see. So, we must choose between being able to build all, or doing one at a time manually?Just ignore my PR then!

Thanks, islcom!

Yes, sadly this is the case. On the upside it is incremental, so if you are working on a single target/config it will not re-run codegen if you don't touch the template files or the IOC files. If you touch the IOC files it will only re-gen that single one. If you touch the main.c/h templates or the interrupt handler templates then it will re-run codegen for all hw targets.

Edit:
What I forgot is you don't need to create PRs, I have my repository set up in a way that it fetches the changes from your repo too. Just tell me which branch to check out. (see pic)

[DavidAlfa]

It's clear here who knows the stuff! Nope, ignore the PR, it's fine!

[KocsisV]

I tried to change the tabs to spaces in the makefile, and now I remember why its full of tabs: it needs a tab before every command of a rule, spaces does not work.
(It's not often that I work with makefiles, I usually use cmake and that does not care.)

[DavidAlfa]

Just the makefile isn't a problem!
Was more if you started to code something large and the editor was using tabs.
I know that from Python too... Got all kind of errors due using spaces instead tabs. Hate so much such silly sintax requirements!

[KocsisV]

Can't find any tabs (that I added) in any of the source files. Doing a project wide search the only ones I found are either from auto generated files, part of an external lib, and a few in the widgets.h, display.h files.
Python accepts spaces Actually it is preferred to use spaces there too. Only rule is that instead of using explicit scope markers ({} in c) it uses the indentation instead.

[ricktendo]

[DavidAlfa]

That's very serious stuff, joking about it might get you and/or your family injured or killed, don't mess with programmers

[trisonic]

I have a K-type bit, but I can't calibrate it because it tells me the delta is too high.
I should proceed manually but I don't quite understand how to do it. Could you please help me?

thanks

[ygi]

Basically the difference between displayed temps and measured temps is more than 50°C therefor calibration can't succeed. You should change the values for cal250 and cal400 (both or either one depending on your situation) in the calibration > settings menu to something more realistic for your stations. Different stations use different opamps and tip brands are all over the place so a bit a DIY is expected there.
For example, if you can't do the 250°C step because it's too hot (say you measure 420°C), you should lower the current cal250 value by 400 (if it was 1500, set it to 1100). If it's too cold, increase it by ~200 and try again. Just don't be to heavy handed when you increase the value as you don't want a red glowing tip.

[DavidAlfa]

trisonic, isn't it correctly explained in the instructions? If there's any doubt just let me know.

CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now.

START
Requires a tip thermometer (e.g. Hakko FG-100 or similar). Calibrates the current tip at temperatures of 250 and 400°C.
Wait for tip temperature to settle (When the thermomether reading stops moving), it can take up to 20 seconds in some cases.
Then enter temperature as measured by the thermometer for each step.
If the entered temperature is more than 50ºC away from the target, the process will be aborted and you will have to adjust it manually.
This values have nothing to do with the Tip Settings calibration values! These are for the tip, while this ones are only used for the calibration process.
You can cancel the process at any time by clicking the STOP button.

SETTINGS
Here you can manually adjust the default calibration values, normally this needs to be done only once.
Cal 250 depends on Zero set, and Cal 400 depends on Cal 250, so if you're changing this, you must follow the correct order:
Zero set (Sampling->Captured) -> Cal 250 -> Cal 400 -> Save

If by any means the 250°C calibration needs to go higher than 400°C value, increase 400°C value carefully and repeat 250°C calibration.
For best accuracy, always calibrate 250°C if CAL_Zero value was changed, and always calibrate 400°C if 250°C value was changed.

Zero set
Calibrates the zero offset of the amplifier. You must have inserted a completely cold tip, or the calibration result will be wrong.
This widgets has 3 states than change when clicking on it:
Zero set: Shows the current value in the system (No changes).
Sampling: Shows the ADC value in real time.
Captured: Shows the captured value and applies it.
To calibrate the zero offset, you must set this mode before moving to the next step.
Zero set value is applied system-wide, not per-tip calibrated.
If you already know your tip calibration values, you can adjust only this parameter and save, then restore the tip calibration values.

Cal 250ºC
Cal 400ºC
Adjusts the value for 250/400°C. When editing this widget, the power is enabled and the value applied in real time.
Move in small steps until the thermometer matches the target temperature

SAVE
Return to calibration menu saving changes.

CANCEL
Return to calibration menu discarding changes.

BACK
Return to system menu.

[trisonic]

trisonic, isn't it correctly explained in the instructions? If there's any doubt just let me know.

Hi

The calibration process is clear to me.
But when the warning and the request to change the "delta" manually appeared on my display, I thought there was some parameter somewhere that was just called "delta"!

By the way, I found the "zero set" to be a bit tricky.
How do I put a cold tip (at room temperature) during this process?
Without a tip the station goes into error and won't let me access this menu.

Thank you

[DavidAlfa]

Read the first line.
Power is removed when entering the calibration menu.
In calibration settings, power is only enabled when editing cal 250 and 400.

Delta means "difference".
So delta between expected 250 and read 320 is 70.
Might edit the name... If it fits..

[trisonic]

Read the first line.
Power is removed when entering the calibration menu.
In calibration settings, power is only enabled when editing cal 250 and 400.

Delta means "difference".
So delta between expected 250 and read 320 is 70.
Might edit the name... If it fits..

The word "delta" could be substituted in the error message but it could be a minor fix. In general by reasoning a little bit it is understood.

However, I would like to suggest this in the calibration procedure:
In my opinion, to start a proper calibration procedure, you should start it without the tip inserted: this is because as soon as you turn the station on, it immediately heats the tip (rightly so) and you should wait for it to cool down.
So I would put the tip in from the bench only after starting the zero procedure from the menu (so you can be sure to take a tip at room temperature).
 
The problem is that: turned on the station without the tip inserted, when I go to the "settings" menu (from the "calibration" menu) I get this error (it doesn't always appear): "ERROR DETECTED Aborting..." and I can't zero.

What do you think?

Thanks

[DavidAlfa]

What is not clear about that yet?

CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now.

BEFORE entering any sub-menu (START, SETTINGS).
You can start your station without tip, enter CALIBRATION, then insert and calibrate each one.
You cannot enter START or SETTINGS without tip, doesn't make any sense, and will cause huge readings due the input floating, about 600-700ºC, that's how it detects the tip.

MAIN SETTINGS->CALIBRATION (Insert tip now)-> START/SETTINGS

Simple as that.

[trisonic]

What is not clear about that yet?

CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now.

if this sentence would be followed by this explanation, everything would be a little bit easier.

BEFORE entering any sub-menu (START, SETTINGS).
You can start your station without tip, enter CALIBRATION, then insert and calibrate each one.
You cannot enter START or SETTINGS without tip, doesn't make any sense, and will cause huge readings due the input floating, about 600-700ºC, that's how it detects the tip.

MAIN SETTINGS->CALIBRATION (Insert tip now)-> START/SETTINGS

Simple as that.

[DavidAlfa]

CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now (Before entering any sub-menu).
You can start your station without tip to prevent it from heating up, then enter CALIBRATION, insert the tip and calibrate it.
Using a cold tip is only critical for the amplifier offset calibration (SETTINGS). If normal calibration works (START), or zero set is already adjusted, it's not required.
START and SETTINGS menus will show warning message if the tip was removed or not detected and then return to main calibration menu.

Clearer now?

[trisonic]

CALIBRATION
When entering this menu, the power is removed from the tip. For best calibration results, insert a cold tip now (Before entering any sub-menu).
You can start your station without tip to prevent it from heating up, then enter CALIBRATION, insert the tip and calibrate it.
Using a cold tip is only critical for the amplifier offset calibration (SETTINGS). If normal calibration works (START), or zero set is already adjusted, it's not required.
START and SETTINGS menus will show warning message if the tip was removed or not detected and then return to main calibration menu.

Clearer now?

Definitely!
I would add this state diagram that sums it all up:
(Station power on without inserted tip) -> MAIN SETTINGS -> CALIBRATION (insert tip to be calibrated at room temperature) -> START/SETTINGS -> start calibration operations:
1) zero calibration
2 & 3) 250° and 400° calibration
End