Some chargers have funky PPS.
Plus some do not want EPR be default (even though 28V is safe by designer on PinecilV2).
So take the safest option by default and make it opt-in
* Update documentation to build IronOS in Windows using MSYS2 environment and fix compilation on case-sensitive file systems.
---------
Co-authored-by: Ivan Zorin <ivan.a.zorin@gmail.com>
Access to the inactive union members is an undefined behavior.
`column.whole = (1 << height) - 1;` -- 'whole' is active member here,
`fillArea(OLED_WIDTH - 1, 0, 1, 8, column.strips[0]);` -- but the 'strips'
member accessed here.
Same issue: https://gitlab.com/libeigen/eigen/-/issues/2898
* Update translation_UK.json
Unified statement to one type of translation ("Sleep mode" instead of "Waiting mode")
Corrected "blink" translation
Shortened phrases for statements ("t° у сек"/"градусів на секунду"; "сек"/"секунд","секунди"; "Хв"/"Хвилин","Хвилини")
Traslated soldering tip type selection menu
* source/Makefile: add temp change for demo
* scripts/deploy.sh: add test check for languages
* scripts/deploy.sh: shellcheck sanitization
* source/Makefile: revert changes for the demo
* Documentation/History.md: update version format according to git tag for easiest automation
* Add test check for changelog of the latest stable version
* Add git config permissions routine to test docs via push.yml
* scripts/deploy.sh fixes
* making shellcheck happy due to false negative in deploy.sh
* push.yml: fetch tags for test docs
* push.yml: set fetch depth trying to get tags
* deploy.sh printf debugging
* deploy.sh: remove printf debugging
* push.yml: rename step from check_readme to check_docs to reflect its function
* Added translation into Uzbek
* Temporaly override translation_UZ.json with EN for reference
* Temporaly override translation_UZ.json with EN for reference
* UZ translation: fill text for messages from the original patch
* UZ translation: fill text for menuGroups from the original patch
* UZ translation: fill text for menuOptions from the original patch, part 1
* UZ translation: fill text for menuOptions from the original patch, part 2
* UZ translation: fill text from the original patch
* adapting translation_UZ.json
This should work 😊
---------
Co-authored-by: Ivan Zorin <ivan.a.zorin@gmail.com>
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
* Minor doc updates
* pydoc
* Draft tip selection menu
* Start linking in manual tip resistance
* Enable on Pinecilv1 / TS10x
* Fixup drawing tip type
* Update Settings.cpp
* Rename JBC type
* Add translations
* Handle one tip type
* Refactor header includes
* Fixup translation_IT.json
* Fixing up includes
* Format
* Apply suggestions from code review
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
* Update Documentation/Hardware.md
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
---------
Co-authored-by: = <=>
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
* Add a sleep timeout setting for hall sensor
* Update Settings.h to reorder HallEffectSleepTime to the end
* Update Settings.cpp to reorder HallEffectSleepTime to the end
* add HallEffSleepTimeout to rest of translations
* mix misaligned number in Settings.cpp
* fix clang-format issue in getHallEffectSleepTimeout
* Add T55 to build
* Approx in T55
* Update ThermoModel.cpp
* use PT1000 lookup logic
* Handle no accelerometer
* Setup for temp reading
* Lock max temp
* No movement pin
* Compensate for heater coil resistance change
* Fix min offset for T55
* Fixup font for T55
* Update draw_profile_advanced.cpp
* Update draw_temperature_change.cpp
---------
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
* Create README.md
* Move to new folder
* Migrating
* Migrate Remainder
* format fix (all but one) (#1889)
* Update USBPDDebug_FS2711.cpp
* Delete PrintVoltage.cpp
* Copy in 128x32 template
* Mask drawing for 96x16
* Import #1819
* Update Font.h
* Homescreen
* Update draw_homescreen_detailed.cpp
* Fix oled normal draw for variable height
* Update OLED.cpp
* Draw settings icons
* Update draw_homescreen_simplified.cpp
* Update draw_power_source_icon.cpp
* Fixup oled drawing for fill area
* Update the region fill for mixed heights
* Fix newline height
* FIXUP! Draw icons in settings menu at correct size
* Fix scrollbar
* Update settingsGUI.cpp
* S60(P) Disable auto display rotation
* On tall oled, scroll in 2 line increments
* Bugfix transition L<->R
@discip I take it back, there was a bug :)
* Draw every other one on transitions
* .
* cleanup
* Bootup logo: Draw in centre
* Update OLED.hpp
---------
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
* Use PDMode to decide if we do resistance pad
* Rename PDVpdo to USBPDMode
* Add options for PD Mode
* OLED: Allow soft line-wrap x position
* Add new translation option for menu settings values
* Use new setting value for PD Mode
* Update translations for new menu setting
* Fixup! S60
* black python
Added a message about how to get around windows dialog prompt when copying from NTFS filesystems (Most of what Windows users will be copying from) to FAT which the iron uses.
This is an extremely common problem for Windows users, and I'd like to put in a tested workaround in the guide as it would have saved me about 15 minutes on what would have been a 20 second install.
I believe this will be of similar benefit to most Windows users.
* source/Makefile compatibility with BSD find [#1886]
* Align formatting
* source/Makefile: remove trailing /s from DIR vars to fix build using BSD find/OSX env [#1886]
* Basic Init
* Rought implementation of fs2711 usb pd interface
* Rought implementation of fs2711 usb pd interface
* Still needs work overcurrent protection keeps getting tripped
* New pdo selection logic
* Update push.yml
* Update push.yml
* Update push.yml
* Update Makefile
* Adds PPS
* Removed unused define
* Adds PPS
* Apply suggestions from code review
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* Code review changes
* Added osDelay include
* New line alignment for S60 softwarei2c
* Code review
* Fixes code review stuff
* code review changes
* Change voltage limit to 20 as that's what the device is rated for
* Shortened wait time for usb pd
* Fixed issues that cuase S60P to restart constantly
* fixing minimal OLED brightness
With the current settings, the OLED turns off if the first level is selected.
* Adds protocol to s60p debug menu
* loosened fs2711 protocol selection timing
* Adds PDO register reading to negotiation logic
* Fixes FS2711 timeout issue and cleans up driver
* Adds FS2711 protocol negotiation to power loop
* Removed uneeded define
* Reverts changes to Font.h and adds clang-format comments
---------
Co-authored-by: Ben V. Brown <Ralim@Ralimtek.com>
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* Starting GUI render refactor to be more immediate mode
Update TemperatureAdjust.cpp
.
Cleanup Soldering
Sleep
SolderingProfiles
Soldering Rework
Rough pass GUI
Temp Adjust
Cleanup old OperatingMode
Debug Menu
* Update TemperatureAdjust.cpp
* Roughing some transition work
* Fixup! Hook in the init starter helper
* Better home screen button handler
* FIXUP! Fix typo's
.
* Update SettingsMenu.cpp
* More settings rework
* More settings rendering
* Fixup
* Transitions
Update SolderingProfile.cpp
Hook in transistions
* Update TemperatureAdjust.cpp
* Update push.yml
* Add auto-repeat to settings menu
* Miniware: Use IT for I2C writes
* Update USBPDDebug_HUSB238.cpp
* Force write screen on side animation cancel
.
* Refactor moving down the settings list
* Update settingsGUI.cpp
* Update I2C_Wrapper.cpp
* Update OLED.cpp
* Rework button handling
* Fix PD debug at boot
* Fixup not showing right menu options
* silence some warnings
* Style cleanup
* Fkit use bit-bang I2C for Miniware
* Update GUIRendering.md
* Fixup transition on enter soldering mode
* Save Settings
* Fixes for some animations not running
Dont bail on animations if keypress is still held
* Fixup settings acceleration
* OLED Up animation
* Link up/down on debug meny
* Make all accelerometers I2C bus aware
Update accelerometers_common.h
* Make I2C mag optional
* Miniware -> Only Bit-Bang I2C
* Fixup for scrollbar
FIXUP! Debug menu returns to home screen
FIXUP! Up oled animation
Fix temp exit
* Settings menu -> Both buttons return a menu layer
* Merge fixup
* Update BMA223.cpp
* Re-Enable OLED sleep
* Save Setting on temp adjust exit
* WiP on startup mode
* Some autostart working
* Add hibernation mode & more autostart fixes
* If cant CJC; go to startup
* Hibernate in sleep
* Cleanup scroll indicator
* FIXUP! Ensure startup warnings are linked in
* FIXUP! Ensure we render out temp change before timing out
* Ensure 100ms delay between CJC samples
* Fix not re-calculating menu length on entering menu
* Implement NegotiationinProgress for USB-PD
* Mask heating until PD finishes negotiation
* Fixup staying in hibernate correctly
* Warning timeout
* Show reset settings warning
* Correctly compensate help text start time
* Update GUIThread.cpp
* Update USBPD.cpp
* .
* Fixup sleep time
* Update printSleepCountdown.cpp
* replacing countdown with big plus while in boost mode
* bringing back the + 1 since it was missing when not in boost mode
* Bail on USB-PD check after 3 seconds incase of DC source
* Fix hibernate
* Update PIDThread.cpp
* did center plus symbol (boost mode)
* Big refactor to not make settings increment handler handle the "is last item" return
* Fixup boot logo
* Fix flashing
* Fixup recalculate the menu length on long hold
* Fixup missing menu entries
* Fix junk left on screen after user confirmation
* Re-order button handler to use custom, then default order to allow setting associated setting
* Attach setting for settings using custom handler
* Fix swap +/- keys
* Fix boost temp
* Implement last menu option for Language selector
* Wait for init before CJC runs
* Check last setting via increment value
* Update BSP.cpp
* removed = from >=
Otherwise incrementing would stop and the scroll bar would already flash at the second to last value.
* (Hacky) Fix for Settings reset
---------
Co-authored-by: discip <53649486+discip@users.noreply.github.com>
The sleep indication phrase in simple mode is too long "Хххррп". The temperature value does not fit on the screen. Replaced it with the original phrase "Zzzz", understandable in all languages.
* chore(deps): bump actions/upload-artifact from 3 to 4
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 3 to 4.
- [Release notes](https://github.com/actions/upload-artifact/releases)
- [Commits](https://github.com/actions/upload-artifact/compare/v3...v4)
---
updated-dependencies:
- dependency-name: actions/upload-artifact
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
* push.yml: split metadata artifacts into two separated packages since now it's error by design in uploadV4 to stuff multiple files from different jobs/steps into artifact with the same name
* push.yml: add metadata per model artifact since now it's error by design in uploadV4 to stuff multiple files from different jobs/steps into one artifact with the same name
* push.yml: testing proposed by github solution for actions:#472
* push.yml: "fixing" upload as github team suggested
* push.yml: rename upload metadata step to unify build steps naming pattern
* push.yml: upload_metadata: add if-no-files-found: error directive since metadata.zip is essential
* push.yml: giving a second chance for cache save/restore actions
* push.yml: remove unsupported name field from cache actions
* push.yml: add tar to deps so cache action can collect cached files on github
* push.yml: try to retrieve cache by key properly
* push.yml: try to retrieve cache by key properly
* push.yml: remove wildcards from keys
* push.yml: try retrieve cache by explicit name
* push.yml: trying with enableCrossOsArchive == true
* push.yml: revert changes back from cache save/restore to actions download/upload
* push.yml: set retention-days == 1 and testing dot file name hoping it will hide artifacts
* push.yml: upload_metadata - download jsons: fix pattern for testing
* push.yml: adding 3rd party step for testing to delete created artifacts
* push.yml: trying to fix syntax in 3rd party step
* push.yml: revert changes to working workaround but keep retention-days == 1
* push.yml: upload_metadata: download prebuilt artifacts, generate jsons, upload them as metadata.zip - Work in Progress
* push.yml: upload_metadata: trying to fix pattern for artifacts [WiP]
* push.yml: upload_metadata: remove matrix since it doesn't work [WiP]
* push.yml: upload_metadata: remove pattern to download all prebuilt artifacts
* push.yml: add every json to every model of artifact
* push.yml: remove uploading/reuploading individual json files as zips
* push.yml: pushing to see which error will be at this time...
* ci
* Revert "push.yml: pushing to see which error will be at this time..."
This reverts commit ed3ac204ca.
* push.yml: revert manually due to accidential commit from different branch of different repo
* Remove the image of my frustration with github checkout update
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* Draft cleanup of the folder definition mess
* Move old startup
* Fixup! broken hacky includes
* Update Makefile
* Update Makefile
* Update Makefile
* Bulk format
* Who knew, header guards are a wise idea
* Squash some sizing warnings
* Drop broken usb stack
* Fix BLE headers to be sensible
* Cleaning up proper c styling
* We have newer clang, it does bracketing now
* Run clang-format brackets
* We can drop the old messy bracket-checker with newer clang format
* WiP formatter
* Align grids of scripts by right side
Massively easier to read in nearly all cases
* Excempt the table for compression from formatter
* MHP30 move to I2C Bit Banging
* Fixup Accelerometer drivers so all can use I2CBB
* No STM32 I2C driver anymore
* TS100 on I2CBB
* Miniware on BB
* Fixup S60 build
* format
format
* Start PWM after adc irq fully done
* Filter len 4
* Use comparitor 2 on timer for wrap around
* Update IRQ.cpp
* Tip measurements are uint16_t
Update BSP.cpp
Update BSP.cpp
* WiP PID
move pid tuning to config
Update PIDThread.cpp
* Handle PWM Timer gitchy comparitor
* Tuning
* Dampen with Kd
* Cleaning up
* Use TemperatureType_t for getTipTemp()
* Add small rolling average to user GUI temp to reduce flicker
* Trigger PID when adc is skipped (will use old values)
* Create a typedef for temperatures
* Quick parse replace temp types
* Fixup for fast/slow PWM on PinecilV2
* Update PIDThread.cpp
* Pinecil small tips need less smoothing
* Remove incorrect comment
* Remove unused function
* Update PinecilV2 Tune as well
* Add OLED replacement info to HardwareIssues document
* Update formatting & text
* Move OLED replacement detailed info from HardwareIssues to Troubleshooting inside the related section
Makefile: add docker-clean sub-targets to remove not only image but cache (eats lot of space sometimes) & update help output / add clean-up of docker cache to deploy.sh as well
Co-authored-by: Ben V. Brown <5425387+Ralim@users.noreply.github.com>
* 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
This shows the tip temp on the simple home screen if the temp is > 50C.
This removes the tip temp warning for all users, as now everyone can see the tip temp.
#187
* Minor corrections of Russian localization
* Russian Translition - Automatic start mode
Changed the description and the header of the "Automatic start mode" mode, since now it is turned on by the checkbox and not by the T/S/F.
TODO: For other languages, the inaccuracy of this description has remained.
* Russian Translition
Slight fix.
* Ukrainian localization
Added Ukrainian localization. Translation is implemented by natural native speakers.
* LANG_UA -> LANG_UK
#214
New Icons
Fix Hold to scroll timer with a lockout
Fix Menu lengths
New French Translation Closes#228
Fix confirmation message scroll speed
Fix translations.cpp
* Split menu handling,speed up OLED
* Split menu apart
Split menu apart.
Next to add icons etc
* Finished main menu re-layout
* Added menu option for scroll speed
* Speed up scroll settings, pad translations
* 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
* HR translation improvement.
* Added "Are you sure...?" translation
* 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
* Parametrized description scrolling speed
* Synchronized Translation.c with original Ralim master
* Removed unnecessary check
* lcd.refresh() in description scroll called only when required
* Smooth scrolling also implemented in userConfirmation() method
* Variable messageSpeedFactor renamed to messageSpeedFactor
* Variable renamed
* adjust left limit for drawing
do draw area also if part just of it is visible - e.g. do not skip whole letter in rolling description if half of it can be shown
* render just visible area part
* fix visible area part computation
* Enabled DOUBLE line for Croatian
* Menu desciption scroll sped
* Better description smooth-scrolling routine.
* Tearing fixed. The screen will update only when required.
+ Creates a new driver for the LIS2DH accelerometer
+ Fixes timing issues since we're already touching a chunk of code
The LIS2DH driver should output similar numbers to the old MMA accelerometer.
Fixes#202Fixes#189
* Add small 6x8 font with utf8 extended charset.
The font data is created from the CasioNostalgia font by zdimension
found at: https://fontstruct.com/fontstructions/show/1193786/casionostalgia
* Cleanup Font.h
The font data should be untouched.
This commit does:
* whitespace cleanup
* some cosmetic changes to the comments
* removing commas at the end of array declarations
* Update OLED.cpp to use utf8 capable FONT_6x8
* Remove ASCII6x8 from Font.h
Removed because all glyphs from ASCII6x8 are now contained in FONT_6x8.
* Fix char offset for UTF-8 page 0xc3
According to the linker script the settings should go on the last
available page of the devices flash rom. This should be page 63
starting at 0x800fc00.
* Added czech translation
Added czech translation (locale cs_CZ)
* Make simple sleep screen more readable
Add gap between "zzz" and temperature for better readability.
* Adjusted czech translation
Modified texts after testing on real device to fix char issues and increase readability
* format
* compensate for chars excluded from font
fixes#146
* added comment to explain magic 32
consolidate whitespaces in this method (really spaces should be used everywhere instead of tabs (exception for makefile) )
Settings menu works
Movement working & TMP calibrated
Tip reading sensibily
Accuracy seems ok
Trimmed down overshoot by biasing integral
Saving to flash working, detailed idle
Sleep mode
Description scrolls
Building for DFU working
Motion detection update
Use manual alg instead, using highpass filter, then sum current change vs rolling average
Re-shuffle the pwm code organisation
This brings across a set of commits to support loading boot up images from a specific location in flash. And also creating a generator tool to make files to put images in said position.
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
- E - git-related from d**e**tached commit
- 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**:
### Timestamp
- This is a timestamp of firmware compilation and it has the following format: `YYYYMMDD HHMMSS` (i.e., `20230701 213456` means it has been built in July, 1st, 2023 at 9:34:56 pm)
### 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.
### Windows (MSYS2 environment)
1. Download `msys2` install package from the [official website](https://msys2.org) and install it according to the instruction there;
2. Install requried packages (here and for the future commands use **`mingw64.exe`** terminal):
```
$ pacman -S mingw-w64-x86_64-arm-none-eabi-gcc mingw-w64-x86_64-libwinpthread-git python3 python3-pip make unzip git
```
3. Download _3rd party RISC-V toolchain_`xpack-riscv-none-elf-gcc-...-win32-x64.zip` from [this repository](https://github.com/xpack-dev-tools/riscv-none-elf-gcc-xpack/releases);
4. Move downloaded `xpack-riscv-none-elf-gcc-...-win32-x64.zip` to `msys64`_Windows_ directory (e.g., `C:\msys64\`);
5. Extract files from `xpack-riscv-none-elf-gcc-...-win32-x64.zip` and go back to _home_ directory:
9. Follow steps _4-8_ from [macOS section](#macos);
10.`pip` can be updated inside `venv` only:
```
$ python3 -m pip install --upgrade pip
```
### 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_Belorussian+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 corresponding `.hex` file from [the official website](https://e-design.com.cn/en/NewsDetail/4203645.html) ([mirror backup](https://github.com/Ralim/IronOS-Meta/tree/main/Firmware/Miniware)) 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](#mac), and can be made to work under [Linux](#linux) _sometimes_ (look for details below).
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)
### Troubleshooting
If you are running into issues such as timeouts during the programming or bootloader errors, the BL702 has a not-amazing USB PHY built in. This can cause problems on cheap cables (especially "thin" ones that tend not to have shielding). One of the authors (Ralim) has found this especially common on the cables supplied with Apple chargers when used with newer Ryzen processor ports.
It is _strongly_ reccomended to use a good quality cable, ideally _short_.
Also try other USB ports, as on some devices they can use different hub's or lengths of signalling, and this can fix the issue.
By the PinecilV2's design, by default some of the internal buses are exposed on the USB3 pins, to enable hacking/debugging/mods. This is suspected it _may_ play poorly on some chipsets. Try using a USB2.0 cable. Others have had luck with chaining USB-C->USB-A->USB-C. This may be due to this, as a lot of these adaptors are USB2 or only USB3 5gbps (half USB3 pins).
Another workaround is to put a USB hub somewhere in the chain, as these will re-form the signal and can work around the issue.
_Finally_, some users have reported issues under Windows that were fixed by changing OS (Typically to a Linux live cd).
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 corresponding `.hex` file from [the official website](https://e-design.com.cn/en/NewsDetail/4203645.html) ([mirror backup](https://github.com/Ralim/IronOS-Meta/tree/main/Firmware/Miniware)) 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](#mac), and can be made to work under [Linux](#linux) _sometimes_ (look for details below).
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 corresponding `.hex` file from [the official website](https://e-design.com.cn/en/NewsDetail/4203645.html) ([mirror backup](https://github.com/Ralim/IronOS-Meta/tree/main/Firmware/Miniware)) 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](#mac), and can be made to work under [Linux](#linux) _sometimes_ (look for details below).
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.
If you get a message when copying: "Are you sure you want to move this file without its properties?" then this can cause an issue where the iron thinks that the file has finished copying before it actually has and can cause a .ERR file. Since this dialog prompt is caused by copying a file from NTFS to FAT (the iron's filesystem) in windows, you can fix this by formatting a thumbdrive as FAT32 and then storing the hex file on that before copying the file to the iron. As there will be no NTFS properties on the file when stored on a FAT32 filesystem, there will be no prompt, and the copy will then proceed normally.
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 when you first receive your device to ensure you are up to date.
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 setting was chosen as it is just below the melting point of a wide range of solders. A lower standby temperature helps reduce the oxidation rate and prevent damage to the soldering tips. As a general rule, when not in use, unplug the unit or let it go into sleep mode to extend the life of the replaceable tips. The default sleep temperature can be adjusted to your preference.
Simply moving the iron or pressing any button will wake it back up into soldering mode. The sensitivity is adjustable. It is recommended to adjust this to suit your environment so that it reliably stays in sleep mode when not in use, but does not go into sleep mode when in use. (This may vary depending on the amount of movement during soldering.)
### Optional Hall Effect Feature (Pinecil (v1/v2) 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).
Below are short summaries / notes around the hardware. This is not an in-depth comparison of the features of the units. Please do your own research before purchasing.
Due to descisions out of our control, Miniware no longer provides source-code/schematics/support for any open source firmware on their devices. This does mean that only (TS100/TS80/TS80P) are "open" to any extent. TS80P is pushing that as it was never open at all but just happens to be very close to the TS80. While this generally shouldn't affect the performance of the device, it does mean that their newer products can be slow to be supported or some issues are harder to resolve.
Sequre has so far been supportive of the S60 by providing schematics.
The Pine64 units (Pinecil) are schematics-available (i.e you can download them on the Pine64 Wiki). They are currently the only vendor that has provided financial support of the project. They are also the only vendor that allows contact directly to the engineering teams for hardware issues. This results in generally better support for these devices. It does **not** mean that this firmware is designed around them, but it does help however that they are designed with this firmware in mind as Ralim talks to them. Where possible features are designed to work across all devices but the time for support may vary depending on the hardware and its quirks.
## A quick note on power supplies
For all devices listed **except** the MHP30:
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/).
For the MHP30, it contains a buck DC/DC, which means it can utilise most power supplies fairly well, but you should still aim for highest voltage that is reasonable to use.
### TS100
The TS100 was the first supported soldering iron, and is generally a very capable device.
Its now generally not reccomended to buy new as other devices have all of its features and more, and can often be the same price or cheaper. It's still fully supported though, nothing will be taken away from it.
- can run from 9-25V DC;
- provides a power range that is determined by the input voltage;
- voltages below 12V don't overly work well for any substantial mass;
- the original firmware can be found [here](https://e-design.com.cn/en/NewsDetail/4203645.html)([mirror backup](https://github.com/Ralim/IronOS-Meta/tree/main/Firmware/Miniware)).
The TS101 is the direct replacement of the TS100 with the same tip compatibility.
It adds a spring pressure tip holding mechanism instead of using a screw so tips are easier to swap on the fly (But are held less securely and can pull out depending on the use case). It adds USB-C PD support and the hardware is compatible with 28V EPR power supplies (under both IronOS and official firmware).
It unfortunately uses an STM32 clone MCU with quirks, so performance of the screen isn't as good as it could be but its perfectly usable. The bootloader for programming is the biggest weakness of this device and programming can be a pain. Fortunately, IronOS is relatively stable feature wise, so you shouldn't need to update the device often.
The Miniware bootup logo is burned into their bootloader, so IronOS cant remove this. IronOS can show your own logo when it starts however. There are quirks to loading a logo on this device, so be sure to read the documentation if you are coming from other devices.
### TS80
TS80 is a successor to TS100, it moves to custom smaller tips that perform better at lower wattages. It is optimised for a 9V/2A Quick Charge 3.0 power supply. This is commonly found on older power banks on the USB-A port.
It does **not** support USB-PD and will not work when powered from a USB-C power supply in most cases.
- doesn't support PD as it is not designed on the hardware level;
- the original firmware can be found [here](https://e-design.com.cn/en/NewsDetail/4203645.html)([mirror backup](https://github.com/Ralim/IronOS-Meta/tree/main/Firmware/Miniware)).

### TS80P
The TS80P is the direct successor to the TS80 and essentially what the TS80 should have been from its debut. It is nearly identical except it adds USB-PD support for far better compatibility with modern power banks as well as a faster tip removal method.
- the original firmware can be found [here](https://e-design.com.cn/en/NewsDetail/4203645.html)([mirror backup](https://github.com/Ralim/IronOS-Meta/tree/main/Firmware/Miniware)).
\*\*: use valid PD device that supports 12V/3A as power source to get full 30W potential, otherwise the iron will fall back to 9V/18W power mode.
- accelerometer is the MSA301, this is mounted roughly in the middle of the unit;
- USB-PD is using the FUSB302;
- the hardware I2C bus on PB6/7 is used for the MSA301 and FUSB302;
- the OLED is the same SSD1306 as everything else, but it’s on a bit-banged bus;
- the original firmware can be found [here](https://e-design.com.cn/en/NewsDetail/4203645.html)([mirror backup](https://github.com/Ralim/IronOS-Meta/tree/main/Firmware/Miniware)).
### Pinecil
Pincecil:
- first model of soldering iron from PINE64;
- the default firmware can be found [here](https://files.pine64.org/os/Pinecil/Pinecil_firmware_20201115.zip).
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.
The [Sequre S60](https://sequremall.com/products/sequre-s60-nano-electric-soldering-iron-support-pd-qc-power-supply-compatible-with-c210-soldering-iron-tips-precision-electronic-mobile-phone-repair-tool-anti-static-soldering-pen?variant=42361945096380) uses JBC tips, which makes it quite useful for the smaller tip types and extra options available.
#### TS101
The TS101 is the evolution of the TS100, picking up USB-PD.
It has otherwise similar tip support to the TS100/Pinecil/PinecilV2.
Absolutely massive kudos goes to @VioletEternity for her work on the reverse engineering of this. If you at all are helped by IronOS running on this device more credit goes to her than to I. Also big thanks to @whitequark for organising + supporting + magic.
### Features & changes
#### PinecilV2 notes
1. BLE is fixed on all devices.
2. Bootup Logo support is finalised and working.
3. Improved the tip control, improving accuracy and remove most oscillations.
#### Profile heating mode for MHP30
This lets you define a heat profile and run this profile akin to a proper reflow device.
This can be used on the MHP30 by long-holding the A button (aka start button).
Profile can be edited in settings.
#### Note on newer OLED's
To prevent this release being held up forever, the TS101 and S60 are being released with a limitation on the OLED screen.
The current code will only draw to the upper left corner of the screen.
Assets have been made for rendering this at full size, but the code is not complete yet.
#### Smaller updates
- Filtering added to MHP tilt-exit to make it less sensitive
- Warning if a tip is detected to be shorted (TS101 + PinecilV2)
- Translation updates ❤️
- Documentation updates
- Lots of tooling and code cleanups
## v2.21
### Features & changes
- Bluetooth Low Energy support for PinecilV2
- Large cleanup of translation files; and refactor of how we handle fonts for translations
- Fixes for I2C corruption on PinecilV2
- Option for using adjustable profiles on USB-PD or not
- Cleanups and improvements to the generated [documents website](https://ralim.github.io/IronOS)
### PinecilV2 notes
For Pinecil V2 users blisp is currently my recommended CLI tool for updating the device. It is built for all main OS's automatically. This does not apply to V1 devices. If your iron came with a blue grip, its a V1 and update the same as always. If your device came with a green silicone grip its a V2 device.
Alternatively you can use Spagett1's PineFlash tool that should provide a GUI interface for PinecilV1 & PinecilV2.
For a small number of V2 Pinecil devices there appears to be an interference issue between the Bluetooth Low Energy and some devices; more information here. If this occurs to you, please let us know in the issue and rollback to 2.20 for now.
## v2.20
- First "full" release for PinecilV2
- Loots of documentation updates
- Documentation is [now nicely readable as a site](https://ralim.github.io/IronOS/GettingStarted)
- A fair collection of bugfixes for PinecilV2
- Cold Junction Calibration was reworked and now occurs _at next boot_ to make it easier to perform when the device is cold
## v2.19
- Bug-fix Infinite Boot Logo
- Shutdown settings for MHP30
- Accelerometer sensitivity for MHP30
- Allow showing unique device ID
- Bug-fix chance of a power pulse at device boot
- Updated translations
- Improved documents, added features table
## v2.18
- Support for animated bootup logo's
- 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
### Features & 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
### Features & changes
- 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 support
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)
When the device starts, you can have it optionally show either a static image or an animation. You can also set if these should stay on the screen or dismiss after some amount of time.
These can be an elegant way to personalise your device or just mark it as your one at a meetup where there may be multiple.
All devices supported by IronOS support this logo, and follow a similar process for setting one up. Please read the below general information as well as any model specific notes.
Bootup logos are stored at the end of the flash storage in the Iron; next to the user settings. By locating them at the end of storage they are not erased during the normal firmware upgrade process. Once a logo is set it should stay (unless we need to change things in the main firmware); so to erase your logo you will also find that we generate an erase file. Alternatively your method of flashing _may_ support doing a full erase flash which will also work for this.
## Generating the Logo files
Because logos are stored at a fixed location in the device's internal flash; we can use the same method to flash these as you would normal firmware.
This does also mean that we need to convert the image/animation file into the format that IronOS understands.
IronOS uses a pre-processed file format to dramatically reduce the amount of space required to store the image; allowing for animations and saving space.
In the [IronOS-Meta](https://github.com/Ralim/IronOS-Meta) repository is a `python` script to convert images into this pre-processed file format.
Additionally, memebers of the community have contributed back their logo images as well. We provide these pre-converted for all models 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 the Python script.
You can checkout the repository or use the download-as-zip button in the Github web interface to download the code.
Inside the download code is a `Boot Logos` folder, inside here is the python script required for logo conversion.
It is easiest if you copy your logo file to be converted into this folder too, in order to keep commands shorter.
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 thresholding used for converting colour to B&W may not always work as well as one would hope.
The converter requires at least Python3 and Pillow apps. Follow online instructions for installing Python and Pillow on your machine. Any reasonably recent version should work well.
When running the script on the Windows operating system; it is recommended to use `Powershell` rather than the old `Command Prompt`.
For installing pillow; you can install it via your package manager (Debian and similar distros) or via pip. To install via pip the command should be `python -m pip install pillow`.
In your shell you can now execute `python img2logo.py input.png out -m ${model}` to convert the file `input.png` and create output files in the folder `out`.
The model should be replaced by one of the following options:
-`miniware` for older Miniware Irons -> TS100, TS80, TS80P
-`pinecilv1` for the Pinecil V1
-`pinecilv2` for the Pinecil V2
-`ts101` for the Miniware TS101 [^1] [^2]
-`s60` for the Sequre S60 [^1]
-`mhp30` for the Miniware MHP30
Different models are used for different flash locations for the image storage.
This means that files are **not** interchangeable between devices. If you are flashing multiple devices you will need to create a different file for different models.
After processing its expected to have a `.hex` and `.dfu` file created to be used. Which one to use will depend on your device.
Note: make sure your image file is in the same folder as script files (img2logo.py, output_dfu.py, output_hex.py).
[^1] Note that these devices have larger resolution screens that the logo system supports right now. Fixes are coming for this soon, roughly scheduled for 2.23.
[^2] The TS101 requires extra steps, see below.
### TS101 Quirks
When Miniware designed the TS101 they cut cost by using an STM32 clone with some odd quirks. They also re-wrote their USB bootloader, which has introduced new bugs for us to deal with.
Their bootloader appears to have kept the existing limit of not being able to flash small hex files, but they no longer fall for the older "just repeat the content" trick and instead reject the file.
Additionally, while the MCU in use has 128K of flash, their bootloader (at least for me) fails to write to anything above 99K. It _looks_ like a watchdog reset or hard crash. Unsure.
This has flow on effects, where the settings can still be located in the upper ~28K of flash, but it cant be used for anything we flash over USB.
Of that 100K we can use, they waste 32K of it for their bootloader (Old bootloaders were 16K).
This means the main "app" of IronOS is limited to around 67K (100K-32K for bootloader, -1K for logo).
For this device the Logo is not located at the end of flash but instead at the last writable page (99K).
Additionally, as we need to do a large write, to avoid having to waste more flash space; the logo is merged with the normal firmware. This means that the firmware and logo are flashed together once.
Future updates can be done without merging as it will leave the logo data there as normal firmware doesnt touch that area of flash.
To do this, download the latest version of IronOS and merge it with the logo using the `--merge` command line argument.
To create the logo file for a TS101 the full command looks like `python3 img2logo.py <image file path> <output folder path> -m ts101 --merge <Path to main firmware>`.
For this reason, there are no TS101 logo's generated by the IronOS-Meta repo.
## Flashing the Logo
### Upload via virtual disk (TS100,TS101,TS80,TS80P,S60,MHP30)
If you normally update your firmware by having your device show up as a flash drive this is the method for you.
This applies to all Miniware + S60 devices running the stock DFU bootloader.
Place your device into update mode (usually by holding the B button when connecting your device to your pc via USB).
Upload the `.hex` file you created earlier as if it was a firmware update. Do any normal tricks required for firmware flashing if any are required.
Afterwards the firmware should indicate that it has worked (often by creating a `.rdy` file).
At this point unplug your iron and re-connect it to power to start normally and the logo should welcome you.
### Upload via GUI flash tool (PinecilV1/V2)
If you normally upload your firmware using a helper application, they should accept the files from the bootlogo the same as the normal firmware.
Try the `.dfu` file first and then the `.hex`. If neither work then the application may not be updated to be able to handle boot logos. And you may need to use a different/newer tool.
### Upload via dfu-util (PinecilV1/IronOS-DFU)
For the PinecilV1 and for any devices that have been converted to use `IronOS-DFU` as the bootloader you can flash these via the `dfu-util` command line tool.
For these flash as per usual using the `.dfu` file. Afterwards power cycle and the logo should show up.
### Upload via blisp (PinecilV2)
For the PinecilV2 we suggest `blisp` as the command line tool to use if you are not using a GUI tool. `blsip` has been updated to accept `.dfu` files as well as the `.bin` files it historically used. As such you use the `.dfu` file for the logo and flash as per normal otherwise and it will work and reboot at the end. It should show you your new logo after flashing.
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.
IronOS is largely designed to run on devices that are using _fairly_ modern microcontrollers at their core. Generally this means an ARM Cortex or RISC-V processor.
At this point in time it is not planned to support 8051 or similar cored devices. This is largely due to the reliance on FreeRTOS at the moment.
When requesting a port for a new device, please try and find out if the hardware meets the below requirements.
The feature list's below are organised into three categories; Hard requirements that as of current must be met, soft requirements that _should_ be met for full featured performance and the final category of planned _but not yet implemented_ features; which can be implemented but can result in delays as these are not yet implemented.
Aside from the below, keep in mind IronOS is really designed for soldering irons. This has expanded out into hot-plates as they are exceptionally similar devices.
## Hard requirements
1. Supported processor (Arm Cortex or RISC-V). (Though generally anything that has an existing FreeRTOS port is possible).
2. 64K of flash or larger (See note A)
3. 16K of ram or larger
4. Device has one or more heating elements that can be controlled by a main temperature sensor
5. If the main temperature sensor is a thermocouple, a reference temperature sensor for cold junction compensation must exist and be close to the sensor contacts
6. Means of the user updating the device without opening
7. Known pinmap for the microcontroller. (see note B)
## Soft requirements
1. USB-PD is strongly preferred over Quick Charge; Quick Charge only devices are considered legacy and will likely not be prioritiesd.
2. Open source or at the least schematics available is **strongly** preferred and will prioritise the device.
3. Likewise friendly vendors will help dramatically with support, due to both questions and also appearances to help the community.
4. Hardware PWM wired up to the tip control is nice to have but not essential
5. Very strong preference against devices that use the endless sea of STM32 clones.
## Planned features
These features are planned for eventual support, but will likely not be done until devices need them.
- Colour screens
- More than 2 buttons for input, or encoder inputs
- WiFi/Zigbee/ any other networking
## Notes
### Note A - Flash storage space
64KB is generally the minimum recommended size for the hardware to have.
Larger is _definitely_ preferred as it enables more features or the multi-pack language firmwares.
Keep in mind that on some devices we loose space to a USB DFU bootloader (Older STM32F1's) so the firmware _can_ work with less. But it can come at the cost of features.
128KB or larger is **great**.
For devices that have BLE or WiFi or other features, often code requirements are significantly larger. These are considered non essential features so will be ignored if we run into size issues.
### Note B - Pinmap for the microcontroller
In order to be able to write the interfacing code to communicate with the hardware, we need to know what pins on the microcontroller go to what hardware.
It is also loosely required to have an understanding of the rest of the device, we do not need details on a lot of the boring aspects,but if for example a USB-PD interface IC is used we would want to know which one.
## Example request for adding a new device
Device Name:
Device Type:
Approximate Price:
Example purchase locations:
### Hardware details
Microcontroller version: `STM32F103C8Tx`
Flash size (If external to the MCU):`N/A`
Microcontroller Pinout: <!-- Either link to manufacturer information, a forum documenting this or a discussion where the pinout has been roughly figured out already-->
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.
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.
If after all of the checks OLED is still blank, or screen works but pixels are barely visible, although soldering iron itself is working (i.e., you can safely check that it's turning on, heating up & melting solder successfully), then it means that _most likely_ OLED is dead. But it can be relatively easily replaced. Models like `TS100`, `TS80`, and `TS80P` share the same OLED screen which can be bought online and used for replacement. To do so:
- find & buy at electronics shop [of your choice] display with the following spec line:
```OLED 0.69 inch / 14 pins / 96 x 16 pixels / **9616TSWC** / I2C IIC```
- disassemble your soldering iron;
- desolder old OLED and solder back new one;
- assemble your soldering iron back.
There are a few youtube videos how to do it like [this one for `TS100`](https://www.youtube.com/watch?v=HlWAY0oYPFI).
Unfortunately, this is a well-known issue of screens with OLED technology: sooner or later the brightness is starting to _"fade out"_ until complete off. Usually common recommendations to prolong its lifetime are: reduce brightness & reduce too often updates (i.e., disable animations). But your results may vary since there were reports when users couldn't see anything after turning on soldering irons which were just laying in a box for a few months after buying. And there are users with first `TS100` models not having any issues with display at all.
## 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.
@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 $(OUT_DIR) (set OUT env var to override: OUT=/path/to/dir make ...)"
@echo " * docker-clean - delete created docker image for IronOS & its build cache objects (to free a lot of space)"
@echo " * docker-clean-cache - delete build cache objects of IronOS docker image EXCEPT the image itself"
@echo " * docker-clean-image - delete docker image for IronOS EXCEPT its build cache objects"
@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 docker image & its build cache"
@echo " * clean-full - delete generated files & dirs produced during builds INCLUDING docker image & its build cache"
@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:"
This project was started to remove the need for USB for changing system settings.
In the latest official firmware they have also added a settings menu system, so it is still worth comparing the two firmwares to select your preferred option.
# IronOS - Open Source Flexible Firmware for Soldering Hardware
## Features
* Soldering / Temperature control
* Full PID iron temperature control
* Automatic sleep with selectable sensitivity
* Motion wake support
* Settings menu
* Input voltage UVLO measurement for battery powered use
* All settings saved
* Improved readability Fonts
* Use hardware features to improve reliability
* Can disable movement detection if desired
* Calibration of the temperature offset
_This repository was formerly known as TS100, it's the same great code. Just with more supported devices._
# Upgrading your ts100 iron
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)
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. Details over on the [wiki page](https://github.com/Ralim/ts100/wiki/Upgrading-Firmware).
Originally conceived as an alternative firmware for the _TS100_, this firmware has evolved into a complex soldering hardware control firmware.
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.
The firmware implements all of the standard features of a _smart_ soldering hardware, with lots of little extras and tweaks.
I highly recommend reading the installation guide fully when installing on your device. And after install just explore the settings menu.
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.
For soldering hardware that is designed to be powered by _smart_ power sources such as _PD_ or _QC_, the firmware supports settings around the negotiated power and voltage.
For soldering hardware that is designed to be powered by batteries (_TS100_ & _Pinecil_), settings for a cutoff voltage for battery protection are supported.
# New 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 power input enters the settings menu.
-> Pressing both buttons together enters the Extras menu
## 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 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 will also exit the soldering mode.
Currently **31** languages are supported. When downloading the firmware for your soldering hardware, take note of the _language code_ in the file name.
## Settings Menu
This menu allows you to cycle through all the options and set their values.
The button near the tip cycles through the options, and the one near the usb 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
This project is considered feature complete for use on a daily basis, _so please suggest any feature improvements you would like!_
* UVCO -> Undervoltage cut out level, settable in 1V increments from 10-24V
* 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
* MOTION -> Wether motion detection is enabled or not
* SENSE -> Motion Sensitivity, H is more sensitive. L is lowest sensitivity (ie takes more movement to trigger)
* TMPUNIT -> Temperature unit, C or F
* TMPRND -> Temperature Rounding, {1,5,10}
* TMPSPD -> How fast the temperature should update in the soldering status screen.
* FLPDSP -> Flip display for left handed users
_This firmware does **NOT** support the USB port while running for changing settings (this is done through the onscreen menu only). Custom logos are edited on a computer and flashed in the same manner as firmware._
Temperature rounding means that the unit will round off the temperature before displaying. This can helpt to reduce the flickering of the temperature when the unit oscillates between two temperatures.
## Extras Menu
This menu defaults to showing the current temperature on the tip.
Pressing the button near the iron tip will show the current input voltage. Pressing the other button while this is show will allow you to calibrate the reading if your iron is like mine and is not overly accurate out of the factory. (Press buttons to change measurement up and down, press both to exit and save).
## Supported Hardware
Pressing the button near the usb enters the temperature offset setting menu, when the iron is cold, pressing the other button will start the unit calibrating for any offset in the tip temperature.
| Device | DC | QC | PD | EPR\*\*\*\* | BLE | Tip Sense | Recommended Purchase | Notes |
_Tip Sense_ refers to the device being able to choose between the _"regular"__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(P)_ as there is only one model of tip for them.
V1.09
- Adds display modes, for slowing down or simplifying the display
_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.
V1.08
- Fix settings menu not showing flip display
The _TS101_ & _S60(P)_ irons and _MHP30_ & _T55_ plates feature a higher resolution OLED than other devices. Work is ongoing to support this fully, for now a cropped view is usable.
V1.07
- Adds shutdown time to automatically shutdown the iron after inactivity
\* _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_**.
V1.06
- Changes H and C when the iron is heating to the minidso chevron like images
\*\* 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_**.
V1.05
- Adds ability to calibrate the input voltage measurement
\*\*\* _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_**.
V1.04
- Increased accuracy of the temperature control
- Improved PID response slightly
- Allows temperature offset calibration
- Nicer idle screen
\*\*\*\* **EPR/PPS with 28V support** is _**disabled by default**_ due to [safety concerns](https://github.com/Ralim/IronOS/pull/2073), but to turn it back on set
_PD Mode_ option in _Power settings_ submenu to _Safe_ or _Default_.
V1.03
- Improved Button handling
- Ability to set motion sensitivity
- DC voltmeter page shows input voltage
## Getting Started
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).
To get started with _IronOS firmware_, please jump to [Getting Started Guide](https://ralim.github.io/IronOS/GettingStarted/).
## Installation
For notes on installation for your device, please refer to the flashing guide for your device:
- 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;
- ... and many many other cool & hackable features![^changelog]
[^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**.
[^changelog]:
[See the full changelog here](https://ralim.github.io/IronOS/History).
## Basic Control
Supported device is controlled by two buttons which can be pressed in the following ways:
- short: ~1 second or so;
- long: more than 1 second;
- both (press & hold both of them together).
Available buttons are:
-`+/A` button: near the front closer to the tip (for irons) or on the left side of the device (for plates);
-`-/B` button: near the back far from the tip (for irons) or on the right side of the device (for plates).
After powering on the device for the first time with _IronOS_ installed and having the tip/plate plugged in, on the main menu in _standby mode_ the unit shows a pair of prompts for the two most common operations:
- pressing the `+/A` button enters the _soldering mode_;
- pressing the `-/B` button enters the _settings menu_;
- in _soldering mode_:
- short press of `+/A` / `-/B` buttons changes the soldering temperature;
- long press of the `+/A` button enables _boost mode_ (increasing soldering temperature to the adjustable setting as long as the button is pressed);
- long press of the `-/B` button enters _standby mode_ and stops heating;
- in _standby mode_:
- long press of the `+/A` button enters _soldering temperature adjust mode_ (the same as the one in the _soldering mode_, but allows to adjust the temperature before heating up);
- long hold of the `-/B` button enters the [_debug menu_](https://ralim.github.io/IronOS/DebugMenu/);
- in _menu mode_ (to make it short here):
-`-/B` scrolls & cycles through menus and submenus;
-`+/A` enters to menu & submenu settings or changes their values if they are activated already.
Additional details are described in the [menu information](https://ralim.github.io/IronOS/Menu/).
## Remote Control
### Pinecil V2 only
Pinecil V2 has [_Bluetooth Low Energy_ module](https://ralim.github.io/IronOS/Bluetooth), which is supported by _IronOS_ since `2.21` release to control some of the settings using additional tools like [PineSAM](https://github.com/builder555/PineSAM) or [PineTool](https://github.com/lachlanbell/PineTool). In `2.21` and `2.22` releases the module was _on_ by default. However, **_Bluetooth_ is turned off in the settings by default in current `dev` builds and for the next releases** [due to security concerns](#1856).[^ble]
To enable _Bluetooth_ back:
- go to _Settings_ menu;
- press `-/B` button four times to scroll the menu for `Advanced settings`;
- press `+/A` button to open submenu;
- press `+/A` button to toggle/enable _Bluetooth_ feature;
- press `-/B`**and hold it** for just more than five seconds to exit from the _Settings_ menu.
[^ble]:
This is related only to situations when a user restores default settings using menu, or when _IronOS_ update is taking place on a new device or on a device with a previous firmware version.
## Translations
Is your preferred language missing localisation of some of the text?
Translations are stored as `json` files in the `Translations` folder.
_Pull requests_ are loved and accepted to enhance the firmware.
## Thanks
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.
## License
The code created by the community is covered by the [GNU GPLv3](https://www.gnu.org/licenses/gpl-3.0.html#license-text) license **unless noted elsewhere**.
Other components such as _FreeRTOS_ and _USB-PD_ have their own licenses.
## 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 hardware with this firmware.
**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**.
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."
"message":"Voordat je opnieuw opstart: zorg dat de soldeerpunt op kamertemperatuur is!"
},
"CJCCalibrating":{
"message":"Kalibreren\n"
},
"SettingsResetWarning":{
"message":"Weet je zeker dat je de fabrieksinstellingen terug wilt zetten?"
},
"UVLOWarningString":{
"message":"DC Laag"
},
"UndervoltageString":{
"message":"Te lage spanning\n"
},
"InputVoltageString":{
"message":"Ingangs spanning: \n"
},
"SleepingAdvancedString":{
"message":"Slaapt...\n"
},
"SleepingTipAdvancedString":{
"message":"Punt: \n"
},
"ProfilePreheatString":{
"message":"Voorverwarmen\n"
},
"ProfileCooldownString":{
"message":"Afkoelen\n"
},
"DeviceFailedValidationWarning":{
"message":"Jou apparaat is waarschijnlijk een namaak!"
},
"TooHotToStartProfileWarning":{
"message":"Te warm om\nprofiel te starten"
}
},
"characters":{
"SettingRightChar":"R",
"SettingLeftChar":"L",
"SettingAutoChar":"A",
"SettingSlowChar":"L",
"SettingMediumChar":"M",
"SettingFastChar":"S",
"SettingStartSolderingChar":"T",
"SettingStartSleepChar":"S",
"SettingStartSleepOffChar":"Z",
"SettingLockBoostChar":"B",
"SettingLockFullChar":"V"
},
"menuGroups":{
"PowerMenu":{
"displayText":"Energie-\ninstellingen",
"description":""
},
"SolderingMenu":{
"displayText":"Soldeer\ninstellingen",
"description":""
},
"PowerSavingMenu":{
"displayText":"Slaap-\nstand",
"description":""
},
"UIMenu":{
"displayText":"Gebruiker-\nsomgeving",
"description":""
},
"AdvancedMenu":{
"displayText":"Geavanceerde\ninstellingen",
"description":""
}
},
"menuValues":{
"USBPDModeDefault":{
"displayText":"Default\nMode"
},
"USBPDModeNoDynamic":{
"displayText":"No\nDynamic"
},
"USBPDModeSafe":{
"displayText":"Safe\nMode"
},
"TipTypeAuto":{
"displayText":"Auto\nSense"
},
"TipTypeT12Long":{
"displayText":"TS100\nLong"
},
"TipTypeT12Short":{
"displayText":"Pine\nShort"
},
"TipTypeT12PTS":{
"displayText":"PTS\n200"
},
"TipTypeTS80":{
"displayText":"TS80\n"
},
"TipTypeJBCC210":{
"displayText":"JBC\nC210"
}
},
"menuOptions":{
"DCInCutoff":{
"displayText":"Vermogens\nbron",
"description":"Minimale spanning om de batterij te beschermen tegen te ver ontladen (DC 10V) (S=3,3V per cell, zet PWR limiet uit)"
},
"MinVolCell":{
"displayText":"Minimum\nspanning",
"description":"Minimale toegelaten voltage per cel (3S: 3 - 3,7V | 4-6S: 2,4 - 3,7V)"
},
"QCMaxVoltage":{
"displayText":"QC\nspanning",
"description":"Maximale QC spanning de soldeerbout zou moeten aanvragen"
},
"PDNegTimeout":{
"displayText":"PD ver-\nloop tijd",
"description":"PD onderhandelings verlooptijd, afstemmingsduur in stappen van 100 ms (voor compatibiliteit met sommige QC laders)"
},
"USBPDMode":{
"displayText":"PD\nMode",
"description":"Zet PPS & EPR modes aan"
},
"BoostTemperature":{
"displayText":"Boost\ntemp",
"description":"Tip temperatuur tijdens \"boost-modus\""
},
"AutoStart":{
"displayText":"start-\ngedrag",
"description":"T=verwarm naar soldeer temp | S=standby op slaap temp tot bewogen | Z=standby zonder verwarmen tot bewogen"
},
"TempChangeShortStep":{
"displayText":"temp veran-\ndering kort",
"description":"Temperatuur veranderings stap bij korte druk op de knop"
},
"TempChangeLongStep":{
"displayText":"temp veran-\ndering lang",
"description":"Temperatuur veranderings stap bij lange druk op de knop"
},
"LockingMode":{
"displayText":"Vergrendel-\nings knoppen",
"description":"Houd tijdens het solderen beide knoppen ingedrukt om de vergrendeling in of uit te schakelen (B=alleen boost-modus | V=volledige vergrendeling)"
},
"ProfilePhases":{
"displayText":"Profiel\nfases",
"description":"Nummer van fases in profiel modus"
},
"ProfilePreheatTemp":{
"displayText":"Voorverwarm\ntemperatuur",
"description":"Voorverwarm naar deze temperatuur op de start van profiel modus"
},
"ProfilePreheatSpeed":{
"displayText":"Voorverwarm\nsnelheid",
"description":"Voorverwarm op deze snelheid (graden per seconden)"
},
"ProfilePhase1Temp":{
"displayText":"Fase 1\ntemperatuur",
"description":"Doel temperatuur op het einde van deze fase"
},
"ProfilePhase1Duration":{
"displayText":"Fase\nduur",
"description":"Doel tijdsduur van deze fase (in seconden)"
},
"ProfilePhase2Temp":{
"displayText":"Fase 2\ntemperatuur",
"description":""
},
"ProfilePhase2Duration":{
"displayText":"Fase 2\nduur",
"description":""
},
"ProfilePhase3Temp":{
"displayText":"Fase 3\ntemperatuur",
"description":""
},
"ProfilePhase3Duration":{
"displayText":"Fase 3\nduur",
"description":""
},
"ProfilePhase4Temp":{
"displayText":"Fase 4\ntemperatuur",
"description":""
},
"ProfilePhase4Duration":{
"displayText":"Fase 4\nduur",
"description":""
},
"ProfilePhase5Temp":{
"displayText":"Fase 5\ntemperatuur",
"description":""
},
"ProfilePhase5Duration":{
"displayText":"Fase 5\nduur",
"description":""
},
"ProfileCooldownSpeed":{
"displayText":"Afkoel\nsnelheid",
"description":"De snelheid van afkoelen op het eind van profiel modus (graden per seconden)"
"message":"Voordat je opnieuw opstart: stel zeker dat de soldeerpunt op kamertemperatuur is!"
},
"CJCCalibrating":{
"message":"Calibreren\n"
},
"SettingsResetWarning":{
"message":"Weet je zeker dat je de fabrieksinstellingen terug wilt zetten?"
},
"UVLOWarningString":{
"message":"Onderspanning"
},
"UndervoltageString":{
"message":"Onderspanning\n"
},
"InputVoltageString":{
"message":"Voedingsspanning: \n"
},
"SleepingAdvancedString":{
"message":"Slaapstand...\n"
},
"SleepingTipAdvancedString":{
"message":"Punt: \n"
},
"ProfilePreheatString":{
"message":"Preheat\n"
},
"ProfileCooldownString":{
"message":"Cooldown\n"
},
"DeviceFailedValidationWarning":{
"message":"Jou apparaat is waarschijnlijk namaak!"
},
"TooHotToStartProfileWarning":{
"message":"Te warm om\nprofiel te starten!"
}
},
"characters":{
"SettingRightChar":"R",
"SettingLeftChar":"L",
"SettingAutoChar":"A",
"SettingSlowChar":"T",
"SettingMediumChar":"M",
"SettingFastChar":"S",
"SettingStartSolderingChar":"T",
"SettingStartSleepChar":"S",
"SettingStartSleepOffChar":"K",
"SettingLockBoostChar":"B",
"SettingLockFullChar":"F"
},
"menuGroups":{
"PowerMenu":{
"displayText":"Vermogens-\ninstellingen",
"description":""
},
"SolderingMenu":{
"displayText":"Soldeer\ninstellingen",
"description":""
},
"PowerSavingMenu":{
"displayText":"Slaap-\nstanden",
"description":""
},
"UIMenu":{
"displayText":"Gebruikers-\ninterface",
"description":""
},
"AdvancedMenu":{
"displayText":"Geavanceerde\ninstellingen",
"description":""
}
},
"menuValues":{
"USBPDModeDefault":{
"displayText":"Default\nMode"
},
"USBPDModeNoDynamic":{
"displayText":"No\nDynamic"
},
"USBPDModeSafe":{
"displayText":"Safe\nMode"
},
"TipTypeAuto":{
"displayText":"Auto\nSense"
},
"TipTypeT12Long":{
"displayText":"TS100\nLong"
},
"TipTypeT12Short":{
"displayText":"Pine\nShort"
},
"TipTypeT12PTS":{
"displayText":"PTS\n200"
},
"TipTypeTS80":{
"displayText":"TS80\n"
},
"TipTypeJBCC210":{
"displayText":"JBC\nC210"
}
},
"menuOptions":{
"DCInCutoff":{
"displayText":"Spannings-\nbron",
"description":"Minimale toegelate voltage"
},
"MinVolCell":{
"displayText":"Minimum\nvoltage",
"description":"Minimale toegelaten voltage per cel (3S: 3 - 3.7V | 4-6S: 2.4 - 3.7V)"
},
"QCMaxVoltage":{
"displayText":"Vermogen\nwatt",
"description":"Vermogen van de adapter"
},
"PDNegTimeout":{
"displayText":"PD\ntimeout",
"description":"PD afstemmingsduur in stappen van 100ms (voor compatibiliteit met sommige QC laders)"
},
"USBPDMode":{
"displayText":"PD\nMode",
"description":"Zet PPS & EPR modes aan"
},
"BoostTemperature":{
"displayText":"Verhog\nings temp",
"description":"Verhogingstemperatuur"
},
"AutoStart":{
"displayText":"start-\ntemperatuur",
"description":"Breng de soldeerbout op temperatuur bij het opstarten. (T=Soldeertemperatuur | S=Slaapstand-temperatuur | K=Slaapstand kamertemperatuur)"
},
"TempChangeShortStep":{
"displayText":"temp veran\ndering kort",
"description":"Temperatuurveranderingsstap bij korte druk op de knop"
},
"TempChangeLongStep":{
"displayText":"temp veran\ndering lang",
"description":"Temperatuurveranderingsstap bij lange druk op de knop"
},
"LockingMode":{
"displayText":"Vergrendel-\ning knoppen",
"description":"Houd tijdens het solderen beide knoppen ingedrukt om de vergrendeling in of uit te schakelen (B=alleen boost-modus | F=volledige vergrendeling)"
},
"ProfilePhases":{
"displayText":"Profiel\nfases",
"description":"Nummer van fases in profiel modus"
},
"ProfilePreheatTemp":{
"displayText":"Voorverwarm\ntemperatuur",
"description":"Voorverwarm naar deze temperatuur op de start van profiel modus"
},
"ProfilePreheatSpeed":{
"displayText":"Voorverwarm\nsnelheid",
"description":"Voorverwarm op deze snelheid (graden per seconden)"
},
"ProfilePhase1Temp":{
"displayText":"Fase 1\ntemperatuur",
"description":"Doel temperatuur op het einde van deze fase"
},
"ProfilePhase1Duration":{
"displayText":"Fase\nduur",
"description":"Doel tijdsduur van deze fase (in seconden)"
},
"ProfilePhase2Temp":{
"displayText":"Fase 2\ntemperatuur",
"description":""
},
"ProfilePhase2Duration":{
"displayText":"Fase 2\nduur",
"description":""
},
"ProfilePhase3Temp":{
"displayText":"Fase 3\ntemperatuur",
"description":""
},
"ProfilePhase3Duration":{
"displayText":"Fase 3\nduur",
"description":""
},
"ProfilePhase4Temp":{
"displayText":"Fase 4\ntemperatuur",
"description":""
},
"ProfilePhase4Duration":{
"displayText":"Fase 4\nduur",
"description":""
},
"ProfilePhase5Temp":{
"displayText":"Fase 5\ntemperatuur",
"description":""
},
"ProfilePhase5Duration":{
"displayText":"Fase 5\nduur",
"description":""
},
"ProfileCooldownSpeed":{
"displayText":"Afkoel\nsnelheid",
"description":"De snelheid van afkoelen op het eind van profiel modus (graden per seconden)"
"message":"Пожалуйста, убедитесь, что жало и корпус имеют комнатную температуру при следующей загрузке!"
},
"CJCCalibrating":{
"message":"калибровка\n"
},
"SettingsResetWarning":{
"message":"Вы уверены, что хотите сбросить настройки к значениям по умолчанию?"
},
"UVLOWarningString":{
"message":"НИЗ.НАПР"
},
"UndervoltageString":{
"message":"Низ. напряжение\n"
},
"InputVoltageString":{
"message":"Питание(В):\n"
},
"SleepingAdvancedString":{
"message":"Сон...\n"
},
"SleepingTipAdvancedString":{
"message":"Жало: \n"
},
"ProfilePreheatString":{
"message":"Преднагрев\n"
},
"ProfileCooldownString":{
"message":"Остывание\n"
},
"DeviceFailedValidationWarning":{
"message":"Вероятно, это поддельное устройство!"
},
"TooHotToStartProfileWarning":{
"message":"Слишком горячо для\nстарта профиля"
}
},
"characters":{
"SettingRightChar":"П",
"SettingLeftChar":"Л",
"SettingAutoChar":"А",
"SettingSlowChar":"М",
"SettingMediumChar":"С",
"SettingFastChar":"Б",
"SettingStartSolderingChar":"П",
"SettingStartSleepChar":"С",
"SettingStartSleepOffChar":"К",
"SettingLockBoostChar":"Т",
"SettingLockFullChar":"П"
},
"menuGroups":{
"PowerMenu":{
"displayText":"Настройки\nпитания",
"description":""
},
"SolderingMenu":{
"displayText":"Настройки\nпайки",
"description":""
},
"PowerSavingMenu":{
"displayText":"Авто\nвыключение",
"description":""
},
"UIMenu":{
"displayText":"Интерфейс\n",
"description":""
},
"AdvancedMenu":{
"displayText":"Доп.\nнастройки",
"description":""
}
},
"menuValues":{
"USBPDModeDefault":{
"displayText":"Вкл.\nPPSиEPR"
},
"USBPDModeNoDynamic":{
"displayText":"Откл.\n"
},
"USBPDModeSafe":{
"displayText":"Вкл.без\nзапроса"
},
"TipTypeAuto":{
"displayText":"Авто\nопред-е"
},
"TipTypeT12Long":{
"displayText":"TS100\nстанд."
},
"TipTypeT12Short":{
"displayText":"Pine\nкоротк."
},
"TipTypeT12PTS":{
"displayText":"PTS\n200"
},
"TipTypeTS80":{
"displayText":"TS80(P)\n"
},
"TipTypeJBCC210":{
"displayText":"JBC\nC210"
}
},
"menuOptions":{
"DCInCutoff":{
"displayText":"Предельное\nнапряжение",
"description":"Установка минимально предельного напряжения от аккумулятора для предотвращения глубокого разряда (DC 10В | S 3,3В на ячейку, без ограничения мощности)"
"description":"Sonraki boot'ta uç Soğuk Nokta Kompansasyonu kalibre edilecek (Delta T < 5°C ise gerekmez)"
},
"VoltageCalibration":{
"displayText":"VOL KAL?\n",
"description":"Voltaj Girişi Kalibrasyonu. Düğmeler ayarlar, çıkmak için uzun bas."
},
"PowerPulsePower":{
"displayText":"Güç\nDarbeleri",
"description":"Güç girişi voltajı ölçüm yoğunluğunu sık tut."
},
"PowerPulseWait":{
"displayText":"Güç Darbesi\nGecikmesi",
"description":"Uyanık tutma darbesinin tetiklenmeden önceki gecikme süresi (x 2.5s)"
},
"PowerPulseDuration":{
"displayText":"Güç Darbesi\nSüresi",
"description":"Uyanık tutma darbesi süresi (x 250ms)"
},
"SettingsReset":{
"displayText":"SIFIRLA?\n",
"description":"Bütün ayarları sıfırlar"
},
"LanguageSwitch":{
"displayText":"Dil:\n TR Türkçe",
"description":""
},
"SolderingTipType":{
"displayText":"Soldering\nTip Type",
"description":"Select the tip type fitted"
}
}
}
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.