Waldemar <w...@z...fu-berlin.de> wrote:

> a w słupkach dałbym po jednym Arduino nano, który by robił za serwer.

Czy to nie jest zbytnia komplikacja?

Jak się chce puścić kilka drutów i zrobić daisy chain, a nie po jednym do
każdego słupka, to rejestr przesuwny IMO tańszy i bardziej niezawodny.
Fakt, że wtedy nie ma się RS-a, tylko komunikację po 3 przewodach (zegar,
dane i latch; reset można odpuścić) i trzeba zrobić PWM po stronie
kontrolera, ale skoro i tak się pisze soft na kontroler...

Pytanie czy dodatkowa elektronika w słupku uzasadni mniejszą liczbę
przewodów do sterowania.

Ja widzę tutaj takie opcje:

1. Najprostsza

- w słupku tylko tranzystor wykonawczy i dwa rezystory
- 14 przewodów (dwie skrętki Ethernet)
- 10 sterujących, po jednym na słupek
- 2 zasilające (można puścić 4, wykorzystując 16 przewodów)
- 2 na czujniki (na początku i na końcu drogi, osobno, żeby móc
rozświetlać w zależności od kierunku nadejścia osoby)
- najmniej elektroniki
- awaria jednego słupka nie wyłączy pozostałych

2. Z rejestrem przesuwnym

- w słupku tranzystor wykonawczy i rejestr + jego zasilanie
- 7 przewodów
- 3 do rejestrów (zegar, dane, latch)
- 2 zasilające
- 2 do czujników
- jeden przewód (dane) jako daisy-chain, reszta równolegle
- awaria słupka wyłączy dalsze w łańcuchu
- trzeba rozwiązać problem puszczenia TTL (czułe wejścia rejestru) na
dalszą odległość i przepięć na drucie (rezystory, diody)

3. Z Arduino Nano

- w słupku tranzystor wykonawczy i Arduino + jego zasilanie
- 5 przewodów
- 2 zasilające
- 2 do czujników (można zejść do 1 lub nawet 0, puszczając transmisję
sterującym, ale wtedy sterujący musi być dwukierunkowy)
- 1 sterujący (puszczony jako daisy-chain)
- awaria słupka wyłączy dalsze w łańcuchu
- konieczność napisania softu na Arduino
- możliwość zawieszenia się Arduino (przepięcia, burza), konieczność
zabezpieczenia się przed tym
- jeśli użyty zostanie RS, a nie coś z clock recovery (np. Manchester),
to rozjazd zegarów z powodu temperatury, mogący rodzić problemy w bardzo
zimne lub bardzo ciepłe dni; IMO tutaj narzut Manchestera nie będzie
problemem
- konieczność zabezpieczenia przewodu sterującego przed przepięciami
- z zalet: Arduino zajmie się PWM-em

4. Najmniejsza liczba przewodów

- komunikacja puszczona na przewodzie zasilającym
- w słupku tranzystor wykonawczy i układ (pewnie też na Arduino), który
wyciągnie z linii zasilającej sygnał dla siebie
- w czujnikach podobny układ, który będzie modulował sygnał zasilający
- konieczność nadania indywidualnego numeru każdemu słupkowi
- niekoniecznie trzeba to zasilać DC -- można AC lub impulsowo, temat do
przemyślenia (czy modulujemy DC wysoką częstotliwością? Czy używamy
timeslotów?)
- największa komplikacja układu
- jedyna zaleta: tylko dwa przewody

Mimo wszystko optowałbym za rozwiązaniem pierwszym. Myślę, że koszt dwóch
skrętek i tak będzie dużo mniejszy, niż koszt dodatkowej elektroniki
(pomnożony przez 10) w każdym słupku.

Do sterowania użyłbym AVR / Arduino, a nie Raspberry. Zalety:

- mniejsza cena i overkill, jakoś nie przemawia do mnie stosowanie pełnego
komputera do sterowania diodami (choć to oczywiście nie mój projekt,
więc nie ja podejmuję ostateczną decyzję)
- AVR pracuje w realtime, co jest ważne przy generacji PWM, podczas
gdy userland Linuksa nie (choć myślę, że użycie jednego ze schedulerów
realtime -- SCHED_FIFO lub SCHED_RR -- wystarczy)
- mniejszy koszt, gdy coś się jednak spali (pamiętajmy, że mamy 70m
przewodu podłączonego do czułej elektroniki; oczywiście trzeba to
dodatkowo zabezpieczyć, ale to znów pewien kompromis)

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]