[Atmega8][C] - Multiplekser 13 wyświetlaczy LED + 2* rejestr przesuwny CD4094

Witam,

Potrzebuję zbudować zespół wyświetlaczy składających się z 13 wyświetlaczy LED(ze wspólną anodą) z czego 12 to wyświetlacze alfa-numeryczne 14-segmentowe. Do załączania pojedynczego wyświetlacza planuje wykorzystać dekoder 1-16bit CD4514 a do podawania sygnału sterującego myślałem wykorzystać połączony kaskadowo dwa 8-bitowe rejestry przesuwne CD4094.

Pozwolę sobie wyjaśnić jak ja to widzę:
Jeśli na na PORT C będzie wartość: 0 wtedy na dekoderze na wyjściu S0 pojawi się "1" a to powinno załączyć tranzystor BC369 i wyświetlacz o nazwie "DIS1" powinien być aktywny a reszta wyświetlaczy wyłączone. Aby wyłączyć wszystkie wyświetlacze podaje na port C wartość: 0b00001111 co aktywuje wyjście "S15" jednak nie jest ono podłączone więc wszystkie wyświetlacze będą zgaszone.

Algorytm wyświetlania liczby:
zmienna: 'nr_wyswietlacza = 1';

1.Wpisanie odpowiedniej wartości do rejestru przesuwnego.
2.Jeśli zakończono zapis włącz wyświetlacz nr 'nr_wyswietlacza'
3.Opóźnienie około 20ms
4.Wyłączenie wszystkich wyświetlaczy
5.Zwiększenie zmiennej 'nr_wyswietlacza' + 1
6.Jeśli 'nr_wyswietlacza' > liczby wyświetlaczy wtedy 'nr_wyswietlacza' = 1


Proszę o sprawdzenie poprawności czy taki układ ma szansę działać oraz jakieś wskazówki jak zapisuje się dane do tego rejestru przesuwnego i jak się dowiedzieć o fakcie zakończenia zapisu do tego rejestru?

Oto schemat, który wymyśliłem, jednak nie jestem pewien czy tranzystory BC369 oraz wartość rezystorów są poprawne.

Schemat:

Koncepcja ma szanse zadziałać. Oczywiście najważniejsze przy tego typu układach jest odpowiednia granie relacjami czasowymi. Co do sposobu zapisu do rejestru przesuwnego...wszystko jest w jego nocie katalogowej. Podajesz daną na wejście DATA i wpisujesz ją narastającym zboczem sygnału CLOCK- oczywiście trzeba pamiętać o pozostałych sygnałach sterujących tj. STROBE i OE- ale wszystko masz w nocie więc nie ma się co rozwodzić. Jak szybko mikrokontroler może wysyłać dane do rejestru przesuwnego-to też precyzuje nota-choć pewnie i tak w tych zmaganiach czasowych CD4094 kontra ATmega to mikrokontroler nie będzie w stanie wygenerować tak szybkiego CLK by układ nie był go w stanie dobrze zinterpretować.

Przede wszystkim zapomnij o układach z serii CD. To seria CMOS, nie nadająca się do współpracy z mikrokontrolerami. Są wolne, mają małe prądy wyjściowe itd. Zastosuj coś z serii 74HCT itd.
Po drugie możesz zastosować zwykł zatrzask, np, 74HCT595, lecz jest to małopraktyczne. Raz, że masz tylko 8-bitowy latch, dwa, że ma to niewielką obciążalność prądową (ale i tak o niebo większą niż CD), trzy, że wymaga rezystorów ograniczających prąd segmentów. Dlatego polecałbym ci dedykowane drivery do LED - np. SCT2024 - ma duży prąd, nie potrzebuje rezystorów i ma 16-bitowy zatrzask. Segmenty i wspólne elektrody możesz sterowąc tak samo przez SPI, nie ma potrzeby oddzielnego sterowania elektrod.

Dodano po 3 [minuty]:

Steryd3 wrote:

Jak szybko mikrokontroler może wysyłać dane do rejestru przesuwnego-to też precyzuje nota-choć pewnie i tak w tych zmaganiach czasowych CD4094 kontra ATmega to mikrokontroler nie będzie w stanie wygenerować tak szybkiego CLK by układ nie był go w stanie dobrze zinterpretować.

