Project: 8x8x8 Led Cube

kickje

Ik ga de multiplexfrequentie op ongeveer 50Hz zetten denk ik (= om de 20mSec). Daardoor staat een verdieping dus 1/8*20mSec. = 2,5mSec aan per cycle.
In die tijd moeten dus alle 8 de 74HC595's geüpdated worden. Dat lukt wel. Maar in die tijd moeten in ieder geval ook 8 bytes uit de EEPROM-chip ingeladen worden. Ik denk niet dat I²C daar snel genoeg voor is (400KHz). Of wel? Anders stap ik over op een door een PC-gestuurde cube.

Heeft er iemand ervaring met het aansturen van een Led Cube, en hoe heb je die data aangevoerd? (EEPROM / PC / ....?)

Volgens mij moet je bij situatie 1 de clock en data lijnen aan elkaar knopen en de latch lijnen apart. Als ik het goed heb.

Ik had maandag onderdelen besteld bij Dick Best en toch binnen tijdens de verhuizing. Het duurde wel wat langer voordat ik de bevestiging kreeg en de status van 'in behandeling'. Nu staat de bestelling pas op Afgehandeld.

Het zal wel goed komen.

Sjoerd Kreyns, data en klok kan je echt niet samenhangen.

loopycoaster, Ik werk niet met PIC's maar de SPI kan op 20M/4=5MHz draaien dacht ik. 8 Byte = 64 bit voor 1 laag, dat duurt dan 12,8µs en je hebt 2500µs de tijd per laag. De shiftregisters parallel schakelen is dus echt niet nodig, je maakt het je moeilijk terwijl het relatief weinig winst kan opleveren.

Om het je nog wat beter te kunnen voorstellen:
Per laag kunnen er 20M/4/50/8 = 12500 instructies uitgevoerd worden
Het uitklokken van 64 bit neem de tijd van 64 instructies in (ookal gebeurt dit HW-matig)

Of het lukt met de EEPROM, ik vermoed van wel maar je bent nooit zekerder dan wanneer je het experimenteel vast stelt. Probeer dus 400 keer per seconde 8 byte te lezen uit de eeprom en 8 byte via de SPI te versturen.

Nu ik het lees ..... Ik bedoelde de datalijnen aan elkaar en de clock lijnen aan elkaar...

@Sjoerd
De datalijnen kunnen niet aan elkaar vast (dan zou elk shuifregister dezelfde byte bevatten). Wel op de manier zoals situatie 2 (wat de normale manier is van shuifregisters koppelen). Toch bedankt voor je reactie m.b.t. Dick Best; ik heb helaas nog geen bevestiging gehad..

Dick Best: Door alle voorbereidingen is er een behoorlijke stagnatie ontstaan in het klaarmaken van de orders, dit zal absoluut nog wel even duren.

Ik hoop dat dit betekent dat hij wel ermee bezig is.

@plantrekker
Ik ga denk ik dan toch gewoon situatie 2 ga gebruiken, want het ziet er inderdaad naar uit dat het geen significante besparing gaat opleveren. En dat is vast de reden dat je situatie 1 nooit ziet

Datalijnen aan elkaar? Dan klok je overal hetzelfde patroon in... Dan komt dus in elk register hetzelfde patroon aan de uitgangen, tenzij je 8 verschillende latch lijnen neemt en komt het qua snelheid en pin gebruik weer beter uit door de shiftregisters in cascade te zetten.

@reactie hierboven, idd, al zou het kunnen maar dan gebruik je geen shiftregisters maar parallel-in parallel-out registers.

[Bericht gewijzigd door plantrekker op dinsdag 18 januari 2011 16:27:50 (19%)]

coaster,

Ik heb het wel eens gedaan: De 8 databits van een ISA bus op de DATA lijnen van de '595 chips en met de address comparator een "clock" signaal gemaakt. 8x een write en je had 64 bits in je '595 chips zitten. Ik heb de kaart nog liggen: 64 digitale inputs en 64 digitale outputs.

(daarna heb ik het herhaald op de S-bus van Sun. Dan zweet je wel effe peentjes als je eigengemaakte kaart voor het eerst dat HFL 24000 werkstation ingaat... )

Ik zou aanraden om de 8 datalijnen aan 8 pins van 1 en dezelfde poort te hangen. Dat is het efficientst.

Het serieel doorclocken is m.i. niet zo'n probleem. De '595 chips hebben een schuifregister waar je data in blijft zolang je niet de boel naar de uitgangsregisters clockt. Dus als je 100Hz verversing wilt doen, moet je 800 Hz per laag verversen. Dus heb je 1.25 milliseconde om met 64 shifts de data in de 595 chips te krijgen. Dat moet makkelijk lukken.

