Nie mam wielkiego doświadczenia w projektowaniu cyfrowych układów złożonych z logicznych układów scalonych - poza prostymi eksperymentami z bramkami raczej się w to nie bawiłem, a wszystkie swoje projekty robiłem od razu na mikrokontrolerach.
Teraz jednak przydałby mi się niezależny moduł do obsługi lamp nixie. Idea jest taka, aby multipleksowany zespół lamp (cztery lub sześć) był sterowany od strony katod przez jeden układ 74141. Dałoby się zrobić to w ten sposób, żeby odbywało się to w 100% sprzętowo, a główny MCU nie musiał się wcale przejmować przełączaniem lamp i wystawianiem właściwej wartości na 71414? Niech jego rola ogranicza się do przesłania (np. szeregowo) nowej wartości, gdy zachodzi konieczność jej wyświetlenia.
Jest jakiś projekt, w którym mógłbym "podpatrzeć" takie rozwiązanie?
Wiem, że można to zrobić w ten sposób, ale chodzi mi także o walor edukacyjny. Poza tym jeśli coś da się zrobić czysto sprzętowo, to chciałbym spróbować. ;)
Jakiś czas temu złożyłem zegar Nixie z Atmegą644PA i ESP8266-01. Obsługą wyświetlacza i liczeniem czasu zajmował się AVR, ESP zajmował się tylko funkcjami sieciowymi, głównie synchronizacją czasu przez NTP. Pomyślałem, że warto byłoby zredukować ilość MCU i skleciłem próbny układ z ESP8266-12, który przez ekspandery I2C sterował lampami. Na tej samej magistrali pracował RTC. Niestety okazało się, że układ nie jest w stanie wyrobić się z odczytem czasu pomiędzy kolejnymi cyklami obsługi wyświetlacza, co objawiało się delikatnym "miganiem" co sekundę.
Co prawda układ był próbny i problem można by wyeliminować też na inne sposoby, jednak do głowy przyszło mi właśnie przerzucenie obsługi multipleksowanego wyświetlacza na jakiś kawałek sprzętu. Jak mówiłem - cel edukacyjny. ;)
W końcu w czasach popularności AT89C2051 budowali na tych MCU układy wyposażone w rozbudowane wyświetlacze LED, posługując się odpowiednimi sterownikami. Może dla nixie również znalazłby się odpowiedni "klocek"? Coś, co komunikowałoby się z MCU przez jednokierunkowe SPI i cyklicznie wystawiało na czterech liniach aktualny kod BCD, jednocześnie aktywując linię odpowiedzialną za zapalanie anody. Sprawę komplikuje fakt, że nixie musi pracować w dwóch cyklach - cyfrę trzeba najpierw zgasić i odczekać chwilę przed zapaleniem następnej, bo w przeciwnym razie wystąpi zjawisko "ghostingu".
Jeśli nie było gotowego scalaka, to może ktoś już kiedyś sklecił coś takiego z dostępnych elementów?
Użytkownik "Atlantis" napisał w wiadomości grup dyskusyjnych:56d99655$0$702$ snipped-for-privacy@news.neostrada.pl... W dniu 2016-03-04 o 13:41, J.F. pisze:
No wiesz, jesli ma byc sprzetowo ... to czemu nie wieksza ilosc 141 ? A prawda, ma byc edukacyjnie :-)
Tego ESP nie znam, ale dziwi mnie to troche. Obsluga wyswietlacza naprawde nie jest wymagajaca.
Chcesz zrobic, czy szukasz gotowca ? :-)
Podejrzewam ze wiele sterownikow LED by sie nadalo - zapomniec o LED, podlaczyc do jednych wyjsc 74141, a do drugich wzmacniacze/sterowniki kolumn. Tylko ... czy te sterowniki jeszcze robia/sprzedaja ? Taki np MAX7219
Technicznie zadanie jest w miare trywialne - dasz np rejestry szeregowo-rownolegly do wprowadzenia wyniku, multipleksery wybierajace dane, dekoder lamp, licznik liczacy kolejne lampy i generator. Ambitniejsi moga pomyslec jak multipleksery zastapic rejestrami szeregowymi, lub zapetlic te powyzej, zeby dane do wyswietlania sobie krazyly w kolko. Moglby wyjsc troche mniejszy burdel polaczen na plytce ... choc w kwesti ilosci niezbednych tranzystorow w ukladzie scalonym czy ilosci CLB w FPGA to juz nie dam glowy.
To tylko kwestia generacji wlasciwych sygnalow zegarowych - generator zegara dzielimy np przez 8, i przy stanie licznika 0 czy 7 wylaczamy napiecie. Tym niemniej - kolejny powod, aby uzyc uC :-)
No ba, kiedys tylko tak bylo mozna. Ale czy warto wracac do tamtych czasow?
To jest właśnie jedno z tych oczywistych rozwiązań, które jako pierwsze przyszły mi do głowy. I kto wie - może właśnie w finalnej wersji zrobię to rezygnując z multipleksowania. Jestem po prostu ciekaw sprzętowego sterownika, tego jak bardzo skomplikowany byłby jego projekt i czy przypadkiem nie okaże się, że potrzeba do tego mniej scalaków niż w przypadku osobnych 74141 ze sterującymi nimi ekspanderami.
Specyfika ESP8266. Sam układ ma całkiem sporo mocy obliczeniowej - to nie tu leży problem. Po prostu cykle procesora są dzielone pomiędzy kilka zadań, jak obsługa WiFi, stosu TCP/IP albo systemu zdarzeń. Jeśli odpali się jakieś zadanie na programowym timerze dostępnym w SDK, to wcale nie ma gwarancji, że zadanie zostanie wykonane dokładnie po zadanym czasie. Opóźnienie nie tylko może nastąpić, ale i występuje. Jitter jest zauważalny. Ktoś co prawda napisał bibliotekę dającą dostęp do sprzętowego timera (używając jej traci się możliwość korzystania z funkcji PWM dostępnych w SDK) ale w moim przypadku wcale mnie to nie ratuje. Dlaczego? Bo moduł posiada zbyt mała liczbę linii GPIO, żeby sterować nimi wyświetlaczem. W grę wchodzą tylko ekspandery, a ESP nie posiada sprzętowego I2C. Odpalanie transmisji I2C w funkcji obsługi przerwania jest bardzo złym pomysłem z uwagi na delay'e, a przekazywanie sygnału do procesu daje praktycznie taki sam efekt, jak stosowanie software'owego timera. I wracamy do punktu wyjścia.
W efekcie wygląda to tak, że jeśli moduł musi odczytać czas RTC, to kolejny cykl obsługi wyświetlacza zostaje opóźniony na tyle, że widać delikatne mignięcie.
Widzę tutaj kilka możliwych rozwiązań:
1) Najprostsze - zrezygnować z multipleksowania i sterować każdą lampę osobnym 74141. Wtedy konieczność odświeżania wyświetlaczy będzie występowała tylko raz na sekundę, tuż po odczytaniu czasu.
2) Zastosowane jakiegoś sprzętowego sterownika, który przejmie na siebie obsługę multipleksowania, a sam dane będzie otrzymywał jak w powyższym punkcie - co sekundę.
3) Zastąpienie ekspanderów I2C jakimiś szybkimi rejestrami przesównymi, którymi można by sterować szybko machając stanem linii IO w funkcji przerwania timera.
Nie tyle gotowca, co przykładu rozwiązania, które mógłbym podpatrzeć. ;)
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.