verlichtingsschakeling voor kunstwerk

Als je hem buigt? Ja, dan wel natuurlijk. Ik tik er alleen op met een vinger, en ik kan de piezo niet eens direct raken.

Akkoord met de Atmega8?

Ik vind het prima, daar heb ik er ook nog wel een paar van liggen, geloof ik. Wat dat betreft mag een MEGA32 van mij ook wel, maar die is gelijk een stuk duurder.

@ lucky luke

ik bestel alles bij Farnell, alleen de LED's vind ik lastig.

Verder kan ik op alles ja zeggen.

Als je een printje wil tekenen moet ik dat wel snel naar Niels sturen. Het duurt zeker 4 dagen voor ik het in huis heb. Met een schema kan ik anders zelf een houten printje maken. Doe ik alles gewoon met draad doorverbinden.

Ik kan natuurlijk altijd nog verder met de analoge versie. Het is niet de bedoeling dat jullie last van mijn deadline hebben

Je kan dan beter op gaatjesbord gaan werken, een IC (of ICvoet) op spijkertjes zetten gaat denk ik niet zo lekker.

Ik zal wel een printje maken voor de Atmega8.

en Scotch: ik weet niet hoe snel die controllers er zijn als je ze sampled, maar het kan geld schelen, en het is volgens mij ook bedoeld voor prototypes en studentenwerk. Ik heb ook geen Atmega8 trouwens... Hopen dat ze ze mij ook op willen sturen...

Ik heb laatst van hout een printje gemaakt door gaatjes te boren waar ik de componenten wil hebben. Vervolgens de pootjes doorsteken en aan de onderzijde solderen, ging super. Mischien niet handig met een controller vanwege kortere pootjes?

Je bedoelt met sampelen toch gewoon samples aanvragen? Of bedoel je een of andere website waar ze dit soort spul voor minder aanbieden??

Ik bedoel samples aanvragen. Heb net dat formulier in zitten vullen zodat ik zelf ook wat kan ontwikkelen op die atmega8 (als ze ze opsturen tenminste. Ik weet niet hoe moeilijk Atmel doet).

Wbt printje van hout: De pootjes zitten ook nogal dicht bij elkaar, zijn kort, en gaatjesprint (experimenteerprint) of echte print is netter/handiger e.d.

Het schema:
http://www.uploadarchief.net/files/download/schema_atm8.png

(ook ter aproval voor sparky. Ik kan namelijk iets vergeten zijn / fout hebben gedaan).

ziet er nog best ingewikkeld uit. Moet eerst even de solex van mijn viendin fixen maar ga zometeen kijken of ik het volg.

Deze is het dan: http://nl.farnell.com/atmel/atmega8-16pu/8bit-8k-flash-mcu-dip28/dp/91…

2.24 per stuk, nog te doen.

Die is het inderdaad. Het schema moeilijk? Phoe, ik zit al sinds half 5 een printje te tekenen, maar ik blijf kruisende lijnen houden... Het zonder draadbruggen voor elkaar krijgen heb ik allang opgegeven... Het is 1 grote zooi op het moment, en echt compact krijg ik het ook niet... Het printje tekenen kost minstens nog een dag...

Ik vrees dat ik nog wat wijzigen in het schema ook. namelijk die connectors voor de boven en onderburen, 't is wel zo handig als die zodanig zijn dat je ze rechtstreeks door kunt lussen, idem voor de linker / rechterburen.

Ander kabeltjes maken is makkelijker dan een ander printje. En het in software fixen kan ook nog.

EDIT:
Goed, hij is nu wat compacter. Zou het dan misschien toch lukken om dit printje af te krijgen?

EDIT:
Flink pijn in mijn schouder van het muizen, maar:

En:
http://www.uploadarchief.net/files/download/tegel_mega8.zip

16:30 tot 20:50... je mag blij zijn dat ik geen uren reken

Iedereen met op of aanmerkingen: de eaglefiles staan online

Ik heb geen Eagle geïnstalleerd, dus ik kan dat laatste schema niet openen.

Opmerkingen: de linkerkant is een beetje spaghetti geworden, maar het lijkt wel te kloppen.

