Taktowanie ATMegi z ENC28J60

On 2014-01-05 00:43, Atlantis wrote: [...]

Przynajmniej w ramach testu.

[*] Np.

W dniu 2014-01-04 19:40, Jacek Maciejewski pisze:

Udało mi się dorwać kwarc z innej serii. ATMega ruszyła zaraz po jego wlutowaniu, programator znów ją widzi. Teraz czeka mnie próba odpalenia stosu TCP na tym wynalazku. ;)

Wielkie dzięki za pomoc.

Podeślij jaką udało Co się uzyskac prędkość w kilobajtach/sek przesyłając dane po tcpip z układu do PC i przy jakiej F zegara mcu.

W dniu 2014-01-05 16:42, Marek pisze:

Dobrze, tylko najpierw muszę wgryźć się w bibliotekę i sposób komunikacji po TCP/IP. Ta płytka to projekt edukacyjny. Do tej pory miałem tylko do czynienia z prostymi przykładami zastosowań sieciowych, zrealizowanych na Arduino z Ethernet Shieldem.

Interesuje mnie w tej bibliotece ile gniazd tcp może być naraz otwartych a co za tym idze ile połączeń jednoczesnych mcu może przyjąć od łączących się klientów. Mógłbyś podać link gdzie opisane jedt co ta biblioteka ma zaimplementowane z tcp/ip (czy ma udp, dhcpd, czy ma resolver itp)?

W dniu 2014-01-06 10:47, Marek pisze:

Z tego co widzę jest to trochę inaczej rozwiązane:

"Microcontrollers are, as the name already suggests, small. If you implement a TCP/IP stack then you are limited by the available processing power and especially the available RAM that such chip have. The stack has to be as small as possible and you have to decided how you spend the available memory. Most stack implementations introduced therefore a very low limit on the number of parallel sessions. Typical values are 2-3 parallel web browser connections. The tuxgraphics stack takes a different approach. There is no hard-coded limit. Instead we limit the amount of data that a web page can hold to one IP packet."

Opis z powyższego linku został przygotowany, gdy stos był w wersji 3. Teraz doszli już do 5.

Tutaj masz poszczególne wersje do ściągnięcia, wraz z wypisanymi zmianami:

Na stronie są podane przykłady funkcjonalnych urządzeń, zbudowanych w oparciu o tak małe MCU jak ATMega 88!

On Mon, 06 Jan 2014 10:54:19 +0100, Atlantis snipped-for-privacy@wp.pl wrote:

Bardzo ładne, podoba mi się, że jest taki minimalistyczny, w wolnej chwili przeportuje go sobie na picka bo jest bardziej kompaktowy niż ten od microchipa (za stary jestem i zbyt dużo czasu poświęciłem pickom aby uczyć się atmegi). Natomiast ciekawy jestem czy ta minimalistycznosc Ci wystarczy a konkretnie chodzi mi o zahardcodowany serwer www (dalej będę używał skrótu "httpd") bez typowego document root. U mnie użycie tcp (nie)stety mocno ewoluowało. Jak na początku testowałem tcp to właśnie w takiej konfiguracji, gdzie httpd odpowiada szablonem prostej strony zaprogramowanym we flash. Podczas testów doszedłem do wniosku, że jest to dość uciążliwe rozwiązanie, bo każda zmiana w szablonie (dodanie nowej informacji, przycisku itp.) wymaga programowania układu (wgrania nowego szablonu, który jest częścią całego kodu we flash). Strona serwowana przez mcu miała być wyświetlana na telefonie i być w miarę miła dla oka a to wymaga bardziej złożonego kodu. Najwygodniej dla zarządzania tym kodem strony mieć go w plikach (index.html, css oraz potrzebne pliki graficzne buttonow). Pierwszym krokiem było zrobienie na szybko coś w rodzaju VFS, niezbędne pliki były konwertowane w tablicę, która była częścią kodu i do której httpd "sięgał" serwując żądania http (do plików). Było to wygodniejsze bo mogłem plik html normalnie edytować na PC a później skryptem przekonwertowac go na tablicę VFS i wgrać całość do mcu. Oczywiście ciągle pozostała niewdzięczna czynność wgrywania całości kodu przy każdej zmianie w html. To spowodowało, że zdecydowałem się dodać obsługę karty SD + fat na której są po prostu pliki źródłowe strony. Przy tym kroku zdecydowałem się też na zmianę mcu na trochę większy, bo dodanie SD i fat przekroczyłoby rozmiar dostępnej pamięci. Ale na tym nie koniec, natura lenia dała znać o sobie, sugerując, że przecież upierdliwe jest wyciąganie karty, wkładanie jej do czytnika, później czytnik do PC, wgranie nowej wersji "strony", odmontowanie czytnika, włożenie karty z powrotem do układu. Dodałem do httpd obsługę uploadu plików, aby w ten sposób je aktualizować (bez wyciągania karty). Już myślałem, że to będzie wreszcie koniec mieszania i może w końcu zrobię porządną płytkę do tego układu. Przypomniało mi się, że ten układ oprócz serwowania danych przez www ma wysyłać przez IR dane do wyświetlacza LCD wiszącego na przeciwnej ścianie. Szukając wolnego pina w mcu dla diody nadawczej IR okazało się, że nie ma, wszystko użyte (użyłem pic32 w wersji dip28 bo jest wygodny w prototypowaniu). Wyszło na to, że gdybym pozbył się karty SD i użył USB (mass storage/pendrive) to zwolniłby się potrzebny pin. Dodatkowo pendrive jest o niebo wygodniejszy niż karta SD. Jak to działa można sobie obejrzeć, "serwer" jest dostępny tutaj (szablon mobilny): http://83.5.7.21:8080

Można nawet się telnetnąć (user & pass dowolne).

W dniu 2014-01-06 14:44, Marek pisze:

Przykład z serwerem www (wyświetlanie komunikatu w przeglądarce, zgłaszanie błędu 401 i odpowiadanie na pingi) kompiluje się do pliku

*.hex o rozmiarze nieco mniejszym niż 9kB. To pozostawia sporo miejsca we Flashu ATMEgi328. W tym kontekście niezrozumiałe są dla mnie zarzuty zwolenników układu W5100, krytykujących ENC28J60 za brak sprzętowej obsługi stosu.

Ja mam trochę inne podejście do tego zagadnienia. Docelowo planuję uruchomić na ATMedze klienta HTTP, który będzie wysyłał informacje do serwera pracującego na Raspberry Pi. Dzięki temu wyświetlaniem ładnej strony będzie mógł się zająć lighttpd albo nginx. Zadaniem MCU będzie zbieranie danych. W ten sposób planuję zrobić prostą, sieciową stację pogodową.

Innym zagadnieniem, które chciałbym rozgryźć jest wysyłanie i odbieranie danych z Twittera. Do tego też potrzebuję jedynie klienta.

zarzuty

dodatek potrzebny jest np. ntp do synch. czasu czy nawet resolver to

prostrzy a firmare mniejszy i mniej skomplikowany.

--
Marek

W dniu 2014-01-07 00:16, Marek pisze:

Niby racja. Jednak w wielu takich przypadkach można już sobie zadać pytanie, czy to faktycznie zastosowanie dla ośmiobitowego MCU. W pewnym momencie bardziej chyba opłaca się zaprząc do roboty jakiś linuksowy minikomputerek w rodzaju RasPi. Obsługa stosu wbudowana w urządzenie niezaprzeczalnie czasem się przydaje (np. nie narzekam na jej obecność w modułach GSM). Niemniej czasem odnoszę wrażenie, że na ENC28J60 narzekają ludzie, którzy na Arduino Ethernet robiliby proste urządzenia, których jedynym zadaniem byłoby wysłanie wyniku paru pomiarów do zdalnego serwera albo włączenie/wyłączenie przekaźnika po otrzymaniu określonego GET-a. :)

