Sähköinen syöttövaihteisto

[jussi]

Ammattilaisen kommentit tervetulleita esim.  muistin käytöstä ja"tehokkuudesta"

[Kremmen]

Ammattilaisen kommentit tervetulleita esim.  muistin käytöstä ja"tehokkuudesta"

Okei, rakentavassa hengessä sitten tämmöisiä havaintoja:

unsigned long int summa (u16 A,u16 B)  //määrittely yhteenlasku funktio

   {
     u32 C = 0;                          //muuttuja C nollaus
     C = A+B;                            // yhteenlasku
     return C;                             //tulos palautetaan
   }   

Tässä funktiossa muuttuja C on todellisuudessa tarpeeton. Sama toiminta saadaan kirjoittamalla vain "return A+B;" sillä return ei välttämättä tarvitse yksittäistä muuttujaa (vaikka sekin toki käy), sille kelpaa mikä tahansa mikä kelpaa tavallisen sijoituslauseen oikealle puolelle (ns. "rvalue").
Tässä ei tapahdu mitään vahinkoa, koska jokainen moderni kääntäjä joka tapauksessa optimoi muuttujan C pois, eli syntyvä konekoodi lienee sama molemmissa tapauksissa.

Semmoinen kauneusjuttu mihin voi kiinnittää huomiota on, että funktion tyypiksi on määritelty "unsigned long int" ja palautettava tyyppi on "u32" (muuttuja C on tätä tyyppiä). Tässä kääntäjä saattaa suorittaa implisiittisen tyyppimuunnoksen mikäli nuo määritykset eivät ole identtisesti samat (tai se siis varmasti suorittaa muunnoksen mutta se on todennäköisesti null operaatio tässä). Kulissien takana tapahtuvat tyyppimuunnokset (typecast) ovat aina vähän riski koska pahassa tapauksessa bittejä lentää avaruuteen. Tässä ei varmaankaan käy niin ja yleensä kääntyri kyllä varoittaa jos näin näyttäisi käyvän.

Pääohjelmassa sijoitukset riveillä:
    u32 C = 0;                         //
    u32 tulos = 0;                     //muuttujat A,B,C,tulos
ovat myös tarpeettomia. Noita nolliahan ei käytetä mihinkään ja ne ylikirjoitetaan heti while-silmukan alussa. Ei nollauksesta mitään haittaa ole, mutta kun ei ole hyötyäkään niin ohjelma olisi yksinkertaisempi ilman niitä. Tässäkin riitävän aggressiivinen optimoija kyllä perkaa nuo pois tarpeettomina.

Ehkä kuitenkin kohta johon eniten kiinnittäisin huomiosi on tapa miten olet rakentanut varsinaisen silmukan 1...1000. Koodi toimii kyllä oikein, mutta olethan samaa mieltä, että avaamalla pelin rakenteella while(1) ei lukijalle anneta liikoja vinkkejä siitä, että meinataan lopettaa tuhanteen? Kaikki koodia lukeneet orientoituvat tässä vaiheessa siten, että nyt on kädessä päättymätön silmukka, niinkuin se onkin. Ymmärrettävyyden kannalta isoin haaste on löytää rivi if(B==1000) ja keksiä, että se katkaisee ylöspäin iteraation ja muuttujassa C siksi on tähän mennessä kertynyt summa. Haastetta ei helpota se, että while-silmukka on täysin tunteeton tälle tapahtumalle ja jatkaa suoraan seuraavalle kierrokselle. Hyvä kuitenkin, että muuttujat on alustettu uutta kierrosta varten joten sekin lähtee kyllä laskemaan oikein.
Pääohjelmallahan ei tehtäväksiannon mukaan ollut mitään muuta tekemistä, joten se saa joko kiertää ikuista silmukkaa tai päättyä - siinä mielessä päättymätön silmukka on OK.
Jos olisit vielä kirjoittanut tulos = summa(tulos,C) niin se yhteenlaskukieltokin olisi toteutunut 100% :)

