Każdy z nas widział lub korzystał kiedyś z Arduino. Wszyscy hobbyści bardzo je lubią i nie ma co się dziwić - moduły te bardzo łatwo jest opanować i nawet ktoś, kto nigdy nie miał do czynienia z systemami wbudowanymi, może w chwilę nauczyć się je programować i zbudować w oparciu o Arduino coś na prawdę ciekawego. Ekosystem Arduino pozwala w prosty i przyjemny sposób nauczyć się projektowania i budowania takich systemów... Problem pojawia się jednak w momencie, gdy ktoś chce wykorzystać elementy tego ekosystemu do projektowania urządzeń komercyjnych.
Wiele osób zachęca, aby korzystać z Arduino w środowisku produkcyjnym. To bardzo, bardzo, bardzo zły pomysł. Dlaczego nie powinno się tak robić? Istnieje szereg podstawowych przyczyn - zapoznamy się z nimi w poniższym tekście.
Po pierwsze - Arduino IDE, wbrew temu co mogliście słyszeć, nie jest darmowe. Oprogramowanie to jest dystrybuowane na licencji GPL, oznacza to, że aby móc legalnie z niego korzystać, trzeba cały tworzony kod publikować za darmo np. w sieci. Jest to dokładnie opisane w licencji tego środowiska, ale także w Arduino FAQ, gdzie czytamy:
"Środowisko to nie jest darmowe do zastosowań komercyjnych, no chyba że publikuje się wszystkie kody tak, aby każdy mógł odtworzyć nasz program. Oczywiście dotyczy to tylko samego IDE i standardowych bibliotek. Inne biblioteki, jakie wykorzystamy w naszym projekcie, mogą być dystrybuowane na jeszcze innej zasadzie, dlatego bardzo nierozsądnym jest wykorzystywanie Arduino IDE do rozwijania komercyjnych aplikacji, bez wcześniejszego sprawdzenia poszczególnych licencji".
Ale ok, załóżmy że to nam nie przeszkadza - i tak chcieliśmy dystrybuować kod jako GPL, albo publikować go w sieci lub też może po prostu w jakiś inny sposób on do sieci wyciekł... Jednakże, to nie wszystko. Jest jeszcze szereg kolejnych argumentów.
Bardzo często mówi się, że Arduino jest dobre dla początkujących. Jasne, każdy, kto nie umie programować z chęcią usiądzie do takiej okrojonej platformy i będzie w stanie rozwijać aplikację w oparciu o ten system. Jednakże każdy bardziej doświadczony deweloper przyzna nam, że np. debugger nie jest jedynie dodatkową, przydatną funkcją, a krytycznym narzędzie, wykorzystywanym podczas tworzenia oprogramowania dla systemu wbudowanego.
Brak funkcjonalnego debuggera w środowisku Arduino jest ogromnym argumentem, aby nie brać go nazbyt na poważnie. Oczywiście, można do układu takiego dołączyć zwykły debugger, ale taka operacja sprawi, że nie będziemy już egzystować w tym ekosystemie. Wykorzystywanie funkcji print() jako jedynej metody quasi-debugowania systemu jest niezwykle ułomne... A poza tym drukowanie na jakiekolwiek wyjście danych w czasie pracy programu zmienia zależności czasowe w systemie, więc raz umieszczone, będą musiały tam zostać na zawsze, co uczyni urządzenie znacznie podatniejszym na hackowanie (o ile jest w ogóle taka konieczność - kod źródłowy jest przecież jawny i publiczny, nie?).
Język używany w środowisku Arduino to jedynie niewielki wycinek C++. Oznacza to, że nie możemy np. budować klas - środowisko mocno do tego zniechęca, a jest to najlepsza metoda na tworzenie testów jednostkowych kodu. Struktura projektu i poszczególnych plików źródłowych oraz zależności między nimi utrudniają utrzymywanie wielu wersji projektu. Można oczywiście umieścić nasz kod w bibliotece, jednakże oznacza to konieczność wielokrotnego przeładowywania IDE i utrzymywanie bardzo nietypowego środowiska kontroli wersji.
A może znacie jakieś inne, lepsze metody integracji Arduino IDE z systemem kontroli wersji? Opiszcie na forum jak (i czy) sobie z tym radzicie. Tak czy inaczej - system kontroli wersji w żaden sposób nie jest wbudowany w to środowisko i programistom - szczególnie początkującym - ciężko jest wyrobić sobie dobre nawyki związane z kontrolą wersji, testami jednostkowymi itp.
Samego IDE nie ma co komentować - jest jakie jest: proste i przez to idealne dla początkujących. Brakuje w nim systemów sprawdzania składni, autouzupełniania itp. funkcji, które posiada każde 'duże' środowisko, a co mogłoby rozpraszać początkujących. Oczywiście, można połączyć Arduino z dowolnym innym edytorem, posiadającym te funkcje, ale czy nie jest to argumentem przeciwko Arduino jako IDE?
Kolejnym problemem jest czynnik ekonomiczny - moduły z ekosystemu Arduino są drogie, a ponadto bardzo energochłonne z uwagi na wbudowane oprogramowanie do wgrywania projektów itp. Oczywiście są wersje jak Arduino Pro, które programuje się zewnętrznym programatorem, jednakże nie jest to typowa ścieżka. Flagowe moduły - jak Arduino UNO z ATMega328 są bardzo drogie jak na oferowane możliwości. Planowanie, że zredukuje się koszty systemu później, po stworzeniu aplikacji, nie jest za dobrym rozwiązaniem w systemach przeznaczonych do komercjalizacji.
Wbudowane w środowisko biblioteki są bardzo niewydajne, gdyż tworzono je pod kątem uniwersalności - mają pracować na każdej płytce z ekosystemu, a nie pod kątem wydajności. Oczywiście, można argumentować, że obecne procesory są coraz wydajniejsze, mają więcej przestrzeni na kod etc., jednakże finalnie wykorzystanie 'nadmiarowych' układów zwiększa koszty systemu - jeśli marnujemy ogromne ilości mocy obliczeniowej, to dlaczego by nie zastosować słabszego mikrokontrolera, który jednocześnie jest tańszy?
Finalnie, warto zwrócić uwagę na to, że Arduino nie pokazuje plików list oraz map. Są one ukryte, a są potrzebne do wprowadzania układu do produkcji. Oczywiście, można je wyekstrahować ze środowiska, ale nie jest to proste. Pliki list i map potrzebne są do zdobycia informacji o optymalizacji prowadzonej przez kompilator i oceny zużycia zasobów przez projekt. Jeśli projektujemy system komercyjny, to staramy się dobrać układ, który zapewnia tyle i tylko tyle, ile jest potrzebne, a nie dobieramy nadmiarowy układ jak w projektach hobbystycznych.
Arduino oczywiście może być fantastycznym narzędziem do produkcji systemów demonstracyjnych dla publiki, czy jako układ do tworzenia szybkich, wewnętrznych prototypów czy testów pewnych rozwiązań. W tych aplikacjach świetnie się sprawdza, ale jeżeli chcemy zastosować je w komercyjnym produkcie - lepiej tego nie róbmy.
Istnieje też szereg alternatyw. Jeśli chcemy mieć prosty system z dużą ilością bibliotek, ale lepszym kompilatorem, to zainteresujmy się np. płytkami mbed. Finalnie, najlepiej jest nauczyć się mikrokontrolerów STM32, dzięki wykorzystaniu HAL (warstwa abstrakcji sprzętowej) i dosyć prostemu systemowi konfiguracji (CubeMX) tworzenie takich projektów jest bardzo proste. (Jeśli dodatkowo wykorzystamy IDE takie jak Keil, które posiada wbudowane wsparcie dla CubeMX dla STM32 możemy cały projekt skonfigurować i opisać w łatwy sposób w jednym programie - przyp.red.).
W przemyśle istnieje wiele ścieżek - trudniejszych i łatwiejszych, niektóre równie proste jak Arduino, a z pewnością mniej problematyczne w zastosowaniach komercyjnych jak Arduino.
Źródło: http://embedded.fm/blog/2017/8/12/dont-use-arduino-for-professional-work
Wiele osób zachęca, aby korzystać z Arduino w środowisku produkcyjnym. To bardzo, bardzo, bardzo zły pomysł. Dlaczego nie powinno się tak robić? Istnieje szereg podstawowych przyczyn - zapoznamy się z nimi w poniższym tekście.
Po pierwsze - Arduino IDE, wbrew temu co mogliście słyszeć, nie jest darmowe. Oprogramowanie to jest dystrybuowane na licencji GPL, oznacza to, że aby móc legalnie z niego korzystać, trzeba cały tworzony kod publikować za darmo np. w sieci. Jest to dokładnie opisane w licencji tego środowiska, ale także w Arduino FAQ, gdzie czytamy:
"Środowisko to nie jest darmowe do zastosowań komercyjnych, no chyba że publikuje się wszystkie kody tak, aby każdy mógł odtworzyć nasz program. Oczywiście dotyczy to tylko samego IDE i standardowych bibliotek. Inne biblioteki, jakie wykorzystamy w naszym projekcie, mogą być dystrybuowane na jeszcze innej zasadzie, dlatego bardzo nierozsądnym jest wykorzystywanie Arduino IDE do rozwijania komercyjnych aplikacji, bez wcześniejszego sprawdzenia poszczególnych licencji".
Ale ok, załóżmy że to nam nie przeszkadza - i tak chcieliśmy dystrybuować kod jako GPL, albo publikować go w sieci lub też może po prostu w jakiś inny sposób on do sieci wyciekł... Jednakże, to nie wszystko. Jest jeszcze szereg kolejnych argumentów.
Bardzo często mówi się, że Arduino jest dobre dla początkujących. Jasne, każdy, kto nie umie programować z chęcią usiądzie do takiej okrojonej platformy i będzie w stanie rozwijać aplikację w oparciu o ten system. Jednakże każdy bardziej doświadczony deweloper przyzna nam, że np. debugger nie jest jedynie dodatkową, przydatną funkcją, a krytycznym narzędzie, wykorzystywanym podczas tworzenia oprogramowania dla systemu wbudowanego.
Brak funkcjonalnego debuggera w środowisku Arduino jest ogromnym argumentem, aby nie brać go nazbyt na poważnie. Oczywiście, można do układu takiego dołączyć zwykły debugger, ale taka operacja sprawi, że nie będziemy już egzystować w tym ekosystemie. Wykorzystywanie funkcji print() jako jedynej metody quasi-debugowania systemu jest niezwykle ułomne... A poza tym drukowanie na jakiekolwiek wyjście danych w czasie pracy programu zmienia zależności czasowe w systemie, więc raz umieszczone, będą musiały tam zostać na zawsze, co uczyni urządzenie znacznie podatniejszym na hackowanie (o ile jest w ogóle taka konieczność - kod źródłowy jest przecież jawny i publiczny, nie?).
Język używany w środowisku Arduino to jedynie niewielki wycinek C++. Oznacza to, że nie możemy np. budować klas - środowisko mocno do tego zniechęca, a jest to najlepsza metoda na tworzenie testów jednostkowych kodu. Struktura projektu i poszczególnych plików źródłowych oraz zależności między nimi utrudniają utrzymywanie wielu wersji projektu. Można oczywiście umieścić nasz kod w bibliotece, jednakże oznacza to konieczność wielokrotnego przeładowywania IDE i utrzymywanie bardzo nietypowego środowiska kontroli wersji.
A może znacie jakieś inne, lepsze metody integracji Arduino IDE z systemem kontroli wersji? Opiszcie na forum jak (i czy) sobie z tym radzicie. Tak czy inaczej - system kontroli wersji w żaden sposób nie jest wbudowany w to środowisko i programistom - szczególnie początkującym - ciężko jest wyrobić sobie dobre nawyki związane z kontrolą wersji, testami jednostkowymi itp.
Samego IDE nie ma co komentować - jest jakie jest: proste i przez to idealne dla początkujących. Brakuje w nim systemów sprawdzania składni, autouzupełniania itp. funkcji, które posiada każde 'duże' środowisko, a co mogłoby rozpraszać początkujących. Oczywiście, można połączyć Arduino z dowolnym innym edytorem, posiadającym te funkcje, ale czy nie jest to argumentem przeciwko Arduino jako IDE?
Kolejnym problemem jest czynnik ekonomiczny - moduły z ekosystemu Arduino są drogie, a ponadto bardzo energochłonne z uwagi na wbudowane oprogramowanie do wgrywania projektów itp. Oczywiście są wersje jak Arduino Pro, które programuje się zewnętrznym programatorem, jednakże nie jest to typowa ścieżka. Flagowe moduły - jak Arduino UNO z ATMega328 są bardzo drogie jak na oferowane możliwości. Planowanie, że zredukuje się koszty systemu później, po stworzeniu aplikacji, nie jest za dobrym rozwiązaniem w systemach przeznaczonych do komercjalizacji.
Wbudowane w środowisko biblioteki są bardzo niewydajne, gdyż tworzono je pod kątem uniwersalności - mają pracować na każdej płytce z ekosystemu, a nie pod kątem wydajności. Oczywiście, można argumentować, że obecne procesory są coraz wydajniejsze, mają więcej przestrzeni na kod etc., jednakże finalnie wykorzystanie 'nadmiarowych' układów zwiększa koszty systemu - jeśli marnujemy ogromne ilości mocy obliczeniowej, to dlaczego by nie zastosować słabszego mikrokontrolera, który jednocześnie jest tańszy?
Finalnie, warto zwrócić uwagę na to, że Arduino nie pokazuje plików list oraz map. Są one ukryte, a są potrzebne do wprowadzania układu do produkcji. Oczywiście, można je wyekstrahować ze środowiska, ale nie jest to proste. Pliki list i map potrzebne są do zdobycia informacji o optymalizacji prowadzonej przez kompilator i oceny zużycia zasobów przez projekt. Jeśli projektujemy system komercyjny, to staramy się dobrać układ, który zapewnia tyle i tylko tyle, ile jest potrzebne, a nie dobieramy nadmiarowy układ jak w projektach hobbystycznych.
Arduino oczywiście może być fantastycznym narzędziem do produkcji systemów demonstracyjnych dla publiki, czy jako układ do tworzenia szybkich, wewnętrznych prototypów czy testów pewnych rozwiązań. W tych aplikacjach świetnie się sprawdza, ale jeżeli chcemy zastosować je w komercyjnym produkcie - lepiej tego nie róbmy.
Istnieje też szereg alternatyw. Jeśli chcemy mieć prosty system z dużą ilością bibliotek, ale lepszym kompilatorem, to zainteresujmy się np. płytkami mbed. Finalnie, najlepiej jest nauczyć się mikrokontrolerów STM32, dzięki wykorzystaniu HAL (warstwa abstrakcji sprzętowej) i dosyć prostemu systemowi konfiguracji (CubeMX) tworzenie takich projektów jest bardzo proste. (Jeśli dodatkowo wykorzystamy IDE takie jak Keil, które posiada wbudowane wsparcie dla CubeMX dla STM32 możemy cały projekt skonfigurować i opisać w łatwy sposób w jednym programie - przyp.red.).
W przemyśle istnieje wiele ścieżek - trudniejszych i łatwiejszych, niektóre równie proste jak Arduino, a z pewnością mniej problematyczne w zastosowaniach komercyjnych jak Arduino.
Źródło: http://embedded.fm/blog/2017/8/12/dont-use-arduino-for-professional-work
Fajne? Ranking DIY
