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?

do góry

Zegarów masz jak mrówków, o co więc biega?

http://www.uploadarchief.net/files/download/nixieuhr
1.jpg
http://www.circuitsonline.net/forum/view/18221/22/ni
xie

Na piechotą jak i z uC, jakie pan sobie życzy, zielone, czerwone
różowe:)

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:56d9768a$0$22831$6...@n...neostrad
a.pl...
>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.

Nie wiem czy wyjdzie, ale sprobowac nie zaszkodzi.
No, wyjdzie
https://www.youtube.com/watch?v=8L5Ns4pXV4k
https://www.youtube.com/watch?v=rcOhOr0Ufi4

>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?

Ale wiesz ... najprosciej to zrobic na jakims mikrokontrolerze :-)
Osobny modul z uC, ktory zrobi wszystko co trzeba.

Jesli koniecznie chcesz sprzetowo ... w dzisiejszych czasach to raczej
jakies FPGA/CPLD ... choc szkoda, bedzie sie marnowal.

A ten "glowny MCU" ma co robic ? Bo obsluga wyswietlaczy to
skomplikowana ani obciazajaca nie jest ...

J.

do góry

W dniu 2016-03-04 o 13:41, J.F. pisze:

> Ale wiesz ... najprosciej to zrobic na jakims mikrokontrolerze :-)
> Osobny modul z uC, ktory zrobi wszystko co trzeba.

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ć. ;)


> A ten "glowny MCU" ma co robic ? Bo obsluga wyswietlaczy to
> skomplikowana ani obciazajaca nie jest ...

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?

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:56d99655$0$702$6...@n...neostrada.
pl...
W dniu 2016-03-04 o 13:41, J.F. pisze:
>> Ale wiesz ... najprosciej to zrobic na jakims mikrokontrolerze :-)
>> Osobny modul z uC, ktory zrobi wszystko co trzeba.
>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ć. ;)

No wiesz, jesli ma byc sprzetowo ... to czemu nie wieksza ilosc 141 ?
A prawda, ma byc edukacyjnie :-)

>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ę.

Tego ESP nie znam, ale dziwi mnie to troche. Obsluga wyswietlacza
naprawde nie jest wymagajaca.

>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.

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.

>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".

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 :-)

>Jeśli nie było gotowego scalaka, to może ktoś już kiedyś sklecił coś
>takiego z dostępnych elementów?

No ba, kiedys tylko tak bylo mozna.
Ale czy warto wracac do tamtych czasow?

Chcesz miec zabawe - zaprojektuj sam :-)

J.

do góry

W dniu 2016-03-04 o 15:55, J.F. pisze:

> No wiesz, jesli ma byc sprzetowo ... to czemu nie wieksza ilosc 141 ?
> A prawda, ma byc edukacyjnie :-)

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.


> Tego ESP nie znam, ale dziwi mnie to troche. Obsluga wyswietlacza
> naprawde nie jest wymagajaca.

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.


> Chcesz zrobic, czy szukasz gotowca ? :-)

Nie tyle gotowca, co przykładu rozwiązania, które mógłbym podpatrzeć. ;)


> Technicznie zadanie jest w miare trywialne - dasz np rejestry
> szeregowo-rownolegly do wprowadzenia wyniku, multipleksery wybierajace
> dane, dekoder lamp,

Ok, dzięki za podpowiedzi. ;)

do góry

Dnia Fri, 4 Mar 2016 23:15:35 +0100, Atlantis napisał(a):
> W dniu 2016-03-04 o 15:55, J.F. pisze:
>> No wiesz, jesli ma byc sprzetowo ... to czemu nie wieksza ilosc 141 ?
>> A prawda, ma byc edukacyjnie :-)
> 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.

Akurat dane musisz gdzies przechowywac, wiec tych ekspanderow trzeba
tyle samo.

Gdyby te 74141 jakies drogie byly ...

> 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.

I to mozesz bez problemu zrobic - pelno takich ukladow.

J.

do góry