Am 13.03.2018 um 12:20 schrieb Adam Wysocki:
> 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)
>

To, że wybrałem Raspi i Arduino to może zboczenie zawodowe, bo tak tu
mam. Ale oczywiście, do sterowania całością taki nano wystarczy jak
najbardziej. Raspi bym brał, jakbym chciał to zintegrować z czymś
większym, choćby przez internet. Arduino kosztuje 10zł za sztukę, a
nawet mniej, jak kupisz u chińczyka, a przewód nie jest za darmo. Zaletą
jest też skalowanie, zawsze możesz dodać słupek, albo go usunąć. No i
wsio jest jednakowe, wystarczy zwielokrotnić płytkę. Rozjeżdżania zegara
nie bał bym się aż tak, bo słupki będą miały podobną temperaturę.
Awarię słupka client wyłapie od razu, bo nie dostanie potwierdzenia, w
razie co można taki słupek wyłączyć ręcznie zwierając RX i TX lokalnie,
a potem wymienić płytkę lub ją naprawić, jak by coś się stało.

Ale każdy je jak lubi, jeden lody, drugi salceson ;-)

Waldek