ECU- styrning till en VW pumpdysediesel.

[KLset]

Ang flaskhals: Om man jämför en krets (Atmega2560) med ca 75 I/O 16 MHz klocka och 16 MIPS, 8 bitar, 1 core och en annan (Atmega328) med ca 25 I/O 16 MHz och 8 bitar, 1 core så har den större mycket mer att ta hand om innan den gått igenom alltihopa, borde den större då inte bli lite trögare då? Mer timers, mer interruptben, mer analogingångar, mer PWM utgångar, mer av allt, den borde bli långsammare?

Ja, det tror jag. Att köra flera ATmega328 som du gör borde vara snabbare än att köra en ATmega2560, förutsatt att det inte är massor av kommunikation mellan dem som gör att de måste vänta på varandra. Hur är arbetsbördan fördelad på dem - vilken ATmega328 gör vad?

[hawkan]

Det håller jag inte med om. Eventuella långsamheter märks inte av användaren. Instruktioner går lika fort, interrupt går lika fort osv. Mega2560 är mer komplex, men det är internt innanför det svarta skalet. Man kan iofs bygga störr program med fler enheter med en mega2560 och det kan vara så att storleken på progammet blir stort så det går långsamt. Å andra sidan går det inte alls att göra på en 328p. Många, många 3D-skrivare drivs av en mega2560 och det är en hel del processande den klarar av utan att storkna.
Om det funkar på en 328 funkar det också på en 2560 skulle jag säga som generellt.

[KLset]

@hawkan: Ja, Microchip skriver att både 328 och 2560 klarar av 1 MIPS/Mhz. Jag tänkte att man som exempel behöver 69 I/O och alternativen är:

• 1) en 2560 som har 86 I/O
  2) tre 328 som har totalt 69 I/O

Om den kod man vill köra lika gärna kan köras parallellt på de tre 328:orna - då är det snabbare än en enda 2560. Sedan kanske problemet inte kräver mer MIPS än en 2560:a kan ge då all I/O används - då är ju det en enklare lösning tycker jag.

[Janson1]

Till min övervakare av dom båda ECU:er så vill jag helst ha allt på samma chip&sketch. Detta är inte tidskritiskt mer än 2-3 sekunder mellan skrivningarna till SD-kortet. Hela systemet med en motor som går på ganska konstant varv och lika effekt är ju inte behov av ögonblicklig övervakning även om det nästan blir det. Med en 2560 får jag 8 analogingångar till vilket passar mig bra då jag funderar på att logga även andra tryck och temperaturer för senare genomgång. Nu i början så behövs nog temperaturkontroll av växellådan lite här och var som man sen ta bort och klistra på Telatempettiketter istället. (En etikett som har 5-6 fält som blir och förblir svarta vid en viss temp som står förtryckt tex, 55 gr, 68 gr, 76 gr, 88 gr, 95 gr.) Jag hittade 2560 kretsar på ebay så dom är beställda, kretskorten likaså. Nu i väntans tider så skall jag testa ut den nya klockmodulen, om jag nu inte måste jobba igen?

[Janson1]

Jag tittade lite på nätet om inkopplingar med flera olika enheter som nyttjar MOSI, MISO och om man vill ha dubbelriktad förbindelse som jag behöver så rekommenderas att alla enheter kopplas parallellt men med varsin chip selekt. Detta innebär att det går åt fyra tampar för en enhet, fem tampar för två enheter osv. Det andra mer likt seriekoppling är bara användbart om man bara behöver kommunikation åt ett håll tex led-driver. Så nu testar jag alternativ ett. Jag får å andra sidan inte det till att fungera heller... Felsökning är på G.

[hawkan]

KLset, jag förstog detta med separata enheter efter jag skrivit inlägget. Visst är det en poäng du har men samtidigt ökar komplexiteten för gemensamma saker som loggning, display och seriellt.
Nu har jag tyvärr inte följt med i allt i själva projektet men cylindrarna behöver inte styras samtidigt, visst är det så? Då sker insprutningen totalt med några hundra Hertz, vilket inte är några som helst problem. Det jag funderar på är om du använder de analoga ingångarna för att styra tidpunkten för insprutning?
SPI med varsin chip select ska fungera, har använt själv.

[Janson1]

