Arduino: jak działają płytki ESP8266 i STM32 w praktycznych projektach?

Fri Feb 03, 2017 8:46 am   

Co prawda nie korzystam z Arduino przy "poważniejszych" projektach, ale
czasem przydaje się ono, gdy trzeba zrobić coś na szybko, sprawdzić
jakiś moduł itp. Problem w tym, że najpopularniejsze płytki są oparte na
AVR-ach, a więc dysponują dość skromnymi parametrami.
Oficjalnie jest wspierane Arduino Due na ARM-ie od Atmela, ale poza tym
są też dostępne nieoficjalne paczki, dodające obsługę kolejnych płytek.
Interesują mnie szczególnie dwie z nich.

1) Płytki na module WiFi ESP8266. Można je doinstalować przez dodanie
odpowiedniego URL-a w opcjach programu. Wtedy pojawią się w Board
Managerze. Jak wygląda to rozwiązanie w praktyce? Projekty działają
stabilnie? Można osiągnąć zbliżoną funkcjonalność do tego, co oferuje
oficjalne SDK od Espressif? Jak wygląda kwestia kompatybilności z
istniejącymi bibliotekami?
2) Paczka dodająca obsługę paru płytek na układach STM32. Jest do
pobrania na GitHubie:
https://github.com/rogerclarkmelbourne/Arduino_STM32
Autor informuje jednak, że oprogramowanie ma charakter eksperymentalny i
rozwojowy, nie powinno być używane w krytycznych zastosowaniach, a on
nie bierze żadnej odpowiedzialności. Ktoś korzystał z tego? Jak to
działa w praktyce?

Fri Feb 03, 2017 10:19 am   

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.

Fri Feb 03, 2017 10:37 am   

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.

Fri Feb 03, 2017 10:43 am   

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?


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus

Fri Feb 03, 2017 11:01 am   

W dniu 2017-02-03 o 10:43, konsul41@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.

Fri Feb 03, 2017 11:29 am   

Xmega128A1u
128KBytes of in-system self-programmable flash
8KBytes boot section
2K - Bytes EEPROM
8K Bytes internal SRAM
External bus interface for up to 16Mbytes SRAM
External bus interface for up to 128Mbit SDRAM

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




---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus

Fri Feb 03, 2017 1:48 pm   

On Fri, 3 Feb 2017 11:29:00 +0100, "konsul41@wp.pl" <konsul41@wp.pl>
wrote:

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.

--
Marek

Fri Feb 03, 2017 2:33 pm   

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.
---
Są inne środowiska programistyczne do modułów Arduino np Visual Studio a
moduły Arduino są gotowe, nie trzeba ich strugać.

Fri Feb 03, 2017 2:35 pm   

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".
---
No tak ... 4/5 na działa. Co ciekawsze nie działają, trzeba poprawiać albo
przebudowywać.

Fri Feb 03, 2017 3:41 pm   

W dniu 2017-02-03 o 11:29, konsul41@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?

Fri Feb 03, 2017 3:49 pm   

On Fri, 3 Feb 2017 15:41:04 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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

--
Marek

Fri Feb 03, 2017 6:30 pm   

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.

Fri Feb 03, 2017 6:39 pm   

On Fri, 3 Feb 2017 18:30:46 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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

--
Marek

Fri Feb 03, 2017 7:09 pm   

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.

Fri Feb 03, 2017 7:52 pm   

Atlantis <marekw1986NOSPAM@wp.pl> wrote:

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.

--
Waldek Hebisch