[C] Komunikacja AVR z SD/MMC i www: serwer HTTP, TCP/IP, RS485, baza danych

witam,

chciałbym stworzyć pewien sposób komunikacji, przesyłania danych.

Założenie jest takie, że sterowanie (zarządzanie bardziej) µC będzie odbywało się poprzez stronę www generowaną przez ten µC (ethernet), więc oczywistym jest że muszę mieć serwer HTTP oraz protokół TCP/IP zaimplementowany na µC.

Do µC będzie podpięta karta pamięci SD (po SPI) z bazą danych opartą na plikach tekstowych.
µC będzie rozsyłał żądania do innych µC po RS485 i otrzymywał ramki z informacjami o stanie ich portów (urządzeń którymi sterują) i zapisywał (zmieniał) odpowiednie wartości w bazie danych.
µC ma za zadanie wyświetlać strone HTTP z prezentacją bazy danych, czyli prezentować stan urządzeń (połączonych z tym µC przez RS485)

oraz

odbiorca strony, poprzez modyfikacje pól formularzy i/lub naciśnięcia linków ma mieć możliwość zmiany parametrów urządzeń w bazie, a µC poprzez RS485 prześlę do odpowiednich jednostek informacje o zmianie ich stanu (a one już to sobie zinterpretują).
W bazie będą 'gotowe schematy' które urządzenia mają być w danej chwili załączone, jakie porty aktywne etc. A użytkownik ma mieć możliwość ich (schematu) wyboru oraz modyfikacji.
czyli reasumując ten bazo-danowy-serwer-www-µC ma być sterownikiem innych µC ma zarządzać informacją w systemie

z połączeniem przez RS485, samym wysyłaniem czy interpretacją nie będę miał problemów.

Problemy na których utknąłem to:
1) wybór µC programuje na razie tylko avr ewentualnie avr32 (nie zależy mi na szybkości transmisji, ma byś stabilna :] )
czy użyć klocka z wbudowanym ethernetem i/lub stosem TCP/IP, czy bawić się jakoś ręcznie implementując stos i protokół ...
(jeżeli µC będzie mocny i np szkoda by go pakować tylko do WWW to odrazu wsprzęgne do niego obsługę wyświetlacza graficznego (najpewniej dotykowego) przez który również będzie można dokonywać tych samych operacji (prezentacja danych i ich modyfikacja) ale chciałem ten moduł 'wyświetlacza' zrobić osobno a w tym konkretnym zająć się tylko WWW)
proszę o propozycję jakiego µC byście zaprzęgli do takiej roboty.

gdy już pkt 1 zostanie rozwiązany (będe miał ethernet i TCP/IP), z samym wysyłaniem stron WWW (pobieranie danych z SD + tworzenie ramki) nie powinienem mieć problemu (ogólnie pokombinuje i zrobię)

mam tylko logistyczny problem, jak rozwiązać to 'sterowanie' poprzez www.

2a) czy ze strony HTTP, poprzez zapytania GET, POST, mogę dostać jakoś informacje do przetworzenia już dla µC (coś jak zmienne globalne ??)

2b) Czy może zrobić to jakoś na CGI (tylko że tu systemu nie będzie który uruchamiałby programy, ew funkcje, ale nie wiem czy w CGI się da tak zrobić

2c) tworzyć wirtualne linki np http://192.168.0.10/change/dev01001/1/0/128/...
gdzie change oznacza informacje że chce zmieniać stan, później ID urządzenia i w kolejnych informacje do przekazania ??
tylko czy da się to zapytanie zapisać do zmiennej ? (jak sie da to dalej sobie to podzielę i zinterpretuje i będzie grało)

jeżeli 2c da się zrobić (wydaje mi się ze tak) to dalej mam problem z formularzami, elementami listy rozwijalnej (normalne elementy HTTP, formularzy, gdzie np dla PHP się przesyła definiując zmienne)