I tu się mylisz, CMOSy są bardzo wolne, szczególnie przy niskich napięciach zasilających. Wg noty dla 5V czas propagacji to nawet 600 ns, a częstotliwość pracy 1,5-3 MHz (1,5 jest gwarantowana jako minimalna). Biorąc pod uwagę, że SPI z M8 może działać na 8 MHz, jesteśmy dużo poza specyfikacją tego scalaka.

tmf wrote:

Dlatego polecałbym ci dedykowane drivery do LED - np. SCT2024 - ma duży prąd, nie potrzebuje rezystorów i ma 16-bitowy zatrzask. Segmenty i wspólne elektrody możesz sterowąc tak samo przez SPI, nie ma potrzeby oddzielnego sterowania elektrod.

Czyli mówisz, żeby wykorzystać jeden SCT2024 dla wszystkich wyświetlaczy a nie do końca rozumiem jak miałbym wybierać wyświetlacz który ma być aktywny?

Oczywiście nie jeden. Masz 12 wyświetlaczy 14-segmentowych, potrzebujesz więc jednego rejestru SCT2024 do trzymania danych o segmentach (wykorzystasz 14 z 16 bitów) i jednego STC lub tu właśnie 595 do sterowania wyborem wyświetlacza - jednej z 13 wspólnych elektrod. Musisz policzyć prądy, jeśli SCT da prąd wystarczający do wysterowania twojego LCD to można go śmiało użyć także w roli sterownika wspólnych elektrod. Jeśli nie to trzeba dać wzmacniacz prądu wspólnych segmentów np. na MOSFETach. Ale zapewne sam SCT wystarczy. Czyli masz dwa takie układy połączone w szereg. Pełne słowo sterujące ma 32-bity - 16 bitów steruje segmentami, kolejne 16 (a dokładnie zawsze jeden z nich) wybiera jeden z wyświetlaczy.

Jeśli dobrze z tej dokumentacji: wyświetlacza LED wyczytałem to pobiera prąd 30mA. Więc chyba SCT2026 jest od 5-60mA powinien dać sobie rade sterować wyświetlaczem bezpośrednio.

I może być drugi taki sam do wybierania wyświetlacza? I wtedy może być maksymalnie 16 takich wyświetlaczy?

Czy będzie lepszy SCT2210CSSG do 90mA?

tmf wrote:

I tu się mylisz, CMOSy są bardzo wolne, szczególnie przy niskich napięciach zasilających. Wg noty dla 5V czas propagacji to nawet 600 ns, a częstotliwość pracy 1,5-3 MHz (1,5 jest gwarantowana jako minimalna). Biorąc pod uwagę, że SPI z M8 może działać na 8 MHz, jesteśmy dużo poza specyfikacją tego scalaka.

Ogólnie trudno się nie zgodzić-może trochę przeszarżowałem. Nie mniej jednak jak można zauważyć scalak nie jest podłączony do SPI czyli generacja sygnałów musi odbywać się w sposób programowy, dodatkowo AVR nie jest taktowany 16MHz a 12MHz co można wnioskować po wartości opisu nieopodal rezonatora kwarcowego. Więc uważam, że w tym konkretnym przypadku z tym co jest szybsze można polemizować a najlepiej było by przetasować. To tak na marginesie bo ogólnie uwagi słuszne.

pawel1730 wrote:

Jeśli dobrze z tej dokumentacji: wyświetlacza LED wyczytałem to pobiera prąd 30mA. Więc chyba SCT2026 jest od 5-60mA powinien dać sobie rade sterować wyświetlaczem bezpośrednio.

I może być drugi taki sam do wybierania wyświetlacza? I wtedy może być maksymalnie 16 takich wyświetlaczy?

Czy będzie lepszy SCT2210CSSG do 90mA?

Teoretycznie tak. Jednak musisz to policzyć. Powiedzmy, że przy 30mA/segment masz max jasność. Przy 14 segmentach daje ci to 420mA na wyświetlacz! Tego żaden driver bezpośrednio nie pociągnie. Więc masz dwa rozwiązania - zmniejszyć prąd na segment do 60mA/14, czyli nieco ponad 4mA (wyświetlacz powinien świecić dosyć jasno, może ci to wystarczy). Lub na wyjście SCT sterującego wspólną elektrodą dać małe MOSFETy, takie w SOT23 spokojnie pociągną 2-4A, np. IRLML9301. Wtedy możesz sterować nawet 16 takimi LCD przy pomocy dwóch SCT. Duty cycle będziesz miał 1/16 i zapewne będzie to wymagało zwiększenia prądu diod, ale mając wzmacniacz nie będzie to problemem.
BTW, nawet nie patrzałem pod co podpiąłeś te SPI, ale oczywiście najlepiej podpiąć to pod interfejs sprzętowy. Jest to po prostu wygodne - robiąc programowo SPI też na 12 MHz M8 można spokojnie wyciągnąć 4 MHz na SPI, ale po co się męczyć jak to może zrobić sprzęt.

