Digital photo frame

Digital Photo Frame

Embedded software development met behulp van C++ & RTOS

Auteur: Tymen Abels

AFSTUDEERVERSLAG VOOR FONTYS HOGESCHOOL ICT Gegevens student:

Naam : Abels, T

Student nummer: 2090661

Opleiding: Technische Informatica Voltijd

Afstudeerperiode van 6 september 2010 t/m 28 januari 2010 (100 werkdagen) Gegevens bedrijf:

Naam: N.B.G. Industrial Automation BV Afdeling: Embedded Software Development

Adres: Hulsenweg 19

Postcode/plaats: 6031 SP Nederweert

Begeleider: Sieben I. , Software Architect Gegevens docentbegeleid(st)er:

Naam: Tilborg, Cees C. van

Gegevens verslag:

“Digital Photo Frame”

Embedded software met behulp van C++ & RTOS 6-1-2011

Getekend voor gezien door bedrijfsbegeleid(st)er: Datum: 6-1-2011

N B G I n d u s t r i a l A u t o m a t i o n H u l s e n w e g 1 9 N L - 6 0 3 1 S P N e d e r w e e r t T . + 3 1 4 9 5 6 3 3 2 2 1 F . + 3 1 4 9 5 6 3 4 4 9 5 E . i n f o @ n b g - i n d u s t r i a l . n l W . w w w . n b g - i n d u s t r i a l . n l

Digital Photo Frame

Customer: NBG Industrial Automation BV. Contact: Ivo Sieben

Scriptie

Embedded software m.b.v. RTOS & C++ - R21507

Author: Tymen Abels Total pages: 41

VERSION DATE AUTHOR STATUS REMARKS

V0.01 7-12-2010 Tymen Initieel

V0.02 13-12-2010 Tymen Reviewed Verschillende wijzigingen na review

externe persoon

V0.10 14-12-2010 Tymen Reviewed Wijzigingen doorgevoerd na review

Ivo Sieben

V0.11 3-1-2011 Tymen Aangepast NBG Huisstijl overgenomen voor dit

document.

V0.12 4-1-2011 Tymen reviewed Na bezoek van docent aantal

aanmerkingen over het verslag

doorgevoerd en afronden

openstaande delen

V1.00 6-1-2011 Tymen Afronding Laatste onderdelen bijwerken en

Voorwoord

De stageopdracht die ik heb aangenomen is: “embedded software met behulp van RTOS & c++ “

Hieruit hebben wij een case gemaakt waarin ik een digitaal foto lijstje ontwikkel met de bedoeling om functionaliteiten van het RTOS aantoon.

De tijdsperiode die gereserveerd was voor deze opdracht is 20 weken ( oftewel 100 werkdagen ).

Graag wil ik mijn stagebegeleiders, Dhr. Sieben en Dhr. Van Tilborg bedanken voor hun begeleiding gedurende de periode. Eveneens wil ik graag de collega’s bedanken voor hun medewerking gedurende de stageperiode.

Contents

3.1 Historie van de opdracht...13

3.2 Initiële opdracht... 13

3.3 De uiteindelijke opdracht... 14

4. Inleiding op eCos ( embedded configurable operating system)...15

5. Initiële fase... 18

5.1 Kennismaking... 18

5.2 ontwikkelomgeving... 18

5.3 Plan van aanpak... 19

6. Ontwerp fase... 20

6.1 plan van aanpak... 20

6.2 requirements... 20

6.3 Ontwerp... 21

7. Onderzoek... 22

7.1 Risico analyse... 22

7.2 FAT File systeem... 22

7.3 Grafische user interface...23

7.4 http server... 24

7.5 FTP Server... 25

7.6 Ethernet stack... 25

7.7 JFFS2 NANDflash... 26

7.8 conclusies uit het onderzoek...26

8. Implementatie... 27

8.1 Deelsoftware... 27

8.2 FAT file systeem... 27

8.3 Ethernet stack... 28

8.4 Graphical User Interface...28

8.4.1 implementatie framebuffer...28

Evaluatie... 40 Literatuurlijst... 41 Bijlage A: Plan van aanpak... Bijlage B: Class Diagram... Bijlage C: Uitwerking uit de risico Analyse... Bijlage D: Requirements

Samenvatting

De stagiaire “Tymen Abels” heeft voor zijn afstudeeropdracht gekozen voor “Embedded software met behulp van RTOS & C++” bij NBG Industrial automation BV gevestigd te nederweert. Als stagebegeleider vanuit Fontys hogescholen ICT gevestigd te Eindhoven werd Dhr. C. van Tilborg aangesteld, hiernaast als bedrijfsbegeleider Dhr. I. Sieben.

De beginsituatie van deze stage luidde dat er een embedded platform was met een “Atmel 32bits ARM processor”. Hierop was deels een real time operating systeem geïntegreerd met een ethernet functionaliteit en een bootloader die er voor zorgt dat het systeem op kan starten, echter waren er vanuit het bedrijf wensen om meer functionaliteit te implementeren in het real time operating systeem. Dit real time operating systeem heet eCos.

Tijdens brainstorm zijn enkele functionaliteiten genoemd die mogelijk meegenomen konden worden in de opdracht. Dit waren:

- “Fat file systeem, Framebuffer driver, NAND flash support via JFFS2, een nieuwer type processor ondersteunen, USB, audio, HTTP server en FTP server”.

Nadat hieruit een keuze was gemaakt, zijnde:

- het filesysteem, framebuffer, NANDflash, http en ftp server.

De opdracht werd door de stagiaire betiteld met “Digital Photo Frame” gekoppeld aan de opdracht. Dit gezien de functionaliteiten veel weg hadden van een digitaal foto lijstje.

Het programmeren van software brengt risico’s met zich mee waardoor er besloten werd een risico analyse uit te voeren waarna de conclusies hieruit bindend waren voor het eindproduct. Door vooraf risico’s in te schatten van de te realiseren software wordt voorkomen dat er teveel beloofd wordt. De volgende delen zijn beloofd:

- Grafische user interface, file systeem voor ondersteunen van een SD kaart, FTP server, http server.

Na deze afbakening kon een begin gemaakt worden aan de eisen aan dit product en samenhangend een ontwerp van de te realiseren software. Hiervoor is gekozen zodat voor het implementeren van de software helder kan worden gemaakt wat het eindproduct dient te kunnen. De eisen zijn vastgelegd middels use cases, het ontwerp is volgens de UML methode. Deze methode is het meest voorkomend bij object georiënteerde software.

Tijdens het realiseren van de software is ervoor gekozen om het meest risicovolle deel als eerste te realiseren, dit was de grafische interface. Deze bestond uit een framebuffer driver die door de stagiaire volledig zelf geprogrammeerd is geworden en een software pakket die een afbeelding naar dit framebuffer schrijft. Het framebuffer zorgt ervoor dat de data op het scherm wordt getoond.

Hiernaast is de FTP server door de stagiair gerealiseerd. De server was deels te vinden op internet om te gebruiken, echter om het opslagmedium hieraan te koppelen moest de stagiair zelf programmeren. Eveneens de niet correcte werking van de server diende door de stagiair te worden opgelost.

De overige software was beschikbaar binnen eCos en kon na de juiste configuratie, die door de stagiair volledig uitgezocht diende te worden, gebruikt worden voor het fotolijstje, dit waren de http server en de ethernet functionaliteit. Deze software bevatte de minste risico’s

De hoofdapplicatie is als laatste gerealiseerd die er zorg voor draagt dat alle sub systemen geïnstantieerd worden evenals het tonen van de afbeeldingen en het instellen van de afspeel modus en de intervaltijd tussen de 2 foto’s . Deze configuratie wordt opgehaald uit een tekstbestand die zich op de geheugenkaart bevindt.

Concluderend uit het voorgaande kan worden gesteld dat de stagiaire begonnen is met het uitwerken van een opdracht, vervolgens hier de eisen voor heeft opgesteld, daarna een onderzoek naar de risico’s voor het

Verklarende woordenlijst

Definitie Omschrijving

.bmp Bitmap file extension, formaat die veelal gebruikt wordt bij afbeeldingen. .jpg Extension voor afbeeldingen, ander formaat dan bitmap, eveneens veel gebruikt. ARM Advanced RISC Machine, Het meest gebruikte ISA in de 32 bit embedded wereld DMA Direct Memory Acces, laat toe data over te brengen van een niveau in de

geheugenhiërarchie met een minimale tussenkomst van de Central Processing Unit. DPF Digital Photo Frame, De naam van dit project

eCos Embedded Configurable Operating System, Naam van het RTOS dat in dit project gebruikt is geworden.

ESD Electro Static Discharge, term die veel gebruikt wordt bij gevoelige elektronica FAT File allocation table, is een bestandssysteem.

FTP File transfer protocol, methode om data van een client naar de server te versturen over het internet en vice versa.

GUI Graphical user interface, De interface met grafische aspecten zoals foto’s die de gebruiker kan zien.

HTTP Hyper text transfer protocol, protocol voor de communicatie tussen webclient en server. ICT Informatie en Communicatie Technologie, een vakgebied dat zich met

informatiesystemen, telecommunicatie en computers bezighoudt.

IP Internet Protocol (een adres waarmee een netwerkkaart van een host in een netwerk eenduidig geadresseerd kan worden binnen het TCP/IP-model)

