Własna prosta niezawodna przejściówka USB-RS232 (AVR)

Witam,

ten temat chyba już był poruszany na elektrodzie, wielu ludzi szukało różnych sposobów na jak najprostszy sposób aby korzystać z komunikacji poprzez USB w swoich układach mikroprocesorowych.

wiele jest różnych rozwiązań w necie jak choćby cesko.igor czy na niemieckich stronach Powerswitch ale są różne niuanse a to od strony driverów do windy a to od strony licencji na wsad itp (a do tego ciężko bywa z napisaniem czasem własnego oprogramowania do transmisji przez różne układy tego typu)

wiadomo są też dobre i sprawdzone układy FTDI Chip ale trzeba je sobie kupić a tymczasem każdy kto grzebie się w AVRkach ma przeważnie pod ręką coś takiego jak ATmega8

widziałem też już ktoś wrzucał tu na elektrodzie link do strony takiego fajnego japończyka Osamu Tamura i do jego projektu. Ktoś nawet pisał że zrobił to ale działa mu z wolnymi prędkościami do 4800

podaję więc jeszcze raz link do stronki:

http://www.recursion.jp/avrcdc/index.html

a tu mamy rozwiązanie "proste jak drut" - dawno każdemu dobrze znana komunikacja jak po zwykłym RS232 (chociaż leci sobie po USB)

i gorąco polecam. Poniżej przedstawiam to co zrobiłem w oparciu o ten projekt. Przepraszam tym razem za jakość zdjęć, zwykle bardziej się staram

widok płytki prototypowej na której widać 2 procesory Atmega8

jeden z nich (ten po prawej) to układ Osamy Tamura (czyli konwerter USB->RS232), drugi natomiast ten po lewej to zwykły procek do którego podłączyłem wyświetlacz PLED.

Jak widać na dole zdjęcia jest gniazdko USB z włożoną wtyczką (kabel do kompa leci) - z tego USB zasilam akurat wszystko na tej płytce czyli te 2 procki oraz wyświetlacz PLED.

Ponieważ w niewiarygodnie prosty sposób można uzyskać za pomocą równie niesamowicie prostego drivera (tylko plik INF!!!) virtualny port szeregowy COM w PC to cały ten układ działa na płytce w ten sposób, że:

1. z komputera PC przesyłam z terminala przez ten wirtualny COM jakieś teksty
2. lecą sobie te dane przez konwerter USB-RS232 (Atmega8 po prawej) i wychodzą w postaci sygnałów Tx oraz Rx dalej
3. dalej to znaczy wchodzą na wejście Rx oraz Tx drugiego procka Atmega8 po lewej, który owe teksty wyświetla na wyświetlaczu PLED

z punktu widzenia mojego układu Atmega8 z wyświetlaczem PLED ten drugi procek jest przeźroczystym problemem ... ot poprostu przejściówka i to jeszcze jaka! ... spokojnie bez najmniejszego bólu uzyskuję prędkości transmisji do 115200 !!! - jakie chcę - w zależności oczywiście od taktowania mojego procka.

Tak więc w moim procku napisałem kilka linijek w języku którego się dopiero uczę czyli Bascom i dzięki temu połączenie i wprowadzanie tekstów z terminala PC na wyświetlacz PLED jest bajecznie proste

dokładny schemat przejściówki:


na koniec dodam jeszcze, że własnie instalacja tego wszystkiego pod Windą sprowadza się do tego, że gdy pierwszy raz podłączamy naszą przejściówkę do USB , system wykrywa nowe urządzenie i pyta o driver, nie ma co pozwalać aby sam szukał - wskazujemy na jeden plik inf, który dostarczył Osamu Tamura i po kłopocie. Wprawdzie system windows informuje że driver nie jest podpisany cyfrowo przez sam Microsoft ale to bzdura bo ten INF tak naprawdę zasysa standardowy i to windowsowy driver do utworzenia wirtualnego COM'a tak więc śmiało można klikać "mimo to kontynuuj" i po chwili mamy w pełni sprawny nowy port COM w kompie - no i chulaj dusza - dalej można już robić co żywnie przyjdzie do głowy!!!

poprostu totalny mega bajer ta przejściówka - jestem w miłym szoku

pozdrawiam

Moderated By androot:

Bardzo ładnie, sam takie coś mam zamiar zrobić TYLKO PROSZĘ O ZAMIESZCZANIE JEDNEGO ZDJĘCIA NA SAMIUTKIM POCZĄTKU. Pojawi sie wtedy na stronie głównej!!

