E34/E32 moottorin dataa ajotietokoneen LCD:lle

[pheno]

Jos nyt ymmärsin oikein niin voisiko vilkkumisen välttää sillä että lukee dme:ltä datan ja kirjoittaa sen kaksi kertaa mittariin, näin tulisi tuplasti aikaa lukea dme:tä. Toki päivitysnopeus hidastuu mutta ehkä se on tässä kohtaa enemmänkin teoreettista hidastumista kuin käytännössä lukemiseen vaikuttavaa.

Kyllä tossa on ajatusta. Voisi tehdä niin, että aina ennen JA jälkeen ecu:n datan lukemista päivitetään LCD. Siihen tulee lisää 16ms että ei se juuri näy eikä tunnu.

[Supra^]

Kyllä tuon nopeuden pitäisi riittää, jos lasketaan että eculle paketin kirjoitus n. 6ms ja luku 40ms. Mittaristolle kirjoitus n. 16ms ja eculle odotusaikaa 20ms , jonka pitäisi riittää. Mulla on nyt tosiaan liian iso delay eculle (50ms) ja koitan seuraavaksi tuota 20ms. Nyt on ihan "delay" käskyt käytössä mutta ei taida olla ihan paras tapa kun se ilmeisesti blokkaa kaikki keskeytyksetkin yms. Onko tämä kovin huono tapa ?? Voisi tosiaan koittaa tehdä koodista sellanen tilakone, kuten ehdotit eli looppi pyörii kokoajan ja sitten tarkistetaan eri ehdoilla mitä pitäisi tehdä.

Mä käytän yleensä tällaisia:

if((millis() - oldTime) > 100)
    {
     tee jotain;
     oldTime = millis();
    }

Eli jos edellisestä loopista on mennyt yli 100ms, suoritetaan tuo koodinpätkä jossa lopuksi resetoidaan oldTime-muuttuja vastaamaan nykyhetkeä. oldTime-muuttuja voi olla vaikka tyyppiä unsigned long.

Delayn käyttämisessä sulla tulee viimeistään ongelmia kun yrität OLEDille kirjoitella jotain, se ei tykkää siitä _yhtään_. Yleisestikin kaikia Delay-komentoja pyritään välttämään juuri sen takia että täysin kaikki toiminnot pysähtyvät siksi aikaa.

Toihan on siisti toi oled, onko sulla jotain käsitystä miten nopea esim. parin tekstirivin kirjoitus on tuolle oled:ille? meneekö aikaa 1ms tai 10ms tai enemmän.. Tilasin nimittäin juuri samoja näyttöjä.

En ulkoa muista, mutta tässä hyvä vertailu videon muodossa: https://www.youtube.com/watch?v=lkWZuAnHa2Y

Mukava kuulla, että on ollut hyötyä! Oletko koittanut tuolla sun e91 dieselillä noita TestO.n "Custom Jobeja" ? Ihan vaan kiinnostaisi tietää toimiiko miten hyvin..

Onhan tossa mielessä parannuksia mitä voisi tehdä lisääkin.

En ole ehtinyt niihin vielä tutustua, ehkä tässä lähiaikoina.

[pheno]

Mä käytän yleensä tällaisia:

if((millis() - oldTime) > 100)
    {
     tee jotain;
     oldTime = millis();
    }

Eli jos edellisestä loopista on mennyt yli 100ms, suoritetaan tuo koodinpätkä jossa lopuksi resetoidaan oldTime-muuttuja vastaamaan nykyhetkeä. oldTime-muuttuja voi olla vaikka tyyppiä unsigned long.

Delayn käyttämisessä sulla tulee viimeistään ongelmia kun yrität OLEDille kirjoitella jotain, se ei tykkää siitä _yhtään_. Yleisestikin kaikia Delay-komentoja pyritään välttämään juuri sen takia että täysin kaikki toiminnot pysähtyvät siksi aikaa.



En ulkoa muista, mutta tässä hyvä vertailu videon muodossa: https://www.youtube.com/watch?v=lkWZuAnHa2Y




En ole ehtinyt niihin vielä tutustua, ehkä tässä lähiaikoina.

Juu, toi koodi näyttää paljon paremmalta, ajattelin kanssa muokata nykyisen siihen muotoon. Hyvä kun sanoit delay:stä niin ei tarvi ihmetellä miksei toimi :-)

Tuosta kun tekee oman luokan ecu:lle ja mittaristolle metodi esim. updateDisplay(), jossa tarkistetaan tuo aika, niin koodi selvenee huomattavasti.

