Witam,

Na początku chciałem zaznaczyć, że tytuł miał brzmieć:
Asynchroniczna komunikacja: serwer www [AJAX] <-> n*[system uc avr] [RS232] ale... niestarczyłomimiejsca...

Dobrze, no to lecimy...
Wczoraj na chat'cie (jak to się odmienia??) pytałem pewnego kolegę i poradził mi żebym tutaj wklepał ten pomysł. Nie będę wymieniał o Kogo chodzi, najwyżej niech sam się zdekonspiruje.

Od jakiegoś czasu chodzi mi po głowie pomysł wykorzystania pewnych technologii w komunikacji obustronnej pomiędzy:
- systemem mikroprocesorowym avr (mikrokontroler + moduły + czujniki, etc.) a
- serwerem www (wykupionym hostingiem, gdzie trzymamy dane, pliki, bazę danych, etc. - w najprostszym ujęciu hosting jest gdzieś w świecie, wśród firm oferujących te usługi)

Technologie, o których wspomniałem (języki programowania jak kto woli) to m.in.:
- język C - do wysterowania uc avr (lub C++ do tych bardziej zaawansowanych), logicznie związany z uc avr
- plik w formacie xml - hmm.. jakby to głupio nie napisać... do bezkonfliktowej wymiany informacji pomiędzy językami z gwarancją potwierdzenia odbioru
- język javascript - działa po stronie przeglądarki na komputerze (urządzeniu) klienta, ale logicznie związany jest ze stroną www
- język php - działa po stronie serwera, do obsługi funkcji, a konkretnie do odczytywania i zapisywania danych do pliku xml.php, logicznie związany ze stroną
- biblioteka jquery - do uproszczonej obsługi funkcji XMLHttpRequest
- technologia AJAX (Asynchronous Javascript And Xml) - do tego, żeby funkcja XMLHttpRequest działała zgodnie z założeniami, a więc: odświeżanie zawartości strony bez przeładowywania strony

Skupię się chwilę na tym całym AJAX'ie, którego na marginesie nigdy nie lubiałem ale tutaj wydaje mi się sensownym rozwiązaniem, dlatego, że:
- jest to asynchroniczna wymiana danych - a więc podobnie jak w jednej z możliwości protokołu rs232
- jest to technologia umożliwiająca natychmiastową reakcję na błąd funkcji, a więc bepieczna, do tego w sensie logicznym dość mocno przypominająca reguły rodem z protokołu RS232 (wysyłanie, potwierdzenie, gotowość do odbioru, etc.)
- umożliwia wysterowanie wieloma systemami mikrokontrolerowymi avr bez wchodzenia w kolizję przy transmisji danych


Jak miałaby wyglądać komunikacja/cały system komunikacji:

1. Jest coś takiego jak terminal, a więc miejsce/punkt odniesienia,z którego wydawane są rozkazy do systemu uc avr. Oczywiście tam też do terminala wędrują wyniki z czujników, etc. z uc avr. Terminal to nic innego jak nasza stronka. Jest to centrum, sterownia wszystkiego co podepniemy pod ten system komunikacji.

2. Z drugiej strony linii komunikacyjnej mamy system mikroprocesorowy avr (obojętnie jaki tam uc avr będzie siedział, byle by był w stanie odebrać dane przez łącze komunikacyjne i coś z nimi zrobić). Innymi słowy, używając terminologii z RS232 jest to urządzenie końcowe. Jest on wyposażony w czujniki, lub przekaźniki sterujące elementami elektronicznymi (urządzeniami) w miejscu gdzie on się znajduje. W domyślnym założeniu do wysłania odebrania danych używa dowolnego modułu ethernetowego, np. ENC28J60. Oczywiście bardzo ważna jest tutaj sprawa z systemami zabezpieczającymi, gdyby coś poszło nie tak, system mikroprocesorowy ma ustabilizować w sposób maksymalnie bezpieczny całą sytuacje. Takie funkcje systemu mikroprocesorowego avr są domyślnie i obowiązkowo przewidziane i co ważne mogą być aktywowane NIEZALEŻNIE od stanu serwera www.

