Jag har skrapat mej en hel del i huvudet med att fundera hur uppgifterna bäst skall fördelas mellan kärnorna [i ESP32:n] och därmed också vilkendera kärnan som samtalar med vilka givare.
För närvarande styrs ju processen av en Arduino Uno, och den räcker bra till, så allt snack om att fördela lasten på två kärnor är förstås ren fåfänga, eftersom en ESP32-kärna utan problem kunde sköta hela ruljansen mycket effektivare än en AVR328.
Ändå vill man ju göra det krångligt, bara för att det är möjligt att göra det. Båda kärnorna kommer dessutom att behöva sin egen I2C-buss…
Jag tänker då som så, att kärna #1 skall göra precis bara det som Arduinon gör idag, d.v.s användarprocessen och styrningen av inverter, pumpar och reningsenhet, medan kärna #0 tar hand om alla nya sensorer, mätningar, uträkningar och optimeringsinställningar, och sedan förmedla styrvärden till #1.
Programmet idag är en lägesmaskin (state machine) som körs som en ändlös loop och lämpar sig därför utmärkt för att köras i en slavprocessor, men också semaforuppsättningen (signaleringen mellan kärnorna) blir så möjligast enkel. Det är ju vanligtvis där det brukar uppstå problem då man kör olika processer i olika kärnor.
Behövs iaf en semafor #1 → #0 för att meddela läget, en #0 → #1 som anger ifall tappning och/eller rening får startas just nu, och så någon semafor med vilken #0 kan tvångsstyra/stoppa #1 ifall någon situation uppstår.
Därutöver kommer några parametervärden att behövas i båda processerna, men det betyder bara, att de variablerna måste vara globala.
Så skall man ju få igång all kringutrustning och kunna prata med den också...
Det bästa (och samtidigt det värsta) i Arduino IDE-världen är en stor uppsättning biblioteksrutiner för så gott som alla möjliga och omöjliga I/O-enheter som finns.
Vill man göra något ”quick-n-dirty” är det bara att välja och vraka. Biblioteken är då oftast den rakaste och enklaste vägen.
Vill man däremot göra något specifikt, optimerat och kanske standardisera gränssnittet till drivrutinerna, och dessutom dokumentera det väl kan biblioteken vara rena h....et!
”Dom stora pojkarna”, som Adafruit, Sparkfun m.fl utvecklar och testar sina rutiner väl, och de är ofta rätt väl dokumenterade också, men även de gör ”the Adafruit way”, ”the Sparkfun way” el.dyl.
Speciellt Adafruit har, iofs förtjänstfullt, byggt upp en arkitektur med olika lager (layers), vilket dessvärre medför, att än flera rutiner måste inkluderas.
Dessutom bakar de oftast in en massa liknande kretsar och versioner av kretsar i samma biblioteksrutin och man måste sedan med olika Defs berätta vilken krets/version man vill kompilera för. Compilern sköter ju nog för all del om, att endast de behövliga delarna tas med i binären, men det är helt omöjligt att dokumentera.
Enskilda programmerare och mindre aktörer har ibland enklare och mera lättlästa rutiner, men de kan sedan i sin tur ha sinsemellan helt olika metoder eller t.o.m vara bristfälligt dokumenterade.
Mao: hjälps inte annat än att läsa igenom ett stort antal, leta fram algoritmerna och sedan re-factorera.
)
Inga som helst meddelanden, men jag var ju färdigt misstänksam, så jag följde dagligen med hur saken framskrider, och visste därför när paketet var framme (= 7.1 på kvällen).
Ser ut som en genomtänkt låda, blir det någon ytbehandling av fanern så det inte suger åt sig fukt?
Det nya systemet skall därför följa exakt samma mönster, med den skillnaden att parametervärdena som styr processen och vilka hittills varit statiska, framöver avläses från variabler vilka dynamiskt och under gång kan ställas av systemprocessen. På så sätt skall det vara möjligt att dynamiskt kunna trimma in systemet för bättre prestanda.
