BASCOM - LED CUBE, czytnik SD, multiplexing

Witam

Projektuje LED CUBE'a 7x7x7. Całość ładnie pięknie działała. Każdy poziom cube'a jest sterowany za pomocą tranzystora. Wiersze są sterowane przez rejestry przesuwne 74HC595. Jednak projekt nieco się rozrósł, i postanowiłem dołożyć obsługę kart SD przez system AVR-DOS i zapisywałbym efekty na SD. okazało się, że odczyt takiego efektu zakłóca się z przerwaniami od timer0 odpowiedzialnego za multiplexing. Mam kwarc 12MHz, (ale będę zmieniał na 11,0592MHz), timer z prescalerem 256, a po każdym przerwaniu ładowana jest wartosc timer0=150 (czyli 105 cykli). Mam kłopot z przeliczeniem tego na Hz, dlatego mierzyłem jeden z poziomów kostki miernikiem i pokazał mi częstotliwość ok.60Hz i wypełnienie 14%. Problem w tym, że jeśli chce zmniejszyć częstotliwość odświeżania (np. do 25Hz) to ledy zaczynają migotać.
Ale wracając. Wpadłem na pomysł żeby dodać drugi procesor (np.attiny2313) który zająłby się multiplexacją. Potrzebowałbym wtedy przesłać z Mastera(atmega32) do Slave 49 bajtów danych. Próbowałem to zrealizować przez polecenia shiftin i shiftout, ale nie zdało to egzaminu.
Zastanawiałem się nad sprzętowym buforowanym UARTem, który by przesyłał dane z prędkością 115200bps (stąd kwarc 11,0592) lub poprzez SPI, ale nie wiem czy nie zakłóci to komunikacji z kartą SD.

Który z sposobów (SPI czy UART) byłby najlepszy dla zastosowania? Oraz prosiłbym ewentualnie o radę lub sugestię dot. stabilnej obsługi przesyłu.

Gołym okiem widać, że to nie jest zadania dla ATmega. Potrzeba silniejszego procesora z 2xSPI i DMA. Jeden SPI do karty SD, drugi do przysyłanai danych do układów sterujących LED, np. serii MBI.

Eeeee, Kolego, nie demonizujmy, tym bardziej że z ARM to Autor nie wejdzie szybko - poziom to Bascom AVR.. Avr i więcej potrafi jak się odpowiednio napisze program - i od tego zacznijmy - pokaż program.

Proszę bardzo, oto program.

Jeśli chodzi o obsługę multipleksu to jest ona zrealizowana, że najpierw jest
zatrzaskiwana wartość w rejestrach przesuwnych, potem zaświecany dany poziom wraz z odpowiednią wartością dla niego i w tym samym czasie do rejestrów przesuwnych ładowane są już kolejne dane dla kolejnego poziomu i tak w kółko.

Sabotaż, kilka sprostowań. Na czas odczytu wyłączam przerwania lub też pauzuje timer0, w obu przypadkach to samo. Gdy nie wyłączam przerwań wtedy w ogóle nie odczytuje mi danych z karty, bądź są to pojedyncze bajty i następuje mrugnięcie niektórych diod przez milisekundy. Zauważ że na każdy poziom od P1()...P7() jest przypisana tablica 7 bajtowa, najprawdopodobniej zrobię to po twojemu, gdy będę wysyłał dane na drugi procesor. Case w przerwaniu jest odpowiedzialne za to który aktualnie poziom kostki jest wyświetlany. Chyba miałeś na myśli pętlę for. No i jeśli chodzi o odczyt z sd to avr-dos odczytuje tylko jeden sektor z karty, gdy miałem efekt zawierający 4 klatki to chodziło okej, nawet jak w trakcie wyjąłem kartę. Kłopot pojawił się gdy animacja jest bardziej obszerna.

I tak rozważam dołożenie drugiego procesora, gdyż wtedy w zwolniłby mi się timer odpowiedzialny za multiplex i wykorzystałbym go do rc5. Teraz natomiast pozostaje pytanie, jakim protokołem transmisji najlepiej jest przesyłać dane do drugiego mikroprocesora. SPI, UART, I2C, a może samemu napisać transmisję równoległą (pomysł mojego nauczyciela elektroniki).

Najlepiej wziąć jeden procesor, który ma wszystko, co trzeba w jednym kawałku.

Jakiś większy ATmega nie różni się zasadniczo od mniejszego ATmega,a po prostu ma więcej nóg i interfejsów (skoro już musi być drogi zabytek). Łatwiej oprogramować jedną sztukę niż dwie. Dziwne macie te pomysły.

BlueDraco - owszem, łatwiej jeden uC. Ale jako że siedzę w avrach i bascomie, to raczej nie mam zamiaru wyrzucać kolejnych pieniędzy, płytek które wytrawiłem i zlutowałem po to żeby babrać się w inną rodzinę procesorów. Poza tym zanim nauczyłbym się nowego języka i nowych uC minęło by sporo czasu, który raczej muszę przełożyć na inne cele (matura + egz techniczny).

Saabotaz.
Właśnie dlatego chce użyć kwarców 11.0592MHz aby baudrate był jak największy. Po stronie odbiornika chciałem zrobić buforowany serialin na 50 lub 100bajtów. Po odebraniu znaku startu, program wpisywałby do tablicy 49bajtowej dane za pomocą inkey lub waitkey, a po odebraniu znaku końca, przepisywałby dane do mniejszych tablic P1()...P7(), a w przypadku jeśli ostatni znak nie byłby znakiem kończącym ramkę, dane by się nie przepisywały.
Tylko chodzi mi o to, czy UART się "wyrobi" pomiędzy przerwaniami, lub czy w trakcie gdy nadejdzie przerwanie i po jego wykonaniu,program powróci do odbioru danych.
Ze strony nadajnika będę ramkę (49bajtów) wysyłał w w odstępach czasowych minimum 100ms.

Zrobiłem tak jak poradziłeś. Działa wyśmienicie nawet na 115200bps. Dziękuje