Alea iacta est

Het zit erop!

Als afsluiter van de periode hebben we zoals eerder aangekondigd een week in Limoges doorgebracht, in het opdrachtgevende bedrijf Dioptik, waar we gisteren een eindpresentatie hebben gehouden. Jammergenoeg kon de stagementor daarop niet aanwezig zijn omdat hij zelf op een buitenlandse missie is. Het departementshoofd van de universiteit was er echter, en vormde dus samen met de wetenschappelijke directeur en een ingenieur van Dioptik de jury. De presentatie is onthaald op zeer positieve reacties en vormde de kers op de taart van de drie boeiende maanden.

Meer details over ons reilen en zeilen hier komen aan bod op onze thuispresentatie en in ons dossier.

Een laatste zuidelijke groet, en tot binnenkort!

Dieter Walckiers
Hannes Claerhout

Testen netwerkmogelijkheden, aanhoudende problemen op gebied van video

Hallo

Gezien we momenteel niet verder na kunnen gaan of op het gebied van lens alles correct werkt (zie vorige week) hebben we ons toegespitst op de andere gebieden die nog voorzien moeten worden in het project:

1) versturen van videosignaal via wifi
2) encoderen van videosignaal in h.264 of ander mpeg-4 formaat.

Gezien er op het ogenblik nog niet echt een wifi-oplossing in zicht is, hebben we tests ontwikkeld voor de klassieke ethernetverbinding. We gaan er van uit dat het wifi-gedeelte voor de stuurprogramma's is en dat het er uiteindelijk op neerkomt om via de juiste interface pakketjes te verzenden (hetzij wifi, hetzij bedraad ethernet).

We slaagden er ondertussen in om de bitmap die we al eerder gebruikten in onze tests (of eender welke) te versturen via UDP en die aan de andere kant opnieuw te laten omzetten in een volwaardige afbeelding. Op dat gebied ziet het er dus goed uit, op voorwaarde dat er ondersteuning voor draadloze adapters ontwikkeld wordt natuurlijk... .

Op het gebied van de videomogelijkheden, blijft de situatie er somber uit zien. We hebben dan wel die nieuwe camera ontvangen en de driver communiceert daadwerkelijk met dit type, maar de driver is blijkbaar nog erg instabiel. We schreven een testprogramma dat gebruik maakt van de video4linux API, - waaruit blijkt dat er wel degelijk gecommuniceerd wordt met de camera - maar op het moment dat de opdracht gegeven wordt om de gegevens van de camera te gaan versturen, loopt alles vast => In de zin dat heel de machine opnieuw moet opgestart worden.

Om na te gaan of het probleem bij onze code lag, hebben we dit testprogramma verstuurd naar ontwikkelaars die hetzelfde type camera gebruiken (maar op een ander hardwareplatform) en zij bevestigden ons dat de code bij hen werkte... . Het probleem zit dus niet in de code, maar in de voorlopig onstabiele driver voor de camera. We contacteerden de ontwikkelaars van de linuxdistributie voor ons platform en ze zijn het probleem aan het inspecteren.

Bij het tweede nog uit te werken topic, zijnde het encoderen van het videosignaal, steken er ook enkele problemen de kop op. Onze hardware (de microcontroller op zich) heeft mogelijkheden om video hardwarematig te coderen naar een ander formaat, maar deze functies zijn op dit ogenblik nog niet geïmplementeerd in onze linuxdistributie.

Een concurrent heeft echter wel reeds bibliotheken ontwikkeld voor dit soort microcontroller, maar zij maken gebruik van een ander ontwikkelplatform. We inspecteerden of het eventueel mogelijk was om deze bibliotheken te compileren voor ons platform, maar dat bleek volstrekt gekkenwerk te zijn, gezien daar ook gebruik gemaakt wordt van specifieke broncode voor dat andere ontwikkelplatform.

Kortom: de bal ligt in het kamp van de ontwikkelaars van de distributie op ons platform om vooruitgang te kunnen boeken op het gebied van alles wat video betreft. (te betreuren)

We zullen zien hoe de situatie zich nog verder ontwikkelt volgende weken. We hebben in ieder geval nog meer dan werk genoeg in verband met documentatie schrijven en opzoekwerk verrichten naar andere oplossingen, dus we zullen niet stil zitten!

Een vriendelijke groet

Hannes Claerhout,
Dieter Walckiers