3. Wymiana danych:
Najpierw chciałem w uc avr budować ładnie cały wielki plik XML, ale w/w Kolega uświadomił mnie (po krótkich obliczeniach w pamięci) że to nie ma sensu. No więc, musiałem przyjąć inne rozwiązanie. Skoro nie mogę za bardzo obciążyć procesorka avr to niech ten ciężar będzie przeniesiony na procesor serwera www - on z takim czymś dużo prościej sobie poradzi. O co chodzi? Już piszę. Dobrze by było zmieścić więcej niż mniej: danych odczytu z czujników, lub rozkazów wędrujące do uc avr. Jak to zrobić po stronie avr? Ano, jest coś takiego jak pola bitowe struktury. Zrobić taką jedną (w podstawowym zamyśle) strukturę i zapisać w niej dane. Teraz te dane to będzie ramka danych, to będą podstawowe dane w pliku wysyłanym do serwera. Pomyślałem sobie, dobrze, skoro nie można ładować takiego wielkiego bydlaka jakim jest plik xml, to niech to będzie przynajmniej plik xml z jednym węzłem, gdzie wartością będą właśnie dane z w/w struktury wraz z polami bitowymi. Ten plik xml powędruje sobie do serwera www, a skrypt strony www (obojętnie już w jakim języku) "zdekoduje" tą strukturę do normalnego pliku xml2ajax.php i tenże xml2ajax.php będzie wykonany przez serwer www. Z kolei w drugą stronę, czyli użytkownik wyda polecenie przez stronę www do systemu uc avr, będzie tak, że skrypt serwera www odpowiednio przygotuje plik xml2avr.php (struktura z polami bitowymi) i wyśle go do systemu uc avr.

Sprawę potwierdzeń, flag odbioru pozostawiam otwartą, bo jeszcze do końca tego nie przemyślałem.

Jedna z niewątpliwych zalet tego systemu komunikacji, to to, że nie jest skierowany on do konkretnych urządzeń, które np. MUSZĄ mieć Androida, lub inny system operacyjny urządzenia, tylko wystarczy że mają przeglądarkę, która potrafi wyświetlić przetworzone dane z serwera.

Pytania do Kolegów z Forum Atnel:
1. Jak Waszym zdaniem powinna wyglądać struktura pliku wymiany informacji (nagłówek, dane, koniec, flaga, ?) - tak żeby można było upakować wiele zmiennych, ale żeby była to struktura dość elastyczna w konfiguracji - oczywiście jakiś kompromis jest potrzebny.
2. UDP czy TCP - jeśli chodzi o uc avr? -bierzemy pod uwagę tak i odczyt z czujników, jak i wykonywanie poleceń z potwierdzeniem. Wydaje mi się, że lepsze byłoby TCP, ale jestem ciekaw Waszego zdania.

Może Ktoś z Kolegów podpowie mi co robię/myślę źle, lub co robię i myślę dobrze Może wspólnymi siłami powstanie coś ciekawego? Wychodzę z założenia, że będzie to dobrze służyło ludziom, a nie że stanie się dla nich utrapieniem.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

No ciekawe, ciekawe :>

Późna godzina jest i ciężko mi się wszystko to czyta, tzn. ogarnąć wszystkie założenia itp. dlatego jak coś nie tak zaproponuję to proszę wybaczyć

Według mnie to jeżeli chcesz, aby po stronie AVRka jak najmniej było robione (strona www itp.) to można by rozważyć to:
1. Zrezygnować z plików xml, a zastosować bazy danych np. mySQL na serwerze www.

2. Uzupełnianiem danych w tle na serwerze www z różnych AVRów zajmowały by się skrypty w cronie, które co jakiś czas odpytują różne IP z AVRkami o dane, w postaci np. zapytań metodą GET lub POST i zapisują te dane do bazy danych. Zaletą tej metody jest korzystanie z TCP, czyli mamy załatwioną kontrolę błędów jeżeli chodzi o same pakiety. Reszta też jest programowo łatwo do oskryptowania. Można się pokusić również o UDP, tylko wtedy oprócz kontrolowania wartości samych zmiennych dodatkowo musielibyśmy sprawdzać, czy pakiety dodarły prawidłowo do odbiorcy itp.

3. Sama witryna jak wspomniałeś jest na serwerze www i ma od razu dostęp do wcześniej zgromadzonych danych w bazie. Można oczywiście z poziomu strony, która jest dostępna dzięki takim założeniom w każdym medium i systemie po prostu przez przeglądarkę internetową, wysyłać kolejne zapytania do konkretnych AVRów o dane, jak również wysyłać im tą samą metodą ustawienia, polecenia itp.

