symulator COM i LPT na laptopie

... bo te aplikacje nie uzywaja COM tylko portu z bitami... i nawalaja po bitach a nie wysylaja znaki...

Wiem. Tylko że nie widzę zasadniczo jakiejś poważnej różnicy o ile autor software i autor hardware zadbali o minimum abstrakcji.

Nic RT. Do tego jest sterownik żeby dbał o czasy a nie pecet. Nie wiem skąd ta potrzeba wciskania wszystkiego do software który z definicji nie jest i nie będzie RT. Może wzgląd ekonomiczny ? No dobrze ale przy 4x silnik po 500zł/sztuka głupi kontroler za 20zł załatwiający wszystkie problemy RT jest już śmieszny.

Wyginąć powinni programiści dalej klepiący programy pod DOSa do ich obsługi jak gdyby czas zatrzymał się w latach 80tych. Wyznawcy religii adresu 0x378 powinni wyginąć jak dinozaury. Mówie to dlatego że od paru lat zmagam się z takimi debilnymi aplikacjami (głównie w automatyce przemysłowej) kóre mimo upływu lat nie mają ani otwartego potokołu ani firma nie zamierza pisać nowej wersji. Wręcz zalecają użycie 486DX do obsługi "bo szybszy komputer jest za szybki i program się wiesza" i tym podobne debilizmy. To ja dziękuje, postoje.

Nooo. Jasne. Zwlaszcza jak musisz sie do sterownika gdzies w terenie podpiac. I targac "prosty PC z pentium" i monitor do tego. To juz lepiej odwrotnie: starszy laptop z LPT i RS i mocny komp stacjonarny.

nie znam API windows ale wydaje mi sie ze moze byc zupelnie inna implementacja tego dla roznego hardware - wlacznie z kartami multi RS a majacymi procesor RISC na pokladzie i widzianymi przez system jako COM. COM COM'owi nie rowny

widzisz, sam znalazles optymalne dla siebie rozwiazanie - nie pytaj mnie dlaczego manager pamiec w win XP jest gorszy od tego w 2000, nie pytaj mnie dlaczego 40 - 60% mocy obliczeniowej w viscie idzie w gwizdek...

A pecet z programem przejmujacym kontrole calkowita nie moze byc ? Czyli startujacym z DOS ? :-)

No coz, w dzisiejszych czasach masz wiele racji. W czasach gdy w pececie byla ISA niekoniecznie, a wrecz nie masz.

J.

Nie interesuje cie API windows. Robisz taki prymitywny interfejs:

struct universalCOM { virtual bool open() = 0; virtual bool write( char c) = 0; virtual char read() = 0; virtual close() = 0; };

I koniec. Oczywiście z grubsza. Pod tym obiektem leżą implementacje dla WinAPI, Linuxa czy choćby przeciętnego routera (!). Ale twoja aplikacja nie wie o tym jaka jest implementacja bo nie musi wiedzieć. Ba, może nawet być implemnentacja która wyśle te znaki przez sieć kanałem VPN do komputera w Australii i wypluje na tamtejszy COM po drodze szyfrując. Dla software żadna różnica. Usdostępniasz ten interfejs i po miesiącu ludzie napiszą ci implementacje dla MacOS, Solaris itd o ile będą zainteresowani rozwojem.

IMHO nie ma nic trudnego w abstrakcji portu COM. Tylko autorom się nie chce.

PS. Api windowsa jest absolutnie abstrakcyjne - podczas otwierania COMa nie masz pojęcia jaki tam jest hardware i jak go obsługiwać. Na tym własnie polega przewaga systemu operacyjnego nad dłubaniem po rejestach.

Świetne rozwiązanie należy podkreślić. 3 latopy powinny starczyć na obskoczenie większości urządzeń z głupawymi programami. Loozik.

Bzdura. Nie jesteś w stanie udowodnić tych procentów bo to nie prawda.

Nie może. Dlatego że współczesna architektura PC musiała by spowodować że:

a) albo mamy strasznie skomplikowany program zdający sobie sprawę z setek implementacji hardware

b) albo mamy program który działa tylko na modelu XXX z serii płyt głównych o numerach seryjnych yyy-zzz.

Obydwa rozwiązania są do d. I nawet nie ma co wspominać że przeciętny pecet to żenada jeśli chodzi o RT bo przeciez nie odetniesz sobie przerwań zeby symulować deterministycznośc czasu. Bo niby jak będziesz czytał z dysku, komunikował się z gfx itd ? A przecież wystarczy wyprowadzić sterowanie niezbędne dla RT na zewnątrz do uC za 20zł i po sprawie.

To my tu narzekamy na eksponaty muzealne czy na problemy wspłczesne? Moment, niech sobie przypomnę ... ISA zanikła gdzieś tak chyba koło 2001 roku. A programy obsługujące LPT pisze się do dzisiaj. Albo robi protezy pozwalające w Win obsługiwać porty COM/LPT na rejestrach zamiast z WinAPI. Chyba mi nie powiesz, że to normalne. Nie usprawiedliwiaj dzisiejszych leni sytuacją 10 lat temu.

