Posiadam ESP8266 (ESP12), który ma domyślny baudrate 115200. Niby nie jest to jakoś bardzo mało, ale potrzebuję przesyłać stosunkowo duże ilości danych, więc czym szybciej, tym lepiej. Znalazłem w sieci informację, że można osiągnąć nawet 4Mb/s i więcej. Próbowałem to zrobić komendą AT+IPR, ale uwaliłem moduł. Musiałem wgrać mu nowy firmware, żeby go ożywić. Komenda AT+ UART_DEF wydaje się działać, ale tylko kiedy ustawiam baudrate poniżej domyślnej wartości. Każda większa wartość (np. 256000) powoduje, że układ wysyła krzaki do terminala. Co ciekawe, wydaje się jeszcze wtedy rozumieć co mu wysyłam i udało mi się tak zmniejszyć baudrate do poprzedniej wartości.
Nie wiem czy powyższe objawy to wina modułu ESP czy może konwerter USB-UART (PL2303HX, podróbka) nie daje sobie rady. Czy komuś z Was udało się osiągnąć jakieś większe prędkości niż domyślne 115200?
When real RS232 signaling is not required, baud rate higher than 115200 bps could be used for even higher performance. The flexible baud rate generator of PL-2303HXD could be programmed to generate any rate between 75 bps to 12M bps
Połączyłem Rx i Tx konwertera i spróbowałem znaleźć granicę do jakiej działa. W terminalu ustawiłem nawet bitrate 1000000000 (9 zer) i ciągle działa. Podejrzane to trochę, bo wątpię, żeby przez USB 2.0 przeszedł taki transfer. Wynika z tego, że albo terminal albo sterownik oszukuje. Zapewne poza dopuszczalnym zakresem ustawia domyślny baudrate. Tak przynajmniej dzieje się kiedy ustawię np. 10bps. Bez oscyloskopu pewnie się nie dowiem jaka jest górna granica...
CH340 supports common baud rate: 50,75,100,110,134.5,150,300,600,900,1200,1800,2400,3600,4800,9600,14400,19200,28800,
33600,38400, 56000,57600,76800,115200,128000,153600,230400,460800,921600,1500000,2000000 and so
on. The baud rate error of serial transfer signal is less than 0.3%, and permission baud rate error of serial
receive signal is not less than 0.2%.
Data transfers to/from UART interfaces can be implemented via hardware. The data transmission speed via UART interfaces reaches 115200 x 40 (4.5 Mbps).
Czyli mniejwięcej znaczy tyle, że może uda się nawiązać łączność z szybkością 1500000 lub 3000000 bps już tylko przy użyciu FT232RL.
Tyle z teorii, a jak w praktyce?
Dodano po 13 [minuty]:
W praktyce 921600 spokojnie jestem wstanie uzyskać na CH340G, niestety przy 1.5Mbps niestety się nie udało nawiązać komunikacji.
Użyłem tutaj polecenia AT+UART_CUR na wypadek, jakby się coś nie powiodło i utraciłbym połączenie z ESP, wówczas restart zasilania i wracamy do 115200.
W praktyce 921600 spokojnie jestem wstanie uzyskać na CH340G, niestety przy 1.5Mbps
A pomyślałeś że to nie problem przejściówki tylko windy, albo programu terminal? Za szybko wyciągasz wnioski. podłacz esp do do jakiegoś ARM-a z szybkim uartem i tam testuj > 1M, inaczej cała Twoja metodologia i analiza nie jest wiele warta.
Zamówiłem dzisiaj na allegro przejściówkę na układzie CH340G, będę miał porównanie. Popróbuję jeszcze z innymi programami. Docelowo ESP ma współpracować z mikrokontrolerem STM32F411, ale chciałem wcześniej przeprowadzić kilka testów z użyciem komputera - bo łatwiej. Na docelowym układzie też to niebawem sprawdzę.
funak napisał:
AT+UART_CUR
Przeoczyłem istnienie tego polecenia, a jest bardzo użyteczne.
Przy tych większych prędkościach trudniej bo nie wiesz co nie działa. Jeżeli masz STM na płytce typu nucleo albo Discovery to nie potrzebujesz przejscioeki, jeżeli nie to podłącz przejściówkę do dowolnego uarta a ESP do innego i wysyłaj komunikaty diagnostyczne przez przejściówkę do Komputera. Mając płytkę z debugerem nawet tego nie musisz robić.
A pomyślałeś że to nie problem przejściówki tylko windy, albo programu terminal? Za szybko wyciągasz wnioski. podłacz esp do do jakiegoś ARM-a z szybkim uartem i tam testuj > 1M, inaczej cała Twoja metodologia i analiza nie jest wiele warta.
Tu się nie zgodzę, FT232RL jak i FT245RL działają powyżej 1Mbps. Sprawdzone I to w postaci VCP - Virtual Com Port.
Inne sterowniki - brałeś po uwagę? Tak że taka metodologia testowania nie jest wiele warta, bo wszystko prawie zależy od windy. Tak że komunikację można testować tylko uart <=> uart, a nie uart <=> przejściówka <=> driver <=> windows <=>biblioteki użytego języka <=> program
Chciałem zakupić, ale na allegro większość to podróbki, które pewnie działają podobnie jak niesławny PL2303HX.
Piotrus_999 napisał:
komunikację można testować tylko uart <=> uart, a nie uart <=> przejściówka <=> driver <=> windows <=>biblioteki użytego języka <=> program
Racja.
Na razie bawię się przejściówką tylko dlatego, że chciałem sprawdzić działanie pewnych komend AT, a zwyczajnie łatwiej jest mi je pisać na bieżąco w terminalu.
Na razie bawię się przejściówką tylko dlatego, że chciałem sprawdzić działanie pewnych komend AT, a zwyczajnie łatwiej jest mi je pisać na bieżąco w terminalu.
oczywiście ale raczej duże prędkości należy już testować jak należy.
program można wgrać do ESP a nie bawić się z komendami AT
Oczywiście, że można, ale powiedz mi jak na ESP obsłużyć jednocześnie kartę pamięci, USB OTG, PWM, UART, 1-wire, I²C i mieć jeszcze kilka wolnych pinów GPIO
...Każda większa wartość (np. 256000) powoduje, że układ wysyła krzaki do terminala. Co ciekawe, wydaje się jeszcze wtedy rozumieć co mu wysyłam i udało mi się tak zmniejszyć baudrate do poprzedniej wartości.
Nie wiem czy powyższe objawy to wina modułu ESP czy może konwerter USB-UART (PL2303HX, podróbka) nie daje sobie rady. Czy komuś z Was udało się osiągnąć jakieś większe prędkości niż domyślne 115200?
Problem z tymi podróbkami jest taki że działające standardowe baudrate kończą się na 115200 albo 230400 (jak w przypadku ft232), dalej pozostają prędkości takie jak np. 250k, 500k, 1M, 2M.
@Pocieszny, bardzo prosto - na ESP pakuję całą komunikację, sterowanie połączeniami, protokołami, dekodowanie otrzymanych danych, ich składanie w logiczną całość, natomiast do układu wykonawczego pakuję tak jak mi się podoba tylko to co potrzebne. Np. prosty licznik - procesor liczy impulsy na jakimś GPIO, po czym wysyła do ESP tylko kilka bajtów, ESP zaś odpowiednio je koduje i wysyła np. po TCP/IP lub HTTP. Oszczędność nawet w tak prostym transferze na transmisji po UART jest ogromna, bo zamiast iluś komend AT, np. nagłówków HTTP itp. wysyłam tylko kilka bajtów.
Nie mówię, żeby na ESP pakować wszystko, bo ESP brakuje wiele do dowolnego uC (timery, przerwania, usb, ...), ale pakując do ESP dedykowane oprogramowanie jesteśmy w stanie podzielić projekt także logicznie - ESP ogarnia sieć, a nasz procek - sprzęt.
Sam robiłem ostatnio kilka tego typu projektów - w ostatnim ESP miał stronę konfiguracji urządzenia po HTTP, możliwość wysyłania danych za pomocą UDP / TCP/IP (także z protokołem TLS) / HTTP(S) - jako HTTP request, w dodatku ESP mógł uaktualnić oprogramowanie swoje i procesora korzystając z wsadów udostępnionych na serwerze klienta (dodam, że to też w trybie bezpiecznym, tak że nie jest możliwe skopiowanie wsadu). Transmisja po UART - prawie żadna. Zrobić to na komendach AT - nie wyobrażam sobie.
✨ Użytkownik posiadający moduł ESP8266 (ESP12) z domyślnym baudrate 115200 poszukuje sposobów na zwiększenie prędkości transmisji danych. Znalazł informacje o możliwościach osiągnięcia prędkości do 4Mb/s, jednak napotkał problemy przy próbie ustawienia wyższych wartości baudrate, co skutkowało błędami w komunikacji. Użytkownicy dyskutują o wpływie konwerterów USB-UART, takich jak PL2303HX i CH340G, na osiągane prędkości, wskazując na różnice w maksymalnych baudrate dla różnych modeli. Sugerują również testowanie komunikacji bezpośrednio z mikrokontrolerami, aby wyeliminować problemy związane z oprogramowaniem i sterownikami. Wskazano na możliwość programowania ESP, co może uprościć komunikację. Wygenerowane przez model językowy.
I to w postaci VCP - Virtual Com Port.
