On Fri, 3 Feb 2017 15:41:04 +0100, Atlantis <m...@w...pl>
wrote:
> 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.

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

--
Marek

do góry

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

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

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.

do góry

On Fri, 3 Feb 2017 18:30:46 +0100, Atlantis <m...@w...pl>
wrote:
> 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?

--
Marek

do góry

Atlantis <m...@w...pl> wrote:
> 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?

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

do góry

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

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

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. ;)

do góry

On Fri, 3 Feb 2017 19:09:23 +0100, Atlantis <m...@w...pl>
wrote:
> Sprawdzało się to całkiem nieźle, naprawdę odciążając AVR-a.

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

--
Marek

do góry

On Fri, 3 Feb 2017 17:52:06 +0000 (UTC), a...@m...uni.wroc.pl
wrote:
> - Przy upraszcznia bootloadera usunieto wsparcie dla
> targetu RAM (tzn. ladownia kodu do RAM i wykonania
> tam). Ja normalnie pracuje w tym trybie.

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

--
Marek

do góry

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

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

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.

do góry

Atlantis <m...@w...pl> napisał(a):
> 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.

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.

--
Grzegorz Niemirowski
http://www.grzegorz.net/

do góry

On Fri, 3 Feb 2017 21:02:50 +0100, Atlantis <m...@w...pl>
wrote:
> 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.

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.

--
Marek

do góry