ISA Instruction Set Architecture

JFFS2 Journalling Flash File System, log gestructureerd file systeem die gebruikt wordt voor het schrijven van flash geheugen

LCD Liquid Crystal Display, een plat beeldscherm met een laag energieverbruik.

MMC Multi Media Card, een geheugenkaart die is opgebouwd met flashgeheugen. De voorloper van SD

Mount Het kenbaar maken van een verwijderbare disk aan een file systeem.

Open source beschrijft de praktijk die in productie en ontwikkeling vrije toegang (open) geeft tot de bronmaterialen (de source) van het eindproduct.

PC Personal Computer

RISC Reduced Instruction Set Computer

Root directory Hoofdmap waarin andere mappen en of bestanden zich kunnen bevinden (top van de boom)

RTOS Real Time Operating System

SD kaart Secure Digital kaart, een geheugenkaart die is opgebouwd met flashgeheugen. unmount Verwijderbare disk klaarmaken voor verwijdering.

USB Universal Serial Bus, een standaard voor de aansluiting van randapparatuur bij computers. Webbrowser Een programma waarmee internet pagina’s getoond kunnen worden op het PC scherm

1

Inleiding

Digitaal fotolijstje bijwerken zonder gedoe met geheugenkaart? Het kan!

Veel mensen worstelen met geheugenkaarten om hun foto’s vanaf de PC naar het digitale foto lijstje te zetten. Er is een tijd geen slideshow omdat de geheugenkaart niet in de digitale fotolijst zit, het kaartje moet in een cardreader welke aangesloten zit aan een PC. Dit wordt vaak als vervelend ervaren. Vanaf nu is dit verleden tijd doordat deze Digital Photo Frame rechtstreeks vanaf de PC naar het lijstje foto’s verzonden kunnen worden.

De case om een digitaal foto lijstje te realiseren kwam tot stand doordat de initiële stage opdracht (zie hoofdstuk 3) een concreet resultaat moest bevatten. Echter niet zomaar een fotolijst, maar een waarmee je vanaf je PC direct foto’s kan inladen en verwijderen zonder dat de geheugenkaart uit het lijstje moet, en deze tevens configureerbaar is via een website.

NBG Industrial Automation bv, een onderdeel van Sioux, is een bedrijf die zich richt op verschillende branches en technologieën, deze zijn:

- Grafische technologie - Logistieke technologie - Medische / zorg technologie - Elektronica

- Machinebouw

- Amusement

Eveneens heeft zij sinds kort de beschikking over een productieruimte waarin assemblage plaats kan vinden van elektrostatisch gevoelige onderdelen.

In hoofdstuk 2 zal meer achtergrond informatie over het bedrijf NBG Industrial Automation bv worden gegeven. Hierna volgt de opdracht in hoofdstuk 3, gevolgd door een korte inleiding op het gebruikte real time operating systeem eCos in hoofdstuk 4.

Hoofdstuk 5 omschrijft de initiële fase van de stage, waarna het ontwerp in hoofdstuk 6 aan bod komt. Vervolgens bevat hoofdstuk 7 het onderzoek dat gedaan is naar de functionaliteiten van deze opdracht.

De implementatie van het eindproduct met de problemen die onderweg zijn tegengekomen tijdens het programmeren worden beschreven in hoofdstuk 8, vervolgens de conclusies in hoofdstuk 9.

2

Het Bedrijf

In dit hoofdstuk zal het bedrijf NBG Industrial Automation B.V., verder genoemd als NBG, nader worden toegelicht. Er zal meer duidelijkheid komen over de aard van de werkzaamheden van het stagebedrijf. Het ontstaan van het bedrijf, de technologieën binnen het bedrijf en de organisatie zullen onder andere aan bod komen.

2.1

Geschiedenis

NBG is opgericht op 1 maart 1994 en werd gevestigd in het pand aan de Hulsenweg 15 te Nederweert. Het bedrijf is door G. Bruinsma, T. Naus en nog vijf andere personen opgericht. G. Bruinsma (commercieel directeur) en T. Naus (technisch directeur) zijn samen met GeRuKo en ETF de aandeelhouders van dit bedrijf. De afkorting NBG staat voor Naus, Bruinsma en GeRuKo.

NBG maakte een grote groei door, waardoor het onderkomen uiteindelijk te klein werd. Om die reden verhuisde het bedrijf in januari 2006 naar het pand aan de Hulsenweg 19, waar het bedrijf heden ten dagen gevestigd is. NBG telt op het moment van schrijven 25 full time medewerkers.

Drie jaar na de oprichting had NBG al een goede plaats verworven binnen de industrie. Er werd een

samenwerkingsverband gesloten met het innovatiecentrum Syntens. Via het KIC-project (Kennis Intensieve Clustering) kwam NBG positief in de pers. In het jaar 1999 werd gestart met de eerste opzet voor een kwaliteitssysteem op basis van het MKB (Midden en Klein Bedrijf) groeicertificaat. Op 1 oktober 1999 werd de eerste versie van het

kwaliteitssysteem NBG-breed ingevoerd. Het jaar 2000 werd een topjaar voor NBG mede door het ingevoerde kwaliteitssysteem. Door verandering van de markt kreeg NBG te maken met grotere projecten dan voorheen. Door dit feit werd NBG gedwongen om grotere risico’s te lopen.

In 2003 kromp de Nederlandse economie voor het eerst sinds 1982 met 0,9% in. Ook NBG kreeg te maken met deze economische tegenvaller en werd voor het eerst gedwongen in te krimpen door het tijdelijk stopzetten van contracten. Aan het einde van 2003 herstelde NBG door de verbetertrajecten. Het in 2002 ingevoerde “Personeels-Functionerings-Systeem” zorgde voor een hogere betrokkenheid van de werknemers. De projecten konden beter binnen het

vastgestelde budget en de vastgestelde tijd worden afgerond. In samenwerking met Merit werd een traject opgezet om grote projecten beter in de hand te houden. Op het moment is NBG een flexibele en professionele organisatie die diensten aanbiedt op het gebied van elektronica, embedded software en PC software voor industriële en medische toepassingen.

Op 1 januari 2010 is NBG overgenomen en onderdeel geworden van Sioux. Hierdoor is H. Moonen er als nieuwe directeur bijgekomen, en de algemene directeur van NBG geworden. Dit heeft betekend dat NBG zich meer met de nadruk op elektronica ontwikkeling en productie richt. Hiervoor is in oktober 2010 een start gemaakt met het ontwikkelen van een productieruimte. Deze ruimte is geheel volgens de ESD richtlijnen ingericht. Tegenwoordig worden o.a. soepmachines ontwikkeld en geassembleerd in deze ruimte. Het streven van NBG is dat meerdere producten in deze ruimte geassembleerd en gerepareerd worden.

2.2

Technologieën

De technologieën waar NBG zich bezig houdt zijn de volgende: Elektronica op maat

De afdeling “Elektronica op maat” houdt zich bezig met de ontwikkeling van maatwerkelektronica. Dit betekent dat de klant het gemak ervaart van een in elektronica gespecialiseerde partner die het beoogde product van A tot Z

ontwikkelt.

Na het ontwerp (het schema en de lay-out) van het beoogde product, wordt wereldwijd naar de beste plek gezocht waar het product gerealiseerd kan worden. Voor het invoeren van de schema’s en het maken van de printlay-outs wordt gebruik gemaakt van een modern CAD systeem. Het resultaat hiervan is een volledig gedocumenteerde

(Embedded) besturingen

Deze afdeling houdt zich bezig met het programmeren van (Embedded) besturingen. Een voorbeeld kan zijn dat een product een of meerdere embedded targets aan boord heeft voor zijn beoogde functionaliteit. Hiervoor dient een regeling gerealiseerd te worden.

Deze software kan gebaseerd zijn op de traditionele talen zoals C, C++ en VHDL. Bij de object georiënteerde analyses wordt veelal gebruik gemaakt van UML (Unified Modelling Language) schema’s. Tevens wordt bij het realiseren van het ontwerp nauw contact gehouden met de klant om zijn laatste wensen en eisen door te voeren.

Doordat NBG gebruik maakt van de nieuwste methodieken, wordt er gebruik gemaakt van versiebeheer. Dit wil zeggen dat een historie wordt opgeslagen. Wanneer een project dat een jaar terug opgeleverd is enkele fouten vertoond, waardoor er aanpassingen moeten worden gemaakt aan de software, kan het voorkomen dat de methodieken nieuwer zijn en daardoor niet geheel samenwerken met de oudere software. De software wordt dan “terug in de tijd” (sub- version ) gezet waardoor de werking van de software gewaarborgd blijft.

Deze afstudeeropdracht bevindt zich in deze afdeling. .NET

Een van de nieuwere frameworks.NET wordt door NBG gebruikt voor het realiseren van PC Applicaties. Zo heeft .NET een grafische library waarmee gelikte grafische interfaces gerealiseerd kunnen worden. Het .NET framework is daarnaast geschikt voor het communiceren naar seriële poorten, CAN bussen en databases.

NBG beschikt over een bibliotheek met herbruikbare componenten voor de meest uiteenlopende toepassingen. Zodoende hoeft het wiel niet nog eens uitgevonden te worden.

