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