haa, bedankt surge_me!
Ik heb inmiddels ook mijn Sharp PSP LCD voor €13 thuis. Ik wilde deze aan de onderkant van mijn Altera DE2 bord plaatsen. Nu zie ik dat ik er een adaptertje voor nodig heb. Waar kan ik deze kopen, of kan ik deze zelf maken?
foto:
Alvast bedankt,
Gr. Rik
Jeroen Boere
IF you can't convince them, then confuse them!
Op 7 december 2007 21:59:06 schreef Rikkepic:
haa, bedankt surge_me!Ik heb inmiddels ook mijn Sharp PSP LCD voor €13 thuis. Ik wilde deze aan de onderkant van mijn Altera DE2 bord plaatsen. Nu zie ik dat ik er een adaptertje voor nodig heb. Waar kan ik deze kopen, of kan ik deze zelf maken?
foto:
[afbeelding]lvast bedankt,
Gr. Rik
Try Xantus.
Wellicht als hij kan en wilt reageren heb je grote kans dat hij nog een PCB heeft liggen.
Maar eigenlijk hoort deze vraag hier NIET thuis he.
maak ff een nieuw topic aan AUB!
@Rikkepic
hehe mooie foto, vooral dat reflectie dat van de plexiglas afkomt, doet me denken aan een lensflare effect om een plaatje op te leuke 
. Hoe kom je aan een psp scherm voor 13 euro? Ik wil er ook een
Voor dat PSP LCDtje heb je de juiste connectors en wat spanningsregelaars nodig (2,5V en backlight iets van 27V dacht ik). Xantus had er een SK van maar of hij nog te bereiken valt en er nog over heeft weet ik niet. The12b (van CO) had ook een printje gemaakt en heeft er misschien nog wel wat over, maar geen complete set onderdelen meer.
Ontopic:
Heeft er iemand eigenlijk een beetje ervaring met softcores? Heb het hier nog niet veel voorbij zien komen en het lijkt me wel interessant er iets mee te doen. Voor het Chameleon project zit ik bijvoorbeeld te twijfelen of ik er nog een losse AVR naast doe of dat ik alles in de FPGA oplos. Sommige dingen lenen zich gewoon erg goed voor software (zoals I2C commando's sturen). Eigenlijk wil ik gewoon zoiets als een AVR in de FPGA hebben.
Van wat ik begreep heb je voor de Nios een licentie nodig, die je dan wel weer krijgt als je een Nios ontwikkelkit koopt, maar dat was ik niet van plan. Ook is het volgens mij een vrij groot ding qua LE's. Ik wil eigenlijk een E2C5 of E2C8 voor het project gebruiken, als die dan helemaal vol zit met een softcore is dat ook weer te veel, er moet namelijk nog andere logica bij ook. Een grotere FPGA nemen heeft dan ook weinig zin, voor een paar euro heb je een AVR.
Op opencores zijn veel softcores te vinden (ook een AVR) maar ik zou niet weten welke er een beetje betrouwbaar zijn. Ik heb ook weinig zin om een of ander prutsprojectje van iemand te gebruiken en vervolgens tegen allerlei obscure bugs aan te lopen. Ook zijn veel van die projecten compleet niet gedocumenteerd wat het helemaal lastig maakt om er iets zinnigs mee te doen. Misschien dat hier toevallig iemand een van de opencores projecten gebruikt heeft?
Daarnaast is een lastig punt dat FPGA's geen flash geheugen hebben en RAM vrij kostbaar is. Bij een losse microcontroller krijg je zo tientallen KBs flash en enkele KBs RAM, in de FPGA moet je daar je RAM weer voor gebruiken. Aan de andere kant kost een extern flash chipje je ook de kop niet, maar het makkelijkst is alles in een natuurlijk.
stecj366
Sonar is meer dan Ping...
De nios valt nogal mee van LE's. Het hangt er allemaal van af wat je ermee wil doen. Wat ik begrepen heb van je Chameleon is dat de processor slechts data moet shuffelen, en geen berekeningen. Dan kom je toe met een kleinere nios (er zijn 3 varianten). De kleinste zijn een paar 100, de grootste 1800. Als je geheugen wil zal je dat er extern moeten aanhangen.
Ik zou voor een externe AVR gaan, omdat je zowiezo met twee chips gaat zitten (FPGA + RAM of FPGA + AVR). Dan lijkt een FPGA +AVR de betere keuze...
In het prototype zit een CPLD die de datastroom verkleint, en doet de AVR het rekenwerk maar in de nieuwe versie moet de FPGA een soort DSP achtige functie gaan krijgen en zelf de berekeningen doen (dit is dus niet iets wat de microcontroller zou moeten doen). De AVR zou dan nodig zijn voor dingen als I2C communicatie, de serieel (USB-UART) interface, soft/hardware instellingen e.d. Vrij eenvoudige taken dus.
Dat valt inderdaad mee van de Nios, klinkt goed. Maar moet ik daar nou wel een licentie voor aanschaffen of is dat zonder ook te doen?
Geheugen is waarschijnlijk niet zo'n probleem, RAM heb ik niet veel nodig voor de microcontroller. En veel flashgeheugen (wat lastiger is in een FPGA) ook niet gezien het programma waarschijnlijk niet zo groot is. Dus een microcontroller in de FPGA zou wel een mooie oplossing zijn in dit geval. Elke kostenbespraring is ook weer meegenomen.
Op 8 december 2007 12:55:09 schreef madwizard:
Elke kostenbespraring is ook weer meegenomen.
Bij ons op de universiteit gebruiken ze ook een AVR softcore, hij heeft een whishbone interface dus het zou mij niets verbazen als die van opencores is.
Heb je ook al gekeken naar wat elektuur ooit had gedaan?
In hun FPGA bordje hadden ze een 8051 softcore gebruikt (van opencores) en daar met de whishbone interface een usb core aan geknoopt, werkte geloof ik wel goed:
Te downloaden van :
http://www.elektor.nl/artikelen-als-pdf/2007/januari/fpga-cursus-(8).5…
succes!
edit.. ik zie net dat dat ding 6,266 LE in neemt, dat gaat dus niet passen op de goedkoopste, je kunt wel eentje nemen die een slag duurder is, daar zal het net op passen maar wel krapjes dan hoor, als je ook nog je eigen code moet toe voegen
[Bericht gewijzigd door surge_me op (16%)]
Waarvoor heb je flashgeheugen nodig? Voor de fpga config kan je gewoon een SPI flash chip gebruiken, deze is vele malen goedkoper dan een altera config chip. Zoek maar op ST M25 als ik me niet vergis. Verder kan flash geheugen heel goedkoop zijn, SD kaartjes kosten geen ruk mee.
Zelf heb ik op mijn fpga bordje 32MB SDRAM erop gezet, kostte toen ~8 dollar. Ik weet nog niet of het werkt, nog geen tijd gehad om te testen 
.
Wat betreft de NIOS softcore, deze kan je gratis evalueren. Dan kan je alvast kostenloos de NIOS uit proberen. Je zit dan wel vast aan een tijd limiet van een uur, of je moet je fpga altijd aan de PC hangen.
stecj366
Sonar is meer dan Ping...
Op 8 december 2007 14:30:37 schreef miniK0bo:
Wat betreft de NIOS softcore, deze kan je gratis evalueren. Dan kan je alvast kostenloos de NIOS uit proberen. Je zit dan wel vast aan een tijd limiet van een uur, of je moet je fpga altijd aan de PC hangen.
Als je geen licentie aanschaft draait de NIOS een uur EN hij moet altijd aan de pc hangen. Als je hem eraf haalt stopt hij met werken.
Als je een dev kit koopt heb je een licentie. Die laat dan toe onbeperkt NIOS te gebruiken en projecten mee te maken. Die draaien altijd en moeten nergens aan hangen.
Op 8 december 2007 13:15:45 schreef surge_me:
Bij ons op de universiteit gebruiken ze ook een AVR softcore, hij heeft een whishbone interface dus het zou mij niets verbazen als die van opencores is.
Er staat er inderdaad een op opencores, maar dat is alleen code en verder geen beschrijvingen. Het is ook VHDL , wat op zich niet erg is maar is lastiger te lezen voor mij, en er zitten wat Xilinx specifieke dingen in.
Heb je ook al gekeken naar wat elektuur ooit had gedaan?
[...]
edit.. ik zie net dat dat ding 6,266 LE in neemt, dat gaat dus niet passen op de goedkoopste, je kunt wel eentje nemen die een slag duurder is, daar zal het net op passen maar wel krapjes dan hoor, als je ook nog je eigen code moet toe voegen
Dat is wel groot inderdaad voor iets wat niet het belangrijkste deel in de FPGA vormt. Verschil tussen EP2C5 en EP2C8 is ook al bijna 5 euro, daar kan je een aardige AVR voor kopen.
Op 8 december 2007 14:30:37 schreef miniK0bo:
Waarvoor heb je flashgeheugen nodig? Voor de fpga config kan je gewoon een SPI flash chip gebruiken, deze is vele malen goedkoper dan een altera config chip.
Ik bedoelde meer flashgeheugen om het programma voor de microcontroller in op te slaan, zoals de AVR dat heeft. ROM eigenlijk dus. Je kunt natuurlijk RAM daarvoor gebruiken maar dat is best zonde. Een ATmega32 van een paar euro heeft bijvoorbeeld 32KB flash om het programma in op te slaan. In een FPGA kost je dat allemaal RAM, of je moet er een extern flashgeheugen aan hangen. Maar dat wordt waarschijnlijk weer een parallel flash geheugen als je binnen 1 klok cycle een instructie wilt fetchen, dus groot IC, veel pinnen, meer ruimte.
Zoek maar op ST M25 als ik me niet vergis.
Hier had ik ook (los van dit onderwerp) even naar gekeken inderdaad omdat ik die Altera ROMs altijd al duur vond voor wat het is. Maar digikey lijkt die M25 serie allemaal non-stock te hebben en die ze wel hebben staat bij dat het de laatste vooraad is ("Part will become a non-stocking item when stock is depleted;"). Gaat die serie eruit ofzo?
Wat betreft de NIOS softcore, deze kan je gratis evalueren. Dan kan je alvast kostenloos de NIOS uit proberen. Je zit dan wel vast aan een tijd limiet van een uur, of je moet je fpga altijd aan de PC hangen.
Dat kan ik sowieso eens proberen, maar voor het einddoel heb ik dan niets aan de Nios, ik heb weinig zin een $400 devkit te kopen voor een licentie.
Ik begrijp eigenlijk niet goed de manier van werken. Je stelt dat je graag een microcontroller zou willen in je FPGA voor de eenvoudige taken. Maar doorgaans nemen die microcontrollers vrij veel LE's inbeslag terwijl je slechts 1 maal een eigen ontwerpje voor die serieele dingen hoeft te maken en die gaan slechts enkele tientallen LE's vergen.
Ik heb toch het vermoeden dat men veel te snel naar een softcore oplossing wil gaan ten koste ven heel veel LE's.
Ik vermoed dat je I2C vooral te maken heeft met configuratie van een externe chip. Als je hiervoor 50 LE's wilt opofferen zou je al heel veel kunnen oplossen met je FPGA. Idem USB-serieel.
Vooral als het gaat over lowcost integratie voor meerdere examplaren zou ik wel de moeite doen om die gewoon in de FPGA op hardware level erin te pompen. De opencores zijn in vele gevallen zelfs te omvangrijk maar daar kun je wel voldoende inspiratie uithalen om een meer geknipte versie voor je toepassing zelf te schrijven. Na een tijdje ga je dan voor andere toepassingen heel snel gelijkaardige oplossingen gaan integreren waardoor je dit niet meer als een ontwikkelings probleem gaat gaan zien maar als een voordeel.
Zeker als het voor de hobby is waarbij je niet echt op een paar uur moet uitkijken om het te realiseren. Daarvoor een NIOS gebruiken zou ik niet snel overwegen.
Flash geheugen kan een groter probleem zijn. Vooral de toegang naar SD cards is niet zo eenvoudig vergeleken met een gewone flash chip. Zolang je echter nog wat interne ram beschikbaar hebt kan die ook readonly gebruikt worden. je config prom laad die toch bij powerup.
Enfin mijn persoonlijke visie...
Op 8 december 2007 14:59:13 schreef fotoopa:
Ik begrijp eigenlijk niet goed de manier van werken. Je stelt dat je graag een microcontroller zou willen in je FPGA voor de eenvoudige taken. Maar doorgaans nemen die microcontrollers vrij veel LE's inbeslag terwijl je slechts 1 maal een eigen ontwerpje voor die serieele dingen hoeft te maken en die gaan slechts enkele tientallen LE's vergen.
Feit is gewoon dat sommige dingen zich beter voor software lenen. Het is ook veel eenvoudiger aan te passen dan hardware. Ik moet bijvoorbeeld I2C commando's uitvoeren na elkaar, maar sommigen hebben een extra delay nodig. Nu kan ik dat wel in hardware maken, en heb dat ook gedaan om te testen maar je bent dan aan het klooien met state machines e.d. om sequentieel de commando's uit te voeren. Je zou de commando's in een stukje geheugen kunnen zetten en deze achter elkaar uitlezen. Maar de delays moeten er ook in. Dan maar weer een soort speciale waarde daarvoor in het geheugen zetten en uiteindelijk ben je gewoon een soort mini-CPU aan het maken specifiek voor dit doel. Ook neemt dat allemaal best veel LE's in door al die state machines, tellers en flags.
I2C zelf is natuurlijk wel weer goed en snel in hardware te implementeren, maar de commando's zelf achter elkaar sturen doe ik veel sneller in software. In hardware ben ik er gewoon veel langer mee bezig. Misschien komt het ook wel omdat ik uit de software richting kom.
Ik vermoed dat je I2C vooral te maken heeft met configuratie van een externe chip. Als je hiervoor 50 LE's wilt opofferen zou je al heel veel kunnen oplossen met je FPGA. Idem USB-serieel.
50 LE's is geen enkel probleem natuurlijk, maar ik denk dat dat erg krap is voor de aansturing. Mijn snelle test-code die de video chip initialiseert - let op: wel op een erg quick & dirty manier geschreven - neemt iets van 250 LE's in. En dat is alleen initialisatie. Het gaat me niet zo zeer om I2C zelf, of een seriele aansturing, dat is juist goed en efficient in hardware te maken, maar vooral de aansturing op hoger niveau: welke commando's en wanneer voor I2C, seriele 'packets' parsen en verwerken voor serieel. Beide zo eenvoudig in software maar een heel gedoe in hardware.
AVRs hebben zelf bijvoorbeeld ook hardware I2C en UARTs, maar de rest is software. Ik wil een soortgelijke aanpak gebruiken maar dan binnen de FPGA.
Flash geheugen kan een groter probleem zijn.
SD flash of soortgelijk heb ik niet nodig, alleen geheugen om het programma in op te slaan en dat kan natuurlijk van alles zijn.
flipflop
"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
Op 8 december 2007 11:05:19 schreef madwizard:
Sommige dingen lenen zich gewoon erg goed voor software (zoals I2C commando's sturen). Eigenlijk wil ik gewoon zoiets als een AVR in de FPGA hebben.
Ik weet niet precies welke functies je precies in je cpu wilt laten lopen, maar je kunt je ook afvragen of je wel altijd een cpu nodig hebt. Je kunt ook een heleboel gewoon met statemachines en zo doen. Voor I2C heb je geen cpu nodig bv.
Soms wordt een beetje te gemakkelijk de "ouderwetse" architectuur (dus hardware aangestuurd door een uC)gecopieerd naar de FPGA configuratie waar dan ook weer een cpu in komt. Niet altijd nodig dus.
Maar misschien is het in jou situatie wel handig.
Is het geen idee om de hardware te ontwikkelen zonder AVR. Maar wel met extra vrije io poorten voor IO. En dat je daarop een AVR kan prikken. Deze is dan bedoelt voor ontwikkelen, en wanneer de meeste dingen klaar zijn. Een port maken naar hardware.
Op 8 december 2007 15:35:23 schreef madwizard:
[...]
Feit is gewoon dat sommige dingen zich beter voor software lenen. Het is ook veel eenvoudiger aan te passen dan hardware. Ik moet bijvoorbeeld I2C commando's uitvoeren na elkaar, maar sommigen hebben een extra delay nodig. Nu kan ik dat wel in hardware maken [.....]
Dit is idd een voordeel in software maar zolang je het kunt oplossen binnen de FPGA is er geen reden om een softcore erin te brengen. Omdat je meer ervaring hebt met software zie je dit terecht als een snellere oplossing maar eens je regelmatig statemachines gebruikt met tabellen en delay's gaat dit even goed maar efficienter. Het is een ontwikkelings curve die je moet doormaken. Met een softcore moet je ook communiceren tussen beide systemen en nog eens afzonderlijk software delen inbrengen. Omdat ik eerder hadrware gebruiker ben zie ik dit juist als een extra belasting en moeilijkheid. Software kan wel echt voordeel hebben als er heel veel data en dialoog moet uitgewisseld worden, een GUI laat ons zeggen. Maar in jou geval waar vooral de compactheid en kostprijs belangrijk is zou ik iets meer moeite doen om het gewoon via de hardware toer op te lossen.
Op 8 december 2007 15:40:54 schreef flipflop:
Ik weet niet precies welke functies je precies in je cpu wilt laten lopen, maar je kunt je ook afvragen of je wel altijd een cpu nodig hebt. Je kunt ook een heleboel gewoon met statemachines en zo doen. Voor I2C heb je geen cpu nodig bv.
Je kunt inderdaad een hoop met state machines doen, in feite kun je alles in hardware maken natuurlijk. Maar het gaat erom of het handig is. Dat hangt misschien ook erg af van de persoon die het maakt.
Ik heb het idee dat naar mate de state machines complexer worden en je allerlei extra tellers e.d. erbij gaat halen het langzaam een CPU begint te worden. Een CPU is natuurlijk ook gewoon een veredelde state machine.
Neem bijvoorbeeld fotoopa's LCD voorbeeld:
lcd_2x16.v
Helemaal onderin deze file zie je bijvoorbeeld een state machine voor de initialisatie van het LCD. M'n huidige I2C code lijkt hier wel een beetje op. Dit is iets wat ik bijvoorbeeld veel liever in software zou doen. Opdelen in functies, commando's achter elkaar in de functies zetten. Of in een array en erover heen loopen. In verilog kan het waarschijnlijk ook wel netter opgezet worden maar in code leest het toch lekkerder.
Ik weet niet precies wat er van dit soort state machines uiteindelijk gemaakt wordt, als alle cases een soortgelijk zijn kan het wel een soort LUT/RAM worden maar ik denk dat de synth het erg moeilijk heeft dit soort stukken efficiënt te implementeren. Als je veel extra registers gaat gebruiken (zoals variabelen in software) krijg je enorm veel afhankelijkheden en zit er ook niet echt een logisch patroon meer in.
Soms wordt een beetje te gemakkelijk de "ouderwetse" architectuur (dus hardware aangestuurd door een uC)gecopieerd naar de FPGA configuratie waar dan ook weer een cpu in komt. Niet altijd nodig dus.
Maar misschien is het in jou situatie wel handig.
Inderdaad, vooral als je uit de software hoek komt moet je opletten een FPGA niet als custom microcontroller te zien, zelf probeer ik zoveel mogelijk te kijken naar wat praktisch is.
Op 8 december 2007 15:49:46 schreef miniK0bo:
Is het geen idee om de hardware te ontwikkelen zonder AVR. Maar wel met extra vrije io poorten voor IO. En dat je daarop een AVR kan prikken. Deze is dan bedoelt voor ontwikkelen, en wanneer de meeste dingen klaar zijn. Een port maken naar hardware.
Het plan was te ontwikkelen op het DE1 bordje dus kan daar ook eventueel een gratis-licentie Nios in zetten tijdelijk.
Op 8 december 2007 16:35:54 schreef fotoopa:
Dit is idd een voordeel in software maar zolang je het kunt oplossen binnen de FPGA is er geen reden om een softcore erin te brengen. Omdat je meer ervaring hebt met software zie je dit terecht als een snellere oplossing maar eens je regelmatig statemachines gebruikt met tabellen en delay's gaat dit even goed maar efficienter.
Ik vind die tabellen en statemachines een stuk minder praktisch. Het blijft een soort source code (of meer assembler) schrijven maar dan direct in hardware. Op elke regel geef je aan wat er moet gebeuren, en in die volgorde worden de regels uitgevoerd.
Een CPU neemt een flinke hoeveelheid resources in maar een groot deel is eenmalig. Extra software kost alleen maar extra geheugen. Ook voert een CPU elke instructie op dezelfde manier uit, de hardware is vrij eenvoudig en niet afhankelijk van wat er gedaan wordt in software.
Op 8 december 2007 10:49:15 schreef miniK0bo:
@Rikkepichehe mooie foto, vooral dat reflectie dat van de plexiglas afkomt, doet me denken aan een lensflare effect om een plaatje op te leuke
sorry voor offtopic, maar schermpje komt van ebay. had de mazzel dat de zender er twee opstuurde, terwijl ik er een besteld heb voor €27. dus vandaar €13....
Gr. Rik
Als je een meer dimensionale array neemt:
reg [7:0]register[0:2]
Dit levert op: register[1],register[2],register[3] die allemaal 8 bits breed zijn.
hoe kan ik dan een gedeelte van bijvoorbeeld register[1] addreseren?
Edit:
Bestaat er ook nog zoiets als een "struct" in Verilog, in VHDL bestaat dat wel.
Ik zou dit handig vinden als je een hoop signalen bijeen neemt dan kun je ze als 1 signaal (de naam van de "struct") over sturen naar een ander blok, scheelt weer lijnen trekken enzo.
[Bericht gewijzigd door surge_me op (36%)]
Om te ontwikkelen zou ik voor een apparte AVR gaan, dit is makkelijker ontwikkelen omdat je alleen hoeft te compileren, ipv te synthesiseren en fitten. Het is gewoon zonde van je tijd als je alles moet synthesiseren en fitten om alleen een paar andere variablen te testen.
flipflop
"We cannot solve our problems with the same thinking we used when we created them" - Albert Einstein
@surge (er kroop net iemand voor )
Da's typisch een vraag van een software designer. Klopt dat?
Deel van register "adresseren". Mijn parate kennis schiet hier iets te kort. Ik zou het even moeten uitproberen, maar in feite zou het net zo moeten kunnen als bij een enkel regiser van 8 bits. Zoiets waarschijnlijk:
reg [7:0]register[0:2];
reg [7:0]register2;
register[1][2] <= 1'b0;
register2[2] <= 1'b0;
Ik hoop dat je snapt waarom ik hierboven "adresseren" tussen quootjes heb staan?
Dan de struct, volgens mij bestaat dat niet in Verilog. Maar je hebt het ook niet echt nodig:
output allemaal[23:0];
reg jan[7:0];
reg piet[7:0];
reg klaas[7:0];
wire allemaal[23:0];
assign allemaal <= {jan,piet,klaas};
En daar waar allemaal een input is kun je de losse elementen weer eruit halen met [23:16] en zo.
Ah nee ik ben niet echt een software designer hoor, (hoe zou jij in hardware "adresseren" dan noemen?, je snapt wat ik bedoel en daar gaat het om )
Maar structs zijn gewoon handig als je veel signalen tegelijk moet over gooien je hoeft dan niet zoals jij voorstelt gek gaan doen met die bitjes en die in een breed register zitten.
In VHDL kan je een struct maken, aanroepen werkt precies als in C.
register[1][2] <= 1'b0;
Dat zal ik eens proberen...
edit wat betreft die structs:
System verilog ondersteund wel structs (ook gewoon te gebruiken in quartus, geef je bestnad wel de extentie .sv anders gaat quartus over zijn nek)
In System verilog:
typedef struct{
reg foo;
logic bar;
} test_t;
test_t.foo <= 1'd1;
Ik vind het wel handig
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
Ik heb een soft-avr op mijn bordje draaien in de EP1C6. Wordt over USB geprogrammeerd (i.e. niet opnieuw synthetiseren als er een nieuw programma in moet).
rew
four NANDS do make a NOR . Kijk ook eens in onze shop: http://www.bitwizard.nl/shop/
pavr geloof ik.
Ah die met pipeline. Ik zal er eens naar kijken, ik kreeg bij dat project een beetje het idee dat het allemaal niet echt getest was. De auteur gaf al aan weinig ervaring met FPGA's te hebben en het niet fysiek getest te hebben.
Die andere AVR core (heet simpel 'AVR core') krijg ik niet goed, heb het idee dat er ooit een Altera versie van geweest is maar de core daarna alleen verder ontwikkeld is voor Xilinx en het nu allemaal niet meer goed werkt.
De T51 core (8051) kreeg ik wel direct gecompileerd, duurde wel 14 minuten en was flink groot, iets van 14k elementen.
edit: helaas, pAVR is GPL 