Voor een extern kristal heb je nog 2 condensators nodig, zie datasheet.

Het lijkt me handig om nu al in een RGB LED te voorzien, dan kun je er nog voor kiezen om die onderdelen er nog niet in te solderen.

We moeten dan ook een beslissing gaan nemen of we alleen met de rechte buren communiceren, via een full-duplex bus, of ook met de hoeken, via een half-duplex bus, in beide gevallen met 8 datalijnen.

Met alle 8 de aangrenzende tegels communiceren, voorkomt wel dat de tegels die informatie onderling door moeten geven, en dan is alle informatie ook na 1 cyclus beschikbaar, in plaats van 2 cycli. De cyclus duurt dan wel 2 keer zo lang, dus netto scheelt het in tijd helemaal niets, maar het scheelt wel in de beschikbare bandbreedte omdat je het niet door hoeft te geven, en ik denk dat het programmeren van effecten daar ook gemakkelijker door wordt.

Op 9 juni 2009 02:11:17 schreef SparkyGSX:
Ik heb geen Eagle geïnstalleerd, dus ik kan dat laatste schema niet openen.

Opmerkingen: de linkerkant is een beetje spaghetti geworden, maar het lijkt wel te kloppen.

Voor een extern kristal heb je nog 2 condensators nodig, zie datasheet.

Het lijkt me handig om nu al in een RGB LED te voorzien, dan kun je er nog voor kiezen om die onderdelen er nog niet in te solderen.

Spaghetti: Ja, dat printje wilde écht niet. Toen heb ik het eerst maar lekker groot getekend, toen bij elkaar gepropt, en daarna ge-re-route.

Xtal: Het spoor er vlak naast is een GND, daar kunnen nog wel 2 ctjes tussen aan de onderkant. De bedoeling is helemaal geen kristal nodig te hebben eigenlijk, maar ik heb er maar een header opgezet. Eens kijken trouwens of die atmega een Ckopt heeft (dat heeft de attiny26: interne condensators voor het kristal die je aan/uit kunt zetten met een fusebit) Bij de ATmega8 doet Ckopt wat anders...

RGB led: ja, kwam ik vanacht achter dat ik die vergeten was...
Gaan we voor een RGB led of voor losse led's per kleur? Losse led's per kleur denk ik, want dat is makkelijk als je 1 kleur niet wilt bestukken, en SMD led's in serie zetten gaat niet (of elke kleur moet afzonderlijk naar buiten zijn gevoerd zoals bij 3W (en 1W, en 5W, en 25W) RGB Led's).

We moeten dan ook een beslissing gaan nemen of we alleen met de rechte buren communiceren, via een full-duplex bus, of ook met de hoeken, via een half-duplex bus, in beide gevallen met 8 datalijnen.

Met alle 8 de aangrenzende tegels communiceren, voorkomt wel dat de tegels die informatie onderling door moeten geven, en dan is alle informatie ook na 1 cyclus beschikbaar, in plaats van 2 cycli. De cyclus duurt dan wel 2 keer zo lang, dus netto scheelt het in tijd helemaal niets, maar het scheelt wel in de beschikbare bandbreedte omdat je het niet door hoeft te geven, en ik denk dat het programmeren van effecten daar ook gemakkelijker door wordt.

Ik wil graag zo makkelijk mogelijk programmeerwerk, maar een half duplex bus met 8 tegels lijkt me eigenlijk ook niet zo makkelijk...

Mijn idee was nu elke tegel gewoon het volgende uit te laten zenden:
p,p,p,p,[fade]

Waarbij bytes in mijn notitie [] staan en bits gescheiden zijn door comma's, maar in het echte bericht uiteraard niet.

fade is de eigen fade-waarde
p's zijn samen 5 bits voor het programma. Die zijn 0 als de ontvangende tegel in de huidige modus moet blijven staan, en anders 1 tm 15 voor b.v. stampmode, burenmode, aan, uit, mozes, vlekatack, vluchtvlek, en alles wat we verder verzinnen mogen.
(zodoende kunnen we een tegel ook ergens niet aansluiten, door de datalijn met een pulldown af te sluiten. Tegel ontvangt dan fade 0, en: houd huidig programma. Aangezien er met een fade van 0 niets gebeurt...)

