Varmepumpe fra Tørretumbler

Jeg har altid været betaget af de der Populær-Mekanik artikler fra midten af det forrige århundrede, hvor man repurposed et eller andet f.ex:

Så her er mit bidrag til Menneskehedens overlevelse!

Jeg har denne gang fået fingre i min smukke kones Tørre-Tumbler, den larmede, sikkert et et kaput leje, ihvertfald nok til at vi skulle have en ny.

Den gamle: en Blomberg btgh473w0 var en kondens-tørretumbe med Varme-Pumpe, så jeg tænkte den kunne være basis for et lille projekt, måske en affugter til mit 3D printer rum i kælderen.

En eftermiddag og tingesten var splittet i atomer:

  • 90w ac-motor til at dreje tromlen, og blæser
  • Kondensat pumpe
  • 16 W 220v blæser
  • Skrue-kompressor gmcc rjsn82v2tzra1:
    • for heat-pump
    • R134a kølemiddel
    • 1 fase 50Hz-220/230/240V
    • heating capacity 1479 W, Power 435 W, COP 3.4 W/W
  • Styrings-enhed baseret på Atmega64 MCU med:
    • 1 x 16A 250VAC relæ
    • 3 x 10A 125VAC relæer
    • 3 x 5A 250VAC relæer
    • 2 temperatur sensorer NTC 12k p38
    • 2 micro-switche
    • LCD med 4 x 7segment og en masse symboler
    • drejeknap 16 LED-er og 6 trykknapper
    • lille switchmode powersupply
    • Ellers ingen power elektronik

Så det er så simpelt som det kan være, og man kunne sådan set blot sætte tingene sammen på en ny måde uden brug af computer, og af-fugteren kunne være i drift i aften, så det gør vi IKKE.

Jeg har leget meget med Atmega processorer, dette er dog min første Atmega64, men det burde være lige-til , der er ingen X-tal så den kører sikkert på den interne RC-oscilator på 8 Mhz

Problemet er en Atmega64 har mange ben – nemlig 64, og dem har jeg ingen lyst til at finde ud af hvor går hen.  Man kunne sikkert nøjes med at finde de 7 udgange der styrer relæerne, og de 2 temperatur følere ender sikkert i en af de 8 ADC  indgange.  Som du ser er vi allerede godt igang 😉

En lille ting der er værd at være opmærksom på er, at den indbyggede switch-mode power-supply der levere de 5V til CPU er bundet til primær-siden så det er nok klogt at afstå fra at bruge den.  Brug en lille 5v USB-lader, så undgår vi et rap over fingrene, indtil videre strømføder jeg blot fra min computers USB serielle forbindelse.

Jeg har tidligere lavet en Bootloader til Atmega der kan boot to forskellige binære, så jeg kunne køre hhv. Marlin og Klipper på mine 3D-printere uden at skulle installere nyt firmware ved skift.  Det er også praktisk her, så vi kan have et lille debugnings-program loaded som sekundær firmware.

Første skridt er at tilpasse og installere DualBoot bootloader på Tøreren.

Jeg starter altid med at installere mit hello.c program fra Dualboot systemet, der viser  io-pin status for alle portene i en uendelighed, programmet compileres og installeres på Atmega64-eren, og vi kan nu trykke lidt på knapperne og finde en passende knap til at vælge mellem de forskellige firmware.  Det blev Port-D bit-5.  Så en bootloader kan kompileres og installeres.

Derefter kan vi installere den originale firmware tilbage i Atmega64-eren som primær firmware og vores hello.c som sekundær firmware, så vi nu har dette layout

  • 0x0000-0xF000 – Den originale Firmware  uden de sidste 4 kbyte
  • 0xF000- 0xFAFF – test firmwaren der blot udkriver port status.
  • 0xFB00-0xFBFF – irq-vector trampolin for den sekundære firmware
  • 0xFC00-0xFFFF – DualBoot bootloaderen der er baseret på optiboot

Så her den første dag, kan vi styre relæer og læse tryk-knapperne, men drejekappen, LED-erne og LCD-en er et mysterium.  Det fornuftige valg her ville have været at erstatte LCD, med en tekst-baset 2×16 LCD, eller måske en lille grafisk 64×128 pixel OLED display der kan styres over i2c, ting jeg har liggende og som koster mindre end en pose bland-selv-slik.

Den roterende knap med de 16 LED

Mit hello program, afslørede at den roterende knap sendte pulser ind på CPU-ens Port A bit 0 og 1, så jeg gættede mig til at de 16 LED der er forbundet til en HC595 blev styret af bit 2-4 også på Port A – Bingo.

Reverse-Enginering af den Originale Firmware LCD kontrol

Jeg havde sikret mig en kopi af den originale firmware, som jeg så kunne kigge nærmere på med Ghidra.  Ikke fordi jeg vil reverse engineere softwaren, men med et par klik var det nemt at finde ud af hvilke porte der blev brugt mest, det var Port-D bit-0 og 1 der var mest populær, og den subroutine der brugte den mest, lignede grangivelig en i2c-bitbang driver, Jeg har her nangivet den lcd_sendbyte(), et kig på den kaldende subrutine afslører også at  Port-B  bit-5 virker som select/reset.

Så jeg riggede en Arduino op som i2c-sniffer, den skrev jeg om i:

og snart havde jeg luret hvad CPU-en og LCD-en havde af hemmelighedder:

    • Først sendes der 16 i2c-overførsler af hver 16 stk 00-bytes – dermed bliver alle buffere flushed.
    • derefter sendes der  burst af de samme 16 data 187 gange per sekund
      0x70, 0xc8, 0xe0, 0x80, 0xed, 0xf0, 0x78, 0x00, 0x00, 0x0a, 0xfa, 0xfa, 0xf0, 0x0f, 0x00, 0x00
    • Drejer man lidt på knappen, skifter anden halvdel at transmissionen, og teksten på LCD skifter også.

Det  tog det ikke lang tid at finde ud af at:

  • 0x70 er i2c addressen som er 0x38, meget typisk for i2c LCD-ere
  • de næste 7 bytes konfigurerer LCD-en
  • de sidste 8 bytes kontrollerer de 64 segmenter på LCD-en
  • Selve LCD-en kunne være baseret på en NXP PCA8538

Det var det – ikke flere hemmelighedder,

Måske der bliver et fortsættelse med beskrivelse af det lille Forth system der overtage kontrollen – stay tuned

 

This entry was posted in Arduino, Embedded, Hardware. Bookmark the permalink.

Leave a Reply