verlichtingsschakeling voor kunstwerk

Die voeding heb ik enkel aangehaald als reden waarom ik het geheel niet als "effe een tegelmat ergens neerploffen" zag. Aan de zijkant is geen probleem zoals ik al zei. En zoals Sparky zei om op te splitsen zal niet zorgen voor minder kabels of minder grote stromen die door de eind tegels zal moeten.

Op 5 juni 2009 13:58:20 schreef Lucky luke:
Bij game of life:
Tegel verzend een fadewaarde hoger dan 128: leven
128 of lager: dood
Maar hoe bepaald de ontvanger van welke tegel het afkomt? 'n mode maken waarin je van tegel left,right,up,down de fadewaarde op kan vragen?
dode tegels faden naar 0 of blijven 0
levende faden naar 255 of blijven 255
zoiets?

Elke tegel hoeft enkel te weten hoeveel levende tegels hij naast hem heeft, verder niets. Elke tegel stuur dus gewoon om de 500 ms ofzo, naar zijn buren of hij leeft of niet. Elke tegel ziet daardoor hoeveel leven er rond hem is.

[edit]
Voor vlek-attack, ik denk dat het weer op hetzelfde neer gaat komen als het feit dat je niet makkelijk een cirkel kan laten uitfaden. Verder heb je een vectorveld nodig dat zichzelf zonder expliciete functie kan opbouwen. En je zal 4 verschillende waardes moeten bijhouden om de richting van het veld te zelf te weten en je zal 4 verschillende waardes naar je buren moeten sturen, voor elke buur een andere. Hoe het veld zich zal verspreiden vertrekkend vanuit 1 punt.. zie ik weeral vierkante countour lijnen ontstaan, misschien is dat wel geen erg, de vlek zal zich wel naar het centerpunt kunnen trekken. De vlek zal in elk punt 2 mogelijke trajecten kunnen kiezen de voor hem als gelijk gezien worden. Behalve op de diagnalen. Het kan dus zijn als je random 1 van de 2 richtingen kiest dat de vlek bvb eerst naar de juiste x positie gaat tot op de diagonaal en dan rechtstreeks naar het center gaat.
(in een uC die totaal overzicht heeft kan het vectorveld f(x,y) direct berekend worden, in elk punt zie je dan direct welke weg het beste met de realiteit overeen komt )

Op zich heeft Plantrekker naar mijn idee helemaal gelijk dat de distributie van de voeding niet gaat werken door gewoon alles door te verbinden en op 1 punt te voeden, maar het lijkt me een vrij eenvoudig probleem, wat op te lossen is door het geheel vanuit een groter aantal punten te voeden, en op strategische plekken de pinnen voor het doorverbinden van de voeding af te knippen. De voeding staat eigenlijk helemaal los van de communicatie, software etc., dus daar wil ik me nu eigenlijk helemaal niet zo druk om maken. Eerst maar eens zien dat de hardware en software gaat werken, en dat er daadwerkelijk iemand is die een bom duiten neer wil leggen voor zo'n vloer.

@Lucky Luke: ik heb ook nog niet exact bedacht hoe die effecten geïmplementeerd kunnen worden, het lijkt me belangrijk dat er in ieder geval wat ideeën zijn voor effecten, en dat we daar een beetje rekening mee kunnen houden bij de ontwerpkeuzes. Het lijkt me handiger om er eerst voor te zorgen dat er wat controllers zijn die met elkaar kunnen praten.

De communicatie is vrij eenvoudig; alle controllers zetten hun uitgaande bits op de pinnen op de neergaande flank van de klok, en halen de data op hun ingangen binnen op de opgaande flank van de klok. Op die manier zorg je ervoor dat de data nooit veranderd wordt terwijl een controller aan het lezen is.

De klok werd in mijn originele ontwerp ook gezamenlijk gegenereerd. De kloklijn heeft een pull-up weerstand naar de voeding, en de controllers trekken de klok alleen naar beneden (open-collector, dus). Als een van de controllers de klok omlaag trekt, ziet iedereen dat de klok laag is. Pas als alle controllers de klok los hebben gelaten, gaat deze weer omhoog. Op deze manier kan elke afzonderlijke controller de communicatie even ophouden (een soort wait-cycle invoegen) als deze om wat voor reden dan ook nog niet klaar is met het verwerken van de data.

Elke controller start een timer op het moment dat hij de clock van status ziet veranderen. Pas als deze afgelopen is, mag hij zelf zijn uitgang laten veranderen. Op deze manier wordt ervoor gezorgd dat er een minimale tijd is dat de clock hoog en laag zal blijven. Dat deze timers niet exact op hetzelfde moment af zullen lopen, is niet erg; aangezien de bus laag wordt zodra iemand hem laat trekt, en pas hoog wordt als iedereen hem los laat.

Dit systeem heeft een paar voordelen en een paar nadelen; voor mijn schoolopdracht mocht ik alleen identieke controllers gebruiken, en moest het netwerk blijven lopen als het gescheiden werd, en later weer aan elkaar geknoopt. Ik kon daar dus geen centraal gegenereerde clock gebruiken. Een nadeel hiervan, is dat het signaal onbetrouwbaar wordt wanneer het netwerk heel groot wordt; de uitgang van een microcontroller kan niet zoveel stroom sinken, waardoor de pull-up weerstanden groot moeten blijven. Daar komt nog bij dat 1 defecte controller het hele netwerk plat kan leggen, en het heel moeilijk is om uit te zoeken welke dat is, zonder de controllers uit elkaar te gaan trekken.