Przeszarżowałeś znacznie wcześniej. Multipleksowanie na 13 to gruba przesada. W praktyce 8 to maksimum, co oznacza, że powinieneś mieć dużo więcej wyprowadzeń do sterowania segmentami - będziesz zapalał po dwie cyfry równocześnie. Multipleksowanie na 7 łlub 8 wymaga sporych wydajności prądowych dla segmentów - wypadałoby użyć specjalizowanego układu drivera, np. serii MBI.

Dość dużym wyzwaniem jest tu też samo uruchamianie oprogramowania - musisz ustawić takie natężenie prądu segmentów, że zatrzymanie multipleksowania np. wskutek błędu może powodować uszkodzenie wyświetlacza.

W praktyce nie jest tak źle. Robiłem multipleksowanie 1:16 i działało sprawnie, nawet bez przekraczania douszczalnego stałego prądu segmentu. Technika idzie do przodu, a LEDy są naprawdę ultrajasne, w efekcie dutycycle 1:13-1:16 to nie jest problem.
BTW, SCT2024 to właśnie specjalizowany układ sterowania LEDami, podobnie jak wspomniany przez ciebie MBI.

Teraz to już sam się trochę zakręciłem jak to ma działać ;/ Po kolei. A więc mam 13 wyświetlaczy LEDy 14-segmentowych ze wspólną anodą. Więc na wspólne elektrody podaje Vcc i aby zaświecił się dany segment wyświetlacza na jego linie od A..P powinno pojawić się GND? Zatem jakie zadanie ma wykonać układ SCT2210 w tym miejscu ?

Co do prądu ile pobiera wyświetlacz to według tego:

przyjmuję, że jest to 30mA na jeden segment, czy dobrze rozumiem?

Jeśli dobrze rozumiem to układ SCT2210 ma zakres prądu od 5÷90mA na pojedynczy kanał czy na wszystkie 16? Zgodnie z poborem prądu przez pojedynczy segment tj.30mA dodałem rezystor 630 Ohm na wyjście REXT co ogranicza prąd do 30mA na wszystkich wyjściach układu?

Czyli mam połączone dwa 16-bitowe rejestry. Pierwszy jest od wybierania wyświetlacza, jeśli są same "0" w rejestrze tzn. że wszystkie wyświetlacze są wyłączone ?
A drugi rejestr od zapalania poszczególnych segmentów wybranego wyświetlacza i tutaj jeśli w rejestrze są same "0" to cały wyświetlacz świeci ?


Poprawiony schemat:



I ostatnie pytanie jak powinno wyglądać poprawnie połączenie tych rejestrów z procesorem z jego hardwarowym SPI ?

Na wspólne anody podajesz dodatni biegun przez tranzystory PMOS, którymi sterujesz z portu lub z dekodera, np. HC138 albo 154. Prąd drivera LED jest specyfikowany na kanał. Do wspólnych anod tego drivera nie użyjesz - on ma źródła prądowe do sterowania katod, o ile dobrze pamiętam. Prąd anod nie może być stabilizowany, bo będzie zależał od tego, ile segmentów świeci. Będziesz potrzebował przerwania timera zgłaszanego z częstotliwością rzędu 4..6 kHz, więc trzeba to rozsądnie oprogramować, żeby staruszek ATmega jakoś się z tym wyrobił.

Przy czym jednak zamiast HC138, lepiej to zrobić również na rejestrze. Dzięki temu nie potrzeba kolejnych pinów IO do sterowania 138. Do sterowania driverami anod można użyć P-MOSFET, np. wspomnianego przeze mnie wcześniej IRLML9301 sterowanego albo z SCT (tu prąd nie ma znaczenia), albo z dwóch 74HCT595.
Samo multipleksowanie to banał, nawet dla 4-6 kHz z SPI, to będzie nie więcej niż 1 MIPS potrzebny.

Czy teraz jest już wporząku? W jaki sposób ma być podłączony pierwszy SCT2210 do procesora?
Dlaczego ten tranzystor IRLML9301 co podałeś ma ujemne napięcie Vgs(th) ?

