So is the code in C or C++?
Sorry for not answering earlier... it seems to be a fairly reasonable and straight C as you can see in the repo here on the flawless_testing branch.
https://github.com/luckyTomas/stm32_soldering_iron_controller/tree/flawless_testing/Src 
My thoughts about it:In regards to your recent suggestion to move the project onto a different platform:
* The main thing to realize is that there seems to be a heck of a lot of code in there for the control loop, dynamically adjusting temperature, calibration stuff etc.
* So therefore if you wanted to move it to a new platform the general expectation of what you would be doing would be 'much more of a porting effort'. To keep that stuff and translate it over. Now I don't know the specifics or how relyant this well developed code is on features that are specific to the STM32 family. So YMMV. I am just guessing that devil is in the details of it. I have not myself the knowledge of what they do down in there. At those level.
* Otherwise (if not possible to port because it's too specific to STM32 hardware features). Then having to throw all that stuff away and redo it. Which is to say I look online and keep stumbling over many other people (quite a few, it is no exaggeration) who have done just that. And ended up with independent firmware coding or re-implemented for that build again the control loops etc. BUT so many of them fail in the performance being so so and the heat up time (from cold) to working temperature being in the laggardly range of 9-12 sec. Wheras the true capability and performance of a JBC (T245) cartridge is in the order of approx. 3 seconds. And this is by far the exception than the rule.
In fact there are only about 3 projects I am aware of which *might* have the real world performance I am keen for. (i.e. a similar performance to a real JBC station). In regards to *this* project, it's been commented by somebody else that the PTDreamer firmware is better performing (or less slow / whatever) than the KSGER closed firmwares available from KSGER. However I am not sure of the performance myself.
One other project is a cheap Russian style job (or Romanian rather) uses an ardiuno for the micro and has a cheaper BOM and everything. That one has a video of decent heating performance. The DIY kit is simpler, and you are doing things in a very 'from scratch way'. Unfortunately the guy hasn't open sourced his firmware. And for a long time. Which I feel is a shame. And why I am so interested in this project instead for STM32. (and also to buy a premade controller than build from scratch has it's advantages, and being not-Romainian everything, searching for clues in the google translate etc).
The third and final project is some clever Turkish guy who is selling his units with international shipping. And also has a video demonstrating a great performance. 3 sec with a 10 amp draw @ 24v. His units are significantly more expensive though. More like $70 - $100 depending on specific options etc. But he did a nice professional looking job of it all.
So in summary:
* Do we need yet another different platform that somebody else likes just because it happens to be what they are familiar with?
Well arguably no, because the main benefit of this project is still an option to buy a premade controller and flash it with a .bin. Hehe we are having trouble in that area but maybe it's not enough to move platforms. Since we want to leverage the existing community efforts that have already been going on. For example if nobody else is familiar with that other new platform then er... perhaps it's not actually going to encourage the broader participation from others. And shut them out.
Maybe the performance side also comes under question. Because complications can occur for redoing those complicated stuff onto the other platform. Which is not exactly a known sure thing until it's actually done, and working on the hardware.
Also because we would have to spin out a different PCB and assemble it. Well heh I already have all the parts needed for the Romanian guy project here. Unfortunately his code is still closed source as it has remained so for some time. But it's also a freakkin arduino with literally the fewest possible moving parts. So much simpler than anything else out there. So that would kindda make more sense from the reason to 'avoid ST over complicated stuff and have things simpler, easier'.
You definately cannot port some complicated ST code over to arduino though. If the porting idea is such feasible one. IDK if it really is though... you will need look more carefully in the code. Browsing the commit history is useful to see what those 2 guys were changing there most recently in respect to the algorithms etc.
There you go. I would still expect it's probably path of 'least resistance' to try flashing this v2.1s or modify it should that be necessary for a difference in the layout. And you know... it's already the biggest community project of the 3 options. And the only one with an open source code. All big pluses.
Don't let my complains about ST toolchain stop us here because maybe it's a solvable problem somehow. We have not had enough time to figure it out yet.
We just don't need to take away from those main PROs to this project. Unless it becomes apparent that is in fact really necessary.
===
For other Guy:
(sorry I confuse the 2 of you here, which is which)
Redoing the PCB to make it better is surely a great value though. It may help to get around compatibility issues or issues of finding / buying the wrong PCB. Plus the reliability improvements to the PCB itself. Finally for people like myself, also to just transfer most of the components over from 'crap PCB' --> onto 'good PCB' is also less wasteful. For everybody who already has wrong version. This is also pretty useful!
Home
Help
Search
Login
Register