No coz, w zasadzie musze ci przyznac racje. Odkad pecetowi "odebrano pazurki", chocby w postaci portu LPT, to przestaje sie on nadawac na sterowniki, a domorosli programisci sa skazani na wymarcie.

Troche zaluje, bo zaplacimy my, klienci. Nie bedzie programator/interfejs/sterownik kosztowal 10$, zaplacimy

100, albo i 500.

A tak swoja droga .. jak sie robi dzis "powazne sterowniki" ? QNX umarl, VxWorks umarl .. RTLinux czy WinCE ?

Trzeba przyznac ze ten mikrosekundowy czas operacji na magistrali to straszne marnotrawstwo w czasach gigahercowych prockow :-)

A Microsoft to kiedy sie zdecydowal i ustalil WinAPI do obslugi COM, takie ze nie zaniknie w kolejnej wersji ?

O LPT juz nie wspominam, bo tu sie chyba dawno zdecydowal - to sie nie bedzie nadawalo do uzytku i zostanie skasowane.

J.

Jesli programisci sie przylozyli do roboty, to nie powinno byc roznic. Tylko ze mowie o programistach z MS, i tu do przylozenia mam wielkie watpliwosci.

Kiedys nawet usilowalem sie z tym API zapoznac, ale mi szybko przeszlo

- publicysci z MS tez sie nie przylozyli do roboty, ewentualnie celowo oddali rynek tym od drogich ksiazek :-)

J.

Użytkownik "Sebastian Bialy" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:fjbbvf$stp$ snipped-for-privacy@atlantis.news.tpi.pl...

Niestety przyjmujesz naiwny model wykorzystania portu COM w programatorach - jako strumienia danych. W prostych programatorach wykorzystuje się piny portu jako zwykłe wyjścia.

To zupełnie inny gatunek problemu - tam hardware jest tajne, protokoły tajne, magiczne sekwencje właczające nieudokumentowane funkcjie w teoretycznie kompatybilnych protokołach itd. Choć od gdzieć 2000 roku sporo samochodów ma w miarę podstawowym zakresie zbliżone interfejsy.

Tobie ta vista szyfruje dane OOTB ? No to tylko współczuć, ja sobie muszę powłączać takie ficzery.

Nie wiem czy zwróciłeś uwagę że dyskusja była o tym, że w prehistorycznych czasach do obsługi LPT dłubano w portach IO procesora. I wielu jaskoniowców robi to do dzisiaj. Nie wiem skąd te wyskoki z vistą, przecież ja tylko chciałbym żeby obsługiwać sprzęd z użyciem API z czasów Windowsa 95 co najmniej ! I działał by z vistą i z win95 bo interfejs api do COM nie zmienił się.

Naiwne jest twierdzenie że jeśli coś wymaga sterowania pinami to musi być to zrobione przez LPT bądzi inną technikę równoległą na poziomie łącza z komputerem. Naprawde nawet nie naiwne tylko żałosne. Zapomniałeś że przeciętny AVR ma koło 20 pinów I/O. No chyba że wymyślenie prostackiego protokołu RS232->równoległe IO przerasta możliwości programisty.

MS trzyma standard tego API od przynajmniej W95 do XP co najmniej (z Vistą nie miałem okazji sprawdzać). Nie ma żadnych istotnych zmian które miały by wpływ na programy stare i nowe.

Wbrew pozorom API do COM jest proste. Nawet jedno z prostszych z WinAPI. Niestety są z nim inne problemy o których już pisałem na grupie typu niektóre hardware nie potrafi ustawiać prędkości, itd. Ale to wina niedorobionych sterowników w samym MS raczej.

Nieprawda. Zrobienie USB->AVR możliwe jest programowo. Za 5zł masz to samo co miałbyś z LPT - fakt nieco więcej roboty ale tylko pozornie. O wiele wygodniej jest wpinać na USB niż LPT i bać się że znowu port popsujesz (a montowane LPT dzisiaj są wyjątkowo delikatne). Dla amatora jak znalazł [*]

E. Pare $ więcej. W produkcji masowej niezauważalne.

Tylko nie WIinCE :) Ja w ogóle mam wrażenie że RT nie powinno być implementowane na PC. Bo się do tego hardware nie nadaje. I w dodatku w wielu projektach da się to całe RT wyjąć ze skomplikowanej logiki samego programu do prostego, deterministycznego kontrolera.

Dla mnie raczej powiedzenie "do widzenia" magii zworek.

Nie wiem kiedy, ale mi program działa od W95 do WXP i obsługuje port COM tak samo z grubsza. IMHO nic nie zmienili bo by sobie odcieli gałąź. Ale problem w czym innym: dinozaury piszące w kodzie w kóło 0x378=(3<<a)|7 mają w oczach błysk paniki jak tylko cokolwiek się zmieni. To się powinno leczyć. Mi tam wystarczy wymienić implementację abstrakcyjnej klasy żeby przenieć program z PC+WinXP na kuchenkę mikrofalową.

Cudownie. Już się nie mogę doczekać kiedy nie będzie można w ogóle kupić płyty z LPT w sklepach. Może częśc osób zauważy że poza Turo Pascalem jakiś postęp nastąpił.

[*] Tak wiem, problem jajka i kury, bez LPT cięzko ten kontoler zaprogramować.