Bardzo czekam na jakiś pomysł logistycznego rozwiązania tematu, być może w ogóle źle do tego podchodzę, musi być sterowanie przez WWW a reszta jest w fazie koncepcyjnej i bardzo czekam na jakiekolwiek propozycję

ad 1/ Jeśli chcesz mieć duże możliwości (serwer http, jakieś inne protokoły, udp, ping, ftp etc etc lub duża liczba połączeń symultanicznych), to może być potrzebne napisanie własnego stosu tcp/ip, w większości przypadków powinien jednak wystarczyć układ z wbudowanym stosem. W jednym z projektów mam atmega128 + rtl8019as (+pamięć, całość na module od propoxu), sprawdza się bardzo dobrze, z podpięciem karty sd nie miałem problemu, uartu jednak nie podłączałem do rs485, ale to nie problem - sprzęgnięcie wszystkiego w programie nie stanowi trudności. Równie dobrze można napisać własny firmware na jakiś router, o ile tylko da się z niego wyprowadzić własne sygnały.

ad 2a/ Przecież jeśli dane są wysyłane do serwera, to gdzieś się w tych nagłówkach muszą znajdować. Jeśli piszesz swój serwer http, to masz do tych danych bezpośredni dostęp, tylko musisz je wyłuskiwać z nagłówków.
ad 2b/ CGI? CGI jest interfejsem pomiędzy serwerem http a programem, umożliwiającym przekazywanie żądań do programu. Wymagane funkcje można równie dobrze zaimplementować w samym serwerze, więc tutaj nie widzę potrzeby dodawania tej warstwy.
ad 2c/ To jak będzie interpretowany adres, zależy tylko od serwera - jeden może używać go do lokalizowania pliku, inny najpierw przepuści przez mod_rewrite, inny wogóle zignoruje, a inny wyłuska z niego w swój sposób jakieś dane.
Ogólnie wszystkie dane są przekazywane do serwera, trzeba je tylko wyciągnąć ze strumienia.

czyli moje przypuszczenia co do analizowania adresu sie okazały słuszne, da się zrobić tak jak myślałem
Jednak nadal nie wiem jak z obsługą formularzy

Cytat:

Ogólnie wszystkie dane są przekazywane do serwera, trzeba je tylko wyciągnąć ze strumienia.

czyli przy przesyłaniu danych z formularzy, gdzieś ramce która dostaje z przeglądarki jest informacja jakie dane zostały wpisane? mam nadzieje że w dość tradycyjny sposób przegladarka je przesyła "POST:zmienna1=wartosc1&zmienna2=wartosc2&..."
jeżeli tak, to moje obawy się rozmywają, pozostaje kwestia implementacji wszystkiego a to tylko kwestia dostepności czasu

patrzałem na tę płytkę propoxu http://www.propox.com/products/t_124.html i zastanawiam się czy to by nie wystarczyło ...

O ile mnie pamięć nie zawodzi, to dane POST były przekazywane jako Content: w nagłówku jest tylko Content-Length (i chyba Type) czy jakoś tak, a zaraz za nagłówkiem dane w formacie: zmienna1=wartosc1&zmienna2=wartosc2.... Najłatwiej albo użyć ethereal lub tym podobne aby zobaczyć co jest wymieniane, albo zagłębić się w dokumentację protokołu http1.0 (1.1 nie trzeba)

Co do modułu - to jest ten sam, co ja mam. Według mnie spokojnie by wystarczył - pamięci wystarczająco dużo, dostępne gotowe proste systemy, które tylko trzeba nadbudować. Pamięci 60,5KB powinno wystarczyć, zawsze można w uwagach przy zamówieniu poprosić o zamontowanie R1 (lub zamontować we własnym zakresie), będziesz miał 2 banki po 60,5KB.

właśnie po Twoim poście poszukałem informacji o rtl8019as i znalazłem temat na elektrodzie gdzie był link propox'a :]

ale mam pytanie właśnie o rtl8019as, ściągnąłem z strony propoxa dokumentacje dla tego modułu i pisze w nim, że "Po wystąpieniu sprzętowego lub programowego resetu kontroler musi zostać skonfigurowany"

