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

> Zaraz, w prototypie używasz 0603? Czy zrobiłeś już płytkę docelowa bez
> wcześniejszego testu układu na prototypie w plytce stykowej? :)

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.


> Jednak chyba coś z kwarcem masz....

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

do góry

On 2014-01-05 00:43, Atlantis wrote:
[...]
> 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...
A generatora[*] nie da się popędzić tej kości (i ewentualnie procesora)?
Przynajmniej w ramach testu.

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

do góry

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

> Na 95% tak :) Popracuj nad generatorem. Może kwarc do d... może dzielnik
> niedobrany... wszystko może być nawet to że podłączenie sondy gasi drgania.

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.

do góry

On Sun, 05 Jan 2014 12:30:57 +0100, Atlantis <m...@w...pl>
wrote:
> Teraz czeka mnie próba odpalenia stosu TCP na tym wynalazku. ;)

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

do góry

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

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

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.

do góry

On Sun, 05 Jan 2014 21:05:44 +0100, Atlantis <m...@w...pl>
wrote:
> Dobrze, tylko najpierw muszę wgryźć się w bibliotekę i sposób
> komunikacji po TCP/IP. Ta płytka to projekt edukacyjny. Do tej pory

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

do góry

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

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

http://tuxgraphics.org/electronics/200905/embedded-t
cp-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!

do góry

On Mon, 06 Jan 2014 10:54:19 +0100, Atlantis <m...@w...pl>
wrote:
>
http://tuxgraphics.org/electronics/200905/embedded-t
cp-ip-stack.shtml

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

do góry

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

> 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

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.


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

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.

do góry

On Mon, 06 Jan 2014 15:45:21 +0100, Atlantis <m...@w...pl>
wrote:
> 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.

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

do góry