Project stall

Opnieuw een vervroegde blogpost omdat deze week ook een verkorte is, 8 mei is namelijk een nationale herdenkdag hier.

Ons project heeft momenteel te kampen met een grote vertraging, om verschillende redenen.
Wat de I2C bus betreft is het de communicatie met de hardware, dus de lens, die schort. Via de oscilloscoop hebben we het signaal proberen te onderscheppen dat door het kaartje van Varioptic (zie foto) in theorie zou moeten worden geconverteerd van digitaal naar analoog (tussen 0 en 60 volt), maar we slaagden er niet in om iets te visualiseren, buiten wat willekeurige ruis.
Met een multimeter zijn we alle bereikbare connecties nagegaan en alles werkte, dus moet het het kaartje zelf zijn waarmee er iets scheelt.
Mr. Faugeras, directeur bij Dioptik, is deze namiddag langsgekomen en heeft op zijn beurt alles in zijn eigen kennis geprobeerd, waaronder de kabeltjes hersolderen, ook zonder resultaat.
Als we de datalijnen controleren die we doorsturen die dienen om het componentje aan te sturen op de I2C poort, dus waar ze het ontwikkelingsbord verlaten, zien we dat alles naar wens verloopt. Ze zijn zichtbaar op de oscilloscoop en we zien effectief die bits passeren die we doorsturen vanuit het programma (zie blogpost van 25 april). Dus softwarematig is alles in orde en is ons taak vervuld (op dat vlak). Maar hardwarematig is er dus een defect.
Een nieuw component bestellen zou een wachttijd van 2 weken betekenen, dus daar zit een probleem. Mr. Faugeras uitte echter de mogelijkheid om een gelijkaardige kaart te lenen uit een ander project, om na te gaan of het daarmee wel gaat, en om zo dus de code die we hebben geschreven om de focus aan te sturen 100% te kunnen testen.
Maar voorlopig kunnen we op dat vlak niet meer dan afwachten.
Dat betekent niet dat we met ons vingers zullen draaien, er zijn nog zo veel aspecten om mee te experimenteren. Zoals de WIFI functie. Want het is nog steeds de uiteindelijke bedoeling om de gerecupereerde beelden van de camera ook over een draadloos netwerk te versturen. Dus dat is een uitdaging voor volgende week.


Varioptic digitaal-analoog convertor kaartje, dimensies ongeveer 1 op 1,5 cm

Vriendelijke groeten vanuit het zuiden

Dieter Walckiers
Hannes Claerhout

Aanhoudende camera-problemen, verdere experimenten I2C

Hallo

Wegens het verlengd weekend een vervroegde-blogpost over deze korte week. Terwijl Dieter zich samen met de stagiair van de IUT verder bezighoudt met het programmeren van de I2C-bus, blijven de problemen op het gebied van de camera oplopen.

De camera wordt gestuurd met een heel recent stuurprogramma, waar er nog hier en daar kinderziektes in zitten. Er zijn namelijk verschillende types van dit soort camera, wat voor problemen zorgt. De driver is in principe ontwikkeld voor het type camera met een I2C GPIO expander, die ervoor zorgt dat op de 10 datalijnen een multiplexing kan plaatsvinden.

Ons type camera echter is een type waar de GPIO expander niet op aanwezig is. We slaagden er wel al in om te communiceren met de camera, maar niet tot op het gebied waar de eigenlijke afbeeldingsgegevens overgebracht kunnen worden. Even verduidelijken:

Om een camera te laten beelden opvangen vanuit linux zijn er twee absolute vereisten:

- Een driver voor de camera zelf
- Een soort van bijkomende 'driver' die gebruikt maakt van de video4linux API in C

Het komt er dus op aan om met de functionaliteiten die in video4linux zitten, direct te communiceren met de driver van de camera door gebruik te maken van ioctl. Het proces om te kunnen 'capturen' van de camera is als volgt:

- Het videoapparaat openen
- Het videoapparaat initialiseren
- Beginnen met 'capturen'
- Loopen en gegevens verwerken
- Stoppen met 'capturen'
- Het apparaat desinitialiseren
- Het apparaat sluiten

Voor het ogenblik zitten we vast in de fase van het initialiseren. Tijdens de initialisatiefase worden er allerlei velden gelezen en geschreven van/naar de cameradriver. We kunnen zien dat er reeds verschillende stappen van het lezen/schrijven succesvol uitgevoerd worden, maar het probleem stelt zich bij het instellen van het te capturen formaat.