Czy plik zip wystarcza do kompilacji?
Mam winXP + AVRstudio
Pozdr

nawet nie trzeba nic kompilować w AVR Studio - tam w podkatalogach są umieszczone gotowe wsady do procesorów różnych w tym do ATmega8 - wystarczy tylko to wgrać za pomocą dowolnego programu do procka i po zawodach

ale oczywiście jak ktoś zna C i chciałby coś tam poszperać w kodzie to trza zassać AVR Studio 4.13 oraz WinAVR (kompilator C) i jazda

Już znalazłem
Dzięki. Może kidyś wypróbuję.
Powodzenia

Rzeczywiście robi to wrażenie.
Ponieważ jest to dość wartościowy projekt oraz kolega mirekk36 "przegryzł" się przez niego i chciał się tym wynalazkiem podzielić to może udałoby się zebrać wszystko co potrzebne do tego projektu w postaci opisanych plików i zamieścić poniżej. Następnym byłoby łatwiej.

Quote:

ale oczywiście jak ktoś zna C i chciałby coś tam poszperać w kodzie

Próbowałem bo chcialem "zassać" niektóre funkcje do ARM'a i nieukrywam że Pan Osama pomimo licznych komentarzy trochę to mocno "wymieszał" . Nie wiem co w tych AVR'ach takiego jest ale mi na ARM'ie (60Mhz) "za chiny" nie rusza obsługa USB gdzie kod do odczytu pisany w ASM. Ale to inny temat.
Co do tego projektu też mam zamiar go wykonać.
Pytanko, próbowałeś uruchamiać to na innych PC, ewentualnie innych wejściach USB??

M. S. wrote:

... to może udałoby się zebrać wszystko co potrzebne do tego projektu w postaci opisanych plików i zamieścić poniżej. Następnym byłoby łatwiej.

jasna sprawa - poniżej potrzebny plik zip

w nim jest wszystko co potrzeba - ja dokładnie z tego skorzystałem

markosik20 -> uruchamiałem to dzisiaj narazie tylko na 2 różnych PCtach z windą XP (jeden Home a drugi Professional) i bez najmniejszego problemu tak samo zawsze działa. Od jutra sprawdzę jeszcze na innych PCtkach - mam nadzieję, że będzie OK. A co do wejść USB - to w tych dwóch kompach wszystkie "przeleciałem" i również wynik pozytywny

a przy okazji niedługo ruszam z nauką również języka C na procki bo nie wytrzymam (super będzie znać 3 języki i z każdego skorzystać gdy trzeba)

Quote:

a przy okazji niedługo ruszam z nauką również języka C

To Bascoma już opanowałeś?

Bascoma ? hyhyhy jeszcze nie - ale pożeram go wręcz - jest super do tzw "szybkich działań bojowych" i to bezsprzecznie. I jeszcze dłuuuga droga przede mną żebym mógł powiedzieć, że go opanowałem, ale w międzyczasie zacznę oczywiście C, więc może czasem wtedy też tu na forum o coś dopytam - i mam nadzieję, że kolega markosik20 spec od C coś mi tam zawsze podpowie?

Czy Pan Tamura nikogo sie nie obawia? FTDI

A tak na poważnie czy ktoś nie zrobiłby kasy gdyby zrobił kontroler typu 'wpisz wartość do rejestru i wyslij paczke danych przez USB' i do niego dołączał jakiś driver/ komponent np do delphi żeby te dane potem 'wyciągnąć' ?

Chcąc nie chcąc to są ciągle "protezy".. W EP często jest jakiś projekt typu "xxxxx z USB!!!" . A jakie to jest USB.. Autorzy tylko podwyższają sobie range projektu tym ".. USB!!!". Powinni pisać RS232 via USB..

Pana Tamure oczywiście podziwiam bo zrobił konwerter a nie 'xxxx z "USB" '

aco powies zo tym konwenterku USB/RS232 ? http://msevm.com/main/igorusb/index.htm

moze wyjdzie ze sie nie znam ale to co zawiera pierwszy post to raczej jest konwenter USB <> TTL bo nie wiem jak mega8 moze "stworzyc" -15 i + 15 na swoich portach
ba wydaje mi sie to totalne bez sensu gdyz ft232bm albo inne chipy robia dokladnie to samo tylko ze nie zzawieraja w sobie kodu ktory moze sie zawiesic !!

