[EiP] ILD-klok

[Sprite_tm]

CM kent het begrip 'CiP', Casemod in Progress, waarin iemand de complete bouw van een casemod beschrijft. Ik wil eens kijken of dat ook met elektronicaprojectjes werkt. Wat is de beste manier om zo'n test te runnen? Zelf eentje te starten natuurlijk

ILD-klok: wat is het?
ILD is een term die ik hier ooit eens op de flat opgepikt heb en het betekent basically 'Interesting Looking Device', iets waar je een tijd naar kan kijken maar wat verder niet noodzakelijk een zeker doel heeft. Het leuke aan deze ILD is dat je er, als je het truukje van weet, de tijd uit kan aflezen. Ik heb een voorbeeld in PHP geschreven wat de huidige tijd weergeeft. Druk op F5 als je andere manieren om de huidige tijd weer te geven wilt zien.

spoiler:

De hoeveelheid ledjes die aanzijn geven de tijd weer: de hoeveelheid gele het aantal uren (in 12-uurs-formaat; geen geel ledje aan = 12), de rode de tientallen minuten en de groene de eenheden minuten.

Bouw
Het idee was om het matrixje van 5x5 van leds te maken en aan te sturen door middel van Charlieplexing (pdf warning) aan te sturen en daar een AVR voor te gebruiken. De AVR word waarschijnlijk een ATTiny2313 omdat ik die in grote getale op voorraad heb en ik er veel ervaring mee heb. Verder is er nog een voeding voor nodig, wat waarschijnlijk een combo GSM-lader/7805 zal gaan worden.

Afwerking
Hiervoor staat nog niets in de planning; een rookglazen kastje is natuurlijk wel l33t maar kost waarschijnlijk meer dan de rest van het project bijelkaar. Ik denk dat ik dit onder de Twentsche afkorting KWW schuif

Updates
Updates komen in een aparte post terecht; ik zal hieronder linken naar die posts.
Update 1: Schema, ledarray gesoldeerd
Update 2: Avr-gcc geinstalleerd; eerste testje matrix.
Update 3: Nu in assembly, display-code, fade-routine, random number generator.
Update 4: random number generator-problemen.
Update 5:Individuele leds mappen
Update 6: N willekeurige leds laten branden
Update 7: We hebben een RTC, meer ILD

[ Voor 23% gewijzigd door Sprite_tm op 17-08-2006 21:24 ]

[naftebakje]

Nice, leuk initiatief, goed dat je "simpel" begint (wie met een µC heeft gewerkt, krijgt zoiets wel gebouwd, met wat geduld en tijd). Tis meteen een mooiere vorm van howto's; en ook beginners kunnen er erg veel van leren (waarom kies je voor dat, en niet iets anders. Als ze dat vragen, is het dikwijls erg moeilijk om te antwoorden, mss kunnen een aantal EiP's dat duidelijk maken).

Ik had EiP overigens meteen door, ik moet onbewust al zoiets verwacht hebben, prachtinitiatief!

[ Voor 8% gewijzigd door naftebakje op 01-07-2006 21:07 ]

[Verwijderd]

klinkt heel leuk, orgineel idee ook.
ben er van overtuigd dat het ook wel moet lukken met jij kennis

alleen, waarom zijn er 3 soorten groen en ook een soort paars ?

en net als naftebakje snapte ik ook meteen EiP

[ Voor 14% gewijzigd door Verwijderd op 01-07-2006 22:45 ]

[lemming_nl]

Heel leuk idee, hopelijk lukt het een beetje om leuke updates te maken zodat het topic interessant blijft.

offtopic:
Ligt het aan mij of is het erg rustig in EL? Misschien dat dit soort dingen het wat veranderd. Er is geen topic waar mensen hun creaties kunnen showen, maar ik denk dat dit is een mooiere oplossing is als een opsom topic.

[TommyboyNL]

Heel veel succes ermee. Alleen vraag ik me af hoe je met een GSM-lader en een 7805 een voeding wilt maken. GSM laders spugen meestal maar 3,7 volt uit. Een enkeling ook 5V, maar 8V of meer, wat nodig is om een 7805 te laten werken, heb ik nog nooit uit een gsm lader zien komen.

[Bio]

Verwijderd schreef op zaterdag 01 juli 2006 @ 22:45:
klinkt heel leuk, orgineel idee ook.
ben er van overtuigd dat het ook wel moet lukken met jij kennis

alleen, waarom zijn er 3 soorten groen en ook een soort paars ?

en net als naftebakje snapte ik ook meteen EiP

volgens mij zijn de paarse de leds die uitstaan

ziet er iig leuk uit.

[ Voor 4% gewijzigd door Bio op 01-07-2006 23:22 ]

[naftebakje]

TommyboyNL schreef op zaterdag 01 juli 2006 @ 23:18:
Heel veel succes ermee. Alleen vraag ik me af hoe je met een GSM-lader en een 7805 een voeding wilt maken. GSM laders spugen meestal maar 3,7 volt uit. Een enkeling ook 5V, maar 8V of meer, wat nodig is om een 7805 te laten werken, heb ik nog nooit uit een gsm lader zien komen.

Spanningsdelertje in de terugkoppeling, en je kan de uitgangsspanning maken wat je wil (binnen grenzen natuurlijk); wel kan je dan minder stroom trekken, en kan het inschakelgedrag er onder lijden (maar dat lost je 7805 dan wel weer op).
Een geschakelde buck-boost regulator lijkt me echter beter, IC'tje met wat weerstanden en een spoeltje, en uit een ingangsspanning tussen 2 en 30V haal je exact je 5V, zuiniger en nauwkeuriger dan een 7805...

Ik hoop dat ik ook wat leuks kan vertellen binnenkort, mij eindwerk voor volgend jaar wil ik in de vakantie af hebben, een sensorennetwerkje maken met zigbee, zodat ze het kunnen geven als labo-oefening

[ Voor 12% gewijzigd door naftebakje op 01-07-2006 23:25 ]

[madwizard]

Leuk initiatief Grappig idee ook de ILD-klok, charlieplexing is een leuke techniek al heb je waarschijnlijk wel een (push-pull) buffer nodig als je de LEDs op hun normale stroom wilt laten branden.

Zelf heb ik op het moment geen geweldige projecten lopen behalve een (optisch geisoleerde) USB JTAG adapter voor AVRs. Vrijdag ga ik op vakantie dus het zal wel even duren nog voordat het af is, ben al wel bezig geweest met het printontwerp.

[kluyze]

Ik ben ook al een tijdje aan het denken van een soort van CiP te maken in electronica . Nu weet ik ook dat het mag

Leuk projectje trouwens, ik ga het zeker volgen.

offtopic:
Hoe zit het trouwens met aanvragen voor een EiP? Via mail?

[Sprite_tm]

madwizard: Yep, je hebt eigenlijk een pushpull-buffer nodig, maar ik wil wel es kijken of ik het met de gpio's in de AVR, eventueel gecombineerd met een stel torretjes, afkan. Dit is de eerste keer dat ik wat met charlieplexing doe, dus het is ook voor mij nieuw. En ja, ik kan het wel theoretisch doorrekenen, maar het is vakantie dus ik ga fijn practisch aankloten Niemand heeft gezegd dat dit ding productie-kwaliteit moet wezen

kluyze: Imo zijn EiPs atm nog gewoon op te starten, als er teveel van bedenkelijke kwaliteit komen kunnen we alsnog regels opstellen. Een CiP is zowiezo wat sneller te bedenken en op te zetten dan een EiP, dus ik hoop een beetje dat het zichzelf filtert.

TommyboyNL: Ooit wel eens aan een GSM-lader gemeten? Iig bij Nokia en de oudere Siemens-laders komt er onbelast gewoon fijn een gelijkgerichte en brak of zelfs niet afgevlakte spanning van ongeveer 10V naar buiten zetten.

[ Voor 19% gewijzigd door Sprite_tm op 02-07-2006 00:30 ]

