Pytam głównie z ciekawości. Obecnie eksperymentuję z mikrokontrolerami PIC32 od Michrochipa. Producent udostępnił całkiem fajne biblioteki do obsługi rozmaitych peryferiów, m.in. Ethernetu (sterowniki + stos TCP/IP). Było to dla mnie dość sporą zmianą, bo dotychczas korzystałem z mocno odchudzonego stosu Tuxgraphics, który nadawał się do obsługi pakietów UDP i bardzo krótkich połączeń TCP. Niemożliwe było m.in. utrzymywanie dłuższej sesji w celu obsłużenia połączenia telnetowego.

Do korzystania z TCP/IP na małych AVR-ach chyba już nie wrócę, ale zastanawiam się jak to wygląda na XMegach. Te MCU posiadają co prawda ciągle ten sam rdzeń AVR, jednak mają więcej flasha i RAM-u, no i całkiem fajne peryferia. Czy w związku z tym taka Xmega128 pozwoli na obsługę jakiegoś lepszego stosu TCP/IP? Ktoś próbował? Dostępne są jakieś przykłady? A może jedynym dostępnym wyjściem jest skorzystanie z jakiegoś chipa Wiznetu, ze sprzętową obsługą stosu?

nie trzeba zaprzegać od razu Xmegi wystarczy się zainteresować nutem
http://www.ethernut.de/en/hardware/enut1/index.html

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

1) Ale to jest chyba jakiś lekki OS pod małe mikrokontrolery? Ja jednak preferuję zwyczajną bibliotekę i programowane "bare metal". Na małych MCU to zawsze oszczędność ograniczonych zasobów.
2) Na podanej stronie wspomniany jest sterownik RTL8019AS. Mają też sterownik pod standardowego ENC28J60? To zawsze mniej elementów i ścieżek na płytce...
3) Pytałem o Xmegę, bo ma ona trochę więcej zasobów, co umiejscawia ją tak w połowie drogi miedzy małymi AVR-ami a prostszymi 32bitowymi PIC-ami. Mam po prostu nadzieję, że to wystarczy, aby odpalić na niej jakiś porządniejszy stos, który poradziłby sobie z otwartą sesją TCP albo nawet obsługą więcej niż jednego połączenia jednocześnie. No i moduł kryptograficzny też może być przydatny, gdy mowa o przesyłaniu danych Internetem.

AD1. Nut jest fajnym rtosem dla AVR - pozwala na wiele i wież mi że wiele nie oszczedzisz w porównaniu z tym co oferuje NUT
AD2. ENC28J60 to zabytek i nadaje się w sumie tylko do niewielkich rzeczy ...
AD3. Xmega jest mało udana , leży dlaeko za PIC16 wiec rdzenia MIPS w PIC32 nie obrażaj bo jest Równorzedny z ARM
zaś Xmega to 8bitowa staruszka wymuszająca zmianę narzędzi ... jak widzisz zresztą odgrzewanie kotleta nie pomogło ATMELOWI
się uratować i sprzedał się Microchipowi

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Dlaczego Xmega jest nieudana?
Prosze napisz jakies konkrety. Czy nie lepiej zamiast atmega stosować xmega?

Też zawsze mnie to ciekawiło dlaczego nie są tak popularne mimo tego że niby oferują więcej za podobną cenę.

przede wszystkim dlatego że Atmel próbował zarobić na nowym nie potrzebnym protokole programującym
próbował wymusić na użytkownikach zmianę środowiska i narzędzi , oferując to w za wysokich cenach , nie pokazując nic nowego
inni producenci zdominowali rynek lepszymi rozwiązaniami w niższej cenie jak też pozbawionych wad o większych możliwościach
z tanimi narzędziami ... ,

a reszta ... we wnętrznościach to zabytkowa babcia , która próbowali na siłę ratować ale za późno niestety
podobnie jak ich ARM pogrążył ... sumarycznie najgorszy na rynku i najbardziej zawodny

docelowo ratowało ich arduino ... , ale na samych hobbystach długo się nie uciągnie , a wiodący odbiorcy segmentu Automotive
odeszli do lepszych rozwiązań konkurencji ....

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Dzieki za odp.

Kogo masz na myśli piszac o konkurencji, ktora grupa mikrokontrolerow jest wiodaca.

Nie mam jak do tej pory żadnych doświadczeń z pisaniem pod RTOS, więc preferuję osobne biblioteki do integracji z samym projektem. Nie neguję przydatności tego Nut-a, jednak w moim przypadku posługiwanie się nim oznaczałoby konieczność nauczenia się obsługi kolejnej platformy, na ośmiobitowych MCU, których będę używał raczej w ograniczonym zakresie. Gdy będę potrzebował RTOS-a, skorzystam pewnie z jakiegoś PIC32 albo STM32. Jeśli będę potrzebował czegoś jeszcze mocniejszego, a nie będzie się liczyła część "real time" - skorzystam z Linuksa na jakimś RasPi.
W przypadku ośmiobitowców wszystkim czego potrzebuje, są zwykłe biblioteki.




