symulator COM i LPT na laptopie

Dalej nie widzisz problemu. To nie jest kwestia tego czy ktoś pina sterownik LPT, COM, PCI czy USB. To jest kwestia że dinozaury piszące software do sterowania tym dalej nie potrafia uabstrakcyjnić protokołów komunikacyjnych. Tak aby ewentualna wymiana była łatwa i nie powodowała przepisania aplikacji na nowo. Tak aby w momencie braku jakiegoś portu można było zrobić jego emulację sprzętową i napisać sterownik do tego emulatora. Gdyby willem był dobrym programatorem to miał by na 100% przelotkę RS232->AVR->Willem i dopisany sterownik do tego zrobiony przez jakiegoś napaleńca któremu zależało.

Moment, chcesz mi powiedzieć że vista szyfruje za pomocą DRM moje pliki z listami do hydraulika? Albo cache przeglądarki? I to wszystko OOTB ? Nie wypowiem się autorytarnie ale sprawdzę, choć nie wierzę.

Mówię o wykorzystaniu dowolnego współczesnego notebooka (a czas życia notebooków ogranicza dostępnośc baterii więc na rynku wiele 486-tek nie ma).

A co ma problem drivera do pisania aplikacji korzystajacych z API portu COM ja się pytam? To problem producenta hardware, nie mój. API działa zawsze tak jak to zaprojektował MS z marginesem błedu na bzdurne sterowniki.

Soft willema nie jest prosty skoro do dzisiaj nie widziałem (ale też specjalnie nie szukałem) innej możliwości podpięcia go niż przez LPT. Nie jest prosty w negatywnym tego słowa znaczeniu. Nie ma abstrakcji warstwy hardware. I tak oto fajny i przydatny produkt idzie do piachu razem z LPT.

CAŁEJ ? Czy tylko tej związanej z obsługą zawartości chronionej prawnie? Jeśli jest tak jak mówisz to Vista nie sprzedała by się w ogóle w sklepach.

Nie żartuj sobie. Zdecydowana większość dinozaurów piszących 0x378 nie widziała Linuxa na oczy. To nie wina Linuxa że nie ma na niego software tylko wina dinozaurów którzy nie słyszeli o przenośnych bibliotekach GUI (często łatwiejszych niż natywne) czy abstrakcji sprzetu. Brak podstaw projektowych nawet w najmniejszych pierdołach mści się straszliwie po latach.

AVR->USB - na Linuxie - to akurat zły przykład. Bo tam jest. A jak nie ma to oficjalnie ci mówie - sam bym napisał jak bym miał potrzebę. _TO JEST PROSTE_ w przeciwieństwie do poprawiania programów pisanych przez osłów dłubiących wprost w hardware LPT czy COM.

Nie masz racji w 100%. Zawsze zdarzają się badziewia, ale przelotki USB->RS232 działają w zdecydowanej większości ok. Jedyny z nimi problem to problemy z warstwą fizyczną (napięcia itd) oraz czasami niereagowanie odpowieniu szybko na linie sterujące przepływem (co ma nikłe znaczenie bo w większości przypadków przecież wpuszczane jest to w RS485 a tam cięzko o kontrolę przepływu hardwareowo).

Oczywiście problem przelotek USB->COM to też stada jaskoniowców z zeszłej epoki piszących software ale tu już producent przelotki nic nie poradzi.

Sebastian Bialy pisze:

Najnowsze płyty główne już nie mają LPT. Na szczęście można kupić kartę z kontrolerem LPT ;-)

ps. Znasz coś niekomercyjnego lub w przystępnej cenie, co zastąpiło by mi Wigglera (LPT) dla ARM'ów?

pzdr mk

Na szczęscie nie do Laptopa (w rozsądniej cenie).

Nie. Ale jeśli chodzi o okolice JTAG to ciągle mam ochotę popełnić coś na USB->AVR->JTAG + sterownik do jakiegoś programu. Brak czasu nie pozwala ale może kiedyś :/

I to wszystko na LPT. I tu jest problem. Bo powinien robić to na abstrakcyjnym interfejsie który w jednej z implementacji jest LPT. Ale w pozostałych dziesięciu nie.

Ach czyli nie aplikacji? Czyli aplikacje (np. obliczeniowe) w zasadzie nie zwalniają? A to ok.

Np. w Widnows Vista można zgłościć się jako HID i do tego jest API. Bez sterowników. Jedyny problem to chyba "nielegalnność" nadawania sobie numerków USB bo nie ma czegoś takiego jak prywatne pule jak w IP.

Hmmm przecież timmingi ma zapewniać uC odbierający dane. A nie RS232. Jak by mi ktoś napisał aplikację w której znaczenie ma prędkośc reakcji systemu i fifo poru to bym pogonił kijem. To uC ma się zajmować timmingiem - uC ma zapewnić RT w wymaganym zakresie żeby zaprogramować pamięć.

Które są absolutnie zbędne, niestandardowe i można bez nich napisać taki konwerter RS232->AVR->Willem z powodzeniem ?

