Nou Razorx-Fijne Hokken: LV-NJ

jeroen74 · 03-03-2014 00:26:31

Een beetje moderne MCU zal zijn porten bij een reset instellen als een input zonder pull up of down. Kun je extern bepalen wat er moet gebeuren. Een 8051 en derivaten echter niet. Daar is een port pin een pull-up weerstand en een mosfet om de pin laag te trekken (en een mosfet die 1 klokcyle of zo bij de overgang van nul naar 1 actief is om wat sneller te schakelen).

Ik heb ooit eens een auto up/down gemaakt voor de electrieke ramen met een 8051 waarbij een hoog niveau van de MCU uitgang het relais activeerde. Toen ik een keer een lege akku had, hield de reset supervisor (een MAX690) de MCU in reset hield wat tot gevolg had dat het raam onbestuurbaar naar beneden ging. Toen snel maar omgebouwd naar actief laag

razorx · 03-03-2014 20:54:11

Bij de eerste init zal een PIC "alle" poorten als input instellen. Het hing dus een beetje van de gebruikte communicatie library af wat die zou doen.

Er bleek inderdaad kortstondig sprake te zijn van een input state bij het initialiseren.
Als je naar mijn interface naar de OBD aansluiting kijkt zie je al snel wat er gebeurde.

(-edit- De pull-up weerstand van 1k mag rustig naar de 470 ohm 20mA )

Bij de init zal de eerste transistor sperren en de tweede zal de K-lijn van de OBD interface omlaag trekken. Niet de bedoeling.
Als allereerste een "1" naar de juiste poort sturen verhielp dat probleem.

Verder heb ik nog wat gewerkt aan de uitlijning van de diverse waarden op het display. Floating point berekeningen zijn op zo een PIC processor uit den boze, net als krachtige stringmanipulatiefuncties. Dus wat slimmigheidjes uitgehaald.

Omdat het circuit aan een geschakelde + hangt wil je voorkomen dat het logging commando nog een tweede keer gestuurd wordt.
Wat ik gedaan hebin het eerste gedeelte van de software, voor de data lees lus is het volgende:
(Even heel simplistisch weergegeven)

wait_for_silence(timeout)
if silence send logging command and display "Start engine."

start tracing data

Lijkt nu aardig te draaien. Omdat de "pauzes" tussen de bytes, headers en footers niet echt vast liggen, zal ik misschien nog wat moeten werken aan de diverse time outs.

De ECU mag immers alleen data zenden als hij niets beters te doen heeft. Ik weet nog niet hoe net het in de ECU geprogrammeerd is.

LouisXIV · 03-03-2014 21:13:36

Citaat van: razorx op 03-03-2014 20:54:11
Bij de eerste init zal een PIC "alle" poorten als input instellen. Het hing dus een beetje van de gebruikte communicatie library af wat die zou doen.

Er bleek inderdaad kortstondig sprake te zijn van een input state bij het initialiseren.
Als je naar mijn interface naar de OBD aansluiting kijkt zie je al snel wat er gebeurde.
http://www.paerl.it/volvo/2014022303.jpg

Bij de init zal de eerste transistor sperren en de tweede zal de K-lijn van de OBD interface omlaag trekken. Niet de bedoeling.
Als allereerste een "1" naar de juiste poort sturen verhielp dat probleem.

Verder heb ik nog wat gewerkt aan de uitlijning van de diverse waarden op het display. Floating point berekeningen zijn op zo een PIC processor uit den boze, net als krachtige stringmanipulatiefuncties. Dus wat slimmigheidjes uitgehaald.

Omdat het circuit aan een geschakelde + hangt wil je voorkomen dat het logging commando nog een tweede keer gestuurd wordt.
Wat ik gedaan hebin het eerste gedeelte van de software, voor de data lees lus is het volgende:
(Even heel simplistisch weergegeven)

wait_for_silence(timeout)
if silence send logging command and display "Start engine."

start tracing data

Lijkt nu aardig te draaien. Omdat de "pauzes" tussen de bytes, headers en footers niet echt vast liggen, zal ik misschien nog wat moeten werken aan de diverse time outs.

De ECU mag immers alleen data zenden als hij niets beters te doen heeft. Ik weet nog niet hoe net het in de ECU geprogrammeerd is.

Nice. Ik snap niet helemaal alles maar het ziet er wel prachtig uit.

Maarten-t5 · 03-03-2014 21:16:12

Op de arduino heb je een serialEvent() functie. Daarmee kun je gewoon je frames binnenhalen zodra ze in de buffer verschijnen. Scheelt n hoop experimenteren met timeouts. Je mailde mij laatst dat je ook een soort arduino achtige software had om je pic mee te programmeren, zit daar die functie ook niet in?