Het modelleren en het ontwikkelen van het ontwerp van deze software wordt eveneens volgens de UML methode gerealiseerd.

LabVIEW Based Applications

De afdeling “LabVIEW Based Applications” houdt zich bezig met het ontwikkelen van applicaties op basis van LabVIEW. Deze programmeertaal is een product van National Instruments waarvan NBG een partner is.

De grafische programmeeromgeving LabVIEW is geschikt voor het verzamelen, analyseren, presenteren en opslaan van data. Het pakket werkt naadloos samen met een breed scala aan hardware, zoals meet- en regelinstrumenten, data-acquisitiekaarten, PXI-apparatuur, maar ook motoren en camera’s. Dit maakt het mogelijk om geautomatiseerde testsystemen, meetopstellingen en procesbesturingen te ontwikkelen.

Product- & Lijnautomatisering

De afdeling “product- & lijnautomatisering” zorgt voor de automatisering van nieuwe en bestaande productielijnen en het ontwikkelen van producten voor kleine series. In het kader van kostenbeheersing wordt bij de productontwikkeling in overleg met de opdrachtgever zoveel mogelijk gebruik gemaakt van standaard verkrijgbare componenten. Hierbij gaat het meestal om ‘intelligente’ softwarebesturing tussen de productiemachine en het logistieke systeem. Verder is een mens-machine-interface van belang en moet het ontwerp voorzien in uitwisseling van informatie naar onder- en bovenliggende systemen.

Regionale Samenwerkingsverbanden

Door nauwe samenwerking met specialistische bedrijven in complementaire branches verruimt NBG haar kennis en mogelijkheden om een zo compleet mogelijke service aan te kunnen bieden. De bundeling van beschikbare

technologieën en ervaring stelt NBG in staat om innovatieve concepten en producten te ontwikkelen. Van ideevorming tot service. Bij dergelijke “turn key” ontwikkelingsprojecten neemt NBG de verantwoordelijkheid voor het hele project. De opdrachtgever heeft daardoor een duidelijke juridische zekerheid en kan rekenen op een transparante financiële afhandeling.

Multidisciplinair Projectbeheer

Het team van NBG is in staat om leiding te geven aan multidisciplinaire samenwerkingsverbanden(verbanden waarbij meerdere specialismen zijn betrokken). Het doel is om optimaal gebruik te maken van kennis op diverse gebieden om zo in korte tijd opmerkelijke resultaten te kunnen bereiken. NBG is verantwoordelijk partner in de belangrijke fases van het definiëren van het probleem, de rapportage van specificaties en de structurele beoordeling van mogelijke

oplossingen. Het analyseren van risico’s en het onderzoeken van de haalbaarheid van een project zijn vanzelfsprekend belangrijke stappen in een plan van aanpak welke ze aan de opdrachtgevers voorleggen.

Productie

Sinds begin november 2010 is de productieruimte in gebruik genomen binnen NBG. De productieruimte telt in totaal 10 assemblage werkplaatsen en 2 reparatie werkplaatsen. Naast deze ruimte bevindt zich de expeditie waarin nieuwe ongeassembleerde producten binnenkomen. Eenmaal binnen de productieruimte moet alles voldoen aan de ESD richtlijnen. Zo dient iedere medewerker die binnen de ESD veilige zone een veilige jas te dragen en een hielader waardoor het lichaam ontladen is. Alvorens de veilige zone binnen te treden dient men eerst langs het teststation te testen of ze ESD veilig zijn. Deze ruimte wordt op het moment gebruikt voor een assemblage van een reeks soep machines. Daarnaast worden reparaties van kapotte onderdelen van klanten gerepareerd in de reparatieafdeling. In de toekomst wil NBG meerdere producten assembleren.

NBG heeft van een aantal projecten testopstellingen voor het ontwikkelen van software. Deze opstellingen bevinden zich eveneens in deze ruimte.

2.3

Organisatie

Figuur 1: Organogram organisatie NBG

Volgens het schema (zie figuur 1) valt de stageopdracht onder de afdeling development. In tegenstelling tot andere projecten binnen NBG is dit een eenmansproject, waardoor de onderverdeling van architecten, specialisten en engineers hiervoor niet geldt. De projectleider van het project is de bedrijfsbegeleider, I. Sieben.

3

De Opdracht

In dit hoofdstuk zal de stage opdracht nader toegelicht worden. Allereerst wordt de historie van deze opdracht uitgewerkt, daarna de initiële opdracht die de stagiair, Tymen Abels, heeft aangenomen en ten slotte wordt de uiteindelijke opdracht omschreven.

3.1

Historie van de opdracht

NBG richt zich voornamelijk op de 8 en 16 bits microcontrollers. Deze worden binnen hun projecten veelvuldig gebruikt. Echter omdat NBG in de toekomst 32 bits ARM processoren wil gebruiken, vanwege de extra capaciteit en prestaties, is er een start gemaakt met het ontwikkelen van drivers voor deze processoren.

Eveneens is gekozen om een real time operating systeem (kortweg RTOS) te implementeren voor de ARM processor die momenteel gebruikt wordt. Hierin zijn verschillende systemen, maar NBG heeft gekozen om eCos te gebruiken als RTOS. eCos staat voor “embedded Configurable operating system”. Voordeel ten opzichte van andere RTOS’en is dat het platform volledig configureerbaar is. De krachtige configuration tool zorgt ervoor dat met een muisklik

functionaliteiten zoals FTP server, Ethernet, Grafische support en file systemen kunnen worden toegevoegd aan het product. Omdat werknemers binnen NBG amper tijd hebben om hieraan te ontwikkelen worden deze als stage opdracht voorgeschreven.

Tijdens een voorgaande stage is dit RTOS al deels ontwikkeld. De opdracht was om dit operating systeem werkend te krijgen voor het AT91SAM9263 platform, dit is een 32 bits Atmel ARM processor.

Gedurende die stage bleek dat het operating systeem meer tijd in beslag nam dan aanvankelijk gedacht werd. Hierdoor is er uiteindelijk een bootloader geprogrammeerd en een kleine ethernet functionaliteit.

Hieruit is deze stage opdracht voortgekomen.

3.2

Initiële opdracht

De voorgeschreven opdracht binnen SAS+, De stagebank van Fontys hogescholen ICT, luidde: “Stuur een pretparkvoertuig aan met behulp van een RTOS”.

Tijdens het eerste gesprek werd meteen duidelijk dat deze opdracht niet met een pretparkvoertuig te maken ging hebben. Dit was een van de mogelijke oplossingen waarvoor het RTOS geschikt kon zijn.

De inhoud van de opdacht was nieuwe drivers ontwikkelen voor het bestaande platform. Hierbij is een keuze gemaakt voor een FAT file systeem, NAND flash support, ethernet functionaliteit en een slimme webserver. Daarnaast zijn enkele mogelijke uitbreidingen voorgesteld zoals USB support, en support voor een nieuwere ARM processor: de “AT91SAMG45”. Deze processor is de opvolger van de AT91SAM9263

3.3

De uiteindelijke opdracht

Tijdens besprekingen met de stagebegeleider ( Ivo Sieben ) werd gebrainstormd over de uiteindelijke opdracht. Het meest tastbaar wordt het product als de gebruiker visueel iets ervaart, zoals het tonen van foto’s. Aan het platform zit een LCD scherm bevestigd, waardoor al snel werd besloten deze te gebruiken in de opdracht. Tijdens het opstellen van de eisen werd het idee geopperd om een “Digital Photo Frame” te realiseren. Dit is natuurlijk al veelvuldig gerealiseerd, maar door deze case worden de functionaliteiten bewezen die beoogd worden in de initiële opdracht, plus het voordeel dat er een demonstreerbaar product gerealiseerd wordt.

Het “Digital Photo Frame” zal bestaan uit: - Het platform ( AT91SAM9263 ). - Een LCD waarop de foto’s te zien zijn.

- Een SD kaart waarop de foto’s zullen worden opgeslagen door middel van het gerealiseerde FAT file systeem - Een FTP server waarmee bestanden direct naar het SD kaart kan worden geschreven.

- Een http server waarmee het foto frame te configureren is.

- Configuratie van intervaltijd en afspeel algoritme ( hiermee wordt bedoeld waarop de foto’s gesorteerd worden).

Hierbij behoren alle drivers die geprogrammeerd dienen te worden voor deze bovengenoemde functionaliteiten evenals de applicatie die de logica tussen deze functionaliteiten verzorgd plus het bijbehorende software design van de applicatie.

4

Inleiding op eCos ( embedded configurable operating

system)

Dit projet gaat gebruik maken van eCos, dit is op voorhand al afgebakend door de opdrachtgever ( NBG ). Wat houdt eCos in?

Zoals de naam al doet vermoeden is het een configureerbaar operating systeem. Zo kan voor elke oplossing een keuze worden gemaakt uit de voorgeprogrammeerde generieke pakketen die eCos in zich heeft, om deze vervolgens te gebruiken en tot een totaalprogramma te werken. Zo kan het operating systeem zo licht en klein houden als dat de klant wil. In het onderstaande figuur staat weergegeven hoe eCos opgebouwd is.

Figuur 2: Outlay eCos