Faktycznie się czepiasz. Do pełni szczęścia potrzebny jest MAX232 i po kłopocie.

Quote:

inne chipy robia dokladnie to samo tylko ze nie zzawieraja w sobie kodu ktory moze sie zawiesic

Niby się zgadza lecz program jest tak napisany że jak "coś mu będzie dolegać" to uC się zresetuje. Może minusem jest ważna długość cyklu maszynowego uC (bo wszystko wyliczone z dokładnością do jednego cyklu) oraz to że USB to sygnał różnicowy który czasami ma się ni jak do TTL, natomiast plusem jest wykorzystanie projektu nie tylko do RS232. Można wykonać magistralę USB-I2C, USB-1WIRE, USB-SPI itp. Wymaga to jednak dobrej znajomości "ASM" i przeciętnej "C" danego AVR'ka.
A cenowo?......no chyba porównywalnie .

avatar wrote:

moze wyjdzie ze sie nie znam ale to co zawiera pierwszy post to raczej jest konwenter USB <> TTL bo nie wiem jak mega8 moze "stworzyc" -15 i + 15 na swoich portach
ba wydaje mi sie to totalne bez sensu gdyz ft232bm albo inne chipy robia dokladnie to samo tylko ze nie zzawieraja w sobie kodu ktory moze sie zawiesic !!

hmm warto kolego abyś przeczytał sobie na stronce Osamu Tamuty, że on skromnie pisze pod koniec, iż jeśli ktoś na dzisiaj potrzebuje w pełni profesjonalnego rozwiązania tego typu to oczywiście powinien skorzystać z układów np FTDI to po pierwsze

Gienek napisał:

Quote:

Do pełni szczęścia potrzebny jest MAX232 i po kłopocie.

a po drugie to tak jak już kolega Gienek powyżej zauważył - że to iż wyjścia są TTL to oznacza że wystarczy tylko sobie dorzucić MAX232. Ale jak widzisz ja podłączyłem bezpośrednio drugi procek więc po co mi było stosować MAX232 - i to jest duża zaleta

.... ogromnym atutem tego rozwiązania jest to, że łatwo , szybko i przyjemnie można wystartować z USB i powoli się tego uczyć dalej

Do mirekk36
Wielkie dzięki że zapodałeś tego linka. Opiniami starych wyjadaczy się nie przejmuj.
Dla wielu początkujących (jak ja) łatwiej zrobić na AVR-ku.
Powodzenia i szukaj dalej

Mam pytanie odnośnie układu... Dlaczego wybrano akurat ATmega8 a nie jaki inny mniejszy(gabarytowo) procesor na przykład z serii Tiny?

Quote:

Dlaczego wybrano akurat ATmega8 a nie jaki inny mniejszy(gabarytowo) procesor na przykład z serii Tiny?

Autor projektu wszystko napisał

"Program size is 2.8KB. Since ATtiny45 has no USART, 8bit timers make 4800bps timing. The USART version is also developed for ATmega8/48/88 and achieves the higher transfer rate."

o kolega markosik20 wytłumaczył to cytując słowa autora najlepiej

ja z chęcią też bym wypróbował ten projekt na ATtiny45 z tym, że nie można go nigdzie kupić natomiast nie porównałem czy można tak na żywca zastosować inny procek z serii ATtiny. Z drugiej strony możliwości przesyłania danych przez RS232 z pełnymi prędkościami jak 115200 są dla mnie bardziej interesujące - choć trzeba wstawić nieco większy gabarytowo procek

mirekk36 wrote:

ja z chęcią też bym wypróbował ten projekt na ATtiny45 z tym, że nie można go nigdzie kupić

Napewno?
http://elektronika-sklep.pl/sklep/index.php?p161

wow - wielkie dzięki kolego treker - tyle sklepów na necie przeszukałem a tego nie znalazłem ... odrazu kupuję - bo ostatnio po tych poszukiwaniach wydawało mi się, że ATtiny45 są już na "wymarciu"

Cześć!!!

Driver RS-232 <-> USB, który daje wirtualny port COM i co dalej ...

Zabawa na terminalu, test komunikacji, może programowanie procka ADuC bo się da przez Com, może programtor pamięci, czasem reaktywacja jakiego "gotowego" rozwiązania działającego dotąd doskonale na RS-232 i właściwie koniec zastosowań.
Potrzebne tylko w szczególnym, a może już dzisiaj standardowym przypadku braku portu COM w komputerze.