Gezien we voor het ogenblik niet beschikken over een gemultiplexte camera, moeten we gebruik maken van het formaat BAYER16, terwijl de gemultiplexte camera gebruik maakt van het BAYER8 formaat. Op zich zou dit geen probleem mogen zijn, maar de camera is (waarschijnlijk voorlopig) zo gecodeerd dat hij enkel met het BAYER8 formaat overweg kan.

We hebben gecommuniceerd met de schrijvers van deze drivers en zij beschikken over nieuwere versies van dit stuurprogramma waar dit probleem zich niet meer mee voordoet. Om deze te kunnen gebruiken moet er een kernel gecompileerd worden die niet specifiek voor ons platform is aangepast. Dit hebben we geprobeerd, maar zonder succes.

De enige overblijvende oplossing was dus om een nieuwe camera te bestellen die wel over deze GPIO I2C expander beschikt, zo zijn we ook iets zekerder dat er in de toekomst minder problemen zullen zijn (algemeen gezien meer ervaring met dit type). De camera kan vandaag nog geleverd worden, zoniet wordt het voor maandag.

Wij wensen u een prettig weekend,

Hannes Claerhout
Dieter Walckiers

Kernel patch, I2C bus, camera probs

De vooruitgang deze week kwam aanvankelijk moeilijker op gang, maar in de loop ervan zijn er toch enkele belangrijke doorbraken geweest.
Het project is op dit moment opgesplitst in twee aandachtpunten: De camera en de focus. Beide apparaten werken via een I2C bus, en hier komen we bij de oorzaak van de moeilijkheden waar we vooral maandag en dinsdag mee hebben gekampt. Er was namelijk geen overeenkomstig apparaat voor de I2C bus in de /dev map in Linux.
Dit was ons al opgevallen vlak voor de verlofweek, en we hebben het gemeld aan de ontwikkelaars van de versie van Linux die op de target draait. In het begin van de week hadden ze dan ook een patch geschreven die gebruikt moest worden bij het recompileren van de kernel (op de target). Echter zonder directe betering. Na lang zoeken was er al sprake van een nieuwe versie van de camera te bestellen, die beter zou functioneren met de bestaande drivers. Toen bleek dat het een bepaalde module was die het probleem veroorzaakte, GPIO. Toen we deze optie uitschakelden voor het recompileren van de kernel hadden we enkele nieuwe devices; enerzijds voor de camera: /dev/video0, en (door het aanvinken van alle compilatie-opties die met I2C te maken hadden) 2 I2C apparaten; /dev/i2c-0 en /dev/i2c-1.
Hierna kwam er terug vaart in de situatie. Er kon geëxperimenteerd worden met de broncodes die werden gevonden voor de communicatie met de camera. Hier werd duidelijk waarvoor die GPIO module eigenlijk nodig was. Zonder deze module kunnen we enkel pure rood – groen – blauw waarden schrijven naar de camera. Dus complexere beelden afbeelden wordt niet evident.
Er waren nog enkele andere problemen, kortom, zoals eerder vermeld, deze driver werkt simpelweg niet goed met ons type camera. Daardoor is, samen met opdrachtgevend bedrijf Dioptik, de beslissing genomen een nieuwe camera te bestellen die beter samenwerkt met de driver. Voorlopig zit het op dat vlak dus even vast, maar er is nog altijd de focus ook om ons op te concentreren.
Ook deze wordt gecontroleerd door een I2C bus, die dus dankzij de patch beschikbaar is geworden.
Al vrij snel hadden we een stukje voorbeeldcode te pakken, die aantoont hoe de device geopend dient te worden en een correct adres dient te krijgen.

#define DEVICE “/dev/i2c-0”
#define addr 0x40
fd = open(DEVICE, 0_RDWR);
if(fd<0)
{
printf(“\Erreur, impossible d’ouvrir %s”, DEVICE);
exit(1);
}
if(ioctl(fd,I2C_SLAVE,addr) < 0);
{
printf(“\Erreur, impossible de sélectionner le composant i2c a l’adresse 0x%x: %s”, addr, strerror(errno));
exit(1);
}