ECos biedt de mogelijkheid om voorgeprogrammeerde templates (voorgeselecteerde pakketen op basis van de beoogde functionaliteit) te gebruiken voor de meest voorkomende configuraties. Zodoende hoeft niet het hele project vanaf nul te worden opgebouwd. Het selecteren van benodigde componenten geschiedt via het selecteren van packages.

Figuur 3: package selecteren in de eCos configuratie tool

In deze packages zijn dan weer verschillende opties te kiezen. De selectie hiervan wordt door de programmeur gemaakt naar de beoogde functionaliteit die door de klant geëist is. In het ondergaande figuur staat weergegeven welke packages aanwezig zijn in eCos binnen NBG.

Omdat eCos een gratis variant heeft, is dit operating systeem door iedereen te gebruiken. Enig nadeel hieraan is dat ten opzichte van de betaalde versie, deze niet zodanig onderhouden wordt. Veelal zijn de bijdragen geleverd door hobbyisten, bedrijven en maintainers die hun sources aan eCos toevoegen. Dit is af te leiden in de “about eCos” op hun website. Daar wordt vermeld dat alle bijdrages welkom zijn. Vanwege het kostenaspect is de opensource variant van eCos een goed alternatief. Deze versie van eCos wordt gebruikt in dit project.

Online staat documentatie over de reeds geïmplementeerde software. Meeste software binnen eCos is generiek en niet hardware specifiek. Dit wil zeggen dat er logische functionaliteit geprogrammeerd is, echter de hardware specifieke taken zoals het schrijven naar een poort, of het initialiseren van registers moet softwarematig gerealiseerd worden. In de documentatie op de site van eCos staat vervolgens beschreven hoe de generieke software benaderd dient te worden.

5

Initiële fase

Aan het begin van mijn stage is allereerst kennis gemaakt met het bedrijf, alle werknemers en de ontwikkelomgeving waarmee de opdracht vervuld zal worden. Dit hoofdstuk zal omschrijven welke middelen tijdens deze stage gebruikt zijn. Hiernaast is in deze fase van de stage ook het plan van aanpak opgesteld met daarin de initiële opdracht.

5.1

Kennismaking

De kennismaking vond plaats op de eerste stagedag, waarin de arbeidsvoorwaarden besproken werden tussen de stagiair en de begeleider. De verschillende officiële papieren die getekend dienden te worden zoals het contract, loonbelasting en geheimhoudingsverklaring werden ingevuld. Er zijn afspraken gemaakt over de maandelijks te ontvangen stagevergoeding. Er werd een werkplek toegewezen met een PC. Daarnaast werden alle huishoudelijke regels die gelden binnen NBG besproken.

De looptijd van deze stage bedroeg 100 dagen ( 20 werkweken ).

5.2

ontwikkelomgeving

De ontwikkelomgeving gedurende deze stage omvatte de volgende elementen: - Het platform met de AT91SAM9263 ARM processor ( zie figuur 5)

- Randhardware: USB -> serial converter, Cardreader, seriële kabel, USB kabel, ethernet kabel, stroomadapter, SD kaart en LCD scherm.

Figuur 5: Het platform inclusief alle randhardware

Desktop PC met de volgende software aan boord:

- Eclipse galileo voor het schrijven van source code. - eCos versie 3.0 + configuratie tool.

- FileZilla client benodigd voor de ftp functionaliteit.

- Webbrowser voor het bekijken van de webserver op het platform. - Microsoft word voor het schrijven van documentatie.

- Wireshark voor het lezen van netwerk verkeer.

- Hyperterminal of een soortgelijk programma voor het communiceren met het platform - Microsoft project voor het realiseren van de planning.

5.3

Plan van aanpak

Tijdens deze fase is eveneens het plan van aanpak opgezet met daarin de afspraken tussen de stagiaire en de docent begeleider en begeleider vanuit de stageplek. In deze fase ging het om een concept dat vervolgens in de volgende fase is uitgewerkt en uiteindelijk naar een final stadium is gebracht en bevroren, dit wil zeggen dat het plan van aanpak niet meer gewijzigd zal worden.

6

Ontwerp fase

Na de initiële fase is een start gemaakt met het ontwerp van het eindproduct. In het plan van aanpak is gedurende deze fase alle benodigde informatie verwerkt over de opdracht. Eveneens is een WBS (work breakdown structure) gerealiseerd, om de tijdslijn van het project af te zetten tegen de geschatte tijd van het werk.Deze WBS is te vinden in bijlage A: Plan van Aanpak onder hoofdstuk Microsoft Project Planning.

Daarnaast zijn de requirements vastgelegd in een requirements document waarmee gebruik is gemaakt van Visual Paradigm, een programma om requirements in een model vast te leggen.

Tot slot is in deze fase gewerkt aan de risico analyse, waarin in hoofdstuk 7 het verloop hiervan beschreven wordt. Hieraan zat een go/No go moment gekoppeld waarin besloten werd welke onderdelen definitief in de opdracht meegenomen werden en welke geschrapt werden uit de opdracht.

Het eerste bezoek van de stage begeleider vanuit Fontys (Dhr. C. van Tilborg) vond binnen deze fase plaats.

6.1

plan van aanpak

Het initiële plan van aanpak was voor het eerste gesprek met de stagebegeleider vanuit Fontys Hogescholen ICT (Dhr. Van Tilborg) digitaal verzonden zodat tijdens de bijeenkomst deze besproken kon worden. Conclusie uit het gesprek was dat nog een aantal zaken onduidelijk waren, onder andere het definitieve doel zoals deze beschreven staat in hoofdstuk 3.3 “De uiteindelijke opdracht”. De fasering diende nog iets dieper uitgewerkt te worden naar aanleiding van dit doel. Dit doel is gedurende deze fase pas vast komen te liggen. Eveneens was een opmerking dat de spelling en grammatica door een derde persoon nagelezen dient te worden. Hierdoor ontstaat er een kwalitatief beter document. De beoogde doelen die tijdens deze stage aan bod komen zijn verwerkt in het plan van aanpak, evenals nog enkele vragen van de docent over kleine opmerkingen. Er kwam een opmerking over dat er geen communicatie plan in verwerkt was, deze is hierna toegevoegd. Eveneens moest de beginsituatie benoemd worden. Zo ontstond de eerste versie (versie 1.0) van het plan van aanpak. Ter controle is deze naar de docent opgestuurd. Hierna zou nog een update volgen met de conclusies van het onderzoek in het plan van aanpak.

6.2

requirements

Alvorens echt een ontwerp te kunnen maken zullen allereerst de eisen moeten worden vastgelegd. De eisen houden in wat beoogd is te behalen in deze stage. Dit zijn de punten vernoemd in hoofdstuk 3.3. Voor het realiseren hiervan hebben we gekozen om gebruik te maken van Visual Paradigm. Deze tool is ook bruikbaar voor het maken van het ontwerp, en uiteindelijk kunnen deze gekoppeld worden aan de eisen. Zo ontstaat een mooi geheel.

Verder bestonden de requirements uit een los document dat een systeem beschrijving, omschrijvingen van de use cases en de traceability tabel omvatte.

De MoSCoW methode is bij het realiseren van deze requirements toegepast. Deze methode houdt in dat elke eis zijn eigen prioriteit krijgt. De afkorting MoSCoW staat voor:

- Must have - Should have - Could have - Won’t have

Must have zijn de eisen die benodigd zijn om het systeem volledig te laten functioneren. De should haves zijn de eisen die het geheel mooier en uitgebreider maken.

Could haves zijn eisen die misschien meegenomen kunnen worden in het product, maar alleen wanneer er voldoende tijd over is om deze mee te nemen.

De eisen die aan het product gesteld zijn: (must haves)

- Zorg dat een foto te zien is op een lcd scherm in een slideshow. - Maak het geheel configureerbaar via een webserver.

- Realiseer een FTP server die bestanden kan up en downloaden, maken van mappen en verwijderen, bestanden kan verwijderen.

- Realiseer een file systeem die zorg draagt voor het schrijven naar SD kaart. De volgende eisen waren graag gewild in deze foto frame: (should have)

- Het schrijven van de configuratie naar NANDflash - Processor AT91SAM9263 vervangen door AT91SAM54G - Videobeelden afspelen

- Beveiligen http server.

De volgende functionaliteiten zijn gewild wanneer er tijd over is: (could haves) - Geluid realiseren.

- USB functionaliteit realiseren. - Touch screen realiseren

- Verwijderen van foto’s via touchscreen

- Toevoegen en verwijderen van foto’s via de http server.

Door gebruik te maken van deze methode kunnen deze eisen op prioriteit worden gerangschikt om vervolgens de work breakdown structure aan te passen. Zo zullen de must haves bovenaan in de WBS komen. De should en could haves onderaan.

Na het opstellen van alle eisen zijn deze verwerkt in de tool Visual Paradigm, Zo zijn er requirements gerealiseerd in combinatie met use cases. Requirements zijn eisen die aan het product gesteld worden, Use cases beschrijven het gedrag van het product.

Visual Paradigm heeft als voordeel dat deze de traceability automatisch kan genereren. Deze tabel kan vervolgens door de tool worden opgeslagen als word bestand. Deze was vervolgens weer te gebruiken in het requirements document. Dit document is na te lezen in bijlage D: Requirements.

6.3

Ontwerp

