Arduino i płytki z MCU innymi niż AVR

W dniu 2017-02-03 o 08:46, Atlantis pisze:

A czy cokolwiek arduinopodobnego może być używane w krytycznych zastosowaniach?? Ja pod tym czymś napisałem spory kawałek kodu i całość poszła do śmietnika. Można się pobawić i to nawet działa. Ale w końcu dochodzi się do kresu możliwości. Gówniany edytor, gówniany preprocesor, gówniana java. Lepiej od razu iść w kierunku czegoś normalnego i olać takie zabawki. Mini Maple STM32f103.

W dniu 2017-02-03 o 10:19, ww pisze:

Ja sobie z tego doskonale zdaję sprawę. Dlatego gdy piszę jakiś większy projekt, który trzeba podzielić na pliki - stosuję IDE od producenta (AVR, PIC albo STM32) tudzież sam piszę makefile'a i używam make (płytki na Linuksie). Arduino jest jednak dobre, gdy trzeba szybko stworzyć coś prostego - jakiś mały moduł, który nie robi zbyt wielu rzeczy. Zaletą tej platformy jest wsparcie ze strony środowiska oraz duża liczba dostępnych bibliotek, które w większości przypadków działają "po wyjęciu z pudełka". Nie muszę się martwić przystosowywaniem ich do konkretnego modelu albo portowaniem pod konkretną rodzinę MCU. Oczywiście wszystko to kosztem mniejszej elastyczności...

No i w przypadku AVR-ów ta dodatkowa warstwa abstrakcji ułatwiająca programowanie zabiera jednak "trochę" cykli procesora, więc chcąc robić coś krytycznego czasowo trzeba i tak odwoływać się bezpośrednio do rejestrów.

W dniu 03-02-2017 o 08:46, Atlantis pisze:

Nie używam Arduino, ale Czego nie możesz zrobić na AVR(XMEGA)? Tak z czystej ciekawości?

W dniu 2017-02-03 o 10:43, snipped-for-privacy@wp.pl pisze:

W poważniejszych projektach też nie. Niemniej do prostego prototypowania jest ok. Do tego w chwili obecnej najłatwiej przetestować nową część czy moduł właśnie za pomocą Arduino, na na tę platformę najłatwiej o przykłady w Sieci.

Nie podłączę do WiFi. Nie odpalę na tym porządnego stosu TPC/IP. Nie ustawię kilku większych buforów na dane (audio, grafika do wyświetlenia na LCD). Operując na zmiennych 16 i 32-bitowych muszę cały czas pamiętać o ATOMIC_BLOCK-u jeśli istnieje szansa, że któreś przerwanie będzie się próbowało dobrać do tej zmiennej. ;)

A co przeszkadza?

Zewnętrzna działa przy 66MHz (przetestowane z SRAM 4 portowo)

tak to chyba jedyny problem.

Podaj przykład porządnego (szybki transfer liczony w min. dziesiątki kB/s, obsługa wielu połączeń równolegle) stosu, który wraz z docelową aplikacją zmieści się w 8kB RAM, chętnie potestuję. Doceniam możliwość podłączemia zew. pamięci ale to trochę takie sztukowanie.

Użytkownik "ww"

A czy cokolwiek arduinopodobnego może być używane w krytycznych zastosowaniach?? Ja pod tym czymś napisałem spory kawałek kodu i całość poszła do śmietnika. Można się pobawić i to nawet działa. Ale w końcu dochodzi się do kresu możliwości. Gówniany edytor, gówniany preprocesor, gówniana java. Lepiej od razu iść w kierunku czegoś normalnego i olać takie zabawki. Mini Maple STM32f103.

Użytkownik "Atlantis"

... Arduino jest jednak dobre, gdy trzeba szybko stworzyć coś prostego - jakiś mały moduł, który nie robi zbyt wielu rzeczy. Zaletą tej platformy jest wsparcie ze strony środowiska oraz duża liczba dostępnych bibliotek, które w większości przypadków działają "po wyjęciu z pudełka".

W dniu 2017-02-03 o 11:29, snipped-for-privacy@wp.pl pisze:

Mogę podłączyć zewnętrzny moduł, zajmujący się obsługą WiFi i TCP/IP. W module takim zwykle siedzi jakiś 32bitowy mikrokontroler, który często można programować. Podpinanie do tego 8bitowego AVR-a pełniącego funkcję głównego MCU to moim zdaniem wydziwianie. Jasne - są sytuacje, kiedy jest to uzasadnione (bo np. moduł nie ma jakichś peryferiów), ale wówczas mamy raczej do czynienia z projektem wieloprocesorowym.

Zależy na jaki stos, zależy co chcesz obsługiwać poza nim. Dodaj do tego jeszcze obsługę hosta USB (kolejny argument za przejściem na 32bitowce), warstwy MSD i systemu plików. Dolicz jakieś większe bufory w warstwie aplikacji i może się okazać, że 8kB to naprawdę niewiele.

To ma sens chyba tylko wtedy, gdy tej pamięci potrzebujesz NAPRAWDĘ dużo. Jeśli brakuje kilku-kilkunastu kB po co sobie komplikować projekt od strony sprzętowej?

Dlaczego? Zdaje się, że sam używałeś taką konfigurację, co w niej jest nie tak?

W dniu 2017-02-03 o 15:49, Marek pisze:

Używałem raz, i nie do końca w takiej konfiguracji. To znaczy trudno powiedzieć, że AVR był tam "głównym MCU". Chodzi o mój projekt zegara Nixie. Tam Atmega zajmowała się obsługą RTC, multipleksowaniem wyświetlaczy i odczytywaniem przycisków. ESP8266 miał swój własny wsad, odpowiedzialny za cykliczne odpytywanie serwera NTP i generowanie interfejsu WWW (ta ostatnia funkcjonalność jeszcze nie została w pełni zaimplementowana). Obydwa elementy wymieniały się tylko podstawowymi informacjami przez UART.

Skoro ESP ma na tyle mocy obliczeniowej i jest programowalny, to nie za bardzo widzę sens w przenoszeniu warstwy aplikacji na ośmiobitowy mikrokontroler.

Ale ja miałem na myśli układy wiznet a nie esp. Nie robiłeś coś z nimi + avr?

Arduino_STM32 to rozwinicie libmaple i zintegrowanie ze srodowiskiem Arduino. Nie uzywalem ale troche sie temu przygladalem (kolo roku temu wiec moglo sie zmienic) zanim zdecydowalem nie uzywac. libmaple ma dosc dobra obsluge STM32F1 i raczej slaba innych rodzin. Arduino_STM32 niby tu dodaje nowe procki ale ciagle byly istotne braki w obsludze urzaden. Moje wrazenie ze glowna zmiana jest w bootloaderze -- bootloader z libmaple byl kompiloway bez optymalizacji i mial spory rozmiar. W Arduino_STM32 bootloader jest znacznie mniejszy. No i integracja z obecnym Arduino IDE (libmaple wspolpracje z Maple czyli klonem starej wersji Arduino). Jest tez troche wiecej bibliotek (ale dalej braki w porownaniu z AVR). Nie uzylem bo:

- Wole linie polecenia od IDE, wiec integracja z Arduino IDE to dla mnie byl krok wstecz. Dla jasnosci: przekonalbys mnie do dobrego IDE, ale Arduino IDE jest strasznie toporne.

- Przy upraszcznia bootloadera usunieto wsparcie dla targetu RAM (tzn. ladownia kodu do RAM i wykonania tam). Ja normalnie pracuje w tym trybie.

- Wczesniej sobie przeportowalem do ARM kilka bibliotek Arduino i dodatki z Arduino_STM32 mi nic specjalnego nie dawaly.

- Byly jakies dziwne problemy z wersjami. Tzn. deweloperzy Arduino co chwile zmieniali cos we wsparciu dla ARM-a i Arduino_STM32 dzialalo z konkretna wersja, wtedy ekperymentalna Arduino IDE, a z niby stabilnimi wersjami nie dzialalo.

