Muszę przetestować aplikację portu szeregowego w systemie Linux, jednak moja maszyna testowa ma tylko jeden port szeregowy.
Czy istnieje sposób na dodanie wirtualnego portu szeregowego do systemu Linux i przetestowanie mojej aplikacji poprzez emulację urządzenia za pomocą powłoki lub skryptu?
Uwaga: nie mogę zmienić mapowania portu, został zakodowany na ttys2 i muszę przetestować aplikację w takiej postaci, w jakiej została napisana.
Odpowiedzi:
Możesz użyć do tego pty ("pseudo-teletype", gdzie port szeregowy jest "rzeczywistym teletype"). Z jednej strony otwórz /dev/ptyp5, a następnie dołącz swój program do /dev/ttyp5; ttyp5będzie zachowywał się jak port szeregowy, ale wysyła / odbiera wszystko, co robi, przez / dev / ptyp5.
Jeśli naprawdę potrzebujesz go do komunikowania się z plikiem o nazwie /dev/ttys2, po prostu usuń stary plik /dev/ttys2z drogi i utwórz łącze symboliczne z ptyp5do ttys2.
Oczywiście możesz użyć innego numeru niż ptyp5. Być może wybierz taki z wysoką liczbą, aby uniknąć duplikatów, ponieważ wszystkie twoje terminale logowania będą również używać ptys.
Wikipedia zawiera więcej informacji o ptys: http://en.wikipedia.org/wiki/Pseudo_terminal
ptsstronę podręcznika po szczegóły.
Uzupełnienie odpowiedzi @ slonik.
Możesz przetestować socat, aby utworzyć wirtualny port szeregowy, wykonując następującą procedurę (testowane na Ubuntu 12.04):
Otwórz terminal (nazwijmy go Terminal 0) i uruchom go:
socat -d -d pty,raw,echo=0 pty,raw,echo=0
Powyższy kod zwraca:
2013/11/01 13:47:27 socat[2506] N PTY is /dev/pts/2
2013/11/01 13:47:27 socat[2506] N PTY is /dev/pts/3
2013/11/01 13:47:27 socat[2506] N starting data transfer loop with FDs [3,3] and [5,5]
Otwórz inny terminal i napisz (Terminal 1):
cat < /dev/pts/2
nazwę portu tego polecenia można zmienić w zależności od komputera. zależy to od poprzedniego wyjścia.
2013/11/01 13:47:27 socat[2506] N PTY is /dev/pts/**2**
2013/11/01 13:47:27 socat[2506] N PTY is /dev/pts/**3**
2013/11/01 13:47:27 socat[2506] N starting data transfer loop with FDs
należy użyć numeru dostępnego w zaznaczonym obszarze.
Otwórz inny terminal i napisz (Terminal 2):
echo "Test" > /dev/pts/3
Wróćmy teraz do terminala 1, a zobaczysz ciąg „Test”.
link=/path/to/linkpo każdej deklaracji urządzenia (po echo = 0). Dzięki temu może być używany w testach automatycznych. (tak jak slonik w swojej odpowiedzi)
socat -d -d pty,raw,echo=0 /dev/ttyUSB5,raw,echo=0.
/dev/ttyS0zamiast /dev/pts/1?
Użyj do tego socat:
Na przykład:
socat PTY,link=/dev/ttyS10 PTY,link=/dev/ttyS11
Jest też http://sourceforge.net/projects/tty0tty/ tty0tty, który jest prawdziwym emulatorem null-modem dla Linuksa.
Jest to prosty moduł jądra - mały plik źródłowy. Nie wiem, dlaczego na SourceForge jest tylko kciuk w dół, ale dla mnie działa dobrze. Najlepsze jest to, że emuluje również piny sprzętowe (RTC / CTS DSR / DTR). Implementuje nawet polecenia iotcl TIOCMGET / TIOCMSET i TIOCMIWAIT!
Na ostatnim jądrze mogą pojawić się błędy kompilacji. To jest łatwe do naprawienia. Wystarczy wstawić kilka wierszy na górze źródła module / tty0tty.c (po dołączeniach):
#ifndef init_MUTEX
#define init_MUTEX(x) sema_init((x),1)
#endif
Po załadowaniu moduł tworzy 4 pary portów szeregowych. Urządzenia to / dev / tnt0 do / dev / tnt7, gdzie tnt0 jest podłączony do tnt1, tnt2 jest podłączony do tnt3 itd. Aby móc korzystać z urządzeń, może być konieczne poprawienie uprawnień do pliku.
edytować:
Myślę, że byłem trochę szybki z moim entuzjazmem. Chociaż sterownik wygląda obiecująco, wydaje się niestabilny. Nie wiem na pewno, ale wydaje mi się, że zepsuło to maszynę w biurze, nad którym pracowałem w domu. Nie mogę tego sprawdzić, dopóki nie wrócę do biura w poniedziałek.
Po drugie, TIOCMIWAIT nie działa. Kod wydaje się być skopiowany z jakiegoś przykładowego kodu „tiny tty”. Wydaje się, że obsługa TIOCMIWAIT jest na miejscu, ale nigdy się nie budzi, ponieważ brakuje odpowiedniego wywołania wake_up_interruptible ().
edytować:
Wypadek w biurze naprawdę był winą kierowcy. Brakowało inicjalizacji, a całkowicie niesprawdzony kod TIOCMIWAIT spowodował awarię maszyny.
Wczoraj i dziś spędziłem na przepisywaniu sterownika. Było wiele problemów, ale teraz działa dobrze dla mnie. Wciąż brakuje kodu do kontroli przepływu sprzętu zarządzanego przez sterownik, ale nie potrzebuję go, ponieważ będę zarządzał pinami samodzielnie za pomocą TIOCMGET / TIOCMSET / TIOCMIWAIT z kodu trybu użytkownika.
Jeśli ktoś jest zainteresowany moją wersją kodu, wyślij mi wiadomość, a wyślę ją do Ciebie.
Możesz spojrzeć na Tibbo VSPDL do tworzenia wirtualnego portu szeregowego linux za pomocą sterownika jądra - wydaje się całkiem nowy i jest już dostępny do pobrania (wersja beta). Nie jestem pewien co do licencji w tym momencie lub czy chcą ją udostępnić komercyjnie dopiero w przyszłości.
Istnieją inne komercyjne alternatywy, takie jak http://www.ttyredirector.com/ .
W Open Source, Remserial (GPL) może również robić, co chcesz, używając Unix PTY. Przesyła dane szeregowe w „surowej formie” do gniazda sieciowego; Podczas tworzenia portu należy wykonać konfigurację parametrów terminala podobną do STTY, zmiana ich później, jak opisano w RFC 2217, nie wydaje się być obsługiwana. Powinieneś być w stanie uruchomić dwie instancje remserial, aby stworzyć wirtualny nullmodem, taki jak com0com, z wyjątkiem tego, że będziesz musiał wcześniej ustawić prędkość portu itp.
Socat (również GPL) jest jak rozszerzona odmiana Remserial z wieloma innymi opcjami, w tym metodą „PTY” do przekierowania PTY do czegoś innego, co może być kolejną instancją Socat. W przypadku tetów jednostek socat jest prawdopodobnie lepszy niż remserial, ponieważ można bezpośrednio umieszczać pliki w formacie PTY. Zobacz przykład PTY na stronie podręcznika. W obszarze „contrib” istnieje łatka zapewniająca obsługę RFC2217 do negocjowania ustawień linii szeregowej.
Korzystając z linków zamieszczonych w poprzednich odpowiedziach, zakodowałem mały przykład w C ++ przy użyciu wirtualnego portu szeregowego. Wrzuciłem kod do GitHub: https://github.com/cymait/virtual-serial-port-example .
Kod jest dość zrozumiały. Najpierw utwórz proces główny, uruchamiając ./main master, który wydrukuje na stderr używane przez urządzenie. Następnie wywołujesz ./main urządzenie podrzędne, gdzie urządzenie jest urządzeniem wypisanym w pierwszym poleceniu.
I to wszystko. Masz dwukierunkowe połączenie między tymi dwoma procesami.
Korzystając z tego przykładu, możesz przetestować aplikację, wysyłając wszelkiego rodzaju dane i sprawdzić, czy działa poprawnie.
Ponadto zawsze możesz utworzyć dowiązanie symboliczne do urządzenia, więc nie musisz ponownie kompilować testowanej aplikacji.
Przychodzą mi do głowy trzy opcje:
RFC 2217 obejmuje port COM w standardzie TCP / IP, który pozwala klientowi w jednym systemie emulować port szeregowy do programów lokalnych, podczas gdy w niewidoczny sposób wysyła i odbiera dane oraz sygnały sterujące do serwera w innym systemie, który faktycznie ma port szeregowy. Oto ogólny przegląd .
To, co byś zrobił, to znalezienie lub zaimplementowanie sterownika portu com klienta, który zaimplementowałby stronę klienta systemu na twoim komputerze - wyglądający jak prawdziwy port szeregowy, ale w rzeczywistości przenoszący wszystko na serwer. Możesz uzyskać ten sterownik za darmo od Digi, Lantronix itp. W celu wsparcia ich prawdziwych samodzielnych serwerów portu szeregowego.
Następnie zaimplementowałbyś połączenie po stronie serwera lokalnie w innym programie - umożliwiając klientowi łączenie się i wydawanie danych i poleceń sterujących w razie potrzeby.
Prawdopodobnie nie jest to trywialne, ale RFC istnieje i możesz znaleźć projekt open source, który implementuje jedną lub obie strony połączenia.
Alternatywnie, łatwo dostępne jest źródło sterownika portu szeregowego dla systemu Linux. Weź to, wypatruj sprzętowe elementy sterujące i niech ten jeden sterownik uruchamia dwa porty / dev / ttySx, jako prostą pętlę zwrotną. Następnie podłącz swój prawdziwy program do ttyS2, a symulator do drugiego ttySx.
Ale najłatwiejsza rzecz do zrobienia teraz? Wydaj 40 USD na dwa urządzenia USB z portem szeregowym, połącz je ze sobą (modem zerowy) i faktycznie posiadaj dwa prawdziwe porty szeregowe - jeden dla testowanego programu, drugi dla symulatora.
-Adam