Witam serdecznie.

Napisałem w C na Atmega32 program który wysyła dane po RS232 do PC gdy tylko dostanie znak 'a', i tu wszystko działa;


Oglądnąłem parę odcinków programowania w C++ Builder6 i postanowiłem przetwarzać dane na PC i oczywiście je wyświetlać.
Po długiej walce w końcu UC zaczął gadać z PC po RS232 i to bardzo dobrze, oto kod C++

No i wszystko działa dobrze gdy COM ustawiony w programie PC jest zgodny z moją przejściówką , ale używam przejściówki FT232RL i przy zmianie komputera zmienia się COM(więc nie mogę na stałe ustawić nr.COM-a) więc chcę testować porty COM aby nie trza było go wybierać. Niestety jeśli już uda mi się otworzyć port COM(oczywiście jakiś inny niż ten od AVR) to już próba odczytu funkcją "ReadFile" ( aby np sprawdzić czy dane mam od AVR) kończy się brakiem odpowiedzi programu,
Bufor read pusty i program stoi.Dodam że pokazany listing C++ jest testowy i tak się bawię, zmienię np nr COM i sprawdzam co się dzieje, Jestem nowicjuszem w tej materii, więc proszę o pomoc, jak mogę sobie z tym problemem poradzić.

Port COM związany jest z hardwarem (dokładnie to sterownikami, które go obsługują). Więc nie możesz sobie otwierać innego portu niż ten przypisany do sprzętu. Jak nie masz dodatkowych fizycznych portów COM albo kolejnej przejściówki lub skonfigurowanego profilu SPP w bluetooth to nie otworzysz innego portu.

--
Pozdrawiam,
Robert

Zamysł miałem taki;
Mam funkcję SetCommState(hNumPort,&dcd) która zwraca TRUE po prawidłowym podłączeniu się do portu COM lub FALSE gdy nie uda się podłaczyć,
Myślę więc - w pętli While() po kolei spróbuję się podłączać do np;15-stu COM-ów, jeśli w końcu funkcja zwróci TRUE to zostanie mi wysłać znak 'a' do AVR aby za chwilę odebrać spodziewane się dane z AVR (bo tak mam napisane nadawanie w AVR) i w ten sposób odfiltruję pożądany COM. Problemem jest użycie funkcji ReadFile(hNumPort,IpBuffor_read,10,&RS_ile,0) ponieważ jeśli jej użyję(aby sprawdzić odebrane dane), a bufor odbiorczy nie jest zapełniony, to funkcja jak by czeka w nieskończoność na dane i blokuje program, nie wiem jak opuścić tą funkcję (np. po jakimś krytycznym czasie) aby kontynuować sprawdzanie portów.
Jako ciekawostkę w menadżerze urządzeń widzę aktywny COM4 (to nie moja przejściówka) i mogę się do niej podłączyć i nawet wysłać dane, a już np. próba odczytu z COM4 ,zatrzymuje program. (przypuszczam że nic nie przylatuje do bufora odbiorczego) , robiąc testy na mojej przejściówce wystarczyło że w Atmedze za komentowałem nadawanie po RS232 i program w PC zachowywał się dokładnie tak samo przy próbie użyciu funkcji ReadFile(hNumPort,IpBuffor_read,10,&RS_ile,0).

Jeszcze muszę dużo poczytać, a najlepiej namówić P.Mirka do napisania książki o C++ (ale tak łopatologicznie tłumacząc na przykładach jak AVR-y) aby można było zrozumieć

Popatrz na komponenty Mirka do Delphi/C++ buildera. Nakręcił do nich różne filmiki. Np. MkUsbDetector

Możesz spróbować odczytać z rejestru windowsa dane każdego urządzenia widzianego jako port COM. Możesz sprawdzać numery VID i PID dla każdego portu.
Prawdopodobnie dla FT232RL wartość VID to 0403 a PID to 6001. Ale to musiałbyś sobie sprawdzić.

Szanowni koledzy, dziś w poszukiwaniu rozwiązania mojego problemu, znalazłem podobny temat i przeczytałem "Tutaj masz kody źródłowe (C#,C++,Delphi) , jak korzystać z chip-ów FTDI : http://www.ftdichip.com/Projects/CodeExamples.htm" pobrałem więc program testowy do C++ Builder wprost ze strony producenta układu z którego korzystam (że też wcześniej na to nie wpadłem), skompilowałem go i uruchomiłem, po uruchomieniu zobaczyłem przyjazny program do testowania przejściówek i to w dodatku do edycji, jest tak mały że może uda mi się go zrozumieć.

Tak więc dziękuję za pomoc i zainteresowaniem tematem,
Serdecznie pozdrawiam ludzi którym się chce pomagać.