Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Moduł WiFi - Http server, TCP client

ginar 10 Wrz 2013 00:37 13995 13
  • Witam

    Jakiś czas temu wykonałem projekt który końcowo nazwałem Brevis.
    W moich pierwszych założeniach miał on być niezależnym modułem, przez który inne konstrukcje miałyby dostęp do Internetu
    w sposób bezprzewodowy.

    A więc moduł miał mieć:
    a. własny interfejs komunikacyjny
    b. bezprzewodowe połączenie z Internetem
    c. możliwość fizycznej interakcji z przyłączonymi do niego modułami
    d. oprogramowanie umożliwiające szybkie przystosowanie do nowych zadań


    Moduł WiFi - Http server, TCP client

    Stąd:

    ad a. komunikacja: USB (ft232)/UART -wybór poprzez dip-switch
    ad b. komunikacja: WI-FI, moduł firmy Microchip MRF24WB0MA http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en548014..
    Wybór ten implikował również wybór procesora tej samej firmy (w wersji 1 - 24FJ128GB110, w wersji 2 - 24FJ256GB110) http://ww1.microchip.com/downloads/en/devicedoc/39897b.pdf
    a to ze względu na legalność wykorzystania ich stosu TCP-IP
    ad c. tutaj nic specjalnego - wejścia/wyjścia I/O (open-collector)
    ad d. FreeRTOS - szybka możliwość modyfikacji programu bez ingerencji w całość


    ================================================

    .:Jak to działa - film:. (film ze względu na rozmiar > 100MB został umieszczony serwerze youtube)

    Link

    ================================================

    .:Wykonanie:.
    Schemat elektryczny (a w zasadzie jego część - połączenie mikrokontrolera<-->MRF24WB0MA) bazuje na zestawie uruchomieniowym "Explorer" microchipa.
    Płytka nie jest specjalnie skomplikowana, ale chociażby ze względu na raster użytego procesora została wykonana przez zewnętrzną firmę.

    Moduł WiFi - Http server, TCP client Moduł WiFi - Http server, TCP client Moduł WiFi - Http server, TCP client Moduł WiFi - Http server, TCP client Moduł WiFi - Http server, TCP client





    Oczywiście najbardziej pracochłonną częścią projektu było oprogramowanie.
    Ponieważ komunikacja z modułem (widziana od strony mikrokontrolera) odbywa się w obu przypadkach poprzez UART postanowiłem napisać pod FreeRTOS'em wiarę solidny sterownik UART.

    Moduł WiFi - Http server, TCP client

    Komunikacja z modułem jest na zasadzie komenda-odpowiedź. Moduł rozróżnia dwa tryby komunikacji przez UART:
    1. dane traktuje jak komendy (format zgodnie z powyższym rys. @nazwa_tasku_adresat_komendy #nazwa_komendy1 dane1 #nazwa_komendy2 dane2)
    2. dane traktuje jak bajty które powinien wysłać do serwera z którym aktualnie jest połączony na odpowiednim porcie. W tym przypadku moduł jest 'przeźroczysty'.
    (będzie to widać na filmiku). Wyjście z takiego trybu jest wykonane poprzez dodatkową linie I/O, na podstawie której brevis może zdecydować czy traktować dane jak
    komendę czy nie.

    Kolejno należało zaprząc stos TCP-IP microchipa do współpracy z FreeRTOS'em w taki sposób aby się nie pogryzły.
    Spodziewałem się komplikacji - aczkolwiek z tego co pamiętam takowych specjalnie nie było - http://ww1.microchip.com/downloads/en/AppNotes/01264a.pdf

    Co się udało osiągnąć:

    1. moduł może pełnić klienta TCP gdy otrzyma komendy:
    +zeskanuj sieci Wi-Fi
    +połącz się z wybraną siecią
    +podaj IP serwera
    +podaj port
    Wszystkie przychodzące dane są traktowane jak zwykłe bajty (nie jak komendy).
    W tym momencie urządzenie podłączone do brevisa powinno mieć możliwość wymiany danych z serwerem.

    2. na module wgrany jest serwer http. Celem tego serwera jest umożliwienie kontroli nad liniami I/O i przesyłania krótkich informacji (np. parametrów) do urządzenia podłączonego do
    brevisa - podobnie jak w AccessPointach.
    Strona jest odświeżana co 100 ms. Jednak tylko ta część, która jest interaktywna tj. panel po lewej stronie tak aby nie przesyłać niepotrzebnie danych (za to jest odpowiedzialny kawałek kodu w AJAX).

    Prócz tego powstała aplikacja napisana w Qt (kompilowana na Linux, nie testowana pod Windows) z której w prosty sposób można uruchamiać/testować moduł (na filmiku komendy wysyłane widać w oknie 'Output').
    Nic nie stoi na przeszkodzie aby moduł sterować komendami z jakiegokolwiek terminala.


    .:Problemy:.
    -Jednym z największych problemów który zajął mi dużo czasu było 'przekręcanie' wysyłanych danych przy transmisji dużej ilości danych do serwera.
    Początkowo zasilanie modułu pochodziło z USB laptopa i to ono było sprawcą problemu - w momencie skumulowania większej ilości danych w buforach nadawczych, moduł
    pobierał w tym momencie impulsowo większą ilość prądu co skutkowało krótkotrwałym spadkiem napięcia zasilania o jakies 7%.
    -Moduł WIFI microchipa: MRF24WB0MA, posiada bug. Nie wyłapuje SSID niektórych sieci podczas skanowania. Zwraca wtedy jakiś bliżej nieokreślony string (przypadek taki jest widoczny na filmiku).

    Projekt w swym zamierzeniu nie był czysto komercyjny ale ze względu na ilość poświęconego czasu chciałbym aby choć w część i koszty się zwróciły.
    Dlatego też nie udostępniam całości projektu (jeśli jakieś szczegóły to pv).
    ---------------------------
    złączniki:
    [schemat.pdf]
    [aplikacja Qt]


    Fajne!
  • #2 10 Wrz 2013 22:38
    2291468
    Użytkownik usunął konto  
  • #3 11 Wrz 2013 09:01
    ginar
    Poziom 21  

    Cytat:
    1) Można wiedzieć w jaki sposób wykonałeś PCB, albo przynajmniej ile to kosztuje ?

    Płytka wykonana była w prototypy.com. Koszt płytki ok. 60zł.
    (Pozostałe grube 'komponenty': MRF24WBMR0 - ok. 90zł; procesor - 35zł)

    Cytat:
    2) Z jakich źródeł korzystałeś


    Jeśli chodzi o stos TCPIP-
    to w zasadzie tylko z przykładów i dokumentacji microchipa (po zainstalowaniu biblioteki mamy kilka przykładów). Bardzo pomocne także było forum micriochipa.

    Jeśli chodzi o FreeRtosa-
    książka -Richard'a Barry'iego

    Cytat:
    (przykłady podobnych konstrukcji)

    Po wykonaniu pierwszego prototypu natknąłem sie w sieci na podobną konstrukcję:
    http://www.openpicus.com/

    Cytat:
    3) Oprogramowanie. ? (update, praca zespołowa, czy może indywidualne dzieło ?)

    indywidualne

    Cytat:
    Większy kondensator i po sprawie .... (w szczególnych przypadkach zawsze można użyć niskoimpedancyjnego elektrolitu równolegle z tantalowym )

    To był pierwszy pomysł jaki mi przyszedł do głowy - jednak (kilkakrotnie zwiększony kondensator filtrujacy) nie rozwiązywał sprawy i po jakimś czasie ciągłego nadawania dancyh wkońcu nastąpiło przekłamanie. Zapewne dlatego, że moduł periodycznie zaczął impulsowo rozładowować kondensator, także w końcu ten stracił poziom napięcia.
    Teraz zasilanie pochodzi z ładowarki od telefonu i wygląda ok.

  • #4 11 Wrz 2013 12:45
    michalko12
    Specjalista - Mikrokontrolery

    Na podstawie jakiej dokumentacji zrobiłeś komunikację z modułem WiFi? Na stronach MC niewiele tego jest.

  • #5 11 Wrz 2013 15:37
    ginar
    Poziom 21  

    Cytat:
    Na stronach MC niewiele tego jest.

    Nie spotkałem się z opisem jak komunikować sie z modułem MRF24.
    W jego manualu są inforamcje ale nie przydatne dla programisty.

    Trzeba zainstalować biblioteke Microchip Libraries for Applications v201x-xx-xx Windows (lub pod linuxa). Zainstaluje się również dokumentacja tej biblioteki (tutaj opis TCP IP nas interesuje). Biblioteka ta dostarcza API do komunikacji z modułem. Konfiguracje najniższej warstwy tj. komunikacja SPI można (a nawet trzeba) wziąć z przykładu który jest dostarczony z biblioteką.

  • #6 11 Wrz 2013 17:10
    2291468
    Użytkownik usunął konto  
  • #7 11 Wrz 2013 19:14
    michalko12
    Specjalista - Mikrokontrolery

    juzek555 napisał:
    W sumie taka ładowarka do tel. nie daje więcej niż można pociągnąć z portu USB.
    Eee tam bez przesady, daje, daje. Weź sobie ładowarkę od tableta to i pięć razy tyle będzie miała, a to nadal ładowarka USB. To telefon decyduje o tym ile pobrać. Port USB (2.0) ma według specyfikacji max 500mA a dajmy na to mała ładowarka od Samsunga ma 700mA, a większa już 1200mA. Inna możliwość jest taka, że FTDI nie było skonfiguroawane na 500mA lub przewód USB był złej jakości co się często zdarza i przy 500mA są duże spadki napięć.
    ginar napisał:
    Biblioteka ta dostarcza API do komunikacji z modułem.
    A mógłbyś tak w skrócie opisać w jaki sposób przebiega komunikacja między modułem a uC? Komendy AT czy coś innego?

  • #8 11 Wrz 2013 20:59
    2291468
    Użytkownik usunął konto  
  • #9 11 Wrz 2013 22:21
    Szymon Tarnowski
    Poziom 27  

    A jak generowałeś te 3.3V z 5V (USB)? Stabilizatorem liniowym czy impulsowym?

  • #10 11 Wrz 2013 23:46
    michalko12
    Specjalista - Mikrokontrolery

    juzek555 napisał:

    Kolego nie sugeruj się wartością 700mA, ponieważ każda ładowarka przy przekroczeniu pewnego progu staje się stabilizatorem prądu a nie napięcia...

    ?????
    A to a pro po czego? A jak telefon pokazuje 900mA prąd ładowania to też mam się tym nie sugerować? Chińskie mA nie podchodzą już pod europejskie?


    juzek555 napisał:

    Nawet jeśli masz te spadki na "kawałku kabla" to myślę iż kondensatorki powinny nadrobić.

    Tak, oczywiście. Już wiem jak z baterii 1,5V wyciągnąć 2V.

    juzek555 napisał:

    Po prostu było dać odpowiednią diodę na zasilaniu. (jak by ci spadło max 0.2 V to żadna tragedia.)


    To chyba nie do mnie

  • #11 12 Wrz 2013 09:53
    ginar
    Poziom 21  

    Cytat:
    A jak generowałeś te 3.3V z 5V (USB)? Stabilizatorem liniowym czy impulsowym?


    Impulsowo, przetwornica (dość stara) mc34063.

    Cytat:
    A mógłbyś tak w skrócie opisać w jaki sposób przebiega komunikacja między modułem a uC? Komendy AT czy coś innego?


    Jedynie co dokumentacja mówi to:

    Cytat:
    The MRF24WB0MA/MRF24WB0MB modules are designed to be used with Microchip’s TCP/IP software stack. The software stack has an integrated driver that implements the API that is used in the modules for command and control, and for management and data packet traffic.


    Cytat:
    Data communications with the MRF24WB0MA/
    MRF24WB0MB are through the SPI interface that is
    detailed in Section 2.0, Circuit Description (tj schemat elektr.).The
    Microchip PIC microcontroller communicates with the
    module through a command API from within the
    Microchip TCP/IP stack. The command API is
    detailed in the Microchip TCP/IP stack online help
    that is included in the free Microchip Application
    Libraries download.


    Nie wchodziłem i nie analizowałem kodu API- po prostu go użyłem.

  • #12 17 Wrz 2013 22:57
    ezbig
    Poziom 19  

    michalko12 napisał:
    juzek555 napisał:

    Kolego nie sugeruj się wartością 700mA, ponieważ każda ładowarka przy przekroczeniu pewnego progu staje się stabilizatorem prądu a nie napięcia...

    ?????
    A to a pro po czego? A jak telefon pokazuje 900mA prąd ładowania to też mam się tym nie sugerować? Chińskie mA nie podchodzą już pod europejskie?


    Proponuję sprawdzić we właściwościach koncentratora usb (można zobaczyć ile co pobiera), bo wprowadzasz ludzi w błąd. Kiedyś jak podłączyłem więcej niż 500mA to otrzymałem stosowny komunikat o ograniczeniu prądu dla tego portu do 500mA. Mój telefon np. z ładowarki ciągnie 700mA, a z usb tylko 500mA.

  • #13 18 Wrz 2013 15:05
    michalko12
    Specjalista - Mikrokontrolery

    ezbig napisał:
    bo wprowadzasz ludzi w błąd

    A niby czym wprowadzam w błąd? Czy gdzieś napisałem, że z portu USB można pociągnąć więcej niż 0,5A? Mowa była o ładowarkach, a nie o porcie USB.
    juzek555 napisał:


    W sumie taka ładowarka do tel. nie daje więcej niż można pociągnąć z portu USB.

  • #14 18 Wrz 2013 15:32
    ezbig
    Poziom 19  

    michalko12 napisał:
    A niby czym wprowadzam w błąd? Czy gdzieś napisałem, że z portu USB można pociągnąć więcej niż 0,5A? Mowa była o ładowarkach, a nie o porcie USB.


    Ok, bo już się tam płynna granica zrobiła między zasilaniem z portu USB (układu z tematu) i ładowarką podpiętą do portu. Fakt ładowarka niezależna może mieć inną (większą) wydajność.