Wpis z mikrobloga

#programowanie #iot #nodejs #nodered #embedded #express

Mam dwa procesy napisane w node.js w oparciu o Express (jeden to node-RED) , które muszą wymieniać cyklicznie dane pomiędzy sobą - wartości pomiarów itd. W jaki sposób najlepiej to zrobić pod kątem wydajności? API RESTfulowe, MQTT, websockety, SQLite?

Aplikacja ma chodzić na jakimś systemie embedded, więc wydajność jest tu kluczowa. Samych danych ma być wymieniane docelowo kilkaset-kilka tysięcy pomiarów.

Proszę o wyrozumiałość, dopiero się uczę( ͡° ͜ʖ ͡°)
  • 14
via Wykop Mobilny (Android)
  • 2
@Wegrzynski: najszybszym mechanizmem komunikacji pomiędzy procesami to pamięć dzielona. Tylko kilkaset-kilka tysięcy to zupełnie nie ta skala. Jakbym robił coś takiego sam to pewnie użył bym web socketow, bo są proste i wygodne. Ale liczba możliwych podejść które będą działały jest ogromna
node.js skaluje się pieknie, ale musi mieć na czym :) embeded to raczej słaby use case


@4191727801: Jeszcze nie wybrałem, ale mówimy o jakimś ARM-ie czy dokładniej SoMie( ͡° ͜ʖ ͡°) Na pewno nie będzie 8-bitowy AVR-erek ( ͡° ͜ʖ ͡°)

najszybszym mechanizmem komunikacji pomiędzy procesami to pamięć dzielona. Tylko kilkaset-kilka tysięcy to zupełnie nie ta skala. Jakbym robił coś takiego sam to
@Wegrzynski: #nodejs i #embedded - wybierz tylko jeden, serio.
Serio, nodejs przecież nie bedzie dzialał bare metal ani na żadnym RTOSie. Czy z góry pakujesz się w jakieś mega drogi hardware. Dodatkowo pakujesz jakiś mega wypasiony stack do czegoś prostego - zbierania i wysyłania pomiarów. Poza tym, tych pomiarów ma być kilkaset / kilka tysięcy na minutę / na dobę / na dzień? Po cholerę tak dużo?
Embedded to sztuka minimalizmu.
#nodejs i #embedded - wybierz tylko jeden, serio.

Serio, nodejs przecież nie bedzie dzialał bare metal ani na żadnym RTOSie.


@groman43: Pisałem, że na ATiny tego nie zamierzam robić :P

Czy z góry pakujesz się w jakieś mega drogi hardware.


@groman43: SoMy nie są koniecznie jakieś drogie, myślę o czymś w stylu Rasberry.

Dodatkowo pakujesz jakiś mega wypasiony stack do czegoś prostego - zbierania i wysyłania pomiarów. Poza tym, tych
@Wegrzynski: Zacznijmy od tego, że ostatnie trzy lata spędziłem pisząc soft dla modemu 5G. Więc zaryzykuje hipotezę, że wiem jak działają telefony komórkowe. I owszem, zwykle bazują na dość złożonych SoC, ale to tylko dlatego że wspierają jednocześnie GSM / 3G (we wszystkich jego odmianach) / LTE / NR / 802.11 / Bluetooth / NFC / cholera wie jeszcze co. Natomiast sama architektura 5G modemu nie jest super skompikowana, więc Twój
Zacznijmy od tego, że ostatnie trzy lata spędziłem pisząc soft dla modemu 5G. Więc zaryzykuje hipotezę, że wiem jak działają telefony komórkowe. I owszem, zwykle bazują na dość złożonych SoC, ale to tylko dlatego że wspierają jednocześnie GSM / 3G (we wszystkich jego odmianach) / LTE / NR / 802.11 / Bluetooth / NFC / cholera wie jeszcze co. Natomiast sama architektura 5G modemu nie jest super skompikowana, więc Twój argument zaliczę
@Wegrzynski: Jeśli chcesz wysłać kilka tysięcy różnych pomiarów raz na sekundę, to musisz wcześniej zebrać kilka tysięcy pomiarów w ciągu sekundy. Matematyka jest tutaj raczej nieubłagana.
A zebranie kilku tysięcy pomiarów, biorąc pod uwagę, że rozmawiasz ze światem zewnętrznym, samo w sobie jest czasochłonne - MCU pewnie większość czasu będzie czekało aż sterownik PLC wyślę odpowiedź. Dlatego na Twoim miejscu wpakowałbym wszystko w FPGA, które będzie gadało z kilkoma sterownikami PLC
nodered to kobyla, do iot się nie nadaje. Są fanatycy, ale prawda taka że to szit.


@korni007: I dlatego wszyscy go pakują do IoT :P Mam nadzieję, że uzasadnisz dlaczego to takie gunwo, jestem bardzo ciekawy :P