W dniu 2014-05-19 08:32, Atlantis pisze:
> W dniu 2014-05-17 18:37, mk pisze:
>
>> Jeśli krytyczna jest wydajność to nie ma co się zastanawiać:
>> mikrokontroler z wbudowanym Ethernetem.
>> Wygoda? Rzecz względna, ale faktycznie ENC28J60 pod pewnymi względami
>> może być wygodniejsze (np. design PCB).
>
> Hmm... Istnieje jakiś standard układu wyprowadzeń w MCU z wbudowanym
> kontrolerem Ethernetu i zewnętrznym interfejsie PHY? Można w miarę łatwo
> poprowadzić magistralę złożoną z równoległych ścieżek, czy raczej trzeba
> będzie się bawić w zworki i przelotki?

Jeśli istnieje to nie zauważyłem :)
Pinologia MII/RMII STM32 taka sobie... na jednej warstwie raczej nie da
rady.

>> uIP tylko do najprostszych aplikacji typu wysłanie lub odbieranie
>> pojedynczych pakietów UDP, czy też najprostsze połączenia TCP (ale
>> naprawdę najprostsze typu po połączeniu wysyłam parę bajtów i rozłączamy
>> się).
>
> Do tego spokojnie wystarczy Tuxgraphics, który jest w dodatku banalny w
> obsłudze i konfiguracji. Czegoś lepszego potrzebowałbym np. do obsługi
> telnetu.

uIP dosyć szybko i bezproblemowo uruchomiłem, ale nie będę bronił, czy
lobbował za uIP.

>> lwIP również warto ożenić z jakimś RTOS, np. z FreeRTOS. Bez
>> wielowątkowości tworzenie aplikacji sieciowych, poza tymi najprostszymi,
>> szybko stanie się koszmarem.
>
> To raczej jeszcze daleko przede mną. Poza tym gdybym potrzebował
> wielowątkowości do jakiegoś poważniejszego projektu, pewnie sięgnąłbym
> po jakąś linuksową płytkę. Zresztą zanim w moim przypadku zajdzie taka
> potrzeba, to na rynku pojawią się tanie MCU SoC, mieszczące kompletny
> linuksowy komputerek w obudowie LQFP. ;)

W jakiś RTOS warto zainwestować. Warto stosować nawet mało-średnich
projektach. Jak przedstawiłeś jesteś na etapie przesiadki 8 do 32-bitów.
Jeśli jeszcze nie masz w arsenale swoich kompetencji budowania aplikacji
mikrokontrolerowych opartych o RTOS, to ja na Twoim miejscu bym się tym
zajął niż jakimiś Ethernetami. A przy aplikacjach Ethernetowych wiedza
ta będzie tylko procentować.

Jeśli chodzi o pingwina stawianego na małych platformach, to się już z
nim przepraszam od jakiegoś czasu. Zgadzam się, że Ethernet na
mikrokontrolerze to zawsze mniejsza lub większa rzeźba. Nawet jak się
wyrzeźbi to apetyt rośnie w miarę jedzenia: a to przydała by możliwość
równoległej obsługi większej liczby połączeń, a to jeszcze jeden serwis,
a to jeszcze wypaśniejsze i ładniejsze www (czyli trzeba je komuś
zlecić, kto się tym profesjonalnie zajmuje; a jak ktoś zrobi, to zrobi
np. na Ruby on Rails :-) ), a w urządzeniu które na początku miało być
prostym rejestratorem danych w końcu dochodzi się do konkluzji: a
dlaczego by zmagazynowanych danych nie udostępniać w postaci bazy
danych... Ale z drugiej strony jakieś proste, ale bardzo szybkie I/O,
czy jakieś inne ustrojstwa mające pracować w rygorze czasu rzeczywistego
(STM32 np. wspiera IEEE1588).

>> Moim zdaniem warto, bo Ethernet to już szybkie przebiegi i łatwo
>> popełnić jakiś błąd w projekcie. Układ może mieć nawet pozory działania,
>
> Mówimy o Fast Ethernet czy o Ethernecie w ogólności. Bo zaprojektowałem
> już kilka płytek z ENC28J60 i nie miałem jak dotąd żadnych problemów.
> Pingi dochodzą bez gubienia pakietów. Nie pamiętam, żebym kiedyś nie
> otrzymał odpowiedzi na wysłany pakiet UDP.

Piszę o Fast Ethernecie i raczej o połączeniach na drodze PHY-wtyk.
A "u mnie działa" nie równa się "u klienta działa" :)

>> ale będą gęsto i często np. ginąć pakiety, transmisja będzie się
>> zacinać. Nie będziesz wiedzieć czy soft Ci szwankuje czy może jednak
>> hardware. Lepiej oprzeć się na czymś sprawdzonym.
>
> Gdybym jednak chciał zaprojektować własną płytkę, to o czym przede
> wszystkim powinienem pamiętać?

Poprawny dobór elementów (czasami nie tylko co do wartości znamionowych
głównego parametru), właściwe zasilanie, właściwy design płytki (patrz
pdfy z zaleceniami), sprawdzenie częstotliwości pracy generatora, trochę
szczęścia.
Inna jeszcze sprawa czy robisz dla siebie, czy robisz produkt który musi
przejść testy EMC.

pzdr
mk