Ok, eli puhutaan millisekuntien päivityksestä. Eipä tuo kauheasti ole, mutta mittaristoon ei taida juuri ehtiä samaan aikaan kirjoittamaan, paitsi jos käyttä tuon videon tekijän omaa kirjastoa joka oli aika nopea, vain 7ms. per rivi..

[pheno]

piti vähän säätää noitten desimaalien kanssa, kun avr:n sprintf ei tue %f ollenkaan

[pheno]

Tää on näköjään vähän oma maailmansa mikropiireille ohjelmointi tai no sanotaan että "PC ohjelmoijalle" uusi. Mullahan oli esim. tossa alunperin sarjaportin luvussa blokkaava funktio käytössä: readBytes. Täytyy muuttaa tuo ohjelma niin, että looppi pyörii kokoajan ja tarvittaessa tehdään muita juttuja jos sarjaportissa ei olekaan dataa vielä tullut. Näin pystyy helposti ylläpitämään tuota 100ms aikaväliä e34lcd:n päivityksessä. Onhan tossa kuitenkin 16Mhz:n kellotaajuus, niin kyllä siinä 1ms:n aikanakin ehtii aika monta asiaa tekemään..

[pheno]

Supra: Onko kokemuksia hw debuggereista? Lueskelin että suht halpa olisi avrdragon joka ainakin megan kanssa pitäisi toimia. Lähinnä toki kiinnostaisi saada toimimaan tämän 328p:n kanssa.

Nyt on muuten koodi täysin "non-blocking" lähinnä sarjaportin luvun osalta sekä ecun tauon kanssa. Ei yhtään delay:ta siis. lcd:tä kerkee päivittämään helposti tarpeeksi nopeasti.

[aae30]

Juurikin tässä tänään leikin Arduino Nano:n kanssa ja hieman on vielä softan kanssa säätämistä. Mutta kyllähän se toimii melkein 100%:sesti. Nano:n UART:in TX,RX on K-linjassa kiinni ja SoftwareSerial:illa keskustellaan mittariston linjan kanssa. Sinne ei nyt muuta tarvi tehdä, kuin kirjoittaa. Noita piirejä mitä tuossa piirtelin en koskaan tullut tehneeksi, koska software serial hoitaa homman.

Missäs tuohon K-lineen kannattaa 'liittyä'? Suoraan mittariston takana?

Kattelin E34 540:n ETM:ää ja siellä on ainakin AGS A5S 560Z boksissa CAN-L ja CAN-H pinnit 85 ja 86, josta voi lukea CAN-dataa. Pinnit menee suoraan ECU:un..

Vaihdetietoja. Ilmeisesti mittariston pinnit 4,5,6 ja 11 on automaattilaatikon vaihdetiedot. ETM:ssä lukee "Automatic transmission range switch"

Menee vielä hetki, että ehdin noita e34 asioita ihmettelemään, mutta Kiitos

Tää on näköjään vähän oma maailmansa mikropiireille ohjelmointi tai no sanotaan että "PC ohjelmoijalle" uusi. Mullahan oli esim. tossa alunperin sarjaportin luvussa blokkaava funktio käytössä: readBytes. Täytyy muuttaa tuo ohjelma niin, että looppi pyörii kokoajan ja tarvittaessa tehdään muita juttuja jos sarjaportissa ei olekaan dataa vielä tullut. Näin pystyy helposti ylläpitämään tuota 100ms aikaväliä e34lcd:n päivityksessä. Onhan tossa kuitenkin 16Mhz:n kellotaajuus, niin kyllä siinä 1ms:n aikanakin ehtii aika monta asiaa tekemään..

Veikkaisin, että ennen joulua sua jo ahdistaa toi 16Mhz, puhumattakaan flashin yms. rajoitteista
Itseä tökki ehkä eniten arduinon IDE, ja C++ 8bittisellä... niin turha
Tuli testattua 'logic analyzerilla' kuinka paljon arduino hidastaa vrt. perus avr libc koodiin 'pinnin flippailussa',
ja sen jälkeen ei enää lohduttanut, että kaikki omat viritelmät käyttää 20Mhz kelloa jonka kanssa ei ollut kyllä ikinä sinänsä mitään ongelmia..

Nyt on muuten koodi täysin "non-blocking" lähinnä sarjaportin luvun osalta sekä ecun tauon kanssa. Ei yhtään delay:ta siis. lcd:tä kerkee päivittämään helposti tarpeeksi nopeasti.

Se että koodi blokkaa tekee siitä usein yksinkertaisemman, mutta vaatii kyllä threadit yms., eli käytännössä käyttöjärjestelmän alle