Het ontwerp is gerealiseerd nadat de eisen zoals in paragraaf 6.2 beschreven vastgelegd waren. Ook hiervoor is gebruik gemaakt van de tool Visual Paradigm.

In het ontwerp is een klasse diagram gemaakt welke klassen de software gaat bevatten en welke functies deze moeten hebben. Er bestaat een hoofdmodule die de baas is van het systeem. Hij initialiseerd alle functionaliteiten en zorgt ervoor dat er volgens een afspeel algoritme en intervaltijd een slideshow wordt weergegeven op het display. Daarnaast een kleine configuratie module die zorg draagt dat de configuratie opgehaald dan wel bijgewerkt wordt. Eveneens bestaat de mogelijkheid om de standaard configuratie terug te zetten.

De configuratie wordt aangepast wanneer er vanaf de website nieuwe configuratie wordt ingesteld ( bijvoorbeeld intervaltijd veranderd). Wanneer er een timer afloopt in de hoofdmodule zal de hoofdmodule een "get configuration" functie van deze klasse aanroepen die vervolgens de meest recente data opstuurt naar de hoofdmodule.

De systemen die binnen eCos gebruikt worden of gerealiseerd zijn, worden als pakket meegenomen in dit klassen diagram. Het klassendiagram is gemaakt volgens de UML methode.

UML wordt binnen het ontwerpen van software programma’s veel gebruikt om logische verbanden weer te geven tussen verschillende stukken deelsoftware. Eveneens is per deelsoftware beschreven welke functies en variabele deze heeft.

7

Onderzoek

Tijdens deze stage is er onderzoek gedaan naar de verschillende functionaliteiten die beoogd waren te realiseren. Gezien het programmeren van software risico’s met zich meebrengt is besloten hier onderzoek naar te doen en deze eveneens vast te leggen in een risico analyse. Dit houdt in dat er een schatting wordt gemaakt van het moeilijkheid niveau en de geschatte werktijd die benodigd is. Uit alle onderzochte stukken software werd vervolgens een keuze gemaakt welke onderdelen uit de initiële opdracht worden meegenomen en welke niet. Deze conclusie van dit rapport was bindend voor de oplevering. In de onderstaande hoofdstukken die elk verband hebben met 1 onderzocht

onderwerp zal het volgende worden omschreven: - De onderzoeksvraag

- Welke opties waren mogelijk - Welke criteria zijn onderzocht

- Matrix waarin de opties tegen de criteria worden uitgezet - Als laatste de conclusie

7.1

Risico analyse

De software die tijdens dit project geprogrammeerd diende te worden, is in een risico analyse(zie bijlage C: Uitwerking uit de Risico Analyse ) geanalyseerd. Dit is gedaan per onderdeel.

Onderstaand de onderdelen: - FAT file systeem - Graphic User Interface - http server

- FTP server - Ehternet stack - Jffs2 NAND Flash

Bij de meeste bovenstaande onderdelen zijn meerdere mogelijkheden onderzocht die kans boden voor het

functioneren van de applicatie. Deze mogelijkheden zijn verwerkt in de risico analyse( zie bijlage C: Uitwerking uit de risico analyse). Voor het FATfile systeem was de opties vooraf al bekend. Dit omdat deze al geïmplementeerd in eCos aanwezig was.

7.2

FAT File systeem

Het onderzoek naar het FAT file systeem was kort. Dit omdat binnen NBG dit file systeem al gerealiseerd was voor eCos.

De onderzoeksvraag luidde: “Fat file systeem geschikt voor SD kaart”.

Doordat deze al bestond en functioneel was is voor deze optie gekozen en wordt dit filesysteem gebruikt voor deze opdracht.

7.3

Grafische user interface

Gedurende het onderzoek werd geconcludeerd door de stagiaire dat de grafische user interface uit 2 onderdelen ging bestaan. Ten eerste een grafische driver in eCos die het LCD initialiseerd en een framebuffer realiseert. Daarnaast een grafisch softwarepakket dat zorg draagt dat afbeeldingen naar de framebuffer worden geschreven.

De onderzoeksvraag naar de onderliggende driver was hoe deze geïmplementeerd moest worden.

Hierin waren geen opties om uit te kiezen, deze moest zelf geïmplementeerd worden. De stagiair heeft dit gedaan. In tegenstelling tot de onderliggende driver bevatte het grafische software deel meerdere pakketten die de functionaliteit kunnen bieden. Deze waren de volgende :

- NanoX (package binnen eCos) - MiniGUI

- Pixil

- QT

- Qtopia

- PDcurses (package binnen eCos)

Verder diende het software pakket aan de volgende eisen te voldoen - Vrij commercieel te gebruiken.

- Het moet met eCos compatible zijn.

- Het moet bruikbaar zijn voor een embedded omgeving (niet pc gericht). - Het moet een bitmap kunnen tonen op een LCD scherm.

In de onderstaande matrix worden deze eisen uitgezet tegen de pakketten. Vrij commercieel te

gebruiken

eCos Compatible Geschikt voor embedded omgeving Ondersteuning bitmaps

NanoX Ja Ja Ja Ja

MiniGUI Nee Ja Ja Ja

Pixil Nee Nee Nee Ja

QT Ja Nee Nee Ja

Qtopia Ja Nee Ja Ja

PDCurses ja Ja Ja Nee

Concluderend uit het bovenstaande schema en na afweging door van deze punten de stagiaire in samenspraak met de begeleider bleek NanoX het meest overeen te stemmen. NanoX bevat op alle criteria een ”ja”. Eveneens was er een versie van NanoX beschikbaar binnen eCos.

MiniGUI, die na NanoX de meeste kans bood, viel af vanwege de licentiebepalingen.

Dit pakket mocht privé gebruikt worden, echter wanneer er commerciële doeleinden ter spraken kwamen, moest men een licentie kopen voor het gebruik van MiniGUI.

PDCurses bleef lang kandidaat, maar toen bleek dat het pakket geen bitmaps ondersteunde en het uiterlijk had van een DOS omgeving viel ook deze af. Alle overige waren al niet eCos compatible waardoor de pakketten afvielen.

7.4

http server

De http server wordt in dit project gebruikt als een configuratie scherm voor het digitale foto frame. Op het scherm zijn een aantal velden waarmee men variabelen kan aanpassen. De intervaltijd en het afspeelalgoritme van de slideshow zijn aanpasbaar.

De minimum interval tijd zal zijn 2 seconden en de maximale zal 30 seconden bedragen, initieel zal de intervaltijd op 15 seconden zijn vastgelegd.

Het afspeel algoritme zal bestaan uit: bestandsnaam alfabetische volgorde, Datum oplopend en grootte van de bestanden.

De onderzoeksvraag bij de http server was: “zoek een geschikte webserver voor eCos die eveneens data van een webpagina kan lezen”

De volgende keuzes waren mogelijk - HTTPD (bevindt zicht binnen eCos) - ATHTTPD (bevindt zich binnen eCos)

- Webserver binnen het LWIP(LightWeight IP) pakket in eCos

Omdat deze pakketten zich allemaal al binnen eCos bevonden werd het onderzoeksaspect licentievrij niet onderzocht, omdat eCos zelf al licentie vrij te gebruiken is.

De volgende criteria zijn onderzocht - Geschikt voor eCos

- Kan de webserver data lezen uit een webpagina - Werkt met het basic network framework pakket

In de onderstaande tabel zijn de eisen uitgezet tegen de webserver.

Geschikt voor eCos Kan data lezen uit webpagina Werkt met basic networking framework pakket HTTPD ja ja Ja ATHTTPD ja ja Ja Webserver binnen LWIP pakket ja nee nee

Concluderend uit het bovenstaande schema bleven 2 kandidaten over die bij benadering de zelfde functionaliteiten boden. Deze waren dus beide geschikt voor dit project.

De keuze is uiteindelijk gemaakt doordat ATHTTP callbacks naar c functies ondersteunde. Deze functionaliteit kan binnen het project goed gebruikt worden voor onder andere het resetten van het foto lijstje via de website.

7.5

FTP Server

Een van de features van het digitale foto lijstje is gebruik maken van een FTP server om foto’s op het lijstje te zetten en te verwijderen. Dit is bij een standaard foto lijstje niet aanwezig. Door deze feature kunnen foto’s tijdens de slideshow worden toegevoegd aan de afspeellijst. De FTP server zal op zijn beurt gekoppeld zijn aan een SD kaart, alwaar de data bewaard wordt.

De onderzoeksvraag luidde dan ook: “zoek een FTP server die geschikt is voor eCos”. De volgende FTP servers zijn gevonden die kans boden de functionaliteit te vervullen:

- Troll-ftp for eCos - Filezilla

- WZDFTPD

De FTP server diende aan de volgende eisen te voldoen: - Geschikt voor eCos

- Vrij te gebruiken

In het onderstaande schema worden de eisen uitgezet tegen de kandidaat FTP servers.

Geschikt voor eCos Vrij te gebruiken

Troll-ftp for eCos Ja Ja

Filezilla Nee Ja

WZDFTPD Nee ja

Concluderend uit het bovenstaande schema sprong troll-ftpd erg in het vizier. Dit omdat deze versie al geport was naar eCos. Zodoende was het niet nodig om een andere server zelf te porten naar eCos. Eveneens omdat deze server onder een publieke licentie viel was dit voor de keuze een definitieve doorslag. Groot voordeel was dat de server gebruik maakte van het zelfde ethernet stack als de http server.

