Zwolnienie prędkości transmisji danych TXT COM RS232 115200 > 9600, 4800...

Nawet nie wiem jak to nazwać, "przystawka" ?
Mam urządzenie w którym nie ma możliwości zmiany prędkości wysyłania danych 115200, a ponieważ producent już nie istnieje, nie ma też możliwości proszenia u niego o pomoc. Urządzenie, które te dane odbiera w tym przypadku drukarka może to robić z prędkością 9600 i niżej.
Szukam jakiegoś prostego (jeżeli istnieje) rozwiązania, by ten "kontroler" zmieniał te prędkości.
Najlepiej jakiś przełącznik DIP gdzie dane wchodzą z prędkością 115200 i można wybrać jakie uzyskamy prędkość wyjściowe np. 9600, 4800 itd.
Może ktoś spotka, może potrafi wykonać... proszę o każdą sugestię.

Maksymalny pakiet danych, [bajtów: 1 920] przynajmniej takiej wielkości tworzy mi plik txt na komputerze gdy z terminala kopiuje raport.
Myślałem nad atmega lun ftdi , ale to za wysokie progi na moje amatorskie nogi by od zera coś wynaleźć

[Ignas] napisał:

Maksymalny pakiet danych, [bajtów: 1 920]

[Ignas] napisał:

Myślałem nad atmega

Atmega np. 328 czy klasyczne Arduino z 2k RAM odpada od razu. Bo potrzebujesz spory bufor w pamięci.
Z tanich, dostępnych rozwiązań może być np. pospolita i tania płytka Bluepill.
Ma więcej uartów niż jeden oraz sporo RAM.
Można ją oprogramować również w środowisku Arduino (choć w tej chwili nie wiem jak wygląda obsługa wielu uartów na raz), co może sporo ułatwić i nie potrzeba do niej żadnego programatora.
Tak że sprzętowo, oprócz tej płytki (i jakiegoś zasilania), były by potrzebne tylko konwertery poziomów na RS232 (w zasadzie jeden jeśli transmisja idzie w jedną stronę).

Miałem nadzieje na jeden układ z kilkoma elementami zewnętrznymi, a wyjdzie, że muszę "mini pc" zbudować.

atari_robbo napisał:

płytki nucleo, one są po kilka euro

Nucleo są niestety sporo droższe niż kilka euro.
Ale jeśli już powiedziałeś mbed, to przecież płytki Bluepill są też obsługiwane przez mbed (choć nieoficjalnie) a kosztują znacznie mniej niż Nucleo (ca. $1.5 u chińczyka).
I mbed chyba byłby najwygodniejszym rozwiązaniem problemu, choć wszystko zależy od możliwości kolegi [Ignas].

Dobrze, a gdyby tak ograniczyć jednorazowy pakiet maksymalnych danych do 200 bajtów (raporty miesięczne) zmieniło by to coś ?
Drukowane są jedynie znaki - i cyfry.

[Ignas] napisał:

Dobrze, a gdyby tak ograniczyć jednorazowy pakiet maksymalnych danych do 200 bajtów (raporty miesięczne) zmieniło by to coś ?

Niedużo. Filozofia ta sama. Po prostu znaki przychodzące muszą być wpisywane do pamięci (bufora kołowego), bo wysyłanie na bieżąco jest wolniejsze. Z racji tego że u Ciebie przychodzą ponad dziesięć razy szybciej niż wychodzą.
I stąd ta konieczność realizacji na jakimś mikrokontrolerze. Choć czysto sprzętowo też się takie rzeczy robiło ale na dziś to nie ma kompletnie sensu.
Zmniejszając rozmiar danych jedynie staje się możliwe użycie mikrokontrolerów z mniejszą pamięcią RAM czyli klasyczne Arduino i niektóre ATmegi. Ale złożoność problemu właściwie bez różnicy.
Ale właściwym problemem jest pytanie, jakie masz doświadczenie w mikrokontrolerach i na ile jesteś w stanie taki temat zrealizować, przy wsparciu oczywiście tu z elektrody.

Na Allegro można w miarę tanio kupić "terminal", który jest komputerem kompatybilnym z PC. Jest nawet jakiś z dwoma portami szeregowymi...

Raspberry Pi ma tylko jeden UART, a do tego napięcia nie pasują do RS232 i byłyby potrzebne translatory napięć. A ten "terminal" kosztuje kilka razy mniej od Raspberry Pi, powinien na tym pójść jakiś TinyCore Linux i ma dwa porty RS322, potrzebne są tylko kabelki z wtyczkami.

Urządzenia spełniające Twoje wymagania to bufor RS232, na przykład taki: Link. Niestety rozwiązanie kosztowne. Może ktoś wykona podobne urządzenie na zamówienie, ale to też kosztuje.

Prawie 300 Euro. Ten "terminal" kosztuje kilkadziesiąt razy mniej - tylko trzeba na nim zainstalować Linux-a i puścić prosty programik. I będzie mógł zbuforować kilkadziesiąt razy więcej danych...