Taktowanie ATMegi 328P z ENC28J60 na 3,3V problemy z CLKOUT i wartościami kondensatorów?

Sat Jan 04, 2014 8:45 pm   

W dniu 2014-01-04 19:00, Artur Miller pisze:


W MCU czy ENC?
Jeden i drugi jest podciągnięty do VCC.
Co z nim może być nie tak?

Sat Jan 04, 2014 10:46 pm   

On Sat, 04 Jan 2014 20:45:33 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Vcap podłączony? Wszystkie Vdd/Vss ?

--
Marek

Sat Jan 04, 2014 10:52 pm   

On Sat, 04 Jan 2014 22:46:27 +0100, Marek <fake@fakeemail.com> wrote:

Czy piny encj są podłączone jak na tym schemacie (chodzi tylko o piny
encj):
http://img264.imageshack.us/img264/7565/encao2.png

--
Marek

Sat Jan 04, 2014 11:05 pm   

W dniu 2014-01-04 22:52, Marek pisze:


Są podłączone jak na tym schemacie:
http://tuxgraphics.org/common/src2/article06061/eth-remote-device.pdf

Czyli pin reset jest na stałe podciągnięty do VCC za pomocą zewnętrznego
rezystora, RBIAS w moim przypadku ma 2,7k. W roli VCAP zastosowałem
kondensator 0603 (brak polaryzacji końcówek).

W pobliżu poszczególnych pinów zasilania są kondensatorki 100nF.

Sun Jan 05, 2014 12:28 am   

On Sat, 04 Jan 2014 23:05:24 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Zaraz, w prototypie używasz 0603? Czy zrobiłeś już płytkę docelowa
bez wcześniejszego testu układu na prototypie w plytce stykowej?
Jednak chyba coś z kwarcem masz....

--
Marek

Sun Jan 05, 2014 12:43 am   

W dniu 2014-01-05 00:28, Marek pisze:


Zaprojektowałem prostą płytkę prototypową, jako bazę do dalszych
eksperymentów. Jest na niej ENC28J60 i ATMega328P. Wyjścia portów
wyprowadzone w formie goldpinów. Wcześniejsze montowanie tego na płytce
stykowej byłoby dość kłopotliwe (gniazdko RJ45, rezystory 49 om 1%,
które mam tylko w wersji SMD) i moim zdaniem niepotrzebne. To na dobrą
sprawę tylko dwa układy spięte magistralą SPI + zasilanie + parę
gniazdek i goldpinów.



Drugi kwarc (tego samego typu, kupiony w tym samym sklepie, zapewne z
tej samej serii produkcyjnej) także nie działa. Spróbuję jeszcze z
kondensatorami, tylko niestety w tej chwili nie mam nieco
mniejszych/większych pojemności w odpowiednim rozmiarze.

Jeśli to nie pomorze, to poszukam innych kwarców...

Sun Jan 05, 2014 1:38 am   

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

Przynajmniej w ramach testu.

[*] Np. http://tnij.org/huw1x1x

Sun Jan 05, 2014 12:30 pm   

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.

Sun Jan 05, 2014 4:42 pm   

On Sun, 05 Jan 2014 12:30:57 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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.

--
Marek

Sun Jan 05, 2014 9:05 pm   

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.

Mon Jan 06, 2014 10:47 am   

On Sun, 05 Jan 2014 21:05:44 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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)?

--
Marek

Mon Jan 06, 2014 10:54 am   

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


http://tuxgraphics.org/electronics/200905/embedded-tcp-ip-stack.shtml

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:

http://tuxgraphics.org/common/src2/article09051/

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

Mon Jan 06, 2014 2:44 pm   

On Mon, 06 Jan 2014 10:54:19 +0100, Atlantis <marekw1986NOSPAM@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).

--
Marek

Mon Jan 06, 2014 3:45 pm   

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.

Tue Jan 07, 2014 12:16 am   

On Mon, 06 Jan 2014 15:45:21 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

Zauważ, że skompilowałeś mocno okrojoną bibliotekę, implementująca
absolutne minimum do zestawienia tcp. Gdy chce się uruchomić w miarę
wydajny (mogący obsłużyć kilka równoległych sesji) serwer tcp, na
dodatek potrzebny jest np. ntp do synch. czasu czy nawet resolver to
implementacja stosu gwałtownie spuchnie z 9 do kilkudziesięciu kB.
Oprócz rozmiaru szybkość też staje się wymaganiem, stąd hardwerowa
implementacja w dedykowanym układzie nie jest taką głupia. Wcześniej
pisałem: zmiana w kodzie (5% całości firmwaru) robiącym coś poza tcp
wymaga wgrania całości. Z dedykowanym układem na stos mcu mogłyby być
prostrzy a firmare mniejszy i mniej skomplikowany.

--
Marek