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
Geen opmerkingen:
Een reactie posten