MHP30 Support

[Ralim]

Tracking progress in bringing in support for the MHP30.
Cant merge / usable until all a ticked off.

• OLED display working
• Buttons
• USB-PD
• Heater control
• Cold junction temp sensor
• VIN measurement
• Accelerometer (Reading but needs logic)
• Inverted logic for accelerometer knock over == stop
• Tip thermal response curve (is it K type?)
• How do we handle bootloader (do we need to do our own)
• RGB LED
• Buzzer
• Fix PD resistance setpoint
• Disable screen rotation via accel

Closes #822

[Ralim]

@vinigas

I gave up trying to make the timing work out, so just masking heating for the 0.3 seconds for now.
Its either that or banging the tone, which feels about as hackish :/

Feel like a re-test? :)

[vini-nu]

Re-tested.

Doesn't crash on any power supplies. And that's what's the most important on first support release, in my opinion.

Seems very great. Works stable. 😊

---

Some notes for future releases:
o RGB coloring is not consistent throughout the menu (moving from heating to main-menu changes color). In default software color always showed approximate temperature of hotplate. Maybe settings could allow to set temperature in #FFFFFF format for user set temperature ranges (dynamic ranges, dynamic amount of ranges).

[vini-nu]

Hmm... Found some bug just now with long pressing BOOST. Cannot tell exactly what it was, but then hotplate was on target temp and pressed boost, temp raised and then beeper screamed non stop, till temp dropped slowly to targettemp+10'C.

Wasn't able to replicate it once more. I may test more. Anyways, it doesn't crash and works fine.

Maybe race condition.

---

Another bug then slow-spaming boost button in range between targettemp and targettemp+10'C.
It crashed firmware. But is rare bug too.

Race condition too, I think.

---

But these bugs doesn't really bother to get job done, for now. 📈

[g3gg0]

temperatures / color:

i personally prefer smooth transitions to signal the color. have implemented this on my 3D printer
faint blue: cold (< 30°C) and no heating
(>= 30°C or heating) switch to orange and fade over yellow to white till 260°C
over 260°C red warning signal because exceeding specification

thats something even my kids understood :)

struct sColorRgb
{
  uint8_t r;
  uint8_t g;
  uint8_t b;
};

struct sColorEntry
{
  short temp;
  struct sColorRgb color;
};

struct sColorEntry colorTable[] = {
  {   0, { 10, 10, 10} },
  {  10, { 10, 10, 10} },
  {  11, {  0,  0, 40} },
  {  30, {  0,  0, 40} },
  {  60, { 60, 20,  0} },
  { 180, {100, 50,  0} },
  { 260, {100,100,100} },
  { 290, {100,100,100} },
  { 295, {100,  0,  0} },
  { 999, {100,  0,  0} }  
};

void channelFade(uint8_t *out, uint8_t low, uint8_t high, float distance)
{
  *out = 255 * (low + (high - low) * distance) / 100;
}

uint32_t calcColor(float celsius)
{
  uint32_t color = 0;

  for(int pos = 1; pos < COUNT(colorTable); pos++)
  {
    if(colorTable[pos].temp > celsius)
    {
      struct sColorEntry *cur = &colorTable[pos-1];
      struct sColorEntry *next = &colorTable[pos];

      struct sColorRgb baseRgb = cur->color;
      struct sColorRgb nextRgb = next->color;

      float distance = (celsius - cur->temp) / (next->temp - cur->temp);

      /* this is in PWM 0-255 */
      uint8_t r = 0;
      uint8_t g = 0;
      uint8_t b = 0;

      channelFade(&r, baseRgb.r, nextRgb.r, distance);
      channelFade(&g, baseRgb.g, nextRgb.g, distance);
      channelFade(&b, baseRgb.b, nextRgb.b, distance);
      
      return strip.Color(r, g, b);
    }
  }
  
  return strip.Color(255, 0, 0);
}

[Ralim]

Led colour is something I'm planning to leave out of this current PR, and welcome the community to provide PR's on how its done.

Personally I'm fairly indifferent to the LED other than wanting bright colours = burn risk. (Prefer not white but not hard rule on that)

The crashes going into and out of boost mode I've only been able to replicate once and that was on my 30W adaptor so I'm more suspect of power glitching at this point :/

I think I'll merge the current status of the PR so I can include this in the next release, and then ask that we split out separate issues for each improvement to keep the noise down :)

So if you could split out issues for remaining issues would be fantastic, as I think we are now beyond usable and into refinement stage.

[Ralim]

@g3gg0

In terms of your colour code, should be easy enough to add something like that when I have time (or PR welcome).

Current implementation is mostly MVP :)

[vini-nu]

I think colors should transition similar to this, and the hottest color being white.

Smooth color transitioning would be very cool.

temp <60'C is safe to touch several seconds without burns (but uncomfortable).

temp <40'C should be blue.

[g3gg0]

personally prefer blue, yellow, orange, white
and red for "error states" while green could be some kind of "ready" signal

[g3gg0]

@Ralim
just want to say a big fat

thanks for your work!

[Ralim]

Hehe, I think we will end up needing settings on this already 😁 since to me white = on, green = safe, blue =cold and red = hot

🤣

[g3gg0]

in the end the user gets used to the colors anyway, no matter which got picked ;)

[vini-nu]

As this project grows, I think that artifacts should be not firmware, but firmware-installer/compiler/manager/driver, which build user preferred modules/features and compiler would look at user editable config file (like linux kernel build config smth).

User downloads portable IronOS builder, launches it, checks what he wants and how, then custom firmware is built. This builder would allow to select language (if GUI) etc. This innovation path would allow to save hardware ROM for features user wants as project grows in features more than hardware can contain.

E.g. if user want full Tetris, he can even uncheck compiler "add feature" for heating the tip. 😂