Verder wordt het bericht misschien langer, maar met deze info zijn burenmodus, stampmodus, alles aan, alles uit, mozes en Life al mogelijk. De andere effecten weet ik nog niet hoe te maken (ga ik me pas in verdiepen als ze écht nodig zijn).

Fictieve situatie als voorbeeld bij gebruik van dit protocol:
Alles aan is simpel: de bedieningsmodule zendt %0001,255
De ontvangende tegels zetten hun modus op 1, wat voor ze betekend dat ze simpelweg hun LED aan doen, het bericht doorsturen, en wachten op verdere instructies.
Alles uit: bediening stuurt %0010,255. Doet hetzelfde als bovenstaande, maar dan alles uit. %0001,0 zou ook nog kunnen...
In geval van RGB komen er dus nog 3 fade waardes achter het programmaselecteernibble
Stampmodus:
%0011,startfade. Doet hetzelfde als het programma wat er nu al is, maar dan met het doorsturen van berichten. (met de ontvangen berichten doen ze, afgezien van de modenibble, niets)
Burenmodus
%0100,startfade
Tegels die in deze modus staan en een bericht ontvangen waaruit blijkt dat ze hun modus houden, nemen een fadewaarde aan van 1/4 van de ontvangen fadewaarde, en sturen dan het bericht weer door.
Mozes:
%0101,constantaandwaarde
De tegels faden naar de constantaanwaarde, en als iemand op ze gaat staan gaan ze uit (bij Monochrome Mozes. In KleurenMozes moeten we tevoren even 2 kleuren kiezen of flink wat extra data sturen/ontvangen)
Game Of Life:
Komt niet uit de verf op een dergelijk kleine vloer, dus ga ik niet implementeren ook.
%0110,[b,o,s,0,0,0,0,0]
In deze modus stuurt elke tegel door of zijn bovenbuur nog leeft, zijn onderbuur nog leeft, en of hijzelf nog leeft.
Zodoende weet elke tegel of hij zelf in de volgende generatie nog leeft, aangezien zijn linker en rechterzijburen 'm vertellen wat zijn diagonale buren doen, en hij zelf weet wat hijzelf en zijn bovenburen doen.

In elke modus kijkt de tegel naar het modusnibble. Is dat 0 houdt 'ie zijn huidige, is dat een andere waarde, dan kiest 'ie voor die modus.
[einde voorbeeld]

In dit voorbeeld dus maar 12 bit communicatie. (aantal bits beperkt gehouden om makkelijker te kunnen programmeren)

Het lijkt me handig om de berichtlengte contant te houden, dus die moeten we zo groot maken als we ooit nodig denken te hebben. Aan de andere kant moeten de pakketten natuurlijk ook niet asociaal groot worden. Ik denk dat een commando byte en 8 data bytes (afhankelijk van het commando) wel redelijk is. 12 bits is voor veel dingen echt veel te klein.

Je hebt natuurlijk 2 soorten programmeerwerk; zorgen dat de tegels goed communiceren (dat wil ik nog wel schrijven, datacom is mijn ding), en de effecten implementeren. Met die half-duplex bus wordt het stukje voor de communicatie wel wat ingewikkelder, maar ook niet echt veel, denk ik, maar de code voor de effecten zal wel eenvoudiger worden, omdat je de informatie van de andere tegels al niet meer door hoeft te geven.

Even wat aanpassingen gemaakt (met paintshop pro )

klikbaar:

Gewoon zooi via's weg weten te werken door de banen anders te laten lopen