Kuvissa omat 'proto-viritelmät', arduino+spi2can-viritelmä ja stm32f4 discovery(168Mhz, hw-debuggeri st-link samalla levyllä jne.) + 2xcan levy, joka kuvissa on jo irti 'palaneesta' discoverysta, johon unohdin virrat breadboardista testi-setuppia purkaessa
Tein noille f4sen kanssa toimiville levyille jumppereilla mahdollisuuden terminoida väylä 120ohmin vastuksella,
ja koodin puolesta discovery lähettää väylästä toiseen kaiken molempiin suuntiin, ja toki loggauksen vuoksi f4sen usb tukea käyttäen (virtuaalisen)sarjaportin kautta koneelle suuntatietoineen.
Kait toi 'modulien' eristäminen väylästä auttaa datan kanssa. Täytyykin tilata lisää osia, ja discoveryja, että sais ecun+laatikon boksit erilleen asap purkamatta mittariston snifferiä
Toinen 2xcan + discovery on jo autossa, ja olisin dataakin ehkä ulos saanut, mutta inpa/auto-läppäri vastusti mm. puuttuvilla ajureilla + kännykästä akku vähissä jne., huomenna uus yritys..
F4discoveryt alle 20e/kpl, että jos ei tuuri käy huomenna kun lyön akun kiinni, niin ei haittaa, mutta en kuitenkaan usko minkään hajoavan vaikka miten kytkennöissä epäonnistuisin

[Supra^]

Supra: Onko kokemuksia hw debuggereista? Lueskelin että suht halpa olisi avrdragon joka ainakin megan kanssa pitäisi toimia. Lähinnä toki kiinnostaisi saada toimimaan tämän 328p:n kanssa.

Nyt on muuten koodi täysin "non-blocking" lähinnä sarjaportin luvun osalta sekä ecun tauon kanssa. Ei yhtään delay:ta siis. lcd:tä kerkee päivittämään helposti tarpeeksi nopeasti.

Ei ole kokemusta noista, aikalailla lastenkengissä tämä koko arduino/raspi-kuvio muutenkin. Tuntuu että kaikesta tietää vähän, muttei mistään tarpeeksi.

[pheno]

Ei ole kokemusta noista, aikalailla lastenkengissä tämä koko arduino/raspi-kuvio muutenkin. Tuntuu että kaikesta tietää vähän, muttei mistään tarpeeksi.

No sama täällä, pikkuhiljaa oppii aina lisää. Tärkeintä tässä nyt itselle ollut se, että saa tehtyä ja jotain aikaiseksi. Katsotaan myöhemmin haastavempia boardeja. Arduino:lla on helppo keskittyä itse ongelman ratkomiseen, copy-paste koodia löytyy ja valmiita kirjastoja kaikenlaisten sensorien, näyttöjen yms. käyttöön. Nopeasti saa aikaiseksi. Se ei välttämättä tarkoita, että tietäisi mikroprosessoreista jotain. Toisaalta jos olisi aloittanut jollain STM32 alustalla, niin aikaa olisi kulunut potenssiin 5 eikä siltikään toimisi.

[pheno]

Missäs tuohon K-lineen kannattaa 'liittyä'? Suoraan mittariston takana?


Menee vielä hetki, että ehdin noita e34 asioita ihmettelemään, mutta Kiitos


Veikkaisin, että ennen joulua sua jo ahdistaa toi 16Mhz, puhumattakaan flashin yms. rajoitteista
Itseä tökki ehkä eniten arduinon IDE, ja C++ 8bittisellä... niin turha
Tuli testattua 'logic analyzerilla' kuinka paljon arduino hidastaa vrt. perus avr libc koodiin 'pinnin flippailussa',
ja sen jälkeen ei enää lohduttanut, että kaikki omat viritelmät käyttää 20Mhz kelloa jonka kanssa ei ollut kyllä ikinä sinänsä mitään ongelmia..


Se että koodi blokkaa tekee siitä usein yksinkertaisemman, mutta vaatii kyllä threadit yms., eli käytännössä käyttöjärjestelmän alle