Pisanie aplikacji opartej na komunikacji szeregowej na porcie COM pod Windows to tragedia , otwórz plik i pisz i czytaj z pliku, tworz wątki.

Do tego jeszcze cała konfiguracja portu buforowanie, ciężka sprawa, do tego dochodzi jeszcze jeden problem właściwie, że ta przejściówka jest rozwiązaniem asynchronicznym , brak prostego testowania transmisji.

A przy takowym zagwarntowanie poprawnej transmisji jest zdecydowanie trudne przy prędkościach powyżej 19200 i dłuższych nieekranowanych kablach. Mam oczywiście na myśli dłuższe wymiany danych.

Praktycznie to rzeczywiście jest proteza i to nawet jeśli uzyskuje się transfer rzędu 115kB to nadal mamy do czynienia ze stunelowaną architeturą portu COM. Praktycznie użytkownik musi napisać protokół komunikacyjny PC - mikroprocesorek końcowy (inna Atmega 8 lub ARM , a może nawej C51) i zająć się opieką nad wymianą danych na "wyższym" poziomie. Czyli w sumie nic nowego, praktycznie jak kiedyć MAX232 i podłączenie procka po UART, a dalej męczarnie budowy protokołu, tylko że tam była jeszcze możliwość RTS/CTS na dwóch kolejnych liniach.

Komponent wykorzystjący rzeczywiste możliwości Atmegi lub ARM bardzo by się przydał (np. przetwornik AC/ USB lub PWM na USB).
Z zachowaniem architektury AVR. Pisanie i czytanie z szybkością USB to byłaby otwarta droga do własnych urzadzeń peryferyjnych PC, karta graberująca Video, karta dźwiękowa, miernik napięcia, oscyloskop etc. .

Co do cen to chiński kabel USB/TTL do telefonu komórkowego chyba jednak wyjdzie deczko taniej , a i stabilnością nie powinien być gorszy i też wirtualnego COM-a mamy .

Poza tym dość łatwo podłączyć go do procka i komputera i ciutkę mniej miejsca zajmie.

Super, że jest takie rozwiąznko i czoło chylę twórcy za znajomość architektury USB, ale coś to chyba jednak jest to ciągle jeszcze sztuka dla sztuki

W każdym razie potencjał to rozwiązanie niesie duży , ale gdyby był driver Atmega w WindowsXP to byłoby dopier coś extra. Nareszcie można by było zapobiegać zawieszeniu się systemu bo Atmega ma WatchDoga a Windos Nie

mirekk36 wrote:

wow - wielkie dzięki kolego treker - tyle sklepów na necie przeszukałem a tego nie znalazłem ... odrazu kupuję - bo ostatnio po tych poszukiwaniach wydawało mi się, że ATtiny45 są już na "wymarciu"

Do szukania elementów polecam taki adres:
www.elecena.pl

Jdsoul wrote:

...Pisanie aplikacji opartej na komunikacji szeregowej na porcie COM pod Windows to tragedia , otwórz plik i pisz i czytaj z pliku, tworz wątki.

Do tego jeszcze cała konfiguracja portu buforowanie, ...

co do jednej rzeczy to kolega ma rację, ano można zastosować tani kabelek z allegro do telefonu - ale wadą tego jest brak powtarzalności dla swoich rozwiązań - często nie można akurat dostać dobrego kabelka albo trzeba kupić 6 żeby 2 okazały się przydatne - więc to rozwiązanie ma się jednak nijak do tego co zrobił Osamu Tamura to po pierwsze

a po drugie co to za herezje kolega opisuje powyżej - zacytowałem dokładnie - sorry ale to tak jakbym słyszał smerfa marudę, któremu wszystko przeszkadza. Tym bardziej pisanie aplikacji opartej na komunikacji przez port COM - to zgroza take bzdury wypisywać, że jest to ciężkie i złe - i raczej słabo świadczy o zdolnościach programistycznych kolegi. Bo do tego typu komunikacji przyzwyczaiło się już tysiące ludzi na świecie, są gotowe komponenty i rozwiązania itp itp itp .... o wiele gorzej jest na dzisiaj oprogramować wprost przez USB coś za pomocą różnorakich driverów dostarczanych przez różnych producentów. Skoro dla kolegi napisanie czegokolwiek co nadaje i odbiera przez RS232 to taki problem to wyobrażam sobie, iż obsługa USB programowo przez drivery jest już w ogóle poza zasięgiem kolegi i uważa ją kolega za kolejne nieporozumienie na świecie bo jest jeszcze bardziej skomplikowane i trudne. Tym bardziej, że tam to już naprawdę przydałoby się zastosować wątki - ale jak widzę wielu niedoświadczonych programistów podchodzi do wątków jak do wielkiego JEŻA nie mając pojęcia co dzięki nim można uzyskać - więc proszę dalej tak nie tłumaczyć bo to troszkę śmieszne

