Elektroda.pl
Elektroda.pl
X
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Sterownik wyświetlacza matrycowego LED 8*48

piotrva 10 Sep 2011 20:35 31351 32
  • Sterownik wyświetlacza matrycowego LED 8*48

    Witam, chciałbym wszystkim przedstawić projekt sterownika matrycowego wyświetlacza LED. Na początek proszę tylko o nie ocenianie wykonania płytki (na płytce uniwersalnej/pająk) bo jestem świadomy jak ona wygląda i jak ją wykonałem.

    Historia
    Pomysł projektu narodził się, gdy jakieś pół roku temu nabyłem od Kolegi assembler z forum matrycę LED o rozmiarach 8*48 pikseli (w rzeczywistości to 2 moduły 8*24 połączone razem). Matryca posiadała już zamontowane sterowniki kolumn na układach 74HC595, a także miejsce na zamontowanie u dołu płytki procesora ATMega8 lub kompatybilnego pinowo, dekodera do wierszy oraz tranzystorów mocy i... na tym koniec. Nie wystarczało to do realizacji mojego minimum, które założyłem, czyli punkt następny:

    Założenia
    Założeniami projektu było:
    1. Wykorzystanie zakupionej matrycy LED
    2. Wykonanie sterownika w oparciu o mikrokontroler z rodziny AVR
    3. Sterownik powinien zawierać:
    a. kompletny moduł zasilania oraz sterowania wierszami, wyprowadzenia do połączenia już gotowych sterowników kolumn
    b. zegar czasu rzeczywistego
    c. termometr
    d. pamięć nieulotną EEPROM do przechowywania tekstów i "programu animacji"
    e. możliwość programowania "animacji" przez UART/RS232 z komputera
    f.* możliwość alternatywnego programowania z klawiatury matrycowej 4*4
    4. Wykorzystanie części walających się po pudełeczkach, a nie potrzebnych do czego innego
    5. Przede wszystkim podszlifowanie C, z mniejszą dbałością o estetykę płytki i minimalizacja kosztów wykonania (stąd wykonanie całości na płytkach uniwersalnych)

    *podpunkt f. nie został zrealizowany z powodu braku pamięci flash procesora po zrealizowaniu wcześniejszych założeń.

    Opis
    Cały projekt składa się z 3 części: matrycy, części "wysokonapięciowej" sterownika oraz części logicznej sterownika - kontrolera

    Matryca
    Sterownik wyświetlacza matrycowego LED 8*48
    Matryca to wspomniana przeze mnie wcześniej matryca zakupiona od Kolegi z forum.
    Wymiary: 8*48 pikseli, 490*120mm
    Kontroler kolumn: 6 układów 74HC595 połączonych szeregowo, ze wspólnym wyprowadzeniem "Latch Enable"
    Zalecane napięcie zasilania diod (impulsowo): 7,5V
    Miejsce na podstawowy system sterowania - nie wykorzystane - zamiast tego wyprowadzenie złącz do sterownika kolumn i do wierszy

    Sterownik - część "wysokonapięciowa"
    Sterownik wyświetlacza matrycowego LED 8*48
    Sterownik ze względu na miejsce na płytkach uniwersalnych i względy czysto logiczne podzieliłem na 2 części na osobnych płytkach. Pierwszą z nich jest część zawierająca:
    Stabilizator napięcia: 7805 - do zasilania 2 płytki i układów 74HC595 - napięcie zasilania całej płytki to 7,5V podawane bezpośrednio na kolektory tranzystorów, stąd za ukłądem 7805 otrzymujemy napięcie nieco niższe niż 5,0V, ale w pełni wystarcza ono do poprawnej pracy całości
    Złącze zasilania: kostka ARK i goldpiny do zasilacza
    Driver wierszy: 74HC595 wpięty szeregowo ze złączem do podłączenia driverów kolumn na matrycy - dzięki temu całą matrycą sterujemy tylko 4 pinami procesora
    Tranzystory do wysterowania wierszy (8 sztuk): BD679A
    Złącza: do podłączenia driverów kolumn, złącz wierszy na matrycy, linii sygnałowych z 2 płytki sterownika oraz zasilanie 2 płytki sterownika

    Sterownik - kontroler
    Sterownik wyświetlacza matrycowego LED 8*48
    Drugą częścią sterownika jest kontroler, zawiera on:
    Procesor: ATMega8 taktowany zewnętrznym kwarcem 16MHz - wybór padł ze względu na chęć wykorzystania tego co leży w szafce, normalnie (biorąc pod uwagę ilość pinów I/O i pamięć flash) wybór padłby na pinowy odpowiednik - ATMega168
    Zegar czasu rzeczywistego: klasycznie PCF8583 - z szafki
    Pamięć EEPROM: AT24C16 - z szafki
    I tu bardziej obeznani elektronicy zaraz krzykną "Hola, hola - konflikt adresów murowany między tymi układami na I2C"
    Owszem, mógłbym zastosować tu inną pamięć o większej pojemności i innym adresowaniu, ale przyświecała mi idea, żeby wykorzystać posiadane już elementy, stąd mając odpowiednią kostkę w SMD i uniwersalną SMD-przejściówkę na DIP wykonałem prosty przełącznik magistrali I2C:
    Przełącznik magistrali I2C: CD4053
    Zasada działania jest prosta - wykorzystałem 2 z 3 linii tego układu - ich wspólne zakończenia są podpięte do procesora, a te, którymi możemy sterować odpowiednio do układu PCF8583 (1 para) i AT24C16 (2para) - jeśli chcę się komunikować z zegarkiem to na linie sterujące układu (spięte razem i podpięte do jednego pinu uP) podaję stan wysoki - jeśli chcę się komunikować z pamięcią EEPROM - podaję na te linie stan niski
    Termometr: DS18B20 - gniazdo na 1 na płytkę i złącze do podpięcia drugiego na kablu - na razie nie używane, gdyż program obsługuje tylko jeden termometr z powodu braku pamięci FLASH procesora
    Układ podtrzymania RTC: klasycznie, 2 diody 1N4148 + złącze do podpięcia pakietu baterii 2xAA (na płytce nie zmieściła się podstawka na CR2032 lub podobną)
    Złącza: do podłączenia płytki "wysokonapięciowej" - jak w jej opisie, do podłączenia baterii podtrzymujących, złącze RS232/TTL (Rxd,Txd,GND) do programowania z komputera, złącze ISP, 2x złącze do DS18B20, złącze do klawiatury matrycowej 4*4 + diody 1N4148 do "wyzwalania" przerwania przy naciśnięciu przycisku - nie wykorzystane z powodu braku pamięci FLASH na obsługę klawiatury

    To właściwie cały sterownik od strony technicznej
    Sterownik wyświetlacza matrycowego LED 8*48 Sterownik wyświetlacza matrycowego LED 8*48

    Oprogramowanie
    Oprogramowanie powstało w całości w C i AvrStudio 4. Do obsługi I2C, termometru DS18B20 i SPI wykorzystałem częściowo zmodyfikowane przeze mnie biblioteki z książki Pana Mirka Kardasia, z której zaraz po jej wydaniu uczyłem się C. Kod jest nieco zabałaganiony jak na chwilę obecną, większość funkcji jest po prostu dopisana w pliku main.c zamiast w osobnych plikach stąd, dopóki kod nie będzie uporządkowany i odpowiednio skomentowany (w bardziej zrozumiały sposób niż moje prywatne komentarze) postanowiłem go nie udostępniać publicznie.
    Czcionkę wraz z polskimi znakami wygenerowałem przy użyciu świetnego programu innego Kolegi z naszego forum: https://www.elektroda.pl/rtvforum/topic1870982.html Mimo to czcionki ze względu na okropnie wyglądające duże wersje większości polskich znaków diakrytycznych wymagają pewnych modyfikacji (obniżenia o 1px i modyfikacji liter używających dolnej linii).

    Funkcje jakie wspiera oprogramowanie:
    1. Wyświetlanie temperatury przez określony czas (1-255s)
    2. Wyświetlanie aktualnego czasu przez określony czas (1-255s)
    3. Wyświetlanie statycznego tekstu (do 8 znaków) przez określony czas (1-255s)
    4. Wyświetlanie przewijanego tekstu dowolnej długości (ograniczonej wolną pamięcią EEPROM) z regulowanym opóźnieniem "przeskoku" o 1px w zakresie 1-255ms)
    5. Programowanie z poziomu terminala RS232 w prostym tekstowym menu

    Programowanie odbywa się w następujący sposób:
    1. podłączmy kabel RS232/TTL do układu (lub przejściówkę USB<>RS232 itp.)
    2. łączymy się z terminalem w podstawowym trybie: 9600 8-N-1 z wysyłaniem po wciśnięciu klawisza ENTER znaków CR+LF (rn)
    3. wciskamy klawisz ESC - następuje wejście w tryb programowania a na matrycy wyświetla się napis "PC-CON"
    4. programujemy poruszając się po menu, mamy możliwość:
    a. ustawienia czasu
    b. programowania sekwencji animacji (nadpisujemy poprzednią)
    Programowanie odbywa się w intuicyjny sposób, aby wprowadzić polski znak w trybie wprowadzania tekstu wciskamy klawisz ESC, a we wprowadzanym tekście pojawia się apostrof. Następnie wprowadzamy literę do której ma zostać dodany "ogonek" lub inne polskie udziwnienie - dalej piszemy normalnie
    5. zakańczamy ewentualną sesję wgrywania programu animacji, aby dodać na koniec wprowadzonych danych znacznik powrotu adresu do początku programu
    6. możemy powtórnie wybrać opcje a lub b albo
    7. wciskamy klawisz ESC w "menu głównym" co zakańcza tryb programowania - zapisana animacja zaczyna się wykonywać i możemy odłączyć kabel od komputera i zamknąć połączenie
    Sterownik wyświetlacza matrycowego LED 8*48 Sterownik wyświetlacza matrycowego LED 8*48

    Pełna galeria:
    Sterownik wyświetlacza matrycowego LED 8*48 Sterownik wyświetlacza matrycowego LED 8*48 Sterownik wyświetlacza matrycowego LED 8*48 Sterownik wyświetlacza matrycowego LED 8*48 Sterownik wyświetlacza matrycowego LED 8*48 Sterownik wyświetlacza matrycowego LED 8*48 Sterownik wyświetlacza matrycowego LED 8*48

    Filmiki z działania:
    V1.0:




    V2.0:




    Z góry dziękuję za konstruktywne komentarze i ponownie proszę o nie komentowanie wyglądu i jakości wykonania płytek.

    Uwagi do załączonych kodów - zgodnie z Prawami Autorskimi niektóre dołączone biblioteki są integralną częścią książki pana Mirka Kardasia i nie mogą być publicznie udostępniane - na podstawie plików nagłówkowych *.h można napisać własne funkcje spełniające odpowiednie działania.

    UPDATE #1:
    LED_matrix_controller_V1.0_2011_09_12
    Załączam program w wersji 1.0 - czyli oryginalna wersja której działanie widać na filmiku i zdjęciach po względnym uporządkowaniu kodu.

    UPDATE #2:
    LED_matrix_controller_V1.5_2011_09_13
    Nieco zoptymalizowana wersja programu, zmiany w stosunku do poprzedniej:
    1. przeniesienie tekstów menu programowania do pamięci EEPROM
    2. dodanie dynamicznego ustalania szerokości liter dla tekstu przewijanego
    3. czcionka v2 - nieco poprawione "polskie" literki, większość obniżona o 1px w dół
    4. załączone pliki czcionek do edycji w generatorze wymienionym w opisie wyświetlacza

    UPDATE #3 - final:
    LED_matrix_controller_V2.0_2011_09_15
    Finalna wersja programu, zmiany w stosunku do poprzedniej:
    1. Obsługa 2 termometrów i 2 ikonek (słoneczko i domek)
    2. Wyszukiwanie termometrów w trybie programowania
    3. Osobne programowanie wyświetlania pierwszego i drugiego termometru, dowolne przypisanie ikonek (podczas programowania dodatkowa opcja Conf.: xy, gdzie x - numer ikonki (0-1), y - numer termometru (0-1))
    4. przechowywanie ID termometrów w pamięci EEPROM procesora (w przypadku awarii komunikat error, można zmienić to i ustawić flags.done=0 w razie błędu, aby pominąć w ogóle odczyt z danego termometru w razie jego uszkodzenia/wypięcia)

    Cool? Ranking DIY
    About Author
    piotrva
    VIP Meritorious for electroda.pl
    Offline 
    Has specialization in: mikrokontrolery
    piotrva wrote 6404 posts with rating 700, helped 623 times. Live in city Kraków. Been with us since 2008 year.
  • #2
    mirekk36
    Level 42  
    Bardzo fajne wykorzystanie staruszka ATmega8 ;) ... sam nie mam ciągle czasu zabrać się za wyświetlacz matrycowy ale po takich projektach odczuwam coraz większe ciśnienie.

    Generalnie bardzo ładnie wszystko działa - ale mam jedno pytanie jeśli można. Bo nawet na tej pierwszej klatce z filmu widać, że przy literach t oraz l i chyba przy ogonku litery ś, są jakby rozdwojone kolumny. Wiem i czuję, że po prostu kamera uchwyciła moment gdy zaczynało się przesuwanie, jednak mam też wrażenie, że przesuwanie odbywa się tak jakby troszkę skokowo.... no i właśnie - może to też tylko efekt po nakręceniu video - a w rzeczywistości może jednak działa to bardzo płynnie ??? Możesz mi powiedzieć tak ogólnie - jaką metodą przesuwasz tekst albo hmm zawartość wyświetlacza ??? czy przesuwasz w lewo zawartość jakichś bajtów czy też po prostu z jakąś częstotliwością odrysowujesz na nowo fonty w innej pozycji ??? ... pytam bo to dla mnie ciekawe tematy ;), których jeszcze nie dotykałem...

    aha ... masz jakieś praktyczne zastosowanie u siebie tego fajnego wyświetlacza ???
  • #3
    Karol966
    Level 31  
    piotrva wrote:
    konflikt adresów murowany między tymi układami na I2C"

    Możesz napisać dlaczego konflikt adresów murowany? Jakoś tego nie widzę, w tej pamięci masz aż 3 linie adresujące oraz jedną linię w kostce PCF8583...
    Nie wiem, może jest za wcześnie ale nie rozumiem skąd pojawił Ci się tutaj konflikt
  • #4
    mirekk36
    Level 42  
    Karol966 wrote:
    piotrva wrote:
    konflikt adresów murowany między tymi układami na I2C"

    Możesz napisać dlaczego konflikt adresów murowany? Jakoś tego nie widzę, w tej pamięci masz aż 3 linie adresujące....


    No to może jednak, skoro piotrva pisze o tym, że będzie konflikt to warto przyjrzeć się dokładnie notom aplikacyjnym PDF kostek 24c16. Bo jednak - jak kolega dobrze poczyta i poszuka to okaże się, że nie ma jednak ani jednej linii adresowej ;) Żeby sobie samemu to udowodnić - proszę znaleźć chociaż jedną notę PDF gdzie wyraźnie będzie ta kostka np firmy Microchip albo ST opisana - i pokazać na ją tutaj, żeby udowodnić, że są w niej i to aż 3 linie sterujące jak napisałeś. Dzięki temu sam szybko wyprowadzisz się z błędu.
  • #5
    maly_elektronik
    Level 23  
    Zmniejsz trochę szerokość pola bitowego dla liter "l" i "i" bo gdy pojawią się jedna obok drugiej będzie to wyglądało jak spacja :)
  • #6
    Karol966
    Level 31  
    mirekk36 wrote:
    znaleźć chociaż jedną notę PDF gdzie wyraźnie będzie ta kostka


    Faktycznie, jest wcześnie

    Quote:

    The 16K does not use any device address bits but instead
    the 3 bits are used for memory page addressing. These
    page addressing bits on the 4K, 8K and 16K devices
    should be considered the most significant bits of the data
    word address which follows. The A0, A1 and A2 pins are no
    connect.
  • #7
    piotrva
    VIP Meritorious for electroda.pl
    A więc od końca.
    1. Litery i i j, będzie to trudne, bo wymagałoby to zupełnie innego umieszczania czcionek i skomplikowało wiele funkcji
    2. Uwagi kolegów dot. 74hc595, owszem nie jest to odkrywcze, powiem nawet że cały projekt to nic ponad standardowe aplikacje układów - racja nic nowego i odkrywczego, można rzec było setki razy. Z drugiej strony czy mój układ źle działa? Po co do czegoś takiego fpga, czy to z kolei nie przerost formy nad treścią?
    3. Co do przesuwania, to jest tak, są 2 bufory, jeden wykorzystywany do odswierzania, drugi do generowania ekranu. Potem w 8 krokach bufor jest kopiowany. Przesuw jest lekko skokowy, bo opóźnienie wynosi 0,11s, ale nie jest to nieprzyjemne dla oka w rzeczywistości - kamera niestety nie jest wstanie tego dobrze oddać i łapie moment kopiowania nie widoczny gołym okiem. Na dniach powinienem uporać się z porzadkami w kodzie więc będzie można zerknąć co i jak, choć to też nic odkrywczego - standardowy kod obsługi takiej matrycy.
  • #8
    nsvinc
    Level 35  
    Pytanie, czemu czcionka jest monotypowa... Nie jest trudno napisac algorytm, który przed renderowaniem znaku do bufora sprawdzi jego szerokość, doda chciany spacing a następnie przekaże dalej punkt od którego ma się zaczynać następny znak. Ja już od wieków nie wyświetlam niczego z monospacingiem ;]

    Jak jest zrealizowana charmapa? W puszce 8x8bajtów na znak, kazdy bit odpowiada konkretnemu pixlowi, i tu gdzie jest jedynka, tu świeci led?

    Co do buforowania - czy aby to na pewno jest double buffering? Czy działa to tak, że jeden bufor jest wyświetlany, gdy na drugim robi się shift pixli i dostawienie nowych? Jesli tak, to imho to lekka lipa. Jeśli na matrycy ma byc wyswietlany głównie przesuwający się tekst, to zupełnie nie ma potrzeby stosować dwóch buforów i kopiowania jednego w drugi.
    Wystarczy jeden bufor znacznie większy, w który renderują się znaki. A funkcja wyświetlająca bufor pobiera numer kolumny w tym buforze, od którego ma zacząć popychać znaki na wyświetlacz...
  • #10
    mirekk36
    Level 42  
    VSS wrote:
    Ok, ale gdzie schemat i wsad do proca ??

    A masz gdzieś panie kolego napisane w regulaminie forum, że każdy projekt DIY musi zawierać schemat i wsad do procka dla ciebie ???? Wszystko trzeba podać na tacy? - nie wystarczy sama inspiracja i chęć pomocy autora w ramach zadawanych pytań. A tym bardziej, że autor pisał co z wsadem i kodem źródłowym. Proponuję więc jeszcze raz uważnie przeczytać cały pierwszy post.
  • #11
    piotrva
    VIP Meritorious for electroda.pl
    @nsvinc, 2 bufory są konieczne bo inaczej podczas zmiany zawartości wyświetlacz migał. Co do definiowania indywidualnej szerokości znaków o ile flash pozwoli po optymalizacji (na razie mam 98%, planuje przenieść teksty menu programowania do eeprom procesora) to dodam je w trybie przewijania - dzięki za radę i pomysł na realizację.
    Co do programu to jak pisałem na początku wymaga porządków, co do schematu - na razie jest on w mojej głowie i na parunastu kartkach noszących znamiona skreśleń i setki odnośników i nie wiem czy będzie mi się chciało to przerysować na komputerze...
  • #12
    I3odzio
    Level 9  
    Witam
    Niektórzy koledzy pisali że autor mógł się postarać i wykonać sterownik matrycy diod na czymś ambitniejszym niz popularne układy 595.

    W związku z tym proszę kolegów o zaproponowanie jakichś ciekawych układów, które możnaby w prosty sposób wykorzystać do sterowania matryc diodowych np 8x8.

    Dobrze by było żeby koszt drivera nie przerósł kosztu matrycy, którą będzie sterował...
    (to kolejny argument za 595 ale czekam na propozycje)

    pozdrawiam
  • #13
    mirekk36
    Level 42  
    I3odzio wrote:
    Witam
    Niektórzy koledzy pisali że autor mógł się postarać i wykonać sterownik matrycy diod na czymś ambitniejszym niz popularne układy 595.

    W związku z tym proszę kolegów o zaproponowanie jakichś ciekawych układów, które możnaby w prosty sposób wykorzystać do sterowania matryc diodowych np 8x8.


    Dla mnie osobiście jest to lekkim bezsensem, twierdzić, że sterownik matrycy na forum powinien być wykonany na czymś ambitniejszym niż 595. Bo czymże będzie się różniła w działaniu taka matryca od tej zrobionej chociażby w tym temacie, gdy zastosujemy nieco droższe scalaki np typu MBI1816GT , które wprawdzie nie wymagają rezystorów dla diod LED ale są ok 4-5 razy droższe. Bo taki 595 kosztuje ok 1zł natomiast MIB ok 4zł. Zresztą co tam cena, i tak w jednym i drugim przypadku nie gra roli bo jest pomijalna wobec pozostałych kosztów a i tak większość efektu działania takiej matrycy zwykle zależy od sposobu jej oprogramowania.

    Dlatego czy to będzie słynny scalak 595, 161, MIB czy dowolny inny rejestr przesuwny - to jeden czort ;) Można zrobić na najbardziej ambitnym scalaku (chociaż nie do końca rozumiem tutaj przymiotnika "ambitny") a jeśli się spartoli oprogramowanie to wyjdzie na jedno a na pewno dużo gorzej niż w tym temacie ;)
  • #14
    piotrva
    VIP Meritorious for electroda.pl
    Cóż, to samo pytanie zadałem wcześniej, po co pakować jakieś wymyślne układy, skoro staruszki świetnie się spisują? Po co do czegoś takiego FPGA, skoro zwykły AVR taktowany kwarcem 16MHz sobie spokojnie z tym radzi, a i tak nie jest krytycznie obciążany tym sterowaniem? Poza tym, jeśli na tym AVR zastosowałbym np. wspomnianą ATMega168 lub nawet 328(p) i dorobił odpowiednie oprogramowanie na PC z okienkowym programowaniem animacji oraz dałbym normalną pamięć (a nie udziwnienia z kostką 24c16) i lepszy zegar niż PCF8583 (np. "odpowiednik" od dallasa) to w czym to rozwiązanie ustępowałoby komercyjnym tablicom tego typu? (Oczywiście obecna wersja ma się do takowych nijak z powodu interfejsu programowania i wad związanych z szerokością liter oraz swoim rozmiarem - komercyjne mają zwykle większe "rozdzielczości" i rozmiary)

    Dodano po 9 [minuty]:

    Dodałem pełne źródła oprogramowania - opis w pierwszym poście.
  • #15
    piotrva
    VIP Meritorious for electroda.pl
    Nowy kod źródłowy - dodałem według porad dynamiczne szerokości literek, nieco poprawiłem polskie czcionki i odzyskałem nieco flasha przenosząc napisy wysyłane po RS232 do dotychczas nieużywanej wbudowanej pamięci EEPROM procesora - obecnie zajętość pamięci:
    FLASH: 92%
    RAM: 24%
    EEPROM (w procesorze): 90%

    Wkrótce postaram się zamieścić filmik z działania tego zmodyfikowanego przewijania tekstu.

    Dalsze plany rozwoju "projektu":
    1. Dodanie obsługi 2-giego termometru DS18B20
    2. Optymalizacja bibliotek do obsługi DS18B20 - zrezygnowanie z gotowych na rzecz ręcznego wysyłania poleceń 1wire
  • #18
    piotrva
    VIP Meritorious for electroda.pl
    1. Matryca do wykorzystania mojej czcionki bez zmian jest za mała - ja mam znaki o wymiarach 6*8 - lepiej poszukać matryc 8*8 i połączyć takie 3 lub 6.
    2. Jeśli stosowałbyś 74hc595 to trzeba jeden taki rejestr na 8 kolumn + rezystory 60-100 ohm na każdą kolumnę. Nie wiem czy uln2803 wydoli prądowo przy większej matrycy o większej szerokośc trzebaby to policzyći.
  • #20
    piotrva
    VIP Meritorious for electroda.pl
    Trudny do oszacowania:
    1. Matryca - gotowa i zmontowana, z tego co pamiętam dałem za nią nieco poniżej 100zł
    2. Sterownik - większość elementów miałem jako pozostałości po innych projektach lub po prostu znajdowały się w moim "składziku" - jedyne co kupowałem to tranzystory (za wszystkie dałem ok. 10 zł) i jedną z płytek uniwersalnych (9 zł)
    Tak na oko myślę, że całość zamknęłaby się w kosztach 200-250 zł.
  • #22
    asembler
    Level 32  
    Szkoda że nie wykorzystałeś na płytce miejsca w którym mozna było umiescic atmegę8,dekoder wierszy, tranzystory sterujace ,eeprom, RTC,stabilizator,złacze do programowania i interface RS. Mozna było to zrobic bez uniwersalnej płytki i jedynie doprowadzić zasilanie.
    Program przewiduje możliwość sterownia dłuższą matrycą? Na przykład 128x8.
    Dwa bufory są niepotrzebne.
  • #23
    piotrva
    VIP Meritorious for electroda.pl
    1. Schematu jak powiedziałem nie będzie
    2. Nie wykorzystałem miejsca, bo na wszystko by i tak nie starczyło i wtedy poza tym na samej płytce byłaby plątanina kabli - a tego nie chciałem.
    3. Program po malutkiej modyfikacji może obsłużyć matryce o rozmiarach do 56*8 (buforem jest tu zmienna 64-bitowa). Po dalszej modyfikacji (trochę większej) można sterować większymi matrycami - oczywiście kosztem pamięci flash i ram.

    Dodano po 5 [godziny] 26 [minuty]:

    Publikuję wersję finalną V2.0, opis w pierwszym poście, filmik z działania także. Jak na chwile obecną projekt uważam za sfinalizowany - zostały zrealizowane wszystkie założenia projektowe (za wyjątkiem klawiatury, ale to już nie na siły ATMega8).
    Obecna zajętość pamięci:
    
    AVR Memory Usage
    ----------------
    Device: atmega8
    
    Program:    7860 bytes (95.9% Full)
    (.text + .data + .bootloader)
    
    Data:        250 bytes (24.4% Full)
    (.data + .bss + .noinit)
    
    EEPROM:      510 bytes (99.6% Full)
    (.eeprom)
    
  • #24
    asembler
    Level 32  
    Jaka czestotliwość multipleksowania?
  • #26
    davinco
    Level 11  
    Witam.

    Właśnie pracuję nad podobnym wyświetlaczem.
    ATMega32 (bo nie miałem wolnej 8ki ;-)), ULN2803 x1, 74HCT595 x3, zasilanie obecnie z USB (via programator ;-)).

    4 panele diodowe takie jak te: Link Docelowo więcej - obecnie koncentruje się na sofcie, który zapewne zostanie upubliczniony w postaci źródeł ;-)

    Póki co pajęczyna na płytce prototypowej. Pracuję nad tym głównie w weekendy, jak skończę to opiszę ;-)








    Pozdrawiam!
  • #27
    piotrva
    VIP Meritorious for electroda.pl
    davinco wrote:
    zasilanie obecnie z USB (via programator :wink:).

    No to życzę powodzenia, może dla tak małej matrycy starcza, ale moja pobiera prawie 800mA - za to jest dosyć dobrze widoczna nawet przy oświetleniu. Mógłby Kolega pokazać filmik w normalnym oświetleniu pod kątem 90 stopni? Poza tym na filmiku nocnym straszne duszki - wina kamery czy tak jest w rzeczywistości? ;-)
  • #28
    davinco
    Level 11  
    Docelowo zasilenie będzie... inne ;-) Na potrzeby pisania softu tyle mi wystarcza, w końcu to tylko 4 panele.
    Duszki to wina kamery (telefonu dokładniej rzecz biorąc, bo kamerą nie dysponuję). Zaraz wykombinuję filmik pod ciekawszym kątem...

    Dodano po 34 [minuty]:

    Inny kąt:




    Duszki są - jednak. Mój błąd, przepraszam. Nie widziałem tego wcześniej, bo skupiłem się na kodowaniu (a widać je tylko w nocy) ;-) Z zawodu jestem programistą, a elektronika to tylko zabawa/hobby.

    Duszki są głównie przez zbyt wolną pracę procesora, na poprzednich filmikach było to 2 MHz i timer0=clk/8, ten nowy filmik to już 8 MHz i timer0=clk/64 - zwiększenie czasu świecenia linii (chyba) likwiduje duszki ;-)

    Nie wiem jeszcze jak to się będzie dalej rozwijać bo głównie ma mi to dostarczać rozrywki :-) dlatego też na takim etapie, duszki nie są tak bardzo istotne ;-)

    Pozdrawiam!
  • #29
    piotrva
    VIP Meritorious for electroda.pl
    Oj są istotne bo oznaczają nieco ferelny algorytm odświeżania i/lub animacji
  • #30
    davinco
    Level 11  
    Algorytm jest banalny, nie ma nic trudnego w przesuwaniu bitów w tą czy w tamtą stronę - tu błędu nie ma i tego jestem pewien ;-)

    Inna sprawa, że elektronicznie może coś być nie tak - coś co wiąże się z innym sposobem oprogramowania kontrolera. Ja zakładam, że duszki są efektem mojego niezrozumienia części analogowej :-) Może powinna być minimalna przerwa czasowa pomiędzy zgaszeniem jednego a zapaleniem kolejnego wiersza...

    Jak znajdę chwilę w weekend to przeanalizuję kody kolegi i porównam ze swoimi - zapewne znajdę skąd te duszki się pojawiają.

    Pozdrawiam!