[Sprite_tm]

Ik heb gisteravond al de leds inelkaargesoldeerd. Het is gedaan volgens dit schema, ik heb het redelijk brak bedacht en meteen aangenomen dat het wel goed zal zijn. Nou maar hopen dat dat inderdaad zo is, anders kan ik het een en ander weer terugsolderen... (Bij alle pics: click = groter)


Ik heb het geheel freestanding opgebouwd, dat staat wel leuk lijkt me. Ik zit er nog over te twijfelen of ik de rest van het schema ook zo ga maken of of ik toch deze week eens ga kijken of ik naar een elektronicazaak heen ga fietsen om een stukkie printplaat op te halen... Da's het nadeel van componenten in huis hebben: als je iets wel mist, moet je voor 1 lullig onderdeeltje de electrozaak binnenlopen.

Anyway, pics. Zoals je ziet heb ik me vrij 1-op-1 aan het schema gehouden.

De horizontale en vertikale 'lijnen' raken elkaar niet omdat ik de pootjes van de ledjes van de vertikale lijnen iets lager afgebogen heb. Ik hoop dat het in deze pic te zien is:


Verder heb ik net even de toekomstige aanstuurschakeling inelkaargeklad:


Linksboven de voeding, een standaard 78L05-oplossing. Ik heb geen flauw idee of de condo-waardes volgens de datasheet zijn, maar de ervaring leert dat alles het met deze waardes wel doet. De uiteindelijke waardes die ik ga gebruiken kunnen zowiezo veranderen; als ik een condo die beter past maar een iets andere waarde heeft heb, gebruik ik die. Da's imo ook een onderdeel van elektronicakennis: weten waar een afwijking in de waarden toegestaan is.

Rechtsboven de ledmatrix, waarvan ik veel te lui ben om 'm opnieuw te tekenen en daaronder twee drukknopjes die uiteindelijk voor het instellen van de klok moeten dienen. De drukknopjes trekken de twee microcontrollerpinnen naar aarde omdat ik dan gebruik kan maken van de zwakke pull-up-weerstandjes die in de microcontroller aan te zetten zijn: dat bespaart me weer twee weerstandjes solderen.

De schakeling rond pd6 is een LDR die aan een AD-converter hangt. Hiermee kan het omgevingslicht gemeten worden en is het mogelijk de matrix te dimmen als het donker word. Voor de mensen die de AD-converter niet zien: Da's de condensator. Hoe dat een AD-converter gaat worden zul je bij de code wel zien

Ik zie net dat ik vergeten ben om een kristal aan de microcontroller te tekenen: die komt er wel aan te hangen. De uC heeft ook een ingebouwde RC-oscillator, maar hoewel die tegenwoordig vrij nauwkeurig is, geeft 'ie in een klok toch teveel afwijking.

[madwizard]

Sprite_tm schreef op zondag 02 juli 2006 @ 13:10:
Ik zie net dat ik vergeten ben om een kristal aan de microcontroller te tekenen: die komt er wel aan te hangen. De uC heeft ook een ingebouwde RC-oscillator, maar hoewel die tegenwoordig vrij nauwkeurig is, geeft 'ie in een klok toch teveel afwijking.

Zeker, volgens het datasheet zelfs maximaal 10%, das 2,4 uur per dag verschil

[SlinkingAnt]

Hee, ziet er weer leuk en origineel uit. Voor de mensen die nog niet eerder van Charlie-plexing gehoord hebben, Op deze site van Maxim staat duidelijk uitgelegd hoe het werkt. Eigenlijk is het vrij simpel . Zeker een projectje wat ik ga volgen en misschien zelf een keer maken

[TommyboyNL]

Ziet er goed uit tot nu toe. Alleen heb je volgens mij een klein foutje gemaakt. Aan de aantallen van de kleurtjes te zien zijn de 12 rode LEDs voor de uren, de 5 groene voor de tientallen minuten, en de 8 gele voor de losse minuten. Dit gaat naar mijn idee niet uitkomen, je kan namelijk de negende losse minuut niet weergeven, slechts tot de achtste.
Naar mijn idee moet je dus een rode LED vervangen door een gele. Correct me if I wrong

[Sprite_tm]

Krek, je hebt gelijk. * Sprite_tm zet soldeerbout weer aan...
Edit: Gefixed. Ik ben te lame om nu een pic te nemen, het resultaat valt de volgende update wel te zien.

[ Voor 44% gewijzigd door Sprite_tm op 02-07-2006 14:23 ]

[brinkdinges]

Sprite_tm schreef op zondag 02 juli 2006 @ 13:10:
[knip]
De schakeling rond pd6 is een LDR die aan een AD-converter hangt. Hiermee kan het omgevingslicht gemeten worden en is het mogelijk de matrix te dimmen als het donker word. Voor de mensen die de AD-converter niet zien: Da's de condensator. Hoe dat een AD-converter gaat worden zul je bij de code wel zien

Gokje Je gaat de tijd meten die nodig is om de condo leeg te laten lopen over de LDR? Ik geloof dat ik dat ooit ergens heb gelezen, om een digitale ingang te gebruiken als AD-converter.

[ Voor 5% gewijzigd door brinkdinges op 02-07-2006 20:37 ]

[SlinkingAnt]

brinkdinges schreef op zondag 02 juli 2006 @ 20:37:
[...]

Gokje Je gaat de tijd meten die nodig is om de condo leeg te laten lopen over de LDR? Ik geloof dat ik dat ooit ergens heb gelezen, om een digitale ingang te gebruiken als AD-converter.

En aangezien PD6 de input capture interrupt is, stelt het eigenlijk niet eens zo veel voor, maar je moet er maar net opkomen

[Nik]

Vanwaar zitten alle ledjes zo door elkaar? Het maakt het kijken / tellen niet makkelijk? Of heeft dat nog een reden?

[ Voor 20% gewijzigd door Nik op 02-07-2006 21:36 ]

[Nakebod]

Ik denk dat die reden is: 'Interesting Looking Device'.
Wat een nog vettere oplossing zou zijn: RGB leds gebruiken, nu zitten feitelijk alle gele, rode en groene op 1 vaste plaats.
Misschien dat je daar met RGB leds nog een ingewikkelder iets van kan maken.
Verder is het een best wel geinig hebbedingetje denk ik

[lemming_nl]

Nakebod schreef op zondag 02 juli 2006 @ 21:48:
Ik denk dat die reden is: 'Interesting Looking Device'.
Wat een nog vettere oplossing zou zijn: RGB leds gebruiken, nu zitten feitelijk alle gele, rode en groene op 1 vaste plaats.
Misschien dat je daar met RGB leds nog een ingewikkelder iets van kan maken.
Verder is het een best wel geinig hebbedingetje denk ik

Toen ik het verhaaltje in de TS las dacht ik dat RGB leds juist het idee waren. Dat hij vervolgens iedere 10 seconden ofzo van patroon zou verspringen. Dan zou iemand die er gewoon naar kijkt echt geen idee hebben wat het is.

[SA007]

Ik ben eens aan het kijken geweest naar dual-color leds hiervoor gebruiken, maar volgens mij is dat met 8 datalijnen niet mogelijk.

Dual color leds zijn eigenlijk altijd common cathode, en hierdoor onstaat een probleem, waardoor je op 8 datalijnen met charlieplexing 24 dual color en 8 normale leds kan aansluiten.

Aan de onderste lijn kan je nog 7 leds hangen, en de ene losse rechtsonder samen maakt 8.

[ Voor 11% gewijzigd door SA007 op 03-07-2006 20:08 ]

[Thijsch]

Rood/groene leds zijn vaak antiparrallel geschakeld, dus in principe al gecharlieplext..

[SA007]

ParaDot: hu?, volgens mij zijn dual colorleds zo:

code:

  Rood  Groen
 __|\|___|/|__
   |/| | |\|
       |