De ioctl() functie wijst de addr variabele toe aan I2C_SLAVE, zodat gecommuniceerd kan worden met de slave, in dit geval dus de focus. Natuurlijk, zoals zo vaak in deze situaties, lukte dit niet zomaar. Het bleek hem om een banale syntax fout te gaan.

if(ioctl(fd,I2C_SLAVE,addr) < 0);

Hier staat er een ‘;’ te veel. Syntaxfouten komen wel meer voor, maar ik vermeld dit gewoon even om een markant verschil met Java te illustreren. Deze fout zou in Java direct opgevallen zijn, maar aangezien de C compiler zeer toelatend is ging het er zonder problemen door, met als gevolg dat hij het als een statement beschouwde, en de inhoud tussen de haakjes sowieso uitvoerde. Hierdoor leek de ioctl() functie steeds te falen.
Zodra dat recht gezet was, konden we beginnen testen met het schrijven naar de I2C bus.

char trame[3]; trame[0]=0x04; trame[1]=0x99; trame[2]=0x01;
If (write(fd, trame, 3) < 0)
{
fprintf(stderr, “failed to write : %m\n”)
}

Dit gaf als resultaat "failed to write : remote I/O error"
We waren echter niet zeker of het adres dat we toewezen aan de I2C_SLAVE wel het juiste was. Dit hadden we weliswaar afgeleid uit de handleiding van de lens, maar het was niet zeer duidelijk. Dus besloten we een klein algoritme te schrijven dat via een for-lus alle adressen nagaat en verifieert op welk adres de functie write() geen -1 oplevert.
Echter geen succes. Geen enkel adres werd gevonden.
De oplossing zat hem in de manier waarop de connectoren van de lens waren bevestigd op de i2c poort. Er zijn namelijk verschillende connectoren die moeten verbonden worden met de pinnen van de i2c bus (Zie afbeeldingen). We hadden alles aangesloten gebruik makend van een tabel in de handleiding van het ontwikkelingsbord, waarvan hier de relevante lijnen:

PIN # SIGNAL NAME DESCRIPITION
1A VCC_CAM_EXT External Power supply
2A VCC_3V3 Power supply
3B CAM1_SDA SDA Quick Capture
4A CAM1_SCL SCL Quick Capture
5B GND Ground

Maar de VCC connector van de focus zat op pin 1A, een configuratie die gebruikt dient te worden als het om een apparaat gaat dat zelf een stroomtoevoer heeft, vandaar “external power supply”. Bij ons is dit niet het geval, de lens gebruikt de stroomtoevoer van het bord. Vandaar dat de VCC connector op pin 2A moet zitten, iets waar we eerst geen rekening mee hadden gehouden, en achteraf niet meer bij stil gestaan.
Dat verklaarde waarom hij geen adres vond. Bij het opnieuw runnen van onze code om het adres uit te vissen, kregen we deze keer wel resultaat, namelijk drie verschillende locaties: 0x0, 0x21 en 0x7E. Schrijven (via write()) naar deze locaties lukte, maar enkel schrijven naar adres 0x21 gaf een int 3 als return waarde, wat bleek te wijzen op het feit dat er 3 bytes succesvol waren weggeschreven. Dit was dus het enige juiste adres.
Via een oscilloscoop konden we de signalen die werden doorgestuurd verifiëren en concluderen dat het inderdaad was hetgene we bedoelden (zie afbeelding).
Een anekdote: de stagementor hier, Mr. Halluin, had er plezier in dat wij, software programmeurs in opleiding, ons aan het scheel staren waren op de kleine hardware componentjes!
Nu we weten dat de juiste elektronische signalen worden doorgestuurd naar de i2c poort, is de volgende stap de spanning controleren die doorkomt op de focus. Want het is namelijk een apparaatje dat elektronische signalen omzet naar spanning, en de lens verandert zijn focus op basis van deze spanning.
Meer hierover volgende week!


De i2c poort waarop de focus wordt aangesloten


De connectoren van de focus, die dus op de pinnen van de i2c poort moeten


Focus geconnecteerd, op de correcte manier


Opstelling, verbonden met een oscilloscoop, om te meten welke elektronische signalen worden doorgegeven


De output van de oscilloscoop (het onderste signaal is de klok). Hierop is te zien dat we eerst de waarde van het adres doorsturen (0x21, dus 0010 0001), gevolgd door een acknowledgement (kleine uitstulpsel naar onderen toe). Hierna volgt de informatie van de trame variabele: 0x04, 0x99, 0x01.