Do W5100 może łatwiej bym się przekonał, gdyby był dostępny w TQFP.

Jeśli chodzi o pracę mojej płytki ze stosem tuxgraphics, to na razie prezentuje się całkiem dobrze. Chodziła całą noc, nie zauważyłem żadnego zawieszenia ENC28J60.

Swoją drogą znasz jakąś metodę na sprawdzenie prędkości transferu pomiędzy pecetem a płytką z tym prostym serwerem http?

W perwszej wersji zmodyfikowałem httpd aby odpowiadał contentem (nagłówki Content-type i Content-length) o sporej długosci np 500 kB i pobierałem taki content wgetem na PC, a wget w trakcie transferu podaje prędkość aktualną i średnią na koniec. Content to była litera A wysyłana w petli o określonej iteracji żeby się zgadzało z zadeklarowanym wcześniej Content-length. Później w ten sposób exportowałem sobie dump pamięci flash.

A tego nie zrozumiałem, narzekają, że do takich prostych requestow Encj się nie nadaje?

Tutaj głupotę napisalem, oczywiście w pętli był wysyłany bufor zawierający AAA... długość bufora to było chyba 64 bajty. Podejrzewam że w Twojej bib też jest jakiś odpowiednik send(socket, buffer, len). W każdym razie wiesz o co chodzi.

W dniu 2014-01-07 20:38, Marek pisze:

Hmm... Nie wiem na ile to wiarygodne, ale przeprowadziłem próbę bez zmieniania długości. Plik index.html ma 44 bajty i został pobrany przez wgeta z prędkością 42.97 KB/s. Taktowanie ATMegi to 12,5 MHz, ENC28J60 pracuje na dwa razy szybszym zegarze.

W dniu 2014-01-07 20:41, Marek pisze:

Słyszałem już po prostu głosy ludzi, którzy najchętniej do wszystkiego dawaliby W5100. Bo przecież on jest lepszy. Bo przecież ma wbudowany stos! :)

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

Nie przeprowadzisz wiarygodnego testu na 44 bajtach. Przypomnij sobie chociażby rozmiar pakietu TCP. Zrób jak pisze Marek, prześlij co najmniej kilkaset kB.

Za mało danych, Musi pobierać kilka sekund, wtedy będzie bardziej miarodajne. Niech encj przerzuci więcej pakietów, będziesz widział czy nl. transfer nie "pływa" i nie szarpie - czy jest stabilny. Miałem kiedys problem z encj: transfer początkowo był duży po czym gwałtownie malał, nie pamietam już co było przyczyną. W każdym razie taki burst test (najlepiej kilka połączeń równoległych) jest dobry nas sprawdzanie stabilności statosu.

W dniu 2014-01-07 21:04, Marek pisze:

Ok, sprawdzę w następnej wolnej chwili. Tak swoją drogą mam jeszcze jedno pytanie. Jak to jest z wartością rezystora na pinie RBIAS? On jest w jakiś sposób krytyczny? Spotykałem się z jednym schematem, gdzie były wprost podane, że musi to być rezystor o dość nietypowej wartości 2,31k w wersji 1%. Na innych schematach widywałem w tym miejscu rozmaite rezystory pomiędzy

2k i 2,7k.

W swojej płytce wlutowałem rezystor 2,7k w wersji 5% (obudowa 0603). Czy to może mieć jakiś negatywny wpływ na stabilność pracy układu, szybkość transmisji albo ilość błędów?

Spotykałem

Ja mam 2K jak datasheet wskazuje. Nie wiem skąd te 2.7k u innych. Może zamiast 50 ohm przy trafo stosują 47 (łatwiej dostępny w szeregu) i kompensują to inną wartością rbias