Kuvissa omat 'proto-viritelmät', arduino+spi2can-viritelmä ja stm32f4 discovery(168Mhz, hw-debuggeri st-link samalla levyllä jne.) + 2xcan levy, joka kuvissa on jo irti 'palaneesta' discoverysta, johon unohdin virrat breadboardista testi-setuppia purkaessa
Tein noille f4sen kanssa toimiville levyille jumppereilla mahdollisuuden terminoida väylä 120ohmin vastuksella,
ja koodin puolesta discovery lähettää väylästä toiseen kaiken molempiin suuntiin, ja toki loggauksen vuoksi f4sen usb tukea käyttäen (virtuaalisen)sarjaportin kautta koneelle suuntatietoineen.
Kait toi 'modulien' eristäminen väylästä auttaa datan kanssa. Täytyykin tilata lisää osia, ja discoveryja, että sais ecun+laatikon boksit erilleen asap purkamatta mittariston snifferiä
Toinen 2xcan + discovery on jo autossa, ja olisin dataakin ehkä ulos saanut, mutta inpa/auto-läppäri vastusti mm. puuttuvilla ajureilla + kännykästä akku vähissä jne., huomenna uus yritys..
F4discoveryt alle 20e/kpl, että jos ei tuuri käy huomenna kun lyön akun kiinni, niin ei haittaa, mutta en kuitenkaan usko minkään hajoavan vaikka miten kytkennöissä epäonnistuisin

Joo, mittariston takaa löytyy iso nippu piuhoja, joista löytyy K-line, mittariston LAC ja DAC, sekä monta muutakin. RPM ja nopeus löytyy näköjään myös. Ollessaan analogisignaali, niin niillä voisi kai teoriassa laskea auton hevosvoimat/väännön tietyllä hetkellä kun päivitysnopeuskin on "hieman" eri luokkaa mitä ecu:lta luettaessa

Toi F4 Discovery on kyllä edullinen lankku, mistä noita Suomesta saa edullisimmin ? STMF1-F4:een löytyy myös jonkinasteinen Arduino tuki: http://www.stm32duino.com/index.php ja koodi: https://github.com/rogerclarkmelbour...i/Installation nucleo-f103rb oli siellä mainittu. Siihen voisi siirtyä, jos sama Arduino koodi toimisi tuossa stm32:ssa. Loppujen lopuksi pitäisi vaan löytää joku kompaktimpi levy kokoluokkaa Arduino Nano/Mini. Kai noista STM32:ista jotain mini-versioitakin on olemassa?

Laitahan vähän updatea sitten miten CAN-BUS datan luku onnistui. Eli ymmärsinkö oikein, että E39:n mittaristo ei välttämättä toimi suoraan tuon dieselkasin moottorinohjauksen kanssa, vai miten ja sentakia olet tutkimassa liikennettä?

[pheno]

Nyt olis Maple Mini-klooni tilattu, jossa SMT32F103xxx. Huimat $4 per kpl. Huomattavasti paremmat speksit mm. 72Mhz, 128kB flash, 20kB RAM, 3 UART:tia, jne. Noilla tehoilla päivittää jotain näyttöäkin jo aika ripeästi. Lisäksi tilasin F103RB nucleon, jotta pääsee testaan debuggausta stlink:kiä.

[aae30]

Nyt olis Maple Mini-klooni tilattu, jossa SMT32F103xxx. Huimat $4 per kpl. Huomattavasti paremmat speksit mm. 72Mhz, 128kB flash, 20kB RAM, 3 UART:tia, jne. Noilla tehoilla päivittää jotain näyttöäkin jo aika ripeästi. Lisäksi tilasin F103RB nucleon, jotta pääsee testaan debuggausta stlink:kiä.

Ei todellakaan huono valinta
ChibiOS 'tukee' F103xxx, ja löytyy perus usb-serial demot molemmille levyille.
Suosittelen. ST:n 'kirjastot' ovat sen luokkaista 'insinöörikoodia', että
Enemmän arduinon suuntaisen kokemuksen saat ChibiOS:n kanssa,
ja sen kanssa aloittaakseen kannattaa ladata ChibiStudio,
esimerkki koodit + compile/upload/run|debug kaikki yhdessä helpossa paketissa.
Uskoisin, että ajurit 'käyttöohjeineen' löytyy lähes kaikelle mitä F103xxx tarjoaa.

[aae30]

Joo, mittariston takaa löytyy iso nippu piuhoja, joista löytyy K-line, mittariston LAC ja DAC, sekä monta muutakin. RPM ja nopeus löytyy näköjään myös. Ollessaan analogisignaali, niin niillä voisi kai teoriassa laskea auton hevosvoimat/väännön tietyllä hetkellä kun päivitysnopeuskin on "hieman" eri luokkaa mitä ecu:lta luettaessa

