-
-
Notifications
You must be signed in to change notification settings - Fork 715
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MHP30 Soldering/Reflow Temperature Profile #1672
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hia,
Thank you so much for getting this going.
A few smaller requests for changes that should hopefully be super simple.
(Please feel free to comment back if you disagree; as well all opinions I welcome discussion)
Can you please ensure that even with this profile build flag turned on, by default the device still acts in the old way where it just has a single setpoint with no timeout; and then profile based modes can be turned on if desired for the use case.
❤️ Thank you so much for this though
Not really a nice way at the moment, I generally just use the VSCodium replace tools with a regex to insert the english placeholder.
If we are out of space, yeah we will need to address it; any chance you have any ideas of how best to mask out what strings are actually required per device? Definitely open to ideas here, just hasnt (yet) been touched.
Ack I'll fixup the gen docs this week. It would be ideal if you could add a new markdown file to the Documentation folder about the profile mode (note in the start of the page its only for MHP30 atm). And then link to it from the |
Alright, so i will probably also write a python script and add it.
The question mostly is… are we out of space? How much space does each device have? The TS100 Firmware in English still compiles at 128k at least. An idea that i had would have been to run the make_translation.py multiple times, before each build or at least before each device. If some strings in the translation definition file are marked as only needed for certain devices, the string could be set to an empty string there which should be enough? Alternatively, features could be defined per device in a format that is readable for both python and the makefile and instead of defining which features to compile in via the configuration.h it could be added using a compiler flag. (So there are no deviations between what the compilers thinks and what the translation script thinks.)
I'lll take a look. |
Keep in mind that some TS100's actually only have 64k of flash, so we need at the least TS100 to stay in its 64k box. The bigger issue is the TS80P which is desperately out of space. While so far they have all used legit ST micros (when generally have always had the full 128k fitted, even if not validated). I dont trust Miniware to keep that going forever since they have swapped what device-implementing-a-clone-of-the-ST-api they have used in the TS100 a bunch already.
I'm leaning towards the latter option of some sort of feature matrix file per device, that python can read and use when generating strings etc. Keeping in mind that as the python generates most of the translation data already, its not a jump for it to also create the header files etc to match the build. Would take a bunch of time to mark strings in the defs as for what features and update the python to generate trimmed files though. |
6c6a9d1
to
df0fbee
Compare
Well, refactoring done and it looks like everything compiles, with the exception of the T80P for a few languages. :/ I can't spontaneously think of a way to save space there other than by implementing the translation strings differently. |
Okay, i've build a relatively simple system that filters out translations. Translations can specify macros that, if they exist, will include/exclude that string. I'm simply calling GCC to export all preprocessor macros for that build and then search through them with python. Works fine! The fun result is that with this merge requests, some firmwares now actually get smaller :D Compared to the last official release:
I'm gonna take a look at documentation now and then assume that this PR is done? |
I've added documentation for the soldering profile mode. All that's needed as far as i can tell is to run the I will also double check that the firmwares compiled with the current state of this PR work as expected on both my MHP30 and my TS100. |
Had to fix a mistake, now i can confirm it runs as expected even outside of profile mode on both TS100 and MHP30. |
First thing I thought reading the discussion about changing file size for devices that don't have features like this: And there you are providing just that! GREAT, FINALLY! 🚀Since this only applies to the function you're implementing, I kindly ask you to do the same for functions like Hallsensor, BLE and PD as well. To possibly further reduce the firmware size for memory-critical-devices like the |
silently passes you a note that you should just check out the diff, because i already did that i mean, why else would i brag about all firmwares getting smaller :P |
Just made a change so that the the black python checker stops complaining too. |
Hey, there's still the call of the menu docs script missing, too early for auto-merge :D Luckily, auto-merge doesn't seem to be working cause the workflow is paused for some reason |
As long as @Ralim does not approve the review, nothing will be merged yet.
I thought this would be good to go? 😊 If this isn't ready yet, though, you still have the option to convert it into a draft. |
In the end there is only one command left to run. Unfortunately, i can't run it, cause the documentation is wrong :D Then it should be ready, yes. |
For this PR dont worry about gen_menu_docs, Ill fix that post-merge. |
CMakeFile is dropped, i also did a bit of a rebase and squash so there's less commits, Could do more if desired, but i'm not sure if that will break the discussions in this PR and i don't know if you will squash this before merging anyway. Well, looks like we're done here? :) |
@codingcatgirl |
Co-authored-by: discip <[email protected]>
Co-authored-by: discip <[email protected]>
Done. Anything else left for me to do? |
Co-authored-by: discip <[email protected]>
Thank you for this, |
Thanks for merging :) |
Is this feature available on latest dev branch? I downloaded artifact from latest dev branch and applied my mhp30. I see profile preferences in setting menu, but cannot enter to profile mode when press & holding A (left) button. |
It was definitely working when the Pull Request was merged. Unfortunately, it looks like @Ralim's Commit for S60 support has removed the button handling to enter the soldering profile mode again. |
Ah ffs. Git hated me with that merge I swear. On it Give me a day or so. |
This PR adds a feature to configure a soldering Profile through the settings, which fulfils feature requests #1201 and #1619.
This feature has the following… uh… features:
The feature is only included when compiling for the MHP30. The reflow profile mode is accessible through a long press on the soldering mode button and, on the MHP30, replaces the previous long press function that was a shortcut to the temperature control.
As a side effect this PR fixes a bug where the the LED would flash wildly when the device turns off the screen.
There's some other bugs i've found while coding on this that i have not fixed, which i have reported in #1670 and #1671.
I have tested it and from what i can tell everything seems to work.
However, there are a few open questions:
gen_menu_docs.py
cause it fails withload_json() missing 1 required positional argument: 'skip_first_line'
. The other question however is if this feature should be documented in some way beyond that.Looking forward to feedback :)
This PR closes #1201 and also fixes #1570!