* debug github CI git meta info
* fix push.yml format
* fix push.yml for shell
* try to fix push.yml
* try to fix push.yml run
* try to fix push.yml run for multi
* keep debugging
* try to do as less changes as possible
* Implement proper git tagging for builds during pull-requests
* Unify new-line separators between build steps
* Keep debugging
* make_translation.py: fix formatting
* push.yml: try to set ENV values
* push.yml: fix copy-paste error
* Remove extra env var
* Experimenting
* Testing upper()
* Re-testing upper()
* Revert tested values
* make_translation.py: add new lines between blocks to improve readability
* Reformulate docs & comments
* make_translation.py: remove debugging print
* make_translation.py: simplify check for SHA ID env var / code review
* make_translation.py: fix condition
---------
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* Use 3 count filter for MHP30 acceleromter
Requires it to trip 3 times in a row to fire. So really only knocking the unit over trips it off.
* Reset shutdown timer forwards on shutdown timeout
Default shutdown mode off
---------
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
* Implement CI target in Makefile to emulate github CI actions & artifacts
* Improve filter for metadata
* metadata.py: update usage output for wrong number of input arguments / code review
* metadata.py: remove excessive checks for the second input argument / code review
* metadata.py: remove hard-coded model for multi-lang builds in ModelName argument processing / code review
* metadata.py: remove hard-coded models for multi-lang builds in file name pattern processing / code review
* metadata.py: update usage output to remove ambiguity about json extension for output file
* metadata.py: unify new lines style formatting
* metadata.py: sort the list of processing files in alphanumeric order before looping through them to get the same lang order on every generation in every json output file
* Simplify commands for build steps
* Fixing multi-lang builds for Pinecil & PinecilV2
* Makefile: fix multi-thread building support
* source/Makefile: fix formatting
---------
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* Makefile: implement tests target with subtargets to run github CI-like tests locally (in docker container)
* Dockerfile: update comment for PIP packages
* Move TS100 info from wiki to Hardware.md
* Move TS80 info from wiki to Hardware.md
* Move TS80P info from wiki to Hardware.md
* Move Pinecil info from wiki to Hardware.md
* Move some info from Home.md wiki to Documentation/index.md
* Fix path inside docker since Dockerfile has been updated to be in the root project tree after starting container
* Move info from Home.md wiki to Documentation/Hardware.md
* mkdocs.yml: swtich config to forked repo for testing formatting online
* Fix formatting
* Fix formatting (md != rtd)
* Fix formatting for index.md
* Revert mkdocs config to original one after testing
* Documentation/: add power sources info
* Documentation/README.md: update with power sources
* tiny fixes with formatting
* Reformat links to stores
* Fix footnote on _default_ charger for TS80P
* Revert mkdocs config
* Fix footnote about wattage for QC, try fix table in index.md
* docker/buildAll.sh: replace /build/source by /build/ironos to eliminate ambiguity with /build/source/source
* scripts/ci/buildAll.sh: fix shellcheck and add additional comment
* implement printSymbolDeg() helper function as method for OLED class
* Remove extra line added by mistake
* OLED::printSymbolDeg - add drawSymbol calls
* OLED: make comments more clear for implemented method
* OLED::printSymbolDeg(): attempt to improve read-ability replacing if/else by switch/case
* OLED::printSymbolDeg() - add comment for drawSymbol to clarify its underhood
* get tipTemp using ?/: instead of if/else
* Implement getTipTemp() helper
* Add missing header
---------
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* Testing clang-format style check using github CI
* github/push: implement check-style for clang-format as a separate build step
* github/push: add missing packages for check-style/clang-format build step
* source/Makefile: check-style - reduce files of interest; update .clang-format to keep enums init
* source/Makefile: empty lines, spaces & tabs refactoring to unify style - part 1 out of N
* source/Makefile: fix formatting for multi-line variables
* source/Makefile: update formatting for multi-line variables
* source/Makefile: remove spaces on vars assignments to unify style
* source/Makefile: remove unused target style
* source/Makefile: implement exclude vars for clang-format related files
* source/Makefile: exclude configuration.h from clang-format check
* Dockerfile: add diffutils in a container to make check-style target using advanced version of diff to get more advanced output to parse & navigate log more easily
* source/Makefile: implement parser for clang-format inside check-style target to make output compatible with gcc-like error compilation format for compatibility with IDEs/editors for easy navigation over files to fix style errors
* source/Makefile: probably final touches on unifying style
* source/Makefile: implement check-style-list target to only list affected file names with wrong code style for debug purposes
* source/Makefile: fix missed spaces
* deploy.sh: add helper routine to deal with clang-format error output logging from makefile
* gitignore: add clang-format log explicitly
* Refactoring for clang-format compiance
* Dockerfile: add sed
* Dockerfile: false alarm - remove sed since busybox-sed seems fine
* source/Makefile: reduce calls of clang-format & make error log more clean, clear, and tidy
* deploy.sh:check_style() - add removal of DOS EOLs for generated log
* source/Makefile:check-style: add more empty lines between blocks with errors for readability when suggestion is too long & heavy
* source/Makefile: add STOP var to check-style for exit on first failed file
* source/Makefile: check-style: make log looks more like traditional diff/patch output
* source/Core/BSP/Pinecilv2/MemMang/heap_5.c: clang-format refactoring using reasonable advises ... and then disable it in Makefile from scanning by clang-format
* Return headers include order
* clang-format config: disable warnings about non-alphabetic include order
* clang-format refactoring
* clang-format refactoring, part 2
* clang-format refactoring, part 3
* settingsGUI.cpp: refactoring, part 1
* settingsGUI.cpp: refactoring, part 2
* settingsGUI.cpp: refactoring, part 3
* settingsGUI.cpp: refactoring, part 4
* clang-format should be happy now
* workflows/push: put readme check into separate build step & update style
* clang-format: giving SortIncludes option second chance by tweaking a couple of headers a bit
* source/Makefile: check-style: add homebrew parser to check for { } in conditional blocks
* homebrew-format: add { } for if/else, while, and for & unify some comments style; left two errors intentionally to debug & improve parser
* source/Makefile: homebrew-format: fix false negative trigger for multi-line condition in if-s
* Sleep.cpp: unify style & comments
* source/Makefile: remove unused debug target
* mkdocs.yml: unify formatting style
* Docs/README.md: add auto-generated README.md file for Documentation/ directory
* Docs/README.md: fix refs
* Docs/README.md: fix locations
* Docs/README.md: trying workaround spaces in filenames for refs
* Documentation/README.md: update generated file trying to fix all formatting issues
* Documentation/README.md: reduce title size
* Documentation/README.md: add link for official online docs
* scripts/deploy.sh: implement docs_readme function
* deploy.sh: add overwrite warning in help output
* deploy.sh: try to fix shellcheck warnings
* deploy.sh:docs_readme() - show note message only if README should be updated
* deploy.sh:docs_readme() - fix shellcheck
* github/push: add Documentation/README.md check
* github/push: force usage of /bin/sh for deploy.sh script
* testing, testing, testing
* deploy.sh:docs_readme() - make error-related message more clear about what to donext
* Revert change used only to test failure on github CI
* version.h: update BUILD_VERSION policy / PoC
* Fix misplaced chars
* make_translation.py: implement get_version_suffix() function to extend BUILD_VERSION build type legend data
* version.h: update version policy info according to implementation of get_version_suffix() function in make_translation.py
* Version policy update: add double-check for release tag so if version doesn't match use another letter T
* make_translation.py: fix extra tabulation
* version.h: tiny tidy update for version format
* Documentation/DebugMenu.md: update info on version line & date
* Documentation/DebugMenu.md: fix formatting & mistypes
---------
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
* Makefile: fix echo for some environments by replacing escape chars with explicit formatting by spaces and new lines
* Dockerfile: extend comments for documentation purpose & switch WORKDIR to IronOS source tree root dir for the seamless workflow
* saveSettings: add comment for #endif, update var name to reflect its purpose regardless its one-time & temporal
* Settings.h: add enum for orientation mode
* settingsGUI.cpp: add markings for #endifs, add/remove extra new lines to propose better code read-ability in my humble vision from the side, didnt touch any functionality only cosmetic syntax
* settingsGUI.cpp: remove added-by-accident new line in the end of the file
* OLED.hpp: unify ifdef section, add markings for #endifs, add readable macros for ON/OFF OLED state instead of magic numbers
* OLED.cpp: add markings for #endifs, add readable macros for ON/OFF OLED state instead of magic numbers, trying unify common style for the whole file for better read-ability
* Settings.cpp: unify code style
* settingsGUI.cpp: revert true/false for setDisplayRotation
* OLED.cpp: unify comments style
* Root directory refactoring: - move info about Bootup Logo from a sepatate README to main README; - replace separate root scripts build.sh and start_dev.sh by root Makefile; - make Scripts directory and move there: flash_ts100_linux.sh script, ci/ directory, dockerfile, LICENSE_RELEASE, and PULL_REQUEST_TEMPLATE; - reconfigure build & deploy scripts according to changes
* Scripts => scripts
* Scripts -> scripts: re-add missing renamed files
* Directories refactoring: add top-level Makefile, add scripts/deploy.sh script, move github templates from top-level dir to .github, organize files inside Development Resources
* Update scripts/deploy.sh accroding to codestyle syntax shellcheck
* Makefile: add docs-deploy target for mkdocs gh-deploy
* Rename IronOS.yml > Env.yml, update related files
* Docs configs: remove empty characters
* docs/devel: update usage of new script
Currently, IronOS increases the tip resistance by 0.5 ohms for the purposes of USB-PD negotiation. On the Pinecil V2, this can cause issues with power supplies that only supply 60W, such as the Framework 60W supply. At 6.2 ohms, 20V will produce 3.2A, but at 6.7 ohms it will produce 2.985 ohms. This 0.5 ohms increase will cause the V2 to negotiate 20V, draw more than 3A, and trip the overcurrent protection, causing it to reboot. Removing this increase will therefore cause it to fall back to the next highest voltage it can achieve.
* Zipping compiler warning about POW_PD_EXT / Option A
* Zipping compiler warning about POW_PD_EXT / Option B
* BSP/configuration.h: implement option A for POW_PD_EXT warning
---------
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* Update header to declare full buffer size
* Strip refactoring
* Refactor the OLED scrolldown part 1
* High res capable scroll down
* Allow button press to skip scroll
* Bunch of Misc Fixups
* Refactor I2C_SOFT to new #define
* Stitch in some of TS101
Update ShowStartupWarnings.cpp
Update OLED.hpp
Update stm32f1xx_hal_msp.c
Update Setup.cpp
Update Power.cpp
Update Pins.h
Update configuration.h
Power Muxing
Working dual input Voltage handler
Scan mode required for differing injected channels
Inject both dc readings
Update configuration.h
Update configuration.h
Use htim4 for adc control on TS101
Refactor htim names
Add ADC_TRIGGER
Speed up BB I2C a lil
Update configuration.h
Update startup_stm32f103t8ux.S
Update configuration.h
Add LIS2DH clone
LIS2DH gains another clone
Create tooling to allow mapping accelerometers onto different buses
Update startup_stm32f103t8ux.S
Ensure PD IRQ is pulled up
* Stitch in some of TS101
Update ShowStartupWarnings.cpp
Update OLED.hpp
Update stm32f1xx_hal_msp.c
Update Setup.cpp
Update Power.cpp
Update Pins.h
Update configuration.h
Power Muxing
Working dual input Voltage handler
Scan mode required for differing injected channels
Inject both dc readings
Update configuration.h
Update configuration.h
Use htim4 for adc control on TS101
Refactor htim names
Add ADC_TRIGGER
Speed up BB I2C a lil
Update configuration.h
Update startup_stm32f103t8ux.S
Update configuration.h
Add LIS2DH clone
LIS2DH gains another clone
Create tooling to allow mapping accelerometers onto different buses
Update startup_stm32f103t8ux.S
Ensure PD IRQ is pulled up
Allow toggle which button enters PD debug
* Update Pins.h
* Fix hard coded IRQ Pin
Update stm32f1xx_it.c
* Enable EPR
* Tip resistance measurement
* TS101 is a direct drive tip
Update BSP.cpp
* Add S60 and TS101 to builds
Update push.yml
* Update MOVThread.cpp
* Refactor power menu handler
* Correct prescaler
Forgot to update since I changed the period
* Tune in the timer divider for tip control to make PWM less audible
---------
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
* source/Makefile modifications: add HOST_PYTHON variable for flexibility of environment setup / extend clean target to make source directory as new / rename -.d autogenerated temp file
* Makefile: keep Hexfile dir by clean target, add mrproper target to clean all
* Makefile: rename mrproper target to clean-all
---------
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* fix: edit button mkdocs
* fix: edit button on mkdocs
- should open edit page for dev branch and requires login if person is not already logged into github
* add favicons for the mkdocs
* Delete android-chrome-192x192.png
* Delete android-chrome-512x512.png
* Delete favicon-16x16.png
* Delete favicon.ico
* Delete favicon-32x32.png
* Delete apple-touch-icon.png
* Create temp
* add favicon for mkdocs
* mkdocs - highlighting for source code
- Enables highlighting of source code in code blocks
- allow highlighting for other languages that are not default 23
- add favicon and custom location (until folder names are changed to /docs and /doc/img
* Delete temp
* Add files via upload
* organize mkdocs
* add mkdocs extensions & plugins
* remove favicon
* Delete favicon.ico
* Delete font-license.txt
* fix mkdocs for markdown extensions
fixed the name since this is not a materials theme.
* add plugins to mkdocs
* add mkdocs git-revision-date
displays the last revision date of the current page of the documentation based on Git. this could be displayed at the bottom of each page.
* add plugins for MKdocs
* closes ticket https://github.com/Ralim/IronOS/issues/1649
* clean up mkdocs plugins
break up code line as it's getting too long with more plugins.
* fix pip install comand
* fix typo
---------
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* fix: edit button mkdocs
* fix: edit button on mkdocs
- should open edit page for dev branch and requires login if person is not already logged into github
* add favicons for the mkdocs
* Delete android-chrome-192x192.png
* Delete android-chrome-512x512.png
* Delete favicon-16x16.png
* Delete favicon.ico
* Delete favicon-32x32.png
* Delete apple-touch-icon.png
* Create temp
* add favicon for mkdocs
* mkdocs - highlighting for source code
- Enables highlighting of source code in code blocks
- allow highlighting for other languages that are not default 23
- add favicon and custom location (until folder names are changed to /docs and /doc/img
* Delete temp
* Add files via upload
* organize mkdocs
* add mkdocs extensions & plugins
* remove favicon
* Delete favicon.ico
* Delete font-license.txt
* fix mkdocs for markdown extensions
fixed the name since this is not a materials theme.
* add plugins to mkdocs
* add mkdocs git-revision-date
displays the last revision date of the current page of the documentation based on Git. this could be displayed at the bottom of each page.
* fix: edit button mkdocs
* fix: edit button on mkdocs
- should open edit page for dev branch and requires login if person is not already logged into github
* add favicons for the mkdocs
* Delete android-chrome-192x192.png
* Delete android-chrome-512x512.png
* Delete favicon-16x16.png
* Delete favicon.ico
* Delete favicon-32x32.png
* Delete apple-touch-icon.png
* Create temp
* add favicon for mkdocs
* mkdocs - highlighting for source code
- Enables highlighting of source code in code blocks
- allow highlighting for other languages that are not default 23
- add favicon and custom location (until folder names are changed to /docs and /doc/img
* Delete temp
* Add files via upload
* organize mkdocs
* add mkdocs extensions & plugins
* remove favicon
* Delete favicon.ico
* Delete font-license.txt
Fixed a bug in the `setSettingValue` function that caused valid values
within the allowed range to be incorrectly constrained to the minimum
value, when the default value of the option was zero and the allowed
range was from zero to one. The bug was fixed by updating the order of
the `if` statements in the function to ensure that the range check is
done before the value is set. This ensures that valid values within the
range are correctly retained, while out-of-range values are still
constrained to the allowed range.
* track and return Operating mode with BLE
* move global variable to fix build on other platforms
* formatting
* expand bulk data to match individual value data
* formatting
* fix accidental single line if
---------
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
Miniware+Pinecil: fix number of items in uVtoDegC array. This only affects us in case we go above 500degC, in which case we'll be reading invalid memory
Fix the calibrate voltage screen, when it exits, it used to overlay the calibrated divider over the previous displayed image, causing confusion. Now it clears the screen before printing the calibrated value
fixed a typo in the first lines, changed "impostazioni iniziali" with "impostazioni di default", replaced "Voltaggio" with "Tensione" since Voltaggio is considered incorrect by most technicians an is likely an "italianization" of Voltage instead of a proper translation
* Silence wchart warning + go back to simple size limiter
Going from smart linker file to basic #defines to make things just easier to debug
* 2 deg c increments for NTC table
* Update cmsis_gcc.h
* Drop special linker
* Update portmacro.h
* Update Makefile
* moved_reset_settings
Since in most appliances the reset option is placed somewhere near the end, this might be the way to go for IronOS as well.
Fixed some inconsistencies and a typo along the way.
* rearranged settingGUI to match the actual layout
Autostart (if enabled) _before_ showing boot logo (rather than waiting for the entire animation to finish). Only heats if the boot logo is on but not infinite (and autostart is set to heat). Heats to sleep temperature or 75*C, whichever is lower, for safety (and if the iron can get to 75* by the time the logo disappears then this really doesn't matter much). This is purely a preheat if your iron is low-powered and takes a long time to warm and so if autostart is set to heat to soldering temperature, it will start heating the rest of the way once the boot logo disappears.
* Bug-fix Infinite Boot Logo
* Shutdown settings for MHP30
* Accelerometer sensitivity for MHP30
* Allow showing unique device ID
* Bug-fix power pulse at device boot
* Reduce PPS max to 20V to avoid instability
Some PSU's cant actually run at 21V
* Creating a rough draft of a "pre start check" concept
* Newer alpine
* Cleaning up MHP detection
* Cleanup comments
* PID: Run prestart based on ADC IRQ rather than times
* MHP30: Far better startup for detecting tip gain
* Newer alpine for github CI
* Bugfix: Exit on movement
* Feature: Shutdown timeout for MHP30
* Reduce PPS max to 20V to avoid instability
Some PSU's cant actually run at 21V
* Creating a rough draft of a "pre start check" concept
* Newer alpine
* Cleaning up MHP detection
* Cleanup comments
* PID: Run prestart based on ADC IRQ rather than times
* MHP30: Far better startup for detecting tip gain
* Newer alpine for github CI
!Allows for new logo format that supports animation!
Also moves logos out of repo into their own repo for ease of management.
Changes:
* Remove deprecated logos
* Draft new Bootloader decoder
* Use new logo handler
* Simplify logo code further
* Fix time bug on static images
* Fix exit at end of animation
* Docs
* Interframe delay in 5ms increments
* Quick pass handling empty updates
* Exit at the end _after_ the frame delay
* One final delay
* Fix for overrun of logo data
* Fixes https://github.com/Ralim/IronOS-Meta/issues/7
The PINE64 Updater tool does support the latest releases. I almost did not try it because of the statement in this doc, but it flashed 2.17 to my pinecil just fine.
Some obsolete strings were deleted.
ThermalRunaway is not translated intentionally. It can be translated as physical term "Тепловой разгон", but it is better to leave at as it is for searching purposes for users having troubles with their soldering irons.
Extended python script to support writing .bin files directly. This avoids the additional step of using objcopy.
Updated the 001_PINECIL.bin file to match the PNG.
Not all people will have the knowledge to understand what it means to use any objcopy command.
Therefore, the default should be an objcopy, which is easy to obtain on Linux.
* Add a clean method to check if the flash is done correctly or not.
* Note that this partially reverts 48b9097 due to the bash shell use instead of legacy sh shell
(this is for the use of colors in the check report)
Change to more generic /bin/sh script
* added support for using on shells that don't have UID variable; uses UID if it's available and calls "id -u" when it's not
* modified quoting as recommended by shellcheck
* changed to not use "$?" to check for failure. Now uses "if ! (command); then (fail condition); fi" for when a command fails
* Impl. sectioned font table in firmware
* make_translation.py: Extract build_symbol_conversion_table function
* Put translation indices and strings in a struct
* Move translation objcopy step to Python
* Impl. multi-language firmware demo
* Impl. strings-compressed multi-lang firmware demo
* Add font compression to multi-lang demo
* Refactor Makefile a bit
* Fix rules for make < 4.3
* Add more multi-lang groups
* Add Pinecil multi-lang CI build
* Add lzfx compression license text
* Remote multi-language demo group
* Fix build after merge
* Import code from BriefLZ
* Change brieflz for our use case
* Change compression to use brieflz
* Remove lzfx code
* Update license file for brieflz
* Exclude brieflz files from format check
* Add BriefLZ test
The debug symbols are only part of the generated ELF files,
they are stripped from the .bin and .hex files.
So there should be no disadvantage of always generating it.
Before:
52456 Pinecil_EN.bin
81700 Pinecil_EN.elf
140759 Pinecil_EN.elf.map
147554 Pinecil_EN.hex
After:
52456 Pinecil_EN.bin
650556 Pinecil_EN.elf
191974 Pinecil_EN.elf.map
147554 Pinecil_EN.hex
One of my power-banks (UTRAI Jstar One) required 7.0W pulse to
stay awake. Extending this limit to 100 gives more flexibility
in setting up stronger but less frequent pulses.
* Clean translation
* Create enum for off/slow/med/fast
* Update configuration.h
* Default loop on
* Create Medium speed symbol slot
* True/False are no longer defined, move to off string + slightly smoother lerp animations
* Creating uart debug handler
* Simpler get raw uV tip
* Update Setup.cpp
* Debug out working. Moved Logo
Need to update docs around logos before merging this in
* Add in current pwm level + fix signed int
* Update moving logo page for pinecil by 64k
* Update TipThermoModel.h
This generates dedicates Translation.cpp files for translation language
and derives all language-specific data from them.
The Makefile is extended to also take care of generating these source
files.
This allows reuse of nearly all object files between builds of different
languages for the same model and regenerating the translation sources if
necessary.
This speeds up the release builds and the normal write-compile-cycle
considerably.
It also eliminates miscompilations when manually building different
languages.
Translation.cpp is now automatically regenerated when necessary.
This frees the developer from having to remember to execute build.sh
after the translations have changed.
Translation.cpp has been moved from Core/Src/ to the new Core/Gen/ as
otherwise it would end up twice in SOURCE, once through the source
discovery and once through the explicit entry.
Change the generated targets to be the actual object files to be build.
Previously the target name was the dependency file itself. As no other
targets required the dependency file, those computed dependencies were
never used.
Pinecil Support.
This is still not perfect, some compiler issues, but want to get the damn thing in and then iterate on compiler quirkyness later.
(Compiler under docker+WSL+Windows works great, under plain ubuntu+docker it doesnt 🤔 )
With this a TS-I tip is usable with a small netbook 19 V / 30 W PSU with
power limit set to 40 W (38.9 W is reported during the heating up
stage). Without this the device just reboots on attempt to turn on the
heater (unless the power limit is set to 10 or even 5 W).
This code doesn't affect maximum power available and allows up to 73 W
when a beefy 24 V / 96 W PSU is used.
Should be useful for all models, not just TS100.
The fixed comments are based on calculations, not measurements!
Fixes#693.
"Fat" LTO objects are only needed if future linking _without_ LTO is
planned. Not using this option gives about 1.5x building time advantage
without affecting the final binary.
An unused variable is removed along the way.
When a symbol is used from inline assembly, LTO compiling and linking
process becomes more picky with regard to the order of compile/linking
units.
Specifically, when FreeRTOS/Source/portable/GCC/ARM_CM3/port.c comes
before FreeRTOS/Source/tasks.c in find results, the build fails with
undefined reference to `pxCurrentTCB' error.
To workaround the issue, do the same as we already have for
vTaskSwitchContext.
Note: different order affects resulting binary (.text section) size:
39924 with the wrong order and 39884 with the correct.
Fixes#685.
This radically slows down auto-incrementing (when the change button is
kept pressed) of values when user reaches the maximum (last) allowed
option. The scrollbar thumb is blinking to indicate to the user that the
next keypress will wraparound (unless this value was already active
prior to entering menu).
Fixes#536.
The code assumes that whenever scheduler is running I2CSemaphore is
available. Initialising it in a task might lead to race conditions and
is also not happening at all if the task is disabled (for debugging or
due to lack of need for a particular usecase).
The race condition can't happen with the current code though, as GUI
task has lower priority than the MOV task, and they're the only tasks
that currently use I2C. However, this might change in the future with
the code refactoring or introduction of new features.
This patch makes allocating special pages automatic and flexible,
allowing flash size and application start offset specification with
linker command line arguments. It should allow easier porting to
different targets and experimentation without adding code complexity.
Many original STM32F103x8 chips have fully functional 128 kiB flash and
so this additional space might come useful for experimentation,
additional optional features etc. Tested on v2.51A board, including
writing and verifying 128 kiB of random data.
Make variables are added to control that, so to build for the full
undocumented flash size and dapboot configured to start the app from 8
kiB offset one can run:
make flash_size=128k bootldr_size=0x2000
This updates Cortex-M3 port files to version found in
V10.3.1-kernel-only tag of FreeRTOS-Kernel.
The new upstream release includes memory barriers which are essential
for use with modern optimising compilers. Without those firmware
certainly breaks with -O3 -flto and might be also broken with other
optimisation configurations.
Fixes: d59ec10c4e ("Update FreeRTOS to v10.3.1")
Advanced settings menu has 9 entries so the thumb ends up being one
pixel high and on the 9th menu it ends up being closer to the middle of
the screen rather than the end. This patch fixes it.
* Update translation_en.json
The meaning for the 'O parameter' in the scrolling description was missing.
* Update translation_en.json
Proposal for consistent appearance of text.
°F Fahrenheit - You will find the default Fahrenheit configuration in the translation_xx.json
If tempUnitFahrenheit is set to:
true - you can switch in menu settings to Fahrenheit or Celsius.
false - you see only Celsius. All settings are then is in Celsius only.
Add. new version.h, which included now the build version.
Adapted build.sh - to extract the build version from versioh.h and sends it to translation script.
Miwer commented in issue #11 that on Mint 17.3 lsblk does not escape
potentially unsafe characters like it does on Fedora (lsblk v2.32.1). So
broaden the grep match expression to catch both posibilities.
The LIS2DH12 driver performed an unnecessary endianness conversion, as
data from the sensor was already coming in little-endian format. The
MMA8652FC driver is now using the rev16 opcode to perform the swap
rather than doing all the bitshuffling operations in multiple steps.
Made the display on/off mechanism a bit more self-descriptive by
replacing bare true/false values with an enum with more appropriate
value names. OLED automatic turn-off logic has been cleaned up,
along with minor updates to the OLED initialisation sequence.
The highest version of bash shipped by vanilla macOS is 3.2, and it will
stay like that for the foreseeable future (bash being removed as default
in 10.15 is a strong indicator for that).
The build.sh script used Bash 4.x syntax for enumerating available
translations - this patch dials back the clock to Bash 3.x making things
work again on macOS and (hopefully) still maintaining functionality on
other platforms that use a newer version of bash.
I suspect that since -flto was added listing generation wasn't working.
-ffat-lto-objects allows tools like objdump to still work by including
both the internal compiler representation (for LTO) and generated code
in the .o files. It increases the compile time from 12s to 17s on my
machine but I think it is small enough cost for the benefit.
Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>
License: MIT
* [Build script] Detect languages with translation_*.json files
* [Build script] Swap model and language in the build loop to avoid full rebuild
* [Build script] Cleaning potential bugs according ShellCheck
* [Build script] Rewrite AVAILABLE_LANGUAGES calculation with @vomindoraan help
* Tweak Serbian translations
* Add "cyrillicGlyphs": true to translations that use Cyrillic
* translation_cs_cz.json → translation_cs.json
The correct language code for Czech is CS; CZ is the country code
* Add "cyrillicGlyphs": false to other translations, move "languageLocalName" to top
Also change BG and HU "localLanguageName" to start with a capital letter
* Add missing "languageLocalName" field for Slovak
* Rearrange a few fields so they're in the same order for all languages
* Regenerate translations source file
* Portugues → Português
* translation_dk.json → translation_da.json
DA is the ISO 639-1 code for Danish
* translation_ua.json → translation_uk.json
UK is the ISO 639-1 code for Ukrainian
* Update language codes in build.sh
* Enabled DOUBLE line for Croatian + translation fix
Enabled DOUBLE line Menu for Croatian.
A minor translation fix.
* Added Double line menus for Croatian
Added Double line menus for Croatian. For some reason they were not included in the previous pull request, even though I made them (most probably it was by my mistake).
* Added "Power: " translation for Croatian
* Menu desciption scroll sped up 3x
* Slow scroll
* Additional HR translation fix
* EOL fixed
* Fixed flickering - update only when required
* Reverted to Ralim/ts100 current Translation.c, HR translation fix moved
to translation-hr branch
* Synchronized with Ralim master
* Synchronized with Ralim
* Ralim
* Ralim
* Sync
* - Translation Editor Tool (HTML5)
- Translations Parser (HTML5 tool for extracting initial translations from Translations.cpp to separate JSON files)
- Languages extracted into separate JSON files
* Added make_translation.py pre-compile script that creates Translation.cpp from JSON files. This one is just for single-language version, until we make a multi-lingual one.
* Fixed Lithuanian local language name.
* Fixed _lt.json syntax
* Added 12x16 and 6x8 HTML5 font editor
* Added Icon (16x16), Screen (84x16) and Full-Screen (96x16) sizes to Font Editor
* "Font Editor" changed to "Bitmap Editor"
* Added 24x16 icon size
* Croatian translation update
* Merged
* Croatian translation update
* Update translation_vl.json
Deze vertaling is geen wijziging van de Nederlandse vertaling; ze is bedoeld voor Vlaamse gebruikers en wordt aangeboden als een nieuwe vertaling. Dit is de eerste versie die nog moet worden getest op de TS-100.
* Restore NL translation & generate NL_BE source
* remove hardcoded MODEL_TS80
* #define MODEL_TS100 in sw4stm32/atollic config
* whitespace fix
* use sum of 'defined' instead of logic
* only print handle temp, not PCBVersion
* whitespace fix
* Updated Hungarian translation json
* Fixed Hungarian translation name
* Ran make_translation.py to update Hungarian strings
* Reverted changes in other languages in translation.cpp
* Estimated pinout into the ioc file
* Fix Atollic paths to be somewhat more portable
* Add make command
* Add rough calls to ADC2 [untested]
* Using dual ADC injected modes
* Start both ADCs
* Move some IRQ's to ram exec
* Stabilize PID a bit more
* Add in ideas for tip type selection
* Update peripheral setup to support TS80
* Add tiptype formula / settings struct
* Add function ids to the settings menu
* Rough tip selection
* Rough out new cal routine for simple tips
* Hardware test is fairly close for first pass
* Add Simple calibration case [UNTESTED]
This adds the calibration option that uses boiling water to the calibration menu.
This is untested, and may need gain adjustments before use.
* [Feat] Add some QC testing code
* Typo fix
* Add double button press handler for different rising times
* Add hook for jump to sleep mode
* QC for 9V Works!
* Rough out QC handler, trim out old menu help text thats useless
* QC 9V working... Static all the things (Low on ROM)!
* Static all I2C to save space
* Move QC negotiation into background task so it doesnt block the UI
* Input V display works, tune ADC
* QC 3 steps working
* Start tip R measurements
* Impliment tip resistance
* Fix up the accel position, link in auto QC stages
* Fix tip title
* Tip type settings, Static OLED
* Revert I2C callbacks
* Misc Cleanup
* Better Gain value, need to investiate offset
* Add model warning
* Add TS80 Boot Logo (#367)
* Add TS80 Boot Logo
* Refined
* Moved down by 1px
* Add in power selection 18/24W
* Clean up accelerometer, fix TS100 builds, Fix voltage div cal
* updated spanish translation
* fix translation of 'blinking'
* print which translation json is being read
* removed PID settings
* #362: updated italian translation
* improved json error reporting in make_translation.py
* fixed extra escape character in LANG_SV
* Update translation definitions and Lithuanian translation
* Fix translations: add three new missing options
Finer input voltage calibration
Settings divisor is stored as uint16_t, not uint8_t.
* Allow more precise input voltage divider calibration.
The existing code changed the input voltage by multiple
tenths of a volt per adjustment, which is way too coarse.
This commit simply multiplies the ADC value (and its divisor)
by 4, which allows for finer calibration adjustments.
Unfortunately, for safety reasons this requires a settings
version bump. While old stored divider values can be detected
and multiplied by 4 on startup to update them, if the user
downgrades firmware it will happily read the new higher value
and cause all sorts of problems (which could be either reading
higher *or* lower depending on how getInputVoltageX10's
parameter wraps around in old firmware due to incorrect type.
* Add rough calls to ADC2 [untested]
* Using dual ADC injected modes
* Start both ADCs
* Move some IRQ's to ram exec
* Stabilize PID a bit more
* Add in ideas for tip type selection
* Add tiptype formula / settings struct
* Add function ids to the settings menu
* Rough tip selection
* Rough out new cal routine for simple tips
* Hardware test is fairly close for first pass
* Add Simple calibration case [UNTESTED]
This adds the calibration option that uses boiling water to the calibration menu.
This is untested, and may need gain adjustments before use.
* Simple Cal Roughly working
* Rough out advanced cal
* Enabled DOUBLE line for Croatian + translation fix
Enabled DOUBLE line Menu for Croatian.
A minor translation fix.
* Added Double line menus for Croatian
Added Double line menus for Croatian. For some reason they were not included in the previous pull request, even though I made them (most probably it was by my mistake).
* Added "Power: " translation for Croatian
* Menu desciption scroll sped up 3x
* Slow scroll
* Additional HR translation fix
* EOL fixed
* Fixed flickering - update only when required
* Reverted to Ralim/ts100 current Translation.c, HR translation fix moved
to translation-hr branch
* Synchronized with Ralim master
* Synchronized with Ralim
* Ralim
* Ralim
* Sync
* - Translation Editor Tool (HTML5)
- Translations Parser (HTML5 tool for extracting initial translations from Translations.cpp to separate JSON files)
- Languages extracted into separate JSON files
* Added make_translation.py pre-compile script that creates Translation.cpp from JSON files. This one is just for single-language version, until we make a multi-lingual one.
* Fixed Lithuanian local language name.
* Fixed _lt.json syntax
* Added 12x16 and 6x8 HTML5 font editor
* Added Icon (16x16), Screen (84x16) and Full-Screen (96x16) sizes to Font Editor
* "Font Editor" changed to "Bitmap Editor"
* Added 24x16 icon size
The flickering on the LCD screen was caused by the OLED DMA taking slightly longer than the delays, so the tail end would flicker if the buffer was cleared before it finished writing.
In future may want to double buffer the LCD.
Fixes#290
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 15
VisualStudioVersion = 15.0.26430.15
MinimumVisualStudioVersion = 10.0.40219.1
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "TS100 Logo Editor", "TS100 Logo Editor\TS100 Logo Editor.csproj", "{206C8AEF-3BE6-44E9-A1B0-25BF3805F1CB}"
The Pinecilv2 has hardware support for Bluetooth Low Energy (BLE). This protocol allows reading and writing of parameters to the Pinecil during runtime.
The BLE interface advertises three services, these provide access to live telemetry as well as the ability to read/write settings.
These are outlined in more detail below.
Pinecil devices advertise themselves on BLE as `Pinecil-XXXXXXX`.
They also include the UUID `9eae1000-9d0d-48c5-AA55-33e27f9bc533` in the advertisement packet to allow for filtering.
Unless otherwise noted, all data is sent and received as Little-Endian.
As of the time of writing this, notifications are not fully implemented so data will need to be polled. Notification/Indication support will come when there is time to implement it.
## Using the BLE Interface
It is advised to follow the below points when first implementing a BLE integration. Of course once the integration is working feel free to deviate from these. These are just _suggested_ ideas to help kickstart.
1. When filtering for devices, its preferable to filter by the UUID `9eae1000-9d0d-48c5-AA55-33e27f9bc533`, rather than by the device name if possible.
2. Upon first collection check if the three expected services exist; if they don't the user may have selected an incorrect device.
3. It's best to read the live bulk endpoint over the live service when its easy to do so (one read vs ~15).
1. However if you are just updating one or two line items it may be more efficient to just read these on the live service.
2. Feel free to test both and decide.
4. When reading settings from the device; the association of number <-> setting is fixed, but you may see settings you don't yet know about, make sure you can handle these.
5. You probably don't want to show unknown setting's to the user though.
6. Read the device firmware revision and ensure you can decode it. If BLE is revised it may be essential for handling versions cleanly.
7. It's advisable to keep an eye on the IronOS repository or at least setup the Github watch for release notifications.
1. Future releases may revise some BLE aspects or add new settings for example.
## Services
Below is a description of each service. Note that the exact settings are not listed for brevity; it's best to refer to [the uuid lists](https://github.com/Ralim/IronOS/blob/dev/source/Core/BSP/Pinecilv2/ble_characteristics.h) and the [handlers](https://github.com/Ralim/IronOS/blob/dev/source/Core/BSP/Pinecilv2/ble_handlers.cpp) alongside this.
### Live
`UUID: d85ef000-168e-4a71-AA55-33e27f9bc533`
The live services has one characteristic per reading. The readings (in order) are:
When implementing these; the ones that are not obvious are generally found in the debugging menu. Values are encoded as an unsigned 32 bit number for all results.
1. Live temperature (In C)
2. Live set point
3. DC input voltage
4. Handle temperature (In C)
5. Power level
6. Power source
7. Tip resistance
8. uptime
9. Time of last movement
10. Maximum temperature settable
11. Raw tip reading
12. Hall sensor
13. Operating mode
14. Estimated wattage
### Settings
`UUID: f6d80000-5a10-4eba-AA55-33e27f9bc533`
The settings service has two special entries; for saving and resetting settings.
Otherwise all settings are enumerated using UUID's of the format : `f6d7ZZZZ-5a10-4eba-AA55-33e27f9bc533))` where `ZZZZ` is the setting number as matched from [Settings.h](https://github.com/Ralim/IronOS/blob/dev/source/Core/Inc/Settings.h#L16).
All data is read and written in fixed unsigned 16 bit numbers.
#### Settings save
To save the settings write a `0x0001` to `f6d7FFFF-5a10-4eba-AA55-33e27f9bc533`.
Its advised to not save settings on each change but instead to give the user a save button _or_ save after a timeout. This is just to reduce write cycles on the internal flash.
#### Settings reset
To reset all settings to defaults; write a `0x0001` to `f6d7FFFE-5a10-4eba-AA55-33e27f9bc533`.
This will reset settings immediately.
### Bulk
`UUID: 9eae1000-9d0d-48c5-AA55-33e27f9bc533`
The bulk endpoint is where extra data is located with varying read sizes.
#### Live data
The bulk live data endpoint provides all of the data provided in the live endpoint, as one large single-read binary blob. This is designed for applications that are showing large amounts of data as this is more efficient for reading.
#### Accelerometer Name
_Not yet implemented_
#### Build ID
This encodes the current build ID to allow viewing and handling when the BLE format changes.
#### Device Serial Number
This is generally the device CPU serial number. For most devices this can be used as an ID. On PinecilV2 its the MAC address.
#### Device Unique ID
This is only relevant on the PinecilV2. This is a random ID that is burned in at the factory. This is used by the online authenticity checker tool.
In this firmware there is extra debugging information in a hidden sub-menu.
This menu is meant to be simple, so it has no fancy GUI animations.
- Access it by pressing the rear button (`-/B`) on the iron while it is on the home screen.
- Use the front button (`+/A`) to scroll through the menu.
- To exit, use the rear button (`-/B`) again.
## Menu items
Items are shown in the menu on a single line, so they use short codes.
### Version
There is a static line on top which is presented on every sub-screen and reflects exact version of firmware. Version line on top has the following format - `vX.YYN.[ZZZZZZZZ]`:
- X: major version
- Y: minor version
- N: build type:
- R - git-related **r**elease tag vXX.YY
- T - git-related release **t**ag but version is not vXX.YY !
- D - git-related **d**ev branch
- B - git-related custom **b**ranch
- G - neither above but **g**it-related
- C - build from github **C**I during _pull request_
- H - build outside of a git tree (i.e. release tarball or **h**omebrew customization without git)
- S - something **s**pecial[^ERR]
- V - something **v**ery special[^ERR]
[^ERR]: `S` and `V` are reserved letters for cases when source of firmware is having very unique origin & configuration
- Z: short commit ID hash with 8 digits generated automatically from git (for git-related build types only)
I.e.:
-`v2.22H` means firmware built locally from tarball with release version of `2.22`
-`v2.22D.1A2B3C4D` means firmware with development version of `2.22` from git `dev` branch & with commit ID `1A2B3C4D` (so it can be traced for debug purposes)
-`v2.22R.5E6F7G8H` means firmware with official release version of `2.22` and it's properly tagged with `v2.22` git tag & with commit ID `5E6F7G8H`'
---
**Additional scroll-able items appear in this order**:
### Date
- This is a date of firmware compilation and it has the following format: `DD-MM-YY` (i.e., `01-07-23` means it has been built in July, 1st, 2023)
### ID
- This is used by Irons that have an ID and serial number to help check if the iron is authentic. All Pinecil V1 show the same ID number as this is the number programmed into the MCU.
- The new Pinecil V2 released Aug. 2, 2022 now uses MCU BL706, which enables generating a unique ID/Serial number to every iron. This can be used to verify your [Pinecil authenticity here](https://pinecil.pine64.org/).
### ACC
This indicates the accelerometer that is fitted inside the unit.
- MMA8652
- LIS2DH12
- BMA223
- MSA301
- SC7A20
- None -> running in fallback without movement detection
- Scanning -> Still searching I2C for one
### PWR
This indicates the current power source for the iron.
This may change during power up as the sources are negotiated in turn.
- **DC** input (dumb)
- **QC** input (We used QC2/3 negotiation for current supply)
- **PD W. VBus** input (PD subsystem is used to negotiate for current supply); and VBus is connected to your input power source
- **PD No VBus** input (PD subsystem is used to negotiate for current supply); and VBus is **NOT** connected to your input power source. If it is Not required or possible to do a special mod of your PCB (i.e. late model V1, some early Green PCB models) then [PD No VBus] displays on-screen ([see details and PD Debug section below](https://ralim.github.io/IronOS/DebugMenu/#pd-debug-menu)).
### Vin
The input voltage as read by the internal ADC. Can be used to sanity check it is being read correctly.
### Tip C
This is the tip temperature in °C.
This can be used with RTip for assessing temperature processing performance.
### Han C
This is the handle temperature or more accurately the reading of the Cold Junction Compensation (CJC) temperature sensor. This is expressed in °C. Range of 20-40 °C is normal depending on how hot/cold the room is and how long power has been plugged in which warms the PCB further.
This is used for CJC of the tip temperature.
> If CHan is extremely high, this indicates the temperature sensor isn't reading correctly ([see Troubleshooting](https://ralim.github.io/IronOS/Troubleshooting/))
### Max C
This indicates the max temperature in °C that the system estimates it can measure the tip reliably to.
This is dependent on a few factors including the handle temperature so it can move around during use. As you use the iron, the Max increases to a point.
### UpTime
This shows how many deciseconds the unit has been powered for (600 ds = 1 minute).
### Move
This is the last timestamp of movement. When the iron is moved, this should update to match the Time field (previous menu item).
This can be used for checking performance of the movement detection code.
### Tip Res
This indicates the tip resistance that the device is currently using. For devices with multiple possible values to choose from (Pinecil V2), the appropriate value is automatically detected at every boot-up. Tip should be installed before boot-up or reading can not be done.
### Tip R
This is the raw tip reading in μV. Tip must be installed or reading will be high/inaccurate. At cool, the range of 700-1000 is normal for larger tips and ~1500 for smaller tips (TS80). This is used to evaluate the calibration routines.
### Tip O
This is the offset resulting from the *'Cold Junction Compensation Calibration'*.
### HW G
This indicates the high water mark for the stack for the GUI thread. The smaller this number is, the less headroom we have in the stack.
As this is a high-water mater, you should only trust this once you have walked through all GUI options to "hit" the worst one.
### HW M
This indicates the high-water mark for the stack for the movement detection thread. The smaller this number is, the less headroom we have in the stack.
### HW P
This indicates the high-water mark for the stack for the PID thread. The smaller this number is, the less headroom we have in the stack.
### Hall
This appears if your device is capable of having a hall effect sensor installed (Pinecil).
This shows the current magnetic field strength reading from the sensor. It is used to check if the sensor is operational, and for diagnostics and optimal placement of magnets on a stand (higher number is better/stronger). [See Hall Sensor for details](https://ralim.github.io/IronOS/HallSensor/).
# PD Debug menu
On the Pinecil; if the iron is booted up while long holding the front button (`+`); it will show an extra hidden menu for inspecting USB-PD power adapters. We can also connect to any PD USB power to check Vbus status, even some cell phones with a USB-C port will work if it is PD. It will not show PD messages when Pinecil is powered by DC port, QC, or USB 5V (non-PD). For example, if you connect to a QC charger, you may simply see "PD State 6" which indicates "waiting for source" as no PD messages will be ever be sent and you will not be able to use (`+`) to scroll through PD negotiated messages.
Pressing (`+`) cycles through elements, and (`-`) or unplugging will exit the menu.
The first page shows the PD negotiation stage number; which can be used for diagnosing if PD is not working. Once negotiation is complete; use (`+`) button to advance to other screens which show the different proposals advertised for voltage and current (State 12 means all is good with the PD charger).
#### Below is a method for user modification to convert some early models of Pinecil V1 to safely support 24V on the DC5525 barrel.
⚠️ Warning: do this at your own risk, read everything in this document, and go to the [Pine64 community chat](https://wiki.pine64.org/wiki/Pinecil#Community_links) if you desire advice. An incorrect cut of the trace could render the Pinecil non-working.
Background: a simple user modification to the PCB on _some models_ of original V1 allows it to safely use DC barrel 24V by cutting a trace line to the Vbus which held it back to 21V. You can check whether your Pinecil V1 needs the update or can benefit from it by using a hidden trick in the PD debug menu.
- Follow instructions above to enter the PD Debug menu.
- After a few seconds or after PD negotiates (state above 5) it will show `[PD No VBus]` if it is not needed (i.e., late model V1). Alternately, if it shows `[VBus]`, then the mod has not been done and there is still a connection to the Vbus (the Vbus connection limits you to 21V until you do the mod).
- If you need to do the mod, then follow the instructions/links below which have photos. Careful to only cut the trace and nothing else.
- Then use the PD debug menu again to check for `[PD No Vbus]` before attaching any 24V PSU to the DC barrel. If you do not get the message, then try cutting the trace a little deeper or using alcohol to clear the gap of copper dust. Then check PD messages again. If you need advice/tips, join the Pine64 chat room.
The mod method is shown in the [February 2022 PINE64 community updates](https://www.pine64.org/2022/02/15/february-update-chat-with-the-machine/). Early Pinecil V1 models required cutting a trace to achieve 24V safety with DC barrel PSU. Late model V1 made sometime in 2022 came with `[No Vbus]` already displayed, and no mod is required.
| Pinecil V2 model released Aug. 2, 2022 is an overhaul of the PCB with all relevant components capable of 28V. V2 requires no mods to support the use of 24V DC Barrel jack charger. |
Building this software can be performed two ways: using the STM32CubeIDE or using command line tools.
## STM32CubeIDE
The easiest way to start working with the STM32CubeIDE is to create a new project for the STM32F103RCTx.
Once this is created, remove the auto-generated source code.
Next, drag the contents of the `source` folder into the project and choose to link to files.
You will need to update the build settings for include paths and point to the new `.ld` linker file.
## Command line tools and building a release
In the `source` folder there is a `Makefile` that can be used to build the repository using command line tools.
When running the `make` command, specify which model of the device and the language(s) you would like to use.
### macOS
Use the following steps to set up a build environment for IronOS on the command line (in Terminal).
1. [Follow steps 1 – 3 here to install the toolchain](https://github.com/glegrain/STM32-with-macOS#0---installing-the-toolchain) needed to compile for STM32 microcontrollers.
2. Install `python`:
```
brew install python
```
3. (Optional) Update `pip` so it doesn't warn you about being out-of-date:
```
python3 -m pip install --upgrade pip
```
4. Change to the `source` directory:
```
cd source
```
5. Create a Python virtual environment for IronOS named `ironos-venv` to keep your Python installation clean:
```
python3 -m venv ironos-venv
```
6. Activate the Python virtual environment:
```
source ironos-venv/bin/activate
```
7. Install the dependencies required to run `make-translation.py`:
```
pip install bdflib
```
8. All done! See some examples below for how you can build your own IronOS.
### Examples
To build a single language Simplified Chinese firmware for the TS80P with 8 simultaneous jobs:
```
make -j8 model=TS80P firmware-ZH_CN
```
To build a European multi-language firmware for the Pinecil with as many simultaneous jobs as there are logical processors on Linux:
```
make -j$(nproc) model=Pinecil firmware-multi_European
```
To build a Cyrillic compressed multi-language firmware for the Pinecil with as many simultaneous jobs as there are logical processors on macOS:
```
make -j$(sysctl -n hw.logicalcpu) model=Pinecil firmware-multi_compressed_Bulgarian+Russian+Serbian+Ukrainian
```
To build a custom multi-language firmware including English and Simplified Chinese for the TS80:
```
make -j8 model=TS80 custom_multi_langs="EN ZH_CN" firmware-multi_Custom
```
To build a custom compressed multi-language firmware including German, Spanish, and French for the TS100 (note if `model` is unspecified, it will default to `TS100`):
```
make -j8 custom_multi_langs="DE ES FR" firmware-multi_compressed_Custom
```
To build a release instead, run the `build.sh` script. This will update translations and also build every language for all device models. For macOS users, replace `make -j$(nproc)` in the script with `make -j$(sysctl -n hw.logicalcpu)` before running.
## Updating languages
To update the language translation files and their associated font maps, execute the `make_translation.py` code from the `Translations` directory.
If you edit the translation definitions or the English translation, please also run `gen_menu_docs.py` to update the settings menu documentation automatically.
## Building Pinecil V1
I highly recommend using the command line tools and using Docker to run the compiler.
It's a bit fussier on setup than the STM tooling, and this is by far the easiest way.
If you _need_ an IDE I have used [Nuclei's IDE](https://nucleisys.com/download.php).
Follow the same idea as the STM Cube IDE notes above.
## Building Pinecil V2
To build the Pinecil V2 firmware, you can use a Docker container that provides a consistent development environment across different operating systems, including Windows with WSL2. Here's how to do it:
### Prerequisites
Docker Desktop: Install the latest version of Docker Desktop for your operating system from the official website.
On Windows follow the instructions on the official documentation to install 'Windows Subsystem for Linux' (WSL2).
### Building Steps
1. Clone the repository, initialize and update submodules:
In the development of this firmware, there are three _types_ of firmware released.
These are the "Main" stable releases, which generally have high confidence in being bug free.
Release candidates are released slightly more often, and these are generally perfectly fine for everyday use. These are released early to allow for translation checking and for wonderful people to help spot bugs and regressions.
Finally, there are the "mainline" builds, which are built from the main git branch.
These are built on every change and can be found on the Actions tab (see below).
### Main release
Main releases are made to the [releases page](https://github.com/Ralim/IronOS/releases).
Download the zip file that matches your model of soldering iron and extract it.
Select the appropriate file type for your unit, in general Miniware devices need `.hex` and Pinecil needs `.dfu`.
Flash according to details below
### Bleeding edge / latest
For the _latest_ code, you will need to download the zip file from the artifacts page on the build for what you want.
Head to the [Actions](https://github.com/Ralim/IronOS/actions) page and then select the run for the appropriate branch you would like.
In general you probably want `master`.
Once you click on a run, scroll down to the "Artifacts" section and then click on your model to download a zip file.
Then this works the same as a production release (use the correct file).
# MHP30
This is completely safe, but if it goes wrong just put the `.hex` file from the official website ([MHP30](https://www.minidso.com/forum.php?mod=viewthread&tid=4385&extra=page%3D1) onto the unit and you're back to the old firmware. Downloads for the `.hex` files to flash are available on the [releases page.](https://github.com/Ralim/IronOS/releases) The file you want is called MHP30.zip. Inside the zip file (make sure to extract the file before flashing with it) will be a file called `MHP30_{Language-Code}.hex`.
Officially the bootloader on the devices only works under Windows (use the built-in File Explorer, as alternative file managers or copy handlers like Teracopy will fail). However, users have reported that it does work under Mac, and can be made to work under Linux _sometimes_. Details over on the [wiki page](https://github.com/Ralim/IronOS/wiki/Upgrading-Firmware).
1. Hold the button closest to the tip (MHP30 the left button on the back), and plug in the USB to the computer.
2. The unit will appear as a USB drive. (Screen will say `DFU` on it.)
3. Drag the `.hex` file onto the USB drive.
4. The unit will disconnect and reconnect.
5. The filename will have changed to end in _.RDY_ or _.ERR_
6. If it ends with _.RDY_ you're done! Otherwise, something went wrong.
7. If it didn't work the first time, try copying the file again without disconnecting the device, often it will work on the second shot.
8. Disconnect the USB and power up the device. You're good to go.
For the more adventurous out there, you can also load this firmware onto the device using an SWD programmer, for easier installation follow the guide at the end of this document.
On the USB-C port, `USB_D+` is shorted to `SWDIO` and `USB_D-` is shorted to `SWCLK` so debugging works without disassembly (attach while staying in the bootloader). Installing [IronOS-dfu](https://github.com/Ralim/IronOS-dfu) is recommended as it allows reliable flashing of binary files with [dfu-util](http://dfu-util.sourceforge.net/).
Noting that for the MHP30 the stock firmware checks a checksum at the end of the first 8k that has to be valid or else it goes into "demo mode".
## Mac
sgr1ff1n (Shane) commented in [issue 11](https://github.com/Ralim/IronOS/issues/11) that upgrading worked on their Mac as per normal:
> I just wanted to say that I was able to update the firmware on my ts100 from the stock version to 1.08 found in this repository using my Mac. I simply followed the same steps however through Finder. I have a MacBook Pro (13-inch, Mid 2012) running Sierra 10.12.4 (16E195).
## Linux
While in the past there were reports of unreliable upgrades, the consensus in [issue 11](https://github.com/Ralim/IronOS/issues/11) is that things work mostly as expected in Linux.
@awigen has contributed a script [flash_ts100_linux.sh](https://raw.githubusercontent.com/Ralim/IronOS/dev/scripts/flash_ts100_linux.sh) that works on Ubuntu 16.04 as well as other distros.
If you want to do it manually (or if the script does not work for some reason) the general procedure is the same as for Windows, the differences are in the way to mount the unit and copy the firmware.
Remember that after flashing, the firmware filename will have changed to end in `.RDY` or `.ERR` or `.NOT` and only `.RDY` means the flashing was successful!
- The unit has to be mounted as `msdos` type (thanks @balrog-kun for having spotted it). You may disable automount, but unmounting the automounted drive and remounting as `msdos` works fine. You do not need to turn off automounting, but you do need to unmount the device with `umount`.
- It is recommended to use an all-caps filename for the firmware, even if successful flashing were done with lower case names.
- Avoid USB hubs, plug directly in your computer.
- If it fails, try again several times without unplugging. Just let it remount.
Example, to be run as root, once the unit has been plugged in DFU mode and auto-mounted:
Device will reboot and automount will rerun if not disabled.
Check the extension of your firmware, it should be `.RDY` now.
## FAQ
#### The file is showing up with the extension `.ERR`
This can occur during the programming process if any of the checks in the bootloader fail. This is often triggered by anti-virus software or using a non-Windows host OS.
First, try just copying the file a second time.
1. Attach the iron in DFU mode.
2. Copy the `.hex` file to the device.
3. The device disconnects and connects with the `.ERR` file.
4. Copy the same `.hex` file again **⛔ DO NOT TRY AND DELETE THE OLD ONE ⛔**.
5. The device will disconnect and reconnect again.
6. The device _should_ now have the `.RDY` file.
7. You're done.
If this fails and you are on Mac or Linux reading the wiki page about programming can help. There is also a very long issue thread going through all of the different attempts around this too.
If you are on Windows, it's often best to try another computer (friends, work, partners etc.).
#### Device randomly disconnects or does not show up in DFU mode
1. Check if the USB cable you are using has the data pins; test it on another device. There are a surprisingly large number of micro-USB cables that are power _only_.
2. Try other USB ports. Often different USB controllers will interact with the units differently due to design quirks in the Miniware design.
### Alternative bootloader
If you are an advanced user, and you have used `usb-dfu` tools before, or you would like to learn; there is an alternative bootloader for these irons.
This will **NOT** show up as a USB storage drive, but instead show up using a standard DFU protocol device. You can then use dfu tools or GUIs to upgrade the iron using the `.bin` files that are posted to the releases page.
To install this alternative bootloader, follow the instructions [here](https://github.com/Ralim/IronOS-dfu/blob/mainline/docs/Bootloader.md).
Note that this is only recommended for users who know what they are doing. If you don't understand how this works, please don't flash this.
In the development of this firmware, there are three _types_ of firmware released.
These are the "Main" stable releases, which generally have high confidence in being bug free.
Release candidates are released slightly more often, and these are generally perfectly fine for everyday use. These are released early to allow for translation checking and for wonderful people to help spot bugs and regressions.
Finally, there are the "mainline" builds, which are built from the main git branch.
These are built on every change and can be found on the Actions tab (see below).
### Main release
Main releases are made to the [releases page](https://github.com/Ralim/IronOS/releases).
Download the zip file that matches your model of soldering iron and extract it.
Select the appropriate file type for your unit, in general Miniware devices need `.hex`, Pinecil V1 needs `.dfu`, and Pinecil V2 needs `.bin`.
Flash according to details below.
### Bleeding edge / latest
For the _latest_ code, you will need to download the zip file from the artifacts page on the build for what you want.
Head to the [Actions](https://github.com/Ralim/IronOS/actions) page and then select the run for the appropriate branch you would like.
In general you probably want `master`.
Once you click on a run, scroll down to the "Artifacts" section and then click on your model to download a zip file.
Then this works the same as a production release (use the correct file).
# Pinecil V1
- The MCU used in Pinecil supports usb-dfu. Reference [Pinecil Wiki](https://wiki.pine64.org/wiki/Pinecil) for hardware and firmware instructions.
- Recommended Updater for Windows/MacOS: [Pine64 Updater](https://github.com/pine64/pine64_updater) is an easy-to-use GUI app. It is fast and automatically fetches the newest stable version of IronOS from GitHub. It can also be used to load custom boot logo art.
- Recommended Updater for Linux/MacOS: [PineFlash](https://github.com/Spagett1/PineFlash) is an easy-to-use GUI app. It is fast and automatically fetches the newest stable version of IronOS from Github. It can also be used to load custom boot logo art.
- Troubleshooting: if you have issues using the Pine64 Updater or your install fails, please go to troubleshooting tips below.
- The [Pinecil Wiki](https://wiki.pine64.org/wiki/Pinecil) is a great resource for all things Pinecil.
- Community chat: if troubleshooting doesn't work, then join the Pine64 > Pinecil channel [here](https://wiki.pine64.org/wiki/Pinecil#Live_Community_Chat). There are knowledgeable members in Discord/Telegram/Matrix. Discord has a bridge bot connection to Telegram and Matrix so that all pine64 volunteers/members can see advice for Pinecil and related items or just get tips on which power supply to purchase.
- One advantage of Pinecil is that you cannot permanently damage it doing a firmware update (because DFU is in ROM); an update could render Pinecil temporarily inoperable if you flash an invalid firmware. But no worries, simply re-flashing with a working firmware copy will fix everything.
- USB-C cable is required to do an update. Generally, all USB controllers work, but some hubs have issues, so it is preferred to avoid USB hubs for updates.
- Alternate Update Methods: if your OS is not currently supported by the [Pine64 Updater](https://github.com/pine64/pine64_updater) or it does not meet your needs, i.e., you want to install a beta version, the below manual methods may be used.
## Linux and Mac
### Steps
⛔ Do not use the DC barrel jack while updating firmware or you may destroy your PC. ⛔
1. Highly recommend updating `dfu-util` to the newest version before starting.
2. Download and extract the firmware package from GitHub [IronOS Releases](https://github.com/Ralim/IronOS/releases).
3. Enter DFU mode: press and hold (`-`) button at the back of the iron before you connect the USB-C cable.
4. Connect USB to PC, and USB-C to back of Pinecil, keep holding (`-`) button down.
5. Once the USB cable is connected at two ends, wait ~10 seconds more, then release the (`-`) button.
6. The screen will stay **black/off** to indicate the Pinecil is in DFU mode. This is normal.
7. Using `dfu-util` you can flash the firmware using a command line like this:
```
dfu-util -D Pinecil_EN.dfu
```
Choose the file name from the folder with the appropriate 2-letter country code for your chosen language (i.e., EN = English).
### Troubleshooting:
- If you get a message stating that `More than one DFU capable USB device found!` when running the above command you probably have an old version of `dfu-util` installed. Might be worth updating. You can still install on the old version, but you will have to specify which DFU interface to flash to. Running the command `dfu-util -l` will show you if there are several DFU devices detected. Example:
In this example we see that more than one part of the Pinecil is detected as a DFU interface and we need to specify which one we want to flash to. We want the `Internal Flash` so in this case we can use `alt=0` to identify which interface to target. The command would then look like this:
```
dfu-util -D Pinecil_EN.dfu -a 0
```
- Note: if you use an older release of `dfu-util` and do not see `alt=0, name="@Internal Flash /0x08000000/128*001Kg"` when running `dfu-util -l` you likely will not be able to update without first updating 'dfu-util'.
- If your update is crashing part-way into the update, there is sometimes an issue with older/fussy USB controllers (they can show up/disappear/then show up again)
- Try a direct connection to the USB port, do not use a USB hub, and use shorter cable. If possible, pick a port connected to the main board.
- Switch to a different PC/Laptop and use different ports. USB-C ports are recommended but some have also reported having a fussy C port.
- Hold down the (-) button for the entire firmware update, do not release until near the end.
-`DC Low` message: a pc/laptop cannot fully power Pinecil, it generally can only get 5 V (non-PD) to communicate for firmware updates and Pinecil will report 'DC Low'. This is normal.
- If `dfu-util` aborts with an error like
```
dfu-util: Cannot open DFU device 28e9:0189 found on devnum 42 (LIBUSB_ERROR_IO)
```
and `dmesg` reports USB errors like these
```
kernel: usb 1-1: reset full-speed USB device number 42 using xhci_hcd
kernel: usb 1-1: device descriptor read/64, error -71
kernel: usb 1-1: device descriptor read/64, error -71
kernel: usb 1-1: reset full-speed USB device number 42 using xhci_hcd
kernel: usb 1-1: device descriptor read/64, error -71
kernel: usb 1-1: device descriptor read/64, error -71
kernel: usb 1-1: reset full-speed USB device number 42 using xhci_hcd
kernel: usb 1-1: Device not responding to setup address.
kernel: usb 1-1: Device not responding to setup address.
kernel: usb 1-1: device not accepting address 42, error -71
```
then try to disable USB autosuspend.
This can be done with a set of udev rules specifically for the Pinecil:
⛔ Do not use the DC barrel jack while updating firmware or you may destroy your PC. ⛔
1. Using command line `dfu-util` is similar to above for Linux / Mac.
2. Highly recommend updating `dfu-util` to the newest version.
3. Download and extract the firmware package from GitHub [IronOS Releases](https://github.com/Ralim/IronOS/releases).
4. Enter DFU mode: press and hold (-) button at the back of the iron (do not release).
5. Connect USB to PC, and USB-C to the back of Pinecil, keep holding (-) button down.
6. Screen will stay **black/off** to indicate the Pinecil is in DFU mode. This is normal.
7. After the USB cable is connected at both ends, wait ~10 seconds more, then release the (-) button.
8. Open PowerShell or Command window.
9. Change to the directory of the unzipped firmware files
10. Using `dfu-util,` flash the firmware using a command like this:
```
dfu-util -D Pinecil_EN.dfu
```
- If you have errors, see Troubleshooting above.
### Option 2: use the GUI tool from chip vendor
### Steps
⛔ Do not use the DC barrel jack while updating firmware or you may destroy your PC. ⛔
1. If you are uncomfortable with the command line, then this chip vendor supplied GUI tool/drivers is an option.
2. Download and extract the firmware package from GitHub [IronOS Releases](https://github.com/Ralim/IronOS/releases).
3. Download both the `GD32 MCU DFU TOOL` and the `GD32 Dfu Drivers`.
- GD32 DFU Tool [here](http://www.gd32mcu.com/en/download?kw=GD32+MCU+Dfu+Tool&lan=en). If the link breaks, search for "GD32 MCU Dfu Tool" at this [link](http://www.gd32mcu.com/en/download/).
- GD32 DFU Drivers [here](http://www.gd32mcu.com/en/download?kw=GD32+Dfu+Drivers&lan=en). If the link breaks, search for "GD32 Dfu Drivers" at this [link](http://www.gd32mcu.com/en/download/).
- Check properties of both downloads, tick Unblock if needed, then Unzip
4. Install the drivers and the GD32 DFU tool (ignore prompts to update the tool).
5. Enter DFU mode: press and hold (`-`) button at the back of Pinecil (do not release).
6. Connect Pinecil to a PC via USB cable (do not release the (`-`) yet).
7. Screen will stay **black/off** to indicate the Pinecil is in DFU mode. This is normal.
8. You may hear a beep from Windows as it connects to Pinecil in DFU mode.
9. If you see windows notification that it `does not recognize USB device`, then you didn't connect, repeat step 3-8.
10. Open the GD32 DFU Tool (ignore prompts to update tool).
11. At the top of the DFU tool, you should see `GD DFU DEVICE 1` appear if you successfully connected Pinecil.
12. If DFU Device box at top is blank, then Pinecil is not connected in DFU mode, repeat steps 3-11.
13. If it has been more than 10 seconds since you connected the USB cable, Release the (`-`) button. (don't use Upload from Device section)
14. Select `Download to device` > Open > Browse to folder you unzipped in step 2.
15. Select the `hex` file for language. English is Pinecil_EN.hex , tick `Verify after download`.
16. Click `OK` at bottom. After a few minutes you will see 0-100%, Download successfully! Click `Leave DFU` at the top.
17. Disconnect Pinecil cable from PC, plug it into a power supply.
18. Do not need to press any buttons, a new screen should appear.
19. To confirm upgrade, hold the minus (`-`) button down for a few seconds, it then shows new firmware version v2.xx.x....date
In the development of this firmware, there are three _types_ of firmware released.
These are the "Main" stable releases, which generally have high confidence in being bug free.
Release candidates are released slightly more often, and these are generally perfectly fine for everyday use. These are released early to allow for translation checking and for wonderful people to help spot bugs and regressions.
Finally, there are the "mainline" builds, which are built from the main git branch.
These are built on every change and can be found on the Actions tab (see below).
### Main release
Main releases are made to the [releases page](https://github.com/Ralim/IronOS/releases).
Download the zip file that matches your model of soldering iron and extract it.
Select the appropriate file type for your unit, in general Miniware devices need `.hex`, Pinecil V1 needs `.dfu`, and Pinecil V2 needs `.bin`.
Flash according to details below.
### Bleeding edge / latest
For the _latest_ code, you need to download the zip file from the artifacts page for the build that you want.
Head to the [Actions](https://github.com/Ralim/IronOS/actions) page and then select the run for the appropriate branch and beta you would like.
In general you probably want `master`.
Once you click on a run, scroll down to the "Artifacts" section and then click on your device model name to download a zip file.
Then this works the same as a production release (use the correct file).
# Pinecil V2
- The MCU in Pinecil V2 is Bouffalo BL706 and does _not_ use usb-dfu for flashing as the previous Pinecil V1 MCU did.
- See the Pinecil Wiki page [here](https://wiki.pine64.org/wiki/Pinecil#Firmware_&_Updates) for instructions.
- The V2 uses the [BLISP flasher](https://github.com/pine64/blisp) to upload the firmware to the MCU.
- The [Pinecil Wiki](https://wiki.pine64.org/wiki/Pinecil) is a great resource for all things Pinecil.
- Community chat: if there are issues updating, then join the Pine64 > Pinecil channel [here](https://wiki.pine64.org/wiki/Pinecil#Live_Community_Chat). There are knowledgeable members in Discord/Telegram/Matrix. Discord has a bridge bot connection to Telegram and Matrix so that all pine64 volunteers/members can see advice for Pinecil and related items or just get tips on which power supply to purchase.
- One advantage of Pinecil is that you cannot permanently damage it doing a firmware update (because BIN is in ROM); an update could render Pinecil temporarily inoperable if you flash an invalid firmware. But no worries, simply re-flashing with a working firmware copy will fix everything.
- USB-C cable is required to do an update. Generally, all USB controllers work, but some hubs have issues, so it is preferred to avoid USB hubs for updates.
- Background on the [BL706 chipset](https://lupyuen.github.io/articles/bl706)
In the development of this firmware, there are three _types_ of firmware released.
These are the "Main" stable releases, which generally have high confidence in being bug free.
Release candidates are released slightly more often, and these are generally perfectly fine for everyday use. These are released early to allow for translation checking and for wonderful people to help spot bugs and regressions.
Finally, there are the "mainline" builds, which are built from the main git branch.
These are built on every change and can be found on the Actions tab (see below).
### Main release
Main releases are made to the [releases page](https://github.com/Ralim/IronOS/releases).
Download the zip file that matches your model of soldering iron and extract it.
Select the appropriate file type for your unit, in general Miniware devices need `.hex` and Pinecil needs `.dfu`.
Flash according to details below
### Bleeding edge / latest
For the _latest_ code, you will need to download the zip file from the artifacts page on the build for what you want.
Head to the [Actions](https://github.com/Ralim/IronOS/actions) page and then select the run for the appropriate branch you would like.
In general you probably want `master`.
Once you click on a run, scroll down to the "Artifacts" section and then click on your model to download a zip file.
Then this works the same as a production release (use the correct file).
# TS100
This is completely safe, but if it goes wrong just put the `.hex` file from the official website ([TS100](https://www.minidso.com/forum.php?mod=viewthread&tid=868&extra=page%3D1) onto the unit and you're back to the old firmware. Downloads for the `.hex` files to flash are available on the [releases page.](https://github.com/Ralim/IronOS/releases) The file you want is called TS100.zip. Inside the zip file (make sure to extract the file before flashing with it) will be a file called `TS100_{Language-Code}.hex`.
Officially the bootloader on the devices only works under Windows (use the built-in File Explorer, as alternative file managers or copy handlers like Teracopy will fail). However, users have reported that it does work under Mac, and can be made to work under Linux _sometimes_. Details over on the [wiki page](https://github.com/Ralim/IronOS/wiki/Upgrading-Firmware).
1. Hold the button closest to the tip (MHP30 the left button on the back), and plug in the USB to the computer.
2. The unit will appear as a USB drive. (Screen will say `DFU` on it.)
3. Drag the `.hex` file onto the USB drive.
4. The unit will disconnect and reconnect.
5. The filename will have changed to end in _.RDY_ or _.ERR_
6. If it ends with _.RDY_ you're done! Otherwise, something went wrong.
7. If it didn't work the first time, try copying the file again without disconnecting the device, often it will work on the second shot.
8. Disconnect the USB and power up the device. You're good to go.
For the more adventurous out there, you can also load this firmware onto the device using an SWD programmer, for easier installation follow the guide at the end of this document.
On the bottom of the MCU riser PCB, there are 4 pads for programming. On v2.51A PCB revision `USB_D+` is shorted to `SWDIO` and `USB_D-` is shorted to `SWCLK` so debugging works without disassembly (attach while staying in the bootloader). Installing [IronOS-dfu](https://github.com/Ralim/IronOS-dfu) is recommended as it allows reliable flashing of binary files with [dfu-util](http://dfu-util.sourceforge.net/).
On some newer TS100 units, the SWD pins are wired up to the USB pins, on older ones they are not sadly.
## Mac
sgr1ff1n (Shane) commented in [issue 11](https://github.com/Ralim/IronOS/issues/11) that upgrading worked on their Mac as per normal:
> I just wanted to say that I was able to update the firmware on my ts100 from the stock version to 1.08 found in this repository using my Mac. I simply followed the same steps however through Finder. I have a MacBook Pro (13-inch, Mid 2012) running Sierra 10.12.4 (16E195).
## Linux
While in the past there were reports of unreliable upgrades, the consensus in [issue 11](https://github.com/Ralim/IronOS/issues/11) is that things work mostly as expected in Linux.
@awigen has contributed a script [flash_ts100_linux.sh](https://raw.githubusercontent.com/Ralim/IronOS/dev/scripts/flash_ts100_linux.sh) that works on Ubuntu 16.04 as well as other distros.
If you want to do it manually (or if the script does not work for some reason) the general procedure is the same as for Windows, the differences are in the way to mount the unit and copy the firmware.
Remember that after flashing, the firmware filename will have changed to end in `.RDY` or `.ERR` or `.NOT` and only `.RDY` means the flashing was successful!
- The unit has to be mounted as `msdos` type (thanks @balrog-kun for having spotted it). You may disable automount, but unmounting the automounted drive and remounting as `msdos` works fine. You do not need to turn off automounting, but you do need to unmount the device with `umount`.
- It is recommended to use an all-caps filename for the firmware, even if successful flashing were done with lower case names.
- Avoid USB hubs, plug directly in your computer.
- If it fails, try again several times without unplugging. Just let it remount.
Example, to be run as root, once the unit has been plugged in DFU mode and auto-mounted:
Device will reboot and automount will rerun if not disabled.
Check the extension of your firmware, it should be `.RDY` now.
## FAQ
#### The file is showing up with the extension `.ERR`
This can occur during the programming process if any of the checks in the bootloader fail. This is often triggered by anti-virus software or using a non-Windows host OS.
First, try just copying the file a second time.
1. Attach the iron in DFU mode.
2. Copy the `.hex` file to the device.
3. The device disconnects and connects with the `.ERR` file.
4. Copy the same `.hex` file again **⛔ DO NOT TRY AND DELETE THE OLD ONE ⛔**.
5. The device will disconnect and reconnect again.
6. The device _should_ now have the `.RDY` file.
7. You're done.
If this fails and you are on Mac or Linux reading the wiki page about programming can help. There is also a very long issue thread going through all of the different attempts around this too.
If you are on Windows, it's often best to try another computer (friends, work, partners etc.).
#### Device randomly disconnects or does not show up in DFU mode
1. Check if the USB cable you are using has the data pins; test it on another device. There are a surprisingly large number of micro-USB cables that are power _only_.
2. Try other USB ports. Often different USB controllers will interact with the units differently due to design quirks in the Miniware design.
### Alternative bootloader
If you are an advanced user, and you have used `usb-dfu` tools before, or you would like to learn; there is an alternative bootloader for these irons.
This will **NOT** show up as a USB storage drive, but instead show up using a standard DFU protocol device. You can then use dfu tools or GUIs to upgrade the iron using the `.bin` files that are posted to the releases page.
To install this alternative bootloader, follow the instructions [here](https://github.com/Ralim/IronOS-dfu/blob/mainline/docs/Bootloader.md).
Note that this is only recommended for users who know what they are doing. If you don't understand how this works, please don't flash this.
In the development of this firmware, there are three _types_ of firmware released.
These are the "Main" stable releases, which generally have high confidence in being bug free.
Release candidates are released slightly more often, and these are generally perfectly fine for everyday use. These are released early to allow for translation checking and for wonderful people to help spot bugs and regressions.
Finally, there are the "mainline" builds, which are built from the main git branch.
These are built on every change and can be found on the Actions tab (see below).
### Main release
Main releases are made to the [releases page](https://github.com/Ralim/IronOS/releases).
Download the zip file that matches your model of soldering iron and extract it.
Select the appropriate file type for your unit, in general Miniware devices need `.hex` and Pinecil needs `.dfu`.
Flash according to details below
### Bleeding edge / latest
For the _latest_ code, you will need to download the zip file from the artifacts page on the build for what you want.
Head to the [Actions](https://github.com/Ralim/IronOS/actions) page and then select the run for the appropriate branch you would like.
In general you probably want `master`.
Once you click on a run, scroll down to the "Artifacts" section and then click on your model to download a zip file.
Then this works the same as a production release (use the correct file).
# TS80 / TS80P
This is completely safe, but if it goes wrong just put the `.hex` file from the official website ([TS80](https://www.minidso.com/forum.php?mod=viewthread&tid=868&extra=page%3D1)/[TS80P](https://www.minidso.com/forum.php?mod=viewthread&tid=4070&extra=page%3D1) onto the unit and you're back to the old firmware. Downloads for the `.hex` files to flash are available on the [releases page.](https://github.com/Ralim/IronOS/releases) The file you want is called TS80.zip or TS80P.zip. Inside the zip file (make sure to extract the file before flashing with it) will be a file called `TS80_{Language-Code}.hex`/`TS80P_{Language-Code}.hex`.
Officially the bootloader on the devices only works under Windows (use the built-in File Explorer, as alternative file managers or copy handlers like Teracopy will fail). However, users have reported that it does work under Mac, and can be made to work under Linux _sometimes_. Details over on the [wiki page](https://github.com/Ralim/TS80/wiki/Upgrading-Firmware).
1. Hold the button closest to the tip (MHP30 the left button on the back), and plug in the USB to the computer.
2. The unit will appear as a USB drive. (Screen will say `DFU` on it.)
3. Drag the `.hex` file onto the USB drive.
4. The unit will disconnect and reconnect.
5. The filename will have changed to end in _.RDY_ or _.ERR_
6. If it ends with _.RDY_ you're done! Otherwise, something went wrong.
7. If it didn't work the first time, try copying the file again without disconnecting the device, often it will work on the second shot.
8. Disconnect the USB and power up the device. You're good to go.
For the more adventurous out there, you can also load this firmware onto the device using an SWD programmer, for easier installation follow the guide at the end of this document.
On the USB port, `USB_D+` is shorted to `SWDIO` and `USB_D-` is shorted to `SWCLK` so debugging works without disassembly (attach while staying in the bootloader). Installing [IronOS-dfu](https://github.com/Ralim/IronOS-dfu) is recommended as it allows reliable flashing of binary files with [dfu-util](http://dfu-util.sourceforge.net/).
## Mac
sgr1ff1n (Shane) commented in [issue 11](https://github.com/Ralim/IronOS/issues/11) that upgrading worked on their Mac as per normal:
> I just wanted to say that I was able to update the firmware on my TS100 from the stock version to 1.08 found in this repository using my Mac. I simply followed the same steps however through Finder. I have a MacBook Pro (13-inch, Mid 2012) running Sierra 10.12.4 (16E195).
## Linux
While in the past there were reports of unreliable upgrades, the consensus in [issue 11](https://github.com/Ralim/IronOS/issues/11) is that things work mostly as expected in Linux.
@awigen has contributed a script [flash_TS100_linux.sh](https://raw.githubusercontent.com/Ralim/IronOS/master/Flashing/flash_TS100_linux.sh) that works on Ubuntu 16.04 as well as other distros.
If you want to do it manually (or if the script does not work for some reason) the general procedure is the same as for Windows, the differences are in the way to mount the unit and copy the firmware.
Remember that after flashing, the firmware filename will have changed to end in `.RDY` or `.ERR` or `.NOT` and only `.RDY` means the flashing was successful!
- The unit has to be mounted as `msdos` type (thanks @balrog-kun for having spotted it). You may disable automount, but unmounting the automounted drive and remounting as `msdos` works fine. You do not need to turn off automounting, but you do need to unmount the device with `umount`.
- It is recommended to use an all-caps filename for the firmware, even if successful flashing were done with lower case names.
- Avoid USB hubs, plug directly in your computer.
- If it fails, try again several times without unplugging. Just let it remount.
Example, to be run as root, once the unit has been plugged in DFU mode and auto-mounted:
Device will reboot and automount will rerun if not disabled.
Check the extension of your firmware, it should be `.RDY` now.
## FAQ
#### The file is showing up with the extension `.ERR`
This can occur during the programming process if any of the checks in the bootloader fail. This is often triggered by anti-virus software or using a non-Windows host OS.
First, try just copying the file a second time.
1. Attach the iron in DFU mode.
2. Copy the `.hex` file to the device.
3. The device disconnects and connects with the `.ERR` file.
4. Copy the same `.hex` file again **⛔ DO NOT TRY AND DELETE THE OLD ONE ⛔**.
5. The device will disconnect and reconnect again.
6. The device _should_ now have the `.RDY` file.
7. You're done.
If this fails and you are on Mac or Linux reading the wiki page about programming can help. There is also a very long issue thread going through all of the different attempts around this too.
If you are on Windows, it's often best to try another computer (friends, work, partners etc.).
#### Device randomly disconnects or does not show up in DFU mode
1. Check if the USB cable you are using has the data pins; test it on another device. There are a surprisingly large number of micro-USB cables that are power _only_.
2. Try other USB ports. Often different USB controllers will interact with the units differently due to design quirks in the Miniware design.
### Alternative bootloader
If you are an advanced user, and you have used `usb-dfu` tools before, or you would like to learn; there is an alternative bootloader for these irons.
This will **NOT** show up as a USB storage drive, but instead show up using a standard DFU protocol device. You can then use dfu tools or GUIs to upgrade the iron using the `.bin` files that are posted to the releases page.
To install this alternative bootloader, follow the instructions [here](https://github.com/Ralim/IronOS-dfu/blob/mainline/docs/Bootloader.md).
Note that this is only recommended for users who know what they are doing. If you don't understand how this works, please don't flash this.
Getting started with IronOS on your Pinecil/TS80/TS80P/TS100.
If your device did not come with IronOS already installed, or if you need to update to the latest version; please see the flashing guide for your device:
It is recommended to update to the newest stable release.
Once your Iron has been flashed, on first power on it _may_ warn you about the system settings being reset.
_Do not panic_; this is 100% completely normal. This is here to note to you that they have been reset to handle the internal structure changing.
If you receive a warning about the accelerometer or USB-PD not being detected, please see [here](https://ralim.github.io/IronOS/HardwareIssues/).
## The Home screen (or idle screen)
This is the landing page of the firmware, from here you can choose to either go into the [settings menu](#Settings-Menu) or go into [soldering mode](#Soldering-Mode).
By default this will show a screen similar to the one below:
Note that this may be drawn mirrored depending on the orientation of your screen (detailed mode shows a different home screen).
The soldering iron symbol on the screen will appear near the tip. This is here to indicate that pressing the button closest to the front of the iron will enter soldering mode.
And naturally, the slider controls icon (or spanner icon in older versions) represents that pressing the button near the rear of the soldering iron will enter the settings menu.
In the settings, you can turn on a detailed idle screen instead. The buttons still function the same, however, the image will be swapped for a text telling you the current status of the iron with extra details.
Depending on how your device is being powered, at right side of the screen, the firmware will either show the voltage your unit is being provided with, a battery icon (if battery mode is enabled) or a power plug icon.
If you see an (**X**) where the soldering iron should be, this indicates that the firmware can't see the tip connected. This could indicate a problem with the iron or tip. First, try removing the tip screw and tip and gently reinstalling both; ensure that the tip is seated all the way back. If the issue persists please see the [hardware issues section](https://ralim.github.io/IronOS/HardwareIssues/).
This OLED screen features burn-in protection; if no buttons or movement have been detected for a while it will automatically blank the screen to reduce burn-in when the iron is left unattended. Any movement or button press will wake the screen.
### Hidden Extras
Additionally to the two icons shown, there are two "hidden" actions that can be performed on this menu.
On devices that do not support profile mode, if you press and hold the button near the tip (`+/A`), this enters the temperature adjustment screen. Normally this is not required; but if you would like to adjust the set temperature _before_ the tip starts to heat, this can be useful.
If you press and hold the button near the rear of the iron (`-/B`), it will take you into the [debug menu](https://ralim.github.io/IronOS/DebugMenu/).
## Soldering Mode
When you press the button to enter the soldering mode, the iron will instantly start to heat up the tip.
The firmware defaults to 320 °C as the set point for the soldering mode, however on this screen you can enter into the adjustment screen by pressing either button.
Pressing and holding the button near the tip will enter **Boost** mode. This allows a temporary override of the set temperature to a higher (or lower) value. This can be useful as a way to force the tip to a higher temperature to drive more wattage into a large joint when the thermal connection is not ideal.
Pressing and holding the rear button will exit soldering mode and land you back at the home screen. You can also do this by pressing both buttons at once and this will also work, this is a bit harder to do but is kept for compatibility with the Miniware firmware.
Pressing and holding **both** buttons at once will enter locked mode, which will prevent the buttons from doing anything. You can in the settings allow boost mode in locked mode optionally. This can be useful if you find yourself hitting the buttons and entering into the temperature adjustment screen by accident.
### Idle Sleep
If the iron detects a period of time without any significant movement, it will enter sleep mode. This is indicated with a screen graphic similar to Zzzz (or text in detailed mode).
In Sleep mode, the temperature of the iron automatically lowers to 150 °C (default), which is just below the melting point of the solder. This helps reduce rate of oxidation and damage to the iron tip. In general, when not using the iron, unplug it or let it sleep to increase the longevity of replaceable tips. The default sleep temperature can be customized.
Simply picking up or moving the iron will wake it back up into soldering mode. You can also press any button and this will also wake the iron up.
#### Optional Hall Effect Feature (Pinecil only):
Pinecil has an unpopulated footprint (U14) for a hall effect sensor (Si7210-B-00-IV). Adding the sensor and placing a neodymium magnet on the holder stand will trigger Pinecil to sleep after it enters the stand, and Zzzz will appear on-screen. The magnet is positioned on the stand in proximity to the sensor/handle which then activates one of 10 user defined settings (0=off, 1=lowest sensitivity, 9=highest sensitivity). Read the Hall Sensor document for [details on installation](https://ralim.github.io/IronOS/HallSensor/).
### Idle Shutdown
If, after entering sleep mode, the iron still does not see movement for a much longer time (default=10 minutes); it will shut down and return to the home screen.
## Profile Mode (MHP30 only)
On devices that support it, a long press on `(+/A)` takes you into profile mode, which initiates the profile selected in the relevant settings.
Profile mode plays out as follows:
1. Check if the temperature is below 55C. If not, you will get a warning and cannot enter profile mode.
2. Preheat by raising the target temperature to the configured preheat temperature with the configured preheat speed.
3. Wait for the device to reach the preheat temperature.
4. Gradually move the target temperature to the configured end temperature of the first phase over the configured duration.
5. Wait for the device to reach the end temperature.
6. Repeat steps 4 and 5 for the next phases until there are no more phases configured.
7. Cool down by lowering the target temperature to 0 with the configured cooldown speed.
8. Once the temperature is below 55C, sound the buzzer (if available) and exit profile mode.
You can manually exit profile mode manually in the same way as the soldering mode, by pressing and holding the rear button or pressing both buttons at once.
## Settings Menu
The settings menu is the most evolving aspect of the firmware, so each option is not documented here. However, do not panic, as every menu option has an on-screen description so you don't _need_ to come back here to figure them all out.
To navigate the menu, the two buttons act separately.
The rear button (`-/B`) is pressed to enter the menu and scrolls down the main options, and the other front button (`+/A`) will enter and change the current option.
To see a description of an option, just wait, and after a few seconds, it will scroll across the screen.
The menu is comprised of a 'main menu' of categories and then sub-items that allow you to adjust parameters.
You can long hold buttons to change through options faster, and there is some acceleration when holding the buttons.
There is a small scrollbar that appears along the right edge of the screen to indicate how far through the current list you are (looks like a dot).
Additionally, this scrollbar will blink rapidly when you are on the last value in a range of a sub-menu. For example, if you are in Motion Sensitivity, which has a range of 0 - 9, it will blink when you are at 9.
I highly recommend taking a few minutes to go through all of the options in the menu to get a feel for what you can change, almost every aspect of the internal system is adjustable to suit your needs.
If you want to start over, simply go to Advanced settings > Restore default settings, confirm using the front (`+/A`) button. This sets all menu items to defaults, and keeps the same version firmware.
In Sleep mode, the iron automatically lowers the temperature to 150 °C (default). This default was chosen as it is just below the melting point of many solders. A stand-by lower temperature helps reduce the rate of oxidation and prevents damage to iron tips. In general, when not using the iron, unplug it or let it sleep to increase the longevity of replaceable tips. The default sleep temperature can be customized.
Simply moving the iron or pressing any button will wake it back up into soldering mode.
### Optional Hall Effect Feature (Pinecil only):
Inside the [Sleep Menu](https://ralim.github.io/IronOS/Settings/#setting-sleep-temp) is an additional type of sleep setting. Pinecil has an unpopulated footprint (**U14**) for a hall effect sensor, Silicon Labs **Si7210-B-00-IV**. After installing the hall effect sensor (HES), it is possible to auto-trigger Pinecil to enter sleep mode when it enters the stand, and _Zzzz_ will appear (or text in detailed mode). This could be a fun enhancement for any Pinecil and adds a feature typically only found in more expensive high-end irons. The HES is available at many electronic stores for ~$2-$6.
After installing the HES on the PCB, place a magnet on the stand close enough to the sensor to activate one of ten user selectable settings.
- 0=off, 1=1000, 2=750, 3=500, 4=250, 5=150, 6=100, 7=75, 8=50, 9=25 (9 has the highest sensitivity to magnets)
- Setting of 1 might be used if you solder on PCBs with magnets and do not wish Pinecil to auto-sleep constantly. A very strong/large magnet would be required on the stand to activate the sleep mode if you use setting 1.
- Setting of 9 would be useful if you only had a small magnet and are not concerned about Pinecil falsely triggering sleep mode near magnetized items/tools.
- Actively watch the _hall_ number change while you slowly move the magnet around to seek the best locations & whether you have too many or too few magnets. Position the magnet(s) where you have the highest hall number will ensure consistent sleep mode when you place the iron in the stand. This requires some experimenting.
- [See debug menu for how to display the _Hall_ number](https://ralim.github.io/IronOS/DebugMenu/)
- Note that the sensor is physically located near the copper contacts for the tip at the front of the handle. [Reference Schematics U14](https://files.pine64.org/doc/Pinecil/Pinecil_schematic_v1.0a_20201120.pdf).
- Neodymium magnets are recommended. If using small magnets, 2-3 may be required, but too many could also be detrimental.
- Positioning/type/quantity of magnets is important for best results. Sometimes too many magnets breaks the effect by distorting the magnetic field **[as seen in this demo video](https://www.youtube.com/shorts/afkqKwCX00I)**. The video shows magnets at the top of the stand, and the pinecil goes correctly into Zzzz with _only_ those magnets. When more magnets are added at the side, the Pinecil did not go to sleep, which is contrary to the goal. See the PDF below for details on magnetic fields with SI7210-B.
- Orientation of North and South faces of magnets is important to increase reaction of the hall sensor [see data sheet SI7210-B-00-IV](https://www.silabs.com/documents/public/application-notes/an1018-si72xx-sensors.pdf).
\*: Please note: these soldering irons do *NOT* contain DC/DC converters. This means that your power at the tip is a function of the supplied voltage. Just because the iron "supports" running at a wide range of voltages, you should always use a voltage near the upper limit where possible. It is highly recommended to use a PD adapter where possible as this allows the iron to _know_ the limitations of your supply. The marked irons can only turn the tip on and off in software, this means that they can't control the maximum power drawn from the supply. This is why when using PD the iron may select a lower voltage than your power supplies maximum. This is to prevent your power supply failing from over current. For more information about power management underhood, please, [see the related documentation section](https://ralim.github.io/IronOS/Power/).
While we would love everything to work perfectly, sometimes that just doesn't happen.
Please do not email maintainers directly, these will generally be ignored.
Keep issue discussions to GitHub issues or the discussions page so that the whole community can help and work together.
## No Accelerometer detected
If your iron was previously working, this could be a bug (and we are very sorry). Please check the currently open and recently closed issues to check if anyone else has run into this. You can try going back to a release on the firmware to test if this is a new issue before opening an issue.
If this is a new iron, also feel free to open an issue if you don't see any; a vendor _could_ have changed the model of the accelerometer on us without warning _again_. In which case, support should come shortly.
If your iron is new, there is a slim chance your accelerometer may be DOA and need replacement.
**Note this warning will only be shown the first few times until settings are reset**
## No USB-PD IC detected
Generally, this means either something went very awry in the firmware, or the chip is not answering as would normally be expected. Try rolling back to an earlier release to confirm if the issue still persists then the device may need repair. If you have some form of seller protection/support, you most likely want to reach out to this to be safe. If you don't, you can always attempt to replace the IC yourself. As of writing both the TS80P and Pinecil use the FUSB302.
**Note this warning will only be shown the first few times until settings are reset**
## No tip detected
If your tip is not being detected, the most likely cause is that the heater element inside the tip has been damaged from over-temperature, being dropped or bad luck. As the heater coil is part of the temperature measurement circuit neither will work if it's damaged.
The best way to see if this is the case is to measure the resistance across the contacts to the tip using a multimeter.
you are expecting to see measurements in the range of 4-10 ohms. Anything higher than 10 ohms is _generally_ an issue.
## Iron will not heat up and displays a high temperature
Check the Rtip and CHan numbers ([see debug menu](https://ralim.github.io/IronOS/DebugMenu/)). Extremly high CHan is suspect to a problem with the cold junction compensation temperature sensor.
For Pinecil V1, inspect near U10 which is the TMP36 sensor ([see issue here](https://github.com/Ralim/IronOS/issues/1234)). You may be able to reflow/resolder the TMP36 chip at U10 to correct a weak solder joint.
If it worked on older firmware, but not on 2.16+, weak solder joints are suspect. The newer firmware runs the ADC a bit faster to keep tighter control of the tip temperature. Normally this wont cause an issue as the output from the TMP36 is powerful enough to keep up without any issue. But if you have a weak or cold solder joint this could cause issues.
If the CHan is extremely high, and reflowing the temperature sensor does not resolve the issue; inspect the pins in the main MCU, possibly try giving them a light squeeze to the board while watching CHan.
If you have a different device, follow the same logic and locate the temperature sensor on your device.
- Bootup logo's moved to their own IronOS-Meta repo
- New Vietnamese translation (limited due to screen size)
- Fixes for SC7A20 in TS80(P)
- Updated translations
- Better Instructions/documents
## V2.17
### Big changes
- Indicate status of VBus for modding Pinecil (debug menu)
- Better hall effect sensor sensitivity adjustment (larger range with more steps)
- Temperature increment will "round" to nearest multiple of increase amount
- Build setup migrated to Alpine (You can now build in docker easily, and on PinePhone/PinePhonePro)
- -> Removed proprietary compiler for Pinecil RISCV now all uses normal gcc
- -> Removed using the arm specific build of gcc for the one that alpine ships (Miniware devices)
- Logo generator python script creates `.dfu` files for ease of use with Pinecil
- Upgrades to translations
- Support for new GD32103 based TS100 units turning up on the market
- Raw hall effect reading now shows in the Pinecil debug menu
- Fixed automatic orientation for newer TS80P's with the SC7 accelerometer
- User interface slight changes
- New `metadata.zip` file to allow the Pine Updater to automatically fetch information on releases
### Notes
- VBus mod detection may not play well with all PPS chargers. If your iron reboots when you view this in the debug menu its not a fault. ([#1226](https://github.com/Ralim/IronOS/issues/1226))
-`metadata.zip` is only designed for use by automatic software, ignore it for normal use
- More details on Pinecil VBus mod coming via other channels.
- Hall effect sensor is not fitted to Pinecil's by default, you have to fit this yourself if you want the feature
- Tweaks to the Accelerometer code means the drivers are slightly more fussy. If you run into any issues let us know in the discussion or issues.
- -> Release has been updated to build `e065be3` after one bug with the BMA223 was found.
## V2.16
* Overhaul of the Timer+ADC setup with help from @sandmanRO
* Overhaul of the PID with help from @sandmanRO
* Settings _should_ now upgrade in place to future versions, with resets only happening to new/changed settings
* Shows error if tip runaway (failed temperature sensor) is detected
* USB-PD now has a timeout, to allow forcing QC3 negotiation to start faster
* QC3 Voltages are now adjustable to user desired setpoint
* Added a small tolerance to allow "overvoltage" on QC3 above unit specifications.
* * Please note: Doing this is entirely at your own risk!
* New Advanced view that is much nicer to use and a very good daily driver option from @Mel-kior
* OLED brightness and contrast thanks to @alvinhochun
* Scrollbar is fixed so it doesnt jump around when menus are shown/hidden
* Moved to `.dfu` files from `.bin` to make flashing commands easier
* Every language had translation updates I believe
* Romanian language added
## V2.15
## Feature upgrades:
* MHP30 support
* Multi-lingual firmware combinations now exist for Pinecil
* More fine grained voltage controlled options
* USB-PD improvements (version one and two)
* More configuration options for power pulse
* All font / character encoding has been very reworked
* More translation updates than one can count
* More languages 😱
### MHP30
The MHP30 is a small reflow station from Miniware.
Thanks to a massive amount of help from @g3gg0 this firmware brings the beginnings of support for this unit.
Also kudo's to @Vinigas and @GoJian for helping with testing.
This is not a _final_ version I'm sure, but this is a working, usable version of firmware support.
Programs the same as any one Miniware unit using drag and drop.
**Note: The boot logo scripts will need updates for this unit, so not supported yet.**
The flood doors are now open for feature requests for this unit :)
## V2.14
- Fixing auto rotation bug in the LIS accelerometer in the TS80/TS80P
- Adds support for two new accelerometers
-- SC7A20 (Future Pinecil batch) #786
-- MSA301 (Newer TS80P) #761
- Add warnings if accelerometer or USB-PD IC's are not detected #752
-- Only shows for first few boots, to help catch unsupported models
- Fixed cooling down blink to be sane speed #769
- Cleanup of threads and slightly faster power negotiation #790
- Updates to flashing scripts #775
- Documentation updates all over the place (and the wiki was given a cleanup)|
- Updates to makefile #792#787
- Cleanup the folder name of the source code #800
- clang-format spec setup #801
## V2.13
- First _official_ Pinecil release
- All of the wire for Pinecil releases added
- Updated Translations
- Delay accelerometer to help with entering sleep on startup
- Dual speed PWM to help with power limit control
- Improve heat up time
- Adds locking mode
- Improved docs all over the place
- Repo rename occured TS100 -> IronOS
- Hall effect sensor support added (not fitted in Pinecil but optional)
- QC 20V support for Pinecil
- CI upgrades for faster builds
- Fixed bug with accelerometer model on Pinecil
- Rework of all of the temperature curves for better accuracy
## V2.12
- Only released as pre-release
- [TS80P] Improvements to the PD negotiation to handle a few more adapters cleanly
- Pause on the last item in a list
- Clean up the menu (removed both enables and settings, so that you can turn things off easier)
- Removing the very old single line menu style.
## V2.11
- First TS80P support
- Added in a USB-PD driver stack for the FUSB302
- Fixed some graphical glitches
## V2.10
- GUI polish (animations and scroll bars)
- Power pulse to keep power supplies alive
- Adjustable tip response gain
## V2.09
- Adjustable steps in temperature adjustment
- Git hash now in build string
- Adjustable language to set if US units are available or not
- Some minor QC3 improvements
## V2.08
- Fixes auto start in sleep mode
- Power limiters
## V2.07
- QC fixes
- Cosmetic fixes for leading 0's
## V2.06
- Warning on settings reset
- Temp temp re-write
- Display calibration offset
- Hide some leading 0's
- Menu timeouts
## V2.05
- Language updates
## V2.04
- GUI updates
## V2.03
- Support for new accelerometers
## V2.02
- Adds small font
## V2.01
- Newer settings menu
## V2.00
- Complete re-write of the low layer system to use the STM32 HAL for easier development
- This allowed easier setup for the new ADC auto measuring system
- Better tip PWM control
- Moved to FreeRTOS for scheduling
- Complete re-write from blank
- Added detailed screen views
- Added smaller font for said screen views
## V1.17
- Added blinking cooldown display
- Allowed smaller sleep timeout values
- New font!
- Automatic startup option
## V1.16
- Added automatic rotation support
- Added power display graph
## V1.15
- Added support for a custom bootup logo to be programmed via the DFU bootloader
## V1.14
- Changed input voltage cutoff to be based on cell count rather than voltage
## V1.13
- Swapped buttons for menu to prevent accidentally changing first menu item
- Added auto key repeat
## V1.12
- Increases sensitivity options to be 1\*9 with 0 off state
- Fixes issue where going from COOL \*> soldering can leave screen off
## V1.11
- Boost mode
- Change sensitivity options to be 1\*8
## V1.10
- Adds help text to settings
- Improves settings for the display update rate
## V1.09
- Adds display modes, for slowing down or simplifying the display
## V1.08
- Fix settings menu not showing flip display
## V1.07
- Adds shutdown time to automatically shutdown the iron after inactivity
## V1.06
- Changes H and C when the iron is heating to the minidso chevron like images
## V1.05
- Adds ability to calibrate the input voltage measurement
## V1.04
- Increased accuracy of the temperature control
- Improved PID response slightly
- Allows temperature offset calibration
- Nicer idle screen
## V1.03
- Improved Button handling
- Ability to set motion sensitivity
- DC voltmeter page shows input voltage
## V1.02
- Adds hold both buttons on IDLE to access the therometer mode
- Changes the exit soldering mode to be holding both buttons (Like original firmware)
This firmware supports a user created bootup logo.
By default, there is _not_ one included in the firmware. This means that once flashed they generally stay. If you want no logo again, you would have to flash a blank image to the bootup logo.
## Generating the Logo files
There are community logo's already converted and ready to use in [IronOS-Meta/releases](https://github.com/Ralim/IronOS-Meta/releases).
Download the zip for Pinecil or Miniware and then install using the instructions in the Flashing section below.
If you want to make custom art then it needs to be converted with a Python script. The script and other needed files are in [IronOS-Meta](https://github.com/Ralim/IronOS-Meta/). Go to that folder, then it is easiest to select the green Code button (upper right), then Download Zip. This way you get all the files you need and some extras. You only need what is inside Boot Logos. Put your custom image inside the Boot Logos folder with all python script files already there.
The Python script converts an image passed into it on the command line into both a `.hex` file and a `.dfu` to be uploaded to the iron in DFU mode. The image can be in color and any size, but it will be resized and converted to 1-bit color. However, it looks best if you create a 96x16 image (Png or Bmp) in any image editor and color the pixels black & white manually.
The converter requires at least Python3 and Pillow apps. Follow online instructions for installing Python and Pillow.
For Windows, it is recommended to use Windows PowerShell instead of Command.
Open Powershell (run as administrator), type python to install it, it will open microsoft store where you can install it free.
Go back to Powershell and install Pillow. What works can vary, but this command may work:
python -m pip install Pillow
or
python3 -m pip install pillow
If the above does not work, see [this page](https://stackoverflow.com/a/20061019/6705343) on StackOverflow about installing Pillow.
Now that Python and Pillow are successfuly installed, you can convert an image.
Go back to Powershell and type this command (change infile.png to the name of your image):
-`python img2logo.py infile.png out -m` for Miniware
-`python img2logo.py infile.png out -p` for Pinecil
Run `python img2logo.py --help` to see available options. Replace the word python with python3 if you have multiple versions of python installed.
Note: make sure your image file is in the same folder as script files (img2logo.py, output_dfu.py, output_hex.py).
## Flashing the Logo
### Miniware (TS100/TS80/TS80P)
Upload the HEX file to the iron in DFU mode and, if the file's extension changes to .RDY, your custom splash screen should show up on startup.
You perform this the same way as if you were flashing a new firmware, and all the existing notes around this apply.
If you have flashed the `IronOS-dfu` alternative bootloader, you should use the `.dfu` files instead
### Pinecil V1
For Pinecil V1, we require using dfu-util to flash the logo art (Pinecil does not use hex).
[Pine64 Updater](https://github.com/pine64/pine64_updater/releases) is the easiest way to load the Bootup logo onto Pinecil as it already includes the necessary DFU library. Connect Pinecil to a PC, and open the Updater the same as updating firmware.
Select Custom > Browse to the DFU image file you just made > Update to install.
The bootup logo is stored in a separate location than the IronOS firmware and you do not have to worry about it changing or breaking the IronOS.
You could also use dfu-util and use Command line to install it.
In this firmware for these soldering irons, all settings are adjustable on the device itself. This means a computer is **not** required to change any setting.
## Soldering mode
In this mode the iron works as you would expect, pressing either button will take you to a temperature change screen.
- Use each button to go up/down in temperature. Pressing both buttons exits the temperature menu (or wait 3 seconds and it will time out).
- Pressing both buttons or holding the rear button (`-/B`) will exit Soldering Mode.
- Holding the front button (`+/A`) will enter [Boost mode](https://ralim.github.io/IronOS/Menu/#boost-mode) (if enabled).
## Profile mode (MHP30 only)
In this mode, accessible by long pressing `(+/A)`, the configured profile will be initiated.
- You cannot adjust the temperature or enter boost mode.
- Pressing both buttons or holding the rear button (`-/B`) will exit Profile Mode as well.
## Settings mode
This mode allows you to cycle through all the options and set custom values.
The menu is arranged so that the most often used settings are first.
- The rear button (`-/B`) cycles through the main options. (declines i.e. Additional warning to proceed.)
- The front button (`+/A`) either enters a submenu or changes the selected option. (accepts i.e. Additional warning to proceed.)
- If the device is unplugged before exiting the main menu settings will not be saved.
- To exit the menu, either continue to press (`-/B`) or hold it until the idle screen is reached. Alternatively, you could press (`-/A`) & (`-/B`) simultaneously to exit the submenu and once more to exit the main menu.
- If you idle on a setting (i.e., don't press any buttons), after 3 seconds, the screen scrolls a brief description (mini help guide).
- Enter submenus using the front button (`+/A`) if you are going to change it or wish to view it.
- Scrolling through the all options of a submenu will return you back to its entry location.
### Calibrating input voltage
Due to the tolerance on the resistors used for the input voltage divider, some irons can be up to 0.6 V out on the voltage measurement.
Please calibrate your iron if you have any issues with the cutoff voltage. This calibration is not required if you have no issues.
Note that cutoff messages can also be triggered by using a power supply that is too weak and fails under the load of the iron.
To calibrate your iron:
1. Measure the input voltage with a multimeter and note it down.
2. Connect the input to your iron.
3. Enter the settings menu
4. Under the Advanced submenu
5. Select the calibrate voltage option
6. Use the front and back buttons to adjust the displayed voltage to minimize the error to your original measurement
7. Press both buttons at the same time to Save and Exit to the menu
### Calibrate Tip CJC
This calibrates the [Cold Junction Compensation](https://ralim.github.io/IronOS/Temperature/) *(CJC)* for the tip. This is normally not needed unless you have an issue with tip temperature or your tips are wearing out prematurely. Changing tip lengths does not necessarily mean a calibration is needed. Check first that your tips are not defective and measured resistance is close to specifications *[Pinecil / TS100 short tips **6.2 Ω**, long tips **8 Ω**, TS80/P ~**4.5 Ω**]*.
What this is for:<br>
Some tips have an offset on their readings which causes issues, i.e. The actual temperature of the tip is much higher than displayed. Follow the steps below to calibrate this.
Caution:<br>
If the method below is not followed, the iron could be worse than before calibration. If you need to repeat the method, first unplug and let the handle/PCB cool down to room temperature.
1. Connect power to your device.
2. Go to **`Advanced Settings`** using (`-/B`) and press (`+/A`) to select it. Use (`-/B`) to scroll to **`Calibrate CJC at next boot`** and confirm with (`+/A`).
3. Accept the *'warning text'* with (`+/A`).
3. Exit the settings menu as usual by pressing and holding (`-/B`).
4. Unplug you device.
5.**Critical: Make sure a tip is attached & wait until the tip & handle are at room temperature.** (Wait a reasonable amount of time after having used the device.)
6. Power the device and ideally keep it out of your hands (You know it might get warm.).
7. The display shows **`calibrating ....`** for a short time while the device measures and compares the tip and handle voltages.
8.**`Calibration done!`** is displayed for 3 seconds. The new offset value can later be viewed in the **`Debug menu`**.
9. Calibration is done and the device proceeds booting.
Note: offsets are dependant on your tip, temperature sensor, and the MCU. It's the culmination of tolerances at rest. Typical values are 700-1000 range. This is only designed to be used at boot while cold (ambient / room temperature), as temperatures drift apart as soon as power is connected. Doing this reading repeatedly could result in wide varience of the offset number and/or incorrect calibration.
### Boost mode
This allows you to change the front button (`+/A`) to become a boost button when you hold it for > 2 seconds. A boost button changes the soldering temperature for short periods. For example, when soldering a big joint and you need a much higher temperature, hold the (`+/A`) button down and it will temporarily increase the temperature to your 'boost' setting. When you release the button, the temperature will gradually go back to the normal set temperature.
The boost temperature is set in Soldering settings.
These soldering irons use a FET to switch the power to the soldering iron tip. This is a P-MOSFET and its controlled via a small transistor circuit, which in turn is controlled via the MCU (i.e., STM32). The MCU controls this PWM output proportional to the output from the PID control loop running in the software.
To measure the tip temperature in the iron, the iron has a small op-amp connected across the terminals at the cold end of the tip. This is setup to measure the voltage across the same terminals that are used to power the tip. In order to read the very small voltage generated by the [thermocouple cold junction](https://ralim.github.io/IronOS/Temperature/), the iron's output must be turned off for a moment.
Once the output is turned off (via the FET), the system has a recovery time as the tip capacitance discharges and the op-amp exits saturation. After this delay period, the MCU's ADC (analog-to-digital converter) samples the output of the op-amp 8 times quickly and then sets a flag to turn the PWM output back on.
This enforces a small dead time in the output signal while this occurs, so there is a balance between sampling the temperature often to maintain a stable tip temperature control and sampling less often to increase the maximum power deliverable to the tip ([see Complexity of measurement](https://ralim.github.io/IronOS/Temperature/#complexity-of-measurement)).
## Power sources
Supported by IronOS hardware may use different power sources (chargers/powerbanks/battery packs) with different standards & protocols (QC/PD/etc). For more information collected by the community on that, please, [see the related documentation section](https://ralim.github.io/IronOS/PowerSources/).
Supported by IronOS hardware may use different power sources (chargers/powerbanks/battery packs) with different standards & protocols (QC/PD/etc). This document contains information collected by the community with tested power sources.
This is not ads but first hands-on experience results from real users since some chargers/powerbanks regardless labels on the box may not fully support what's declared!
## QC(3)
### Compatible Devices (QuickCharge for TS80/P)
The following table is the list of compatible device and remarks when powering up the TS80 through it for both stock firmware from MiniDso and IronOS. The list of devices below are primarily taken from [#349](https://github.com/Ralim/ts100/issues/349#issuecomment-449559806)
| Device Name | Stock FW | IronOS FW |
|-------------|:--------:|:---------:|
| Anker PowerCore II Slim 10000 Powerbank | Not Working | Good |
| Polaroid PS100 Powerbank (https://polaroid.com/products/ps100) | Good | Good |
| Xiaomi 10000mAh Mi Power Bank Pro (PLM03ZM) | Good | Unknown |
| Xiaomi 10000mAh Mi Power Bank 2i (PLM09ZM) | Good | Good |
| Xiaomi 20000mAh Mi Power Bank 3 (PLM07ZM) | Unknown | Good Type A, Bad Type C |
| [ZeroLemon ToughJuice](https://www.amazon.com/dp/B01CZR3LT2/) 30000mAh PD/QC2.0 Power Bank | OK\*\* (20sec t/o) | OK\*\* (20sec t/o?) |
| [URUAV XT-60 to USB module](https://www.banggood.com/URUAV-XT-60-to-USB-Charger-Converter-Support-3S-6S-LiPo-Battery-10_5V-32V-Input-3V-20V-Output-45W-Max-Fast-Charging-Adapter-For-RC-Racing-Drone-p-1475876.html) | Unknown | Good |
\* Need further tests on newer firmware
\*\* Most Power Banks shut down if current draw drops below 50mA, assuming that charging is complete and avoiding overcharging. Custom firmware is designed to avoid this until it enters Zzzz mode.
### DIY QC3.0
You may also build your own QC3.0 power source that requires this little [thing](https://www.tindie.com/products/soubitos/qualcomm-qc2-3-diy-8-32vin-36-12vout-3a-max/) and have at least 3S lithium packs or any input voltage from 8 to 32V.
You can also go for an [alternate module](https://www.banggood.com/DC-Buck-Module-12V24V-to-QC3_0-Single-USB-Mobile-Charging-Board-p-1310585.html) which has at least one good review of it.
**DISCLAIMER:**_**We do not hold any responsibility for accidents that happen when building your own QC3.0 power source!!!**_
## PD
The following additional table is the list of devices compatible with hardware which requires Power Delivery support (>= 30W). Devices from the list have been successfully tested & used with TS80P in PD mode. Please, keep in mind that:
- PD can be provided only through usb-c <-> usb-c cable;
- not only a charger but a cable itself should be capable to carry higher wattages.
### Compatible Devices (PowerDelivery for TS80P)
| Device Name | IronOS FW |
|-------------|:---------:|
| Traver Charger QC09 (45W max)\* | OK |
| Xiaomi AD65GEU Mi 65W Fast Charger with GaN Tech (AD65GEU, 65W max) | OK |
\* Comes as an _option_ for extra price in the package with TS80P from [official store](https://aliexpress.com/item/4000764937427.html) or from [NovelLife store separately](https://aliexpress.com/item/4001316262433.html) on AliExpress.
Please, DO NOT BUY cheap "fast chargers with QC/PD support" for a few dollars online (i.e., less than ~10$): if you check reviews, then you see that they are phonies - even if you get lucky, you probably get 5V/1A max from them.
<!-- This is an automatically generated file. DO NOT EDIT. Edit gen_menu_docs.py instead -->
# IronOS Settings Menu
The below breaks down the menu's and what each setting means.
## Menu Categories
In the menu there are a few main categories that are used to keep the list manageable.
### Category: Power settings
Menu for settings related to power. Main settings to do with the input voltage.
### Category: Soldering settings
Settings for soldering mode, such as boost temps, the increment used when pressing buttons and if button locking is enabled.
### Category: Sleep mode
Settings to do with power saving, such as sleep mode, sleep temps, and shutdown modes.
### Category: User interface
User interface related settings, such as units.
### Category: Advanced settings
Advanced settings. Misc catchall for settings that don't fit anywhere else or settings that require some thought before use.
## Settings
These are all of the settings possible in the menu.
**Not all settings are visible for all devices.**
For example, the TS100 does not have USB-PD settings.
When using the device, if unsure you can pause (press nothing) on a setting and after a short delay help text will scroll across the screen.
This is the "on device help text".
### Setting: Power source
When the device is powered by a battery, this adjusts the low voltage threshold for when the unit should turn off the heater to protect the battery.
On device help text:
Set cutoff voltage to prevent battery over-drain. (DC 10V) (S=3.3V per cell, disable PWR limit)
### Setting: Sleep temp
Temperature the device will drop down to while asleep. Typically around halfway between off and soldering temperature.
On device help text:
Tip temperature while in "sleep mode"
### Setting: Sleep timeout
How long of a period without movement / button-pressing is required before the device drops down to the sleep temperature.
On device help text:
Interval before "sleep mode" starts (s=seconds | m=minutes)
### Setting: Shutdown timeout
How long of a period without movement / button-pressing is required before the device turns off the tip heater completely and returns to the main idle screen.
On device help text:
Interval before the iron shuts down (m=minutes)
### Setting: Motion sensitivity
Scale of how sensitive the device is to movement. Higher numbers == more sensitive. 0 == motion detection turned off.
Should the device show an 'advanced' view on the idle screen. The advanced view uses text to show more details than the typical icons.
On device help text:
Display detailed info in a smaller font on idle screen
### Setting: Display orientation
If the display should rotate automatically or if it should be fixed for left- or right-handed mode.
On device help text:
R=right-handed | L=left-handed | A=automatic
### Setting: Boost temp
When the unit is in soldering mode. You can hold down the button at the front of the device to temporarily override the soldering temperature to this value. This SETS the temperature, it does not ADD to it.
On device help text:
Tip temperature used in "boost mode"
### Setting: Start-up behavior
When the device powers up, should it enter into a special mode. These settings set it to either start into soldering mode, sleeping mode or auto mode (Enters into soldering mode on the first movement).
On device help text:
O=off | S=heat to soldering temp | Z=standby at sleep temp until moved | R=standby, heat-off until moved
### Setting: Cooldown flashing
If the idle screen should blink the tip temperature for attention while the tip is over 50°C. Intended as a 'tip is still hot' warning.
On device help text:
Flash temperature reading at idle if tip is hot
### Setting: Calibrate CJC at next boot
Note:
If the difference between the target temperature and the measured temperature is less than 5°C, **calibration is NOT required at all**.
This is used to calibrate the offset between ADC and Op-amp of the tip **at next boot** (Ideally it has to be done at boot, before internal components get warm.). If the checkbox is set, the calibration will only be performed at the next boot. After a successful calibration the checkbox will be unchecked again! If you need to repeat the calibration however, you have to set the checkbox *again*, unplug your device and let it cool down to room/ambient temperature & power it up, ideally while it sits on the desk.
Also, the calibration will only take place if both of the following conditions are met:
- The tip must be installed.
- The temperature difference between tip and handle must be less than 10°C. (~ ambient / room temperature)
Otherwise, the calibration will be performed the next time the device is started and both conditions are met, unless the corresponding checkbox is unchecked.
Hence, never repeat the calibration in quick succession!
On device help text:
Calibrate tip Cold Junction Compensation at the next boot (not required if Delta T is < 5°C)
### Setting: Restore default settings
Resets all settings and calibrations to factory defaults. Does NOT erase custom user boot up logo's.
On device help text:
Reset default settings for this firmware ver.
### Setting: Calibrate input voltage
Enters an adjustment mode where you can gradually adjust the measured voltage to compensate for any unit-to-unit variance in the voltage sense resistors.
On device help text:
Start VIN calibration (long press to exit)
### Setting: Detailed solder screen
Should the device show an 'advanced' soldering view. This is a text-based view that shows more information at the cost of no nice graphics.
On device help text:
Display detailed info in a smaller font on soldering screen
### Setting: Scrolling speed
How fast the description text scrolls when hovering on a menu. Faster speeds may induce tearing, but allow reading the whole description faster.
On device help text:
Speed info text scrolls past at (S=slow | F=fast)
### Setting: QC voltage
This adjusts the maximum voltage the QC negotiation will adjust to. Does NOT affect USB-PD. Should be set safely based on the current rating of your power supply.
On device help text:
Max QC voltage the iron should negotiate for
### Setting: PD timeout
How long until firmware stops trying to negotiate for USB-PD and tries QC instead. Longer times may help dodgy / old PD adapters, faster times move onto PD quickly. Units of 100ms. Recommended to keep small values.
On device help text:
PD negotiation timeout in 100ms steps for compatibility with some QC chargers
### Setting: Power limit
Allows setting a custom wattage for the device to aim to keep the AVERAGE power below. The unit can't control its peak power no matter how you set this. (Except for MHP30 which will regulate nicely to this). If USB-PD is in use, the limit will be set to the lower of this and the supplies advertised wattage.
On device help text:
Maximum power the iron can use (W=watt)
### Setting: Swap + - keys
Swaps which button increments and decrements on temperature change screens.
On device help text:
Reverse assignment of buttons for temperature adjustment
### Setting: Temp change short
Factor by which the temperature is changed with a quick press of the buttons.
On device help text:
Temperature-change-increment on short button press
### Setting: Temp change long
Factor by which the temperature is changed with a hold of the buttons.
On device help text:
Temperature-change-increment on long button press
### Setting: Power pulse
Enables and sets the wattage of the power pulse. Power pulse causes the device to briefly turn on the heater to draw power to avoid power banks going to sleep.
On device help text:
Intensity of power of keep-awake-pulse (watt)
### Setting: Hall sensor sensitivity
If the unit has a hall effect sensor (Pinecil), this adjusts how sensitive it is at detecting a magnet to put the device into sleep mode.
If locking the buttons against accidental presses is enabled.
On device help text:
While soldering, hold down both buttons to toggle locking them (D=disable | B=boost mode only | F=full locking)
### Setting: Minimum voltage
When powered by a battery, this adjusts the minimum voltage per cell before shutdown. (This is multiplied by the cell count.)
On device help text:
Minimum allowed voltage per battery cell (3S: 3 - 3.7V | 4-6S: 2.4 - 3.7V)
### Setting: Anim. loop
Should the menu animations loop. Only visible if the animation speed is not set to "Off"
On device help text:
Loop icon animations in main menu
### Setting: Anim. speed
How fast should the menu animations loop, or if they should not loop at all.
On device help text:
Pace of icon animations in menu (O=off | S=slow | M=medium | F=fast)
### Setting: Power pulse delay
Adjusts the time interval between power pulses. Longer gaps reduce undesired heating of the tip, but needs to be fast enough to keep your power bank awake.
On device help text:
Delay before keep-awake-pulse is triggered (x 2.5s)
### Setting: Power pulse duration
How long should the power pulse go for. Some power banks require seeing the power draw be sustained for a certain duration to keep awake. Should be kept as short as possible to avoid wasting power / undesired heating of the tip.
On device help text:
Keep-awake-pulse duration (x 250ms)
### Setting: Language: EN English
Changes the device language on multi-lingual builds.
On device help text:
Current firmware language
### Setting: Screen brightness
Display brightness. Higher values age the OLED faster due to burn-in. (However, it is notable that most of these screens die from other causes first.)
On device help text:
Adjust the OLED screen brightness
### Setting: Invert screen
Inverts the entire OLED.
On device help text:
Invert the OLED screen colors
### Setting: Boot logo duration
Sets the duration for the boot logo (s=seconds).
On device help text:
Set Boot logo duration (off | s=seconds | infinity)
The soldering irons use a modified N-type thermocouple in the tip to measure the tip temperature.
This is constructed for free by using a different type of metal to join one of the rings to the heating coil. This effectively creates a free temperature sensor for very low cost and construction difficulty.
The downsides of this are twofold; one, it is made using non-optimal metals and has a non-constant temperature response; and two, as this uses the same connections as the heating current, you can't measure the temperature while you are heating the tip.
## How a thermocouple works (brief)
[Thermocouples use a junction of two dissimilar metals](https://www.youtube.com/watch?v=v7NUi88Lxi8) to create a very small amount of power (microvolts). This can then be measured and used with a known transfer function to derive the temperature of the junction.
This has some fairly large limitations, but it also has the benefit of being extremely cheap.
Conventionally a thermocouple is created using two dissimilar metals that join, and then the other ends of these metals are terminated to copper contacts. These copper contacts are also part of the construction of the thermocouple and are referred to as the cold junction.
As there are these extra two joins between the thermocouple wires and the copper; these also have properties of their own in their reactions with temperature.
If the cold junction is held at 0 degrees Celsius, then their effect is considered to be null, and so they can be ignored. However, in the real world the joins to copper are often at room temperature, and as such the measured voltage from the thermocouple must be compensated to remove the influence of these joints. This process is often called cold junction compensation.
Every time in the circuit there is a join between two different metals, then a small thermocouple is created, this means that _every_ soldered connection is also one.
## How these irons implement the temperature reading
If you analyse one of the open circuit schematics (Pinecil, TS100, TS80) they all use the same approximate formula.
This consists of an op-amp that is connected directly across the heating connections to the tip, and a separate handle temperature sensor.
When the iron is **not** heating the tip, the microcontroller uses the ADC to read the output from the op-amp. This produces a voltage that _should_ be linear to the temperature of (tip-handle). This value is then offset compensated (to remove ADC+op-amp offsets), and then converted into a temperature delta in °C/K. This temperature delta can then be added to the handle temperature to derive the tip temperature in degrees Celsius.
Depending on the construction of the tip, the lookup values used for converting the tip reading in µV into °C/K varies. It is worth noting, however, that TS100 and Pinecil tips are approximately the same as the Hakko T12 tips. (In @Ralim's testing, to within measurement error). This makes sense as the T12 tips are an excellent and cheap design for Miniware to mimic in making the TS100 in the first place.
## Implications of this
### Reading accuracy vs Heating performance tradeoff
Because the tip can only be measured when the unit is not heating, the more often the tip is measured (for finer temperature control) the less time the unit can spend heating up the tip. This means that for fast heat up and fine temperature control the firmware now implements two speeds to the controller loop. During heating up the system runs fewer temperature measurements and instead allows the tip to spend more time burning power. Once the unit is up to temperature, the rate of taking temperature readings is doubled to allow for faster reaction times.
### Tip heat up lag time
As the temperature sensor is a part of the heater coil inside of the tip (or very close by, not entirely certain); the temperature reading is of the _inside_ of the tip, rather than the outside. The outside temperature is the most critical for the user as this is where the solder is actually melting and performing work.
The PID controller in the firmware is tuned to be slightly underdamped and thus more "jumpy" than some people would expect. This is based on the theory that if the inside of the tip is seeing the temperature drop; the outside temperature has dropped more and so we should overcompensate until they equalise.
This is why sometimes the temperature may flick around a little during use but the tip temperature itself is quite stable. The thermal mass of the tip smooths these small amounts out nicely for the user. Though seeing larger jumps on some tips than others _may_ indicate that the tip does not have optimal internal thermal bonding between the heater coil and the tip itself.
The firmware uses the theory that these irons are aimed more to the power users territory than most, so it tries to _not_ hide the actual temperature. Some soldering iron controllers hide the actual measurement once you are within a certain tolerance of this. For example, on a digital Weller unit that Ralim has, if set to 350 °C, it will regulate to within around +/- 3°C but not indicate you are outside of the margin of error until you exceed +/- 5°C. This gives the illusion that it's holding the temperature perfectly when in actuality it's moving around as well.
Given enough time (3-5 seconds) with no external cooling, the inside and outside temperatures of the tip will be equal. When testing the tip temperature accuracy try to allow time for the system to stabilise.
### Complexity of measurement
The firmware in these irons does a *best-effort* of calculating an accurate temperature. As always there is a tradeoff between perfect accuracy and firmware complexity and setup. These irons are built down to a cost; expecting accuracy greater than 1% is not really an option as the voltage reference is only 1% accurate at best. So _all_ measurements are affected by its accuracy. The low-cost chips used in the irons do not come calibrated from the factory so we do not have an internal calibration we can use to try and measure this inaccuracy.
The firmware only accounts for [cold junction compensation](https://www.tegam.com/what-exactly-is-cold-junction-compensation/) and then treats the remaining error as being a constant offset.
While the error is small, it is actually composed of both a constant offset as well as an offset that is linear to the handle temperature.
This offset that is linear to handle temperature is as of current not modelled into the firmware and is assumed to be constant. This is generally *close enough* as once the unit is in use, the handle temperature is usually within 10 °C as the components inside warm-up from use. This means that this error is "relatively" constant once the unit is being used.
`However, this can cause odd behaviour when the tip temperature ~= room temperature. It can cause some jumping and movement in the readings when attempting to control the tip to sub 100 °C.`
This is a known tradeoff that is made as the irons intended use case means that it will spend most of its time above 150 °C, at which point these errors are no longer the dominant error sources in the system.
At the present time the main way of performing translations is to open a PR to this repository.
All translations are stored as `json` files in the repository. Currently there is ongoing work to look into a more user friendly method of editing translations than these but for now these are reliable.
You can create a pull request with the new / updated json configuration file, and this will include this language into the new builds for the firmware.
For testing you can build locally and test of course; but if you dont want to figure out the build environment; you can just open a PR and github will build the firmware for you using the _actions_ feature.
This means that once you have a github account you can perform all of your edits inside Github should this be desired.
Translations are _NOT_ accepted via issues/discussions or email.
If your device is not operating as expected; and you are within the manufacturer support window, please first contact your manufacturer and RMA / warranty your device.
If your iron is not working as expected, [the Debug menu](https://ralim.github.io/IronOS/DebugMenu/) exposes internal measurements to help you narrow down the root cause of the issue.
Alongside all of these, issues with the soldering of the main MCU could cause all of these as well; and should always be checked.
The tip is important for the operation of your iron. T100 and Pinecil tips are around 8 ohms, and TS80(P) tips are around 4.5 ohms.
You are welcome to open discussions about issues as well, or if you bought your Pinecil from an official store; use the [Pinecil community chat](https://wiki.pine64.org/wiki/Pinecil#Community_links) for support.
But it is helpful to do some basic diagnostics first just in case the issue is easily fixed.
The **VAST** majority of issues are poor soldering or cold solder joints.
If you can open up your iron, give it a good look at all the connection points, and use another iron to reflow any suspicious ones, this can fix most issues.
## Tip Shorted warning
If you are powering up a device that supports tip resistance detection (TS101 and Pinecilv2 as of present), the firmware checks the readings of the raw tip resistance and sorts these into three "bins". `8 ohm tips`, `6.2 ohm tips` and `tip-shorted`. The tip resistance is used when negotiating USB-PD and in thermal calculations.
The `tip-shorted` option is selected if your tip is measured to be abnormally small. This could indicate a failed driver mosfet or a failed tip.
When this warning is shown; heating will be disabled to protect from damage. As trying to heat a shorted tip can damage the iron itself.
It is best to take out your tip and manually measure and verify the tip's resistance. It should be 6-8 ohms (depending on tip type). When measuring resistances this small some multimeters can struggle. If you have access to a current limited bench power supply, you can try doing a 4 wire measurement by measuring the voltage drop on the tip while applying a known current. `(R=V/I)`.
If the tip measures correctly you may have a damaged driver mosfet; it would be ideal to open your iron and test the mosfet is operating correctly.
If after both of these checks everything looks as expected, feel free to open a discussion on IronOS to talk about the issue (Or for Pinecil the community chat can be a much faster response).
## High tip temp reading when the tip is cool
If you are finding the tip is reading high; the first fields to check in the Debug menu are `RTip` and `CHan`.
-`RTip` is the raw tip reading in μV; at cool this should be around 700-1000 for larger tips and ~1500 for smaller tips (TS80's)
-`CHan` is the temperature of the temperature sensor on the PCB in degrees Celsius \* 10. So 29 °C ambient should read as 290
### RTip is out of spec
`RTip` will over-read on bad contacts or no tip inserted.
If `RTip` is overreading, you may have one of the following:
- Partially stuck on main MOSFET
- Slow reacting main MOSFET driver transistor
- Damaged Op-Amp
- Poor soldering on the Op-Amp circuitry
- No tip inserted or tip that is not connecting correctly
If `RTip` is under-reading you most likely have issues with the Op-Amp or the tip. The signal should be pulled high by hardware (reading hot), so this often means the MCU is not reading the signal correctly. Check MCU soldering.
### CHan is out of spec
CHan reading comes directly from the cold junction compensation temperature sensor.
This is usually a TMP36 (Pinecil V1), or an NTC thermistor (MHP30, TS80P, Pinecil V2).
If `CHan` is reading low:
- Check the connection from the MCU to the handle temperature sensor.
- Check the power pin connection on the TMP36
- Check pullup resistor on the NTC thermistor
- Check no bridged pins or weak shorts on the signal to nearby pins on MCU or temperature sensor
- Reflow/resolder the aforementioned components
If `CHan` is reading higher
- Check ground connections on the sensors
- Check no bridged pins or weak shorts on the signal to nearby pins on MCU or temperature sensor
- Reflow/resolder the aforementioned components
## No display OR dots on the display
If when you power up your iron you get no display, the first test is to (carefully) attempt to heat the tip.
Press the front button (`+/A`) on your device and check if the tip heats up.
If the tip does not heat up, it is worth trying to reflash the firmware first in case it is corrupted.
The main failure mode of the OLED display module is usually poor soldering on the OLED display cable to the main PCB.
As this is soldered by hand generally, it's the most prone to failures.
If you have a poor connection or a floating pin, you can end up with a state where the screen works _sometimes_ and then freezes or only works on some power cycles. It might work on very old versions of IronOS but not the newest ones. You could try to reflow the pins for the OLED. On 96x16 screens, carefully peel it back from the adhesive and reflow the solder on the pins. If needed, replacement Oled screens are common and low cost.
As the OLED runs on an I2C bus, there are pull up resistors on the SDA and SCL pins. It is worth checking these as well, while they don't often fail, issues with these can cause _weird_ display issues.
## Tip heats when not in heating mode
⚠️ DISCONNECT YOUR TIP ⚠️
Most likely you have either a blown MOSFET or shorted pin.
Check the MOSFET and also its driver transistor.
The firmware will not enable the tip until you are in soldering mode.
## Accelerometer not detected
Your Iron may have a new accelerometer that is not supported yet (happens every year or so) OR there is a soldering issue with the accelerometer (reflow/resolder).
# IronOS - Flexible Soldering iron control Firmware
The firmware implements all of the standard features of a 'smart' soldering iron, with lots of little extras and tweaks.
I highly recommend reading the installation guide fully when installing on your iron. And after install just explore the settings menu.
For soldering irons that are designed to be powered by 'smart' power sources (PD and QC), the firmware supports settings around the negotiated power and voltage.
For soldering irons that are designed to be powered by batteries (TS100 & Pinecil), settings for a cutoff voltage for battery protection are supported.
Currently **31** languages are supported. When downloading the firmware for your soldering iron, take note of the language code in the file name.
This project is considered stable & feature complete for everyday use with a supported device, _so please suggest any feature improvements you would like!_
_This firmware does **NOT** support the USB port while running for changing settings. This is done through the onscreen menu only. Logos are edited on a computer and flashed like firmware._
| Device | DC | QC | PD | EPR | BLE | Battery | Recommended |
\*Please note that Miniware started shipping TS100's using cloned STM32 Chips. While these do work with IronOS, their DFU bootloader works terribly, and it is hard to get it to successfully flash larger firmware images like IronOS without timing out. This is the main reason why the TS100 is **_no longer recommended_**.
## Getting Started
To get started with IronOS firmware, please jump to [Getting Started Guide](https://ralim.github.io/IronOS/GettingStarted/).
But the [TL;DR](https://www.merriam-webster.com/dictionary/TL%3BDR) is to press the button near the front of the iron to heat up. Use the button near the back of the iron to enter the settings menu.
Long hold the rear button in soldering mode to exit back to the start screen.
## Installation
For notes on installation for your device, please refer to the flashing guide for your device:
But the _generic_ [TL;DR](https://www.merriam-webster.com/dictionary/TL%3BDR) is to:
- [download firmware from here](https://github.com/Ralim/IronOS/releases) for the correct model with suitable language support;
- put a device into DFU/bootloader mode (usually by keep holding A/+/front button while connecting a device to power source to power device on);
- flash the firmware by drag-n-drop the firmware file using a file manager of your OS **or** using a separate flashing tool.
## Key Features
- PID style iron temperature control
- Automatic sleep with selectable sensitivity
- Motion wake support
- All settings exposed in the intuitive menu
- (TS100) Set a voltage lower limit for Lithium batteries so you don't kill your battery pack
- (TS80) Set 18 W or 24 W settings for your power bank
- (TS80P) Automatically negotiates appropriate PD and falls back to QC mode like TS80
- (Pinecil) Supports all 3 power modes (PD, QC, DC In).
- (Pinecilv2) Supports USB-PD EPR for 28V operation.
- Improved readability Fonts, supporting multiple languages
- Use hardware features to improve reliability
- Can disable movement detection if desired
- Boost mode lets you temporarily change the temperature when soldering (i.e. raise the temperature for short periods)
- (TS100/Pinecil) Battery charge level indicator if power source set to a lipo cell count
- (TS80/TS80P/Pinecil) Power bank operating voltage is displayed
- [Custom boot up logo support](https://ralim.github.io/IronOS/Logo/)
- Automatic LCD rotation based on the orientation
## Menu System
This new firmware uses a new menu system to allow access to the settings on the device.
When on the main screen and having the tip plugged in, the unit shows a pair of prompts for the two most common operations.
- Pressing the button near the tip enters the _soldering mode_
- Pressing the button near the USB end enters the _settings menu_
- When not in _soldering mode_, holding down the button near the tip will enter _soldering temperature adjust mode_ (This is the same as the one in the _soldering mode_, but allows to adjust the temperature before heating up), in _soldering mode_ however this will activate _boost mode_ as long as you hold down the button.
- Holding down the button near the USB end will show the _[debug menu](https://ralim.github.io/IronOS/DebugMenu/)._ In _soldering mode_ this ends the heating.
Operation details are over in the [Menu information.](https://ralim.github.io/IronOS/Menu/)
## Feedback
If you would like to:
- report any issue related to IronOS
- request a feature
- provide some suggestion
then you can [fill this form](https://github.com/Ralim/IronOS/issues/new/choose) using github account\*.
And if you would like to:
- ask more generic question about IronOS/supported hardware/something you're curious about/etc.
- reach out community to chat with
- share your soldering & DIY skills
- share some interesting finding
- share useful related hardware/software with others
or _anything_ like that, then you can use forum-like [Discussions here](https://github.com/Ralim/IronOS/discussions).
\*: You may need to create it first if you don't have one - it's free of charge.
Please edit this template and fill out all the information you can (where relevant). Failure to provide essential information can delay the response you receive.
* **I'm submitting a ...**
- [ ] Bug report
- [ ] Feature request
- [ ] Translation
* **Do you want to request a *feature* or report a *bug*?**
* **What is the current behavior?**
* **What is the expected behavior?**
* **If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem**
***Steps to reproduce:***
1.
2.
3.
***Video of problem if hard to reproduce***
* **What is the motivation / use case for changing the behavior?**
* **What are you running:**
On the idle screen, you can hold the settings button and it will show you the firmware version.
- Firmware Version: 2.x
- PCB Version: (1/2)
- Power Supply (Voltage and Current Rating) :
* **Other information**
If submitting graphics to go on the iron, please use BMP or PNG files over JPG.
@echo " * compile builds of IronOS firmware for all supported models inside that container"
@echo " * export generated binaries to \"scripts/ci/artefacts/\" local directory"
@echo "Patches are welcome. Happy Hacking!"
@echo
# target to list supported targets with additional info
list:
@echo
@echo "Supported top-level targets:"
@echo " * help - shows short basic help"
@echo " * list - this output"
@echo " * docker-shell - start docker container with shell inside to work on IronOS with all tools needed"
@echo " * docker-build - compile builds of IronOS for supported models inside docker container and place them to \"scripts/ci/artefacts/\""
@echo " * docker-clean - delete created docker container (but not pre-downloaded data for it)"
@echo " * docs - generate \"site\"/ directory with documentation in a form of static html files using ReadTheDocs framework and $(MKDOCS_YML) local config file"
@echo " * docs-deploy - generate & deploy docs online to gh-pages branch of current github repo"
@echo " * tests - run set of checks, linters & tests (equivalent of github CI IronOS project settings for push trigger)"
@echo " * clean-build - delete generated files & dirs produced during builds EXCEPT generated docker container image"
@echo " * clean-full - delete generated files & dirs produced during builds INCLUDING generated docker container image"
@echo ""
@echo "NOTES on supported pass-trough targets:"
@echo " * main Makefile is located in source/ directory and used to build the firmware itself;"
@echo " * this top-level Makefile supports to call targets from source/Makefile;"
@echo " * if you set up development environment right on your host, then to build firmware locally, you can just type right from here:"
A short(ish) video that goes through every single menu option in the firmware is available [over here](https://www.youtube.com/watch?v=WlnpboYfxNk).
This video was created on an earlier 1.x version of the firmware, so alot has changed and a new video will be coming soon for the 2.x fork.
# IronOS - Flexible Soldering iron control Firmware
*This firmware does **NOT** support the usb port while running for changing settings. This is done through the onscreen menu only. Logos are edited using the tool or python script and uploaded in DFU mode.*
_This repository was formerly known as TS100, it's the same great code. Just with more supported devices._
*Please note that when running the iron off a Lithium battery pack, the Iron is only rated to 24V input. So using a fully charged 6S battery *slightly* exceeds this rating, and is done so at your own risk.
Please calibrate your irons voltage reading when you are using a lithium battery after any firmware upgrades.*
Originally conceived as an alternative firmware for the TS100, this firmware has evolved into a complex soldering iron control firmware.
## Features
* PID iron temperature control
* Automatic sleep with selectable sensitivity
* Motion wake support
* Settings menu on the unit
* Set a voltage lower limit for Lithium batteries so you dont kill your battery pack
* All settings saved to flash when you exit the menu
* Improved readability Fonts
* Use hardware features to improve reliability
* Can disable movement detection if desired
* Calibration of the thermocouple offset
* Boost mode lets you temporarily change the temperature when soldering (ie raise temperature for short periods of time)
* Battery charge level indicatior if power source set to a lipo cell count.
* Custom bootup logo support
* Automatic LCD rotation based on orientation
The firmware implements all of the standard features of a 'smart' soldering iron, with lots of little extras and tweaks.
I highly recommend reading the installation guide fully when installing on your iron. And after install just explore the settings menu.
## Upgrading your ts100 iron
For soldering irons that are designed to be powered by 'smart' power sources (PD and QC), the firmware supports settings around the negotiated power and voltage.
For soldering irons that are designed to be powered by batteries (TS100 & Pinecil), settings for a cutoff voltage for battery protection are supported.
This is completely safe, if it goes wrong just put the .hex file from the official website onto the unit and your back to the old firmware. Downloads for the hex files to flash are available on the [releases page.](https://github.com/Ralim/ts100/releases) The file you want is called *ts100.hex* unless you want the translations, they are ts100_*language short name*.hex.
Currently **31** languages are supported. When downloading the firmware for your soldering iron, take note of the language code in the file name.
Officially the bootloader on the iron only works under windows. However, users have reported that it does work under Mac, and can be made to work under Linux*sometimes*. Details over on the [wiki page](https://github.com/Ralim/ts100/wiki/Upgrading-Firmware).
This project is considered feature complete for use as a soldering iron,_so please suggest any feature improvements you would like!_
1. Hold the button closest to the tip, and plug in the USB to the computer.
2. The unit will appear as a USB drive.
3. Drag the .hex file onto the USB drive.
4. The unit will disconnect and reconnect.
5. The filename will have changed to end in .RDY or .ERR
6. If it ends with .RDY you're done! Otherwise something went wrong.
7. Disconnect the USB and power up the iron. You're good to go.
_This firmware does **NOT** support the USB port while running for changing settings. This is done through the onscreen menu only. Logos are edited on a computer and flashed like firmware._
For the more adventurerous out there, you can also load this firmware onto the device using a SWD programmer.
On the bottom of the MCU riser pcb, there are 4 pads for programming.
There is a complete device flash backup included in this repository. (Note this includes the bootloader, so will need a SWD programmer to load onto the unit). Please do not use the backup of the bootloader for anything malicious, its only saved here for those who are tinkering with their iron and decide to replace it.
| Device | DC | QC | PD | EPR | BLE | Tip Sense | Recommended Purchase | Notes |
_Tip Sense_ refers to the device being able to choose between the 'usual' TS100 or Hakko T12 style tips and Pine64's custom shorter tips which have lower resistance and allow for more power. This is N/A for TS80/TS80P as there is only one model of tip for them.
This firmware uses a different method of updating the bootup image.
This removes the need for emulating a USB drive on the iron just to allow for a bootup image to be setup.
There are further instructions on the [wiki](https://github.com/Ralim/ts100/wiki/Logo-Editor). Instructions are kept on the wiki so that users can update the information if they find extra helpful information.
_Recommended Purchase_ is only referring to if you are buying a **new** device. Of course all the devices listed are supported and will work excellently for years to come.
## New Menu System
The TS101 and S60 feature a higher resolution OLED than other devices. Work is ongoing to support this fully, for now a cropped view is usable.
\*PinecilV1 stopped being manufactured a long time ago now, all models for sale online are generally clones (or old stock). Vendors are trying to sell these for more than Pine64 sells the V2 for now. Thus the V1 is **_no longer recommended_**.
\**Please note that Miniware started shipping TS100's using cloned STM32 Chips. While these do work with IronOS, their DFU bootloader works terribly, and it is hard to get it to successfully flash larger firmware images like IronOS without timing out. This is the main reason why the TS100 is **_no longer recommended_**.
\**\*TS80 is replaced by TS80P. Production ramped down a long time ago and it's just existing stock clearing the system. It's marked not recommended being optimistic that people might pause and buy the far superior TS80P instead. This is the main reason why the TS80 is **_no longer recommended_**.
## Getting Started
To get started with IronOS firmware, please jump to [Getting Started Guide](https://ralim.github.io/IronOS/GettingStarted/).
But the [TL;DR](https://www.merriam-webster.com/dictionary/TL%3BDR) is to press the button near the front of the iron to heat up. Use the button near the back of the iron to enter the settings menu.
Long hold the rear button in soldering mode to exit back to the start screen.
## Installation
For notes on installation for your device, please refer to the flashing guide for your device:
- (TS100) Set a voltage lower limit for Lithium batteries so you don't kill your battery pack
- (TS80) Set 18 W or 24 W settings for your power bank
- (TS80P) Automatically negotiates appropriate PD and falls back to QC mode like TS80
- (Pinecil) Supports all 3 power modes (PD, QC, DC In).
- (Pinecilv2) Supports USB-PD EPR for 28V operation.
- Improved readability Fonts, supporting multiple languages
- Use hardware features to improve reliability
- Can disable movement detection if desired
- Boost mode lets you temporarily change the temperature when soldering (i.e. raise the temperature for short periods)
- (TS100/Pinecil) Battery charge level indicator if power source set to a lipo cell count
- (TS80/TS80P/Pinecil) Power bank operating voltage is displayed
- [Custom boot up logo support](https://ralim.github.io/IronOS/Logo/)[^bootlogo]
- Automatic LCD rotation based on the orientation
[^bootlogo]: **BOOTUP LOGO NOTICE**:
IronOS supports both a bootup logo _AND_ bootup animations.
However, _**they are no longer included in this repo**_.
**Please, [read the docs](https://ralim.github.io/IronOS/Logo/) for more information**.
## Menu System
This new firmware uses a new menu system to allow access to the settings on the device.
When on the main screen, the unit shows prompts for the two most common operations.
* Pressing the button near the tip enters soldering mode
* Pressing the button near the USB enters the settings menu.
* Holding the button near the tip will enter soldering temperature adjust mode (This is the same as the one in the soldering menu, just to let you edit before heating up).
* Holding the button near the USB end will show the firmware version details.
## Soldering mode
When on the main screen and having the tip plugged in, the unit shows a pair of prompts for the two most common operations.
In this mode the iron works as you would expect, pressing either button will take you to a temperature change screen.
Use each button to go up and down in temperature. Pressing both buttons will exit you from the temperature menu (or wait 3 seconds and it will time out).
Pressing both buttons or holding the button near the USB will exit the soldering mode.
Holding the button at the front of the iron will enter boost mode (if enabled).
- Pressing the button near the tip enters the _soldering mode_
- Pressing the button near the USB end enters the _settings menu_
- When not in _soldering mode_, holding down the button near the tip will enter _soldering temperature adjust mode_ (This is the same as the one in the _soldering mode_, but allows to adjust the temperature before heating up), in _soldering mode_ however this will activate _boost mode_ as long as you hold down the button.
-Holding down the button near the USB end will show the _[debug menu](https://ralim.github.io/IronOS/DebugMenu/)._ In _soldering mode_ this ends the heating.
## Settings Menu
Operation details are over in the [Menu information.](https://ralim.github.io/IronOS/Menu/)
This menu allows you to cycle through all the options and set their values.
The button near the USB cycles through the options, and the one near the tip changes the selected option.
Note that settings are not saved until you exit the menu, and some settings such as screen flip do not apply until a power cycle is applied.
If you leave the unit alone (ie don't press any buttons) on a setting, after 3 seconds the screen will scroll a longer version of the name
* PWRSC -> Power source, select a cell count if using a LiPo, or DC to disable the shutdown. (Sets it to minimum of 10V).
* STMP -> The temperature the unit drops to in sleep mode
* SLTME -> Sleep time, how long it takes before the unit goes to sleep
* SHTME -> Shutdown Time, how long the unit will wait after movement before shutting down completely
* MSENSE -> Motion Sensitivity,0*9,0 means motion sensing is turned off, 9 is most sensitive, 1 is least sensitive (ie takes more movement to trigger)
* ADVDSP -> Enable the advanced display (shows more details)
* DSPROT -> Display rotation mode, Automatic, Left handed or Right handed
* BOOST -> Enable boost mode
* BTMP -> Set the temperature for the boost mode
* ASART -> Automatically start the unit when power is applied (i.e. the unit will go straight into soldering mode)
* CLBLNK -> Blink the screen as an alert when cooling down
* TMP CAL -> Use to calibrate offset on the tip temperature
* RESET -> Use to force a complete reset on exit of the settings menu
* TMPUNIT -> Temperature unit, C or F
### Calibrating input voltage
Due to the tolerance on the resistors used for the input voltage divider, some irons can be up to 0.6V out on the voltage measurement.
Please calibrate your iron if you have any issues with the cutoff voltage.
Note that cutoff messages can also be triggered by using a power supply that is too weak and fails under the load of the iron.
This is more critical than before with the new cell count based cutout voltage.
To calibrate your Iron:
1. Measure the input voltage with a multimeter and note it down.
2. Connect the input to your iron.
3. On the home screen (showing iron symbol), press both buttons simultainiously.
4. The iron will now show the tip temperature.
5. Press the button near the soldering iron tip.
6. The screen will display the measured input voltage.
7. If this is the same as what you measured before skip to step 13
8. Otherwise, press the button near the USB end of the iron
9. The voltage will now slowly blink.
10. Use the buttons to adjust the reading up and down until it reads as close as possible to the voltage you measured earlier.
11. When it is reading as close as possible, press both buttons at once.
12. The screen will go back to just showing the input voltage.
13. Press the button near the tip of the iron to exit back to the live temperature display.
14. Press both buttons at once to exit back to the idle screen.
15. You're done. Enjoy your iron.
### Calibrating tip offset
Some tips will have an offset on their readings, to calibrate this out perform the following steps:
1. Connect power to your iron
2. Make sure the tip is at room temperature (ie. wait for a fair while after using the iron before calibration)
3. Enter the settings menu
4. Scroll down to *TMP CAL*
5. Press the button to change the option (tip button)
6. The display will start to scroll a warning message to check that the tip is at ambient temperature!
7. Press the button near the tip of the iron to confirm.
8. The display will go to "...." for a short period of time as the unit measures the tip temperature and the handle temperature and compares them
9. The display will then go back to *TMP CAL*
10. Calibration is done, just exit the settings menu as normal
11. You're done. Enjoy your iron.
### Boost mode
This allows you to change the front key (one near the tip) to become a boost button when you hold it for > 2 seconds. This allows you to set this button to change the soldering temperature for short periods. For example when soldering a big joint and you want to boost the temperature a bit.
The boost temperature is set in the settings menu.
## Translations
Is your preferred language missing localisation of some of the text?
Translations are stored as `json` files in the Translations folder.
PR's are loved and accepted to enhance the firmware.
## Thanks
If you love this firmware and want to continue my caffine addiction, you can do so here (or email me for other options) : https://paypal.me/RalimTek
If you love this firmware and want to continue my caffeine addiction, you can do so [here](https://paypal.me/RalimTek) (or email me for other options).
I also want to give a shout out to all of the [Fantastic Contributors](https://github.com/Ralim/IronOS/graphs/contributors).
Especially to the following users, who have helped in various ways that are massively appreciated:
Plus the huge number of people who have contributed translations, your effort is massively appreciated.
## Licence
The code in this repository that is based on the STM tools is under a BSD like licence.
The code created by the communitiy is GNU GPLv3.
The FreeRToS is under its own licence.
The code created by the community is GNU GPLv3. Unless noted elsewhere.
Other components such as FreeRTOS/USB-PD have their own licence.
## Commercial Use
This software is provided as-is, so I cannot provide any commercial support for the firmware. However you are more than welcome to distribute links to the firmware, or provide irons with this software on them.
Please do not re-host the files, but rather link to this page, so that there are not old versions of the firmware scattered around. If this firmware does make you money, it would be nice to recieve a donation, however there is no enforcement.
This software is provided as-is, so I cannot provide any commercial support for the firmware.
However, you are more than welcome to distribute links to the firmware or provide irons with this software on them.
Please do not re-host the files, but rather link to this page, so that there are no old versions of the firmware scattered around.
If you would like to contribute a translation, look at the file `translation.c` in the source code.
Currently translations are compiled in at compile time with #defines (nothing complex).
So all you need to do is add another section formatted like the english one that is there and either create a pull request or a github issue for inclusion.
If the glyphs required already exist in the fonts then support should be quick. Otherwise it may take longer for the fonts to be created.
b"Lorem ipsum dolor sit amet, consectetur adipiscing elit. "
b"Ut consequat mattis orci ac laoreet. Duis ac turpis tempus, varius lacus non, dignissim lectus. "
b"Curabitur quis metus luctus, sollicitudin ipsum at, dictum metus. "
b"Cras sed est nec ex tempor tincidunt in at ante. Vivamus laoreet urna eget lectus euismod feugiat. "
b"Duis a massa ac metus pellentesque interdum. Nunc congue, est faucibus convallis commodo, justo nibh sagittis augue, sed tristique urna neque vitae urna. "
b"Donec quis orci et purus imperdiet sollicitudin."
"description":"Επαναφορά στις προεπιλεγμένες ρυθμίσεις"
},
"LanguageSwitch":{
"displayText":"Γλώσσα:\n EL Ελληνικά",
"description":""
}
}
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.