Elektroda.pl
Elektroda.pl
X
Arrow Multisolution Day
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Jak poradziłem sobie z brakiem portu równoległego

mdziewie 14 Lut 2018 22:41 8661 40
  • Jak poradziłem sobie z brakiem portu równoległego

    Dzień dobry,
    Długo mnie tu nie było, ale wreszcie trafił się drobiażdżek, który jest elektrodowalny...

    Jak dobrze wiemy, jednym z największych problemów XXI wieku jest właśnie ten, że dla oszczędzenia paru marnych juanów producenci komputerów postanowili pozbawić je portu równoległego, co większości z nas odbija się czkawką - i nie chodzi tu bynajmniej o możliwość podłączenia starej drukarki...
    Istnieją wprawdzie karty na PCI (jeśli mamy w domu skrzynkę), istnieją konwertery USB-coś-a'la-LPT, ale żadne z nich nie uraczą nas adresem bazowym 0x378 w przestrzeni I/O. A mówiąc już krótko i węzłowato - szanse, że taka przejściówka zadziała z oprogramowaniem/sprzętem niestandardowym - takim jak programatory pamięci czy mikrokontrolerów, sterowniki silników krokowych itd - są bliskie zeru.
    (Przy okazji -tutaj można znaleźć ciekawe, częściowe rozwiązanie problemu w przypadku kart PCI)

    Z tego też powodu od lat - obok laptopa, na którym normalnie pracuję - trzymałem skrzynkę, uruchamianą od wielkiego święta w celu zaprogramowania starego '51.
    Niestety, skrzynka dała ostatnio znać, że wiecznie działać nie będzie. I kiedy już zamierzałem wydać nieprzyzwoite pieniądze na nowy programator, urodził się w mojej głowie pomysł szalony.

    Otóż: Jeśli zapomnimy o naprawdę pradawnym oprogramowaniu i skupimy się nad tym, co działa pod Windowsem, to okaże się, że spora część tych programów (w tym większość darmowych, amatorskich i wszystkie moje) używa do obsługi LPT jednej z dwóch bibliotek:
    io.dll (Tutaj)
    tudzież:
    InpOut32.dll (Tutaj).
    Mniejsza z tym, jak one działają (więcej można poczytać np. pod powyższymi linkami) - istotne jest to, że udostępniają funkcje typu "pisz port" i "czytaj port", które umożliwiają bezpośredni dostęp do portów I/O procesora, a więc również bezpośrednie sterowanie portem równoległym.

    Pomysł: Zróbmy fałszywą bibliotekę, która ma taki sam interfejs (więc możemy po prostu podmienić plik .dll i wszystko będzie działać jak z oryginalną), ale nie odwołuje się ona do przestrzeni I/O procesora, ale do zewnętrznego urządzenia, które udaje port równoległy. Pozostaje zrobić urządzenie.





    Urządzenie zaś jest banalnie proste. Do udawania LPT zaprzęgłem mikrokontroler ATMega88 w obudowie DIP-28, który akurat mieści się w obudowie wtyczki DB-25. Mikrokontroler zaś komunikuje się z komputerem przez... port szeregowy:) A dokładniej - użyłem przejściówki pewnego znanego producenta przejściówek, a jeszcze dokładniej - TTL-232R-5V od FTDI.

    Schemat urządzenia wygląda tak:
    Jak poradziłem sobie z brakiem portu równoległego
    Funkcje nóżek zostały tak zaprojektowane, aby ułatwić połączenie mikrokontrolera z gniazdem portu - właściwie cała jedna strona układu łączy się bezpośrednio z kolejnymi wyprowadzeniami gniazda. Dzięki temu mogłem zrezygnować z płytki i z zachowaniem jako takiej gracji zlutować wszystko "na pajęczynę".
    Jak poradziłem sobie z brakiem portu równoległego
    Lista galanterii zewnętrznej zawiera jeden element - kondensator 10µF.
    Po włożeniu do pudełka wygląda to tak:
    Jak poradziłem sobie z brakiem portu równoległego

    Przejściówka udaje port równoległy w wersji SPP/Bidirectional, natomiast w obecnej wersji nie ma możliwości "odwrócenia" linii kontrolnych (ba, dopiero niedawno dowiedziałem się, że taka możliwość w ogóle występuje w niektórych portach). Zapis/odczyt adresów innych niż bazowy/+1/+2 (czyli np. konfiguracji ECP) jest ignorowany.
    Co więcej można dodać?... Działa! Laptop, windows 10, 64 bity, obsługuje mój stary programator! Z mieszanymi uczuciami ulgi i nostalgii mogę się rozstać ze skrzynką...

    Projekt jest prosty do skopiowania i będę rad, jeśli komuś z Forumowiczów się on przyda. Niemniej trzeba pamiętać, że posiada on pewne...

    Wady: W zasadzie istotne są dwie:
    1. Przejściówka działa tylko pod Windowsem (ale za to jakimkolwiek!*) i tylko z programami wykorzystującymi w/w dwie biblioteki.
    2. W porównaniu z prawdziwym portem, urządzenie jest przynajmniej 10-krotnie wolniejsze. I - niestety - jest to kwestia nie tylko "wąskiego gardła" transmisji szeregowej, ale również sposobu organizacji transmisji przez USB.
    *czyt. "Jakimkolwiek obsługującym USB, chyba że nie użyjemy USB"


    Kilka szczegółów dla tych, którzy jednak chcieliby zbudować kopię mojego układu:

    Urządzenie może współpracować z układem FTDI, tak jak ja to zrobiłem, bądź z dowolną inną przejściówką lub nawet zwykłym (prawdziwym) portem szeregowym - w przypadku komunikacji na poziomach RS-232 potrzebny jest oczywiście konwerter poziomów i zewnętrzne zasilanie.
    Standardowo port szeregowy pracuje przy szybkości 1 Mbps, którą można zmienić bez ingerencji w kod oprogramowania za pomocą pinów konfiguracyjnych (PD6=12, PD7=13). Podłączenie ich w odpowiedniej konfiguracji do masy spowoduje ustawienie jednej z predefiniowanych prędkości transmisji:







    PD6PD7Baudrate[kbps]
    GNDGND115,2
    wolnyGND250
    GNDwolny500
    wolnywolny1000
    Trzeba pamiętać, aby nastawy prędkości zmienić również w konfiguracji biblioteki (opisane niżej).

    W moim wykonaniu mikrokontroler nie ma wyprowadzonego złącza do programowania. Większość potrzebnych sygnałów znajduje się na złączu DB-25, a dwa brakujące (RST i +5V) podłączane są bezpośrednio do nóżek mikrokontrolera na czas programowania - tak jak na obrazku:
    Jak poradziłem sobie z brakiem portu równoległego

    Biblioteka udostępnia interfejsy obu wymienionych wyżej (io.dll, InpOut32.dll), tzn. funkcje następujące:
    Dla io.dll:
    Kod: c
    Zaloguj się, aby zobaczyć kod

    Dla InpOut32.dll:
    Kod: c
    Zaloguj się, aby zobaczyć kod


    Jeśli nasz program używa io.dll, po prostu kopiujemy naszą bibliotekę do katalogu, w którym jest plik .exe programu.
    Jeśli program używa InpOut32.dll... zmieniamy nazwę naszej biblioteki na taką właśnie, a potem jak wyżej.
    Tej drugiej póki co nie przetestowałem, więc proszę o solidny OPR, gdyby coś było nie tak...

    Do szczęścia potrzebny jest jeszcze plik konfiguracyjny, znajdujący się w tym samym katalogu co program, zatytułowany io.conf i wyglądający np. następująco:
    Kod: dos
    Zaloguj się, aby zobaczyć kod

    "0" w pierwszej linii to wyłącznik konsoli debugującej - jeśli zmienimy je na "1", to wraz z załadowaniem biblioteki otwarte zostanie okno konsoli z informacjami diagnostycznymi.
    Druga linia to konfiguracja portu: pierwsza liczba (378) oznacza adres bazowy w kodzie szesnastkowym, druga (9) to numer portu COM używanego przez naszą przejściówkę, trzecia (1000000) to prędkość transmisji, a czwarta (100) to magiczna liczba określająca przeplot we/wy. Nie wnikając w szczegóły - ustawienie jej na 1 wymusza rzeczywistą synchronizację wykonania programu z faktycznymi zmianami stanu portu. Ustawienie na wartość wyższą umożliwia kolejkowanie danych, co nieco przyspiesza działanie urządzenia, ale pozbawia nas ścisłej synchronizacji (program może myśleć, że wykonał jakąś operację na porcie, podczas gdy ona w rzeczywistości jeszcze oczekuje na przepchnięcie przez port szeregowy).
    Jeśli chcemy podłączyć więcej przejściówek, drugą linię można powielić, przypisując kolejnym portom inne adresy bazowe.
    W każdym przypadku musimy pamiętać, że nasza biblioteka - w przeciwieństwie do "oryginałów" nie udostępnia przestrzeni I/O procesora, więc w hipotetycznym przypadku, jeśli program używa portu równoległego i czegoś jeszcze z przestrzeni I/O, nasza biblioteka nie zadziała. Niemniej jest to problem do przeskoczenia i proszę o informację, gdyby ktoś takowy problem napotkał.

    W załącznikach znajdują się wszystkie potrzebne pliki:
    io.hex - wsad do mikrokontrolera
    io_dll.zip - skompilowana biblioteka plus przykładowy plik konfiguracyjny
    Dla tych, którzy chcą podrążyć głębiej, udostęniam kody źródłowe - odpowiednio io_atmega.zip i io_pc.zip.

    Na koniec, jak to mówią, dziękuję za uwagę i zapraszam do dyskusji:)


    Fajne!
  • Arrow Multisolution Day
  • #3 15 Lut 2018 10:15
    byrrt
    Poziom 21  

    Czy kolega zdaje sobie sprawę że są gotowe przejściówki z USB na LPT? :) Nawet FTDI ma takie w swojej ofercie - chociażby FT245R :)

  • #4 15 Lut 2018 10:59
    mdziewie
    Poziom 18  

    @kranzio: Nie taki znowu większy ten koszt; rzeczony scalak Cypressa kosztuje coś koło 50 zł, więc do przełknięcia... Zresztą, na koszcie mi specjalnie nie zależało (przejściówka FTDI kosztowała mnie 70 złotówek, chociaż bez większego wysiłku da się tę kwotę zmniejszyć do około 7), ale raczej na szybkości załatwienia sprawy.

    Trzeba swoją drogą przyznać, że projekt pana Haftmanna jest boski. I trzeba również przyznać, że nielicho się przy nim narobił.
    Przy okazji, tu jest link do oryginału: https://www-user.tu-chemnitz.de/~heha/basteln/PC/USB2LPT/

    @byrrt:
    FT245 niestety NIE jest portem równoległym w sensie LPT. Jest przejściówką z USB na równoległy interfejs FIFO i "przerobienie" go na port LPT również wymaga dodatkowej elektroniki. Pierwszy raz użyłem tego scalaka ponad 10 lat temu, więc wiem:)

  • #5 15 Lut 2018 12:37
    3099750
    Użytkownik usunął konto  
  • #6 15 Lut 2018 17:21
    waleryfw
    Poziom 13  

    Ja mam pytanie może trochę dziwne jak napiszą pewni "fachowcy" . Czy taka przejściówka może być wykorzystana do programów CNC działających na LPT. Chociażby program Mach lub podobne

  • #7 15 Lut 2018 17:51
    mdziewie
    Poziom 18  

    waleryfw napisał:
    Czy taka przejściówka może być wykorzystana do programów CNC działających na LPT. Chociażby program Mach lub podobne


    Otóż to jest bardzo dobre pytanie. Zasadniczo odpowiedź brzmi "nie albo z trudem".
    Trzeba pamiętać o dwóch ograniczeniach:
    1. Moja przejściówka działa tylko z programami, które używają jednej z dwóch wymienionych bibliotek. Mach, o ile wiem, używa czegoś swojego. Ten problem "prawie na pewno" da się obejść, używając bardziej skomplikowanej przejściówki, która była wspomniana wcześniej w tym wątku, a która współpracuje z własnym sterownikiem, dość barbarzyńsko ale i dość skutecznie oszukującym komputer.
    2. Zarówno moja przejściówka jak i ta druga są zdecydowanie wolniejsze niż prawdziwy port LPT. Nie jest to ścisła przeszkoda, ale jednak poważne utrudnienie. Przy prostych sterownikach bez mikrokroku i przy małych prędkościach idzie przeżyć, ale CNC to jednak zazwyczaj inny poziom wymagań...

    Ogólnie - przejściówka działa raz szybciej a raz wolniej, przeważnie wolniej - ale w zastosowaniach czasu rzeczywistego (takich jak CNC) najgorsze jest to, że czas jej reakcji jest nieprzewidywalny... Dlatego ogólnie tendencja jest taka, żeby owszem przesiadać się na USB czy Ethernet, ale tylko z pomocą dedykowanych kontrolerów. Wiem, że to kosztuje...

    Odnośnie drugiego pytania, żeby nie mnożyć postów - do Macha ja nic nie mogę polecić, niech się wypowiedzą znawcy Macha;)

  • #8 15 Lut 2018 18:10
    waleryfw
    Poziom 13  

    OK dzięki koledzy . W takim razie co polecacie jako konwerter USB/LPT . Bo są dostępne karty na PCI do komputera stacjonarnego , droższe /tańsze . która by pasowała do np: Macha

  • #9 15 Lut 2018 18:22
    zgierzman
    Poziom 18  

    waleryfw napisał:
    OK dzięki koledzy . W takim razie co polecacie jako konwerter USB/LPT . Bo są dostępne karty na PCI do komputera stacjonarnego , droższe /tańsze . która by pasowała do np: Macha

    Rozejrzeć się za laptopem z LPT. Na Alle wpisz "Laptop LPT" i wyskoczą ci szroty po parę zł i "specjalnie dla serwisów samochodowych" po parę stów. Teraz zajrzałem i jest jeden sprawny COMPAQ za 100 zł.
    Ja kupiłem niedawno jeszcze taniej - trzeba poszukać.

    Wątpię żebyś znalazł taniej przejściówkę, taką bez rzeźbienia, readresacji portów i innych dziwnych zabiegów.

  • #10 15 Lut 2018 18:23
    bodzio667
    Poziom 18  

    A może by to przepisać na procesor PIC z sprzętowym USB ? Prędkość znacznie by wzrosła.

  • Arrow Multisolution Day
  • #11 15 Lut 2018 18:30
    zgierzman
    Poziom 18  

    bodzio667 napisał:
    A może by to przepisać na procesor PIC z sprzętowym USB ? Prędkość znacznie by wzrosła.


    Nie wiem co powie autor wątku o swoim projekcie, ale ten z linku oparty jest na procesorze ze sprzętowym USB High Speed. I napisane jest, że działa 10 - 100 razy wolniej od prawdziwego portu.

  • #12 15 Lut 2018 18:35
    mdziewie
    Poziom 18  

    zgierzman napisał:
    Rozejrzeć się za laptopem z LPT.

    Zgadzam się z Kolegą, ale przez wrodzoną up...dliwość będę trochę polemizował;)
    Stare komputery mają to do siebie, że działają, działają, a potem już nie działają... i trzeba szukać następnego. Dlatego rozumiem tęsknotę ludzkości za przejściówką, która by wreszcie działała...
    W końcu dlatego zrobiłem swój projekt, żeby pozbyć się starego, niepewnego komputera.

    bodzio667 napisał:
    A może by to przepisać na procesor PIC z sprzętowym USB ? Prędkość znacznie by wzrosła.

    Można przepisać na dowolny procesor ze sprzętowym USB, ale prędkość nie wzrośnie znacznie. Problem z USB jest taki, że może przepychać duże ilości danych, ale... nie kiedykolwiek. Pakiety muszą być zsynchronizowane z mikroramką i właśnie z tej przyczyny, jeśli chcemy coś odczytać z USB, to możemy to zrobić nie częściej niż 8 tysięcy razy na sekundę (vs milion albo 8 milionów w przypadku prawdziwego portu).
    Jeśli mamy tylko zapisy, to można oczywiście w ramkę wepchnąć więcej zapisów (i tak się dzieje), ale i tak pierwszy z nich poczeka do najbliższej mikroramki, a reszta ruszy lawinowo za nim... Gdzie tu praca w czasie rzeczywistym?

  • #13 15 Lut 2018 18:51
    zgierzman
    Poziom 18  

    mdziewie napisał:
    Stare komputery mają to do siebie, że działają, działają, a potem już nie działają... i trzeba szukać następnego. Dlatego rozumiem tęsknotę ludzkości za przejściówką, która by wreszcie działała...

    Ano tak. Tęsknią, ale wydaje mi się, że realizacja tego marzenia nie będzie możliwa - z powodów które sam podałeś ;-)

    mdziewie napisał:
    W końcu dlatego zrobiłem swój projekt, żeby pozbyć się starego, niepewnego komputera.

    Ale nie zaspokoi wielu potrzeb których Ty nie masz.
    Programator będzie działał wyraźnie wolniej - cóż, kilka/naście/dziesiąt sekund może się wydłużyć nawet do minut. Z tym da się żyć.
    Ale nie będą działały sterowniki maszyn. zabezpieczenia typu "dongle", itp. A z tym gorzej.
    Nowa licencja na jakiś specjalistyczny soft może kosztować małą fortunę. Ale przyjdzie z "donglem" USB ;-)
    Nowe CNC też może nie być tanie.
    A stary laptop jest tani - można położyć na półce nawet kilka takich i wymieniać w razie potrzeby.

    Stare sprzęty mogą działać nadspodziewanie długo - mam laptopa jeszcze z XX wieku - rok produkcji ok 1999. Działa do dzisiaj bez miałczenia (nie licząc baterii).

  • #14 15 Lut 2018 19:05
    3099750
    Użytkownik usunął konto  
  • #15 15 Lut 2018 19:14
    mdziewie
    Poziom 18  

    zgierzman napisał:
    Ale nie zaspokoi wielu potrzeb których Ty nie masz.

    Ale stary laptop nie zaspokoi wielu potrzeb, których Ty nie masz:)

    A tak całkiem serio, to nawet zajrzałem na popularny serwis aukcyjny, czy by jednak czegoś nie kupić na zaś (jakby mało mi było tej sterty, która leży w garażu). Jednak za coś, co nosi znamiona użytkowalności (ma RAM, twardy dysk itd.) trzeba dać kilkaset złotych... Myślę (choć ręki pod topór nie podłożę), że amator CNC za te pieniądze może kupić kontroler na USB i będzie to dużo lepsze wyjście.

    Ale ogólnie pełna zgoda - żadne rozwiązanie nie jest uniwersalne, a idealna przejściówka rzeczywiście nie istnieje i jak zwykle powodem jest to, że źli ludzie prawie 40 lat temu zdecydowali się na procesor Intela, zamiast po Bożemu wybrać Motorolę 68k :D

  • #16 15 Lut 2018 19:26
    zgierzman
    Poziom 18  

    mdziewie napisał:
    Jednak za coś, co nosi znamiona użytkowalności (ma RAM, twardy dysk itd.) trzeba dać kilkaset złotych...


    Na "popularnym portalu" wklep HP COMPAQ NC8000
    Jest jeden sprawny za 100 zł. To przykład, znaleziony w minutę przy pisaniu poprzedniego posta.
    Jak się poszuka dłużej, to znajdą się sprawne maszyny poniżej tej kwoty. Jak nie dziś, to jutro... ;-)

  • #17 15 Lut 2018 19:48
    lvy
    Poziom 11  

    AnicoZ napisał:
    waleryfw napisał:
    OK dzięki koledzy . W takim razie co polecacie jako konwerter USB/LPT . Bo są dostępne karty na PCI do komputera stacjonarnego , droższe /tańsze . która by pasowała do np: Macha

    Stacje dokujące maja LPT.

    dokładnie!
    taki dell E7450 ze stareńką stacja dokującą PR02X E-Port albo nowszą Dell Legacy Expansion Port 452-10776 ma natywny sprzetowy LPT
    z tego co pamiętam na 6400 na starszej stacji można było z powodzeniem używać programatorów do AVR złożonych z kilku rezystorów, więc do macha tez powinna dać radę. Póki dell nie ubije swojego expansion porta to raczej te rozwiązanie będzie ciągle dostępne dla nowego sprzętu.

  • #19 15 Lut 2018 19:56
    mdziewie
    Poziom 18  

    waleryfw napisał:
    OK dzięki koledzy . W takim razie co polecacie jako konwerter USB/LPT . Bo są dostępne karty na PCI do komputera stacjonarnego , droższe /tańsze . która by pasowała do np: Macha


    No to, kontynuując dyskusję z kolegą Zgierzmanem, laptop za 100 złotych albo sterownik CNC np. z popularnego serwisu z chińszczyzną za 37 dolarów.
    Kto co lubi:)

    wniedzie napisał:
    115kbps to za mało.

    Mniej więcej dlatego standardowo COM pracuje przy 1 Mbps (więcej Atmega nie pociągnie), co pozwala się rozpędzić teoretycznie do 100 kHz. Ale, jak już pisałem, nie to stanowi rzeczywisty problem, a rozrzuty czasowe dorzucane przez USB i ewentualnie przez system operacyjny.

    Freddy napisał:
    jak to liczysz, że Ci wychodzi 115<25? :D

    Bo trzeba umieć jeszcze dzielić. 115/(1+8+1) < 25 :)

  • #20 15 Lut 2018 19:57
    Freddy
    Poziom 43  

    wniedzie napisał:
    Mach korzysta z "taktowania" portu równoległego z prędkością 25kHz, o ile dobrze pamiętam. 115kbps to za mało.
    Skąd masz takie rewelacje i jak to liczysz, że Ci wychodzi 115<25? :D
    Po drugie mylisz pojęcia, bo określenie 115kbps dotyczy portu UART, a nie SPP, czy też EPP.
    PO trzecie ustawienie 25kHz to jest tzw. kernel speed (szybkość jądra) czyli najprościej mówiąc - dla 25kHz to 25000 kroków/sec. Czym większe ustawienie, tym większe wymaganie dla procesora.

  • #21 15 Lut 2018 20:49
    wniedzie
    Poziom 13  

    Freddy napisał:
    Po drugie mylisz pojęcia, bo określenie 115kbps dotyczy portu UART, a nie SPP, czy też EPP.

    W tym projekcie następuje zamiana jednego na drugie, więc argument nietrafiony.

    Freddy napisał:
    PO trzecie ustawienie 25kHz to jest tzw. kernel speed (szybkość jądra) czyli najprościej mówiąc - dla 25kHz to 25000 kroków/sec. Czym większe ustawienie, tym większe wymaganie dla procesora.

    Czy nie jest czasem tak, że Mach non-stop zapisuje stan portu LPT właśnie z tą prędkością? Jutro postaram się to sprawdzić i dać znać.

    BTW. Właśnie wyczytałem, że Mach 3 ma możliwość zmiany prędkości jądra nawet do 100Khz.

  • #22 15 Lut 2018 20:56
    gimak
    Poziom 37  

    byrrt napisał:
    Czy kolega zdaje sobie sprawę że są gotowe przejściówki z USB na LPT? :)

    A jest Kolega pewien, że będą działać pod 8.1 lub 10. Jestem zainteresowany nabyciem takiej przejściówki.
    Mam takie dwie przejściówki i działają bardzo dobrze na komputerach z XP, ale nie działają już pod 8 i 8.1. Niby nie wymagają żadnych sterowników, ale okazuje się, że pierwsza przejściówka powinna działać jeszcze pod 7, a druga kupiona bo miała działać pod 8.1, podobno działa jeszcze pod Vistą.

  • #23 16 Lut 2018 03:09
    rb401
    Poziom 33  

    mdziewie napisał:
    Można przepisać na dowolny procesor ze sprzętowym USB, ale prędkość nie wzrośnie znacznie.


    Ale tak się świetnie składa że akurat istnieje proste, tanie, łatwo dostępne rozwiązanie, które upraszcza Twój hardware do minimum. I to bez większego wysiłku.
    Chodzi o pospolitą płytkę "Blue pill" STM32F103C8T6 dostępną byle gdzie za kilkanaście zł.
    Plus oprogramowanie z mbed, które dostarcza praktycznie już gotowca pod Twoja koncepcję (funkcje nadawania i odbioru znaku przez USB jako CDC).
    Oglądałem Twoje źródła na Atmega i widzę że jedyną rzeczą do zrobienia była by modyfikacja modułu lpt.c by sterować pinami STM32. A do wyboru jest w mbed kilka metod ich obsługi, od wygodnych wirtualnych pinów i magistral, poprzez sterowanie za pomocą biblioteki HAL do prostego dostępu do rejestrów sprzętowych (których obsługa nie jest jakoś specjalnie trudniejsza niż w AVR).
    Moduł serial stałby się niepotrzebny, bo w zamian za Twoje serial_get() i serial_put() wykorzystane by były funkcje udostępniane przez bibliotekę USBDevice_STM32F103 (_getc() i _putc() z USBSerial/USBSerial.h).

    Tu jest link do przykładowego użycia tej płytki w roli CDC. Co prawda co innego te demo robi ale to nieistotne bo pokazuje prostotę wykorzystania tej biblioteki:
    https://os.mbed.com/users/hudakz/code/STM32F103C8T6_USBSerial/

  • #24 16 Lut 2018 07:36
    Freddy
    Poziom 43  

    wniedzie napisał:
    BTW. Właśnie wyczytałem, że Mach 3 ma możliwość zmiany prędkości jądra nawet do 100Khz.
    To jest kernel speed. Ty musisz czytać o tym, a ja sprawdzam w programie na maszynie.
    Cytat:
    5.2.2 Choosing Kernel Speed
    The Mach3 driver can run at frequencies from 25,000 Hz (pulses per second) up to 100,000 Hz, depending on the speed of your processor and other loads placed on it when running Mach3.
    The frequency you need depends on the maximum pulse rate you need to drive any axis at its top speed. 25,000 Hz will probably be suitable for stepper motor systems.
    With a 10 micro-step driver such as a Gecko 201, you will get around 750 RPM from a standard 1.8 degree stepper motor with a 25,000 Hz pulse rate. Higher pulse rates are needed to achieve desired motor RPM for servo drives that
    have high resolution shaft encoders on the motor. Further details are given in the section on motor tuning and in Section 4.4.2, Determining Axis Drive Requirements.
    Computers with a 1 GHz clock speed will almost certainly be able to run at 35,000 Hz, so you can choose this if you need a high step rate (for example, if you have very fine pitch lead screws).
    The demonstration version of Mach3 will run at 25,000 Hz only. In addition, if Mach3 is forcibly closed, then on re-start it will automatically revert to 25,000 Hz operation.
    The actual frequency of the running system is displayed on the standard Diagnostics screen.
    Click the box next to the desired kernel speed.


    @mdziewie Dlaczego robisz takie kombinacje, a nie od razu USB do procesora?
    @mdziewie Dlaczego odpowiadasz na mój post we wcześniejszym poście? To jest nie w porządku i nielogicznie - odpowiedź powinna być pod pytaniem :)

  • #25 16 Lut 2018 12:22
    mdziewie
    Poziom 18  

    Freddy napisał:


    @mdziewie Dlaczego robisz takie kombinacje, a nie od razu USB do procesora?

    Właśnie po to, żeby nie robić kombinacji. FTDI jest absolutnie wyjątkowym przykładem urządzenia, które podłączasz i działa. Na każdym komputerze i z dowolnym systemem operacyjnym*.
    Bawiłem się w USB na STM; wiem, że są biblioteki i również wiem, jakiej są jakości:( Dobra, wprawdzie jestem genialny, ale nie ogarnąłbym sprawy w trzy popołudnia, tak jak ogarnąłem.
    No i znajdź mi STMa w dipie :D
    Mam nadzieję, że odpowiedziałem również na komentarz Kolegi rb401.
    *patrz pierwszy post

    Freddy napisał:
    @mdziewie Dlaczego odpowiadasz na mój post we wcześniejszym poście? To jest nie w porządku i nielogicznie - odpowiedź powinna być pod pytaniem :)


    Przepraszam. Nie chciałem sobie nabijać postów tą w sumie prywatną dyskusją. Ale skoro zostałem zrugany, to już nic nie stoi na przeszkodzie :D


    Może ustosunkuję się jeszcze wspólnie do wszystkich komentarzy z grupy "a mogłeś użyć takiego procesora albo takiej płytki" - oczywiście, mogłem :D Uważam, że wszystkie proponowane przez Kolegów rozwiązania są funkcjonalnie bardzo zbliżone. Każdy używa tego, co lubi:) No, mam pewne opory przed używaniem płytek uruchomieniowych, bo to zawsze się kończy plątaniną kabli. Wykorzystałem w sumie to, co leżało pod ręką (z pewnym naciskiem na możliwość zmieszczenia się we wtyczce) i nie widzę, żeby to rozwiązanie było wyraźnie lepsze albo wyraźnie gorsze od innych. Na pewno było szybkie w wykonaniu;)
    Natomiast w ogóle uważam, że to nie elektronika stanowi sedno tego projektu. Sedno stanowi koncepcja podmiany bibliotek, co pozwala ominąć problem sterowników i w ogóle interakcji z systemem operacyjnym. To daje pewną nadzieję na większą żywotność rozwiązania (nie przestanie nagle działać po którejś aktualizacji Windowsa).
    Elektronikę (gdyby kto chciał skopiować projekt) można sobie wykonać taką lub inną - oczywiście wykonując tę według mojego schematu, można uniknąć pisania własnego wsadu.

  • #26 16 Lut 2018 16:26
    rb401
    Poziom 33  

    mdziewie napisał:
    Mam nadzieję, że odpowiedziałem również na komentarz Kolegi rb401.


    Ok. Tylko chciałbym podkreślić że nie było moją intencją dyskredytowanie Twojego projektu w szczegółach wykonania a tylko zwrócenie uwagi na pewien istniejący zbieg okoliczności że akurat istnieje tani i dostępny gotowiec, zarówno od strony hadware jak sofware, który mógłby być wygodniejszą alternatywą części sprzętowej Twojego projektu (zgodnie z filozofią zrobić a się nie narobić), szczególnie wobec proponowanych rozwiązań jak np. na CY7C68013A czy PIC.
    I też osobiście uznaję (jak sam również podkreślasz) za największą wartość Twojego to ten numer z preparacją dll. A to jak to będzie konkretnie sprzętowo zrealizowane już od poziomu USB to kwestia raczej poboczna. Ale Twój wkład pracy w części dekodującą (jasne, czytelne źródła) jest również bardzo wartościowy bo to co tu opisałeś stanowi kompletną, działającą całość.

  • #27 16 Lut 2018 16:32
    Freddy
    Poziom 43  

    mdziewie napisał:
    Właśnie po to, żeby nie robić kombinacji
    Słyszałeś o vUSB?
    https://www.obdev.at/products/vusb/prjinterface.html#33
    https://www-user.tu-chemnitz.de/~heha/basteln/ to działa i to bez problemów i kombinacji :)

  • #28 16 Lut 2018 17:40
    mdziewie
    Poziom 18  

    @rb401: Chyba poczułeś, że poczułem się urażony :D
    Nie, nie poczułem - uważam, że takie wpisy jak Twój są jak najbardziej pożądane i cenne w dyskusji. Wątek ma mieć wartość dydaktyczną i jest świetnie, jeśli użytkownicy mogą się zapoznać z różnymi podejściami do rozwiązania problemu.
    A elektronika właśnie dlatego jest sztuką, że problemy można rozwiązywać na przeróżne sposoby - czasem proste, czasem barokowe, a czasem iście zawadiackie:)
    A ja... po prostu nie chciałbym, żeby wątek stał się polem walki miłośników l.p. Atmela z miłośnikami ST czy jeszcze Microchipa.

  • #29 17 Lut 2018 10:39
    mkpl
    Poziom 37  

    Przejściówka jak przejściówka ale sposób montażu jak dla mnie genialny. Ja bym już kombinował z PCB itp jak to upchnąć a tu dip idealnie spasował.

  • #30 17 Lut 2018 12:09
    mdziewie
    Poziom 18  

    mkpl napisał:
    Przejściówka jak przejściówka ale sposób montażu jak dla mnie genialny. Ja bym już kombinował z PCB itp jak to upchnąć a tu dip idealnie spasował.


    Przyznam się, że też na początku kombinowałem z PCB;) No dobra, ze względu na czas myślałem o uniwersalnej... Z tego też względu od razu odpuściłem sobie opcję SMD. A już pierwsza przymiarka DIP-a pokazała, że z płytką "nie wlyzie"...

    Żeby nie było tak różowo - może nie wszyscy zdają sobie z tego sprawę, ale rozstaw pinów w złączach D-Sub nie wynosi 2.54mm, tylko ciut więcej... W rzeczywistości, na 14 nóżek obudowy przypada 13 nóżek złącza. Dlatego nóżki zostały dość zmyślnie powyginane, czego nie widać na zdjęciach.
    Największe wygięcia wypadłyby w środku, ale tutaj i tak ATMega ma nogi zasilające, więc połączenia poszły kabelkami z drugiej strony układu;)
    Właściwie schemat ideowy dosyć wiernie oddaje rzeczywistą mechanikę połączeń.