Arvaan ettet kirjoita koodia ammatiksesi. Se huomioiden tässä toteutuksessa ei ole mitään varsinaista vikaa. Kaikille muillekin lukijoille voi heittää sellaisen mietittäväksi, että koodin kirjoitus on kuin shakin peluuta: se että osaa siirrot ei vielä tee suurmestaria.
Ketä ohjelmointi noin muuten kiinnostaa niin suosittelen lukemaan jos käsiinne saatte: McConnell: "Code Complete 2" ja toinen kuolematon Ranade & Nash: "The Elements of C Programming Style". Noiden lukemisen jälkeen koodieditorin läpi aukeaa ikkuna toisennäköiseen maailmaan.

[jussi]

juu ammatikseni en koodaa. Onneks vois tulla nälkä :D olen tosiaan jotain pikkujuttuja tehny noilla avr:illä niihinkih koodit on suurimmaksi osaksi muokattu/yhdistelty valmiista esimerkeistä. Niissä on aina toi while silmukka. Jääny takaraivoon ;)

[Kremmen]

...  niihinkih koodit on suurimmaksi osaksi muokattu/yhdistelty valmiista esimerkeistä. Niissä on aina toi while silmukka. Jääny takaraivoon ;)

Joo, tällaisissa mikrokontrollerisovelluksissa on käytännössä aina pääohjelman uloin runko jonkinlainen päättymätön silmukka. Eihän jossain sulautetussa systeemissä kerta kaikkiaan ole mitään sellaista laajempaa ympäristöä johon suoritus voisi palata jos pääohjelma sattuisi ajamaan itsensä loppuun asti. Laskenta vaan tyssäisi ja kapine mykistyisi. Kyllä Windowsinkin syvimmissä uumenissa on jonkinlainen päättymätön silmukka.  :P

Toimivaksi tiedetyn esimerkkikoodin tarkastelu on usein erinomainen tapa saada selville miten jokin toimii tai miten sen pitäisi toimia. Kannattaa vaan aina pitää mielessä, että esimerkkejä ei välttämättä ole mietitty "oikeaksi" koodiksi joten niiden anti pitää sovittaa omaan näkemykseen. Se taas puolestaan kehittyy ajan kanssa ihan niinkuin shakinpeluun taito johon viittasin. Koodaaminen on yksi niitä taiteen ja tieteen välimaastossa häälyviä asioita joissa tyyli on enemmän kuin vain hienostelua. Sillä on aika suora korrelaatio ohjelmiston laatuun ja sitä kautta toimivuuteen.
Muutaman rivin esimerkkikoodin pätkässä tätä ei huomaa kun ongelma ja sen ratkaisu on kerralla silmien edessä ja helposti hahmotettavissa. Sitten kun koodia on satojatuhansia tai miljoonia rivejä, juttu on ihan toinen. Mullekin maksoi liksan melkein 14 vuotta Nokia Data / ICL / Fujitsu ja siellä kyllä käytettiin paljon aikaa ja vaivaa koodaamisen tyylin kehittämiseen juuri sen takia, että se on olennainen osa ohjelmiston elinkaarta laatumielessä. No, ehkä me päästään vähemmällä kun ei nämä ympyrät ole ihan verrattavissa...

[jussi]

Tuo debukkaus esimerkki, mitä kokeilin nyt ihan ensimmäistä kertaa aukaisi ihan uuden maailman noihin esimerkki koodien tutkimiseen.Paljon helpompi seurata koodia noin. Varsinkin jos on käytetty paljon vakioita voi tuolla wiewillä seurata muuttujia.

[Kremmen]

Tuo debukkaus esimerkki, mitä kokeilin nyt ihan ensimmäistä kertaa aukaisi ihan uuden maailman noihin esimerkki koodien tutkimiseen.Paljon helpompi seurata koodia noin. Varsinkin jos on käytetty paljon vakioita voi tuolla wiewillä seurata muuttujia.

Jep. Kunnollinen debuggeri on vähän niinuin patologian laitos poliisille. Lopullinen totuus selviää siellä.

[Tauru]

Ne ei tässä tunneista tai päivistä ole kysymys, välillä tuppaa nuo omatkin aikataulut hiemen venymään. Teen nyt ensin jyrsimen tuunausta jonkin aikaa ja sitten jatkan taas sorvin parissa.

En tiedä onko minusta mitään apua tässä projektissa, C-koodi kyllä onnistuu, mutta elektroniikan suunnittelu ei. Ja voin toki tehdä jos jotenkin pystyn auttamaan.