Weet niet wat dat te maken heeft met antiparalel, en wat charlieplexing heeft te maken met 1 losse dualcolor led...

[SlinkingAnt]

Op het moment is er een inkoopactie op sk.net waar er diverse ledjes tegen spotprijzen aangeboden worden. Hier zitten ook redelijk felle common anode RGB-leds tussen

[SA007]

geen dual color leds helaas... Link direct naar de sk

[madwizard]

Met charlieplexing kun je met n datalijnen n * (n-1) losstaande LEDs aansturen. Logischer gezegd: je kunt n groepen van (n-1) segmenten aansturen. Met common-* LEDs heb je al groepjes van 2 gemaakt, het maximum (8 groepen van 7 segmenten) kun je dus niet gebruiken omdat je geen groepen van 7 kunt maken (de LEDs gaan immers per 2). 8 * 6 is het grootste even aantal, oftwel 48 LEDs, wat idd 24 dual color LEDs zijn. Wat je overhoudt is dan nog 1 segment per groep, dus 8 losse LEDs. Dat klopt met wat SA007 heeft uitgewerkt.

Er zijn ook dual-color LEDs waar de LEDs antiparallel staan. Dat zijn dus LEDs met gewoon 2 pootjes, maar wel met 2 kleuren. Afhankelijk van de polariteit waarmee je ze aansluit gaat een van de 2 LEDs aan:

code:

   +---|<|---+
   |         |
---+         +---
   |         |
   +---|>|---+

Er kan dus ook maar 1 LED tegelijk branden.

Ik denk dat deze types juist nog ongeschikter zijn voor charlieplexing. Je zult namelijk groepen moeten maken van kathodes (of precies andersom maar ik neem nu even kathode aan). Als je echter kathodes aan elkaar gaat knopen worden ook de anodes van de anti-parallele LED aan elkaar geknoopt. Dan kun je nooit die anti-parallele LEDs meer afzonderlijk schakelen. Charlieplexing gebruikt steeds 1 lijn als kathode om een groep te selecteren en de andere lijnen worden geselecteerde anodes om bepaalde LEDs in die groep op te lichten. Als anodes aan elkaar zitten werkt dit niet meer. Ook kom je waarschijnlijk in de knoei met voorschakelweerstanden.

[SA007]

Ah, das antiparrallel, tnx voor de uitleg
Die zijn inderdaad totaal niet te gebruiken..

Zijn er geen common anode dual color leds, of waar er helemaal niks common is (dus 1 led, 4 pootjes), dan zou het wel helemaal kunnen.

Anders wordt het 1 led die maar 1 kleur kan weergeven helaash.

[madwizard]

SA007 schreef op dinsdag 04 juli 2006 @ 00:04:
Zijn er geen common anode dual color leds, of waar er helemaal niks common is (dus 1 led, 4 pootjes), dan zou het wel helemaal kunnen.

Met common anode schiet je ook niets op, charlieplexing gaat juist uit van een common iets. Als je allemaal losse LEDs gebruikt ga je namelijk zelf een common cathode maken door ze aan elkaar te knopen. Het probleem is puur dat dual color LEDs per 2 aan elkaar vast zitten, en je dus geen groepen van 7 kan maken maar hoogstens van 6. Als alle LEDs los zaten kan je een groep meer vullen en zo aan de 25 komen (en nog meer). 1 LED met 4 pootjes zou alles oplossen.

Je zou trouwens ook nog twee extra I/O poorten voor de ene dual-color LED die er net niet in past kunnen gebruiken. De attiny2313 heeft er wel meer dan 8.

[SA007]

@madwizard, als er beide types zouden zijn zou je op 27 dual color leds en 2 normale aan kunnen sluiten, dus dat zou het oplossen, zoals ik getekend had kom je er met common kathode net niet, met common anode nog niet uitgewerkt, maar beide types gemengd is ook een oplossing hoor.

(en het gaat niet om dat ene extra poortje wat je dan gebruikt hoor)

[madwizard]

SA007 schreef op dinsdag 04 juli 2006 @ 00:23:
@madwizard, als er beide types zouden zijn zou je op 27 dual color leds en 2 normale aan kunnen sluiten, dus dat zou het oplossen, zoals ik getekend had kom je er met common kathode net niet, met common anode nog niet uitgewerkt, maar beide types gemengd is ook een oplossing hoor

He ja een combinatie is natuurlijk niet zo'n gek idee, dat zou wel eens kunnen werken.

[SA007]

nu nog common anode dual color leds vinden, en common cathodes in dezelfde kleur en vorm...

[Thy...]

Ziet er gaaf uit! Met RGB leds is hij mischien wel spectaculairder maar juist het simple uiterlijk (een paar ledjes) het nut (een klok) en omdat andere geen idee hebben wat het is erg leuk.

En [Eip] vind ik ook een goed idee, hopelijk komen er veel projectjes op t forum.

[Sprite_tm]

Door het mooie weer en andere zaken heeft het even geduurd voordat ik weer bezig kon aan de ILD-klok. Vandaag vond ik het echter zo'n type weer dat een beetje buiten relaxen toch te passief is; vandaar de update.

Ik had al eerder een IC-voetje aan het geheel gesoldeerd:


Verder ga ik, zoals gezegd, het geheel programmeren in C, wat vrij nieuw voor me is omdat ik m'n eigen AVRs eigenlijk alleen maar in assembly geprogrammeerd heb. (Wat trouwens niet betekent dat ik geen ervaring met C heb; dat heb ik zowel op de PC als op andere microcontrollers al wel gebruikt.)

Het eerste wat er moet gebeuren is een toolchain (compiler + tooltjes eromheen) installeren. Had ik Windows gebruikt had ik Winavr kunnen gebruiken, maar ik ben Debian-fan dus ik kan het installeren door op een console sudo apt-get install avr-libc binutils-avr gcc-avr in te tikken. Na wat pruttelen staat er dus nu een compiler op mijn bak.

Wat hebben we nog mer nodig? Een programmer heb ik al geinstalleerd staan (avrdude), dus aan de tools-kant zou alles er moeten zijn. We kunnen dus een project starten, en als Linux-fanaat doe ik dat dus zonder nifty IDE, maar gewoon met een teksteditor.

Een project zie ik als niet meer dan een directory met daarin de bestanden om de firmware te kunnen bakken. In dit geval zijn dat de sourcecode en het 'recept' om de source in firmware om te zetten. De meestgebruikte manier daarvoor is een makefile. Makefiles schrijven worden door de meeste mensen die het nog niet zo lang doen als hoge magie gezien, samen met sendmail.confs veranderen en geavanceerde regexps schrijven. Ik zou hier graag zeggen dat het helemaal niet zo is, maar helaas behoor ik zelf ook tot de groep die het moeilijke stof vind. Daarom heb ik een makefile van een ander project gekopiepeest en aangepast.

Verder hebben we sourcecode nodig. Ik ben alleen van plan om de matrix zelf te testen, dus een zwaar geavanceerde filestructuur is niet nodig; alle code mag wel in de main.c gedumpt worden.

Daarna de code zelf. Hoe begin je daaraan? Zoals gezegd ken ik wel C maar de library welke je aanroept om dingen op de AVR te kunnen doen is mij onbekend. Geen nood, dat kreng (genaamd avr-libc) heeft ook een handleiding (pdf) met voorbeelden.

Eerst maar even een testje om te kijken of de toolchain zowiezo wel iets doet:

C:

#include <avr/io.h>                                                             
#include <util/delay.h>                                                         
                                                                                
int main(int argc, char** argv) {                                               
    unsigned char w;                                                            
    unsigned char p;                                                            
    DDRB=0x3f;                                                                  
    p=1;                                                                        
    while(1) {                                                                  
        PORTB=p;                                                                
        p=p<<1;                                                                 
        if (p==1<<6) p=1;                                                       
        _delay_loop_2(65535);                                                   
        _delay_loop_2(65535);                                                   
        _delay_loop_2(65535);                                                   
    }                                                                           
    return(0);                                                                  
}     

