RS232 na przejściówce działa, na prawdziwym COMie nie. :-(

Mam dziwny problem, który całkowicie mnie zaszokował. Zgłupiałem! Mam urządzenie na Atmega, które:

1. Na przejściówce USB-COM współpracuje z terminalem idealnie (mogę przesyłać z poziomu terminala i transmisja przebiega dobrze)

2. Na prawdziwym porcie COM, mogę przesłać z terminala do urządzenia tylko dwa znaki (wiem, bo po każdym przesłanym znaku mam zwrócone echo). Po przesłaniu dwóch znaków jakby blokuje się bufor - nie mogę przesłać ani jednego znaku więcej - nie dostaję echa. A bufor jest 4 znakowy (tyle znaków ma komenda sterująca, i na tyle znaków oczekuje moje urządzenie).

Co jest, kurcze! Normalną rzeczą jest prawidłowość, że nie każde urządzenie, które działa na prawdziwym porcie COM, musi od razu działać z przejściówką USB-COM, ale... żeby w drugą stronę...?

Zamurowało mnie to, co teraz stwierdziłem, i pojęcia nie mam co jest nie tak.

Na początku nie zmostkowałem linii 6-4 i 7-8. Myślałem, że to będzie przyczyna. A teraz jest zmostkowane, i układ zachowuje się tak jak opisałem wyżej. Czyli z przejściówką dalej działa, a na prawdziwym porcie nie!

Ktoś wie, co tu jest grane?

Jak juz zmostkowales 6-4 i 7-8 to czemu nie sprawdziles czy po zmostkowaniu 2-3 odbierasz wysylane znaki? (takie hardware echo). Jesli jest OK to niestety ale wina gdzies po stronie ukladu/oprogramowania.

Z tego co napisałeś rozumiem, że nie dostajesz w terminalu echa dla 3, 4 i kolejnych (??) znaków w przypadku rzeczywistego portu szeregowego. Jeśli po tej paczce wyślesz kolejną to już nie dostaniesz echa po dwóch pierwszych znakach?

Próbowałeś podglądnąć transmisje (np. oscyloskopem, analizatorem stanów logicznych) w celu upewnienia się, że to wina komputera, a nie mikrokontrolera? W ten sposób sprawdzisz, czy to nie jest przypadkiem tak, że mikrokontroler dostaje te znaki, ale z jakiegoś powodu nie odpowiada.
Jeśli nie masz oscyloskopu lub analizatora to może po każdym kolejnym znaku odebranym przez mikrokontroler zmień stan na kolejnym wyjściu (np. PA1 jeśli odebrano pierwszy znak, PA2 - jeśli przyszedł drugi, itp). Może wystawiaj to, co dostaniesz na którymś porcie mikrokontrolera?

Wstępnie wydaje się, że to jest problem po stronie Twojego układu/programu.

VanThor napisał:

Z tego co napisałeś rozumiem, że nie dostajesz w terminalu echa dla 3, 4 i kolejnych (??) znaków w przypadku rzeczywistego portu szeregowego.

Dokładnie.

VanThor napisał:

Jeśli po tej paczce wyślesz kolejną to już nie dostaniesz echa po dwóch pierwszych znakach?

Jest tak jak piszesz, i to jest właśnie dziwne.

VanThor napisał:

Próbowałeś podglądnąć transmisje (np. oscyloskopem, analizatorem stanów logicznych) w celu upewnienia się, że to wina komputera, a nie mikrokontrolera?

Na pewno nie jest to wina komputera, bo sprawdziałem na trzech prawdziwych portach RS232. Okazuje się, że mój układ działa tylko na przejściówce, bo tylko przy jej zastosowaniu mogę wysłać do urządzenia więcej niż dwa znaki (paranoja).

VanThor napisał:

W ten sposób sprawdzisz, czy to nie jest przypadkiem tak, że mikrokontroler dostaje te znaki, ale z jakiegoś powodu nie odpowiada.

Jutro będę testował dalej i niuchał co jest nie tak. Ale nie ma prawa tak robić. Nie może nie odpowiadać, bo echo jest funkcją automatyczną instrukcji języka wysokiego poziomu w którym firmware zostało stworzone. Jeżeli 4 znakowy bufor (długość zmiennej typu string) zapycha się po 2 znakach, to tak trochę jakby urządzenie dostało jeden znak podwójnie, tylko niby dlaczego (z resztą echo potwierdza, że był wysłany pojedynczy znak a nie dwa znaki). Jutro zbadam swoją hipotezę. A transmisja przebiega prawidłowo i to w dwie strony, przynajmniej przy pierwszych dwóch znakach, więc cała reszta tej historii jest dla mnie jakimś absurdem... Sam jestem ciekaw przyczyny tej dziwnej sytuacji!

Problem rozwiązany.

Problemem była prędkość 128000
Na nieco mniejszej 115200 wszystko pracuje idealnie.

Wychodzi na to, że przejściówki USB-COM potrafią mieć lepsze parametry niż prawdziwy COM.

albertb napisał:

Czy urządzenie się zawiesza, czy oprócz transmisji działa poprawnie?
Jeśli masz komunikację po znaku (tzn. wysyłasz z komputera znak, odbierasz echo, wysyłasz następny znak)
to przychodzi mi na myśl, że Twoje urządzenie nie wyrabia
się czasowo.
Bo przy RS232 odstęp między kolejnymi transmisjami jest limitowany tylko szybkością transmisji,
a przy przejściówce to co najmniej 2 ms (dla USB full speed wysłanie 1 znaku, za 1ms potwierdzenie, i znowu 1ms na wysłanie)

Zanim doszedłem do sedna problemu, zaprogramowałem mikrokontroler tak, aby wysyłał string "ala" co 100ms, a na terminalu PC obserwowałem co dochodzi. Okazało się, że dochodzą krzaki (mimo prawidłowej konfiguracji po obu stronach transmisji). Zmieniłem prędkości do 115200 i nagle wszystko zaczęło działać. Sytuacja dotyczy prawdziwego portu COM.

Na przejściówce działało wszystko, 115200 i 128000, więc nie wiem, dlaczego prawdziwy port (i to na trzeh niezależnych komputerach) miał problem z obsłużeniem prędkości 128000.

Oczywiście mamy tutaj do czynienia z tzw. transmisją znakową.

Na przejściówce USB/rs232 można pędzić prędkości kilkukrotnie wyższe niż 128000, niestety interfejs rs232 w pc oparty o klasyczny 16550 jest w stanie pracować z maksymalną prędkością 115200. Nie wiem skąd w Windowsach możliwość ustawienia 128000, skoro działa to jak sam widzisz...