[bielu000]

Macie jakieś dobre materiały na temat tego jak handlować komunikację poprzez układ UART? Nie mam na myśli konfiguracji samego układu bo to sobie znajdę w manualu. Mam na myśli coś innego - jakieś dobre praktyki, może jak zaprojektować warstwy od tych wysokopoziomowych do niskopoziomowych (ale bez szaleństw, celuje w MCU). Tak swoją drogą materiały nie muszą być oczywiście stricte związane z programowaniem MCU, ale może coś związanego z embedded Linux ,w końcu dobre praktyki są w teorii dość uniwersalne.

Ostatnie nad czym się zastanawiam - może mnie ktoś wyprowadzi z błędu lub wskaże dobrą drogę. Mam sobie dwa mikrokontolery jakiś od STM np. STM32F1 i ESP8266. ESP8266 chce wykorzystać jako medium transmisji poprzez Wifi.
Na STM-ie chciałbym mieć serwer http, do którego np. mógłby się podłączyć jakiś klient. Czy jest możliwe, aby mając taki serwer i nasł#!$%@?ąc na jakimś porcie, wykorzystać ESP8266 tak abym za pomocą klienta http mógł wykonać jakiś request ale z poziomu STM-a?

Dla zobrazowania
:
STM32
- serwer http, nasł#!$%@? np. na porcie 80 oczekując na requesty,
- inna część kodu poprzez to samo medium wykonuje request pod jakiś adres, np. celem pobrania konfiguracji.

#programowanie #programista15k #embedded #elektronika

[elfo]

@bielu000: Sprawdzałeś, czy nie prościej będzie postawić serwer na samym ESP8266? Nie wykluczone, że nawet i całość zadań, które chcesz wykonać będzie łatwiej zrobić na samym ESP, to dość funkcjonalny układ.

[bielu000]

@elfo: Nie sprawdzałem, natomiast nie chce nic tykać przy ESP8266. Oczywiście zdaję sobie sprawę, że są lepsze rozwiązania (zapewne to o którym wspomniałeś), natomaist możemy założyć że ze względów edukacyjnych chce się skupić na implementacji rozwiązania na STM. ESP8266 nie ruszam.

[elfo]

@bielu000: A planujesz używać jakiegoś RTOSa?

[zarowka12]

@bielu000: pytanie odnośnie UART jest dosyć szerokie, więc nie wiem od czego zacząć. Do głowy przychodzi mi:
- odbiornik nie może gubić bajtów. Zwykle więc dane odbiera się tle, np. w przerwaniu albo za pomocą DMA i przechowuje się je w buforze
- główny kod zagląda do bufora i sprawdza czy jest pełna ramka, wtedy ją dekoduje i usuwa z bufora
- warto pomyśleć o CRC
- stosujemy timeouty, dzięki temu

[bielu000]

@elfo: Bez RTOS-a. Tzn. może sprecyzuję - nie chce gotowego rozwiązania na tacy. Przypuszczam, że RTOS i scheduling rozwiązałoby wiele problemów. Bardziej chodzi mi o ideę i dlaczego będę miał problem nie korzystając z RTOS-a, oraz na jakie inne problemy mogę natrafić próbując coś takiego zaimplementować.

[zetisdead]

Macie jakieś dobre materiały na temat tego jak handlować komunikację poprzez układ UART?

@bielu000: dane przychodzące odbierasz w przerwaniu i wkładasz do fifo, to samo w drugą stronę, w przerwaniu od pustego bufora nadawczego wyciągasz dane z fifo i wkładasz do rejestru nadawczego. Możesz do tego dołożyć lukier w postaci usypiania wątku piszącego/czytającego fifo jeśli musi czekać wolne miejsce lub przyjście danych.

[bielu000]

@zarowka12: O dzięki, z tymi timeoutami to w sumie bardzo sensowne.

[bielu000]

@zetisdead
@zarowka12

Zastanawiam się nad czymś takim:
Pomijając już protokół http. Myślałem, żeby ustawić stałą długośc ramki, np. 48 bajtów.
Wykorzystałbym DMA do kopiowania danych UART -> memory. Za każdym razem kiedy otrzymam 48 bajtów, parsuję sobie ramkę, jeżeli wszystko jest ok, handluję wiadomość itp, później odsyłam. Czy muszę mieć dwie kolejki fifo? Jedna do odbierania, druga do nadawania?