Wat uiteindelijk blijkt te compileren en het volgende beeld oplevert: Videotje. De video geeft meteen aan wat een typische aanstuur-structuur je krijgt als je met behulp van Charlieplexing een matrix aan wilt sturen.

De complete broncode + mijn makefile zijn te downloaden: Klik!

Voetnootje / persoonlijke rant:
Het blijkt trouwens maar weer dat het zeker met deze kleine devices zeer zeker wel handig is om ook assembly te kennen en er van op de hoogte te zijn dat compilers niet altijd doen wat je wilt. Ik had bijvoorbeeld voor het wachtloopje eerst

code:

unsigned int w;
for (w=0; w<65535; w++);

gedaan. Als dit echter door de compiler heengetrokken word, blijft er dit als assembly over:

code:

Helemaal niets dus: het loopje lijkt programmatechnisch nutteloos te zijn en dus word het weggeoptimaliseerd. Normaliter zou je dit kunnen oplossen door w volatile te maken; wat betekent dat de compiler alle veranderingen eraan ook moet uitvoeren en er niets aan mag wegoptimaliseren. De assembly die ik daaruit kreeg zal ik maar niet posten; behalve niet-werkend was 'ie namelijk ook nog ueber-smerig Nja, geeft maar weer aan: listing-files zijn handig

[DrivinUCrazy]

Ziet er alweer goed uit Sprite_tm!