RTL8019AS jest chyba jeszcze większym zabytkiem. Przecież ten układ pamięta czasy komputerowych kart sieciowych na magistrali ISA. On w ogóle nie był projektowany z myślą o stosowaniu w małej automatyce - ludzie przez długie lata korzystali z niego tylko dlatego, że nie było żadnej rozsądnej alternatywy. Dlatego też powstawały "dziwne" projekty, w których magistrala równoległa była emulowana portem Atmegi32. Poza tym tutaj naprawdę nie ma wielkiego wyboru. Są układy od Wiznetu z wbudowanym stosem, jest jakiś KSZ na SPI w obudowie QFN32, którego pełnego oznaczenie w tej chwili nie mogę sobie przypomnieć. Jest też kilka MCU PIC18F, które posiadają wbudowane MAC+PHY. I to chyba tyle.
W 32bitowych mikrokontrolerach można jeszcze korzystać z wbudowanego kontrolera MAC z osobnym PHY na magistrali MII/RMII. Jednak to już nieco wyższa szkoła jazdy, wymagająca stosowania wysokich częstotliwości, a co za tym idzie, uważnego projektowania płytki.




Nie miałeś przypadkiem na myśli PIC24, czyli rodziny szesnastobitowych układów Microchipa? PIC16 to dość proste mikrokonrolery ośmiobitowe, porównywalne (w zależności od konkretnego układu) do wczesnych AVR-ów albo nawet czegoś w stylu AT89C2051. Xmega wyprzedza je dość znacznie.



Miałem na myśli raczej to, że Xmega stoi w połowie drogi, bo:
1) Posiada ten sam rdzeń, co w starszych AVR-ach (tylko taktowany nieco wyższą częstotliwością).
2) Oferuje nieporównywalnie większy zbiór peryferiów, wśród których znajdują się i takie, które znajdywały się raczej w ofercie 32bitowych MCU. Tych "standardowych" także mamy więcej do dyspozycji.




W tej chwili można to chyba powiedzieć o STM32, ewentualnie ARM-ach Cortex M3 od innych producentów. PIC32 też są całkiem fajne, choć akurat w naszym kraju dość mało popularne.

akurat za tym modelem się zgodzę , ale jeśli chodzi o implementacje 8051 i 8052 to Xmega raczej siedzi gdzieś we wczesnej kredzie , avra kopanego ...

RTL jest stary , ale podobnie jak 8051 ponadczasowy
oczywiście masz alternatywę w postaci Wiznetów i różnych WIFI , a nawet znacznie nowszy układ ENC624J600
czy wiele innych.... jak etherCAT LAN9252



no raczej nie bardzo w połowie .... Microchipy starsze i MSP430 zdecydowanie wyprzedzają i są dłużej na rynku przez co mają bogate dokumentacje , ponadto cenowo więcej oferuje ARM za lepszą cenę z wyższą stabilnością i kultura pracy

Trochę siedziałem w Xmegach i mnie nie urzekły niczym .... te parę MHz i DMA nic nie zmienia dalej to powolny , zbtyt drogi ślimak w porównaniu z resztą rynku ...

PICE nie sa popularne w naszym kraju bo były droższe , miały droższe narzędzia developerskie i nie było darmowych środowisk innych niż assembler ... teraz się wiele na przestrzeni lat zmieniło, ja od PIC zaczynałem

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Jakie byś aktualnie darmowe środowisko polecił ?

jest przecież MPLABx z darmowymi kompilatorami C zgodnymi z Hitec wiec poco szukać i oczywiście PicKIT3

_________________
Zbuduj swój system [url=https://helion.pl/ksiazki/w-labiryncie-iot-budowanie-urzadzen-z-wykorzystaniem-ukladow-esp8266-i-esp32-andrzej-gromczynski,wlablo.htm#format/d]IOT[/url]

Główną wadą darmowego środowiska od Michrochipa są zablokowane wyższe stopnie optymalizacji kodu. Niby Drobiazg w amatorskich zastosowaniach, bo w razie czego zawsze można kupić lepszy MCU, jednak Atmel udostępniał za darmo pełne wersje swoich narzędzi.
Z drugiej strony dali się wyprzedzić konkurencji, która była w stanie przygotować bardziej zaawansowane narzędzia konfiguracyjne (STM32CubeMX, MPLABX Harmony) nie mające swojego odpowiednika w przypadku produktów od Atmela.

Co do układów Xmega, to nie mam zamiaru inwestować w nie sporo czasu. Jednak kiedyś kupiłem kilka i prostą płytkę testową z myślą o eksperymentach. Dałem się wtedy zwieść opiniom, że mikrokontrolery 32bit są trudne w obsłudze i sądziłem, że Xmega będzie dobrym "etapem przejściowym". Teraz widzę, że się myliłem - obsługa PIC32 albo STM32 przy wykorzystaniu udostępnionych przez producenta bibliotek i narzędzi konfiguracyjnych jest nawet łatwiejsza, chociaż Atmela i tak można pochwalić za uporządkowanie rejestrów w Xmegach.
Niemniej leży u mnie tych kilka mikrokontrolerów i chciałbym je kiedyś wykorzystać w jakimś projekcie, choćby z uwagi na dostępne peryferia.
Więc jak wygląda kwestia obsługi TCP? Idzie na tym odpalić jakiś przyzwoity (tzn. lepszy od Tuxgraphics) stop, pozostawiając trochę zasobów pod obsługę innych peryferiów i własnego kodu? Ktoś próbował? Stos od Microchipa można w końcu skompilować pod ośmiobitowe PIC18F...