Schieberegister beschreiben

Hallo Jungs!
Ich habe da mal eine Frage zur Herrangehensweise an die Programmierung mit Bascom. Ich habe an einem AtMega8 4 Schieberegister in Reihe angeschlossen (74HC595) die ich jetzt gerne mit Hilfe von Bascom mit Werten füttern möchte. Das ganze dient zur Steuerung eines 5x5x5 LED Cubes. Der Würfel hat 25 Säulen und 5 Ebenen (logisch). An den Schieberegistern liegen die Säulen. Es werden also nur 25 Ausgänge der 32 Möglichen benutzt. Soweit erstmal zur theorie.
Jetzt das eigentliche Problem: Ich muss also für jede Ebene die Schieberegister beschreiben und anschließend die Ebene aktivieren (geht bei mir per Mosfet). Jetzt müssen die Schieberegister wieder neu beschrieben werden für die nächste ebene usw., sodass die Ebene nacheinander durchgeschaltet werden können (Multiplex eben).
Wie Speicher ich nun Sinnvoll die jeweils 32 Bit für jede Ebene ab und bekomme die in die Schieberegister? Ich würde am liebsten die Bitmuster für jede Ebene im EEprom abspeichern und anschließend per Forschleife Bitweise durchgehen und in die Schieberegister takten.

Pseudocode:
for x=32 To 1 Step -1
Bit x aus eeprom lesen
In Schieberegister Takten
next x

Ich hab allerdings keine Ahnung wie ich erstmal das EEprom Bitweise beschreiben kann und dann auch Bitweise lesen kann. Nach meiner Idee hätte ich dann für 1 Bild 5x32Bit = 160 Bit hintereinander im EEprom stehen. DIe for schleife muss dann erst 32 Bit lesen und in die Schieberegister takten. Anschließend wir die Ebene ausgegeben und durch eine weiter For schleife die nächsten 32 Bit gelesen und auf die Schieberegister gepackt usw. usw.
Kann mir da jemand freundlicherweise ein paar Ansätze zu schreiben? Gibt es eine Sinnvollere Möglichkeit die Muster abzuspeichern? Ich hatte zunächst an mehrdimensionale Arrays geacht aber das unterstützt Bascom ja leider nicht.
Danke schonmal vorab für eure Hilfe!

Oze

Bei einem Projekt hatte ich eine ähnliche Vorgabe, nämlich Daten "Rauszuschieben" und das in einer von mir gewählten Geschwindigkeit. Ich habe dazu Bytes mit den SHIFT-Befehl (BASCOM) verschoben und auf einen als Ausgang definierten Port geschrieben. Hat für eine Zwecke total gereicht und funktioniert. Übrigens auch mit einem ATmega8. Für Deine Zwecke brauchst Du warscheinlich, wenn Du diesen Weg nehmen würdest, einen ATmega16 wegen der Anzahl der Ausgänge. VG Micha

Hallo Oze,
lesen und schreiben von Bytes wird mit dem EEPROM sicherlich viel besser gehen. Es sind dann halt immer 8 Säulenwerte gleichzeitig. Vorstellen kannst du dir dann immer noch, dass die 25 Werte der Säulen hintereinander stehen.
Tatsächlich würde ich sogar Long Werte nehmen, dann hast du alle 25 direkt in einer Variable und kannst sie entsprechend manipulieren. Eine Long einlesen wird auch schneller gehen als 4 Byte einzeln.
Ob das EEPROM schnell genug für diesen Zweck ist, musst du dann mal sehen, ich befürchte eher nicht. Um ein einigermaßen flimmerfreies Bild zu bekommen, wirst du sicherlich mit 50Hz den ganzen Würfel ausgeben müssen. Es käme dann noch darauf an, wie schnell du die Bilder wechseln möchtest.
Jedenfalls würde ich die beiden Aufgaben "Daten holen" und "Daten ausgeben" komplett entkoppeln. Ein Timer ist nur für die Ausgabe der Matrix zuständig, indem er im mindestens 250Hz Takt die aktuellen Daten ins Schieberegister ausgibt. Ein zweiter Timer oder die Mainloop besorgt die neuen Daten.