#include <avr/io.h>

void fill_shift (char *p)
{
  unsigned char c, i, j; 

  for (i=0;i<8;i++) { 
     c = *p++;
     for (j=0;j<8;j++) {
       if (c & 1) {
          PORTC |= 0x01;
       } else {
          PORTC &= 0xfe;
       }
       PORTC |= 0x2;
       c >>= 1;
       PORTC &= 0xfd;
     }
  }
}

Ik kom op ongeveer 8 clocks per bit, dus 600 clocks oftewel 30 microseconde voor 64 bits. Hou ik nog 24400 clocks over om andere dingen te doen....

rew, je c-code is softwarematige SPI, waarom? De PIC16F877A heeft een HW-SPI die in de tijd van 1 instructie 1 bit naar buiten kan klokken. 8 keer sneller dus dan de c-code.

/edit
Nog sneller dan 8 keer sneller zelfs, want terwijl dat de HW-SPI de byte naar buiten klokt kan je de volgende ophalen, daar verlies je dan geen tijd mee terwijl dat wel het geval is bij de c-code

ja? oh, ik deed het tot nu toe ook nog softwarematig

datasheet eens overlopen kan handig zijn

Hmm, ik ga me er eens is in verdiepen...

Nu ik zit te rekenen lijkt het me zelfs dat ik geen interrupts nodig ga hebben:

I²C tijd (binnenhalen data uit EEPROM IC):
snelheid = 400.000Khz (400.000 Kbits/s)
tijd per bit = 1 / 400.000 = 2,5µSec.
tijd per 64 bits (1 verdieping) = 64 * 2,5 = 160µSec. (daar komen dan nog wel de start,stop, en adresbytes bij..
Blijft er voor de SPI over als ik een refresh rate van 100Hz neem (is beter dan 50):
1250 - 160 = 1090µSec.

De overgebleven tijd na de SPI kan ik gewoon delayen (of gewoon weglaten voor een snellere refresh), die tijd komt toch niet zo nauw.
Of sla ik de plank nu helemaal mis?

Wat je kunt doen is 800 x per seconde een timer interrupt regelen. Die clockt dan even de volgende 64 bits naar het schuifregister en toggled de juiste kolom-outputs. Dan heb je in je "main" de tijd om "ongestoord" de patronen uit te rekenen. Uit de eeprom halen of wat dan ook....

Je kan dan telkens in de interrupt een teller ophogen. Wanneer die 32 is, zet je een valg. In je main weet je dan wanneer je een nieuw beeld moet berekenen (800/25=32, dus 25 beelden/sec)

Als je zonder interrutps werkt dan moet de routine die het beeld update (uit eeprom halen / zelf berekenen / ontvangen van pc) elke keer even lang duren, anders krijg je een onregelmatige refreshrate.

Op 18 januari 2011 21:00:26 schreef plantrekker:Als je zonder interrutps werkt dan moet de routine die het beeld update (uit eeprom halen / zelf berekenen / ontvangen van pc) elke keer even lang duren, anders krijg je een onregelmatige refreshrate.

Moet lukken, elke keer worden er altijd 8 bytes tegelijk opgevraagd uit het EEPROM, en worden er altijd weer 64 bits weggeschoven in de shiftregisters. Wanneer de cube en print gebouwd zijn kan ik uitsluitsel geven of het echt even lang duurt.

Ik zet trouwens sowieso een max232 PC verbinding aan de PIC, zodat de EEPROM makkelijk gevuld kan worden vanuit de PC. In de PIC komt dus ook een subroutinetje die na indrukken van een knop wacht op data van de PC en die meteen doorstuurt de EEPROM in.

Hmm, ik wou je eigenlijk laten aanvoelen dat interrupts juist hetgene is wat je moet gebruiken. Dan kan je bvb ook data van de pc ontvangen en in de eeprom plaatsen zonder dat je daar iets van merkt bij het refreshen van je kubus. Interrupts zijn echt niet moeilijk en eens je het onder knie hebt, maken ze het je net veel makkelijker, ze bestaan niet voor niets!

Ik ga binnenkort testen met het tmr1 interrupt, ik denk dat ik het begrijp (datasheet erbij gepakt).
Volgens mijn theorie is timer1 trouwens ongeschikt voor de cube, op prescaler 1:1 is er elke 13mSec. (0,2µ * 65536) een interrupt ,wat te langzaam voor multiplexing is. timer2 lijkt geschikter, die heeft op een prescaler van 1:16 om de 0,8mSec een overflow (0,2µ * 16 * 256).

De onderdelen van Dick Best zijn vandaag binnengekomen:D, dus ik kan beginnen.

Je kunt het maximum, wanneer ie terug naar nul gaat, ergens instellen. Zo kan je ieder aantal microseconden korter dan 13msec maken.

Je kan zover ik weet alleen de timer zelf op een beginwaarde zetten zodra er een interrupt plaatsvindt.

Update!

De print met de 8 74HC595's is klaar! (gewoon met 1 datalijn )
Sorry voor de jumpers trouwens , maar zo is het overzichtelijker.

achterkant:

Ook zijn al 3 van de 8 verdiepingen klaar (= 192 LED's):

loopycoaster zou jij mij misschien kunnen helpen met het schema. Ik ben ook een 8x8x8 LED kubus aan het maken. Ik maak het schema van http://www.boudewijnbruinsma.nl/Led-Cube-8x8x8.pdf
Ik weet niet of jij deze ook maakt? Maar ik zit met die dikke blauwe lijnen. Is hier alles met elkaar doorverbonden of gewoon alles appart?
Ik hoor het wel.
Alvast bedankt.

[Bericht gewijzigd door Guus Berens op maandag 24 januari 2011 19:16:49 (17%)]

Ik gebruik niet hetzelfde schema als in de instructable. Wel de indeling van de kubus zelf.

Ik heb zelf geen schema gemaakt, er zit er alleen 1 in mijn hoofd, die ik helaas niet via een USB'tje kan overzetten...

Ik gebruik dus 8 74HC595's om de + te schakelen. De 3 datalijnen gaan aan de uC. De 8 - draden van de Led's worden geschakeld door een ULN2003 (transistor array). Die 8 draden gaan ook in de uC.

Wat bedoel je met de blauwe draden. paginanr?

okee toch bedankt.
Ik bedoel die dikgedrukte blauwe lijnen op pagina 35, en dan het rechtse schema. Bedoelen ze daarmee dat al die datalijnen 8x hetzelfde is of is dat allemaal met elkaar doorverbonden.

alvast bedankt

Het betekent dat de datalijnen parallel zijn aangesloten. Dat wil zeggen dat D0 van de ene chip op de D0 van de andere zit. D1 van de ene zit aan de D1 van de andere. Een wat dikkere (blauwe) lijn is overzichtelijker, anders wordt het een warboel aan lijnen en kruisingen.

okee dank je. Ik merk dat jij hier beter in bent dan mij:P

Ik heb nog een vraag. Misschien is het helemaal niet moeilijk maar ik kom er niet uit.
Zou iemand mij kunnen vertellen hoe het zit met IC4P, IC8P enz. Verder zie ik ook nog JP1, JP2 enz. staan. En die SV1 en SV2 en SV3 zijn dat aansluitingen voor flatcables?
Ik weet niet waar deze voor zijn of waar ze naar toe gaan?
Ik vind het lastig dat het 2 schema's zijn. ik weet niet hoe ik die 2 schema's moet koppelen?
Kan iemand mij helpen?

Alvast bedankt

Update:

De printen zijn nu beiden klaar (een uC-print en een 595-print), en de cube zelf ook!

kuch*scheef*kuch :

Deze moeten alleen nog samenkomen in de behuizing, maar die moet nog geverft worden... Tot die tijd ben ik even aan het proberen met de tmr1. Zoals op de foto te zien is zitten er 8 leds (die elk parallel staan met een verdieping). Daarmee heb ik al gezien dat het tmr1 te traag is; de flikkering is duidelijk zichtbaar. Ik heb nu het tmr0 erbij gepakt, en deze flikkerde op een prescaler van 1:256 ook nog, en ik ben het daarna gaan afbouwen. Nu ben ik uitgekomen op een prescaler van 1:32 waarbij hij niet flikkert. Daarmee zou de tijd die 1 verdieping aanstaat uitkomen op:
256*32*(1/(20.000.000/4))= 1638µSec. (~600Hz)
In die tijd moet ik dus alles doen.

Zou iemand mij globaal kunnen vertellen hoe ik dat zou moeten doen met inlezen, aansturen, interrupts ed.? Zelf denk ik dat het zo moet:

pseudocode:

while 1 = 1
   data inlezen
   data in de 595's schuiven
   wachten op de interrupt
wend

interrupt:
   595's latchen
   flag resetten
terugkeren naar de while

Zit ik zo in de goede richting?
(En gaat dat uberhaupt wel lukken in 1638µSec. ?)