oczywiście kolega na zasadzie typowego (sorry za określenie) malkontenta odrazu chciałby to porównać do rozwiązań typu RS485 aby przesyłać na większe odległości.... ale jak to? to kolega jednak korzysta z obsługi transmisji szeregowej???? hmmm dziwne
a i tu gdybyś zadał sobie choć minimum trudu i zobaczył, że można spokojnie zrobić sterowanie większą ilością linii bo jest otwarty kod w C do tego projektu to już byś może inaczej troszkę mówił - ale oczywiście nikogo nie przekonuję do tego rozwiązania

jednak dyskutować warto rzeczowo a nie narzekać na wszystko na świecie i w jednej długiej wypowiedzi zaprzeczać samemu sobie

tym bardziej jeszcze raz podkerślam sam autor zwraca uwagę, że nie jest to w pełni profesjonalne rozwiązanie więc po co porównywać to z transmisją np przez RS485 czy może inną synchroniczną - no trochę bzdury

Quote:

Poza tym dość łatwo podłączyć go do procka i komputera i ciutkę mniej miejsca zajmie.

pewnie że dość łatwo ale coś koledze podpowiem, otóż ile razy podłączamy tego swojego procka i musimy dostarczać mu jakimiś zewnętrznymi kablami choćby zasilanie - zaczyna się plątanina a tu ??!!?? wszystko w jednym - i zasilanie (oczywiście układów o małym poborze mocy zwracam uwagę bo kolega za chwilę zapewne wskazałby wadę że nie można przez USB podłączyć silnika trójfazowego na 330V)

dobrze, że chociaż pod koniec swojego postu pozwolił sobie kolega na dostrzeżenie potencjału rozwiązania i na to co zrobił Osamu .... b jakby zwrócić uwagę to jego projekt wciąż się rozwija i jeszcze jakiś czas temu nie było aż takich możliwości jak teraz.

1. Prosta i szybka, łatwa instalacja w Windows - w oparciu o certyfikowane i standardowe sterowniki windy!
2. Przejrzysty i jasny a co ważne b szybki transfer nawet do 25600 !!! i stabilny wbrew pozorom
3. Maksymalna prostota pisania aplikacji pod windows do komunikacji przez RS ze swoim urządzeniem zarówno od strony windowsa jak i procka AVR (choćby w Bascomie)
4. Absolutna powtarzalność układu - działa szybko i pewnie

Dodano po 50 [sekundy]:

ooo a szczególne podziękowania znowu dla kolegi treker za elecenę - EXTRA !

Nie mam pojęcia o jakich gotowych komponentach do programowania portów szeregowych COM kolega wspomina Ale chętnie z nich skorzystam .

Co do rzeczonego otwierania pliku i zapisu i odczytu z pliku to tak to niestety w C++ pod Windę działa.

Może te "super" komponenty działają w "super" Visual Basicu lub Delphi - takie gotowe klasy jak sądzę wprost z M$. Mam nadzieję, że kolega rzeczywiście je już wyprobował i poznał słabe strony Windowsowego BCOM, bo ja niestety miałem tą nieprzyjemność wynikającą z rozdzielnia sprzętowego UARTU od aplikacji i straconych połączeń, nieudanych timeoutów etc.

Poprostu Windows od czasu do czasu lubi się sobą zająć i wtedy przerwania sprzętowe z portów COM nie są dla niego najważniejsze.

Co zaś się tyczy driverów USB, to niech kolega przeczyta.
Chodziło o jeden konkretny do Atmegi 8, 48, 88 i nie widzę tu nic zdrożnego, żeby był to ogólnie dostępny standard dla środowiska AVR, zawierający w sobie potencjał związany z SFR Atmegi dostępny dla programisty PC-ta. Naprawdę fajnie byłoby załadować Atmegę i załatwić wszystkie sprawy do których trzeba się teraz odwoływać przez MCI po swojemu.

Zaraz tam pisanie sterownika DirectX do Atmegi nie koniecznie.

