Heb je misschien een tip hoe ik dit aan moet pakken? Ik zou graag d.m.v. dit kitje een pong spelletje willen proberen te maken. VGA lijkt me daarvoor wel geschikt.
Ik vermoed dat meer personen dit kitje in bezit hebben vanwege de gunstige prijs, het lijkt me daarom leuk om het pong spelletje met een CPLD te realiseren.
Op het board zitten een aantal buttons die kunnen dienen als besturing.
Als je me verder wilt helpen wordt dat zeer gewaardeerd!
Voor een pong spelletje zal het zeker gaan. Je hebt waarschijndelijk geen ram geheugen nodig omdat je de info ( balletje of niets) samen met de lijnscan van de VGA kunt bepalen. palet is ook zo. En de pure VGA timing heeft maar weinig LE's nodig.
Omdat het nu volop tijd is voor het opnemen van vliegende beestjes kan ik momenteel geen tijd vrijmaken voor FPGA/CPLD toepassingen. Ik heb het te druk met mijn nieuwe integratie voor IR lasers, highpower UV leds en groene leds om nachtopnames te maken van de vliegende insecten. Dit is ook FPGA werk maar de meeste tijd gaat in de mechanische montage.
Vliegende beestjes?
pbase vliegende beestjes van fotoopa
Of ook op Flickr:
flickr vliegende beestjes van fotoopa
Vanaf september is het dan weer kalmer en wordt er meer hardware FPGA/CPLD gedaan. Ik heb hier nog 2 boardjes MAX II liggen die op een toepassing wachten.
Ik heb inmiddels allerlei dingen gedaan met vhdl, maar ik vroeg me af hoe ik het beste kan zien hoe vaak een signaal binnen een sampletijd komt.
Als voorbeeld: Als ik 100m afleg in 10s dan weet ik dat mijn snelheid 10m/s.
Als ik 10m afleg in 10s dan is mijn snelheid 1m/s.
Als ik nu bijvoorbeeld de snelheid wil uitdrukken in vhdl, moet ik dan ook gebruik maken van de shift actie om te delen, of zijn er nog andere (eenvoudige trucjes), heeft iemand er misschien een voorbeeld van?
Delen in hardware is tricky (vraag maar aan Intel). Dus als je 9.8m in 10 sec aflegt is je snelheid ongeveer 1.02 m/s,
Het makkelijkste is om de deling te voorkomen. Zoals je al zegt: als je meters telt in een bepaalde periode, heb je iets wat evenredig is met de snelheid. Maar heb je de tijd om 10s te tellen? Heb je wel iedere 1m een pulsje? Kan je leven met 10% onnauwkeurigheid?
Je moet een teller maken die telt als je pulsje binnenkomt. En je moet als de tijd-teller weer naar nul springt de pulsjes teller ergens bewaren voordat je hem op nul zet.
Delen en vermenigvuldigen zijn inderdaad lastige en "dure" operaties in hardware. Wat vaak gebeurd is dat deze in software gedaan worden als je toch al een CPU aan boord hebt (wat vaak wel het geval is).
Het KAN wel natuurlijk. Googlen maar.
Bericht voor Fotoopa:
Grappig, toevallig ben ik ook met het DE-1 board en de Intronix logic analyzer aan de gang gegaan. Mooi spul.
Kijk maar op dit forum waar ik enkele dagen geleden mijn eerste FPGA project heb gepost. http://forums.parallax.com/forums/default.aspx?f=25&m=305800
Veel succes met de prachtige foto's
Ik vind het jammer dat de interne LA niet werkt in de quartus webversie.
@nutson,
Mooi project!
Ik kan maar niet genoeg de nadruk leggen op tools om te kunnen meten zoals die Intronix LA. Die wordt hier bijna daagelijks gebruikt. Hoe kun je anders je resultaten beoordelen als je niet ziet wat er gebeurt?
De DE1 board wordt hier altijd gebruikt om de meeste ontwikkelingen te doen. Gezien die uitgangsconnector van de DE1 dezelfde is als de lowcost CPLD board MAX-II maak ik al de testen eerst op de DE1 en als die werken zet ik het project om naar het MAX-II boardje.
Mijn huidig ontwerp bevat nu 2 extra AVR controllers die eigen locale functie's uitvoeren en de resultaten via SPI connectie naar de CPLDboard sturen. Zo maak ik 50.000 analoge metingen per seconde in de AVR controller en stuur die door. Een 2de AVR controller doet mijn 150V regeling voor de magneten, bereken de gevoeligheid voor mijn lichtmetingen, bepaald de PWM waarde voor mijn UV powerleds en bereken ook de batterijspanning. Al deze gegevens gaan opnieuw naar de CPLD board via een SPI verbinding waar dan alle gegevens gebruikt worden. Zo kan ik binnen 40 usec weten als er een vliegend object in focus komt te staan met de camera en de nodige bevelen sturen om de foto te nemen. Al deze gegevens zijn eerst gemeten op de STK600 AVR toolkit samen met de Intronix LA. Enorm voordeel is dat je al de software kunt ontwikkelen zonder dat je de definitieve applicatieprint hoeft te maken. De Analoge instelwaarden die de STK600 kan leveren zijn ernorm handig bij de ontwikkeling. Ook het omschakelen naar verschillende type AVR controllers verloopt heel snel. Zo heb ik alle software op 1 dag tijd kunnen schrijven en uittesten voor de ATtiny45 en de ATtiny26 controller. Meteen beschik je over alle meetresultaten die opgeslagen worden op je PC voor verdere documentatie.
Ik zie hier op CO heel vele gebruikers die gewoon wat code of lib's overnemen en dan schreeuwen dat het niet werkt. Ze hebben niet de minste idee wat er gebeurt, erger nog ze weten ook niet hoe het moet werken.
Oude wijsheid: meten is weten. Ik had de ontwerp van deze FPGA versie van de Parallax Propeller CPU-kern nooit tot een goed eind kunnen brengen als de debug en test methode niet al van het begin in het project ingepland was.
Overigens kan ik iedereen aanraden eens naar deze processor te kijken, 8 kernen x 20 MIPS = 160 MIPS is een feest. Het grote voordeel is dat je een real-time proces (driver) op een kern kunt ontwikkelen, en als dat werkt vervolgens een ander proces op een andere kern kunt ontwikkelen zonder dat er ook maar een nanoseconde aan de timing van het eerste proces verandert. Probeer dat maar eens in een systeem met interrupts. Multi core micro controllers zijn de toekomst, kijk maar eens hier 4 kernen x 4 threads x 100 MIPS = 1600 MIPS en direct in C aanstuurbaar. Leuke tijd leven we in. http://www.xmos.com
@nutson, Alleen jammer dat ze in BGA vorm aangeboden worden en niet in een leuke DIP behuizing. Ik zie er het voordeel ook niet van in overigens.
De propeller is in een gewone 40 pin dip verkrijgbaar, en is perfect om bv robots te bouwen. Waar de Xmos mensen op mikken weet ik ook niet, ik schat producten waarin meerdere audio en video stromen gelijktijdig verwerkt moeten worden. Het was maar bedoeld om mijn stelling over multi-core kracht bij te zetten, ik kan nog andere voorbeelden noemen.
Van die proppellor weet ik dat hij ook in DIP behuizing zit. Maar ik had het over die andere multi-core processors.
Als je toch zo een multi-core neemt, lijkt het mij eenvoudiger om een FPGA te nemen. Maar goed.
Dan nu meer een FPGA-gerelateerde vraag. Wel te verstaan meer gerelateerd aan Quartus en zijn Megacore plugin-wizard. Ben er gisteren een beetje mee bezig geweest om eens te kijken naar een divider. (Neen, ik kan dat nog net niet zelf schrijven.... heb er wel voorbeelden van gezien, maar zó veel verstand van VHDL heb ik nu ook nog niet) iig. Ik was vooral benieuwd naar hoe goed die presteren wat betreft LE's/snelheid ten opzichte van een bijvoorbeeld zelf geschreven devider. Stoppen zij er heel erg veel extra meuk in, wat in sommige gevallen niet nodig is voor je eigen applicatie?
In mijn huidige geval, pipelined naar 1clock cycle 8bits denom en numer input, met 8bits quotient en 8bits remainder output, gebruikt hij op mijn cycloneII 93LE's.
(Uiteindelijke bedoeling is het inlezen van een CMOS camera, dus eigenlijk het realiseren van een CSI (CMOS Sensor Interface) en daar achter een eigen EMMA(heet zo toch? iig in de ARM9 wereld? of net iets anders? zo een co-processor die images kan (re)scalen en converteren naar andere Colorspaces, ik moet het weten! want ik heb er 5maanden geleden nog mee gewerkt.....) die vervolgens de RGB (of YUV) in kan lezen en converteren naar RGB/YUV/HSI.
Uiteindelijk is het de bedoeling om gebruik te maken van een LUT om Object Recognition te kunnen doen (met kleur, dus niet naar vorm) en om verschillende matrix- bewerkingen te kunnen doen (denk aan blur, Marr Edge Detection, Canny Edge Detection, Kirch (is dat ook een matrix bewerking?))
Van die gegevens die uit de LUT rollen moet een RLE gemaakt worden en die moet vervolgens naar buiten (of een interne CPU) gestuurd worden om region growing te kunnen doen en andere verwerkingen/bewerkingen.
[edit] Dit is trouwens een hobby-projectje 
Ik heb zo iets dergelijks (RGB inlezen, door een LUT halen, RLE maken en vervolgens region growing doen en dan X/Y coordinaten sturen via UART) al gerealiseerd in een pic24FJ. waarbij het inlezen/LUT in 2/3(assembler) instructies gedaan wordt en de RLE in 7.
Zie:
code:
and.b andNibble,[pPORTB],w0 ;[5]
mov.b [w0+pLut_g],w1 ;[6]
---snip---
and.b andNibble,[pPORTB],w0 ;[5]
mov.b [w0+pLut_r],w0 ;[6]
and.b w0,w1,[pBufferLine++] ;[7]
---dit stukje wordt 160x herhaald vervolgens:---
and.b andNibble,[pPORTB],w1 ;[5]
mov.b [w1+pLut_b],w1 ;[6]
and.b w1,[pBufferLine++],w0 ;[7]
---snip---
sub.b w0,[pBuffer],w1 ;[2]
bra NZ,2f ;[3]
;gelijk
mov.b w0,[pBuffer++] ;[4]
inc.b [pBuffer],[pBuffer--] ;[5]
nop ;[6]
bra 3f ;[8]
;ongelijk
2: inc2 pBuffer,pBuffer ;[5]
mov.b w0,[pBuffer++] ;[6]
mov.b w4,[pBuffer--] ;[7]
inc _FrameMgr_rle_length ;[8]
3: nop ;[9]
---en dat wordt ook 160x herhaald, daarna is 1line scan klaar---
Is toch best netjes? (dit is voor mijn afstudeerstage overigens) al zeg ik het zelf? en, iig, zo iets wil ik dus ook realiseren in een FPGA, maar dan ook dus nog colorspace conversie erbij en dus die matrix-bewerkingen 
[Bericht gewijzigd door Daan Timmer op 19 november 2008 10:25:27 (26%)
Hoi Daan,
Een deling heb je zelden nodig.
Als je een image van zeg 185 pixels naar 300 pixels wilt schalen is dat een schaling van 300/185. Wat je dan doet is, je deelt beide getallen door de macht van twee zodat ze alletwee kleiner zijn dan 1.
Je krijgt dus (300/512) en (185/512).
Vervolgens start je op pixel 0, de uitgangs pixelpositie is dan ook 0.
Dan copieer je dus 0->0 . Vervolgens tel je bij "uitgangspixel" de 300/512 op, en bij ingangspixel de 185/512. De uitgangspixel is nog steeds pixel 0, maar die hadden we al. Dus tel je nog een keer 300/512 bij uitgangspixel op, en 185/512" bij de "ingagnspixel". Nu is uitgangspixel "1.17" geworden. (het integer gedeelte is niet meer gelijk aan de vorige waarde). Dan moet je weer een pixel copieren....
Om logica te besparen kan je het "als de uitgangswaarde != vorige" stap ook overslaan...
Dit dupliceert simpelweg pixels. Dat is niet zo mooi. Wat mooier is als je pixels gaat mengen.
In het onderhavige geval willen we pixel 1 vullen. De "ingangspixel" waarde staat ondertussen op 370/512. Als je dan 3 bits achter de (binaire!) comma neemt, blijken die 5/8e te representeren. Dan neem je dus 5* pixel 1 (integer waarde +1) en (8-5=) 3* pixel 0 (ingangspixel), en deel je dat door 8.
P.S. De Altera megacores zijn heel redelijk. Alle stuff die er in zit en je niet nodig hebt, wordt geen VHDL van gegenereerd. Alles wat dan nog te veel er in zit wordt door de optimizer er uit gehaald. Ik verwacht dus weinig overhead in de deel-megacore van altera, die je niet nodig hebt....
Neen, die deling is nodig voor het converteren tussen verschillende colorspaces Ik ben zekers niet van plan om te gaan rescalen. Dat is iets wat die EMMA processor wel kan, maar voor mij niet nuttig is Mijn huidige beeldsensor gaat niet hoger dan 640x480. Als ik ga scalen scale ik met 2 of 4 (dus 320x240 en 160x120)
Wel bedankt voor de uitleg Weer wat handigheidjes geleerd!
RGB > HSI conversie (vanaf HSL/I wiki:
[Bericht gewijzigd door Daan Timmer op 19 november 2008 12:24:55 (28%)
Dan kan je de factoren toch altijd zo instellen dat de deling een macht van twee wordt?
neen, zie mijn vorige post.
'Fixed point RGB to HSI' levert ook niet veel soeps op via google 
Je moet van -60 naar +60 graden in max-min stappen. Neem "g-b" stappen....
Maar goed, als je dit iteratief doet, dan kan je net zo goed de deling iteratief doen... Ehh....
Verrek, dan is het weer een vermenigvuldiging geworden, nietwaar? Iteratief optellen noemen we vermenigvuldigen!....
(Ik heb in mijn eerste jaar universiteit de theorie uit "hoofdstuk 4" toegepast op een prakticum opdracht. Volgens de praktikumleiding moest ik echter de theorie uit hoofdstuk 7 gebruiken. Blijkt dat de praktikumleiding niet aan hun verstand te praten was dat het gewoon hetzelfde was. De formules waren hetzelfde, dus de methode is ook hetzelfde. Maar goed. Hier dus ook: De (ik weet ineens weer hoe het heet) bresenham methode werkt hier dus ook gewoon...
http://en.wikipedia.org/wiki/Bresenham's_line_algorithm
In HSI probleem heb je dus een Y as die overeenkomt met H (van -60 tot +60), en een Xas die van 0 naar max-min loopt. Hierop wil je eigenlijk direct de Y coordinaat van de pixel die overeenkomt met g-b weten....
Merk op dat in de taal "C" ze de "mod" (%) functie verkeerd gedefinieerd hebben.
In C is -30 % 360 = -30. Dat moet m.i. 330 zijn. En zo wordt het hier ook bedoelt!
PS: Ik probeer het even te implemeteren in C, maar loop even tegen een probleempje op. Ik weet even nog niet zeker of het kan. Moment....
Haha, je edit maakt dingen al een stuk duidelijker!
Ik ben maar een simpel HBO studentje die als 'Digital Systems (FGPA's e.d.)' vak alleen maar een serieele input, buffer, en teller + output heeft hoeven maken .
Wisknudde? alleen booleans dus wat je eerst schreef was voor mij echt abrakadabra >_< had wel eventjes ge-googled op 'iteratief optellen' e.d. maar, dan kwam ik gewoon op, wat iteratief is, en dat weet ik nu net weer wel 
This young padawan has much to learn, teach me, master!
Ik heb het effe geprobeerd, maar het lukt me niet. Ik kom niet onder de deling uit. Sorry.
http://prive.bitwizard.nl/rgb2hsi.c is mijn huidige probeersel. Ik was nog aan het klooien met de H voor als RED de grootste is, dus die werkt niet. Je hebt er (als je dat weer fixed zoals ook voor de andere kleuren) wel een versie puur in "ints" (maar dus helaas wel met deling).
Omdat ik toch heel regelmatig meerdere timers gebruik heb ik hiervoor een kleine module geschreven. Een parameterwaarde "TIMER_RANGE" kan ingesteld worden om de max timerduur te bepalen. Nu staat die konstante op 16 bit maar andere waarden mogen gegeven worden. 16 bit wil gewoon zeggen dat het timerbereik loopt van 0 tot 65535 clk's.
code:
module timer_mod
(
input clk, // tijden zijn clk x 10
input start, // pos edge startpuls min. breedte = 2 x clk
input [TIMER_RANGE-1:0] puls_time, // directe puls output duur
input [TIMER_RANGE-1:0] delay_time, // vertraagde puls output duur
output reg puls_out, // directe puls uitgang timer
output reg delay_out // vertraagde puls uitgang timer
);
parameter TIMER_RANGE = 16; // bitbreedte timers
reg [TIMER_RANGE-1:0] puls_cnt; // overname register puls_time
reg [TIMER_RANGE-1:0] delay_cnt; // overname register delay_time
reg [3:0] sync_cnt; // synchronisatie teller
reg start_reg; // edge detectie start
reg timer_ena; // enable timer
always @(posedge clk)
begin
start_reg <= start;
if(!start_reg & start & !timer_ena) // posedge start + timer moet free zijn
begin
timer_ena <= 1; // set timer busy
puls_cnt <= puls_time; // overname pulsbreedte
delay_cnt <= delay_time; // overname vertraging
sync_cnt <= 9; // synchronisatie op 10 x clk
end
else
begin
if (sync_cnt == 9) sync_cnt <= 0; else sync_cnt <= sync_cnt + 1;
if((sync_cnt == 9) & timer_ena)
begin
if(puls_cnt != 0)
begin
puls_cnt <= puls_cnt-1;
delay_out <= 0;
puls_out <= 1;
end
else
begin
if(delay_cnt != 0)
begin
delay_cnt <= delay_cnt-1;
delay_out <= 1;
puls_out <= 0;
end
else
begin
puls_out <= 0;
delay_out <= 0;
timer_ena <= 0;
end
end
end
end
end
endmodule
De timer bevat 2 inputwaardes:
"puls_time" is de breedte van de directe pulsuitgang.
"delay_time" is de breedte van de vertraagde pulsuitgang.
De "clk" is 10x hoger dan het aftellen van de timer. Hierdoor is er betere kontrol over het starten van de timer waardoor de tijd die verloopt tussen de startpuls en de directe pulsuitgang slechts 2 x clk is of 0.2 eenheden van je tellerwaarde.
Het starten van de timer gebeurt door het "start" signaal waarvan de posedge genomen wordt. Vandaar dat er 2 clk's verlopen tussen start en de directe uitgang. Maar deze heel kleine delay's zijn te verwaarlozen tov de 65535 * 10 clocks van de timer.
In je toepassing mag je als tijdswaarde gewoon de decimale waarde ingeven omdat Quartus dit zelf omzet naar de binaire waarde. Enkel in het geval je tijdswaarde een teller is binnen je applicatie moet je ermee rekening houden dat die binair moet zijn.
Het gebruiken van deze timermodule in je applicatie wordt dus zo een vorm:
code:
timer_mod timer1
(
.clk (clk_1ms),
.start (!KEY[0] | delay_t2),
.puls_time (120),
.delay_time (50),
.puls_out (puls_t1),
.delay_out (delay_t1)
);
timer_mod timer2
(
.clk (clk_1ms),
.start (delay_t1),
.puls_time (200),
.delay_time (50),
.puls_out (puls_t2),
.delay_out (delay_t2)
);
Ik heb er hierbij 2 timermodules gebruikt nl timer1 en timer2. Beide timers hebben een clk_1ms waardoor iedere opgegeven puls of delay time n*time*10 is hier in de eerste timer is de directe puls 120*10*1ms = 1200 msec
Merkop dat zolang de timer busy is er geen nieuwe cyclus kan gestart worden ( niet retriggerbaar dus) en je mag wel de timers aan elkaar verbinden waardoor je een knipperlicht kunt maken.
Deze timers gebruik ik in grote getallen voor al mijn vertragingen van mijn waterfiguren, sturen van camera, sturen van flitsen enz. Heb je een kleinere range nodig dan moet je de parameter waarde aanpassen. Met 10 bits zou je tot 1024 clk's kunnen instellen wat overeen komt met een 3 digit waarde.
Na de parameterwaarde te hebben aangepast moet je eerst hercompileren.
De conversie RGB -> H zou je kunnen oplossen met wat min/max/swap logica en een lookup table van 256 * 256 entries, maar 64k is natuurlijk best veel voor zoiets, en ik kan me voorstellen dat het moeilijk wordt om zo'n grote lookup efficient (ruimte en tijd) te doen.
@rew: dat bresenham algoritme is prima met integers te implementeren, door steeds A (185) op te tellen bij een totaal, en zodra die groter wordt dan B (300), een stap te zetten en B af te trekken van het totaal. Toevallig heb ik dit van de week geschreven in Verilog (werkt wel, nog geen onderzoek gedaan naar grootte / snelheid).
Waar ik momenteel even op vastloop, is het implementeren van buffers voor datacommunicatie en parameters. Ik wil een bepaalde module een set parameters geven, en bij een bepaalde conditie de volgende set parameters gaan gebruiken. Hiervoor wil ik een redelijk groot aantal (in ieder geval meer dan 2) sets parameters beschikbaar hebben, welke wordt aangeleverd door een microcontroller. Enig idee hoe ik zoiets efficiënt zou kunnen implementeren?
Ook ben ik nog bezig met het implementeren van SPI communicatie, waarbij ik verschillende registers in de FPGA wil kunnen lezen en schrijven. Bij voorkeur wil ik niet elk register in een case statement opnemen. Ik denk dat zoiets een enorm aantal flipflops gaat kosten, ideeën?
Sparky, inderdaad Bresenham is precies voor "met integers" bedoeld. Het ging er even om om bresenham toe te passen op RGB->HSV, maar dat lukte even niet.
(het lukt natuurlijk wel als je de deling doet door herhaaldelijk op te telen, en te kijken waar je de ingangswaarde overschrijd, maar dat kost weer cycles, en je wilt in 1 of 2 cycles je antwoord, en niet gemiddeld na 128....)
Als programmeur stuit het je tegen de borst om daar gewoon variabelen voor te nemen. Maar in hardware blijkt dat toch redelijk efficient te worden. Eventueel doe je iets met een FIFO buffer, waar je zodra de nieuwe parameters nodig zijn je de parameters uitlepelt. Dus als de microcontroller dat per 8 bits tegelijk aanlevert, kan je dus een 8bit x 128 buffertje maken. Als je iedere keer X waardes nodig hebt, kan je die met een statemachientje in je parameter registers zetten. Of je maakt de FIFO even breed als je registers.. (en dan maak je dus de writepuls van de fifo gelijk aan de write van het "laatste" register. )