Potrzebuję sklecić jednostkowo coś co by odczytywało dane z czujnika po SPI 3,3V po
czym pakowało w ramki UDP i wysyłało do dalszej obróbki. Ilość danych taka że
wystarczy Ethernet 10 Mb/s (czujnik to akcelerometr 3-osiowy ADXL313 - max
próbkowanie 3200 Hz, trochę za dużo danych dla I2C i RS232), mile widziane zasilanie
PoE. Coś małego i odpornego na ekstremalne temperatury (w puszce hermetycznej na
szczycie masztu antenowego - ma monitorować jego drgania, czy coś się nie poluzowało
po kolejnej wichurze), jakieś Raspberry Pi to chyba trochę "strzelanie z armaty do
muchy". Poleci ktoś coś aktualnie dostępnego?

do góry

wtorek, 15 lutego 2022 o 13:17:59 UTC+1 M M napisał(a):
> Potrzebuję sklecić jednostkowo coś co by odczytywało dane z czujnika po SPI 3,3V po
czym pakowało w ramki UDP i wysyłało do dalszej obróbki. Ilość danych taka że
wystarczy Ethernet 10 Mb/s (czujnik to akcelerometr 3-osiowy ADXL313 - max
próbkowanie 3200 Hz, trochę za dużo danych dla I2C i RS232), mile widziane zasilanie
PoE. Coś małego i odpornego na ekstremalne temperatury (w puszce hermetycznej na
szczycie masztu antenowego - ma monitorować jego drgania, czy coś się nie poluzowało
po kolejnej wichurze), jakieś Raspberry Pi to chyba trochę "strzelanie z armaty do
muchy". Poleci ktoś coś aktualnie dostępnego?

Ja się bawię z atmegą i W5500 - ale zasilacz poe musisz znaleźć/zrobić sam.
Ale 3200Hz i od razu ethernet? RS485 mógłby wystarczyć.
Albo zrobić obróbkę na miejscu i wysyłać raporty i alarmy - chyba że taka
skomplikowana ma być?

do góry

Ethernet jest już "pod ręką" (na maszcie switch CRS318-16P-2S+OUT do którego dochodzi
zasilanie i światłowód, a wychodzą porty Ethernet z PoE do wyboru 24V lub 48V).
3 osie * 12 bitów * 3200 * 10/8 (start+stop) = 144 kb/s + coś by rozpoznać początek
ramki, RS485 musiałby mieć "niestandardową" prędkość (powyżej 115200 co pewnie jest
max dla tanich przejściówek z USB - choć może się mylę, trzeba by sprawdzić).
Obróbka najchętniej w bardziej przyjaznym miejscu (kolejna maszyna wirtualna na
serwerze, jedna dla 2 czujników w 2 lokalizacjach), to co na górze najlepiej jak
najprostsze i bezobsługowe (sam tam nie wejdę tylko zlecam komuś).

do góry

On 15.02.2022 13:17, M M wrote:

> Potrzebuję sklecić jednostkowo coś co by odczytywało dane z czujnika
> po SPI 3,3V po czym pakowało w ramki UDP i wysyłało do dalszej
> obróbki. Ilość danych taka że wystarczy Ethernet 10 Mb/s

Coś takiego robiłem niecałą dekadę temu korzystając z zestawu ENC28J6 +
Atmega328 + prosty stos TCP/IP od Tuxgraphics.
Jak nie chce Ci się bawić w rzeźbienie płytek i chcesz mieć dostęp do
nieco lepszego stosu, to zestaw Arduino + Arduino Ethernet załatwi
sprawę. Będziesz musiał tylko zadbać o translację poziomów na SPI, bo
Arduino pracuje na logice 5V.

Albo ewentualnie możesz wziąć dowolny zestaw deweloperski Discovery lub
Nucleo na STM32, z wbudowanym modułem Ethernet.

do góry

wtorek, 15 lutego 2022 o 13:59:13 UTC+1 M M napisał(a):
> Ethernet jest już "pod ręką" (na maszcie switch CRS318-16P-2S+OUT do którego
dochodzi zasilanie i światłowód, a wychodzą porty Ethernet z PoE do wyboru 24V lub
48V).
> 3 osie * 12 bitów * 3200 * 10/8 (start+stop) = 144 kb/s + coś by rozpoznać początek
ramki, RS485 musiałby mieć "niestandardową" prędkość (powyżej 115200 co pewnie jest
max dla tanich przejściówek z USB - choć może się mylę, trzeba by sprawdzić).
> Obróbka najchętniej w bardziej przyjaznym miejscu (kolejna maszyna wirtualna na
serwerze, jedna dla 2 czujników w 2 lokalizacjach), to co na górze najlepiej jak
najprostsze i bezobsługowe (sam tam nie wejdę tylko zlecam komuś).

No tak, bliski ethernet robi wręcz "big russian" "golden hammer".
Chociaż utrudnia w wielu innych miejscach (co właśnie czyni go "golden hammerem") -
począwszy od zasilania.
Dyskusja robi się więc nieco akademicka niestety.
Ew. do przemyślenia jeszcze sprawdzenie, czy może w tej skrętce, która idzie do
switcha, nie ma przypadkiem 2 par wolnych (bo 100Base-TX) - starczyły by na RS-485 i
zasilanie z dołu (choć dawanie 3,3V z dołu to i tak słabo, jakaś przetwornica czy coś
stabilizator na górze będzie pewnie niezbędne - hmm, w sumie mając z 24V POE też
można dać stabilizator - choć taki moduł z W5500 zżera 100mA z 5V - moduł ma
wbudowany stabilizator na 3,3V, ale nie wiem, jak sprawny, nie sprawdzałem, ile żre
zasilany bezpośrednio z 3,3V - więc trzeba zapewnić odprowadzenie ciepła do obudowy).
Tanie przejściówki USB (no dobra, z RS232C a nie RS485 ;), przynajmniej pod Linuxem,
spokojnie sobie radzą z 230400bps, a chyba 460800bps też testowałem.
Zaś sama ATmega bez problemu realizuje mi na 819200bps łączność w sieci domofonów z 6
jednoczesnymi rozmowami na jednej parze RS485 (oprócz tego sampluje, odgrywa i
realizuje protokół komunikacji - oraz jeszcze drugi na drugim UART).