Apropos to szkoda że jednak microsoft nie wypuścił DirectX do portów COM , LPT itd. Bezpośredni dostęp do sprzętu czasem czyni cuda

W końcu ktoś się dopatrzył i wrzucił na stronę główną...

Pytanie do mirkk'a:
czy ta konstrukcja może robić za pełnosprawny konwerter usb<=>rs232? pomijając oczywiście napięcia poziomów H/L po stronie RS'a (jest dla mnie jasne, że TTL zamiast +/- 15V) ale w przypadku mojej koncepcji jest to atut.

Po krótce o co mi chodzi:
otórz zajmuję się (amatorsko) sterownikami instalacji LPG (szczególnie swoim...) i aby dobrać się do komputera gazowego wykorzystuję aktualnie następujący zestaw 'młodego technika': laptop (bez RS'a) => przejściówka chińska USB-RS232 => interfejs (własnoręczna kopia oryginału za 12pln zamiast 280!!!) => komputer gazowy. Ten interfejs to zwykły MAX232, niezbędny ze względu na fakt, że procesor w komputerze lpg pracuje na 5V. Oczywiści mój dołączany RS jest widziany przez windę jako usb device, ale oprogramowanie serwisowe pracuje poprawnie.
Jednak rozwiązanie na M8 zdaje się być o wiele prostrze (jedna puszka mniej) tylko mam wątpliwości czy to zaskoczy...
Pzdr.

A tak przy okazji to stabilność pracy UARTU ściśle zależy od kwarca i od dokładności ustawienia dzielnika taktowania Uartu, akurat użyty w projekcie kwarc 12 MHz jest mało szczęśliwy bo daje dokładność rzędu 0,2% błędu taktowania już przy 9600 po stronie Atmegi.
To sprawia, że co któraś ramka musi się rozsynchronizować już przy tak małym błędzie, który rośnie do 8,5% przy prędkości 115 kB.

Tak więc jeśli, co któryś znak nie zsynchronizuje pan Atmegi ponownie, to pójdzie PC sobie a Atmega sobie .

Gdyby chciał Pan np. użycić tej wspaniałej przejściówki do przesłania pliku o długości 2048 znaków ( typowa zawartość pamięci wewnętrznej Flash układu AT89C2051) mógłby pan się mocno zdziwić efektami zaprogramowanego układu .

Nie neguję że wysłanie jednego lub dwóch znaków z terminala z prędkością 115 kB przejdzie bezbłędnie.

Dodano po 1 [minuty]:

To wynika z karty Atmega 8,

Jdsoul -> wspominałem o gotowych komponentach jak np CPort, lub tym podobnych dla początkujących programistów bo oczywiście nie ma to jak zrobić własną obsługę portu COM. Ja np przy okazji pisania aplikacji obsługującej modem GSM zrobiłem całkowicie własny komponent i działa mi wyśmienicie. Naprawdę nie ma co narzekać na biednego windowsa i na to że coś on lubi robić poza naszymi plecami. Takie sytuacje mamy wtedy gdy brak nam doświadczenia i ja zwykle gdy mi coś na początku nie wychodzi w programowaniu w tym środowisku to szukam przyczyn po swojej stronie a nie zarzucam całemu microsoftowi że zrbili kichę - i tym się różnimy.

odnośnie portu LPT też przecież można mieć bezpośredni dostęp - i ja oraz wielu ludzi z tego korzysta. Są programiki do tego pod windę albo znowu - można sobie pod czytym winapi oprogramować port LPT i też nie ma żadnych problemów. Więc chodzi mi tylko o to, że jak się nie zna metod to nie można mówić, że dane rozwiązanie nadaje się do .... no własnie ... trza szukać i się uczyć - ja spędziłem naprawdę sporo czasu zanim doszedłem do tego co umiem i nie żałuję. Np jeśli chodzi o procki to do tej pory programowałem tylko w asemblerze a teraz uczę się Bascoma i za chwilę C

Tylko co to za System Operacyjny w którym, żeby coś zrobić trzeba stosować całą gamę protez i sztuczek , nie dokońca udokumentowanych przez samego Producenta systemu

Dodano po 2 [minuty]:

Coś wspominałeś o różnych driverach, różnych producentów etc. niekompatybinych, ciekawe z czego się bierze problem , może M$ rozdaje różnym producentom różne "kody" dostepu do systemu i jeszcze, różne standardy w jednym Systemie Operacyjnym. Dziwne nie....[url][/url]