Na pierwszy rzut oka wydaje się, że jest ok. Tylko dodaj kondensatorów odsprzęgających, bo SCT też ich potrzebują. No i zrób coś z czytelnością tego schematu. Mam wrażenie, że symbol PE to coś innego niż masa. Stosuj się do zasad.
Ok, teraz z innej paczki - widzę, że masz tam USB "softwarowe" i tego typu udziwnienia. Połączenie USB softwarowego + taka multipleksacja może być pewnym wyzwaniem ale się da. Ale, można też rozważyć porzucenie archaizmu jakim jest ATMega8 (ze względu właśnie na to USB, nie multipleksowanie) i użycie nowszego AVR, np. XMEGA? Mają USB, przykład muplipleksowania na XMEGA, akurat matrycy 8x8x2, ale to bez znaczenia znajdziesz w darmowych przykładach do mojej książki o XMEGA. Przykład użycia USB sprzętowego z tym prockiem znajdziesz na blogu:
http://mikrokontrolery.blogspot.com/2011/03/X...emulacja-portu-szeregowego-rs-232-na-USB.html
Na jednym i drugim da się to zrobić, przy czym na tym drugim prościej i efektywniej.

Dlaczego ten tranzystor IRLML9301 co podałeś ma ujemne napięcie Vgs(th) ?

tmf chyba mnie przekonałeś do XMEGA głównie tym: "Dlaczego XMEGA?" Ale czy są jakieś rady który uC wybrać dla siebie?

Który z XMEGA? Jeśli potrzebujesz USB to wybierz taki z literką U w nazwie, np. A1U, A3U itd. Ale nie AU bo to coś innego. Rodzina A4U będzie odpowiednia. W farnellu masz za 15zł/sztuka xmega128A4U, w tqfp44. Ew. masz tańszą 64B3 w tqfp64. Można wejść w tanie E5 w cenie 6-9zł, ale te nie mają USB.
Jak pisałem wiele przykładów jak z tym zacząć masz w darmowych przykładach do mojej książki, warto przejrzeć.

A taki żeby miał USB, szybki ADC, obsługę sprzętową enkodera optycznego i dało się go zaprogramować w łatwy sposób ?

To już lepiej zabierz się za Cortexy, LPC17xx albo STM32F2, F3

A który uC AVR czy ARM będzię łatwiejszy do uruchomienia i jego programowania i który będzie szybszy ?

pawel1730 wrote:

A który uC AVR czy ARM będzię łatwiejszy do uruchomienia i jego programowania i który będzie szybszy ?

Co to znaczy szybszy? Określ jaką szybkość potrzebujesz.
Szybkie ADC (2x2Msps, 12-bitów) ma rodzina XMEGA A, Wszystkie XMEGA AU i B mają sprzętowe USB, wszystkie XMEGA mają sprzętową obsługe enkodera, także optycznego, także z indeksem.
Także sprecyzuj potrzeby. Twoje multipleksowanie np. da się zrobić na XMEGA całkowicie sprzętowo, tak, że po skonfigurowaniu peryferii procesor może iść spać.
Co do programowania - wszystkie XMEGA mają PDI/JTAG, więc programuje się je podobnie jak poprzednie (potrzebujesz klonów programatorów z MkII w nazwie), można też użyć bootloadera - tylko ktoś ci go musi wgrać.
Co do łatwości - biorąc pod uwagę że wsparcie dla AVR masz ogromne i wszystko chodzi po zainstalowaniu Atmel Studio, w nic nie musisz się bawić, żadne konfiguracje, to prostota AVR vs. ARM jest oczywista.

tmf wrote:

Co to znaczy szybszy? Określ jaką szybkość potrzebujesz.

Masz rację źle się wyraziłem. Pasowałby jakiś z USB, żeby dał radę prze enkoderze 2500ppr, kilka kanałów dla przetworników ADC tak około 4-5, oraz te 14 wyświetlaczy 14-segmentowych i dał rade jeszcze obsłużyć 60 przycisków. Jeśli to by dał radę ogarnąć to to dla mnie oznacz szybki.
Co byś poradził oczywiście Xmega, tak żeby dał sobie z tym radę i jakoś koszty obsługi były do zaakceptowania ?