För att det inte skall råda några missförstånd. Jag har tre eller fyra separata NANO:sar, två st är ECU:er A och B där endast en är verksam åt gången. Allt dom gör är ytterst tidskritiskt, dom får inte störas av nåt annat krafs. En funktionsbeskrivning följer senare. Den sista eller ev dom två sista NANO:sarna är till övervakningen alena. Dom skall bara samla in data från div givare och det som kommer ut från den aktiva ECU:n, även hålla reda på vilken som är aktiv. Vissa data vill jag ha presenterade på en display såsom varvtal, effektsetting, nån temperatur mm. Men den mesta datan vill jag ha samlad på ett tex SD-kort med tidsangivelse, det är inte nödvändigt med exakt realtid, det räcker med antal minuter från start per gång. Själva ECU:n Har två digitala ingångar som i princip styr alltihopa, en vevaxelingång som känner vevaxelns position och förändring och en kamaxelgivare som känner kammens hemposition, den ingången blir "döv" ett några hundra varv, så en ingång till det mesta. Sedan så finns en analog ingång som känner börvärde varvtal benämnd "gas". Vidare så finns det 7 analoga ingångar till som känner av div temp och spänningar mest för optimering av spridarstart och spridaravstängning.
Sen har den några digitala utgångar som driver varsin spridare via MOS-transistorer. Och några digitala kontrollutgångar som övervakningen sedan tar hand om.

[ViktorSigg]

Jag hoppar in lite sent i tråden men jag kanske kan tillföra något.

Du har alltså 2 st ECU, dessa är naturligtvis tidskritiska. En är master den andra ligger i dvala som reserv.
Du har sedan 1 st kontroll-MCU som enbart gör mindre tidskritiska prylar och håller ECUerna under uppsikt.
Då detta ska användas till flygplan så är det viktigt att prylarna fungerar, framför allt failsafe, dvs eventuellt byte av ECU processor. Är detta korrekt uppfattat?

Jag kan säga hur jag skulle ha strukturerat upp det, så kanske de ger några idéer.

ECU 1&2 skulle jag koppla till signalerna som krävs för realtidskörningen, dvs. vevaxel, kamaxel samt spridare och önskat gaspådrag.
Det bör bli 2 digitala ingångar samt 4 digitala utgångar per ECU enhet, plus en analog ingång.

Jag skulle då ha kopplat Vevgivare och kamgivare till pin 32 och 01 för att köra dessa rutiner med interrupt. Spridarna skulle jag ha kopplat till valfri ledig digital pinne, men hållt mig borta från SPI pinnarna 14, 15 och 16. Analoga gaspedalen skulle jag ha kopplat till valfri analog ingång. Jag skulle även ha hållit pin 13 ledig för kontrollutgång med PWM möjlighet.


Kontroll-MCUn skulle jag koppla alla mindre kritiska givare till, alltså temperatur osv.
Säg att dessa är:
Analog - temperatur 1 (ex. motor)
Analog - temperatur 2 (ex. växellåda)
Analog - temperatur 3 (ex. omgivande lufttemp)
Analog - spänning
Analog - gaspådrag
Analog - reserv
Digital - kamgivare (för varvtal)
Digital - Kontrollinput ECU 1
Digital - Kontrollinput ECU 2

Jag skulle även ha kopplat SPI med chip-select, dvs. 3 pinnar för kommunikationen samt två eller tre valfria pinnar dedikerade till SS ingången på varsin ECU. Alla enheter på samma bus men med varsin SS och kontroll-MCUn som master.

I programmet skulle jag ha strukturerat upp så att varje ECU ger ut en PWM kontrollsignal som följer motorvarvtalet. Denna signal skulle jag ha mätt med kontroll-MCUn som då skulle jämföra sin egen input av varvtal (kamaxelgivare) med inputen från var ECU. Om något felas så används beräkningen att de två som är överens anses vara hela, den avvikande stängs av.

Jag skulle även ha strukturerat upp programmet så att kontroll-MCUn skickar värdena för mindre kritiska givare till varje ECU, några gånger i minuten. Om så behövs så skulle jag polla data från ECUerna också via SPI, men tanken är att ha de värden som skall visas på till exempel en display direkt till kontroll-MCUn som då kan hantera allt i lugn och ro.

Hela grundidén är att att koppla så lite som möjligt till varje ECU, och låta hårdvaru SPIn ta hand om resten. Då denna inte stjäl tid från ECUs huvudloop så borde det ge varje ECU gott om tid att hantera sina uppgifter. Det är det som är fördelen med hårdvaruserial, då man kan använda buffrarna för att skicka och ta emot data "när det passar" så att säga.