[vini-nu]

Maybe this installer/compiler thing could also have profile manager.

Maybe user could make heating profile logic with https://github.com/google/blockly which would be embedded into Electron webapp.

[g3gg0]

(added a graphic above, visualizing the coloring i meant)

regarding building:
i suspect that the average john doe user just wants to download the firmware.
even me. i prefer downloading the binaries, not wanting to even flip a bit in the hex image.
definitely not building from source. this iron/hotplate is a tool i wanted to use :D

however you could provide a separate hex with the settings area that could be customized by the user.
(not sure if the DFU mode could handle that properly)

but having a small C/.py tool that generates a maybe 128 byte .hex from out of thin air, that contains all provided settings
and can be flashed into the settings area.
that is some concept which is very common, especially in automotive area.

in this settings area you could also place the color structure from above, as well the profiles or even a startup image.
project-wise, just use a struct which is hardcoded to be at 0xsomething and make sure the linker never occupies that area.

[Ralim]

My general feeling on the compiler tool is that most people don't really want to deal with that, plus packaging compilers for multiple distributions is a nightmare.

I haven't come across a single electron app that is smaller than the zip of firmwares to date 😂 also my general preference is anything but electron. (When electron stops shipping me basically a browser to run a Web page maybe I'll be interested).

I agree a config tool / page that generates a hex to flash in the settings area is a better way to go, but also that feels largely a nightmare for support.
One could technically write it now as all you need to do is repeat the content a bunch of times as DFU has a ~4k min file size.

I've thought about making up a qt or fyne gui to do this but just don't have the time at all.

My plan was the tool does:

1. You select your device
2. Select release
3. It downloads the zip and extracts this
4. It configures bootlogo, settings and firmware into merged hex
5. It wraps up flashing this as well

But building that out is a chunk of time 😢

[g3gg0]

I agree a config tool / page that generates a hex to flash in the settings area is a better way to go, but also that feels largely a nightmare for support.

ok then we would have to reserve 4k of the flash for the settings area - is this feasible?
What about a simple web tool, maybe javascript, where you just download the configuration hex after configuring the settings?
building a hex isnt magic and the basics would be done within a day or two.

[Ralim]

Ah, no we only need to reserve one erase page (1k), you literally copy-paste the hex file lines to make the resulting hex file larger than 4k.

No firmware changes required really.

Yeah Web page is definitely a valid way to go about this, only magic is knowing settings offset based on model number.

[g3gg0]

settings offset based on model number

cant we use a fixed location in the flash for the future? or do we have different chips?

[Ralim]

Different sized flash and we place settings in one of the last pages to avoid dealing with linking over a gap

[g3gg0]

just googled a BSD 3-clause hex handling library that could fit:
https://github.com/NordicSemiconductor/nrf-intel-hex

[g3gg0]

linking over a gap shouldnt be an issue, or?

[Ralim]

Shouldn't be an issue, but ran into issues in my quick attempt to get it to work nicely.

Also given we have bumped into 0% free flash a few times already in the history of the firmware, concern around packing density against aligning to the gap is a thing.

But yeah I agree it could definitely be done, most likely by just careful linker set up.

[g3gg0]

yeah understand and agree. reserving 1k ist tough anyway.

[Zuckme]

temperatures / color:

i personally prefer smooth transitions to signal the color. have implemented this on my 3D printer faint blue: cold (< 30°C) and no heating (>= 30°C or heating) switch to orange and fade over yellow to white till 260°C over 260°C red warning signal because exceeding specification

thats something even my kids understood :)

KISS!

In every bathroom in the world blue means cold, red means hot.
When kids wants to draw a fire they use mainly red not white.

My proposal, simple and intuitive for all humans that use hot/cold water at home

Standby: Green (good to go)
Heat on < 60°C : BLUE! safe to touch!
Heat on > 60°C : RED! (do not touch it!)

only then we can discuss the below ones:

Overheat: RED flashing + buzzer! (do not touch it, ALARM!)
DFU upgrade: white
Error: yellow flashing! (means attention!)

smooth transition is for teenagers IMHO.

[g3gg0]

talking about a custom open sourced firmware for a mini microcontroller / OLED controlled USB-C PD hotplate and asking for KISS.
not exactly the KISS i am used to, but thanks for sharing your thoughts ;)

[Ralim]

Hello,
Always open to new ideas.

Please note that DFU is NOT changeable, and thus is will always be blue and we won't use blue because of that.

The convention I went with is red/yellow== burn risk and green == safe. As red/green is far more used on tools than blue (blue is often an on light).

What would you mean by overheat?

[Zuckme]

asking for KISS. not exactly the KISS i am used to, but thanks for sharing your thoughts ;)

Well if it is possible always go KISS!
I use FAR Manager in Windows... so believe me I love not KISS if it makes sense.

Please note that DFU is NOT changeable, and thus is will always be blue and we won't use blue because of that.

To put the unit in DFU mode the user has to perform a not intuitive process.
It is impossible to kick the DFU in without knowing it and being 100% aware of that.
On top of that two things:

1. the display shows "DFU...."
2. DFU mode should not be used everyday. Only sporadic.

Long story short: it is impossible to confuse the blue DFU with the unit on and <60

What would you mean by overheat?

Oh, I assumed there is a safety/emergency state when the unit is thermal drifitng with full power...
If there isn't ignore that. I got my MHP30 since two days....
That said all the color discussion boils down to my personal taste.

Ralim and g3gg0 you did and do a wonderful job, and deserve all my respect.
I am sorry if I sound harsh and bossy.

As you already mentioned, colors must be user configurable somehow.
We can save a lot of discussion about personal tastes in this way.

Ping me if you need someone to test some new features.
Thanks again for your hard work.