Groeten vanuit Brive.

Dieter Walckiers
Hannes Claerhout

Zoektocht naar camera-modules en onderzoek naar threads

Hallo

Deze week hebben we ons vooral toegespitst op het laten functioneren van de camera. We moesten voordien wachten op een speciaal aansluitingskabeltje vooraleer we aan het sturen van de camera konden beginnen. De camera wordt zoals elk linux-apparaat bestuurd door het schrijven naar een specifiek /dev/ bestand. Het probleem dat zich stelt met de camera namelijk is dat er geen /dev/video0 (verwachtte apparaatnaam) aangemaakt wordt.

Eerst dachten we dat dit misschien te wijten was aan een slechte aansluiting van de bedrading, maar later bleek dat in de nieuwe versie van de BSP (zie vorige week); enkel een andere type cameramodule ondersteund wordt. We moesten dus op zoek gaan naar de bijpassende kernelmodules voor onze camera. We vonden reeds enkele geprecompileerde modules voor onze camera, maar deze werden gecompileerd op een ander platform dat niet compatibel is met het onze.

Gelukkig hebben we reeds enkele contactpersonen op IRC, die verantwoordelijk zijn voor de linuxdistributie op ons platform. We namen dus contact met hen op om te vragen of de camera in de nabije toekomst ondersteund zou worden. Men liet ons weten dat de modules voor de camera nog in aanmaak waren en erg onstabiel bleken. De dag erna echter, liet de ontwikkelaar van deze modules ons weten dat er onverwachte vooruitgang gebeurd was op het gebied van de modules. Hij beloofde ons dat als we enkele dagen zouden wachten we een afgewerkte versie zouden toegestuurd krijgen. Het wordt dus nog eventjes de kat uit de boom kijken, maar we hebben er alle vertrouwen in (in samenspraak met het opdrachtgevende bedrijf) dat het de moeite loont om af te wachten.

Verder hebben we ons wat geconcentreerd op het maken van documentatiebestanden voor onze reeds ontwikkelde testprogramma's. Er moet in gedachten gehouden worden dat wij slechts een prototype aan het ontwikkelen zijn en dat deze documentatie in een later stadium zeker nog van pas zal komen.

We dachten ook reeds aan de toekomst en hebben een klein testprogrammatje gemaakt op basis van threads. Het programma bestaat uit twee threads: een die gebruikt wordt om het programma af te sluiten en een andere die instaat voor het verplaatsen van een scrollbar. Later zullen we nood hebben aan een gelijkaardige opstelling, één thread die de scrollbar met de waarde voor de focus beheerst en een andere gelijktijdige thread die de input van de camera op het scherm tovert.

Volgende week zal er geen blogpost gemaakt worden, gezien de IUT zijn deuren sluit en er bijgevolg niet aan het project kan gewerkt worden.

Groeten uit Brive

Hannes Claerhout
Dieter Walckiers

Scrollbar, BSP update, I²C-Bus

De week is zeer gunstig begonnen op vlak van touchscreen mogelijkheden. In de loop van vorige week hadden we namelijk enkele problemen;
In de broncode van tslib was te zien hoe - na het laden van de touchscreen device - enkele benodigde modules werden geladen.
Deze device ("event0") laden leverde geen probleem (na verandering van het pad dat werd meegegeven in de code van "/dev/ts/" naar "/dev")

tsdevice = strdup("/dev/event0");
ts = ts_open (tsdevice, 0);

Pas bij het configureren ervan doken er enkele problemen op. Dit gebeurde met de functie ts_config met als argument de tsdevice. Hierin wordt een configuratiebestand ts.conf geopend.

f = fopen("/etc/ts.conf","r");

Dit configuratiebestand bevat een hoop commentaarlijnen waarvan men van de gewenste de commentaartekens moet weghalen zodat ze gelezen kunnen worden. Bijvoorbeeld, in het originele ts.conf bestand staat:

# Uncomment if you wish to use the linux input layer event interface
# module_raw input

Door de hekjes weg te halen voor module_raw input, zal het programma deze module proberen laden. Het heeft even geduurd voor dit duidelijk was, we waren er eerst niet opgekomen om de inhoud van ts.conf te bekijken.
Verder was er enige verwarring tussen het filesysteem op de target en dat van de host, omdat er op allebei een ts.conf bestand stond. Het ts.conf bestand op de host (ontwikkelingscomputer) zagen we per ongeluk aan als het ts.conf bestand in kwestie, op de target.