Ik kan wel volgen wat je doet, maar er helemaal zelf op komen is toch weer een ander verhaal. Misschien moet ik maar eens wat meer met microcontrollers gaan klooien, het blijft toch leuk speelgoed. (ik programmeer zelf vooral PLC's, een andere tak van sport)

Wat ik eigenlijk wilde vragen, komt dit ook weer in de Elektuur te staan? Met andere woorden, je doet hier het voorbereidende werk, en het uiteindelijke verslag komt in de Elektuur? Of vind Elektuur dan dat ze eigenlijk 2e keus zijn, omdat het al uitgebreid op internet staat?

[Sprite_tm]

Nah. Ik ga hier uiteindelijk wel in het Engels een projectbeschrijving van maken en op mijn website zetten, maar that's it wel zo ongeveer. Ik heb nog genoeg projectjes voor Elektuur liggen om dit fijn alleen hier uit te werken. Ik heb het met de elektronische stempel wel gedaan maar dat was meer omdat het bijna 2 aparte projectjes waren: zowel de hard- als de software voor hetgene wat ik voor GoT en Elektuur geschreven heb, zijn vrij verschillend.

[NMe]

Sprite_tm schreef op zaterdag 08 juli 2006 @ 17:02:
Voetnootje / persoonlijke rant:
Het blijkt trouwens maar weer dat het zeker met deze kleine devices zeer zeker wel handig is om ook assembly te kennen en er van op de hoogte te zijn dat compilers niet altijd doen wat je wilt. Ik had bijvoorbeeld voor het wachtloopje eerst

code:

unsigned int w;
for (w=0; w<65535; w++);

gedaan. Als dit echter door de compiler heengetrokken word, blijft er dit als assembly over:

code:

Helemaal niets dus: het loopje lijkt programmatechnisch nutteloos te zijn en dus word het weggeoptimaliseerd. Normaliter zou je dit kunnen oplossen door w volatile te maken; wat betekent dat de compiler alle veranderingen eraan ook moet uitvoeren en er niets aan mag wegoptimaliseren. De assembly die ik daaruit kreeg zal ik maar niet posten; behalve niet-werkend was 'ie namelijk ook nog ueber-smerig Nja, geeft maar weer aan: listing-files zijn handig

C:

unsigned int w;
for (w=0; w<65535; w++) {
  __asm { NOP }
}

Zoiets lijkt me ook mogelijk?

edit:

Beetje een schop zie ik nu, maar goed, het is wel een leuk projectje natuurlijk.

[ Voor 7% gewijzigd door NMe op 21-07-2006 01:28 ]

[Sprite_tm]

Mja, maar de gein was dat ik in C wilde programmeren, niet in assembler
Het project staat trouwens even een weekje op pauze; mijn werk is verhuist en dat hebben we als IT-mensen meteen aangepakt om het server- en workstationpark es up te graden en ook de workstations te migraten naar Linux. Drukdrukdruk dus

[RedPixel]

offtopic:
'is verhuisd' is met een d

Wat een leuk en moeilijk projectje, jammer dat er een week niks aan gebeurd.

[NMe]

Sprite_tm schreef op vrijdag 21 juli 2006 @ 10:29:
Mja, maar de gein was dat ik in C wilde programmeren, niet in assembler

Ach, het meest belangrijke staat hier nog steeds in C. Het verschil is dat je eerst letterlijk niets deed, waardoor het terecht weggeoptimaliseerd wordt. Door expliciet te zeggen "doe 65535 keer niks" doet ie dat niet.

[SA007]

Wat is er eik mis met usleep oid? werkt dat niet ofzo?

[Sprite_tm]

SA007: usleep is een library routine van bijvoorbeeld glibc; die zit niet standaard in de AVR oa omdat je daar geen OS hebt.

En de moed begint me een beetje in de schoenen te zakken qua C-programmeren. Waarom dumpt gcc globale variabelen bijvoorbeeld in het SRAM, terwijl ik nog zat registers vrij heb? Waarom krijg ik dit als assembly

code:

    pb=(1<<matrixpos);
  64:   e0 91 60 00     lds     r30, 0x0060
  68:   ff 27           eor     r31, r31
  6a:   81 e0           ldi     r24, 0x01       ; 1
  6c:   90 e0           ldi     r25, 0x00       ; 0
  6e:   0e 2e           mov     r0, r30
  70:   02 c0           rjmp    .+4             ; 0x76 <muxmatrix+0x24>
  72:   88 0f           add     r24, r24
  74:   99 1f           adc     r25, r25
  76:   0a 94           dec     r0
  78:   e2 f7           brpl    .-8             ; 0x72 <muxmatrix+0x20>

terwijl wat ik wil in ongeveer de helft van de code kan, en ik zowel matrixpos als pb als uint8 gedeclareerd heb?

Ik zit er hard over te denken om C voor de 16/32-bitters over te laten en op mijn avr'tjes weer gewoon in assembly te proggen; hoewel ik normaliter geen enkel probleem heb om werkende C uit te spugen heb ik het idee dat ik bij avr-gcc tegen problemen blijf oplopen.

[SlinkingAnt]

Sprite_tm schreef op vrijdag 21 juli 2006 @ 18:57:
SA007: usleep is een library routine van bijvoorbeeld glibc; die zit niet standaard in de AVR oa omdat je daar geen OS hebt.

En de moed begint me een beetje in de schoenen te zakken qua C-programmeren. Waarom dumpt gcc globale variabelen bijvoorbeeld in het SRAM, terwijl ik nog zat registers vrij heb? Waarom krijg ik dit als assembly

code:

    pb=(1<<matrixpos);
  64:   e0 91 60 00     lds     r30, 0x0060
  68:   ff 27           eor     r31, r31
  6a:   81 e0           ldi     r24, 0x01       ; 1
  6c:   90 e0           ldi     r25, 0x00       ; 0
  6e:   0e 2e           mov     r0, r30
  70:   02 c0           rjmp    .+4             ; 0x76 <muxmatrix+0x24>
  72:   88 0f           add     r24, r24
  74:   99 1f           adc     r25, r25
  76:   0a 94           dec     r0
  78:   e2 f7           brpl    .-8             ; 0x72 <muxmatrix+0x20>

terwijl wat ik wil in ongeveer de helft van de code kan, en ik zowel matrixpos als pb als uint8 gedeclareerd heb?

Ik zit er hard over te denken om C voor de 16/32-bitters over te laten en op mijn avr'tjes weer gewoon in assembly te proggen; hoewel ik normaliter geen enkel probleem heb om werkende C uit te spugen heb ik het idee dat ik bij avr-gcc tegen problemen blijf oplopen.

Heb je wel optimalisaties aanstaan/goedstaan?
Als ik met WinAVR op eenzelfde manier een pin hoogmaak, krijg ik dit in de .lss

code:

        led2_port &= ~(1<<led2);                //LEds uitzetten
 2b8:   c3 98           cbi 0x18, 3 ; 24

Hmm, net even in je Makefile uit de TS gekeken, maar daar mis ik idd de OPT = ?

code:

# Optimization level, can be [0, 1, 2, 3, s]. 
#     0 = turn off optimization. s = optimize for size.
#     (Note: 3 is not always the best optimization level. See avr-libc FAQ.)
OPT = s

Waarschijnlijk al voeg je ^^ toe, werkt het dan wel fatsoenlijk

[Sprite_tm]

Ik heb mijn makefile tijdens het prutsen al es veranderd; deze regel geeft waarschijnlijk genoeg aan (zo is het bestand wat ik quote ook gecompiled)

code:

CFLAGS = -mmcu=attiny2313 -g -Os -Wall

De optimalisatie die jij aangaf heb ik dus ook al.
Verder zijn de operands voor de shiftfunctie die jij gebruikt constanten. Ik gebruik variabelen, en hoewel het dan iets groter word, verwachtte ik niet veel meer dan

code:

   mov r_temp,r_matrixpos
   inc r_temp
   ldi r_temp2,0
   sec
loop:
   rol r_temp2
   dec r_temp
   brne loop

(en dan kan het vast nog wel kleiner)

[ Voor 52% gewijzigd door Sprite_tm op 21-07-2006 23:13 ]

[SlinkingAnt]

Ik zal er morgen eens een blik op werpen, iig vind je hierrrr mijn Makefile (voor WinAVR). Zou je jouw code eventueel online kunnen zetten/emailen? Dan kan ik s kijken wat die hier doet

[Kaj.]

wwwhizz schreef op vrijdag 21 juli 2006 @ 10:35:

offtopic:
'is verhuisd' is met een d

Wat een leuk en moeilijk projectje, jammer dat er een week niks aan gebeurd.

En hier is gebeurt met een t.

Tof project inderdaad, maar het heeft gewoon even tijd nodig.

[Shuisman]

Ik ben eigenlijk wel benieuwd hoe je de tijd gaat bijhouden ? Blijft hij aan de computer? Gebruik je de interne frequentie, lichtnetfrequentie? Ik probeer het nu namelijk met een atmega32 en een interrupt timer, de interne frequentie alleen die kristallen zijn niet ZO betrouwbaar als ik gehoopt had

[Sprite_tm]

SlinkingAnt: De code.
Wat het zou moeten doen is langzaam maar zeker de rijen van de matrix afscannen. Wat het doet is na 3 seconden de eerste rij laten branden... en dat is het.

SHuisman: Ik zag je andere topic jah In principe zou de afwijking van kristallen in het ppm-bereik moeten zitten, dus nofi maar ik ga er gewoon vanuit dat er iets fout zit met je code en het in de eerste instantie gewoon met een kristal proberen. Mocht dat niet werken heb ik Vast Nog Wel ergens een RTC-chippie liggen.

[ Voor 7% gewijzigd door Sprite_tm op 22-07-2006 08:27 ]

[Sprite_tm]

* Sprite_tm neemt een aanloop en trapt het topic omhoog
Update: nieuwe code, aansturing display, fade-routine, random-generator
Nieuwe code
Ik heb eindelijk een beetje tijd gevonden om verder te gaan met de ild-klok die een tijdlang op mijn buro heeft liggen te verstoffen. Zoals ik hierboven al deed blijken, vind ik C voor de AVR niet meer wat en ben ik opnieuw begonnen met de firmware in assembly. Gelukkig had ik nog niet zoveel, erg veel tijd ben ik niet kwijtgeraakt; zeker voor de ervaring die ik ervoor teruggekregen heb is 't een goede bezigheid geweest Door assembly te gebruiken weet ik ook zeker dat ik wat andere features in kan bakken die de l33tness van het geheel zeker positief doen worden

Display-code
Ik ben begonnen met de display-routine. Op zich een vrij rechttoe-rechtaan stukkie: je scant de 6 outputs af. Als je bij output n bent haal je de displaydata op en voor elke output die aan moet staan zet je zowel in ddrb als portb een bit aan. Verder zet je in ddrb de n'de bit aan en in portb de n'de bit uit.
De display-data haal ik uit het SRAM, waar het in 6 bytes staat. (aka de framebuffer)

Fade-routine
Nadat ik de display-routine bekeken had, viel het me op dat de routine op zich wel heel vaak het display aanstuurde: met het 20MHz-kristal wat ik er ondertussen aangehangen heb draaide het programma prima als ik met een refreshrate van 1,5KHz het display aanstuurde. Da's weer een voordeel van assembly: als je er even wat moeite insteekt kan je bijvoorbeeld code die weinig uitgevoerd word aanpassen om zo code die vaker gedaan word razendsnel te maken Omdat de displaycode 15 keer zo snel is als de verversingsfrequentie waarop ik het display uiteindelijk wilde hebben draaien (namelijk 100Hz) zag ik mogelijkheden... wat als ik nu per cyclus van 16 verversingen n keer framebuffer1 en (16-n) keer framebuffer 2 liet zien? Door n te varieeren tussen 0 en 16 kan je dan faden tussen 2 framebuffers. Zo gezegd, zo gedaan, en na wat prutsen had ik een faderoutine geschreven. (Voor diegene die naar de code kijken: het beslissen welke framebuffer geshowed moet worden gebeurt op een op het eerste gezicht nogal op een rare manier: per row en met vergelijkingsfactor die per row 15 verschuift. Dit is omdat het op deze manier minder geknipper geeft; basically diepere magie die ik vanuit mijn werk opgepikt heb (gecombineerd met een foutje zie ik nu, dat poets ik later wel weg) )

Random-number-generator
Een van de belangrijkste dingen van de ILD-klok is een random-number-generator. We werken hier niet met cryptografische shit, dus de rng hoeft alleen op het oog random te zijn en kan dus lekker simpel wezen. Een snelle Google kwam aanzetten met deze pagina, waar dit opstond:

We use the following primitive polynomial in our machine:
x15 + x + 1

This equation tells us how to generate the new bit from the 16 bit register. Let the bits be numbered starting b0 from the right to b15 at the very left. The new bit is simply b15 ^ b1 ^ b0. The old contents of the register is shifted to the left once and then this new bit is added to becomes b0. This operation is performed eight times to get a new word (8 bits). Procedure get_random performs the above operations.

Dat was genoeg info: zonder hun code verder te bekijken heb ik dat geimplementeerd.

Alles samen
Het programma wat ik nu heb voegt alle drie de stukken code samen: er word om de 5 seconden naar een ander, random gegenereerd, beeld gefade't. Pics zijn niet echt nuttig, een filmpje des te meer.

ToDo: klok-logica, rtc programmeren

Mochten mensen nog ideeen hebben over hoe snel en compact de random-lijkende patronen vanuit de huidige tijd te genereren, giltumaar. Dat is namelijk iets waar ik zelf nog niet uitben.

Edit: Oepsie, vergeten: de source is hier down te loaden.

[ Voor 7% gewijzigd door Sprite_tm op 06-08-2006 11:48 ]

[Ricvdp]

Sprite_tm schreef op zaterdag 05 augustus 2006 @ 23:28:
knip
(Voor diegene die naar de code kijken
knip

Welke code?

[kluyze]

Ben effe aan het brainstormen geweest

Sprite_tm schreef op zaterdag 05 augustus 2006 @ 23:28:
[...]

Random-number-generator
Een van de belangrijkste dingen van de ILD-klok is een random-number-generator. We werken hier niet met cryptografische shit, dus de rng hoeft alleen op het oog random te zijn en kan dus lekker simpel wezen. Een snelle Google kwam aanzetten met deze pagina, waar dit opstond:

[...]

Mochten mensen nog ideeen hebben over hoe snel en compact de random-lijkende patronen vanuit de huidige tijd te genereren, giltumaar. Dat is namelijk iets waar ik zelf nog niet uitben.

In c is het gewoon ergens dat die een getal genereerd vanuit een bepaalde standaard tijd dacht ik
Een leraar heeft zo eens iets verteld.

C:

srand(time(NULL));     //vergelijkt met een bepaalde tijd
rand();
j = (rand()*35/RAND_MAX);     //geeft voor j een random getal tussen 0 en 35

zonder die eerste regel geeft die niet echt een mooi random getal.

Misschien dat je dat ergens kunt maken. Dus ergens de tijd vergelijken sinds hij opgestart is of zo. Of ten opzichte van een vaste tijd, (bv vandaag 12u) en daar dan een bewerking mee maken zodat die een random getal geeft. In een rtc kan je toch meestal een alarm tijd inzetten. Kun je daar dan niets mee?

[Sprite_tm]

Kluyze: Dank voor het meedenken, maar een random-number-generator heb ik al, en de limiet tussen 0 en een bepaald getal te leggen zou ook geen probleem moeten zijn Het is meer: hoe kies ik, als ik weet dat ik 3 rode leds moet laten branden, uit welke leds moeten gaan branden.

Ricvdp: Oeps... Nja, pobody is nerfect Ik heb 't erbijin geedit.

[ Voor 11% gewijzigd door Sprite_tm op 06-08-2006 11:50 ]

[kluyze]

Ah zo, verkeerd begrepen Opnieuw brainstormen dan.

Je zou als je 3 leds moet laten branden 3 random getallen kunnen laten genereren, maar of het dan echt compact wordt. Ligt er een beetje aan hoe lang die er over doet om die getallen te genereren.

Nog wat meer brainstormen, misschien dat er nog een idee uit de kast komt. Ik laat nog van me horen.

[Verwijderd]

Hmm, dat algoritme is wel een leuke ja. Hier is iig een werkend stukje code, maar ik denk inderdaad dat er wel snellere manieren mogelijk zijn.

C:

int led_mask = 0x00;
byte leds_total = 9;
for (byte i = 0; i < leds_on; i++) {
    byte led_next = rand() * (leds_total - i);
    for (byte j = 0; j < led_next; j++) {
        if ((led_mask & (1 << j)) > 0)
            led_next++;
    }
    
    led_mask |= (1 << led_next)
}

De code spreekt op zich voor zichzelf: elke outer loop wordt een random getal tussen 0 en (totaal aantal leds - aantal gekozen leds) (exclusief) gekozen, wat dus aangeeft welke led nu nog aan moet. Het probleem is alleen dat dit getal het aangeeft zonder de leds die al aan zijn mee te tellen, waarna met de inner loop wordt gekeken welke leds al aan zijn, zodat led_next gecompenseerd kan worden.

[edit]
Een alternatief is natuurlijk om gewoon een lookuptable te gebruiken (voor de 9 leds kost het je dan 1024 bytes (helaas net niet genoeg aan 8 bits) aan ruimte. (source)

@hieronder: dat is dus met bovenstaande 2 oplossingen niet het geval, aangezien hij niet blijft loopen tot ie toevallig op dat ene getal uitkomt.

[ Voor 20% gewijzigd door Verwijderd op 06-08-2006 14:08 ]

[Sprite_tm]

Mmm, bij alle makkelijke oplossingen kom ik op het probleem dat de random number generator wel 100% zeker alle mogelijkheden moer 'raken'... stel je voor, ledje X moet voor een bepaalde configuratie nog branden en de RNG komt nooit op waarde X, dan hangt de unit. Ik denk dat ik mijn RNG maar eens daarop ga testen.

[Sprite_tm]

Ik maak d'r meteen maar weer een update van:
Update: De random number generator
De makkelijkste manier om random led-sequences te genereren berust in de basis op het feit dat we random nummers trekken en kijken of het nummer wat we getrokken hebben voldoet aan een bepaalde regel, zoniet trekken we nog een nummer en kijken we weer. Dit principe kan echter alleen werken als we zeker weten dat na X keer trekken, daadwerkelijk een nummer wat de eisen voldoet langskomt; zoniet dan blijft het programma tot in de oneindigheid nummers trekken.

Daar ik de random number generator uit een niet al te professionele bron getrokken heb ben ik 'm maar eens gaan testen. Ik heb een PHP-bestandje geschreven wat 64k aan random getallen trekt en bijhoudt hoevaak elk getal getrokken worden. Het resultaat met de oorspronkelijke RNG blijkt belabberd te wezen. (eerste kolom: getal, tweede kolom: hoe vaak het getrokken is. Geen entry = nooit getrokken)

Uit ervaring weet ik dat het idee van dit soort binaire shift- en xor-operaties op zich wel goed is, de poynoom is echter blijkbaar slecht gekozen. Op puur geluk heb ik de code aangepast van X¹⁵+X+1 naar X¹⁴+X+1. Dit heeft weliswaar als nadeel dat de reeks getallen zich elke 32K herhaalt ipv elke 64K keer, maar da's voor deze toepassing niet zo boeiend. Na het draaien van het scrippie bleek het resultaat erg mooi te zijn, het geheel is zelfs uniform verdeeld (elk getal heeft evenveel kans langs te komen). De getallen lijken nog steeds op het oog erg random te zijn:

code:

103,50,33,18,214,147,156,144,132,148,164,155,36,142,
219,67,142,80,189,148,248,155,244,143,228,191,219,0,
113,85,233,152,55,117,30,25,125,118,6,29,93,121,134,8,162
(etc)

Ik ga dus het polynoom ook in de assembly-source aanpassen, dan weet ik iig zeker dat de rng wel goed zit

[ Voor 4% gewijzigd door Sprite_tm op 06-08-2006 14:36 ]

[madwizard]

Een vrij simpel algoritme dat geen eisen stelt aan je RNG, en volgens mij erg lijkt op die van Emiel is als volgt (per kleur):
Je maakt een array in je ram met 1 byte per LED. In het begin (bij opstarten) vul je deze array met 0,1,2,enz. Deze waardes geven LEDs aan. Stel dat je nu x LEDs aan wilt hebben. Voor de eerste LED neem je een random nummer tussen 0 en de hoogste index (elke index uit de array dus). Je leest de byte uit op die index en gebruikt dat als LED nummer. Verwissel dan de bytes in de laatste array index en de index die je random gekozen had. Het nummer van de LED die al aan staat dan dus helemaal achteraan in de array. Voor de 2e LED doe je hetzelfde, maar doe je alsof de laatste index niet bestaat. Je kiest dus random uit de array, op de laatste index na. Ook daar lees je weer de byte uit die het LED nummer voorstelt en zet die LED aan. Daarna verwissel je die byte met de (nu) op een na laatste index.
Het klinkt wat ingewikkeld in deze beschrijving maar als je het snapt is het vrij simpel, en de implementatie stelt ook weinig voor (pseudo code):

C:

max_idx = aantal_leds - 1;
for (i=0;i<x;i++)
{
    nr = random(max_idx);
    // zet led arr[nr] aan
    swap(arr[nr], arr[max_idx]);
    max_idx--;
}

edit: Je kunt de array voor de volgende ronde gewoon zo laten, als het goed is wordt er toch random gekozen en maakt de initiele staat van de array niet uit zolang alle LED nummers er maar in staan. En dat blijft zo.

[ Voor 7% gewijzigd door madwizard op 06-08-2006 14:53 ]

[Sprite_tm]

Update: Individuele leds mappen
Het is eigenlijk geen update waard, maar ik moet toch een post hebben om een link naar de code in te plaatsen: Ik heb vanavond even de routines geschreven die 'zet-het-nde-ledje-van-die-kleur-aan' kunnen doen. Lang verhaal kort: Je hebt een hoop .dbs in de code die 2 keer een bitnummer aangeven: de eerste van het portb-pinnetje dat hoog, de andere van het pinnetje dat laaggemaakt dient te worden om het ledje aan te laten gaan. Het leuke ervan is dat het op deze manier makkelijk configureerbaar is: mocht je besluiten mijn ontwerp na te willen bouwen maar je wil de leds compleet anders door elkaar hebben zitten, kan dat door die .db-regels even aan te passen.

De reden dat ik de code vrij wil geven is dat 'ie erg practisch is: er zit namelijk ook een testroutinetje in wat de leds een voor een laat aangaan. Op die manier kan je controleren of je je .db's wel goed hebt, en bovendien zijn losse contacten makkelijk te spotten: als inplaats van een enkele led meer leds aangaan weet je dat er ergens iets loszit.

Ik denk dat ik als random-aanzet-routine een derde alternatief ga pakken: Maak een lijstje van evenveel bytes als je leds van een bepaalde kleur hebt, vul die met random getallen en pak dan de n hoogste eruit. De index in de lijst geeft aan welke led je aan moet hebben. Er is een kans dat de randomness verstoord word doordat 2 plaatsen hetzelfde random getal hebben, maar die is te verwaarlozen imo.

[kluyze]

Misschien wat laat maar iemand op CO had een geweldige manier om iets random te laten verlopen.
Daar ging het wel om 1 bit. Maar het ging om het idee.

Als je externe invloeden het random gedrag van de schakeling laat bepalen.
Uitleg:
Stel je neemt een lichtsensor/geluidsensor/... waar je de DC component gaat afhalen, dat signaal ga je dan versterken voor de analoge ingang van de µC. Door dan het verschil in licht/geluid/... ga je dan een redelijk goed random getal verkrijgen.

Als je dan ook nog ergens een combinatie van meerdere externe invloeden neemt dan gaat het waarschijnlijk nog meer random worden.

Ik weet dat je al code ervoor hebt, maar ik vond het eigenlijk te mooi om hier niet te vermelden. Ik moest toen onmiddelijk aan dit project denken.
En ik vond het futuristisch genoeg om aan de ILD klok te hangen.

[Sprite_tm]

Hmm, het plan was om er uiteindelijk een LDR aan te knopen... daar kan in ik principe wel de laatste significante bit terugstoppen in de random generator, weer ik helemaal zeker dat ik geen repeterende patronen heb

[Verwijderd]

Sprite_tm schreef op donderdag 10 augustus 2006 @ 07:58:
Hmm, het plan was om er uiteindelijk een LDR aan te knopen... daar kan in ik principe wel de laatste significante bit terugstoppen in de random generator, weer ik helemaal zeker dat ik geen repeterende patronen heb

Het kan nog simpeler, de ruis uit een weerstand is wit, dus totaal geen correlatie, en dus compleet random, heb je geen ldr voor nodig.. (of het moest zijn dat je die nog had liggen...)

[Sprite_tm]

surge_me: Klopt, maar je hebt wel een unit nodig om die ruis te versterken, en dat zou betekenen dat mijn schakeling toch wel 2 keer zoveel chips gaat tellen Dit doet het ook prima, zoals gezegd hoeft het niet statistisch perfect te wezen.

Update: N random leds laten oplichten
Weer een kleine update: ik heb het algoritme wat onderaan de vorige update staat, geimplementeerd. Ik ben dezer dagen moe omdat ik in de vakantie fulltime werk, en ik kan het wel merken: bij wat lastiger code vliegen de off-by-one-fouten, de breq ipv brne (zeg maar de assembly-equivalent van != ipv ==), de teller-in-de-loop-vergeten-op-te-hogen etc me om de oren. Kwam ook nog bij dat ik een condootje aan de voeding van mijn prototype heb moeten hangen; ergens door reset de microcontroller bij een bepaalde operatie als ik die er niet aan heb hangen.

Nja, na veel plussen en minnen is dan toch de code die een vast aantal willekeurig gekozen ledjes aan kan zetten af. Het ding is zo opgezet dat het voor alle drie de kleuren kan, geen copypeest-code dus. Het effect ervan is in dit filmpje te zien: er branden continue 4 rode, 2 groene en 3 gele leds. Voor de geinteresseerden: de code is hier te zien.

Nu is het basically alleen nog maar de RTC implementeren, een methode verzinnen om de RTC in te stellen, een mooie voeding en behuizing maken en klaar is Sprite. Van die 4 ToDo's zie ik alleen problemen bij de laatste: ik heb eigenlijk nog een idee voor een ueber-leete behuizing nodig die niet teveel mag kosten. Jullie nog suggesties?

[TommyboyNL]

Ikzelf zit ook altijd met het behuizing probleem Wat ik zelf in gedachten had als behuizing voor mijn binaire LED klok was plexiglas met pooierfolie (spiegelfolie dus ) aan de binnenkant. Alleen maar een gat voor de voedingskabel nodig dan, het LED licht schijnt dwars door de folie heen. Je ziet echter zo goed als niks van de andere meuk die er in zit (als het goed is dan ).
Behuizing moet ik echter nog maken, maar dit kan niet, omdat mijn vaste plexiglas leverancier (kan ik overkopen voor inkoopprijs) met vakantie is.

[Ricvdp]

TommyboyNL schreef op woensdag 16 augustus 2006 @ 02:17:
Ikzelf zit ook altijd met het behuizing probleem Wat ik zelf in gedachten had als behuizing voor mijn binaire LED klok was plexiglas met pooierfolie (spiegelfolie dus ) aan de binnenkant. Alleen maar een gat voor de voedingskabel nodig dan, het LED licht schijnt dwars door de folie heen. Je ziet echter zo goed als niks van de andere meuk die er in zit (als het goed is dan ).
Behuizing moet ik echter nog maken, maar dit kan niet, omdat mijn vaste plexiglas leverancier (kan ik overkopen voor inkoopprijs) met vakantie is.

offtopic:
kun je wat info geven over je binaire LED klok? Ik ben ook van plan een binaire LED klok te maken, met een uC, wss een attiny2313 of een PIC16F628A. Wat gebruik je om de goede tijd te weergeven?

[TommyboyNL]

offtopic:
Als uiterst accurate tijdsbasis gebruik ik het lichtnet. Een kleine antenne bij de trafo, gekoppeld aan 2 stuks 4017 (ingesteld als 50-deler), waardoor ik een 1 Hz puls krijg. Deze voer ik vervolgens (via via) aan 6 stuks 4510 (binaire 10-teller), met hier en daar een of-poortje (4081) voor resets van bepaalde ICs bij bepaalde waarden.

[Ricvdp]

offtopic:
analoog dus, maar laten we sprite's mooie topic niet vervuilen, als je wil reageren, doe dat ff via een DM, en zet dan gelijk DM's aan.

[Sprite_tm]

Update: We hebben een RTC, meer ILD

Ik ben gister en vandaag bezig geweest een RTC (Real Time Clock) te programmeren. Lang verhaal kort: Ik gebruik timer1 om om de 256*15625 kloktikken een interrupt te genereren, dat komt uit op precies 5 keer per seconde. In de interruptroutine worden dan de 1/5e seconden, seconden, eenheden minuten, tientallen minuten en uren bijgewerkt, en zo heb ik in mijn hoofdprogramma mooi de tijd in een stel registers tot mijn beschikking zonder dat ik daar verder wat aan hoef te doen. Die variabelen worden dan gevoerd aan het routinetje wat ik in de vorige update gemaakt heb en al met al heb ik een basic klok. Hij is echter nog niet helemaal af; een manier om de tijd in te voeren is er niet: die moet door middel van een tijd hard te coden en het geheel op het juiste moment van power voorzien, ingevoerd worden. Het is echter genoeg om te kijken of het geheel werkt en of het bevalt. Ik ga het spul zowiezo een dag laten werken, om te kijken of er misschien fouten in de routine zitten die de tijd fout laten lopen. De code is natuurlijk weer te downloaden btw.

Verder heb ik nog eens over een behuizing lopen nadenken, en ik bedacht me dat het ILD-idee nog wel wat verder uitgemolken kon worden door random electronica aan het geheel te solderen:






Het idee is geinig, ik moet het allemaal nog even aankijken of ik het echt zo ga houden. Als ik hiermee doorga ga ik waarschijnlijk het geheel in epoxy ofzo gieten, zodat het nog l33ter word, als een soortement stuk eeuwenoud elektronica gevangen in barnsteen Ik heb alleen geen flauw idee waar ik epoxy vandaan moet halen of hoe het te verwerken is...

[DP Kunst]

is resin anders geen idee om t in te gieten, net als die jamesclar. of kaarsvet

t idee vind k iig super, is weer eens iets anders als een standaard klokje

[naftebakje]

Mijn grootvader is/was kunstenaar, en heeft nog beeldjes zo ingegoten. Als ik hem eens zie (eigenlijk moet ik studeren voor mijn herexamens, dus het kan wel ff duren) zal ik vragen waar hij dat gehaald heeft, volgens mij kun je dat in de betere kunstenaarsbenodigdhedenwinkel krijgen (er was er hier een in de buurt, maar die is al een tijdje dicht). Volgens mij was dat gewoon een deel giethars en een deel verharder (polymerisator, moeilijk woordje om vrouwen mee te imponeren ), door elkaar mengen en je hebt 15 minuten om alles te gieten.

[Xiphalon]

houd er wel rekening mee dat bij het uitharden van epoxy er veel warmte vrijkomt, weet niet of elektronica dat leuk vindt...
Hoe heet precies zou ik zo niet kunnen zeggen, maar je krijgt wel brandwonden van in 15 minuten uithardende epoxy.
't spul wat in 24 uur uithardt wordt minder warm.

Zoek ook een hars wat nog een beetje elastisch is na het uitharden, anders overleeft je klokje het niet. En denk aan de warmtegeleiding!

Als je gaat gieten, doe dat dan in dunne laagjes, zodat je geen luchtbellen krijgt.

Ciba en 3M maken epoxyhrsen, zou zo snel niet weten waar je ze kan krijgen.

[jeronimo]

Ingietmaterialen zijn te verkrijgen bij: http://www.polyservice.nl/index.html

[Sprite_tm]

Dank voor de hints; ik zal komende week eens bij hobbywinkels en als dat goedkoper is ook bij websites rondsnuffelen. Verder nog even een update'tje op de code die nu draait: in 2 1/2 dag loopt het klokje nu ongeveer 2 minuten voor. Dat foutpercentage komt ongeveer overeen met hetgene wat een off-by-one-fout in de timer compare value zou geven, dus ik moet me een dezer dagen maar eens inlezen in wanneer timer1 nou daadwerkelijk z'n interrupt afschiet, ik denk dat ik daar ergens iets verkeerd begrepen heb.

[Verwijderd]

Is zoiets wat die japanners in de jaren 80 hadden gemaakt, kan alleen de link niet 1,2,3 vinden. Was een horloge maar moest je op een vreemde manier de tijd aflezen. Ook met rood,groen,gele ledjes.

[Verwijderd]

Je zou ook voor een 6*6*6 kubus kunnen gaan

Any howz, weer een heel gaaf idee

[SA007]

6x6x6 is 216 leds, ik zou 3x3x3 pakken, dat zijn er 27

Idd leuk idee, als ik thuis ben ga ik dat 's wat uitwerken, nog grotere ILD factor

[Sprite_tm]

Volgens mij gaat dat helemaal onleesbaar worden Mijn 2D-unit is al niet heel makkelijk af te lezen...

[SA007]

Goed punt, maar toch, een ILD is niet bedoelt om daarwerkelijk erg nuttig te zijn, klokken zat toch.

[kluyze]

Maar de klok heeft ook een zekere pats factor, en hoe kun je nu je vrienden er mee versteld doen staan als je het zelf niet kunt uitlezen of een uur nodig hebt.

Hoe zit het nu eigenlijk met de behuizing? Ik was laatst aan het denken aan iets glibberig je weet wel van die engelse pudding, gelatine. Natuurlijk iets vaster en niet zo eetbaar. Maar dat je bij aanraking het wat ziet na sidderen

[Sprite_tm]

Mmm, je zou het in kunnen gieten in siliconenkit; afaik blijft dat een zekere glibber-factor houden. Jammer alleen dat het niet 100% doorzichtig opdroogt; het word wit-achtig.

[naftebakje]

Sprite_tm schreef op vrijdag 25 augustus 2006 @ 12:25:
Mmm, je zou het in kunnen gieten in siliconenkit; afaik blijft dat een zekere glibber-factor houden. Jammer alleen dat het niet 100% doorzichtig opdroogt; het word wit-achtig.

Heb je het nu over witte of transparante siliconenkit? AFAIK is transparante siliconenkit glashelder (zolang je het niet te dik legt, 1 cm dik moet wel nog helder genoeg zijn imho).

[Sprite_tm]

Transparante jah. Ik heb thuis nog wel een tube liggen, ik zal het wel showen. Als het idd doorzichtig genoeg is is het ook nog een optie om het daarin te gooien: siliconenkit heb ik, epoxy moet ik moeilijk voor doen

[SA007]

Siliconen is alleen niet zo vloeibaar, dus echt gieten valt tegen, je moet er druk achter zetten om geen luchtbellen te krijgen, en je moet blijven bijgieten tijdens het drogen, anders krijg je geen mooie vorm. (en dan nog is het niet perfect)

Goede giethars krimpt minder (hard eigenlijk alleen uit)

[Ricvdp]

Sprite, hoe staat het inmiddels met je project? Ik ben van plan een klok te maken, alleen dan in BCD weergave (aka binary clock), en dit project is wel heel handig om te kijken hoe jij bepaalde dingen oplost (fade, random (al is dat voor mij niet echt aan de orde) etc.). Ik twijfel of ik een PIC16F628A of een Attiny2313 ga gebruiken, als ik de PIC pak schrijf ik het sowieso in ASM, als ik de AVR pak wil ik C wel eens proberen voor de AVR (met C georienteerde talen heb ik wel veel ervaring, met asm ook wel wat overigens). Wat raad je me aan?

Eerst wou ik de netfrequentie gebruiken als tijdsbasis, maar iemand gaf mij deze link:
http://www.romanblack.com/one_sec.htm
Ik denk dat ik dat beter kan gebruiken.

[ Voor 13% gewijzigd door Ricvdp op 10-10-2006 21:05 ]

[Sprite_tm]

Woei, fans Het project ligt atm een beetje in een hoekje te liggen het idee is wel om 'm een keer af te maken, maar dan moet ik eerst wat andere zaken afgemaakt hebben. Als je een AVR pakt, ligt het een beetje aan welke controller je target of je C of asm wilt doen; zoals je hebt kunnen lezen heb ik in dit topic wat slechte ervaringen met C opgedaan maar het kan zijn dat ik net pech had.

Ik ben zelf nog steeds van plan om een standaard timer te pakken als secondenteller: met de 16-bit timer van de ATTiny kan je genoeg. Als je een klok van 20MHz pakt, kan je bijvoorbeeld een prescaler van 64 pakken en je timer instellen op een compare&reset-value van 31250, als je daar dan een interrupt aanknoopt heb je als het goed is een interrupt die tien keer per seconde afgaat. Gooi in die routine een tellertje die tot 10 telt en je hebt je 1Hz-signaal.

[Ricvdp]

Hù? Je had er toch een RTC aan gehangen? Maargoed, is die timer een beetje nauwkeurig? Ik wil het sowieso aan het begin wel zo gaan doen idd, maar als het niet goed blijkt te lopen wil ik dat implementeren wat ik in die link gaf..