A co sądzicie o tym rozwiązaniu, że za pomocą tego samego medium (mam

[elfo]

@bielu000: Chcesz gadać z ESP przy pomocy komend AT?

[zarowka12]

@bielu000: w przypadku DMA wskazujesz dwa bufory, jeden z danymi do wysłania a drugi z odebranymi danymi. Używanie jednego byłoby bez sensu. Jako, że są to po prostu fragmenty pamięci, nie nazywamy tego kolejkami.

Nie wiem czy dobrze rozumiem drugą część, ale możesz nasłuchiwać na kilku portach.

[bielu000]

@elfo: Zgadza się.

@zarowka12: Faktycznie - widzę, że jest konfiguracja na wiele połaczeń, to jest dobry trop.

[elfo]

@bielu000: Jeżeli będziesz gadał komendami AT, to stała długość ramki nie przejdzie. Nasł#!$%@? znak po znaku i jak trafisz na '\n' albo "\r\n", to przekazujesz całą linijkę dalej.

Dalej np składasz kilka linijek w całość i wyszukujesz OK\r\n lub ERROR\r\n i po tym obsługujesz całą komendę.

Nie wiem na ile ESP wysyła wiadomości URC, ale jeśli tak, to miej na uwadze, by rozróżnić nasłuchiwanie ich i odpowiedzi na komendę (wysyłając komendę

[elfo]

@pepepanpatryk: Możesz w swoim protokole na samym początku zdefiniować pole (np na dwóch bajtach) określające długość ramki, wiesz ile nasłuchiwać i masz elastyczność.

Inna sprawa - czy na pewno potrzebujesz to robić po HTTP? Mam wrażenie, że chcesz go wykorzystać tylko jako warstwę transportową. Wystarczyłoby otwarcie zwykłego socketa TCP i na nim działać swoim protokołem jeśli nie chcesz korzystać z dobrodziejstw HTTP.

[a.....k]

@bielu000: ostatnio piszę kod na STM32F1, który obsługuje asynchroniczną komunikację z SIM800 by wysłać i odebrać pare pakietów TCP. Warto zastosować DMA i próbować parsować komendy AT po otrzymaniu przerwania oznaczającego ramkę stopu w transmisji. A bufor no to oczywiście cykliczny, trzymasz jako zmienną indeks początku ramki, a jako indeks końca ustawiasz to, co ci zwraca jakiś tam rejestr, już nie pamiętam dokładnie. Po prawidłowym sparsowaniu ramki przesuwasz zmienną do przodu,

[bielu000]

@elfo: @elfo: W sumie racja, całkiem sensowne. W ogóle mam wrażenie, że ciężko znaleźć jakieś fajne przykłady jak to wszystko wykrzystać w praktyce, więc zapewne będę trochę improwizowal :)

@anuar2k: Dzięki jak coś to odezwę się :) Robiłem już coś kiedyś podobnego ale po USB i wszystko działało, tyle, że tamto było dużo prostsze. Tutaj mimo wszystko chciałbym odspearować trochę warstw. Tzn. mam na myśli coś w stylu

Serwer

[bielu000]

W ogóle - tak przy okazji - współpracuje teraz w pracy z gośćmi, którzy u nas w fimie zajmują się właśnie rzeczmi bardzo blisko systemu operacyjnego i właśnie jest problem z handlowaniem danych przez UART. Ja supportuje ich z warstwy wyżej, gdzie kodzimy już faktyczną logikę biznesową i korzystamy z interfejsów jakie nam udostępniają. Cholera zazdroszczę im, bo tam zajebiste rzeczy muszą robić :D Szkoda, że to zagraczny zespól, bo ciężko bedzie

[QBA__]

@bielu000:

@zarowka12 dobrze Ci opisał: ramka ze startem, długością pola danych, crc i końcem + timeouty.

Nie polecam sztywnej długości ramki, szybko okaże się że albo przesyłasz dużo pustych danych, albo ramka jest za mała

[sz__po]

@bielu000: imo firmata jest tym, czego szukasz