Wat ik ervan begreep is dat de ecu, zoals je al zei, alleen frames spuugt als ie nix beters te doen heeft. Voor zover ik weet spuugt ie gewoon met een simpele functie in de main loop de data over de k-line. De belangerijke bezigheden van de ecu worden met interrupts geregeld, dus het dataspugen kan naar mijn weten mid-frame onderbroken worden.

razorx · 03-03-2014 21:22:22

Mhh, pijnlijk. Dank je Maarten. Zie door jouw post dat ik een vergelijkbare functie heb: Interrupt on Rx Event.

Niet zo geavanceerd als de Arduino functie, maar kan ik wel wat mee doen.

-edit- Ik zeg het wat dom: Heb geen hapklare routines. Maar als ik het omzet naar afhandeling middels interrupts, wordt het allemaal wat frisser.

Maarten-t5 · 03-03-2014 21:32:46

Heb zelf ook even geworsteld hiermee. Het synchroniseren van de arduino en de ecu om n combinatie te maken van de twee frames had ook wat voeten in aarde.

razorx · 03-03-2014 21:41:24

Citaat van: Maarten-t5 op 03-03-2014 21:32:46
Heb zelf ook even geworsteld hiermee. Het synchroniseren van de arduino en de ecu om n combinatie te maken van de twee frames had ook wat voeten in aarde.

Dat geloof ik graag. Even tussendoor: 62500 Baud lijkt vooalsnog in TunerPro een hogere framerate op te leveren dan 125000.

Met het temmen van de koudestartverrijking ben ik ook wat verder, maar nog niet klaar voor definitieve data.

jeroen74 · 03-03-2014 22:21:31

Als je een pull up weerstandje aanbrengt op de basis van de eerste transistor is het hele probleem toch verholpen? Is de reset en init timing van je MCU ook opeens irrelevant.

Seriele communicatie moet je altijd interrupt driven doen, nooit polled. Tenzij je de luxe hebt van een UART met hele diepe FIFO's. In de ISR dump je de ontvangen characters is een ringbuffer en leest die uit in de main-loop. Heb je heel wat meer 'elastiek' in je timing.

Overigens zijn er ook kleine ARM gebaseerde controllertjes in 28 DIP die rustig zo 60 MIPS doen

(Cortex M0 en M3). Mocht je wat extra power willen

razorx · 03-03-2014 22:37:54

Het probleem is al verholpen.

Maarten-t5 · 04-03-2014 10:02:14

Hmm interresant. Toch eens experimenteren met die baud rates.

razorx · 05-03-2014 20:42:21

Ik ben een eigenwijze flapdrol.

Ik was van plan de communicatie pas later om te zetten naar een interrupt gebaseerde afhandeling.
Dacht het mezelf makkelijk te maken, met een afhandeling op basis van polling en timeouts.

Nog geen uur na het bericht van Maarten, had ik het geheel draaiende op basis van interrupts. De communicatieroutine is vele vele malen simpeler en handelt zowel de test opstelling met de lage framerates als real life goed af.

Dus Maarten en Jeroen: Tegen beter weten in zat ik onhandig te klootviolen.

Het is verstandig meteen een logische "1" te sturen naar de verzendende poort. Als dit gedurende de eerste paar uS gebeurt is er niets aan de hand.

Tja, alles draait op een klein maar verhoudingsgewijs snel RISC processortje. Dat is meteen ook een leuke sport:
Hoe houd je het programma zo klein mogelijk?

Het programma is ondanks wat "luxe" en foutafhandeling een 6k byte groot. Vind ik leuk, kan ik ook niets aan doen.
En dat ondanks de hogere programmeertaal waarin het geschreven is.

Lastiger was het de stack diepte beperkt te houden en de code toch leesbaar te laten zijn.

Enfin: Big fun hier.

razorx · 09-03-2014 00:35:14

Tja, wat doe je als een programmeerbare chip niet altijd doet wat je wilt?
Het antwoord is heel simpel. Mijn grootvader heette Tony S. Ik heb zijn voorbeeld gevolgd.

Je kijkt die chip diep en indringend aan, pakt een prullenbak en zet die in de buurt van die chip. Chipje voelt zich al wat ongemakkelijk.
Je blijft die chip indringend aankijken en je gooit iedere programmatuur van een ander in de prullenbak. Vanaf dat imoment weet de processor dat er een goede reden is voor processorpaniek. Jankerds zijn het.

Daarna pak je een zak ribbelchips van goede kwaliteit en pakt er een chipje uit dat je vervolgens heel langzaam in je mond steekt om het vervolgens te vermalen tussen je kaken. Nu pas is het voor de Microchip duidelijk wie de baas is.
Zo, punt.

Terwijl FJ vrolijk fluitend wegdribbelt met een restje ribbelchip en de Microchip nog aan het nabibberen is zal ik vertellen wat er is gebeurd.

IWAW meter zaken
Het metertje moest onder alle omstandigheden stabiel zijn. Het hangt immers direct aan de ECU van een wagen waar een levend mens in rijdt. Ehh dat hoop ik.