Można i w takiej sytuacji to zrobić. Dla mnie to żadne wyjaśnienie bo skoro jest czas na pisanie nowych features to czemu nei ma na refaktoring kodu ? Tym bardziej, że to wazniejsze niż ikonki na przyciskach bo zapewnia przetrwanie poza LPT.

No to niewielki do niego dodatek. Tu się jak widze zgadzamy.

Nawet zlewozmywak jeśli trzeba. I tak jest to 10x lepsze rozwiązanie niż

Dokładnie tak. Tylko że fakt, że nie ma już tego martwi mnie bo to może oznaczać badziewnośc kodu willema i nikt nie chce się za to zabrać. BTW czy willem ma upubliczniony kod ?

To zupełnie inna kwestia. Willema miałem i uważam go za nieciekawy kawałek hardware. Głównie ze względu na brak narzedzi konsolowych do programowania (nie cierpie programatorów tylko z interfejsem GUI). Pozbyłem się go szybko bo teraz sporo scalaków programuje się magistralami szeregowymi. Szkoda jednak tych setek (tysięcy) płytek lądujących w koszu w najbliższym czasie.

Bo to caly nowy projekt bedzie. Znacznie kosztowniejszy zasadniczo.

I nie trzeba ich robic, bo takie juz sa.

Z powyzszego zostaje karta dzwiekowa ... A jak ci na dzien dobry vista zagra "tadam" na kosci w programatorze ? Albo sie zdziwisz ze dane przeklamuje, bo po drodze mikser zmniejsza amplitude o polowe :-)

Ale to chyba nieciekawy kawalek software ?

Nie bardzo rozumiem czemu .. ale trzeba bylo napisac :-)

J.

Bo to nie soft jest trudny, tylko hardware jest prosty.

I wymaga odpowiedniego, calkiem prostego sterowania, tylko niestety ta mozliwosc zostala z peceta skreslona.

Teraz trzeba hobbyste ktory sie przebije przez mase dokumentacji i udostepni co ciezko wyczytal..

I to jest IMHO bardzo zle ...

Zapewne tylko tej od filmow.

Sprzedalaby sie sprzedala. W koncu nie piszesz prgramow tylko kupujesz dzialajacy komputer z oprogramowaniem.

A ze potem sie okaze ze w kazdej karcie jest danina dla MS za licencje, ze konkurencyjnosc na rynku sie zmniejszyla, bo kilku producentow odpadlo, ze moze nie tylko filmy sa zabezpieczone, bo zeby je dobrze zabezpieczyc to trzeba caly interfejs uszczelnic, zeby sie nie dalo "podejrzec" co jest do karty wysylane .. to nic, napiszesz "leniwym programistom sie nie chce".

A ktore od abstrakcji sprzetu polecasz i jaka dajesz gwarancje ze beda w przyszlosci ?

J.

Co konkretnie masz na mysli ? Bo owszem, IgorPlug jest, ale dziala w przeciwna strone.

No to zrob :-)

Jesli juz to Ethernet. USB tez latwo spalic :-)

Hardware nie jest taki zly.

A ludziska chca zeby maszyna miala ethernet, zeby bylo TCP/IP, zeby bylo zarzadzanie przez http, zeby pliki dalo sie podlaczyc do windows - jest miejsce na komenrcyjny system...

W zworkach nie bylo wiele magii, za to duzo zalet jak Pray&Płacz nie zadzialalo poprawnie.

teraz obowiazuje .NET [jeszcze ?], ale to nie jest ciecie galezi, tylko "profit multiplying" :-)

Taa .. a ile zajmuje implementacja. Tzn ile czasu ?

Nie martw sie - cos wymysla, i za 10 lat ktos ciebie nazwie dinozaurem :-)

J.

No chyba ze trzeba osiagnac predkosci dla RS232 nieosiagalne, szczegolnie jesli po USB, ewentualnie wymogu szybkiego zadzialania nie ma, ale czemu kostka programuje sie godzine ?

J.

Znaczy w czym kosztowniejszy ? Bo chyba lepiej szuka się błedów w programie z sensownym projektem niż w programie z sieczką dłubania po portach gdzie popadnie. Dobry projekt prawie zawsze wyjdzie na dobre nawet jesli wprowadzamy go później.

Nie przesadzajmy. A jak mi na dzieńdobry PnP wyśle komendy sterujące po LPT i nadpisze flash to już nie problem ?

Nie. Hardware. Tzn jest bezużyteczne.

make all.

Ide na kawe.

Przychodze i muszę k.... klikać. I w dodatku za każdym razem tak samo. Nie no ...

Hę ?

I cykl życiowy aplikacji się zamyka w koszu na śmieci. E, to nie jest droga. To że jest sporo pokemonów tak robiących to nie oznacza że to jest dobrze.

Myślisz że jest klasa HID pod nazwą "Willem" ? Przecież na LPT też jestem ściśle limitowany tym co może. I jakoś nikt nie narzeka bo da się to "obejść".