Jak pisałem multipleksowanie na XMEGA nie zżera czasu procesora, bo da się to zrobić sprzętowo, a i programowo to kwestia 1 MIPSa może. Enkoder jest obsługiwany sprzętowo więc również czasu CPU nie zżera. ADC XMEGA A ma dwa niezależne, każdy z 16-kanałowym multiplekserem, ale łącznie masz 16 wejść analogowych i dwa niezależne ADC 2 Msps. 60 przycisków to też nie problem, zakładam, że raczej jakąś matrycę tworzą? USB jest sprzętowe więc też za dużo CPU nie żre. No i masz 32 MIPSY, nie 16 jak na ATMega8. Określ ile potrzebujesz pinów IO. XMEGA A3U są w obudowie tqfp64, XMEGA A1U w tqfp100, w związku z czym mają więcej pinów IO.
Koszty obsługi - nie za bardzo rozumiem co masz na myśli.

tmf wrote:

Koszty obsługi - nie za bardzo rozumiem co masz na myśli.

Miałem na myśli koszt programatora. Myślę, że 64 piny powinno wystarczyć.

Dodano po 58 [minuty]:

Abstrahując od wyboru Xmegi miałem jeszcze przygotowany taki schemat dla 1 wyświetlacza:




Tutaj mam pytanie czy poprawnie zapisuje dane do tych dwóch rejestrów 74LS164?

A taki mam kod programu:



Po wykonaniu tego kodu spodziewałem się na wyjściach pierwszej kostki(ta bliższa od procesora) mieć napięcia same blisko zeru a na drugim rejestrze same bliskie napięcie bliskie Vcc a tym czasem na pierwszej kostce mam w okolicach 3V a drugiej 2,5V.

Masz w programie błąd - zanim ustawisz tryb master SPI, koniecznie linia SS jeśli jest wyjściem musi być w stanie wysokim, inaczej SPI przejdzie w tryb slave.
Drugi "błąd", który nie pozwoli ci zaobserwować stablinych stanów, to wysyłanie w pętli danych. Ponieważ dane przechodzą przez wyjścia, które nie mają zatrzasków, więc na rejestrach tak naprawdę masz naprzemiennie 1 i 0. Średnia w okolicach 2,5 V to odzwierciedla.
Trzecia sprawa - 164 nie nadaje się do sterowania LED - brak zatrzasków powoduje, że bity wsuwane na starsze pozycje przelatują przez młodsze i robią sieczkę z wyświetlania.
Co do kosztów - klon AVRISPMkII to koszt 50-60 zł.

Ok, dzięki.
Czyli przerobie to na 74HC594. Ale jeśli zrobiłbym to tak, że przy wyłączonym wyświetlaczu zapisuje dane do rejestru 74HC164 i po wpisaniu włączył wyświetlacz, czyli zapisywał dane tylko przy wyłączonych wyświetlaczach, to wtedy by działało?

Wracając do Xmegi jak polecasz procesor spełniający te wymogi co pisałem wcześniej, czy to obojętne który byle by z serii AU lub B?

Tak, jeśli będziesz wyłączał wyświetlacz na czas modyfikacji rejestru to to zadziała. Tylko ograniczy ci duty cycle, co jakośtam odbije się na jasności. Użycie 595 jest sensowniejsze.
Co do XMEGA - w twoim przypadku tak. Seria AU ma szybszy ADC (2x2Msps), A1U jest w tqfp100, a3U w tqfp64, a4U w tqfp44. Seria B ma wolniejszy ADC (brak potoku), ale za to ma kontroler LCD, dzięki temu możesz podłączyć tanie LCD bez kontrolerów (te "szybki").

W taki sposób niby działałoby na '164, ale po co, skoro HC595 jest wygodniejszy w użyciu i równie tani? Policz czas transmisji: sama transmisja to 128 cykli zegara procesora, narzut programowy - jakieś 20 cykli, a przy 13 wyświetlaczach trzeba ją powtarzać ok. 4000 razy na sekundę i na ten czas zgasić wyświetlacze, które i tak zbyt jasno nie świecą.
Przy takim multipleksowaniu potrzebujesz min. 30 mA (raczej ok. 40..50 mA) na segment - z układów serii 74HC takiego prądu nie wyciągniesz. Brniesz w ślepą uliczkę.

Co do programatora: gdybyś użył współczesnego układu, nie potrzebowałbyś programatora - nowe uC mają wbudowany bootloader i programują się przez port szeregowy lub USB. Przydaje się za to interfejs do debugowania, który kosztuje tyle, co jakiś AVRISP (tylko że AVRISPem nie zdebugujesz ATmega8, bo starsze uC w ogóle nie mają możliwości debugowania).