Co do stabilnisci: co bylo zaimplementowane w libmamaple to mi dzialalo. Dla STM32F1 to w pewnym sensie byl komplet. Dla F4 bylo sporo brakow. W Arduino_STM32 w zasadzie powinno byc lepiej (oprocz IDE), tyle ze nie probowalem...

Jest tez jest projekt Energia. To dla prockow TI, ale przeportowali sporo bibliotek Arduino do ARM-a. W sumie oznacza to ze czesto port biblioteki daje sie znalezc w sieci. Ale ilosc dogranych gotowcow jest znacznie mniejsza niz dla Arduino-AVR. Dodam ze sporo "bibliotek" to banaly ktore tylko wolaja takie rzeczy jak digitalWrite. Takie sie latwo portuja. Dla mnie istotniejsze sa biblioteki ktore dodaja wsparcie dla ciekawszego sprzetu -- w Arduino-AVR one czesto bazuja na niskopziomowych ficzerach AVR i wtedy z portem jest wiecej roboty.

W dniu 2017-02-03 o 18:39, Marek pisze:

Eksperymentowałem z nimi. Skleciłem sobie kiedyś płytkę prototypową z Atmega644 i W5100. Głównie celem sprawdzenia, czy uda mi się wytrawić i zlutować coś z tak małymi padami i cienkimi ścieżkami. Udało się - układ działał całkiem przyzwoicie, chociaż jego EMC pewnie wyglądała kiepsko zważywszy na jednostronną płytkę i co za tym idzie brak pola masy po drugiej stronie. Strona software'owa składała się ze zmodyfikowanej biblioteki Arduino Ethetnet - usunąłem wszelkie odwołania do Arduino Core, zostawiając jednak obiektową formę, a wiec musiałem stworzyć projekt C++ w Atmel Studio.

Sprawdzało się to całkiem nieźle, naprawdę odciążając AVR-a. Jednak teraz mając do wyboru potężne, 32bitowe MCU, preferuję podejście software'owe.

A różnica w stosunku do ESP polega na tym, że Wiznety nie są programowalne - to specjalizowane sterowniki Ethernetu, z wbudowanym stosem TCP/IP. Warstwy aplikacji się na nich nie postawi. ;)

No ale wcześniej napisałeś, że taka konstrukcja to widziwianie, czyli co się nie sprawdzilo w tandemie avr+wiznet?

A możesz zdradzić czemu konieczne było w, Twoim przypadku wykonywanie z ram?

W dniu 2017-02-03 o 20:10, Marek pisze:

Miałem na myśli tylko i wyłącznie sytuację, kiedy moduł WiFi (np. ESP) możemy zaprogramować, ale i tak upieramy się sterować nim z o wiele słabszego, ośmiobitowego mikrokontrolera. Szczególnie, jeśli nie istnieją żadne istotne powody, uniemożliwiające podzielenie pracy na kilka procesorów. Nie mogę na przykład zrozumieć, dlaczego tak wielu ludzi upiera się, żeby ESP8266 sterować za pomocą komend AT z Arduino. Internet jest pełen takich projektów.

A W5100 to po prostu sprzętowy kontroler Ethernetu z wbudowanym stosem. Trochę inna sprawa. Tego już od innej strony ugryźć nie można, bo układy Wiznetu nie potrafią pracować autonomicznie.

Atlantis snipped-for-privacy@wp.pl napisał(a):

Wada projektów takich jak Arduino. Zamykają użytkownika w prostym wygodnym świecie i potem nawet nie wie, że można coś zrobić łatwiej/lepiej/inaczej. Jak im powiesz, że LED może migać bez mikrokontrolera, to robią wielkie oczy.

Wiem, ale właśnie o to pytam. Jestem ciekaw co można wyciągnąć z takiego tandemu 8bit+wiznet. Ile gniazd można obsłużyć, jakie transfery można uzyskać? Wypasiony stos w mcu zabiera sporo zasobów, w porównaniu z tym co potrzebuję aplikacja końcowa. Przeniesienie stosu do wyspecjalizowanego układu powinno pozwolić by na aplikację końcową wystarczył 8bitowy mcu.