4. Sam AJAX jest tylko dodatkiem, który można w tym wypadku wykorzystać na stronce www. Jeżeli jest skomplikowana i nie chcemy odświeżać całości i mieć cały czas otwarte jakieś okienka czy podstronę i mieć spływające nowe dane to wtedy to się sprawdzi. Jednak w przypadku AJAXA jest to o tyle trudne, że jest problem z ostylowaniem pobranych danych jak i podczepieniem do nich kodu javascriptu np. robiącego dodatkowe wodotryski jak animacje. Nie mówię, że jest to nie możliwe po prostu trzeba więcej się namęczyć i pogłówkować . Jednak efekt jest czasami ciekawy, szczególnie jak patrzymy sobie na zmieniające się niezależnie różne pomiary z czujników

_________________
.

Nie jestem w tych tematach biegły, ale tu na forum był taki temat, gdzie to AVR odpytywał serwer zaszywając w pytaniu php informacje które wysyła. Po stronie serwera zapytanie php upycha dane w bazie MySQL, które następnie mogą być już przetwarzane przez inne mechanizmy. Dane są wysyłane nie na żądanie tylko zgodnie z harmonogramem zaszytym w konkretnym urządzeniu końcowym. Osobną sprawą jest potwierdzenie czy serwer odebrał prawidłowo dane. W takim modelu jest to chyba trudne.

