Niin se vaan on prkl , >:( ,että peruskoulun matikka ei tähän nyt riitä. printf funktiolla tuo toimii ja tulostuu oikein vaikka 10 metriin asti.
Turhan raskas tapa vaan tähän ehkä. Kun pitää lukea 3 akselia yhtäaikaa. Tuo aiemmin käyttämäni tapa ei tässä toiminut eikä 10 muutakaan :(.

Kyllä se toimimaan saadaan ilman printf-funktiotakin, joka onkin raskas kuin synti.
Laitapa se (toimimaton) koodi näkysälle niin fiksataan se.

Perhana kun en tallentanut niitä mitkä kaikkein lähimmäksi toimi. nyt oon jo niin sekaisin noista ,etten pirullakaan muista miten sain toimimaan sen,tuohon 327 mm asti ja desimaalit. laitan nyt tuon viimeisimmän. Mä en ymmärrä miksi tuo kokonaisluku on tuossa alasanassa ja yläsana tyhjää täynnä ja desimaalit kadonnut johonkin. koodin lopussa on lcd tulostus funktiot millä olen tuossa aiemmassa tulostanut .Valtaosa koodista on taas netistä keräiltyä muuteltua sopivaksi. oma epäilykseni on ,että verrattuna tuohon aiempaan paikkatieto oli int16->int32 tässä se on valmiiksi int32 ja siitä muunnetaan int64 että näkyy myös negatiiviset luvut. Nyt kun sitä lähdetään muuttamaan kahdeksi int16 luvuksi tapahtuu jotain mitä en ymmärrä.

No, katsotaan eiköhän se selviä. En lupaa tänään enkä huomenna mitään lopullista viisautta kun Tukholman lento lähtee huomenna klo 6:50 (...kele) ja tulen takaisin vasta myöhään, pitää siis mennä ajoissa höyhensaarille. Mutta pakko tuon on lähipäivinä ratketa.
P.S. niin ja sullahan oli XMega prosessorina eikös niin? Siltä ainakin näyttää noiden alustusjuttujen perusteella.

No yksi aivan triviaali bugi löytyi helposti. Tämä nyt ainakin menee pieleen, mutta meneekö muuta niin en sitä vielä tarkemmin tutkinut. Tuo datan vastaanotto mittasauvalta saattaa myös olla... hmm... vähän hauras... No mutta asiaan.
Nämä kaksi ei toimi kuten oletat:

     int GetHighWord(int intValue)
   {
       return (intValue & (0xFFFF << 16));
   }

ja

  int GetLowWord(int intValue)
   {
       return (intValue & 0x0000FFFF);
   }


Oikea esittely jolla nämä toimii suoraan olisi:

     int16_t GetHighWord(int32_t intValue)
   {
       return (intValue & (0xFFFF << 16));
   }

ja

  uint16_t GetLowWord(uint32_t intValue)
   {
       return (intValue & 0x0000FFFF);
   }


Eli ei tarvitse muuttaa kuin tyyppien esittely. Kun olet mennyt käyttämään funktion argumentissa int-tyyppiä eli 16-bittistä muuttujaa niin kääntäjä suorittaa automaattisen tyyppimuunnoksen kutsussa käytetystä muuttujatyypistä (siis long integeristä) esittelyn mukaiseksi integer-tyypiksi. Tällöin ylimmät 16 bittiä lentävät bittiavaruuteen eivätkä koskaan edes saavu sisälle funktioon. Ihan tuo voi riittää siihen että alkaa toimimaan. Jollei, niin on meillä vielä paikkoja joita käydä läpi.

Joo xmega on käytössä ja kokeilin noita tyyppejä myös noin muttei toiminut. siinä kohtaa saattoi olla jotain muuta sitten lisäksi.
kääntäjä antaa muuten varoituksen  ledt shiftingistä tuossa Gethighwordissa

Okei mutta niin ne pitää kyllä olla. Tuossa int-muodossa se ei voi toimia. Tosin harvoinkos sitä löytyy useita bugeja samasta koodista. Katsellaan lisää.

Muok: Melkein veikkaan että nuo näytön formatointirutiinit ei toimi tuolla tavalla. Koetan niitä vielä vähän tsekkailla.

Muok2: Itse asiassa GetHighWord pitää tehdä tämä:

       return intValue >> 16;

Olisko sinulla linkki tuohon lcd-kirjastoion tai sen lähdekoodi, kun niitä on niin paljon, ettei voi tietää mikä lcd.h olisi se käyttämäsi. Ja lcd.c myös kiitos.

Nyt on pakko nostaa kädet pystyyn :( ei vaan onnistu . Piti oikein kokeilla edellistä projektia tallä lcdllä ja koodilla .se toimii tämä ei.
Tuossa edellisessäkin koodissa saattaa olla jotain väärin ja ylimääräistä jonka fiksu kääntäjä heittää kuikkaan. je se toimii vahingossa. ilman että ymmärrän mitä siinä tapahtuu. kuollaksenikaan en muista miten tuohon päädyin.
Toimiihan toi nyt ainakin sillä sprintf funktiolla jos muu ei auta xmega sitä tuntuis jotenkin pyörittävän
Laitoin lcd.c ja lcd.h tähän samaan tiedostoon.

Pitääpä koittaa vääntää iteki joku tommonen, ei vain ole Atmelin ohjelmointi systeemeitä kuin Amigassa (jota en ole buutannu käyntiin vuosiin) joten koitan Microchipin prossuilla kunhan ehin.

Tuosta jussin koodista löytyi pari aika helppoa lisäbugia. Nyt muunnos toimii teknisesti oikein, mutta voisin tehdä malliksi esimerkin kuinka itse toteuttaisin tuon laskennan. Se kun on varsin yleinen probleema jota joutuu ratkomaan tosituvasti ja sen voi minusta tehdä yksinkertaisemmin, yleispätevästi ja jopa ymmärrettävämminkin. Perästä kuuluu.

Hyvä homma. olin jo lähes valmis pilkkoon ton stripin kirveellä sentin paloiks. :) Olen koittanut laittaa talteen aina kun on löytynyt joku hyvä ja toimiva funktio. ikäänkuin oma kirjasto mistä voi liittää niinkuin legopalikoita.

Kremmeni viittasi kaiketi tuohon 10 luku järjestelmään muuttamiseen, sen voi tehdä paljonkin helpommin ja ilman jakolaskuja (jako ja kertolaskut on aina olleet ne hitaimmat käskyt suorittaa) Tuossa on itoa funktion sorsa http://www.raspberryginger.com/jbailey/minix/html/itoa_8c-source.html tehtynä kuitenkin jakolaskulla.

Ascii hexaksi muunnos on vielä simppelimpi. Käyppäs vilkasees ASCII-taulukkoa niin idea on selviää. 2 kerto ja jakolaskut voi tehdä shiftaamalla bittejä ja se on vanha optimointi kikka jne.

Tässä laskentaesimerkki toteutettuna kiinteän pilkun esitystavalla, jota suosittelen käytettäväksi tällaisissa sovelluksissa.
Irroitin tästä koodista kaikki hämäävät käytännön jutut ja jätin vain laskentaosuuden ja näytön formatoinnin jäljelle.
Koodi on ajettu emulaattorissa ja toimii.
Tarvittavaan fixmath-kirjastoon löytyy linkki kommenteista, mutta voi sen laittaa tähänkin: http://code.google.com/p/libfixmath/downloads/detail?name=libfixmath_r64.zip&can=2&q=
Tuolta siis tarvitaan fix16.h, fix16.c ja int64.h -tiedostot.

Jos koodi ei hahmotu niin kysykää vapaasti.

En sitten malttanut olla vielä etsimättä ratkaisua ,mikä sitten löytyi arduino foorumilta. siellä oli näytillä funktio mikä arduinossa tekee tuon homman.
Muokkasin siitä tähän sopivan ja nyt se toimii. Ero koodin koossa on 6190 bytes ->sprintf versio 6920bytes.
Pakko on kyllä kokeilla tuota Kremmenin esimerkkiäkin jos vaikka oppis samalla jotain.

Niin tässä olisi se etu, että on käytetty ensinnäkin vakiokirjastoa joka on testattu ja debugattu miljoonaan kertaan käyttäjäkunnan erilaisissa sovelluksissa. Toinen etu on, että numeerisen tiedon käsittely tapahtuu menetelmänmukaisesti, eli on olemassa standardi (siis tämä S15.16 kiinteän pilkun lukutyyppi) jota on helppo soveltaa eri tilanteissa, ja jonka toimivuuden ennakointi on varmalla pohjalla. Voit esim etukäteen tietää, tuleeko lukujen arvoalueet riittämään sovelluksen tarpeisiin jne.

Muok: Binäärin koko kun optimoitiin koon suhteen (-Os) oli 6074 tavua ja kun optimoitiin tappiin, eli suoritusajan maksimioptimointi (-O3) 7410 tavua.
Mielenkiintoista on ehkä havaita (kts oheinen linkkerikartta) että koodisegmentissä (.text osio tuossa kartassa) varsinaisen ohjelman koodi, eli segmentti DIY_DRO.o ulotuu vain välille 0x23a - 0x42c eli siinä on vain 498 tavua varsinaista sovellusta. Kaikki muu on kirjastoa joka ei toistu kun ohjelma kasvaa. Tässä muuten on linkattuna mukaan lcd-näytön koodi, joten koon puolesta tämä lienee melkein vertailukelpoinen muihin ratkaisuihin. Mittadatan sisäänluku tästä lähinnä puuttuu.