Finns såklart mycket mer att tillägga men detta är iallafall min tanke i en sammanfattning.

[Janson1]

Intressant att någon har ungefär samma tanke som en själv. Jag har valt att jag själv bestämmer vilken ECU som skall vara aktiv, för då kan den inte välja fel åt mig... Annars har jag kopplat så som du beskriver, ungefär. Jag har D2 och D3 som digital input från vev och kamgivare för dom är dom ända två som går att interrupta, fast det klarar jag inte av att få till med nån reda så jag har inget interrupt.
Utgångarna är D8, D9, D10, D11 dom kommer från samma port för att få så lika processtid som möjligt. Jag har en kontrollutgång (D7) fast den lämnar ut två pulser per motorvarv, utnycklad från vevaxelns 28_2_28_2 pulståg per varv. På D13 kör jag samma signal som aktiv spridare får så den ger 2 signaler per varv motsvarande motorns arbetstakter. Signalen använder jag till att räkna ut momentanförbrukningen tillsammans med D7:s pulsutgång. Jag har däremot valt att köra in alla analoga signaler direkt till både ECU och övervakare parallellt där det inte är kritiskt vid givarfel och dom kritiska givarna är dubblerade så en aktiv givare bör finnas kvar oavsett per ECU. Det kommer även att finnas två separata vevaxelgivare med varsitt tandhjul och som drivs från två olika strömkällor, dels det vanliga huvudbatteriet och dels via ett ECU-backup batteri som diodladdas och toppladdas via ett extra motstånd. Bägge batteriernas spänning övervakas av ECU och övervakningsArduinon.
Det här med SPI är jag egentligen inte alls påläst på fast jag fuskat med det nån gång, men det låter som ett hållbart förslag. Att ge ut en pwm signal baserad på varvtalet har jag ju redan så det skulle väl gå att ordna... Men stannar nu motorn så skulle jag som första åtgärd skifta ECU och som andra åtgärd stänga av och starta om elen, så den kanske är lite onödig?
I min sketch så har jag gett ganska mycket tid till just analogläsning så tidsmässigt är det nog inga problem att låta ECU hålla reda på värdena. Det ligger även inbyggt i (ska göra i alla fall då jag medvetet inte gjort detta än) i ECU:n om en givare går sönder, ligger utanför "fönstret" då skall den ta ett förutbestämt värde tex om vattentempen saknas blir det i beräkningsgrunden 70 grader, och felavläst värde blir kryss i displayen och skrivs ut på SD-kortet som uppmätt felvärde, allt för lättare felsökning... Alla ben jag hänvisar till är Arduino NANO och UNO som referens.
Hoppas detta är förståeligt. Jag kanske kan lägga ut sketcherna om intresse finns...

[Janson1]

Det verkar som SD-drivkortet med eller utan SD-kort belastar ner MOSI, MISO och SCK? Skall prova att lägga motstånd i serie, kanske gör det nån nytta?

[Klas-Kenny]

Det är väl en 5V Arduino du har?
Ett SD-kort kör 3.3V, vilket innebär att det måste finnas någon nivåskiftare på skölden. Kan mycket väl vara så att miso där aldrig tri-stateas vilket gör att inget mer går att koppla in på Miso, på Arduinons sida om nivåskiftaren.

[Janson1]

Jag provar just nu ut om det finns nåt lämpligt värde på motstånd mellan SD-kortet och Arduinon... När/om den möjligheten är uttömd, då får det bli en annan lösning.

[Janson1]

Nu är det testat. Bästa motståndskompromissen är 560 ohm. Men när jag först hämtar klockdata på RTC och nästa vända skriver den datan till SD-kortet, då skiter det sig. Om jag kommer på nåt bra sett att först hämta klockdata och sen spara den i en variabel och sen skriva in variabelvärdet på SD-kortet, det borde gå även om jag inte riktigt vet hur... Nu kan man i alla fall ha både RTC och SD-minne på samma snören.

[Janson1]

Fixat! Först hämta klock/datum, sedan mellanspara som String sedan anropa Stringen och putta in datan till SD-kortet.

[Janson1]

Nu har kretskortet kommit och en viss förbestyckning är gjord. Under sitter en NANO som snart skall amputeras. Men först skall 2560 kretsen komma på plats. Nu får jag en expanderad NANO med dubbelt så många analoga och ungefär dubbelt så många digitala, det är bara fortsätta att programmera...

IMG_20180213_213909.jpg