_________________
sig off ;(

Witam Kolegów i dziękuję, że pojawiły się konkretne odpowiedzi.
Dzisiaj bardzo krótko odpiszę (tzn. teraz), bo parę innych spraw wypadło mi w międzyczasie. Do projektu zajrzę prawdopodobnie w weekend. Teraz załączę tylko przykład pliku xml - oczywiście jest to tylko początkowe i raczej teoretyczne rozwiązanie, ponieważ jeszcze nie sprawdzone w praktyce.
Osobiście będę projektował to tak, żeby korzystać z pliku xml, pomimo pewnego obciążenia dla uc avr. Przemawiają za tym względy bezpieczeństwa (chciałbym żeby plik xml w przyszłości pełnił rolę takiej czarnej skrzynki).
Ok. Na razie muszę kończyć.

Przykładowy plik xml:


Edit:19:41:
Kilka słów wyjaśnienia na temat samego pliku xml:
Plik jest przeznaczony do DWUSTRONNEJ komunikacji.
Oznaczenia:
sens1, sens2, <itd> - nr czujnika podłączonego do uc avr
avr-id: identyfikator uc avr, to nie jest nazwa (tutaj podałem nazwę, ale tylko dla jasności sprawy), tylko id avr, avr-id ma być domyślnie rozpoznawany w tablicy danych, ale to już w kodzie strony www
order - rozkaz do uc avr
mnemo - mnemonik rozkazu do uc avr
par1, par2, <itd> - parametry rozkazu
ctrl_flag - flaga kontrolna, domyślnie minimum 3 wartości, tzn. 0 - ok, 1 (lub nieparzyste) - błąd po stronie uc avr, 2 (lub parzyste) błąd po stronie serwera www

Kody błędów dekodowane będą z tablicy wpisanej do kodu strony (serwer www) - żeby nie zajmować niepotrzebnego miejsca w pliku xml.

Proszę sprawdzić rozmiar pliku xml, dodać do tego bajty na wysłanie go do serwera (tzn. bajty w linii rozkazu funkcji).
Edit:19:41: Chodzi mi o to, że sam rozkaz wysłania pliku na serwer www, a raczej nie tyle jego wysłanie co zmiana w nim danych także zajmuje pewne miejsce w kodzie uc avr.

Na razie tyle. Więcej naprawdę napiszę w weekend. Przepraszam, ale mam w tej chwili pewne inne (pilniejsze) sprawy.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Jesli moge cos wtracic to ja tego xml'a zrobilbym tak:

*Spacje i konce lini dodane dla czytelnosci, w AVR nie bedziesz musial ich stosowac.

Wszystko gra, ale dziś w nocy o tym trochę myślałem i doszłem do wniosku, że wskazane byłoby tworzyć jeden plik xml do jednego uc avr. Tzn. jeśli w systemie (a więc na serwerze) miały być odbierane sygnały WIĘCEJ NIŻ z jednego uc avr, to w celu minimalizacji kolizji próby otwarcia pliku xml po raz drugi powinna być zależność: jeden plik xml z nazwą pliku wskazywaną na uc avr (+ew.nr systemu uc avr) <-> jeden uc avr. Innymi słowy linijka avr-id mogłaby wtedy być zbędna, ale o ile plik nie byłby specjalnie wielki mogłaby zostać. Wszystko sprowadza się o rozmiar pliku, dlatego też na początku ominąłem ten węzeł zbiorczy (przepraszam, jeśli pomyliłem coś w terminologii teraz, ale trochę się spieszę) jakim jest w Twoim przykładzie -kolego charsz- <senss>.

Dzięki za konstruktywną odpowiedź.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Ja tak tylko nieśmiało wtrącę .... że jak "trochę" podziałacie na takich pikusiach 8-bitowych z małą ilością pamięci RAM to szybko się odechce pomysłów typu analiza i parsowanie plików XML ..... moim zdaniem to co najmniej "trochę" zgroza ... Pomijam już fakt, że w ogóle stawianie serwera HTTP na AVR to pomysł z którego każdy wcześniej czy później zrezygnuje - bo jeśli już miałby być taki wymóg że MUSI być taki serwer to wtedy ARM/STM i można też wtedy katować się XML'ami do bólu .... Jeśli zaś bawimy się pikusiami to korzystajmy z balansowania MOCY że tak powiem, czyli - PIKUŚ może robić MINIMUM a WIĘKSZY czyli program na HOSTINGU może robić CAŁĄ RESZTĘ. Do czego się to sprowadza? ..... PIKUŚ może przesłać dane w jak NAJPROSTSZEJ i najkrótszej postaci np:

3.14,1.63,1020.53,80.82

najkrótszy możliwy string zawierający tokeny ułożone w z góry zaplanowanej kolejności, podobnie mogą wyglądać dane przesyłane pikusiowi czyli JAK NAJPROSTSZE i najkrótsze stringi do parsowania ... dlaczego ? Bo nie chodzi tylko o brak RAM'u na operacje na pamięci ale też o brak RAM'u na samą ramkę ETH w tejże samej pamięci i pewnie jeszcze wiele innych potrzeb ...

to tylko taki przykład - i wcale nie muszę mieć racji - tak tylko głośno myślę sobie - a mogłem też nie zrozumieć założeń bo temat jest przepastnie opisany i nie mam za dużo czasu na analizę szczegółową całości. Więc proszę nie traktować mojej wypowiedzi że to jedynie słuszne zdanie - raczej luźna dygresja.

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

No to przepraszam - zamotałem się w takim razie .... sorki

_________________
zapraszam na blog: http://www.mirekk36.blogspot.com (mój nick Skype: mirekk36 ) [ obejrzyj Kurs EAGLE ] [ mój kanał YT TV www.youtube.com/mirekk36 ]

W szczegolnosci takie pocwiczenie fajnie rozwija pod katem ewentualnych zadan w zakresie komunikacji miedzy roznymi systemami, nie koniecznie embedded.

Projekt nie jest po to, żeby mnie czegoś nauczył - jakkolwiek, uważam, że wiem jeszcze niewiele (nie wiem czy dobrze zrozumiałem aluzję, ale jeśli źle to przepraszam).
Ogólne cele projektu określiłem na samej górze (i chyba mówiłem o nich na chat'cie, no ale to jest nie do odtworzenia)
W każdym razie OGÓLNE cele/zalety tego projektu to m.in.:
- komunikacja po stronie terminala niezależna od systemu operacyjnego - wystarczy przeglądarka internetowa przetwarzająca javascript (po stronie urządzenia, bo po stronie serwera php, i inne sprawy raczej będzie)
- bezpieczeństwo i stabilność w wymianie danych
- możliwość agregacji do wielu systemów/uc avr

Ważna sprawa: nie chciałbym być z automatu podejrzany o coś takiego jak wchodzenie w paradę producentom systemów wbudowanych, bo to nie o to chodzi. Nad podobnymi projektami, choć nie do końca pracują m.in. studenci z MIT i w ogóle wiele ludzi. Osobiście doszukałem się zastosowań JSON (są np. takie mikrobiblioteki do json'a). Ja chciałbym sprawdzić jak z tym wszystkim poradzi sobie AJAX z uwagi na to, że umożliwia on ASYNCHRONICZNĄ i względnie bezpieczną/stabilną wymianę danych - podobnie jak RS232.

Tak na margiesie. Stronkę www, serwer mam przygotowane w ok. 60-70% - w założeniu, że jest to prosta strona do konfiguracji/wysyłania poleceń. Na razie pracuję na lokalnym serwerze, więc gdyby Któryś z Kolegów był ciekawy, to moja stronka na razie nie działa i nie jest to jakieś tam wprowadzanie w błąd. Nieco później będę się męczył natomiast z konfiguracją uc avr. Domyślny uc to atmega32, chociaż zastanowię się czy nie spróbować z nieco "słabszym", a tańszym atmega8. Czeka mnie więc to co opisują na temat stosu TCP/IP na http://www.tuxgraphics.org. Nie chodzi o to, że sobie z tym nie poradzę, bo poradzę sobie. Być może przydałby się jakiś programista/tester do kodowania uc avr.. (???) Któryś z Kolegów chętny? Chodzi o podział zadań przy założeniu, że "gdzie kucharek 6 tam nie ma co jeść" - a więc jeśli ktoś by się pisał do pomocy to tak na 100%. Jeżeli tak by było, to wtedy kod piszemy i udostępniamy razem - zresztą po to opisałem to wszystko jak ma to wyglądać i w opaciu o jakie technologie działać. Stronka dla większego bezpieczeństwa (dla bezpieczeństwa od strony hmm.. np. autoryzacji danych i stabilności) będzie budowana na rdzeniu WordPress. Podkreślam, że pliki kodu strony (pliki bo jest ich parę/kilka - oprócz samego rdzenia) udostępnię. Zastanawiam się, żeby przynajmniej część projektu opisać diagramami z UML'a - ale prawdę powiedziawszy szkoda mi na to czasu bo -osobiście- wolałbym mniejszymi krokami od strony praktycznej dojść do konkretnego, w miarę stabilnego końca projektu (żeby coś się działo), niż budować od razu wielki projekt i zagubić się w założeniach, dokumentacji itp. Diagramy UML są dobre jak wykonuje się projekt bardziej złożony. Tutaj wszystko jest względnie proste, tzn. jeden uc avr + jeden czujnik + jeden przekaźnik (lub nawet dioda) + serwer z silnikiem php + javascript.

Przy okazji pragnę zwrócić uwagę, że jest Czwartek/Piątek, a naprawdę nie miałem kiedy żeby odpisać w szczegółach co i jak. W weekend będę mocno działał. Mam przeczucie, że przydałby mi się GreenBook, ale cierpliwie czekam na GB HD. Przy okazji dziękuję Panie Mirku za zabranie głosu, a Koledze Mokrowskiemu za taktowne pokierowanie dyskusji Naprawdę jest to dla mnie bardzo ważne, że osoba jaką jest Pan Mirek - autor BB i GB - zabrał głos w tej dyskusji.

Proszę dostrzeć pozytywne strony projektu. Pisząc o nim, biorąc się za ten projekt - chcę wyłącznie dobrze.

Na kolejne pytania/sugestie będę mógł odpowiedzieć jutro w ciągu dnia (krótkie posty), lub wieczorem - pewnie trochę więcej. Proszę o wyrozumiałość, bo akurat wypaliłem z tym projektem jak zbliża się Święto Wszystkich Wiernych Zmarłych i są wobec tego dodatkowe sprawy/obowiązki. Jednak w Sobotę tak czy siak planuję nad projektem posiedzieć.

Edit 5.11.2014::18:30::Środa:
Kończę opracowywać kod do WordPress'a. Wykonuję to na dwóch różnych stronkach (rdzeniach/bazach danych), bo jedna z nich to emulator avr. Nie wszystko idzie tak po mojej myśli jakbym chciał. W każdym razie piszę tutaj, bo wydawało mi się, że te informacje podawałem, ale jednak nie. To są źródła z jakich korzystam:
http://it-ebooks.info/

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Może kolega zdradzić w jaki sposób zrobił proste parsowanie XMLa? na AVRku? bo temat już trochę wysechł .

Tak dla kolegów którzy Ajaxem się próbują w obie strony skomunikować z AVR-em. O ile w jedną stronę AJAXEM wyślemy dane do AVR np wysyłając formularz z danymi bez problemu, to problem robi się w drugą stronę czyli z odpowiedzią AVR-a na takie AJAXOWE zapytanie . Wynika to z zablokowania oficjalnego możliwości komunikacji AJAXEM z inną domeną. Na szczęście jest metoda na "głoda" , która omija powyższe ograniczenie , metoda nazywa się CORS.
A co daje nam dwustronna komunikacja AJAXEM ano daje m.in następujące możliwości :
- potwierdzenie odebrania przez AVR poprawnie danych wysłanych ze strony www (czyli np wysłanie formularza do AVR ze strony www ), w przypadku braku komunikacji np zanik sieci WIFI po stronie AVR-a lub zanik zasilania otrzymujemy zwrotnie stosowny komunikat na stronie www.
- w tym samym połączeniu Ajaxowym przesyłamy dane z AVR do strony www (bez użycia php w tym przypadku) , mając świeżutkie dane na stronie www otrzymane w jednym połączeniu Ajaxowym za pomocą JavaScriptu możemy robić cuda niewidy i wodotryski
- wiele innych jeszcze przeze mnie nie odkrytych.

_________________
http://strefapic.blogspot.com

Bardzo dziękuję za pomocne info Kolego. Szkoda, że nie wiedziałem tego minimalnie wcześniej, bo właśnie byłem zmuszony opracować własny (dodatkowy) protokół komunikacyjny (w sensie zapytań i odpowiedzi, oraz szybkości i poprawności). Wcześniej jeszcze słuszałem, że AJAX gdy wykorzystuje notację JSON może alternatywnie skorzystać z notacji JSONP, która ponoć (choć tego nie sprawdzałem) omija to ograniczenie AJAX'a polegające na korzystaniu z jednego źródła (tj. serwera).

Rez, temat wcale nie wysechł. Dzięki pomocy kilku Kolegów można powiedzieć, że całkiem nieźle ruszył do przodu, chociaż skończony jeszcze nie jest. Przyjdzie czas to być może napiszę więcej. Na razie nie ma się czym chwalić.

Acha... W razie czego ruszy to (prawdopodobnie) na tej stronce -na razie jeszcze nic tam nie ma.

A za metodę CORS dziękuję Kolego Wat1970, sprawdzę ją i spróbuję zastosować gdyby okazała się wydajniejsza.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

No fajnie że jeszcze temat żyje. Warto poświęcić kawałek życia dla technologi webowych w kontekście spięcia webu z AVR-em:) . Taka nauka nowych technologii daje dużo satysfakcji i poszerza światopogląd
W przypadku Kolegi J23 i jego projektu optymalnym wydaje się być zastosowanie AJAXA wykorzystując dwustronną komunikację pomiędzy www a AVR-em , mniej więcej to by chodziło tak :
- ze strony www np za pomocą formularza i transmisji AJAX wysyłamy dane do AVR, w których wydajemy komendy lub zmieniamy konfigurację wyjść etc, nie ma potrzeby męczyć AVR-a dekodowaniem formatu XML-a tylko zwykły format tekstowy z przełamaniem linii po każdej komendzie/danej aby po stronie AVR minimalizować wielkość bufora odbiorczego. Dane przed wysłaniem poddajemy serializacji (najlepiej za pomocą funkcji jQuery - serialize(), można w ten sposób pchnąć cały formularz z milionem opcji i ustawień w bardzo prosty i zrozumiały format dla AVR-a:)
- w tej samej transmisji AJAX , AVR potwierdza nam przyjęcie danych (potwierdzenie otrzymujemy na stronie www np w postaci wyskakującego okienka z informacją lub wpisem na stronie www) i tutaj musimy po stronie AVR zastosować metodę CORS czyli wysłać odpowiednie nagłówki do strony www. W odpowiedzi wysyłamy do strony www dane uformowane w postaci XML-a lub JSONP.
Dane odbiera metoda AJAX-owa responseXML (jeśli XML) i jakiś pierwszy lepszy przykład z neta :
Dane w XML zwracane przez AVR w odpowiedzi na formularz wysłany ze strony www (plus nagłówki niezbędne do poprawnej wymiany danych metodą CORS trzeba tu dodać) :
<?xml version="1.0" ?>
<root>
Jestem testem.
</root>
wycinek skryptu po stronie www
var xmldoc = http_request.responseXML;
var root_node = xmldoc.getElementsByTagName('root').item(0);
alert(root_node.firstChild.data);

mając odebrane dane w metodzie responseXML, poruszamy się po nich jak po drzewie DOM.

Odebrane dane z AVR służą nam np do aktualizacji danych wyświetlanych na stronie www, dane mogą być potem retransmitowane drugim połączeniem AJAX (plus skrypt PHP) do bazy danych na przykład etc. tutaj jeszcze można by się zastanowić nad obiegiem danych.

Jeszcze kwestia aktualizacji danych w bazie czy robić to na żądanie ze strony www czy też cyklicznie samoczynnie z AVR z uwzględnieniem czasu ostatniej aktualizacji (ostatni czas aktualizacji wyświetlany na stronie). Czy może obie metody zastosować.

Jak by nie spojrzał przy takim projekcie jest wiele ciekawych aspektów do rozwiązania, które wymagają poznania nowej wiedzy i to jest w tym wszystkim najpiękniejsze.

Pozdrawiam

_________________
http://strefapic.blogspot.com

Jeszcze w temacie AJAX-a i wymiany danych z AVR-em. Trzeba wspomnieć o najprostszej formie wymiany danych i nie skreślać jej tylko dlatego , że jest najprostsza Format XML fajny tylko daje nadmiarową ilość znaczników (które AVR musi pchnąć po UART-cie), jest czuły na błędy składni i nie wszystkim musi się podobać latanie po drzewie DOM po stronie odbiorczej
Zapodaję więc prosty/prostacki format wymiany danych, który działa bardzo sprawnie po AJAXie

a więc to co wysyła AVR do strony www jako odpowiedź na zapytanie AJAX-owe (plus nagłówki potrzebne CORS):

<html><body>
PK1=1^PK2=0
PK3=1^PK4=0
</body></html>

po stronie www kawałek skryptu, który w prostacki sposób odbiera dane i przyporządkowuję jakieś działanie :

http.onreadystatechange = function() {
if(http.status == 200)
{
var dane = http.responseText ; // dane odbieramy metodą responseText i tam szukamy stringów jakie nas interesują
if(dane.indexOf("PK1=1") !== -1) // -1 jest wartością zwracaną jeśli nie znajdzie stringa
alert("PK1 ustawiony na ON") ;
}
else

alert("Problem z przesłaniem danych spróbuj później .....");

W tym rozwiązaniu trzeba trochę nawachlować if-ów po stronie kodu JS na www, ale jest to najprostsze myślę rozwiązanie dla zaczynających w te klocki rzeźbić.

Pozdrawiam

_________________
http://strefapic.blogspot.com

o JSONP lepiej nic nie piszmy bo to już bliska technologia dla hackerów , za pomocą której wyciąga się np. dane o użytkownikach sieci TOR

_________________
http://strefapic.blogspot.com

Witam Kolego Wat1970,
Widzę, że Kolega stara się DUŻO pomóc i za to OGROMNIE dziękuję. Wszelkie uwagi są jak najbardziej mile widziane. Z racji, że Kolega tyle piszę postaram się uchylić rąbka informacji.
Wiem, już -dzięki Tobie Kolego Wat1970- że CORS jest świetną technologią pracującą w ramach technologii AJAX. CORS może pracować w wielu metodach pobierania/wysyłania danych do serwera (GET, POST, REQUEST, etc.), a nie jak JSONP tylko poprzez GET. Należy jednak zdać sobie sprawę, że trzeba nałożyć trochę więcej kodu, tzn. najlepiej do pamięci EEPROM załadować różne stałe potrzebne do metody CORS + do zwykłego FLASH'a funkcje odpowiedzialne za funkcjonowanie CORS. Nie ma tego wiele jeśli chodzi tylko o metodę GET, ale gdy brać pod uwagę metodę POST to już sprawa odrobinę się komplikuje. Na obecnym etapie projekt wykorzystuje AJAX, metodę GET, format JSONP (nie JSON) i autorski protokół komunikacji wraz z potwierdzeniami. Plus jest taki, że nie trzeba tyle kodu ładować do biednego MCU (obciążenie przejmuje serwer/hosting). Minus tego rozwiązania, że może to iść tylko metodą GET. Docelowo będzie to pisane na CORS, jeśli CORS w testach okaże się skuteczny.

Dane wysyłane z i do MCU są rzeczywiście bardzo upakowane - to także jest już zrobione.
Co do serwera zewnętrznego (hostingu) i frameworku, na którym będzie to działało, to póki co projekt powstaje w oparciu o CMS WordPress jako wtyczka, a więc są do dyspozycji wszystkie możliwości WordPressa, w tym szybkie enkryptowanie/dekryptowanie danych z JSONP, oczyszczanie danych (sanitize) i inne bajery.
Projekt nie jest jeszcze skończony i jak już wyżej napisałem, kiedy "przyjdzie czas to być może napiszę więcej". Na razie jeszcze wiele rzeczy jest w fazie płynnej. Projekt trochę się ciągnie, ale to z uwagi na to, że nie tylko przy nim mogę siedzieć.

Edit:
Heh.. Co do JSONP i tam technologii dla hackerów... Uważam, że CORS ma jeszcze szersze możliwości w tym zakresie...
A co do wiedzy (ogólnie) i możliwości jej wykorzystania to zawsze trzeba się liczyć z tym, że znajdą się ludzie na tyle podli i głupi (mam na myśli decydentów, nie programistów), żeby wykorzystać ją w złym celu. W zasadzie już w oparciu o zwykły kondensator, cewkę i tranzystor można niebezpieczne zabawki budować. Skargi proszę kierować do tych co wynaleźli tranzystor, albo do tych co wynaleźli lampę elektronową... W każdym razie projekt nad którym pracuję ma docelowo ludziom POMÓC, żeby było dobrze, żeby np. Polacy mogli samemu zmajstrować inteligentne domy, być może jakieś eko-projekty... Możliwości jest wiele i każdy o tym wie. Natomiast sposób wykorzystania wiedzy, którą się posiada każdy osobiście musi wybrać sam w oparciu m.in. o własne sumienie i podstawowe normy etyczne.

Dziękuję Kolego Wat1970 za zainteresowanie tematem i udzielenie pomocy w przypadku, np. informacji o CORS.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Hey J23 ,

Moze nie do konca bedzie to pomocne dla Ciebie ale ja w uC AVR uzywam post w bardzo laicki sposob ale jednak dziala dokladnie tak jak ma Moze Ci sie przyda w projekcie



Oczywiscie celowo uzylem JSON jako content jako ze moj webservice tego oczekiwal ale mozesz to w miare potrzeb dostosowac jak potrzebujesz

Raf

_________________
sig off ;(

Cześć Rafał,

Na pewno przyda się do prac z CORS (późniejszy etap). Na razie wszystko leci przez GET -a ściśle będzie leciało, bo obecnie piszę kod wtyczki/widgetu do WordPressa, a to w przypadku AJAX'a i tego całego zamieszania z dodatkowym protokołem nie lada wyzwanie.


Dzięki WIELKIE raz jeszcze. W projekcie działa JSONP (JSON padding) wraz z metodą GET. Sam łańcuch wymiany danych jest drobniutki, żeby łatwo przeszedł przez wąskie gardło ENC28J60. Żadnych zbędnych nawiasów. Reszta to odpowiednie kodowanie/dekodowanie i parsowanie danych wraz z potwierdzeniami wysyłania i odbioru - czyli ten dodatkowy protokół (zamiast CORS'a). Tyle mogę na razie powiedzieć na ten temat.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

RafPe dałeś wzorcowy przykład zapytanie POST z danymi w formacie JSON brawo. Niestety w AJAX-xie to już nie zatrybi od strony AVR-a. Dlatego do AJAX-a m.in wydumano taki trik nazwany JSONP, na którym J23 się oparł. O ile do AVR-a , AJAXEM pchniemy dane metodą POST bez problemu to już z powrotem w odpowiedzi tylko GET zostaje w przypadku JSONP.

_________________
http://strefapic.blogspot.com

Jeszcze do projektu J23 może się przyda pewna myśl , dotycząca aktualizacji danych na stronie. Fajnie by było , żeby aktualne były dane już po załadowaniu kodu html na stronę bez jakiś dodatkowych czynności ze strony użytkownika po wejściu na portal. Tak myślę , że można by tu spróbować przed załadowaniem strony uruchomić skrypt JS i odpytać AVR-a o aktualne dane połączeniem AJAX-wym, które zaktualizuje nam wpisy w bazie danych. Czyli krótko mówiąc wywołanie strony www automatycznie wywołuje proces aktualizowania danych w bazie. Do rozważenia pomysł.

_________________
http://strefapic.blogspot.com

To jest już zrobione, tzn. jako osobny moduł. W tym celu ustawia się zmienną w javascript odświeżania strony przez AJAX (set interval).

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

Tutaj jest projekt na Linuxa . Fajnie , że przez Polaka zrobiony. Kawał porządnej roboty gość zrobił. Można sobie zaczerpnąć pomysły ewentualnie do swojego projektu

http://techfreak.pl/nettemp/

_________________
http://strefapic.blogspot.com

Jeszcze jedna sugestia może komuś się przyda. Mianowicie, HTML5 umożliwia przechowywanie danych lokalnie, zatem w wielu przypadkach możemy zrezygnować z zewnętrznej bazy danych. Takie rozwiązanie może być ciekawe , np jeśli chcemy malować wykresy na stronie na podstawie danych uzyskanych z AVR-a. Pomijając pośrednictwo bazy danych pomijamy jeden element w łańcuszku wymiany danych a wiadomo im mniej części do zepsucia tym maszyna mniej narażona na awarię Po za tym rezygnując z przechowywania danych na serwerze nie musimy w ogóle używać skryptów PHP . Pozostaje tylko czysta wymiana danych AVR <----> strona kliencka www bez żadnych dodatkowych pośredników co wydaje mi się piękne i proste

Pozdrawiam

_________________
http://strefapic.blogspot.com