Het lijkt me in dit geval dus beter om een centrale clockgenerator bij de voeding te zetten. Dit hoeft dan niet meer te zijn dan een blokgolf generator met een leuke driver erachter; misschien is een NE555 al voldoende, aangezien die 200mA kan sourcen en sinken.

EDIT ik werd gestoord tijdens het typen, waardoor het bericht van Plantrekker er nog niet stond toen ik begon.

De bewegingsvector hoeft natuurlijk niet beperkt te zijn tot 4 of 8 richtingen, je kunt vrij gemakkelijk een variant van het Bresenham algoritme gebruiken, waarbij je de vlek, inclusief de parameters, doorgeeft aan de volgende tegel, die met de parameters gaat rekenen, aan de hand daarvan beslist aan welke tegel hij het door moet geven, en dan dus de nieuwe parameters mee doorgeeft. Je kunt elke lichtvlek dan zien als een proces dat van de ene virtuele machine wordt doorgegeven naar de volgende.

Behalve de vector parameters van de vlek, moet je natuurlijk ook informatie hebben over de activiteit in het veld. Elke tegel kan voor elk van zijn 4 buren een waarde opslaan, en aan elke buur een gewogen gemiddelde van alle waarden behalve afkomstig van die buur doorgeven.
Ik noem de tegels even X(self), N(noord), O(oost), Z(zuid) en W(west).
Dus een tegel geeft de activiteitswaarde van ( N * 2 + O + W + X ) / 5 door aan Z. Op die manier propageert de waarde niet alleen in rechte lijnen, maar in een bepaalde mate wordt deze ook uitgespreid. Je kunt dan nog wel spelen met de gewichten en de deelfactor, om te bepalen over welke afstand die waarde af moet nemen, en hoe snel die waarde uitgespreid wordt over een groter gebied t.o.v. een rechte lijn. Elke keer dat er een vlek door een tegel gaat, beslist die tegel aan de hand van de activiteit in zijn 4 richtingen met een kleine factor wat de nieuwe vector moet worden, en samen met de fout factoren beslist hij naar welke tegel hij de vlek moet doorgeven.

Het klinkt nogal ingewikkeld als ik het zo opschrijf, maar volgens mij valt het wel mee. Het Bresenham lijn algoritme is hierbij belangrijk, en de rest is alleen om de informatie over de activiteit een beetje handig door het netwerk te krijgen.

EDIT2 voor The Game of Life hoeft elke controller steeds maar 5 bits informatie te versturen; zijn eigen status, en de status van zijn directe buren. Daaruit kan elke andere controller ook de informatie halen over de diagonale buren, waar hij niet direct mee kan communiceren. Het enige lastige is dat er na elke statusverandering 2 berichtcycli nodig zijn om de informatie op de juist plek te krijgen, aangezien deze door een andere controller moet komen.

Ik weet niet of ik dit duidelijk heb verteld bij de uitleg van de communicatie, maar alle controllers beginnen tegelijkertijd met een bericht, en alle berichten zijn even lang, dus de berichtcyclus eindigt ook voor alle controllers op hetzelfde moment.

EDIT3: ik krijg zo langzamerhand wel het gevoel dat Plantrekker nog steeds vind dat een gedeelde bus met een centrale controller technisch de beste oplossing is, maar dat hij daarin ook alleen staat. Nu moet ik er meteen bij zeggen dat ik het ook leuk vind als een idee wat ik heb aangedragen wordt gebruikt hoor, maar naar mijn idee hebben beide systemen technische voor- en nadelen, en hebben we die al besproken. Hier zijn echter meer argumenten van toepassing dan alleen de technische, aangezien het een kunstzinnig project is, en ik geloof dat de consensus tussen Scotch, Lucky Luke en mijzelf is dat de losse tegels met beperkte informatie wat dat betreft leuker / beter is dan een dictator met een veld vol onderdanen.

Het is echt niet dat ik mijn gelijk wil halen, en ik waardeer je input zeker, maar ik denk dat het een beetje zinloos is om alsnog te proberen een enkele gedeelde bus door te drukken. Ik hoop dat je je niet aangevallen voelt, want dat is geenszins mijn bedoeling.

Ik ga later nog die post van sparky doorspitten en op losse dingen reageren, maar wil nu vast dit kwijt:

Er mag dan hoogstwaarschijnlijk geen bus master komen, een soort bedienings-iets* aan de zijkant is misschien wel handig (om mee in te stellen wat de tegels moeten gaan doen: stampmodus, burenmodus, vlekatack, vluchtvlek, Life, Mozes etc..

(*=de I.E.T.S module: Insteller En Transport Starter. Een kastje waarop je kunt kiezen in welke modus de tegels gaan werken, waarmee tevens het datatransport gestart wordt) _{naar analogie met de N.E.R.D van CanSat: Noise Emitting Retrieval Dinges}

Verder: zullen we het voor het gemak even bij 1 kleur houden? Scotch akkoord?

Mozes kan dan met zwart (geen licht) op geel.

En uhm , wiens project is het eigenlijk? Al die ideeën <kijkt sparkyGSX streng aan> zijn leuk, sparkyGSX, maar wie moet ze eigenlijk verzinnen? <kijkt Scotch streng aan>, want wie krijgt er studiepunten voor?
(niet boos of naar bedoeld, maar zitten we (ik inclusief) niet een beetje te veel voor te kauwen, onze eigen ideeën in Scotch project te verwerken, of op zijn minst vér op de zaken vooruit te lopen?)

Ik voel mij niet aangevallen

Maar de meeste van mijn argument werden telkens afgewimpeld, of kregen reacties niet to the point en zo gingen die argumenten dan te niet of werden die niet als voordeel tegenover het huidige systeem gezien. Zoals dat er per effect nieuwe algoritmes zouden moeten bedacht worden. Dat er delays zouden optreden in bepaalde gevallen en dat je er dan telkens rekening mee zou moeten houden. Dat het lastig ging worden om met verdere buren te praten. Reactie: "maar waarom wil je dat?" enz.. Het kwam er telkens op neer dat het geen nadeel zou zijn. Het geeft allemaal beperkingen, waarop weer de reactie "waarom zou dat niet zonder bus kunnen?" Nu zie ik toch veel van die dingen naar boven komen.

Het was al van helemaal bij het begin wanneer ik aankwam met "doe het met uC, hang er RGB LED's aan, laat ze communiceren met elkaar en maak golfeffecten" Toen was het telkes, analoog is eleganter... De voordelen en mogelijkheden werden toen ook niet erkend. Tja op die manier denk ik niet dat iedereen hier een juist beeld krijgt van voor- of nadelen. Hiermee wil ik zeker niet verder srtijden, had mij er al bij neergelegd.

@Plantrekker: Tja, het is soms niet te voorspellen hoe zoiets gaat evolueren.

In het begin werd er ook nog niet gesproken van grote vlakken, en ging het om een stukje elektronica wat een LED kon laten branden als er iets ingedrukt werd. Ik vind de analoge oplossing ook nog steeds erg elegant, maar de microcontrollers bieden gewoon veel meer mogelijkheden voor interessant gedrag.

Ik zag (en zie) zeker wat problemen i.v.m. de schaalbaarheid bij een gedeelde bus, maar (en dat vind ik zelf nog veel belangrijker) zonder centrale besturing vind ik het veel eleganter, en kun je het geheel gaan zien als een groot aantal domme dingen met een heel beperkt waarnemingsvermogen.

@Lucky Luke: aan de ene kant heb je daar gelijk in, aan de andere kant kan ik er weinig aan doen. Als ik over zoiets na ga denken, krijg ik vaak wat wilde ideeën, en die moet ik dan opschrijven. Uiteindelijk zal Scotch zelf moeten beslissen wat hij wil gebruiken en wat niet.

Een groter probleem zie ik in de implementatie; ik denk dat dit Scotch een flink eind boven zijn pet gaat (met alle respect hoor).

@ sparky

prima dat je met me meedenkt, ik heb ook altijd ideeen als ik met medestudenten meekijk. Zou je dat niet zus of zo doen, daar kan je ook dat mee, etc... Lijkt me een goede eigenschap.

Bedankt voor alle respect wat betreft implementatie ;0, proefmodel moet toch wel lukken denk ik. Maar ik ben vrij optimistische ingesteld

@ lucky luke
voor het proefmodel is een kleur en het bassis effect het uitgangspunt. Ik wil me daar nu eigenlijk eerst op focussen.

Bedieningstegel wil ik er zeker in hebben.

@ plantrekker

Ik doelde eigenlijk meer op de implementatie van de software; dat je zo'n microcontroller op een printje kan solderen en de rest daar omheen goed aan kan sluiten met wat duidelijke aanwijzingen, daar twijfel ik niet aan.

het ontwikkelen van de software gaat me nu zeker niet lukken idd. Maar de basis configuratie heeft luckyluke natuurlijk al gemaakt. Verdere ontwikkeling is een latere zorg.

Dat wordt pas relevant als iemand intresse heeft om het uittevoeren.

Maar heb je die analoge uitvoering intussen al aan de gang gekregen?

Goed. There we go. Dit wordt een lange post... (om precies te zijn: ik ben gisteren begonnen met typen, maar werd onderbroken)

Op 5 juni 2009 17:25:59 schreef SparkyGSX:
<Iets wat neerkomt op: voeding is van later zorg, en bovendien niet al te lastig>

Mee eens. Maar plantrekker heeft wel gelijk dat doorlussen geen goed plan is. Nu was ik dat ook niet van plan, eigenlijk... Meer elke 16 tegels eigen voeding, en dan voor mijn part per 4 doorlussen, maar dit alles buiten de eigenlijke tegel om.

@Lucky Luke: ik heb ook nog niet exact bedacht hoe die effecten geïmplementeerd kunnen worden, het lijkt me belangrijk dat er in ieder geval wat ideeën zijn voor effecten, en dat we daar een beetje rekening mee kunnen houden bij de ontwerpkeuzes. Het lijkt me handiger om er eerst voor te zorgen dat er wat controllers zijn die met elkaar kunnen praten.

Mee eens. Laten we eerst een controller en een communicatieprotocol kiezen. Ik denk aan iets met 4k of meer flash, ram boeit niet (is bij dergelijke controllers toch groot genoeg, maargoed: minimaal 128byte dan), EEPROM, mooi meegenomen als er 64 byte of meer in zit, maar dat is meestal toch wel het geval bij de grotere controllers (qua flash). Verder natuurlijk ADC (eigenlijk maar 1 kanaal nodig, maar meer mag natuurlijk, en meestal krijg je gelijk 6 of 8 kanalen) en PWM (lieft 3 kanalen of meer zodat we later wat met meerdere kleuren kunnen maken). Pin change interrupt lijkt me ook handig , zie onder.

De communicatie is vrij eenvoudig; alle controllers zetten hun uitgaande bits op de pinnen op de neergaande flank van de klok, en halen de data op hun ingangen binnen op de opgaande flank van de klok. Op die manier zorg je ervoor dat de data nooit veranderd wordt terwijl een controller aan het lezen is.

De klok werd in mijn originele ontwerp ook gezamenlijk gegenereerd. De kloklijn heeft een pull-up weerstand naar de voeding, en de controllers trekken de klok alleen naar beneden (open-collector, dus). Als een van de controllers de klok omlaag trekt, ziet iedereen dat de klok laag is. Pas als alle controllers de klok los hebben gelaten, gaat deze weer omhoog. Op deze manier kan elke afzonderlijke controller de communicatie even ophouden (een soort wait-cycle invoegen) als deze om wat voor reden dan ook nog niet klaar is met het verwerken van de data.

Elke controller start een timer op het moment dat hij de clock van status ziet veranderen. Pas als deze afgelopen is, mag hij zelf zijn uitgang laten veranderen. Op deze manier wordt ervoor gezorgd dat er een minimale tijd is dat de clock hoog en laag zal blijven. Dat deze timers niet exact op hetzelfde moment af zullen lopen, is niet erg; aangezien de bus laag wordt zodra iemand hem laat trekt, en pas hoog wordt als iedereen hem los laat.

Dit systeem heeft een paar voordelen en een paar nadelen; voor mijn schoolopdracht mocht ik alleen identieke controllers gebruiken, en moest het netwerk blijven lopen als het gescheiden werd, en later weer aan elkaar geknoopt. Ik kon daar dus geen centraal gegenereerde clock gebruiken. Een nadeel hiervan, is dat het signaal onbetrouwbaar wordt wanneer het netwerk heel groot wordt; de uitgang van een microcontroller kan niet zoveel stroom sinken, waardoor de pull-up weerstanden groot moeten blijven. Daar komt nog bij dat 1 defecte controller het hele netwerk plat kan leggen, en het heel moeilijk is om uit te zoeken welke dat is, zonder de controllers uit elkaar te gaan trekken.

Het lijkt me in dit geval dus beter om een centrale clockgenerator bij de voeding te zetten. Dit hoeft dan niet meer te zijn dan een blokgolf generator met een leuke driver erachter; misschien is een NE555 al voldoende, aangezien die 200mA kan sourcen en sinken.

Helder, hiermee moet wat te doen zijn. Moet dan wel helemaal "met de hand...".. Even wat alternatieven: kunnen we niet alle tegels gewoon de controllerklok aan 1 kloksource hangen? Zodat we tussen de controllers gewoon asynchroon serieel kunnen kletsen? Of communicatie zoals de TI84+ dat doet? (D-bus protocol). Of RC5 (niet hier voor bedoeld, maar misschien wel bruikbaar)
<hier hield ik gisteren al op>
Heb het nu door denk ik. Goed plan, geen alternatieven meer nodig. Klopt dit: per tegel 1 klokinput, tegel pin change interupt laten gebruiken om neergaande flank te bepalen. Halve klokperiode wachten en bits inlezen van de datapin (4 per tegel, 1 voor elke buur), dus terwijl de kloklijn laag is. Vervolgens wachten op opgaande flank, dan datapin omzetten naar output en zelf data erop plaatsen, wat de andere tegel dan in kan lezen bij de volgende neergaande flank. Kortsluiting als in "ene controller trekt datapin laag, ander wil 'm hoog maken" zou je dan in theorie al niet meer moeten hebben. Maar 470R als bescherming opnemen in elke datalijn zal geen kwaad kunnen?

Als je dit inderdaad bedoelde weet ik nu hoe ik 1 bit kan verzenden / ontvangen over 1 draadje per buurtegel + gezamelijke klok.

EDIT ik werd gestoord tijdens het typen, waardoor het bericht van Plantrekker er nog niet stond toen ik begon.

dat heb ik dus ook wel eens .

De bewegingsvector hoeft natuurlijk niet beperkt te zijn tot 4 of 8 richtingen, je kunt vrij gemakkelijk een variant van het Bresenham algoritme gebruiken, waarbij je de vlek, inclusief de parameters, doorgeeft aan de volgende tegel, die met de parameters gaat rekenen, aan de hand daarvan beslist aan welke tegel hij het door moet geven, en dan dus de nieuwe parameters mee doorgeeft. Je kunt elke lichtvlek dan zien als een proces dat van de ene virtuele machine wordt doorgegeven naar de volgende.

Behalve de vector parameters van de vlek, moet je natuurlijk ook informatie hebben over de activiteit in het veld. Elke tegel kan voor elk van zijn 4 buren een waarde opslaan, en aan elke buur een gewogen gemiddelde van alle waarden behalve afkomstig van die buur doorgeven.
Ik noem de tegels even X(self), N(noord), O(oost), Z(zuid) en W(west).
Dus een tegel geeft de activiteitswaarde van ( N * 2 + O + W + X ) / 5 door aan Z. Op die manier propageert de waarde niet alleen in rechte lijnen, maar in een bepaalde mate wordt deze ook uitgespreid. Je kunt dan nog wel spelen met de gewichten en de deelfactor, om te bepalen over welke afstand die waarde af moet nemen, en hoe snel die waarde uitgespreid wordt over een groter gebied t.o.v. een rechte lijn. Elke keer dat er een vlek door een tegel gaat, beslist die tegel aan de hand van de activiteit in zijn 4 richtingen met een kleine factor wat de nieuwe vector moet worden, en samen met de fout factoren beslist hij naar welke tegel hij de vlek moet doorgeven.

Het klinkt nogal ingewikkeld als ik het zo opschrijf, maar volgens mij valt het wel mee. Het Bresenham lijn algoritme is hierbij belangrijk, en de rest is alleen om de informatie over de activiteit een beetje handig door het netwerk te krijgen.

klinkt inderdaad niet simpel, vectorveld, bressenham aloritme... Moet ik me eerst eens over in gaan lezen... Eerst de communicatie maar werkend krijgen.

EDIT2 voor The Game of Life hoeft elke controller steeds maar 5 bits informatie te versturen; zijn eigen status, en de status van zijn directe buren. Daaruit kan elke andere controller ook de informatie halen over de diagonale buren, waar hij niet direct mee kan communiceren. Het enige lastige is dat er na elke statusverandering 2 berichtcycli nodig zijn om de informatie op de juist plek te krijgen, aangezien deze door een andere controller moet komen.

Leuker: 3 bits. Eigen status, bovenbuur status, onderbuur status. Als een tegel dan info binnenkrijgt van links dan weet 'ie wat zijn linkerbuur en linkerboven- en onderbuur doen. Idem voor rechts. Eigen onder / bovenburen moet 'ie zelf toch al lezen om weer naar zijn buurtegels te sturen.

Game of life gaat me nu wel lukken eens communicatie werkt. Probleem is alleen dat het absoluut niet uit de verf komt op 4 bij 4 tegels. Ik heb wat zitten prutsen op een dambord (letterlijk prutsen, soms kreeg ik heel andere figuurtjes dan ik zou moeten krijgen, ergens een foutje gemaakt in een tussenstap natuurlijk), maar 4*4 is domweg te weinig ruimte, echt. Je hebt echt wel iets nodig van het formaat dambord... (en dan je randen van het bord "aan elkaar plakken". Als in asteroids: vlieg boven het beeld uit en kom er onder weer in.)

Ik weet niet of ik dit duidelijk heb verteld bij de uitleg van de communicatie, maar alle controllers beginnen tegelijkertijd met een bericht, en alle berichten zijn even lang, dus de berichtcyclus eindigt ook voor alle controllers op hetzelfde moment.

Heb ik door .

EDIT3: ik krijg zo langzamerhand wel het gevoel dat Plantrekker nog steeds vind dat een gedeelde bus met een centrale controller technisch de beste oplossing is, maar dat hij daarin ook alleen staat. Nu moet ik er meteen bij zeggen dat ik het ook leuk vind als een idee wat ik heb aangedragen wordt gebruikt hoor, maar naar mijn idee hebben beide systemen technische voor- en nadelen, en hebben we die al besproken. Hier zijn echter meer argumenten van toepassing dan alleen de technische, aangezien het een kunstzinnig project is, en ik geloof dat de consensus tussen Scotch, Lucky Luke en mijzelf is dat de losse tegels met beperkte informatie wat dat betreft leuker / beter is dan een dictator met een veld vol onderdanen.

Let op sparky, die bedieningsmodule gaat toch wel redelijk de rest van het veld als onderdanen behandelen... Ok, in beperkte mate: hij vertelt tegel 1 wat het gewenste effect is, en die verteld het weer door.

Op 5 juni 2009 21:15:18 schreef plantrekker:
Het was al van helemaal bij het begin wanneer ik aankwam met "doe het met uC, hang er RGB LED's aan, laat ze communiceren met elkaar en maak golfeffecten" Toen was het telkes, analoog is eleganter... De voordelen en mogelijkheden werden toen ook niet erkend. Tja op die manier denk ik niet dat iedereen hier een juist beeld krijgt van voor- of nadelen. Hiermee wil ik zeker niet verder srtijden, had mij er al bij neergelegd.

Even voor de duidelijkheid: we zijn nu wel met een uC bezig . Vanwege de voordelen. En RGB sluit ik ook zeker niet uit!

Op 5 juni 2009 22:27:07 schreef SparkyGSX:
@Lucky Luke: aan de ene kant heb je daar gelijk in, aan de andere kant kan ik er weinig aan doen. Als ik over zoiets na ga denken, krijg ik vaak wat wilde ideeën, en die moet ik dan opschrijven. Uiteindelijk zal Scotch zelf moeten beslissen wat hij wil gebruiken en wat niet.

Klinkt ergens wel bekend .

Een groter probleem zie ik in de implementatie; ik denk dat dit Scotch een flink eind boven zijn pet gaat (met alle respect hoor).

Mwah, ik heb, om het zwak uit te drukken, a-technischer mensen ontmoet dan Scotch... Hoeveel topics zijn er niet van "kwil robot maken, moet simpel" die uitdraaien op "%&$!! ik kannutniet! Jullie schuld!!!". Ik denk dat 'ie in een middagje doorheeft hoe 'ie een AVR programmer + software bediend. Code leren schrijven zal wat langer duren. Maar er is vast ook wel iemand anders te vinden die dat wil doen.

Op 6 juni 2009 09:53:29 schreef Scotch:
@ sparky

prima dat je met me meedenkt, ik heb ook altijd ideeen als ik met medestudenten meekijk. Zou je dat niet zus of zo doen, daar kan je ook dat mee, etc... Lijkt me een goede eigenschap.

Is het .

Bedankt voor alle respect wat betreft implementatie ;0, proefmodel moet toch wel lukken denk ik. Maar ik ben vrij optimistische ingesteld

@ lucky luke
voor het proefmodel is een kleur en het bassis effect het uitgangspunt. Ik wil me daar nu eigenlijk eerst op focussen.

Bedieningstegel wil ik er zeker in hebben.

Proefmodel gaat je lukken! Dat is gewoon die microcontroller op een printje solderen (liever: een voetje waar 'ie in past), en wat randonderdeeltjes erbij. Het enige wat je daarvoor moet weten is hoe je elektronica soldeert (weet je al denk ik: tin met fluxkern, geen S-39 oid, 25 / 30W boutje of temperatuurgeregeld station), en dat die AVR's niet meer dan 5.5V mogen hebben, en sommigen ook niet minder dan 4.5, anderen houden er bij 1.8V pas mee op afhankelijk van de klokfrequentie. Anyhow: met 5V zit je goed, en het beste is daar een 7805 oid voor te pakken (of een labvoeding, mocht je die hebben).

Verder nog een vragenregen @ Scotch:
Wat moet het proefmodel (dat is wat de 17 af moet toch?) kunnen?
Wat gaat er daarna gebeuren? Heb je iets van een datumlijst?
Het proefmodel is 16 tegels, 4x4, maar wat wordt het uiteindelijke model? En wat gebeurt er uiteindelijk mee? Slijt het de rest van z'n dagen ergens ter decoratie in een gebouw, in een oplslagplaats, of in jouw woonkamer? Ik neem aan dat je je eigen project niet de afvalbak in laat gooien?

Daar heb ik weinig aan toe te voegen.

Alleen een correctie: voor de communicatie had ik per richting 2 pinnen gebruikt; data in en data out. Er wordt dus ook altijd tegelijkertijd in beide richtingen een bitje verstuurd.

Op zou zou het wel met 1 gedeelde pin kunnen, als elke controller op de even klokflanken links en onder ontvangt, en rechts en boven zendt. Daarmee wordt, voor een gegeven klokfrequentie, natuurlijk wel de datarate gehalveerd.

De controllers van mijn schoolprojectje kon je op elke willekeurige manier aan elkaar hangen, waardoor zo'n systeem niet mogelijk was. Als je de tegels altijd in dezelfde richting neerlegt, is dat niet zo'n probleem. We zijn er ook steeds vanuit gegaan dat de tegels vierkant zijn. Als je de tegels rechthoekig gaat maken, en misschien zelfs verschillende maten door elkaar wilt gaan gebruiken om patronen te kunnen leggen (zoiets als meestal met grindtegels wordt gedaan), wordt het wel heel erg ingewikkeld. Lijkt me iets voor versie 2.

Zoals jij schrijft "een halve klokperiode wachten" is niet handig, want dan heb je gelijk weer een timer met interrupt nodig. Bovendien weet je in principe niet precies hoe lang een klokperiode duurt. Het is dan beter op de klokfrequentie te verdubbelen.

Het lijkt me overigens niet zo'n goed idee om software PWM te gebruiken in combinatie met deze vorm van communicatie, want als je dan ook nog eens een beetje moet rekenen voor het effect, ga je, denk ik, echt in de knoop komen met de beschikbare processortijd.

Juist. Het zijn 4 tegels die tegelijk met elkaar babbelen. Dat wist ik nog wel in het begin (want om die reden wilde ik wat pinnen sparen), maar ergens halverwege ben ik dat uit het oog verloren.

Dan doen we dus gewoon 9 pinnen voor de communicatie. Dus komt er een voorwaarde bij voor de controller: veel I/O: 3PWM + 2ADC (voor evt. 2e sensor) + 1 pin change interrupt + 1CLK + 4 data in + 4 data out = 15 I/O. Hmm, valt me nog mee. Maar een beetje extra is nooit weg.

Software PWM wil ik sowiso vermijden. Hardware PWM programmeert makkelijker, en is tenminste zeker weten flikkervrij.

Wat de halve klokperiode betrof: ik dacht dat je altijd in het midden van de bit samplede? Of gaat dat bij dit sowiso wel goed en moet je daar alleen op letten bij erg snelle communicatie?
Enuhm, de kloksnelheid weten we toch wel, want die NE555 staat toch op een vooraf bepaalde snelheid? Ik heb het dus over de klok van de communicatie, niet van de controller.

@ lucky luke
Duidelijk en overzichtelijk verhaal.

Ingaand op jouw vragen:
Wat moet het proefmodel kunnen?
-> ik ben blij met de werking zoals je die op youtube hebt laten zien. Alles wat het verder kan is leuk meegenomen. Opbouw bij voorkeur zodat ik later nog dingen kan toevoegen aan het programma. Grotere controllers op voetjes (of iets met headers maar dat begrijp ik nog niet helemaal).

Wat gaat er daarna gebeuren?
-> daarna moet ik eerst drie weken keihard aan een ander project werken (moet weer eens geld verdienen en ga ik proberen een plek te vinden waar ze het uit willen voeren. Nog geen strak plan dus

Het proefmodel is 16 tegels, 4x4, maar wat wordt het uiteindelijke model?
-> proefmodel wordt mischien zelfs iets kleiner: 3x4
-> het uiteindelijke ding wordt een modulair systeem, proefmodel is een werkendmodel hiervan (beleving testen)

En wat gebeurt er uiteindelijk mee -> nog onbekend

Ik neem aan dat je je eigen project niet de afvalbak in laat gooien? -> goed geraden

EDIT:
volgens mij moet je de diagonalen er ook bij pakken voor het beste effect in beeld. Dan comuniceert iedere tegel met zijn 8 buren. (of wordt het dan heel complex/groot?

De tegels communiceren alleen met hun eigen, rechte buren. Maar die communiceren weer met hún buren, en die weer met hún buren, enz. Dus het effect is niet beperkt tot de directe buren .

Dat wil zeggen: nadat ik (of iemand anders) dat geprogrammeert heb.

Ik heb tot nog toe al rekening gehouden met de uitbreidbaarheid, alleen niet op dat eerste printje. Sparky's communicatie idee is ook bedoeld om modulair te werken. Tegel meer of minder maakt niet zo veel uit. Behalve dat effecten natuurlijk slechter of zelfs totaal niet uit de verf komen op te weinig tegels. De buren mee laten faden op een vloer van 1 bij 1 tegels is vrij lastig, game of life op minder dan 3 tegels ook, en op 4 bij 4 komt het absoluut niet goed uit de verf.

Wat controllers in voetjes betreft:
Dat zorgt ervoor dat ze makkelijk los te halen zijn, zonder solderen. Weet je wat IC voeten zijn? Die dingen dus.
headers: Gewoon een rijtje pinnetjes waar weer een connectortje op past. In geval van ICP: een rijtje pinnen waar de connector van je programmer op past, zodat je de controller kunt programmeren zonder 'm los te hoeven halen uit de schakeling.
Waarom dan toch beiden:
Mocht er onverhoopt een controller defect raken, dan vervangt het ook wat makkelijker met zo'n voetje. Verder kun je dankzij het voetje de controller uit de schakeling halen als je aan de schakeling soldeert. Zodoende raakt je controller niet beschadigd door oververhitting of een verkeerd/niet geaarde soldeerbout. (zo'n standaard 25W / €10 (velleman)boutje is normaal geaard. Steek je 'm echter in een ongeaard stopcontact dan kan er door capitatieve koppeling spanning op komen te staan. Dat is ongevaarlijk voor jou, want er kan bijna geen stroom gaan lopen, maar mogelijk kan je schakeling er toch minder goed tegen. Als je 'm in een geaard stopcontact steekt en je raakt zelf statisch geladen, dan kan die lading via je schakeling en je geaarde bout weg. Ook ongevaarlijk voor jou, maar niet voor je schakeling. Weertanden enzo hebben er geen last van , maar microcontrollers en andere IC's kunnen er minder goed tegen. Ze kunnen het overleven (dankzij beveiligingsdiodes e.d.), maar ze doen het niet altijd.)
ICP header is gewoon gebruiksgemak. Headers kosten niet veel. (ik moet ook eens een vooraadje van die dingen inslaan...)

En Scotch, heb je al gekeken of je misschien samples kunt krijgen?
ik denk van wel namelijk. Ok, je moet eerst weten welke controller je nodig hebt voor je gaat samplen. Maar ik breng het nog maar even ter sprake om te voorkomen dat het verloren gaat in het gewoel van topic.

En nou duik ik weer in mijn C++ boek

De proefopstelling is idd eigenlijk te klein om een goed beeld te krijgen van de meer uitgebreide effecten. Mijn doel is dan ook het basis effect te laten zien.

Het liefst wil ik natuurlijk zoveel mogelijk laten zien dus als het lekker gaat bouw ik gewoon verder (hoe meer tegels hoe beter). Het is even afwachten hoeveel tijd ik hiervoor nodig heb.

Het comuniceren in de diagonalen lijkt me wel belangrijk. Optisch is de diagonaal namelijk net zo belangrijk als de verticaal/horizontaal. Het zou gek zijn als de diagonaal trager reageerd en minder fel oplicht dan de horizontaal/verticaal. Zijn er hiervoor te weinig poorten of iets dergelijks?

Succes met c++

Op 7 juni 2009 12:07:42 schreef Lucky luke:
[...]
Wat de halve klokperiode betrof: ik dacht dat je altijd in het midden van de bit samplede? Of gaat dat bij dit sowiso wel goed en moet je daar alleen op letten bij erg snelle communicatie?
Enuhm, de kloksnelheid weten we toch wel, want die NE555 staat toch op een vooraf bepaalde snelheid? Ik heb het dus over de klok van de communicatie, niet van de controller.

Dat doen we hier ook, want de uitgangen worden op de ene flank van de klok geschreven, en op de andere flank gelezen. Aangenomen dat de klok een duty-cycle van 50% heeft, zit je dan precies midden in het bit.

Vaak wordt een bit vaker gesampled, waarbij een gewogen gemiddelde wordt bepaald, waaruit de meest waarschijnlijke bitwaarde wordt gehaald. In dit geval lijkt het me niet zinvol om iets dergelijks toe te passen, daar wordt het onnodig ingewikkeld van.

De kloksnelheid weet je in principe wel, maar niet met absolute nauwkeurigheid, en er kan nogal wat afwijking zitten in de kloksnelheid van de verschillende controllers, vooral als je de interne oscillators gebruikt.

Maar waar het om gaat, is dat het niet echt handig is om zulke dingen asynchroon te gaan doen, als je een kloksignaal beschikbaar hebt. Zulke dingen worden overigens wel vaker gedaan in de datacommunicatie, vaak met analoge phase-locked loops, maar waarom zou je zulke toeren gaan uithalen als het niet nodig is?

Met 8 tegels communiceren wordt te gek, denk ik, want dan heb je alleen voor de communicatie al 17 I/O pinnen nodig. Zoals Lucky Luke al zei, kun je daar indirect toch al mee communiceren.

Wat natuurlijk wel zou kunnen, is er alsnog een half-duplex bus van maken, en dan wel met de diagonale buren communiceren. Misschien moeten we daar wel even over gaan denken.

@Scotch: maar heb je die analoge versie nou al aan de praat gekregen? Wat wil je voor de presentatie gaan doen, analoog of met microcontrollers en het programma van Lucky Luke? De tijd begint intussen aardig te dringen, lijkt me.

met de analoge ben ik niet meer bezig geweest, wil het even overnieuw bouwen maar had nog geen tijd om langs de winkel te gaan.

Voor de zekerheid maar nieuwe componenten, dat is het geld niet.

Ik heb het gevoel dat ik voor de verdere opstelling het beste de controller versie zou kunnen maken. Ben alleen bang dat hier te veel tijd in gaat zitten (weer allemaal nieuwe dingen om te leren...). Een moeilijke keuze.

De tijd gaat idd wel dringen.

Wat zou ik op de piezzo moeten meten eigenlijk, voltage wisselt maar heel miniem (ga het vanavond nog even nameten).

De spanning op de piezo kun je bijna niet meten met een multimeter. Ik zie pieken van 100mV of zo met mijn Fluke.
Met een oscilloscoop kun je die pieken wel goed zien.

Heb je al gekeken of je kunt ontdekken wat je fout gedaan hebt, afgezien van de verkeerde aansluitingen van de transistors? Heb je geprobeerd de transistors na te meten?

ja heb ik wel geprobeerd maar met mijn multimeter kwam ik er niet uit. Beide transistoren waren iig verkeerd aangesloten in eerste instantie. Had perongeluk ook de condensator paralel aan de weerstand gezet en vervolgens over de LED's.

Alles klopt nu volgens mij wel maar het zou kunnen dat er nog ietsa fouts inzit. Ik wou ook een beetje te klein werken denk ik, printje is ongeveer 2 x 3 cm geworden Niet echt overzichtelijk...

Wat voor multimeter heb je precies?

Ik was even op zoek naar een plaatje van de typische goedkope multimeter, dus ik google op "multimeter praxis". Eerste hit: CO, het grote interessante aanbiedingen topic...

Het doormeten van die transistors zou toch geen problemen mogen opleveren. Als je vreemde waarden krijgt, zou het natuurlijk zo kunnen zijn dat ze allebei stuk zijn. Om ze te kunnen moeten moet je ze overigens wel los solderen.

ik heb er twee,
lifetime tools (heel goedkoop ding)
topcraft (heel goedkoop aldi ding)

had ze natuurlijk niet losgesoldeerd, soms denk ik niet na...

EDIT: pak net die topcraft erbij, daarop zit een npn/pnp meetding, ga ik even proberen.

[Bericht gewijzigd door Scotch op zondag 7 juni 2009 19:40:53 (23%)]

Ik heb ook zo'n goedkope meter voor als ik iets niet vertrouw, en ik er de trouwe Fluke er niet aan wil wagen. Dat ding heeft ook een transistor tester, maar die heeft het bij mij nog nooit gedaan.

Gewoon de diode stand gebruiken, dat werkt wel goed.

zit er bij deze ook op dus dan doe ik dat

Ik zie net een relevant item op Thinkgeek: http://www.thinkgeek.com/geektoys/science/ae39/
Het ontwerp komt blijkbaar hier vandaan:
http://blog.makezine.com/archive/2006/12/make_it_game_of.html

Hier http://www.makezine.com/gol/ staat ook een PDFje met het ontwerp. Volgens mij hebben ze mijn idee voor die bus gejat! Het ding lijkt 1 gedeelde lijn te hebben (waarschijnlijk een klok), en 1 datalijn per zijde.

De source staat er ook bij, en die is wel dusdanig beroerd dat het eigenlijk niet bruikbaar is.

Nieuwe posts nog niet geheel bestudeerd (dwz: gelezen, maar geen linkjes gevolgd), maar ik heb denk ik door hoe die bus werkt:

klok gaat omlaag -> controllers zetten hun data neer.
Klok blijft even laag (tis 'n blokgof) -> cotrollers doen niks, data blijft staan (nouja, de controllers doen niks met de data. Als het even wil wel met de rest van het programma)
klok wordt hoog -> controllers lezen data in
klok blijft even hoog -> controllers doen niks met de data (als het even kan wel met de rest van het programma)

Dat zit best wel geniaal in elkaar En ga ik ook kunnen toepassen.

De tijd gaat idd tikken nu. Controllers in het prototype. Dan moeten we wel weten welke... Atmega8? Misschien een beetje overkill, maar heeft voldoende pinnen, mogelijkheid op interupt bij falling/rising edge op een pin (INT1), heeft een 6 kanaals adc, 3pwm kanalen, en genoeg geheugen (8k flash, 1k ram, 512byte eeprom).

Qua moeilijke nieuwe dingen met microcontrollers:
Je kunt ergens aan componenten/gaatjesprint komen? (ik denk van wel, immers: de analoge versie heb je ook ergens onderdelen voor gekocht)
Je kunt solderen en een schematje lezen? (uhm, ja, denk ik)
Je kunt ergens een AVR programmer kopen (AAVRS)? (of bouw die die hier op CO bij schakelingen staat, er staat een printontwerp bij wat Technojunk zou kunnen etsen/boren).
Je kunt ergens een AVR kopen? (AAVRS. Niels zal te lang duren qua verzending, samplen weet ik niet hoe snel dat is)
Je kunt een kabeltje ergens op prikken?
Je weet hoe je een computer bedient (op een knopje "program" oid. klikken op je scherm)?
Je kunt dat kabeltje ook weer los halen?

Indien nergens nee kun je gewoon een AVR programeren . Zo moeilijk is het niet. Ok, er zijn altijd onverwachte problemen, maar die zijn toch wel te fixen in een paar dagen?

Je bouwt nl. gewoon de avr schakeling op (als zeker is welke controller we gaan gebruiken wil ik wel een schema/printje maken), prikt die programmer er op (moet ik er even op letten dat ik een ICP header voorzie die klopt met die van je programmer, ikzelf klooi altijd maar wat aan met draadjes voorzien van headerpinnen in een breadboard.), zorgt dat je schakeling voeding heeft, je klikt program (oid, afhankelijk van het programma), je haalt de programmer los, en 't zou moeten werken.

_{hmm, het werkt niet lekker zonder muis... Batterijen zijn leeg, heb een beetje een tekort aan oplaadbare batterijen sinds ik mijn Pizoo Z ermee voedt. Ja, ik ken het shift-numlock trucje (muistoetsen)}

EDIT:
Op zo'n piezo meet ik met de multimeter op wisselspanning toch wel pieken van zo'n 15 volt en hoger (als ik de piezo een beetje buig) Op gelijkspanning idd maar een paar milivolt.