(nog 1foutje van mij >_>, links onderin moet dat baantje natuurlijk ook om de RLED poot heen gaan en niet door die baan

[Bericht gewijzigd door Daan Timmer op dinsdag 9 juni 2009 09:46:32 (16%)]

Welke programeertaal wordt het ? In geval van Bascom wil ik ook wel een handje mee helpen. Waarom geen dubbelzijdige print trouwens als je ze toch laat maken.

Er kan inderdaad nog wel wat gedaan worden aan het grote aantal draadbruggen.

Links bovenin, bijvoorbeeld, gebruik je 3 draadbruggen om 2 banen over te steken, waarvan er 1 iets verderop toch al een draadbrug heeft.

Welke communicatiepoort op welke pin uit komt, is niet zo boeiend, dat kun je in de software eenvoudig recht trekken, dus daar kun je ook mee schuiven om het aantal draadbruggen te verminderen.

Het is natuurlijk ook niet strikt noodzakelijk dat de connectors voor de communicatie aan de 4 zijden van het board zitten; die zou je best naast elkaar kunnen zetten, aangezien er toch kabels aan komen.

Op 9 juni 2009 08:13:39 schreef SparkyGSX:
Het lijkt me handig om de berichtlengte contant te houden, dus die moeten we zo groot maken als we ooit nodig denken te hebben. Aan de andere kant moeten de pakketten natuurlijk ook niet asociaal groot worden. Ik denk dat een commando byte en 8 data bytes (afhankelijk van het commando) wel redelijk is. 12 bits is voor veel dingen echt veel te klein.

Je hebt natuurlijk 2 soorten programmeerwerk; zorgen dat de tegels goed communiceren (dat wil ik nog wel schrijven, datacom is mijn ding), en de effecten implementeren. Met die half-duplex bus wordt het stukje voor de communicatie wel wat ingewikkelder, maar ook niet echt veel, denk ik, maar de code voor de effecten zal wel eenvoudiger worden, omdat je de informatie van de andere tegels al niet meer door hoeft te geven.

Protocol is ook nog niet af. Als iemand anders een stuk code wil schrijven voor de communicatie (dat ik gewoon wat data in een var gooi, een sub aanroep, en de andere tegels kunnen die data weer lezen door een sub aan te roepen) vind ik dat prima. Voor mijn part in C, ik probeer er wel uit te komen en het naar basic te vertalen. (jaja, van object oriented naar function oriented, gaat heel leuk worden)

Op 9 juni 2009 10:45:53 schreef Roland van Leusden:
Welke programeertaal wordt het ? In geval van Bascom wil ik ook wel een handje mee helpen. Waarom geen dubbelzijdige print trouwens als je ze toch laat maken.

Wat mij betreft Bascom

Printje verbouwen ga ik vanmiddag eens doen, of misschien morgen. Becommentarieer maar gerust verder.

Wat betreft dubbelzijdig: Dat hangt er vanaf welke Niels het printje gaat maken... Maar het moet ook on the cheap...

Is ModBus misschien iets als protocol ?

http://www.mcselec.com/index.php?option=com_content&task=view&…

http://www.modbus.org/faq.php

Comunicatie connectors hoeven idd niet aan de corresponderende zijde.

Er kan nu nog maar een led op toch?

Ik heb Niels Technojunk gemaild, weet niet of hij dubbelzijdig kan.

@ luckyluke
ik ben idd blij dat je (en sparky ook) geen uren rekent, dan was het onbetaalbaar geworden

@Roland van Leusden: ik neem aan dat je niet het hele topic hebt gelezen (wat ik je niet kwalijk kan nemen, gezien het volume), maar we willen juist geen centrale bus, en als we 4 poorten per controller nodig hebben, is een asynchrone bus veel te geheugen en processor intensief.

De bus die we nu in gedachten hebben, kost weinig ruimte in de controller, is snel, betrouwbaar, en toereikend.

Ik ga dadelijk bekijken of ik op een harde schijf uit een oude PC die code nog terug kan vinden. Zo niet, dan wil ik het ook wel opnieuw schrijven, maar ik weet niet wanneer ik daar genoeg tijd voor heb.

Overigens is C niet object geörienteerd, dus de vertaling naar basic zal niet echt heel erg moeilijk worden, denk ik. Misschien kun je die code ook wel gewoon linken als je daar een object file van maakt, dat lijkt me nog handiger.

@Scotch: die factuur komt nog wel een keer

Op 9 juni 2009 16:09:05 schreef SparkyGSX:
Overigens is C niet object geörienteerd, dus de vertaling naar basic zal niet echt heel erg moeilijk worden, denk ik.

Sinds wanneer is BASIC dan wel OO? O.- ?

Ai, ja, dat boek is natuurlijk C++.
Ik denk niet dat bascom overweg kan met een stuk C... Een stuk asambler invoegen kan wel.
Als je het echt moet herschrijven wil ik ook wel een poging wagen eerst, per slot van rekening: als ik het moet overzetten ben ik ook lang bezig.

Vraagje: maak(te) je gebruik van pin change interupt of niet?
En laten we de controller nu zelf de klok opwekken of doen we een NE555? Ik dacht NE555 eigenlijk.

Bascom is afaik niet OO.

Technojunk zal wel dubbelzijdig kunen. Het is waarschijnlijk alleen wel duurder e.d, en die paar draadbrugjes... (een deel ga ik er nog uit-editen ook... Als muizen met links een beetje wil...)

Edit: toch maar met rechts... RGB led verwerkt, nu de draadbruggen aan het elimineren.

EDIT:

en schema:
http://www.uploadarchief.net/files/download/schema_atm8_improved.png

Eagle files:
http://www.uploadarchief.net/files/download/tegel_mega8_improved.zip

De huidige software naar een atmega8 porten moet te doen zijn. Ik heb alleen geen atmega8 om te testen (sampleaanvraag loopt, nog niks van gehoord). Dat ga ik alleen vandaag niet meer doen.

@ lucky luke en Sparky
Als we de configuratie helemaal compleet hebben dan wil ik wel een pakketje onderdelen naar jullie opsturen.

Hoe groot is de nieuwe print ongeveer?
Zitten alle 4 de LED's nu op de print?
en met je handtekening zie ik

Nog een paar aanpassingen:

Overigens, als je die mega8 op een DIP voetje gaat zetten kan je C1 en R1 onder de chip zetten, bespaart ruimte (wel eerst even kijken of je C1 daadwerkelijk past, niet dattie hogever is dan je IC DIP voetje.

@ Daan: thanks, scheelt weer 2 draadbruggen.
Onderdelen onder het IC zetten durf ik even niet aan, ook al was een voetje wel de bedoeling.

Op 9 juni 2009 22:55:15 schreef Scotch:
@ lucky luke en Sparky
Als we de configuratie helemaal compleet hebben dan wil ik wel een pakketje onderdelen naar jullie opsturen.

Graag! Onderdelen zijn altijd welkom! Als atmel me die samples niet stuurt, wil je er dan een atmega8 bij doen?

Hoe groot is de nieuwe print ongeveer?
Zitten alle 4 de LED's nu op de print?
en met je handtekening zie ik

Ja, ik had wat ruimte voor tekst, technojunk vereist een tekst (om niet in spiegelbeeld te etsen), dus dan zet ik er ook een tekst op
De LED's zitten niet op de print, ik heb een paar headertjes voorzien waar je ze dan met draadjes op kunt zetten. Het is iets meer werk, maar je kunt de led's nu wel waar dan ook in je tegel kwijt.

Verder: de voeding vraagt nu 5V en 12V, maar die 12V kun je ook aan de 5V hangen, dan kun je alleen minder LED's in serie zetten.

Er zijn 3 kanalen voor LED's. Je kunt dus 3 verschillende kleuren gebruiken in het uiteindelijk ontwerp.

Alledrie de LED uitgangen zijn voorzien van een BC547, je kunt daar dus flink wat led's op kwijt, eventueel kun je ook een BC337 neerzetten.

Serieweerstand voor de LED's zit op de print mocht je 1 serie led's doen (per kanaal), wil je meer dan zet je de serieweerstanden extern en overbrug je die op de print.

Afmetingen: Edit ik zo nog even deze post in, als ik de draadbrugjes eruit ga halen.

EDIT: ze staan in een volgende post

Cool, Niels stuurde mij dit namelijk:
'Het zou mooi zijn als je de printjes naast elkaar zou kunnen zetten, in een 10x16 cm print.
> (met iets van 3.5mm space)'

Wat betreft de voeding; zouden we niet gewoon een mosfet op de print kunnen zetten? Van 12volt <> 5volt kan toch?

LED's buiten de print is prima, die zullen toch meer naar de rand gaan.