Wenn es auch die Geschwindigketi ankommt sollte man für das Schieberegister das Hardware-SPI Interface nutzen. Da braucht man dann nur noch einmal die Geschwindigkeit einstellen und dann die Daten Byte-Weise reinschreiben. Das Takten der Bits übernimmt die Hardware. Es macht dann auch nichts, das man jeweils 32 statt 25 Bits ausgibt.

Wenigstens die Daten für ein Bild (5 mal 4 Bytes) sollte man nicht jedesmal aus dem EEPROM hohlen, sondern im RAM halten. Für ein gleichmäßig helles Bild würde ich die Wechsel der Ebene komplett in einen Timerinterrupt stecken - da will man keinen langsamen Zugriff auf das EEPROM drin haben.

Danke Jungs für die vielen Anregungen! Ich werds wohl machen wie Besserwessi vorgeschlagen hat: Die Bilder im EEprom speichern und jeweils 5x4 Byte lesen und in den Ram speichern und wie schon vorgeschlagen dann per Timer die Ebenen durchmultiplexen.
Jetzt noch ne Frage zum Hardware SPI: Kann ich dem Controller sagen welche Pins dafür genutzt werden sollen oder sind die fix? Wär ärgerlich denn dann müsste ich die Platine nochmals umstricken.

Alternativ: Was haltet ihr davon das ganze EEprom außenvor zu lassen und die Bilder im Flash zu speichern? Da sollte dann ja mehr reingehen wenn ich bedenke, dass der Mega8 8K Flash speicher hat. Dann spar ich mir die ganze routine die Bilder aus dem EEprom zu lesen und je nach dem wieviel Platz mein Programm frisst könnt ich noch mehr Bilder speichern.
Um die Bilder zu generieren werd ich mir eh ein kleines Script für den PC schreiben das mir graphisch den Würfel anzeigt und man dann quasi die Bilder "malen" kann. Das Script wird mir dann die Bilder in die Werte für die Schieberegister umwandeln und in ner txt speichern. Ob ich die Bilder dann per include im Flash speicher oder in das EEprom speicher macht dann ja ehr keinen Unterschied oder seh ich das jetzt vollkommen falsch?

Nochmals: Riesen Dank für die schnelle Hilfe!

Die Pins für Hardware SPI sind fix. Wenn der µC ein USART hat, hat man 2 Möglichkeiten. Das reine SPI-interface oder die USART. Wäre aber schon zu fall wenn da eine Lösung paßt. Wenn man die Software SPI Lösung mit Inline ASM schreibt, ist die auch nicht so langsam. Gereade für so etwas wie das SPI Interface ist inline ASM sehr viel schneller als original BASCOM code. Man kann es auch erstmal in reinem BASIC Probieren und nur wenn es nicht schnell genug ist auf ASM zurückgreifen.

Man könnte die Daten auch im Flash speichern. Da wäre der Zugriff auch relativ schnell un man müßte die Daten nich unbedingt in RAM kopieren. Etwas anders ist der Zugriff schon, aber nicht viel.

hmm dann werde ich denke ich einfach erstmal versuchen das ganze auf Softwareebene zu realisieren ohne hardware SPI. Sollte das ganze dann nicht so laufen wie zu erwarten werd ich wohl die Platine neu erstellen und das Hardware SPI Interface nutzen. Mit ASM kenn ich mich leider nur in Grundzügen aus, sodass ich auf Bascom vorerst angewiesen bin. Sollte das ganze wie gesagt nicht sauber laufen ist das wenigstens ein guter Einstieg in ASM ;-)

Ich danke euch nochmals für eure wirklich gute Hilfe! Solltet ihr noch andere Anregungen haben bin ich gerne dafür offen ;-)