Maar de functie ts_config neemt dus tokens van dat ts.conf bestand en geeft de te laden modules (input in ons geval) door naar de functie __ts_load_module(...). Deze functie bouwt op zijn beurt een pad, dat oorspronkelijk "/lib/ts/" was, waar we effectief modules aantroffen, waaronder ook input.so. Het pad wordt dus gebouwd met de doorgegeven naam van de module als bestandsnaam.

strcpy(fn,"/lib/ts");
strcat(fn, "/");
strcat(fn, module); // doorgegeven modulenaam, "input" dus
strcat(fn, ".so");

Het zag er goed uit, maar bij het uitvoeren bleek dat de module niet werd gevonden, hoewel alles wel op de juiste plaats stond. Hier stonden we even voor een raadsel. De oplossing was uiteindelijk de module verplaatsen naar een andere map "/usr/lib/ts/". .so bestanden zijn namelijk shared objects, en de ene locatie is blijkbaar beter geschikt dan de andere om ze te delen. Het is nog niet geheel duidelijk waarom deze map wel werkte, maar het werkte, dus dat was positief!

De nodige modules werden geladen (naast de module_raw input waren er nog een paar gewone modules; pthres, variance, dejitter, linear) en de functies gebruikt in de broncode van ts_lib konden getest worden.
Functies werden aangepast en naar onze hand gezet. Al gauw slaagden we erin lijnen en pixels te tekenen met onze vinger, alsook drukknoppen te programmeren en na enig proberen deze drukknoppen te verslepen. Hierdoor was de stap minimaal om een scrollbar te maken, wat nodig is voor het uiteindelijke ontwerp.

Op dat vlak zit het dus goed. Er is in de loop van de week echter nog een andere uitdaging opgedoken. We kregen we een e-mail van Mr. Granger, een ingenieur van het opdrachtgevende bedrijf Dioptik. Deze vertelde ons dat er een nieuwere versie uit is van de BSP (board support package) dan de huidige op de target. Deze versie ondersteunt het vastleggen van video via een camera en heeft een grafische bibliotheek.

Het installeren van deze nieuwe BSP was niet zo eenvoudig. Eerst moesten we uitzoeken hoe de broncode juist gecompileerd moest worden, daarna moesten we de gecompileerde "images" op het ontwikkelaarsbord zien te flashen.

Het compileren gebeurt aan de hand van een tool genaamd ptxdist. Na het configureren en uitvoeren van ptxdist beschik je vervolgens over een nieuwe kernel-image en een image met het volledige bestandssysteem voor de target. Deze images kunnen normaal gezien snel op de target geflashed worden met behulp van de bootloader u-boot. Het flashen gebeurt dan via een ethernet-verbinding met een TFTP server op de ontwikkelingscomputer. Er is echter een probleem in de code van u-boot wat ervoor zorgt dat we de ethernet-interface niet kunnen gebruiken. De oplossing is dan ofwel (indien er al/nog linux op het bord staat) de images rechtstreeks via linux op het flashgeheugen te schrijven ofwel gebruik te maken van een windows-tool die het flashgeheugen kan updaten via een seriële poort. Gezien een vorige poging mislukt was en we bijgevolg geen toegang meer hadden tot de linuxversie op de target, hebben we dan maar de windows-tool gebruikt; met succes.

Donderdag zijn de directeur en een ingenieur van Dioptik weer langsgeweest, met deze keer ook de algemene directeur bij. Ze hebben onze vooruitgang bekeken en geduid hoe het verder moest. Ook meteen een misverstand uit de wereld geholpen, want wij waren er van overtuigd dat we een zoomfunctie moesten programmeren, terwijl het eigenlijk de focus van een lens is die we besturen. Het beeld scherpzetten dus.
Een illustratie die ze maakten toonde aan dat deze lens bestuurd moet worden via een I²C-bus, die elektrische signalen doorgeeft naar de lens. Op basis van deze signalen verandert bijgevolg de focus van de lens.

Deze concepten in praktrijk brengen is dan ook de uitdaging die ons rest voor volgende week.

Groeten vanuit het zuiden

Dieter Walckiers
Hannes Claerhout

LCD afbeelden + touchscreen functionaliteit

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

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!

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.

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

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!