do góry

On 15.02.2022 13:17, M M wrote:
Raspberry Pi to chyba trochę "strzelanie z armaty do muchy".

Tylko że ta armata jest w cenie muszkietu, załadowana i z obsługą.

--
Mirek.

do góry

On 15.02.2022 20:51, Mirek wrote:

> Tylko że ta armata jest w cenie muszkietu, załadowana i z obsługą.

A teraz zobacz po ile OBECNIE chodzi Raspberry Pi. :)
Poza tym jest jeszcze jedna sprawa. Awaryjność.
W RasPi słabym ogniwem jest karta pamięci. Można co prawda kupić
przemysłową, ale to podnosi koszt całości. A i tak wypadałoby
odpowiednio skonfigurować system, żeby po kilku latach zapisywania logów
nośnik nie został zajechany.

No i pozostaje jeszcze kwestia bezpieczeństwa. Masz tam cały system, a w
każdym jego komponencie mogą być jakieś 0-day'e. Wypadałoby wiec dbać o
to, żeby był aktualny. Jednak każda aktualizacja może zepsuć.

Do mikrokontrolera jeden raz wgrywasz firmware i masz spokój.

do góry

On 15.02.2022 21:04, Atlantis wrote:


> odpowiednio skonfigurować system, żeby po kilku latach zapisywania logów
> nośnik nie został zajechany.

Obecnie to się robi jednym poleceniem i masz system read-only.

>
> No i pozostaje jeszcze kwestia bezpieczeństwa. Masz tam cały system, a w
> każdym jego komponencie mogą być jakieś 0-day'e. Wypadałoby wiec dbać o
> to, żeby był aktualny. Jednak każda aktualizacja może zepsuć.
>
A na maszcie MikroTik i goła transmisja po UDP - no szczyt bezpieczeństwa ;)

> Do mikrokontrolera jeden raz wgrywasz firmware i masz spokój.

Chyba Ty, bo ja zawsze coś poprawiam n razy.

--
Mirek.

do góry

wtorek, 15 lutego 2022 o 21:22:35 UTC+1 Mirek napisał(a):
> Obecnie to się robi jednym poleceniem i masz system read-only.
Lokalnie nie trzeba nic zapisywać, wszystko leci przez sieć.

> A na maszcie MikroTik i goła transmisja po UDP - no szczyt bezpieczeństwa ;)
Własna sieć, wydzielony VLAN bez dostępu do Internetu.

> Chyba Ty, bo ja zawsze coś poprawiam n razy.
Idealnie jakby flash zawierał tylko prosty bootloader, który ładuje do RAM właściwy
soft przez sieć z serwera (DHCP, TFTP).
Wtedy łatwo poprawiać, a trudno popsuć tak by konieczny był fizyczny dostęp.

do góry

On 15.02.2022 21:22, Mirek wrote:

> Obecnie to się robi jednym poleceniem i masz system read-only.

Możesz powiedzieć coś więcej? Wiedziałem, że istnieją metody na
ograniczenie użycia karty pamięci (na wzór rozwiązań stosowanych np. w
OpenWRT) ale gdy szukałem jakichś opisów, to znajdywałem dłuższe
tutoriale. Da się to pod Raspbianem zrobić jednym poleceniem? Jak
wygląda potem kwestia instalacji softu?


> A na maszcie MikroTik i goła transmisja po UDP - no szczyt
> bezpieczeństwa ;)

Ale tutaj nie chodzi o bezpieczeństwo transmisji czy nawet
bezpieczeństwo sieci. Chodzi o bezpieczeństwo tego konkretnego
urządzenia. RasPi to jednak standardowy komputer. Jeśli będziesz miał na
nim przestarzały system albo inny komponent software;owy, to jeśli
atakujący w jakiś sposób się do niego dostanie (chociażby w sytuacji,
gdy uda mu się zinfiltrować twoją sieć) to będzie mógł próbować się do
niego dobrać za pomocą zupełnie standardowych exploitów. W razie sukcesu
stworzy sobie całkiem fajny przyczułek.

A urządzenie na mikrokontrolerze to urządzenie na mikrokontrolerze.
Projektowane do konkretnego celu. Odpala kod, który został wgrany. Nie
instalujesz na nim programów. Tak więc atakujący co najwyżej będzie w
stanie podsłuchać komunikację. Jeśli występuje opcja zdalnej
aktualizacji to istnieje niewielka szansa, że będzie w stanie wgrać
zmodyfikowany firmware, ale to będzie już wymagało od niego znacznie
więcej wysiłku. O wiedzy na temat samego urządzenia nie wspominając.


>> Do mikrokontrolera jeden raz wgrywasz firmware i masz spokój.
>
> Chyba Ty, bo ja zawsze coś poprawiam n razy.

Chodzi mi o to, że w przypadku urządzenia wbudowanego musisz
aktualizować tylko jego firmware. W przypadku komputera musisz
aktualizować wszystko, bo co chwilę będzie się okazywało, że któryś z
komponentów użytych w systemie ma podatność, która może być eksploitowana.
I jasne, obecnie granica też się zaciera, bo biblioteki wchodzące w
skład SDK ESP8266/ESP32 też co jakiś czas warto aktualizować ze względów
bezpieczeństwa.

do góry