[Kremmen]

Ne ei tässä tunneista tai päivistä ole kysymys, välillä tuppaa nuo omatkin aikataulut hiemen venymään. Teen nyt ensin jyrsimen tuunausta jonkin aikaa ja sitten jatkan taas sorvin parissa.

En tiedä onko minusta mitään apua tässä projektissa, C-koodi kyllä onnistuu, mutta elektroniikan suunnittelu ei. Ja voin toki tehdä jos jotenkin pystyn auttamaan.

Avusta on aina apua :)
Jos olet koodaustaitoinen niin kyllä tässä projektissa tekemistä löytyy. Oletko tutustunut tälle alueelle toisessa viestiketjussa laittamaani RTOS-demoon? Mikäli katsot ymmärtäväsi demon ilman suurempia haasteita, sekä pystyväsi tuottamaan suunnilleen samantasoista koodia demossa käytettyyn ympäristöön, niin tervetuloa remmiin.
Heittelen tällaista haastetta sen takia, että tässä ollaan toteuttamassa laitetta joka saattaa päätyä vakavasti otettavaan käyttöön oikeassa tuotannossa, ja joka tapauksessa sen on oltava henkilöturvallinen. Jos ikinä liha kohtaa nopeasti liikkuvan metallin, niin en haluaisi olla keskustelemassa, täyttikö koodi minimilaatuvaatimukset. Samaa pohdiskelua suosittelen kaikille jotka tarjoutuvat vapaaehtoisiksi. Tämä ei ole kuitenkaan tarkoitettu pelotteluksi, vaan jotta pysyisi totuus kirkkaana mielessä.
Ellei vieläkään arveluta niin toistan - tervetuloa remmiin. Niin, ja hommaa siis löydetään tehtäväksi ihan varmasti, vaikka koodaamisen haluaisitkin jättää väliin. Mutta kerro tähän väliin millä mielellä niin jatketaan siitä.

[Tauru]

Jep, luin koodia läpi, mutta en kääntänyt vielä. Pitää kokeilla kääntämistä VS2008:lla kun aikataulut antaa periksi.
Eipä tuossa koodissa ollut mitään ihmeellistä (eikä pidäkkään olla ylläpitämisen takia) joten saman tasoista koodia pystyn tuottamaan. Tarvittaessa voit kysyä jotain muutakin hommaa minulle tehtäväksi, vaikka kyllä tuo koodaaminen on varmasti lähimpänä omaa aluetta.

[Kremmen]

Jep, luin koodia läpi, mutta en kääntänyt vielä. Pitää kokeilla kääntämistä VS2008:lla kun aikataulut antaa periksi.
Eipä tuossa koodissa ollut mitään ihmeellistä (eikä pidäkkään olla ylläpitämisen takia) joten saman tasoista koodia pystyn tuottamaan. Tarvittaessa voit kysyä jotain muutakin hommaa minulle tehtäväksi, vaikka kyllä tuo koodaaminen on varmasti lähimpänä omaa aluetta.