Raczej ten wątek jest o porażce a nie o sukcesie. Przecież wraz z LPT na śmietnik historii lecą też płytki willema. Można by je uratować prostym konwerterem ale ... software ... jesli jest zamknięty albo otwarty ale sieczka to tylko kosz.

Dlaczego niestety. Ja jakoś nie płakałem kiedy w moim komputerze zabrakło portu COM. W jeden dzień napisałem implementację mojego (interfejsu) COMa na TCP/IP i wykorzystałem router z interfejsem LAN i portem RS232. Ma w ten sposób RS232 over Ethernet. Aplikacja nie zauważyła zmiany. Jaki problem pisać tak software żeby wartwa komunikacyjna była łatwa do podmiany?

Czy ja coś mówie o podglądaniu kart ? Przecież Win ma trywialny interfejs obsługi COM portów od lat. Co tu niby jest tajemniczego?

Rozumiem że sobie żartujesz w tym miejscu ?

Napisałem (parę postów wczesniej) wszak prosty interfejs zapewniający abstrakcję COMa po wsze czasy. Jak jutro zabiorą Ci COMa z peceta to sobie doszyjesz na USB i zmienisz implementację klasy stojącej za tym interfejsem. Jak zabiorą USB do doszyjesz na TCP/IP+Ethernet+uC. Funkcjonalność jest zachowana, rdzeń software się nie zmienia, zmienia się tylko implementacja tego trywialnego interfejsu do COMa. Co w tym niby tajemniczego?

Mówiąc o abstrakcji nie mam na mysli systemu operacyjnego. Mam na myśli oddzielenie w moim kodzie pojęcia działania programu od komunikacji z hardware. To jest _moja_ abstrakcja i robie ją jak chce byle dobrze i z perspektywą.

Gwarancję daje na tą abstrakcję do czasu kiedy komuś się będzie jeszcze chciało pisać nowe implementacje tego interfejsu i do czasu aż będzie używany kompilator danego języka.

Nie mam tu zależności od systemu operacyjnego - ona jest schowana za interfejsem i reszta kodu nie ma pojęcia jaką metodą się komunikuje ani na jakim systemie pracuje.

Zrobiłem jakiś czas temu. Musiałem mieć 3x COM a miałem 2xCOM + LPT. Zrobiłem więc konwerter LPT<->COM na ATMega8. Działał w tym jednym konkretnym przypadku choć trudno być z niego dumnym. Potrzeba chwili. Aplikacje przerabiałem około 2 godzin pisząc wyłącznie implementacje jednej klasy. Jeśli willem ma sensowny projekt software to powinno się dać radę zrobić. Tylko że ja nie mam willema.

Ehernet jest nieprzyjazny amatorsko. Scalaki skomplikowane, drogie, wymagające masy tajemniczych elementów typu dławiki albo jakieś precyzyjne rezystory, itd. Implementacja softwareowa USB o ile pamietam wymaga 3 rezystorów + gniazdka.

Dalej ma w biosie obsługe pamięci taśmowych na _jakimś tam_ przerwaniu ? Dalej ma masę róznych przerwań sprzetowych zależnych od konfiguracji kart rozszerzeń ?

No świetnie. Tylko czemu u diabła ma to być poza tym wszystkim jeszcze RT ? ? ? Jedno z drugim nijak się zgadza. Albo rybki albo akwarium.

PnP było do d. bo i ISA była do d. Na PCI nie narzekasz, kiedy miałeś ostatnio problem z PnP w PCI i pochodnych od niej ? Win95 miał bo i sami się uczyli i producenci się uczyli. Teraz .. chyba nie ma żanych poza patologiami.

Teraz _możesz_ użyć .NET. W dodatku znowu nie tędy droga. A niech sobie MS zmienia implementację COM co rewizję systemu operacyjnego. Ja sobie pomienie klasę implementacyjną komunikacji co pół roku i soft będzie działać. Bez zmian w rdzeniu. Niech sobie producenci wywalają dowolny hardware. Zrobie międzymordzie i kawałkiem kodu załatwie problem.

Tej klasy na WinAPI ? Około 2 godzin z czytaniem dokumentacji. Tej klasy na Linux ? Około 3 godzin czytaniem dokumentacji. Tej klasy na router ? Około 2 dni z przebijaniem się przez brak dokumentacji i czytaniem PDFa CPU. Nie ruszyłem kijem ani bajtu w plikach rdzenia aplikacji - działa wszędzie tak samo.

Wątpie. Ja zauważam problem troche wcześniej niż kiedy znajduje swój projekt na śmietniku historii informatyki. Przynajmniej mam taką nadzieję.

Dziwnym trafem STK200 nie daje rady wyciągnąć nawet 1/2 prędkośći USBASP

- a to tylko głupia softwareowa implementacja programatora na USB. Może mam zły soft do sterowania STK200 ale raczej sprawdzałem na paru.

COM to był w ogóle zły przykład pod kątem szybkości. Ale w ogóle pozwalał by coś zaprogramować. Sugerujesz że lepiej mieć super szybki programator na LPT i laptopa bez LPT czy wolniejszy ale działający ?