Ik heb het systeem aardig gepest. Nu kan het irreële ECU frame rates van boven de 60 fps aan. In de praktijk kom je niet veel verder dan een kleine 20. Nooit en te nimmer mag zo een metertje, door een software fout zomaar data sturen naar de ECU. Dit is in mijn ogen een essentiële verantwoordelijkheid.

Als je programmeert is het heel normaal programmatuur van anderen te gebruiken. Werkt makkelijk, maar er is geen mens die die code wil controleren. Het grootste deel daarvan is in de prullenbak gegaan. Meer volgt.

Ik zie de ikwilalleswetenmeter niet als gadget. Ik wil ieder ritje kunnen loggen. Ook zonder laptop. De logging moet gewoon volkomen op orde en comfortabel zijn voordat ik verder ga dan de huidige setup voordat ik verder mag. Ideeën kunnen veranderen, maar zo zie ik het voorlopig.

Status tot nu toe voor het display:
AFR, KVS, turbo druk, LTFT part load, STFT. Een druktoetsje geeft je de kans te bladeren tussen de diverse schermen.

Er komen nog wat extra schermpjes bij met LTFT idle, ECU voltage, en boost aanpassingen door het systeem. En wie weet wat?
Olietemperatuur en druk. Ik ga niet alle mogelijkheden gebruiken, alleen dat wat ik voorlopig wil. Kan het altijd aanpassen.

Wat ik heel graag wil is anytime logging naar SD kaartje of USB stick.

Tuning zaken
Zolang ik geen grotere MAF (LMM) heb, ga ik hier niet mee verder.
Ik moet wel zeggen , dat de huidige setup ronduit fijn rijdt. De wagen voelt levendig aan met een vloeiende overgang van normaal rijden naar de wegpiraat modus.
De turbo doet een fractie eerder mee dan standaard en dan heel voorzichtig, tot je meer vraagt. Geen abrubt binnenkomen, maar geleidelijk en wat eerder dan gebruikelijk.

Al met al een prettige en controleerbare reactie op het gaspedaal en een zeer plezierige rij ervaring.

UserID6342 · 09-03-2014 08:34:37

Ben vreselijk benieuwd Yits hoe de auto nu rijd ! Gaan we straks meemaken

razorx · 09-03-2014 21:09:45

Vandaag een erg gezellig dagje gehad. Even wezen buurten bij Dirk. We hebben het wereldrecord o.h.-een verbeterd. Veel gekletst over menselijke en technische zaken.

De terugrit was bedoeld op zo veel mogelijk relevante situaties te loggen. Het was druk op de weg, maar van tijd tot tijd was er toch een kans wat zaken te testen.

-De absurde koudestartverrijking heb ik nu wel onder controle. Aardig getemd zonder enige concessie.
-De "R" typische boost heb ik niet meer. Gewoon een stabiele max turbodruk van 1Bar (16T)
-De WOT enrichment tabel lijkt niets te doen. Lager dan een AFR onder volle last van ongeveer 12,8 kom ik niet.

Ik gaf al eerder aan dat ik WOT enrichment als lapmiddel zie. Maar zolang mijn LMM de luchtstroom niet aankan en ik hier niets aan gedaan heb moet ik het met WOT verrijking doen. Snap niet waarom die tabel geen invloed lijkt te hebben.
Het is overigens aardig om te zien dat de ECU de STFT weergave onmiddellijk stopt tijdens een WOT moment.

-Dirk gaf na een ritje aan dat er wat meer druk bij mag tussen de 2000 en 3500RPM. Klopt.
Dat is een kuiltje dat fabriekshalve in de "Target Load Setpoint" tabel zit. Dat kuiltje zit ook in mijn mapping. Net weggevlakt. Binnenkort even testen.
Ik vermoed dat dat turbodruk kuiltje er door de ontwerpers bewust is ingezet. Dit is wel een belangrijk werkgebied van de motor. Zal vast bedoeld zijn om het verbruik wat te reduceren.
Dit deukje bedoel ik:

Bezig glad te strijken met de virtuele strijkbout:

Wat de beveiliging voor de motor in het hoge einde aangaat: Volvo heeft gekozen voor een fuel cut off én een load cut off. Ik geef de voorkeur aan alleen de laatste. Kan een discussiepunt zijn.

razorx · 09-03-2014 22:22:47

Zoals ik even een tabelletje aanpas lijkt het wat simpel. Dat is het niet.
Deze lichte verhoging, niet alleen bij het deukje zal een licht overshoot probleem van mijn turbodruk wegwerken.

De "Target load Setpoint" tabel heeft immers een complexe relatie met de "Duty Cycle Pilot Control" tabel. Zeg maar de inzet waarmee het regelsysteem de gevraagde doelbelasting wil bereiken.