"Standardowym sposobem konfiguracji układu RTL8019AS jest podciąganie wejścia danych z pamięci EEPROM do plusa zasilania za pomoc rezystora R11. Zapewnia to poprawną pracę diod LED (jako wskaźników LINK i ACT), oraz ustawia kontroler w tryb full duplex. Reszta parametrów (np. adres MAC) musi zostać ustawiona programowo. "

i czy te programowe ustawianie całej reszty jest jakies skomplikowane czy przesyłam po magistrali (jeszcze nie wiem które to wyjścia/wejścia) bajty informacji i teoretycznie wszystko śmiga

ściągnąłem datasheet do rtl8019as, ale prawdę mówiąc prawie nic z niego nie zrozumiałem doczytałem się tylko, że od cholery rzeczy trzeba tam ustawiać, i nie wiem jak sie komunikować etc elektroda tez mi nie pomogła bo wszyscy mają już układ podłączony i jakoś się z nim porozumiewają (więc może to nie takie trudne a ja w złym miejscu czytam? )

zainteresował mnie w sumie NUT/OS, używałeś go może ?


znalazłem biblioteki do RTL8019 w AVRlib więc wszystko powinno działać, jak tylko przegryzę się przez wszystkie kody :]

konfiguracja kontrolera polega na tym, że do kilku(nastu) rejestrów wpisujesz odpowiednie dla siebie wartości, ustawiasz rozmiar buforów, adres MAC etc. W tym module kontroler jest widoczny w przestrzeni pamięci pod 32 adresami zaczynając od 0xFF00, więc dostęp do rejestrów jest skrajnie prosty. Komunikacja z tym układem nie jest skomplikowana, z początku jest konfiguracja, odbiór można zrobić w przerwaniach: po odebraniu sygnału przerwania sprawdzasz dwa rejestry (BNRY, CURR), robisz kilka obliczeń i pobierasz ramkę z kontrolera (na koniec poprawiasz BNRY). Wysyłanie jest prostsze: sprawdzasz, czy kontroler skończył transmisję ramki, jeśli tak to przekazujesz do niego całą ramkę do buforu, a potem nakazujesz jej wysłanie (lub inne sposoby, gdzie przekazywanie do buforu odbywa się równocześnie z wysyłaniem, tzn jeśli jest kilka buforów nadawczych). W pełni okomentowany sterownik w moim projekcie to 400 linii, więc nie jest aż tak skomplikowany.

Czy używałem NUT/OS? Nie. Nie chciał mi działać (może się nie starałem), więc napisałem swój.

acid12 napisał:

chciałbym stworzyć pewien sposób komunikacji, przesyłania danych.

podpowiedź - poszukać routera sprzętowego z możliwością rozbudowy o karty SD i z wbudowanym UART - przykład Linksys WRT54G, ..GS, ..GL
Potem już tylko napisać programik w C na router, zintegrować go z ATmega poprzez UARTa, a resztę sobie dopiszesz.

Dystrybucja OpenWRT ma wbudowany serwer WWW, można też doinstalować moduły związane z CGI, chyba nawet PHP widziałem. Generalnie najmniej roboty, najszybciej uruchomiony projekt. U mnie działa jako akwizycja danych z zapisem na karcie SDHC.

powodzenia,
--
migod

pomysł ciekawy i ogólnie wydaje się być bardzo dobry,
ale na dzień dzisiejszy dla mnie niemożliwy, tam zdaje sie ARMy siedzą jakieś a to jest nauka nowego procesora

na już, to niestety nie wykonalne (dla mnie) ale w przyszłości na pewno się nad tym zastanowię, byłoby fajnie jakby udało się zintegrować 'normalną funkcję' routera z moim zadaniem (ciekawe ile flasha/ramu zostaje wolnego...) byłyby 2 pieczenie na jednym ogniu a nawet i więcej ... :]