7.6

Ethernet stack

In de bovenstaande functionaliteiten wordt beschreven dat er een ethernet stack benodigd is voor het laten werken van de functionaliteit. Omdat er in eCos verschillende ethernet stacks zaten die geschikt waren voor dit platform. Diende onderzocht te worden welke in onze situatie geschikt is.

De onderzoeksvraag was: “ zoek na welke ethernet stack benodigd is om de functionaliteit te laten werken”. Hierbij is gebruik gemaakt van de eCos documentatie site.

De volgende kandidaten waren geschikt: - LWIP

- Basic Networking framework De volgende eisen werden gesteld.

- Werkt samen met FTP Server - Werkt samen met http server

In het onderstaande schema zijn de eisen tegen de kandidaten uitgezet

Werkt samen met FTP server Werkt samen met http Server

LWIP Nee Nee

Basic networking framework Ja Ja

7.7

JFFS2 NANDflash

JFFS2 NAND flash staat voor Journalling flash file system versie 2, en hiermee kan een NAND flash geheugen geprogrammeerd worden. Voor deze opdracht werd dit gekozen om de configuratiefile op te slaan en te borgen. Zodoende kan de configuratie niet door een gebruiker van het fotoframe handmatig worden overschreven. Het onderzoek door de stagiair hiernaar wees uit dat er voor NAND flash programmeren met behulp van dit filesysteem een nog te ontwikkelen basis aanwezig was, met een grote kans dat deze nog niet werkt. De platform gerelateerde drivers waren nog niet geprogrammeerd. Doordat er nog niet veel kennis is op het gebied van jffs2 door de stagiaire en deze functionaliteit niet meer in de planning paste nadat deze op de geschatte tijd gebaseerd was, is dit onderdeel niet in het eindproduct meegenomen.

7.8

conclusies uit het onderzoek

Voor de definitieve oplevering aan het einde van de stageperiode waren de beloften die uit deze onderzoeken zijn gedaan bindend. Het volgende kan worden geconcludeerd uit de hier bovenstaande hoofdstukken.

- Voor het schrijven en lezen naar SD kaart wordt gebruik gemaakt van een FAT file systeem die reeds aanwezig is in eCos.

- De grafische user interface zal bestaan uit een zelf te programmeren driver, en een grafisch softwarepakket. Dit pakket is vastgesteld op NanoX.

- De http server die gebruikt zal gaan worden voor het configureren van het digitale foto lijstje is ATHTTP geworden wat staat voor Another Tiny http Server.

- Als ftp server zal troll-ftpd gekozen worden omdat deze al geport is naar eCos en van dezelfde ethernet stack gebruikt maakt als de http server.

- De ethernet stack “Basic networking framework” zal worden gekozen omdat functionaliteiten als ftp en http server hiervan gebruik maken

- Als laatste zal het JFFS2 file systeem buiten deze opdracht vallen. Dit vanwege de tijdsplanning waarin deze functie niet past.

8

Implementatie

Het hoofddoel van de stage opdracht was het implementeren van de verschillende losse onderdelen en hier een logisch samenhangend geheel mee realiseren, met als eindproduct een Digital Photo Frame. Dit hoofdstuk omschrijft per onderdeel welke stappen gemaakt zijn tijdens de implementatie (onder andere keuzes) en daarnaast in woorden omschreven hoe het geheel samenhangt.

8.1

Deelsoftware

Voordat er begonnen kon worden aan het maken van de hoofdapplicatie, is gekozen voor het realiseren van kleine testprojecten waarin de functionaliteiten bewezen worden. Zo worden de stukken software klein en behapbaar gemaakt alvorens het geheel samen te voegen tot 1 groot product. Voor elk onderzocht onderdeel is een deelproject gerealiseerd met als einddoel het hoofdproject.

 Bij de aanvang van de stage is een afspraak gemaakt dat alle drivers die in eCos geprogrammeerd worden, in de taal C worden geprogrammeerd.

 De testprojecten die gebruik maken van de drivers zijn in C++ geprogrammeerd. Zo zijn er de volgende testprojecten:

- een test project voor het FAT file systeem die iets op de sd kaart kan lezen en schrijven, - een test project die naar het framebuffer kan schrijven,

- een test project die een ftp server instantieert,

- een test project die de grafische software pakket demonstreert ( NanoX)

- een test project wat een http server opzet, waar vervolgens op een website gegevens kunnen worden ingetoetst en deze worden uitgelezen door de software.

8.2

FAT file systeem

Om kennis te maken met eCos en de programmeerwijze van NBG is begonnen met het werken aan de al

geïmplementeerde FAT file systeem. Dit omdat deze al deels werkte en daardoor als opstap diende voor het echte programmeer werk.

Het FAT file systeem wordt gebruikt om data naar een SD kaart te schrijven of uit te lezen. Tijdens testen van de demo applicatie door de stagiaire bleek dat er iets niet klopte binnen de driver. Een collega die als laatste aan deze driver gewerkt had, bleek een foutje te hebben gemaakt in een while loop waardoor er geen data gelezen werd. Deze fout had hijzelf herzien en opgelost. Hierna kon het fat file systeem gebruikt worden.

In deze driver stonden nog enkele puntjes open die nog geprogrammeerd dienden te worden. Een van de punten was fout afhandeling, Zo kon er bijvoorbeeld gelezen worden als een file nog niet bestond. Dit resulteerde in een systeem crash. Hiernaast was het unmounten van de SD kaart niet vlekkeloos afgevangen en werd uitgegaan dat dit slaagde. Hier is vervolgens een controle lus over geprogrammeerd zodat bekend is of de kaart geunmount is of niet.

Hiernaast zijn nog enkele inconsistente naamgeving vervangen door consistente naamgeving zoals de bus waaraan de SD kaart aangesloten is. Dat is in ons geval bus 1. De programmacode bevatte bus0.

Het merendeel van deze code was al geprogrammeerd binnen het bedrijf waardoor de stagiaire enkel nog kleine aanpassingen aan de broncode heeft moeten doen.

8.3

Ethernet stack

Vele onderdelen van het digitale foto frame zijn afhankelijk van de ethernet stack. Hiervoor was het belangrijk dat deze moest functioneren. Met het uittesten van de FTP server bleek dat het netwerk niet online kwam, waardoor er geen verbinding mogelijk was tussen het target board en een PC dan wel laptop. Voor de werking van de FTP server en http server was deze stack noodzakelijk.

Al vrij snel kon de conclusie getrokken worden door de stagiaire dat dhcp functionaliteit binnen eCos nog niet functioneel was, De bedoeling van DHCP is dat een server IP adressen uitdeelt aan verschillende clients die zich hiervoor aanmelden. Dit doen ze door een netwerkpakket te versturen (DHCP Discover). Elke pc in het netwerk krijgt deze discover te zien. Enkel DCHP servers zullen reageren op dit bericht en de desbetreffende pc een uniek IP adres geven. Echter omdat de DHCP server niet reageerde op dit pakket gaf deze geen IP adressen uit, dus zodoende was er geen netwerk mogelijkheid. Als tijdelijke oplossing werd gekozen om het target statisch te configureren waardoor het in elk geval mogelijk was om een verbinding te maken met een PC dan wel laptop.

Vanwege de planning en het verwachte werk bij het grafische user interface, is dit probleem verschoven naar een later tijdstip. Deze planning zit in Bijlage A: plan van aanpak.

8.4

Graphical User Interface

Dit onderdeel geeft afbeeldingen weer op het display, Het bestaat zoals vooraf genoemd uit 2 delen, het framebuffer en de grafische software pakket die hiermee praat. Dit hoofdstuk omschrijft de implementatie hiervan en de

voorgekomen problemen.

8.4.1 implementatie framebuffer

Omdat het grafische gedeelte in dit project als een van de risicovolste werd gezien, is gekozen om deze als eerste te implementeren. Daaronder behoorde het grafische softwarepakket Nano-X en het framebuffer. Deze laatste wordt in dit hoofdstuk beschreven.

Dit nog niet bestaande onderdeel diende door de stagiair zelf gerealiseerd te worden. Het framebuffer is een buffer die de inhoud voor het weer te geven afbeelding bevat.

Afbeelding 6: plek van het framebuffer

De moeilijkheidheid in het programmeren van deze driver was dat er geen ervaring was bij de stagiaire met het programmeren van drivers voor eCos. Hierdoor moest eerst na worden gezocht wat er geïmplementeerd diende te worden in het framebuffer, en vervolgens hoe deze geïntegreerd moest worden in eCos.

De driver diende aan de volgende zaken te voldoen:

- Initialiseren van het LCD scherm. Dit werd gedaan door de volgende registers te schrijven:  contrastwaarden,

 controleregisters,  timing waarden,

 configureren van een DMA module ( dat staat voor een Direct Memory Acces)  pin configuratie.

- Aan en uitschakelen van de DMA en LCD power.

- Het bekend maken naar de buitenwereld hoe deze driver heet. - Initialisatie functie die door eCos automatisch aangeroepen word.

Om te realiseren dat alle registers juist geschreven werden, is gebruik gemaakt van een testproject van de Atmel website. Hierin werden de registers geschreven en kon dit bijna 1 op 1 worden overgenomen. Voor verdere referentie over de registers van de LCD module, zie bron 10: datasheet Atmel hoofdstuk 44.

