Add Alientek T90 (Nations N32L40x) BSP with GC9 colour display

[vshuraeff]

Summary

Adds a new BSP target for the Alientek T90 soldering iron — a Nations N32L40x (Cortex-M4F) iron
with a JBC T245 / C245 cartridge, a GC9-family 160x40 RGB565 colour SPI LCD, a CH224Q USB-PD
sink and a QST QMA6100P accelerometer. Build with make model=T90 firmware-EN.

The T90 has no exposed SWD header and ships a closed HID "update-mode" bootloader, so the port was
brought up almost entirely by reverse-engineering the stock firmware. A small atktool utility
(Tools/atktool/) packs the .atk image and flashes over the HID bootloader; see the flashing guide.

Status — validated on real hardware

• Boots; reads tip temperature; drives the heater; PID converges.
• Settings persist across power cycles.
• Accelerometer auto-rotation (R / L / Auto).
• Native RGB565 colour soldering screen; every other screen (menus, warnings, no-tip icon, boot logo)
  renders through IronOS's normal mono pipeline.
• Compact small-font menu help text suited to the wide/short panel.

Calibration caveat: the tip / Vin scale is reverse-engineered from the stock firmware and tracks the
factory closely, but a final fit against a reference thermometer is still pending — treat absolute
readings as approximate (room temperature currently reads at the fixed ~38 °C cold-junction anchor).

Reverse-engineering notes

• First-boot fault — a deterministic UsageFault / INVSTATE was an inherited FPU exception
  frame: the hard-float factory bootloader branches into the app with CONTROL.FPCA still set, while
  this is a soft-float build on the FreeRTOS ARM_CM3 port that never saves FP context. Fixed in
  preRTOS.cpp (clear FPCA, disable FPCCR auto/lazy stacking, deny CP10/11 before the scheduler).
• ADC channel map — N32L40x channel N samples PA(N-1); the front-end is Vin=ch2/PA1, NTC=ch3/PA2,
  tip=ch4/PA3 (injected group), current=ch5/PA4.
• Calibration — the factory tip function returns an absolute temperature via a piecewise-linear
  lut_interp(opamp_input) with no live cold-junction term at soldering temperatures; reproduced as a
  uV→°C LUT in the IronOS delta model plus a fixed 38 °C cold junction (the factory's baked-in anchor).
• Settings flash — the top of the die is bootloader-owned and wiped on power-cycle, so settings were
  relocated into the retained application-flash region (linker shortened to 76K).
• Flash protocol — the .atk format and HID update protocol were recovered by byte-exact round-trip
  against factory images; the commit opcode is SetBoot (0x15).

More detail in source/Core/BSP/Alientek-T90/README.md.

Shared-core changes (for discussion)

Most of the change is confined to the new BSP, but a few small, flag-gated hooks touch shared code —
non-T90 builds are byte-identical:

• FRAMEBUFFER_ROTATION (OLED.hpp) — when the BSP rotates the whole framebuffer in software the UI
  draws a single un-rotated layout: getRotation() is forced false and getRawRotation() exposes the
  true left/right-hand state (otherwise the per-screen rotation branches double-apply).
• MENU_DESCRIPTION_SMALL_FONT — word-wraps menu descriptions and renders them in the small font under
  the setting value instead of the full-screen scrolling takeover (build-side support in
  make_translation.py).
• getCurrentOperatingMode() (GUIThread.cpp) — a C accessor so the BSP colour renderer can read the
  active operating mode without depending on the deep UI enum header.

Testing

make model=T90 firmware-EN builds clean (FLASH ~49 %, RAM ~70 % of the N32L403 budget); the resulting
image was flashed and exercised on a physical T90 — boot, heating, settings persistence, auto-rotation,
the colour soldering screen and the menus.

---

#2195

[Ralim]

Please do not include files that are not required for the project to keep bloat down 🙏🏼

[Ralim]

Rather than one time generating this, its preffered if this is generated in the Makefile so we only commit the source image data; and can derive this at compile time

[Ralim]

Please do NOT do this sorts of comparative comments, I know the LLM likes to make them but they do not really help. Its best to just document what is here rather than what isn't

[Ralim]

Floating comment?

[Ralim]

Hia, Thank you so much for the PR.

A few questions / small ask.

1. Which LLM is used for this?

You ignored the PR template and instead raised the PR with a very LLM-like message, as well as lots of the code comments read like an LLM. If an LLM is used please disclose this.

2. Where did atktool come from?

Is it brand new, or is it from another project (So I know for the software licence)?

3. Flashing docs

For the flashing doc, thank you for writing one 🙇🏼

-> Where does t90-factory.atk come from (can you link to it in the doc?)
-> Does the flashing work on windows? If it doesn't, Please be very clear at the top of the file.

I dont mind if it does or doesn't work on Windows, just want to make it very clear so we dont get issues raised

4. Colourisation implementation

Please do not do colourisation or theme's in the BSP folder. All drawing logic needs to live in the UI/drawing folder.

As you are adding a colour screen, create a new folder colour_WidthxHeight and place the updated drawing logic in there. Update the code to mask out OLED.{cpp,hpp} and make a new driver for the screen.

This way you can link to your display driver instead of the oled file,and call functions directly to draw how you want.

5. Boot logo

Traditionally, IronOS does not burn in a boot logo by default and that is up to the user to flash later on. It would be preferable to keep matching this setup. This way the boot logo can be submitted to IronOS-meta repo, and users can flash their own.

Some thought will need to be given to how to encode and store boot logos vs flash size for a colour display.

6. Shared code changes

For the first two code changes; these should be raised in their own PR's for review.
I believe you may not need the framebuffer rotation change once you write your own display driver file instead of hijacking oled.

7. PR Size

This PR is quite large, I've some a skim review of things that show up as soon as I open the file, but its hard to read each line when its this big.

Would you be willing to break this up into PR's that implement logical blocks / changes incrementally so that its not a 60k line delta to sift through.

8. Readme

When updating the main readme, you dont need to add the LLM-speak long explanation, just mark it as experimental.

I hope that all makes sense 🙇🏼

[dogtopus]

Also the atktool should probably do firmware flashing only, and be separated from this repo. This aligns better to what other platforms do (e.g. Pinecil).