Hyvä juttu, päästään eteenpäin. Demo oli suunnilleen niin yksinkertaista kuin ylipäänsä on mahdollista tuottaa, joten kyllä projektiin oikeaakin haastetta saadaan.
Kääntäminen VS:llä voi kyllä olla aika turhauttava harjoitus. C-koodiosuus tietysti kääntyy, mutta tätä projektia tuskin saa kasaan järkevästi Visual Studiolla. Ei ole tullut mieleeni itse kokeilla tuota, mutta veikkaan että VS nikottelee viimeistään törmätessään AVR:lle portattuun RTOS-ytimen inline-assembleriin. Eikä se ainakaan emittoi siitä mitään järkevää :(.
Joka tapauksessa tämä projekti on ehdottomasti tuotettava yksillä ja samoilla työkaluilla, joten avoin gnu toolchain on harkittu valinta ja sen avr-gcc on kääntäjänä tässä projektissa. Jokainen koodaukseen osallistuva voi toki oman mieltymyksensä mukaan käyttää mitä tahansa IDEä tai olla käytämättä jos perinteinen tapa miellyttää enemmän.

Olisiko käyttöliittymä sinua kiinnostava aihealue? Siinä olisi vielä koodaamisen lisäksi paljon konseptointi- ja rakennesuunnittelua. Itse asiassa sitä hommaahan ei ole oikeasti edes aloitettu vielä. Samoin tarjolla olisi EEPROM-muistin käyttö ja sarjaporttiliitynnän miettiminen. Jos sarjaportti toteutetaan (miksipä ei toteutettaisi kun resursseja on), sitä voisi käyttää myös diagnostiikkaan.

Yksi koodaamiseen liitymätön tehtävä kaipaa myös tekijää. Jonkun olisi nimittäin hyvä toimia kustannuspoliisina. Tähän mennessä emme ole asettaneet valmiillee tuotokselle mitään tavoitehintaa. Siitäkin pitäisi muodostaa jokin käsitys ja sen jälkeen valvoa kustannusten kehittymistä osa-alueittain. Joillakin komponenttivalinnoilla saattaa olla merkitävää kustanusvaikutusta, samoin toimittajavalinnoilla. Kun päästään pidemmälle, voidaan ruveta pelaamaan hankintapolitiikoilla kun tiedetään enemmän toimitajakandidaateista ja volyymeista. Kuka vaan tuntee kiinnostusta tällaiseen, saa siitä äkkiä homman itselleen.

[Tauru]

Visual Studio on koneella valmiina niin siksipä sillä ajattelin ensin kääntää. Taitaa olla parasta kuitenkin pudottaa nuo työkalut joita aikasemmin ehdotit. Eclipse on tuttu vuosien takaa kun olin tovin Javan ihmemaailmassa mukana. Ja siinä olet oikeassa että kaikilla pitää olla samat kilkkeet käytössä.

Käyttöliittymä voisi olla minulle sopiva osa. Onko mitään mitä pitäisi huomioida ennen kuin alan miettimään ratkaisua? Pieni näyttö ainakin ja tuskin qwerty-näppäimistö on käytettävissä. Numeronäppäimistö ja muutamia muita toimintonäppäimiä joilla pitää tulla toimeen.

On tämä ainakin vaihtelua web- ja windows-sovellusten käyttöliittymien tekemiseen.

[Kremmen]

...
Käyttöliittymä voisi olla minulle sopiva osa. Onko mitään mitä pitäisi huomioida ennen kuin alan miettimään ratkaisua? Pieni näyttö ainakin ja tuskin qwerty-näppäimistö on käytettävissä. Numeronäppäimistö ja muutamia muita toimintonäppäimiä joilla pitää tulla toimeen.
On tämä ainakin vaihtelua web- ja windows-sovellusten käyttöliittymien tekemiseen.

Hyvä, erinomaista.
Huomioitavaa on paljonkin ennekuin päästään koodaamaan. Oikeastaan koko käyttöliittymä pitää ensin konseptoida loppuun, suunnitella ja vasta sen jälkeen päästään koodaamaan.
Syöttölaitteina ei tosiaan ole mahdollista ajatella qwerty-näppäimistöä (hmm, tarkkaan ottaen miksipä ei, prosessorissa ainakin riittää sarjaliikennekapasiteetia :) ), numeronäppäimistökin pitää vielä selvittää. Tähän mennessä keskustelu on liikkunut erilaisten koodikytkinten ja paneelipulssipyörien ympärillä. Näyttöpuolella tarvittanee joitakin signalointiledejä ja varmaankin LCD-näyttö. Keskustelua on käyty erilaisista merkkipohjaisista ja (semi)graafisista vaihtoehdoista.

Ottaisitko koko tämän osa-alueen haltuusi? Toimeksianto olisi silloin osapuilleen seuraava:
- Kaikkien käyttöliittymän käyttötapausten konseptointi ja perustason dokumentointi toiminnallisella tasolla.
- Käyttötapausten vaatiman käyttöliittymän suunnittelu laitteistotasolle yhteistyössä elektroniikkamestarimme ramin kanssa.
- Käyttötapausten prosessien suunnittelu ja toteuttaminen ohjelmistoksi. Tässä osassa sitoudun olemaan tukena ja koordinoimaan yhdessä kytkentää muuhun ohjelmistoon.