Echter ontstond er een probleem, de stagiaire ondervond tijdens een test dat de waarden uit het register wel gelezen konden worden, maar niet geschreven. Dit had de volgende oorzaak.

Doordat eCos gebruik maakt van een MMU tabel (MMU staat voor Memory Management Unit) werden de waarden niet in het register geschreven omdat deze registers nog niet als overschrijfbaar waren gezet in de MMU tabel. De Memory management unit (of kortweg MMU) is een hardwarecomponent die gebruikt wordt voor de runtime -mapping van virtuele naar fysieke geheugenadressen. Daarnaast zorgt het voor geheugenbescherming. In de onderstaande figuur staat schematisch de werking van een MMU weergegeven

Figuur7: MMU

De CPU geeft een logisch adres door aan de MMU waar iets gewijzigd dient te worden. De MMU zal aan de Translation look-aside buffer vragen welk fysiek adres hier bij hoort en of dit adres geschreven mag worden of niet.

Wanneer er geschreven mag worden zal de waarde die door de cpu naar het logische adres geschreven is worden gekopieerd naar het fysieke adres. Zo wordt voorkomen dat op plaatsen waar niet geschreven mag worden toch per ongeluk geschreven wordt. Wanneer het geheugen niet geschreven mag worden zal vervolgens ook geen wijziging plaatsvinden.

Het stuk translation look-aside buffer wordt in eCos opgelost door de tabel.

Doordat niet in alle registers zomaar geschreven mag worden staan de registers standaard op alleen lezen. Door de bereiken te schrijven in deze tabel welke geheugenbereik wel geschreven mogen worden, zullen deze door de MMU op overschrijfbaar worden gezet.

Na vervolgens het bereik van de registers van de LCD Controller werd het lcd scherm geïnitialiseerd en kon het buffer geïmplementeerd worden. Deze ziet er als volgt uit:

Het buffer is een 8bits array met de grootte van de lengte maal de hoogte maal het aantal kleuren (bits per pixel gedeeld door 8). (240*320*(24/8) )= 230400 plaatsen). Om een pixel te vullen zijn 3 plaatsen in het array nodig. Een voor rood, een voor groen en een voor blauw. Plek 0, 1 en 2 staan voor de pixel links bovenaan het scherm.

Figuur 6: Schematische weergave framebuffer

In het bovenstaande figuur staat het schematisch getekend. Elk kleine blokje staat voor één 8bits plek in het array. De buffer bevat per horizontale lijn 240*3 plaatsen(in totaal dus 720 plaatsen per horizontale lijn).

Op plek 720 in het array begint de nieuwe horizontale lijn op het scherm. Op deze manier wordt het scherm gevuld. Nadat dit buffer gerealiseerd was werd onderzocht hoe deze driver in eCos aangemeld moest worden. Op de site van eCos staat een artikel over hoe een framebuffer voor een nieuw target device gerealiseerd diende te worden. (zie bron 7). In eCos was al een hardware specifieke code aanwezig die mogelijk als voorbeeld kon dienen voor het realiseren van de driver, dit was echter voor een synthetisch target die gebaseerd is op een PC omgeving, waardoor deze niet meteen als voorbeeld kon worden gebruikt om het framebuffer te implementeren. Het voorbeeld kon niet gebruikt worden omdat een embedded omgeving anders is dan een pc omgeving.

Op internet is gezocht naar een project dat een dergelijk framebuffer heeft moeten implementeren. Na een zoektocht werden source files gevonden van een project die voor een blackfin target een framebuffer hadden geschreven. Deze kon als voorbeeld gebruikt worden.

ECos bood voorgedefinieerde primitieve functies zoals: - het tekenen van lijnen.

- het tekenen van vlakken. - het tekenen van pixels. - het uitlezen van pixels.

Binnen eCos bestonden echter geen 24bits functies die wel benodigd waren voor het vullen van deze buffer. Deze dienden eveneens zelf gerealiseerd te worden. Om aan de eCos stijl vast te houden zijn de zelfde voorgeschreven parameters gebruikt voor de functies. (zie bron 7).

De generieke driver in eCos was wel in staat om een 24bits kleur te creëren. De kleur was opgebouwd uit 8 bits rood, 8bits groen en 8 bits blauw. De 24 bits kleur kon worden ontleden door te “bit shiften” (term voor het schuiven van bits), Zo kon per pixel kleur de waarde worden overgenomen in het array. In het volgende voorbeeld is de kleur wit gekozen. (de waarden 255 voor rood, de waarde 255 voor groen en de waarde 255 voor blauw). Door deze manier werd voldaan aan de stijl van eCos.

Figuur 8: Kleur omzetten naar waarden in het framebuffer

Tijdens implementeren van de driver bleek dat de driver te vroeg geïnitialiseerd werd. Er ontstond een blauwe achtergrond in plaats van een zwarte achtergrond die beoogd was. Dit had te maken met een initialisatie prioriteit voor het construeren van deze driver. Omdat de MMU die de registers op overschrijfbaar zet, achteraan in de opstartlijst word geconstrueerd, moest de prioriteit van het framebuffer worden aangepast zodat deze later dan de MMU geconstrueerd werd.

Na deze stap was het framebuffer al “aardig” op weg. In het testproject konden al vlakken en lijnen getekend worden evenals individuele pixels. Er zat echter een afwijking in het beeld. Volgens een regelmatig patroon zat er een

verkeerde kleur in het beeld. Na onderzoek door de stagiaire bleek dat dit te maken had met de burstlength. Burst wil zeggen dat de data in het DMA(direct memory acces) geheugen naar het lcd geschreven wordt. De burstlengt is de lengte van zon blok. Deze stond op een verkeerde waarde. Zodoende de afwijking. Nadat deze bug gerepareerd was, leek het framebuffer voor dit project voltooid.

Hierna is het framebuffer getest op alle functionaliteiten die deze bood. Dat waren: - Initialisatie

- Tekenen van pixels

- Tekenen van lijnen in verschillende lengten - Tekenen van blokken in verschillende lengten - Lezen van een pixel

Hieruit bleek dat in het tekenen van de lijnen nog een foutje zat. In de lus waarin geteld werd hoelang de lijn moest zijn, werd geteld tot en met de lengte. Het ging goed zolang op punt 0 werd begonnen met tekenen. Wanneer er een offset gebruikt werd, werd er maar getekend tot aan de lengte van de lijn in plaats van de offset + de lengte van de lijn. Dit werd al snel gerepareerd door de stagiaire door in de lus te tellen tot de offset+ de lengte van de lijn.

Het framebuffer realiseren was een grote brok werk, met veel nazoekwerk in datasheet van Atmel. Echter dit stuk is volledig gelukt en kan gebruikt worden in het eindproduct. Deze driver is door de stagiaire geschreven.

8.4.2 Nano-X

Binnen het eCos pakket was een versie van nano-X ( vroeger Microwindows) aanwezig. Deze versie was echter eerder in eCos geïntegreerd voordat het framebuffer die nu gebruikt wordt voor het LCD gerealiseerd was. Hierdoor werden in deze versie niet de functies van het framebuffer gebruikt, maar van functies die bedoeld waren voor een Ipaq. Op internet is vervolgens onderzoek gedaan naar een meer recentere versie en werd ook gevonden. Deze versie ondersteunt wel het eCos framebuffer. http://www.zylin.com/efgit.tar.bz2

De werking van nano-X werkt als volgt ( schematisch weergegeven in de onderstaande afbeelding).

Figuur 9: NanoX schematisch getekend

Binnen het blok NanoX bevind zich de functionaliteit die zorg draagt dat de afbeelding op de juiste manier in het gerealiseerde framebuffer wordt gezet.

In het testproject kwamen meteen een aantal problemen tegen het licht. Zo moest in het stuk software waarin het framebuffer van eCos werd aangesproken nog enkele veranderingen worden doorgevoerd zodat dit gebruik ging maken van de functies die in de generieke framebuffer aanwezig zijn in plaats van hardware specifieke functies. Dit is mogelijk omdat er in de generieke framebuffer onderhuids zorg voor wordt gedragen dat die functies de hardware specifieke framebuffer aanroept.

Hierna bleek ook dat ten opzichte van de oude versie, de versie ook een beveiliging aan boord had. De processen worden gesynchroniseerd zodat ze niet tegelijkertijd op dezelfde plek kunnen schrijven en lezen. De realisatie hiervan wordt verzorgd door een mutex. Deze kan maar door 1 proces geblokkeerd worden en daarna weer vrijgegeven. Echter werd deze mutex op een andere plek geïnitialiseerd. Doordat deze functie niet in de broncode zat, moest deze worden toegevoegd. Hiervoor is diep in de broncode gezocht. Na het aanroepen van die functie werd de mutex geïnitialiseerd en kon verder worden gewerkt aan het werkend krijgen van NanoX.

Zo was in een andere source file ook dezelfde foutmelding waardoor deze ook aangepast moest worden dat dezelfde functie als voorgaand werd aangeroepen. Na deze reparaties kon de sourcefile bouwen en de functionaliteit worden getest.

