Hallo
Het project begint stilaan vorm aan te nemen; de werkende functionaliteit wordt almaar groter. Voor het ogenblik hebben we reeds de volgende functionaliteit:
- Het afbeelden van tekst, lijnen, vierkanten, knopjes, ... op het scherm
- Het afbeelden van een zelfgemaakte bitmap-file met 16-bits kleuren
- Het interpreteren van invoerinfo van het touchscreen
Deze week zijn we er dus in geslaagd om de bestaande broncode van "tslib" (die eigenlijk slechts een klein testprogramma is met beperkte functionaliteit) aan te passen zodanig dat de aanwezige basisfuncties bruikbaar zijn in onze eigen toepassing.
Het afbeelden van tekst, lijnen, vierkanten, ... was relatief eenvoudig in tegenstelling met het afbeelden van de bitmap-file. Het ophalen van de juiste kleurdata uit de bitmap-file is niet vanzelfsprekend en er moet ook rekening gehouden worden met de maximale kleurcapaciteit van het scherm.
Even illustreren:
Een (huidige) standaard bitmap-afbeelding heeft een fileheader, infoheader en een gebied waar de kleurwaarden per pixel opgeslaan zijn. Standaard heeft men echter 24-bits kleuren wat wil zeggen 8 bits per hoofdkleur (RGB). Omdat we echter niet wisten (gebrek aan info) wat de maximale kleurdiepte van het scherm was zijn we dus begonnen met het converteren van de 24-bits kleuren naar een kleurenpalet van 256 kleuren. Het lukte om de afbeelding af te beelden maar door de conversie is er te veel verlies aan kleurinfo en dus ook aan kwaliteit, wat voor ons einddoel niet gewenst is.
We verlegden dus de grens en probeerden het andere extremum, de volledige 24-bits kleuren in één keer afbeelden. Het scherm beschikt echter niet over voldoende kleurdiepte (te weinig geheugen) dus dit bleek onmogelijk.
We vonden dan de gulden middenweg, het afbeelden van een bitmap met 16-bits kleuren, zijnde 2 bytes per pixel, wat tegelijk het maximum blijkt voor ons scherm. De indeling van de kleuren in pixels is als volgt:
bit: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
kleur: R R R R R GGGGGG B B B B B
Merk op dat groen 1 extra bit krijgt, dit omdat groen beter waarneembaar is door het menselijk oog en bijgevolgd meer varianten krijgt.
We slaagden er naar het eind van deze week ook in om de sturing van het touchscreen te ontrafelen (laden van de juiste modules, opvangen van druk en coordinaten) en zijn nu aan het experimenteren met het verslepen van vierkanten, knopjes, ... .
Volgende week zullen we de beide tests samenvoegen en beschikken we dus over de volledige mogelijkheden van het scherm. Vervolgens zullen we proberen het beeld van de camera op te vangen. Dan wordt het experimeteren met POSIX-threads omdat we later de noodzaak hebben aan een thread om de camera te sturen en een andere die tegelijkertijd de zoomfunctie bestuurt.
Hopelijk blijven de vorderingen aan dit tempo verder gaan!
Vriendelijke groeten uit Brive
Hannes Claerhout
Dieter Walckiers
vrijdag 28 maart 2008
vrijdag 21 maart 2008
Tests en Libs
Een week verder en een week wijzer.
De week begon hoopgevend. We hadden de ontwikkelaars gevonden van de software (OSELAS-Linux) die voorgeprogrammeerd stond op het doelplatform. Via online speurwerk in feite, want dat stond in de manual nergens duidelijk aangeduid. Op de site vonden we een quickstart guide toegespitst op de I.MX27, het model van microcontroller in kwestie dus. We bezochten de irc chatroom en troffen daar enkele ontwikkelaars aan, die ons wisten te melden dat er voor de camera in de komende weken een startklare driver wordt geschreven.
Verder leek deze nieuw ontdekte bron uitgeput, behalve dan dat we er een handig kanaal bij hadden om vragen aan te stellen. Maar dan ontdekten we in de quickstart iets dat we eerst over het hoofd hadden gezien: de mogelijkheid om voorgemaakte testprogrammatjes te runnen rechtstreeks vanaf de console, in seriële verbinding met het doelplatform. Hierbij gaat het om fbtest (framebuffertest - toont een reeks van afbeeldingen op het scherm), ts_test (laat de gebruiker een crosshair rondslepen / tekenen op het aanraakscherm) en ts_calibrate (calibreert het aanraakscherm).
Hieruit leerden we dus dat de voorbeelden gebruik maken van het linux begrip framebuffer. Dit leek een zeer interessante nieuwe weg om in te slaan.
Ons eerste reactie was uiteraard "Waar kunnen we de broncode vinden van die 3 tests?". Beginnend bij fbtest, vonden we na lang zoeken uiteindelijk een C broncode met dezelfde naam. Dit bleek niet de broncode van de test in kwestie te zijn, maar beschikte over een rijke bibliotheek met een aantal interessante methoden. Bijvoorbeeld put_char, draw_rect, clear_screen, tastbare zaken.
Deze code runnen was niet evident, maar na de nodige eliminaties is het toch gelukt om de essentie te doen werken; het aanspreken van het LCD scherm, en het laden van een pointer naar de juiste plaats in het geheugen voor weergave van pixels.
Via een for lus die de geheugenlocaties verwijzend naar de pixels op het scherm aanspreekt, slaagden we erin het scherm op te vullen met een kleur naar keuze. Een random kleur toewijzen in elke binnenste for-iteratie gaf een nog interessanter effect. Een hele overwinning weer, hoewel er ook enkele vreemde stippellijnen verschenen. Maar dit beschouwden we als zorgen voor later, en we herschikten de methodes zodat we een logisch werkend geheel kregen om daarop dan te kunnen verderbouwen.
Trots legden we deze nieuwe stap voor aan onze stagementor, Mr. Halluin, die ook enthousiast was, maar erop wees dat die stippellijnen waarschijnlijk veroorzaakt werden door een corrupte initialisatie van het LCD scherm in de code.
Bijvoorbeeld, de dimensies van het scherm; deze moeten in principe automatisch gedetecteerd worden, maar in ons bestaande code was dat niet het geval. Met als gevolg dat het programma bij het tekenen van een rechthoek kleiner dan het scherm, 3 keer opnieuw begon, 3 verschillende rechthoeken naast elkaar. Dit was dan ook de verklaring van de stippellijnen; deze verschenen op de plaatsen tussen waar het programma telkens opnieuw begon te tekenen.
Hier trapten we bijgevolg weer even ter plaatse, we vielen weer terug op de 3 testprogramma's, meerbepaald de ts_test (touchscreen test). Dit bleek - dit stond zo op het schermpje te lezen bij het runnen ervan - gebruik te maken van een bibliotheek tslib. Deze bibliotheek vonden we direct online en beschikt over een heel arsenaal aan methoden waarbij de initialisatie van het LCD scherm veel duidelijker verloopt.
We hadden dus een nieuwe uitvalsbasis, de tslib! Deze bibliotheek beschrijft de touchscreen-mogelijkheden, maar ook natuurlijk methoden om te schrijven op het scherm. Methoden die veel duidelijker zijn en meer controle bieden dan wat we tot dan toe hadden gebruikt.
We konden experimenteren met gekleurde vierkanten, lijnen, strings,... De uitdaging waar we nu mee bezig zijn is het omzetten van een BMP bestand naar zijn pixelwaarden, met als doel het bedrijfslogo van Dioptik af te beelden met de woorden "Tapez l'écran pour continuer".
Dat en de touchscreen functies. Het inladen van het touchscreen device in de broncode verloopt tot op heden nog niet zoals het hoort. Er zijn bepaalde modules die niet worden gevonden.
Verder is er straks nog een meeting gepland met Mr. Faugeras, de directeur van Dioptik. Hij komt even polsen naar onze vooruitgang.
Groeten vanuit het vandaag zeer natte Brive!
De week begon hoopgevend. We hadden de ontwikkelaars gevonden van de software (OSELAS-Linux) die voorgeprogrammeerd stond op het doelplatform. Via online speurwerk in feite, want dat stond in de manual nergens duidelijk aangeduid. Op de site vonden we een quickstart guide toegespitst op de I.MX27, het model van microcontroller in kwestie dus. We bezochten de irc chatroom en troffen daar enkele ontwikkelaars aan, die ons wisten te melden dat er voor de camera in de komende weken een startklare driver wordt geschreven.
Verder leek deze nieuw ontdekte bron uitgeput, behalve dan dat we er een handig kanaal bij hadden om vragen aan te stellen. Maar dan ontdekten we in de quickstart iets dat we eerst over het hoofd hadden gezien: de mogelijkheid om voorgemaakte testprogrammatjes te runnen rechtstreeks vanaf de console, in seriële verbinding met het doelplatform. Hierbij gaat het om fbtest (framebuffertest - toont een reeks van afbeeldingen op het scherm), ts_test (laat de gebruiker een crosshair rondslepen / tekenen op het aanraakscherm) en ts_calibrate (calibreert het aanraakscherm).
Hieruit leerden we dus dat de voorbeelden gebruik maken van het linux begrip framebuffer. Dit leek een zeer interessante nieuwe weg om in te slaan.
Ons eerste reactie was uiteraard "Waar kunnen we de broncode vinden van die 3 tests?". Beginnend bij fbtest, vonden we na lang zoeken uiteindelijk een C broncode met dezelfde naam. Dit bleek niet de broncode van de test in kwestie te zijn, maar beschikte over een rijke bibliotheek met een aantal interessante methoden. Bijvoorbeeld put_char, draw_rect, clear_screen, tastbare zaken.
Deze code runnen was niet evident, maar na de nodige eliminaties is het toch gelukt om de essentie te doen werken; het aanspreken van het LCD scherm, en het laden van een pointer naar de juiste plaats in het geheugen voor weergave van pixels.
Via een for lus die de geheugenlocaties verwijzend naar de pixels op het scherm aanspreekt, slaagden we erin het scherm op te vullen met een kleur naar keuze. Een random kleur toewijzen in elke binnenste for-iteratie gaf een nog interessanter effect. Een hele overwinning weer, hoewel er ook enkele vreemde stippellijnen verschenen. Maar dit beschouwden we als zorgen voor later, en we herschikten de methodes zodat we een logisch werkend geheel kregen om daarop dan te kunnen verderbouwen.
Trots legden we deze nieuwe stap voor aan onze stagementor, Mr. Halluin, die ook enthousiast was, maar erop wees dat die stippellijnen waarschijnlijk veroorzaakt werden door een corrupte initialisatie van het LCD scherm in de code.
Bijvoorbeeld, de dimensies van het scherm; deze moeten in principe automatisch gedetecteerd worden, maar in ons bestaande code was dat niet het geval. Met als gevolg dat het programma bij het tekenen van een rechthoek kleiner dan het scherm, 3 keer opnieuw begon, 3 verschillende rechthoeken naast elkaar. Dit was dan ook de verklaring van de stippellijnen; deze verschenen op de plaatsen tussen waar het programma telkens opnieuw begon te tekenen.
Hier trapten we bijgevolg weer even ter plaatse, we vielen weer terug op de 3 testprogramma's, meerbepaald de ts_test (touchscreen test). Dit bleek - dit stond zo op het schermpje te lezen bij het runnen ervan - gebruik te maken van een bibliotheek tslib. Deze bibliotheek vonden we direct online en beschikt over een heel arsenaal aan methoden waarbij de initialisatie van het LCD scherm veel duidelijker verloopt.
We hadden dus een nieuwe uitvalsbasis, de tslib! Deze bibliotheek beschrijft de touchscreen-mogelijkheden, maar ook natuurlijk methoden om te schrijven op het scherm. Methoden die veel duidelijker zijn en meer controle bieden dan wat we tot dan toe hadden gebruikt.
We konden experimenteren met gekleurde vierkanten, lijnen, strings,... De uitdaging waar we nu mee bezig zijn is het omzetten van een BMP bestand naar zijn pixelwaarden, met als doel het bedrijfslogo van Dioptik af te beelden met de woorden "Tapez l'écran pour continuer".
Dat en de touchscreen functies. Het inladen van het touchscreen device in de broncode verloopt tot op heden nog niet zoals het hoort. Er zijn bepaalde modules die niet worden gevonden.
Verder is er straks nog een meeting gepland met Mr. Faugeras, de directeur van Dioptik. Hij komt even polsen naar onze vooruitgang.
Groeten vanuit het vandaag zeer natte Brive!
vrijdag 14 maart 2008
Eerste ervaring materiaal & probleem LCD-scherm
Hallo
Sinds maandag hebben we de eerste ervaring met het te gebruiken materiaal achter de rug. Alvorens te kunnen beginnen met het ontwikkelen van software voor het doelplatform moesten we eerst openSuse 10.2 installeren op een gewone desktop-pc. De installatie verliep zonder al te veel problemen, er was slechts een klein probleem (de linuxdistributie wilde niet in grafische omgeving starten omdat de muis later bleek stuk te zijn) dat snel verholpen was.
Vervolgens hebben we een quickstart-guide gevolgd die bij de hardware geleverd werd om de juiste tools te installeren. Om te kunnen communiceren met het ontwikkelaarsbord hebben we ook een speciale versie van linux moeten compileren en die vervolgens op het doelbord "geflashed" (er is -miscchien voorlopig- geen enkel extern geheugen zoals HD's en dergelijke op het doelplatform beschikbaar).
We slaagden er ook in om het programma "Hello world" te laten werken op het doelplatform in 2 verschillende versies: één keer gaf het de output weer via de seriële poort zodanig dat we het resultaat konden waarnemen vanop de desktop pc, de andere keer verscheen de tekst op het aangesloten LCD-scherm.
Het LCD-scherm echter, brengt enkele problemen met zich mee. Hoewel we er reeds in slaagden om de tekst "Hello world" erop te doen verschijnen deden we dit door de tekst via een klein C programma naar het linux-apparaat /dev/vcs te schrijven. Dit is nuttig als je slechts één regel tekst moet schrijven maar heeft geen enkele zin wanneer je video, vensters, afbeeldingen enz. op het LCD-scherm wil afbeelden.
De bedoeling is dus, om de nodige gegevens naar het juiste geheugenadres te schrijven, na eerst enkele configuratie-instellingen naar andere geheugenplaatsen te schrijven (LCD aanzetten, brightness juistzetten, de startpositie voor de cursor aangeven ...). Gezien we echter geen opleiding van ingenieur achter de rug hebben is dit een moeilijke opdracht voor ons.
Voor de rest van de week zijn we dus (op aanraden van Dhr. Haluin) op zoek gegaan naar kleine voorbeeldprogrammaatjes die het gebruik van het LCD-scherm demonstreren voor het specifieke doelplatform. Informatie hierrond is echter héél schaars zowel op het internet als in boeken. Het enige voorbeeldprogramma waar we ondertussen over beschikken is één dat we kregen van de fabrikant Freescale (de fabrikant van de i.MX27 processor die op het doelplatform aanwezig is) na via e-mail contact op te nemen. Dit programma is echter wel gemaakt om te werken met de gebruikte processor, maar is niet ontwikkeld voor het exacte ontwikkelaarsbord (andere geheugenadressen van registers). Bijkomend probleem stelt zich ook omdat het met een aangepaste ontwikkelomgeving gecompileerd is, die niet compatibel is met ons ontwikkelaarsbord (andere compiler). Het voorbeeldprogramma zal waarschijnlijk wel een hulp zijn op gebied van enkele methodes maar kan dus onmogelijk op ons platform uitgevoerd worden.
Voor de rest van de week zijn we dus (op aanraden van Dhr. Haluin) op zoek gegaan naar kleine voorbeeldprogrammaatjes die het gebruik van het LCD-scherm demonstreren voor het specifieke doelplatform. Informatie hierrond is echter héél schaars zowel op het internet als in boeken. Het enige voorbeeldprogramma waar we ondertussen over beschikken is één dat we kregen van de fabrikant Freescale (de fabrikant van de i.MX27 processor die op het doelplatform aanwezig is) na via e-mail contact op te nemen. Dit programma is echter wel gemaakt om te werken met de gebruikte processor, maar is niet ontwikkeld voor het exacte ontwikkelaarsbord (andere geheugenadressen van registers). Bijkomend probleem stelt zich ook omdat het met een aangepaste ontwikkelomgeving gecompileerd is, die niet compatibel is met ons ontwikkelaarsbord (andere compiler). Het voorbeeldprogramma zal waarschijnlijk wel een hulp zijn op gebied van enkele methodes maar kan dus onmogelijk op ons platform uitgevoerd worden.
Ondertussen hebben we ook contact opgenomen met de leverancier van ons ontwikkelaarsbord (Phytec) voor een voorbeeldprogramma maar we kregen nog geen reactie.
Dhr Haluin is zich bewust van het feit dat we geen ingenieursopleiding genoten hebben en zal ons persoonlijk proberen te helpen met het ontwikkelen van de nodige basisfuncties van zodra hij tijd heeft (momenteel heeft hij het te druk tot eind volgende week).
Hieronder enkele foto's de begrippen ontwikkelaarsbord en doelplatform moeten verduidelijken:
Het kleine lichtgroene deel is het doelplatform en is dus wat aanwezig zal zijn in het afgewerkte apparaat. De rest is het ontwikkelaarsbord met daarop aangesloten het LCD-scherm.
Hello world!
Linux werkend op de host-pc
Vanop afstand
Groeten uit Brive
Hannes Claerhout
Dieter Walckiers
dinsdag 4 maart 2008
Welkom
Hallo, en welkom op onze stage-blog. Hierop zullen op regelmatige basis rapporten verschijnen die een overzicht geven over onze vorderingen hier.
Tot nu toe hebben we nog geen specifieke opdracht gekregen. We hebben een gesprek gehad met Mr. Haluin, die ons wist te vertellen dat er iemand van Dioptik, het opdrachtgevende bedrijf, een dezer dagen verwacht wordt. Hij zal ons haarfijn uitleggen wat er moet gebeuren. Wat we tot nu toe weten is dat het zal handelen over het programmeren van een micro-controller die een camera aanstuurt, via een touchscreen. De beelden moeten kunnen worden gecomprimeerd en opgeslaan ofwel verstuurd via internet.
Het programmeren zal gebeuren in C++, een taal die we ons dus eerst meester moeten maken in de komende dagen.
Updates van zodra beschikbaar!
Tot nu toe hebben we nog geen specifieke opdracht gekregen. We hebben een gesprek gehad met Mr. Haluin, die ons wist te vertellen dat er iemand van Dioptik, het opdrachtgevende bedrijf, een dezer dagen verwacht wordt. Hij zal ons haarfijn uitleggen wat er moet gebeuren. Wat we tot nu toe weten is dat het zal handelen over het programmeren van een micro-controller die een camera aanstuurt, via een touchscreen. De beelden moeten kunnen worden gecomprimeerd en opgeslaan ofwel verstuurd via internet.
Het programmeren zal gebeuren in C++, een taal die we ons dus eerst meester moeten maken in de komende dagen.
Updates van zodra beschikbaar!
Abonneren op:
Posts (Atom)