Kaikki päätökset ovat siis vielä ainakin jonkin verran auki. Ottaisitko sinä ajaaksesi ne maaliin ja tekisit meille veret seisauttavan käyttöliittymän?
Tämä vaatii melko aktiivista otetta ja rekisteröityneen, aiheesta kiinnostuneen jäsenkunnan haastamista keskusteluun mukaan. Jonkin verrankin duunia ja haastetta tässä siis on luvassa, mutta haastetta hyvässä harrastuksessa kai pitää ollakin. Minusta ainakin.

Käytännön kysymyksiä: onko sinulla esim Microsoft Office-paketin työkaluja käytössä ja jos on niin mitä ja mitä versioita? Powerpoint ja/tai Visio olisivat aika hyviä/helppoja käyttöliittymän mock-upien tekoon joskin muitakin toimivia on. Nuo yleiset mockup-työkalut vaan eivät oikein sovellu tämmöiseen ympäristöön kun tässä ei ole mitään GUI.ta käytettävissä. Kuitenkin - jonkinlainen demo kannattaa tehdä vaikka paperille ja "ajaa" sitä kunnes se vaikuttaa riittävän toimivalta.
No, ehkä nämä ovat sinulle jo tuttuja juttuja joten en jauha sen enempää. Jos edelleen vaikuttaa kiinnostavalta niin sitten ei kai muuta kuin menoksi.

[Tauru]

Käytännön kysymyksiä: onko sinulla esim Microsoft Office-paketin työkaluja käytössä ja jos on niin mitä ja mitä versioita? Powerpoint ja/tai Visio olisivat aika hyviä/helppoja käyttöliittymän mock-upien tekoon joskin muitakin toimivia on. Nuo yleiset mockup-työkalut vaan eivät oikein

Jep, kaikki mahdolliset versiot löytyy, ehdottaisin käytettäväksi 2007:aa.

Minä ryhdyn miettimään käyttöliittymää. Sen pitää olla niin yksinkertainen että sitä voi käyttää ilman käyttöohjeita.
Syöttölaitteina saattaa riittää napit ENTER, ESC, <, >,  ^, v ja yksi pyörivä säädin. Mahdollisesti pari lisää mutta melko vähillä pärjätään.

Koetan saada viikolla mietettyä ensimmäisen version toiminnoista ja UI:n toiminnasta, palaan asiaan kun on jotain näytettävää.

Sellainen asia tuli vielä mieleen että kun tästä pitäisi saada idioottivarma ettei esimerkiksi terää voi ajaa pakkaan kiinni, niin miten se pitäisi toteuttaa? Rajakytkimillä vai näytetään ensin liikkeiden äärireunat? Tuo jälkimmäinen ei vain ole varma menetelmä jos kelkan irrottaa trapetsista.

[saulij]

Jep, kaikki mahdolliset versiot löytyy, ehdottaisin käytettäväksi 2007:aa.

Mielestäni kannattaa käyttää vanhempaa talletusformaattia esim 2003 tai 97, kaikilla ei ole välttämättä uusimipia versioita käytettävissä.

Sauli

[Kremmen]

Jep, kaikki mahdolliset versiot löytyy, ehdottaisin käytettäväksi 2007:aa.

Mielestäni kannattaa käyttää vanhempaa talletusformaattia esim 2003 tai 97, kaikilla ei ole välttämättä uusimipia versioita käytettävissä.
Sauli

Itsekin mielelläni käyttäisin 2007:aa, mutta saulij on siinä oikeassa, että ei pitäisi aiheuttaa hankaluuksia niille joilla ei noita versioita ole. 2007 tallentaa myös 2003-formaatissa joten se voisi olla sopiva minimi. Windows 97 ehkä on jo niin historiaa, että rajoittaa liikaa.
Tosin, onhan olemassa Open Office joka on ihan napakka paketti sekin. Sen voi kuka vaan hakea itselleen ilmaiseksi ja sen jälkeen on kaikilla varmasti yhteensopivat vehkeet. En ole tätä vaatimassa, mutta minulle se kyllä sopisi. Juuri nyt ei ole OO:ta asennettuna omallakaan koneella, mutta eipä siihen kauaa mene.