Omdat NanoX gebruik maakt van een client server model, kon de client gedeelte die geïmplementeerd was in het testproject niet communiceren met de grafische server. Deze server is nodig omdat deze de vertaalslag verzorgd van

Omdat in overleg met de stagebegeleider vanuit NBG besloten werd dat het integreren van de FTP server meer waarde had voor de eindopdracht en er een terugval punt is voor het tonen van bitmaps, zal nano-X in een later stadium gedurende deze stage worden gerealiseerd.

8.5

FTP server

De FTP server is gelijktijdig met het onderzoek getest op functionaliteit. De source files werden gedownload en vervolgens in een eCos project gezet. (bron 5) Er bestond al een eCos ftp client, echter kon deze niet gebruikt worden omdat voor deze opdracht een server benodigd was.

Dit project is vervolgens zodanig aangepast dat de gedownloade server hierin aangeroepen werd en geïnstantieerd. De oude cliënt code werd uit het project gehaald, en de nieuwe server code werd toegevoegd.

Daarna zou in het project alleen de server nog maar aangeroepen te worden zodat deze zich instantieerde tijdens het opstarten van eCos.

De FTP server instantieerde en kon met gebruikersnaam en wachtwoord worden ingelogd. Maar er zat nog geen file systeem aan gekoppeld die de files vervolgens op kon slaan naar een SD kaart. Dit FAT filesysteem werd hierna gekoppeld aan de FTP server door de stagiaire door de naam van het gemounte SD kaart mee te geven als root directory voor de server.

Tijdens deze koppeling kwamen er een aantal problemen om de hoek kijken. Allereerst was het wel mogelijk om bestanden te downloaden van de SD kaart, maar uploaden ging verkeerd. Later wordt dit probleem uitgelegd. Allereerst was de inhoud van de sd kaart niet zichtbaar. Deze fout moest nader onderzocht worden.

Na een tijd bleek dat de verkeerde mount naam werd gebruikt in plaats van de naam van het gemounte SD kaart (“/mci”), werd (“/”) gebruikt.

Nadat deze fout verholpen was door de stagiaire leek aanvankelijk het uploaden te werken met kleine bestanden. Wanneer de inhoud van de SD kaart werd bekeken, bleek dat het bestand niet ge upload was. Op een andere client kon echter wel het bestand worden gedownload. Nadat door de stagiaire aan een collega gevraagd werd of er een stuk geheugen tussen de SD kaart en de daarbij behorende file systeem zat, bleek dit waar te zijn. Op dit stuk geheugen werd tijdelijk het bestand opgeslagen. Door in de code een zogeheten “cache flush” aan te roepen die er voor zorgde dat het bestand vanaf het stuk geheugen fysiek op de SD kaart werd geschreven, was het bestand zichtbaar op de SD kaart.

Het volgende probleem was dat bestanden bij overschrijding van een grootte van een paar kilobyte er voor zorgde dat het programma crashte (Het systeem loopt vast ). Om dit probleem nader te verklaren zal eerst de werking van het versturen van bestanden worden beschreven.

Wanneer de client een overdracht wil starten naar de server toe zal deze eerst een verzoek sturen naar de server. Dit verzoek gaat via de controle socket. De server realiseert een data socket waarnaar hij luistert wanneer het maximum aantal gebruikers niet overschreven is, daarna zal hij de verbinding accepteren en een acknolage sturen naar de client. De data socket is nu compleet.

De client stuurt nu zijn eerste pakket met ftp data over naar de server via de data socket verbinding. De server leest de ontvangen data en zet deze in een buffer en geeft een acknolage terug dat het pakket ontvangen is. Dit buffer wordt vervolgens geschreven naar de SD kaart.

Allereerst werd aangenomen door de stagiaire dat de systeemcrash te maken had met de buffer tussen de data socket en het file systeem. Door in de broncode de grootte aan te passen van deze buffer kon worden uitgesloten dat deze buffer ervoor zorgde dat het systeem crashte.

Door gebruik te maken van Wireshark, dit is een programma waarmee alle netwerkacties kunnen worden gelezen, werd gekeken wat er precies gebeurde op het moment dat er een bestand van de client naar de server verstuurd werd. Hierin werd een probleem ontdekt.

Een data pakket bevat 1460 bytes maximum. En na elk pakket dat door de server ontvangen is zal deze een acknolage sturen naar de client. Echter pas na 4 of 5 verzonden pakketten kwam de acknolage van het eerste pakket pas terug. De conclusie kon worden getrokken dat de data veel te snel verstuurd werd door de client. Daardoor moest de client met een gelimiteerde snelheid data versturen naar de server.

Vervolgens werd een test uitgevoerd met een snelheidsbeperking en deze slaagde.

Echter binnen het FTP protocol bevindt zich geen afspraak die tegen een client aangeeft met hoeveel snelheid deze mag zenden. Dit is enkel een instelling die gezet is op de client kant.

Voor de werking van het systeem is dit een work around, echter zal de bug die zorgt voor de crash nog worden opgelost. In de ethernet stack van eCos bevind zich een buffer van 128 plaatsen. Dit is niet erg groot waardoor er veelvuldig gelezen en geschreven moet worden. Wanneer er te veel data wordt ontvangen kan het buffer overlopen waardoor een systeem crash kan optreden. Op het moment van schrijven is dit onderdeel nog in behandeling.

De FTP server bevat nu alle functionaliteit die gewenst was voor deze opdracht en daarmee kan de FTP server worden gebruikt in de eindopdracht.

8.6

http server

Als een van de laatste onderdelen werd een start gemaakt met het demo project voor de http server. De reden dat deze later bekeken is, was omdat deze functionaliteit de laagste prioriteit had. Ook zonder aanpasbare variabelen zoals intervaltijd en afspeel algoritme kan het foto frame uitstekend werken.

De keuze was gevallen op ATHTTP server, een kleine webserver met een aantal zeer bruikbare functies voor ons, zoals het aanroepen van een C- code functie (de programmeertaal waarin in deze stage deels gewerkt wordt), en het opvragen van form variabele.

Het doel is om op een form ( zichtbare interface die daadwerkelijk op het scherm te zien is) de instelbare variabelen neer te zetten. De server bevat een tabel waarin de programmeur het form veld kan koppelen aan een interne variabele in de source code. Met de functie “find variable from form” kan een unieke variabele in deze tabel, die gekoppeld is aan een unieke form variabele, worden uitgelezen door de unieke naam in de tabel in deze functie mee te geven, en kan die variabele in het programma gebruikt worden.

Figuur 11: Werking http server schematisch weergegeven.

Via de broncode is in de lookup table een record aangemaakt. Dit record bevat een unieke naam in de tabel, een unieke form variabele die overeenstemt met de form variabele op de website, een buffer waarin de data kan worden opgeslagen, en als laatste de lengte hiervan .

De website bevind zich op de SD kaart. Daarin staat een index.htm die de hoofdpagina bevat. Vervolgens zijn er nog enkele .htm forms gemaakt die verschillende functionaliteiten hebben. Dat zijn de volgende:

- Configuratie form.

- FTP Password change form. - Reset form.

- Een about form met informatie over de DPF.

Daarnaast is het mogelijk om via de webserver de inhoud van de FTP server te bekijken.

Wanneer de server gestart wordt zal worden gekeken of er op de SD kaart een bestand bestaat die index.htm heet. Bestaat deze, dan wordt deze weergegeven, anders zal de inhoud van de SD kaart weergegeven worden.

Op de volgende manier wordt het lezen van een form variabele door de http server gerealiseerd

- Er wordt via de broncode een record toegevoegd aan de lookup tabel volgens de voorgeschreven methode. - Op de website wordt in HTML code een form gerealiseerd die een inputveld met een unieke naam bevat, en

een knop met een HTML “get” actie.

- Wanneer die “get” actie wordt uitgevoerd zal de webserver de form doorzoeken of de form variabele overeenkomen met de variabelen in de lookup tabel. Zo ja, dan wordt de waarde die het inputveld bevat naar de bijbehorende buffer geschreven.

- Via een functie kan vervolgens in de broncode deze tabel worden doorzocht en de waarde worden gebruikt die in de buffer geschreven is. Het buffer is altijd van het char* type.

De waarde die in de buffer is geschreven kan vervolgens in het programma worden gebruikt bijvoorbeeld om de interval tijd aan te passen.

De mogelijkheid om callbacks naar C functies te realiseren is meegenomen in deze opdracht.

Om via de website de digitale fotolijstje te resetten is een form aangemaakt die een knop bevat. Wanneer deze knop ingedrukt wordt zal de fotolijst na een bevestiging worden gereset.

Eveneens het aanpassen van de FTP server wachtwoord geschied via een callback functie. De realisatie hiervan is bijna hetzelfde als de realisatie van het lezen van een form variabele.

Via een andere lookup tabel wordt door de http server vergeleken of een unieke form variabele gevonden wordt tijdens een “get” actie.

Wanneer dit het geval is, zal de bijbehorende C functie worden uitgevoerd. Deze C functie is eveneens voorgeschreven hoe deze gebruikt dient te worden. Hierna is door de stagiair binnen de functie een methode gerealiseerd die de parameters hersteld naar de oude waarde en het wachtwoord van de ftp server terugzet op het initiële wachtwoord. Door deze http server is het mogelijk de beoogde functionaliteiten uit te voeren en dit is ook gerealiseerd.