Toi F4 Discovery on kyllä edullinen lankku, mistä noita Suomesta saa edullisimmin ? STMF1-F4:een löytyy myös jonkinasteinen Arduino tuki: http://www.stm32duino.com/index.php ja koodi: https://github.com/rogerclarkmelbour...i/Installation nucleo-f103rb oli siellä mainittu. Siihen voisi siirtyä, jos sama Arduino koodi toimisi tuossa stm32:ssa. Loppujen lopuksi pitäisi vaan löytää joku kompaktimpi levy kokoluokkaa Arduino Nano/Mini. Kai noista STM32:ista jotain mini-versioitakin on olemassa?

Laitahan vähän updatea sitten miten CAN-BUS datan luku onnistui. Eli ymmärsinkö oikein, että E39:n mittaristo ei välttämättä toimi suoraan tuon dieselkasin moottorinohjauksen kanssa, vai miten ja sentakia olet tutkimassa liikennettä?

Nyt vasta huomasin edittis ylläolevaan
Luulis mini-versioitakin löytyvän, mutta itse en ole toistaiseksi edes etsinyt.

Dataa sain jo, mutta en ollut 'formaattiin' tyytyväinen,
enkä laiskana jaksanut vääntää mitään skriptaa korjaamaan sitä,
niin korjasin koodin ja seuraavalla käynnillä taas uus yritys..
Yksi autolla käynti meni väärän baudraten takia pieleen,
ja läppäriä en oo jaksanut säätää että sopis muuhun kuin loggaukseen/inpaan autolla

Niin siis kyllä tässä päällimmäisenä on suunnitelmissa vain e39 dme+ags ja e34 mittaristo parittaa yhteen.
Sivussa olisi kiva toki oppia mitä kaikkea 'kori kohtaista' oleelliset purkit väylään lähettää,
jos siellä jotain olisi minkä muokkaus ns. lennosta asioita parantaisi.
Ja kun en millään tahtois sijoittaa mihinkään icomiin tms.,
ja opetella saksaa eri asetusten kanssa jne., ajatuksella että jos vaikka onnistuis
Jos ja kun e39v8d toteutuis ni se olis ehdottomasti koiran takia toukkaan,
josta tulee mieleen esim. takaluukun/lasin viestit mittaristossa, tajuaako e38 koodilla oleva mittaristo?
Eli ihan vain varmuuden vuoks haluisin sitten olla esim. mittaristoon koskematta

[pheno]

Ei todellakaan huono valinta
ChibiOS 'tukee' F103xxx, ja löytyy perus usb-serial demot molemmille levyille.
Suosittelen. ST:n 'kirjastot' ovat sen luokkaista 'insinöörikoodia', että
Enemmän arduinon suuntaisen kokemuksen saat ChibiOS:n kanssa,
ja sen kanssa aloittaakseen kannattaa ladata ChibiStudio,
esimerkki koodit + compile/upload/run|debug kaikki yhdessä helpossa paketissa.
Uskoisin, että ajurit 'käyttöohjeineen' löytyy lähes kaikelle mitä F103xxx tarjoaa.

Näytti tuo ChibiOs ihan mielenkiintoiselta ja sillä pääsisi tekemään jo paljon fiksumman näköistä ja luettavampaa koodia vrt. Arduino. Ollessaan ihan oma RTOS käyttiksensä, jossa on toteutettu aikalailla kaikki tarpeellinen (taskit, threadit, synkronoinnit, yms.) ja enemmän. Saattaa vaatia enemmän aikaa opetella miten sisäinen töidenjärjestelijä yms. toimii. Toi on kätevä, että voit antaa "deadlinen", jonka jälkeen suorituksen on palattava takaisin. Tuolla päästään eroon siitä Arduino- tyylisestä koodauksesta, jossa jatkuvasti tarkistetaan millis()-käskyllä nykyistä aikaa ja että onko menty yli sallitun ajan. En ole ihan varma miten hyvin tuo tukee esim. eri näyttöjä. Mutta oli tuossa esim. u8glib:issä tuki ARM:ille myös, mutta se ei nyt vielä tarkoita että kääntyy suoraan ChibiOs:ssa

[jonttuks]

Olis tarkoitus väsätä omaan e34:seen saman tyylistä hommaa paitsi erillisellä näytöllä. Tarkoitus olisi käyttää arduino nanoa. Ainut asia joka mietityttää on se datan lukeminen autosta ja kuinka toteuttaa se koodissa. Analogisenahan saisi kyllä helposti joitain antureita mitattua, mutta kiinnostaisi sen k linjan datan lukeminen enemmän.

Jos sattuisi joltain löytymään vinkkejä asiaan