timing petli synchronicznie 100kHz
Manolo - 21-06-2006 00:52
timing petli synchronicznie 100kHz
Witam,
Kiedys juz poruszalem podobny temat (synchroniczne wykonywanie petli) i ktos
z szanownych grupowiczow poddal pomysl, sterowania z poziomu hardware
(jednym z 3 timerow znajdujacych sie na plycie glownej) wykonywaniem prostej
petli,z czestotliwoscia rzedu do 100kHz, ktora to petla bedzie wystawiala
odpowiednie wyliczone stany na kilku liniach LPT'a.
Dlatego taki timer hardware'owy, odpowiednik Builderowskiego eventu OnTimer
bylby bardzo odpowiedni,tylko czy to ma szanse dzialac pod Windowsem? I jak
sie do niego dobrac? Skoro steruje czyms, to czy mozna go sobie swobodnie
przeprogramowac i wykorzystac?
A moze sa inne sposoby?
Z goey dziekuje za odpowiedzi.
Pozdrawiam
=?ISO-8859-2?Q?Piotr_Ni=BFy=F1ski?= - 21-06-2006 00:52
Manolo napisał(a):
> Dlatego taki timer hardware'owy, odpowiednik Builderowskiego eventu OnTimer
> bylby bardzo odpowiedni,tylko czy to ma szanse dzialac pod Windowsem?
Te timery są w użyciu przez system. Sugeruję raczej mierzyć czas przy
pomocy instrukcji RDTSC (1F 30 ZTCP -> licznik taktów CPU w EDX:EAX)
mnisiuk - 21-06-2006 00:52
Manolo wrote:
> Witam,
> Kiedys juz poruszalem podobny temat (synchroniczne wykonywanie petli) i ktos
> z szanownych grupowiczow poddal pomysl, sterowania z poziomu hardware
> (jednym z 3 timerow znajdujacych sie na plycie glownej) wykonywaniem prostej
> petli,z czestotliwoscia rzedu do 100kHz, ktora to petla bedzie wystawiala
> odpowiednie wyliczone stany na kilku liniach LPT'a.
> Dlatego taki timer hardware'owy, odpowiednik Builderowskiego eventu OnTimer
> bylby bardzo odpowiedni,tylko czy to ma szanse dzialac pod Windowsem? I jak
> sie do niego dobrac? Skoro steruje czyms, to czy mozna go sobie swobodnie
> przeprogramowac i wykorzystac?
> A moze sa inne sposoby?
> Z goey dziekuje za odpowiedzi.
> Pozdrawiam
>
>
W miarę synchronicznie to będzie na przerwaniu, ale Windows nie jest
systemem czasu rzeczywistego i nie ma gwarantowanego czasu na obsługę
przerwania = nierównomierne opóźnienia. Poza tym przerwania obsługuje
driver w trybie jądra, podczas obsługi przerwania raczej nie można
poszaleć bo czas obsługi musi być krótki. Dostarczanie informacji o
przerwaniach do user mode (czyli do normalnej aplikacji) to dalsze
opóźnienia (liczone już w milisekundach) co dyskwalifikuje pracę z
częstotliwością 100 khz. Obsługa przerwań z częstotliwością 100 kHz
(parę mikrosekund na przerwanie) jest możliwa, ale raczej na granicy
możliwości systemu. Jednym słowem raczej pomyśl o jakimś specjalizowanym
układzie który będzie generował odpowiednie sygnały na wyjściu +
ewentualnie sterowanie tym układem z aplikacji Windows.
mnisiuk
Bernard - 22-06-2006 01:06
Manolo wrote:
> Witam,
> Kiedys juz poruszalem podobny temat (synchroniczne wykonywanie petli) i ktos
> z szanownych grupowiczow poddal pomysl, sterowania z poziomu hardware
> (jednym z 3 timerow znajdujacych sie na plycie glownej) wykonywaniem prostej
> petli,z czestotliwoscia rzedu do 100kHz, ktora to petla bedzie wystawiala
> odpowiednie wyliczone stany na kilku liniach LPT'a.
> Dlatego taki timer hardware'owy, odpowiednik Builderowskiego eventu OnTimer
> bylby bardzo odpowiedni,tylko czy to ma szanse dzialac pod Windowsem? I jak
> sie do niego dobrac? Skoro steruje czyms, to czy mozna go sobie swobodnie
> przeprogramowac i wykorzystac?
> A moze sa inne sposoby?
> Z goey dziekuje za odpowiedzi.
> Pozdrawiam
To się nie da. Nie uzyskasz deterministycznej odpowiedzi programowej w
czasie 10 us. Potrzebujesz urządzenia mikroprocesorowego podłączonego
np. do USB, które na podstawie poleceń z PC będzie generowało
odpowiednią sekwencję sygnałów. Robię podobne zabawki, gdybyś był
zainteresowany.
Manolo - 22-06-2006 01:06
Użytkownik "Piotr Niżyński" <adx@bezduszni.pl> napisał w wiadomości
news:e79f3o$sro$1@atlantis.news.tpi.pl...
> Manolo napisał(a):
>> Dlatego taki timer hardware'owy, odpowiednik Builderowskiego eventu
>> OnTimer bylby bardzo odpowiedni,tylko czy to ma szanse dzialac pod
>> Windowsem?
>
> Te timery są w użyciu przez system. Sugeruję raczej mierzyć czas przy
> pomocy instrukcji RDTSC (1F 30 ZTCP -> licznik taktów CPU w EDX:EAX)
Witam wszystkich,
dzieki za odpowiedzi. Jednak sa programy,ktore synchronicznie steruja przez
LPT silnikami krokowymi,i to z czestotliwoscia rzedu 50kHz, spod Windowsa,
jak i spod DOSa (te wykorzystuja timer z plyty glownej,jak sobie radza
Windowsowe- nie wiem).
Bardzo ciekawa jest instrukcja RDTSC, szkoda tylko ze czas zalezy od
taktowania procesora. No i gdybym chcial na 1GHz procesorze osiagnac moje
10us,musialbym sprawdzac kiedy zawartosc EDX:EAX zwiekszy sie o 10000, ale
takie liczenie zapchaloby chyba calkiem procesor, o ile sie nie myle
(wielopotokowosc?jakos sprytniej sie da?)?No i w jaki sposob wywolac co te
10us z wstawionego kodu Assemblera funkcje C?
Dzieki za podpowiedzi
Lopez - 23-06-2006 00:39
Użytkownik "Manolo" napisał...
>
> Witam wszystkich,
> dzieki za odpowiedzi. Jednak sa programy,ktore synchronicznie steruja
przez
> LPT silnikami krokowymi,i to z czestotliwoscia rzedu 50kHz, spod
Windowsa,
> jak i spod DOSa (te wykorzystuja timer z plyty glownej,jak sobie radza
> Windowsowe- nie wiem).
Nie znam sie za bardzo na silnikach krokowych, ale zrobilem sobie
szybka kalkulacje i przy zalozeniu ze sinik krokowy posiada 6 biegunow
przy tej czestotliwosci osiagnie zawrotna predkosc 500tys. obr/min.
Moim zdaniem pomyliles sie o rzad wielkosci.
> Bardzo ciekawa jest instrukcja RDTSC, szkoda tylko ze czas zalezy od
> taktowania procesora. No i gdybym chcial na 1GHz procesorze osiagnac
moje
> 10us,musialbym sprawdzac kiedy zawartosc EDX:EAX zwiekszy sie o 10000,
ale
> takie liczenie zapchaloby chyba calkiem procesor, o ile sie nie myle
> (wielopotokowosc?jakos sprytniej sie da?)?No i w jaki sposob wywolac co
te
> 10us z wstawionego kodu Assemblera funkcje C?
> Dzieki za podpowiedzi
Instrukcja ta jest przeznaczona przede wszystkim do pomiarow,
czasem do wymuszania pojedynczych niewielkich opoznien gdzie
timer systemowy daje za duzy interwal.
Dodatkowo korzystanie z tej funkcji jest znacznie utrudnione
na procesorach ze zmienna czestotliwoscia taktowania,
np. na Amd z wlaczonym QnQ.
--
Pozdrawiam
Lopez
Piotr M =?iso-8859-2?Q?Ku=E6?= - 23-06-2006 00:39
W artykule <e7ccv5$vtq$1@news.onet.pl> Manolo napisal(a):
>
> Użytkownik "Piotr Niżyński" <adx@bezduszni.pl> napisał w wiadomości
> news:e79f3o$sro$1@atlantis.news.tpi.pl...
>> Manolo napisał(a):
>>> Dlatego taki timer hardware'owy, odpowiednik Builderowskiego eventu
>>> OnTimer bylby bardzo odpowiedni,tylko czy to ma szanse dzialac pod
>>> Windowsem?
>> Te timery są w użyciu przez system. Sugeruję raczej mierzyć czas przy
>> pomocy instrukcji RDTSC (1F 30 ZTCP -> licznik taktów CPU w EDX:EAX)
>
> dzieki za odpowiedzi. Jednak sa programy,ktore synchronicznie steruja przez
> LPT silnikami krokowymi,i to z czestotliwoscia rzedu 50kHz, spod Windowsa,
> jak i spod DOSa (te wykorzystuja timer z plyty glownej,jak sobie radza
> Windowsowe- nie wiem).
Niedawno na innej grupie ktoś miał podobny problem - chciał dokonywać
regularnych odczytów z karty własnej konstrukcji.
Przekleiłem Ci moje wypociny z tamtąd.
-------------------początek-cytatu----------------------------------
W artykule <6e1c.00000208.447370be@newsgate.onet.pl> logison@o2.pl napisal(a):
>> > Pytanie : na ilę mogę zaufać TIMER'owi w Delphi , aby procedura obsługi
>> > mojej karty była wywoływana w zadanych interwałach czasowych?? Jakie inne
>> > niebezpieczeństwa jeszcze widzicie w kontekście WINDOWS ??
>>
>> mozna napisac bardzo szybki program w ktory z intrerwalem nawet 5us bedzie
>> czytal ikarte ale niestety TYLKO WTEDY kiedy mu na to system
>> pozwoli. A e windows jest systemem z wywlaszczeniem - czyli obojetnie co
>> robi dany proces jak skonczy sie przydzielony czas procesora przychodzi
>> ''niemaskowalne'' przerwanie i proces zostaje zahibernowany na nie wiadomo
>> jak dlugo. Dlatego w windowsie mozna liczyc czasy z dokladnoscia do 1 ms +/-
>> x a x zaczyna sie do zera i zmierza do neskonczonosci :)
>
> Niestety utwierdzasz mnię w opinii , iż zrobienie programu robiącego porządnie
> FFT (próbkujacego dane ze stałą częstotliwością z jakiegoś urządzenia )w
> środowisku Windows jest cholernie ryzykowne. No cóż , próbkowanie zrobię w pełni
> hardware'owo.
W czasach DOSa na kompie działał pi*drzwi jeden program
i wtedy można sobie było robić co się chciało, gadać
ze sprzętem, chulać ile dusza zapragnie. Ale to se nevrati. *)
Współczesne systemy operacyjne są wielozadaniowe i w związku
z tym muszą wywłaszcząć procesy**) użytkownika.
Ograniczają też dostęp do sprzętu by procesy nie wywalały
całego systemu, wystarczy że system sam się czasami wykłada :)
Oczywiście są obejścia - można podwyższać priorytet wątku,
by nie oddawał za często i na zbyt długo procesora procesora.
Jednak jest to rozwiązanie takie sobie, gdy nie ma zbyt ostrych
ograniczeń na czas obsługi.
Jeśli potrzebujesz gadać z żywym metalem, to lepszym miejscem
jest działanie w trybie jądra, czyli musisz napisać sterownik.
Tu Ci za wiele nie pomogę, bo nie siedzę w sterownikach.
Napewno musisz zdobyć Windows Driver Development Kit,
który MS wysyła ~po kosztach transportu. Ponadto przydała
by się jakaś książka o pisaniu driverów, jest kilka pozycji,
ale nie licz na tłumaczenia. No i oczywiście dużo czasu na
naukę i ćwiczenia. Odnoszę też wrażenie że nie zaszkodziłoby
Tobie najpierw przeczytać coś ogólnego o budowie systemów
operacyjnych, np. Silberschatz, Galvin "Podstawy systemów
operacyjnych", duża cegła ale chociaż przejżeć warto.
Jeszcze sobie przypomniałem że jakiś czas temu wyszedł
przekład "Inside Windows 2000" Russinovicha, nie pamiętam
polskiego tytułu. To nie jest co prawda książka o sterach,
a raczej przegląd architektury systemów Windows z linii NT.
A wracając do metalu, dodanie sprzętowego bufora jak sugerowali
inni, to też jest dobry pomysł. Pamiętaj że nad Twoją kartą
masz całkowitą kontrolę i możesz zagwarantować regularność
odczytów. Natomiast kontrola togo co użytkownik odpali
i jak to wpłynie na zasoby dostępne dla Twojego soft,
jest już dużo mniejsza.
*) Pisałem ze słuchu, nie znam czeskiego.
**) Najczęściej szeregowanie zadań jest na poziomie wątków,
czytaj wątki współzawodniczą o procesor, a nie procesy.
-------------------koniec-cytatu------------------------------------
--
Pozdrawiam,
Piotr Kuć
Sebastian Bialy - 23-06-2006 00:39
Manolo wrote:
> dzieki za odpowiedzi. Jednak sa programy,ktore synchronicznie steruja przez
> LPT silnikami krokowymi,i to z czestotliwoscia rzedu 50kHz, spod Windowsa,
> jak i spod DOSa (te wykorzystuja timer z plyty glownej,jak sobie radza
> Windowsowe- nie wiem).
> [...]
Więc masz ewidentnie problem, którego NIE DA SIE:
a) sensownie rozwiązać pod normalnym systemem operacyjnym
b) używając zanikającego i tandetnego LPT
Natomiast rozwiązanie idealne oceniam na jakąś 1 godzinkę pracy
lutownicą. IMHO potrzebujesz:
1) mikrokontroler - osobiście wybrał bym coś koło ATMega8 ze zwględu na
gcc+cenę
2) sterownik do silnika - L298 jeśli to bipolarny, zwykły ULN2800 jesli
to unipolarny (oczywiście zakładam, że prądy niewielkie)
3) coś do komunikacji - dalej można stosować RS232, a więc sprawę
załatwia MAX232 + garstka elementów.
Całośc jakieś 30zł i godzinka roboty. Elementy do dostania w kazdym
większym mieście + allegro. Efekt powali na kolana każdego miłośnika
dłubania w timerach na peceta. Oczywiście nalezy jeszcze ATMega
zaprogramować, ale jeśli znasz C to dasz sobie radę (choć nie od razu) a
będzie to 10x prostsze i bardziej wiarygodne niż żałosne dłubanie w
timerach windowsa/cpu.
W przypadku silników krokowych szczególnie sterujących sporymi masami
niedopuszczalne jest byle jakie sterowanie, bo inaczej będzie gubił
kroki. Wykonanie pracy mikrokrokowej tez nie jest trudne na uC a na PC
raczej awykonalne. Dlatego zostaw w spokoju peceta i zainteresuj się
mikrokontrolerami.
Manolo - 23-06-2006 00:39
>> dzieki za odpowiedzi. Jednak sa programy,ktore synchronicznie steruja
>> przez LPT silnikami krokowymi,i to z czestotliwoscia rzedu 50kHz, spod
>> Windowsa, jak i spod DOSa (te wykorzystuja timer z plyty glownej,jak
>> sobie radza Windowsowe- nie wiem).
>> [...]
>
> Więc masz ewidentnie problem, którego NIE DA SIE:
>
> a) sensownie rozwiązać pod normalnym systemem operacyjnym
> b) używając zanikającego i tandetnego LPT
>
> Natomiast rozwiązanie idealne oceniam na jakąś 1 godzinkę pracy lutownicą.
> IMHO potrzebujesz:
>
> 1) mikrokontroler - osobiście wybrał bym coś koło ATMega8 ze zwględu na
> gcc+cenę
> 2) sterownik do silnika - L298 jeśli to bipolarny, zwykły ULN2800 jesli to
> unipolarny (oczywiście zakładam, że prądy niewielkie)
> 3) coś do komunikacji - dalej można stosować RS232, a więc sprawę załatwia
> MAX232 + garstka elementów.
>
> Całośc jakieś 30zł i godzinka roboty. Elementy do dostania w kazdym
> większym mieście + allegro. Efekt powali na kolana każdego miłośnika
> dłubania w timerach na peceta. Oczywiście nalezy jeszcze ATMega
> zaprogramować, ale jeśli znasz C to dasz sobie radę (choć nie od razu) a
> będzie to 10x prostsze i bardziej wiarygodne niż żałosne dłubanie w
> timerach windowsa/cpu.
>
> W przypadku silników krokowych szczególnie sterujących sporymi masami
> niedopuszczalne jest byle jakie sterowanie, bo inaczej będzie gubił kroki.
> Wykonanie pracy mikrokrokowej tez nie jest trudne na uC a na PC raczej
> awykonalne. Dlatego zostaw w spokoju peceta i zainteresuj się
> mikrokontrolerami.
Witam,
odpowiadajac wszystkim trzem szanownym grupowiczom:
- 100kHz potrzebne,zeby liniowo przyspieszac do 10kHz przez "gubienie"
niektorych taktow. Wtedy przy 400krokach na obrot mam 25obr/sec, co przy
srubie o skoku 4mm daje predkosc 10cm/sec, a wiec wystarczajaca,lecz niezbyt
oszalamiajaca.
- Czyli rozwiazaniem byloby "cofniecie sie" do DOSa? Albo jakiegos innego
darmowego systemu jednozadaniowego. Jest to jedna z rozwazanych opcji.
Jednak wciaz istnieja dzialajace programy pod Windows (MACH, KCAM). Nie wiem
czy wykorzystuja cos co nazywasz driverem, co prawda wymagaja restartu
systemu po instalacji i dzialaja. Ale jednak da sie to zrobic i to nie daje
mi spokoju... Liczylem troche na to DRTSC. Pisanie drivera to chyba ponad
moje sily (brak wiedzy i czasu na nauke, kiedy ledwo radze sobie z
poznawaniem C++). No a moze ktorys z timerow na plycie? Czy napewno
wszystkie sa uzywane przez Windows?
- Natomiast zrobienie kawalka elektroniki nie powinno byc problemem,
rozwazalem rozwiazanie mikrokontroler+RS232 na poczatku, tylko wydawalo mi
sie mniej czyste- po co robic tak,skoro da sie skorzystac z tego co juz jest
w kompie (LPT). Mikrokrok rzez LPT to tez nie problem, jedynie zamiast L298
(umozliwia polkrok,co mi wystarcza) trzebaby zastosowac inna koncowke
mocy,albo zrobic wlasna. No i w rozwizaniu z mikrokontrolerem bylby on
wlasciwie tylko do taktowania silnikow, obliczenia interpolacji, lukow itp
robilby PC, jakos trzebaby przeslac wektor ruchu z predkoscia do niego przez
RS.
=?ISO-8859-2?Q?Piotr_Ni=BFy=F1ski?= - 23-06-2006 00:39
Manolo napisał(a):
> Bardzo ciekawa jest instrukcja RDTSC, szkoda tylko ze czas zalezy od
> taktowania procesora. No i gdybym chcial na 1GHz procesorze osiagnac moje
> 10us,musialbym sprawdzac kiedy zawartosc EDX:EAX zwiekszy sie o 10000, ale
> takie liczenie zapchaloby chyba calkiem procesor, o ile sie nie myle
> (wielopotokowosc?jakos sprytniej sie da?)?No i w jaki sposob wywolac co te
> 10us z wstawionego kodu Assemblera funkcje C?
No zapchałoby, ale pod jednozadaniowym DOS-em i tak jest zapchany.
Można oczywiście zlecić procesorowi w tym czasie jakieś inne, mało
zajmujące zadania związane z naszym procesem.
Co do wywołania to proponuję coś jak i386_GetTSC() z
http://crashnet.pl/cgi-bin/viewcvs.c...79&view=markup
;) No i wątek powinien mieć SetThreadPriority(GetCurrentThread,
THREAD_PRIORITY_TIME_CRITICAL), a proces
SetPriorityClass(GetCurrentProcess, REALTIME_PRIORITY_CLASS).
To de facto wyłącza wywłaszczanie i oddaje nam całe CPU. Bardzo
niedydaktyczne i ogólnie strasznie nieeleganckie, choć jeśli używane
tylko przez chwilę i w zastosowaniach specjalistycznych, to może da się
znieść.. ;)
Sebastian Bialy - 24-06-2006 01:07
Manolo wrote:
> - 100kHz potrzebne,zeby liniowo przyspieszac do 10kHz przez "gubienie"
> niektorych taktow. Wtedy przy 400krokach na obrot mam 25obr/sec, co przy
> srubie o skoku 4mm daje predkosc 10cm/sec, a wiec wystarczajaca,lecz niezbyt
> oszalamiajaca.
Rozumiem, ze liczyłeś moment obrotowy silnika przy takiej prędkości i
jest on powyżej oporów mechanicznych silnika ;) ? 25 obr/s to całkiem
sporawo jak na krokowca.
> No a moze ktorys z timerow na plycie? Czy napewno
> wszystkie sa uzywane przez Windows?
Czemu nie napisać softu przenośnie z kawałkiem elektroniki wykonawczej
zamiast utopić się w aktualny Windows i być moze okaże się, że w Vista
nie ma tego timera/whatever ?
> - Natomiast zrobienie kawalka elektroniki nie powinno byc problemem,
> rozwazalem rozwiazanie mikrokontroler+RS232 na poczatku, tylko wydawalo mi
> sie mniej czyste- po co robic tak,skoro da sie skorzystac z tego co juz jest
> w kompie (LPT).
No właśnie się nie da. Nikt Ci nie zagwarantuje, ze twój soft na LPT w
ogóle ma szanse działać za rok - nowe komputery mają LPT w zaniku. LPT
jest strasznie czułe na przepięcia - jeden ruch wyczką/przepięcie z
cewki i koniec LPT (wiem co mówie, spaliłem juz LPT na 3 płytach w
różnych okolicznościach, na szczęście opamiętałem się i już nie używam).
Pewno że masa ludzi na świecie dłubie na LPT (jest taki kawał o muchach
.... ) ale jak mi przychodzi student i mówi że ma pomysł jak coś
podłaczyć pod LPT w kompie to dostaje kopa w d... i za drzwi. Od
komunikowania się z komputerem są interfejsy szeregowe i taka jest
ogólna tendencja. Chyba że to projekt do szuflady. Szkoda by było
zaprzepaścić szansę na samym początku na kawałek sensownego softu.
> wlasciwie tylko do taktowania silnikow, obliczenia interpolacji, lukow itp
> robilby PC, jakos trzebaby przeslac wektor ruchu z predkoscia do niego przez
> RS.
Ej ? A co niby trudnego dla wypasionego AVR jeśli chodzi o liczenie
krzywych ? W zasadzie to trywialne obliczenia są, co prawda nie robiłem
sterownika na razie z obliczeniami trajektorii, ale myśle, że to
wykonalne. W tym roku będe musiał wreszcie ruszyć z prywatnym projektem
CNC więc jest szansa że przetestuje to co mówie.
IMHO porzuć bzdurne pomysły o LPT a zrób raz a dobrze na szeregowym
interfejsie. Zalet niewspółmiernie wiele w stosunku do LPT.
Sc0rpi0 - 09-07-2006 03:46
Sebastian Bialy uderzył(a) głową w klawiaturę i wyszło takie coś:
> Czemu nie napisać softu przenośnie z kawałkiem elektroniki wykonawczej
> zamiast utopić się w aktualny Windows i być moze okaże się, że w Vista
> nie ma tego timera/whatever ?
Pytaniem na pytanie - a czemu aktualny Windows zawsze musi coś
mieć zjeb... i niezgodne w dół z poprzednimi wersjami ? Najlepiej w ogóle
się nie topić w badziewny aktualny system tylko wybrać inny albo zrobić
sterownik odpowiedzialny za samą komunikację pod konkretny system - do
następnego tak czy siak trzeba będzie pewnie nowy napisać.
>> - Natomiast zrobienie kawalka elektroniki nie powinno byc problemem,
>> rozwazalem rozwiazanie mikrokontroler+RS232 na poczatku, tylko wydawalo
>> mi sie mniej czyste- po co robic tak,skoro da sie skorzystac z tego co
>> juz jest w kompie (LPT).
I o to chodzi - po cholerę inwestować pieniądze (nie za dużo, ale zawsze)
i czas w tworzenie elektroniki skoro można to osiągnąć za pomocą paru
drutów, a reszta już czeka gotowa ?
> No właśnie się nie da. Nikt Ci nie zagwarantuje, ze twój soft na LPT w
> ogóle ma szanse działać za rok - nowe komputery mają LPT w zaniku. LPT
> jest strasznie czułe na przepięcia - jeden ruch wyczką/przepięcie z
> cewki i koniec LPT (wiem co mówie, spaliłem juz LPT na 3 płytach w
> różnych okolicznościach, na szczęście opamiętałem się i już nie używam).
> Pewno że masa ludzi na świecie dłubie na LPT (jest taki kawał o muchach
> ... ) ale jak mi przychodzi student i mówi że ma pomysł jak coś
> podłaczyć pod LPT w kompie to dostaje kopa w d... i za drzwi. Od
> komunikowania się z komputerem są interfejsy szeregowe i taka jest
> ogólna tendencja.
Ogólnymi tendencjami piekło jest wybrukowane. I nie wypisuj farmazonów,
bo do komunikacji równie dobrze może służyć zarówno interfejs szeregowy
jak i równoległy. Po prostu nie kupować płyt gdzie nie ma 1xLPT i 1xRS232,
minimum. Robisz inaczej to sam sobie dołki kopiesz. To właśnie dzięki takim
mądralom producenci zbijają kasę co moment wprowadzając coś nowego
co może i jest nowsze, lepsze ale o jakieś powiedzmy 5% i absolutnie nijak
ma się do wcześniejszego sprzętu na czym oczywiście kasę można zbić, bo
trzeba sprzętu nawymieniać. A twoim studentom współczuję - kopa to bym
może i zasadził, ale nie im. Po to były wymyślone te interfejsy i nie widzę
powodu ładowania się w układy, scalaki, płytki - kilogram elektroniki itp.
tam gdzie mogę wykorzystać coś co juz jest zrobione i nie potrzeba więcej.
Oczywiście to wszystko co naskrobałem to lekka przesada, ale nie wiem
czemu niedługo np. mając starą drukarkę (LPT) czy sprzęt wymagający
RS232 (a tego to już naprawde jeszcze sporo działa) miałbym to wymieniać
(jeszcze pod warunkiem, że producent wyprodukował np. wersję USB),
czy też utracić możliwość korzystania bo taka jest "ogólna tendencja".
Wszystkie te udogodnienia, hot-plugi itp. wodotryski są fajne, ale
niekonieczne zawsze i wszędzie - osobiście wolę mieć do tego jeszcze
stare sprawdzone i co najważniejsze PROSTE do wykorzystania
możliwości.
--
Sc0rpi0
I hated going to weddings.
All the grandmas would poke me saying "You're next".
They stopped that when I started doing it to them at funerals.
Sebastian Bialy - 10-07-2006 00:08
Sc0rpi0 wrote:
>>Czemu nie napisać softu przenośnie z kawałkiem elektroniki wykonawczej
>>zamiast utopić się w aktualny Windows i być moze okaże się, że w Vista
>>nie ma tego timera/whatever ?
> Pytaniem na pytanie - a czemu aktualny Windows zawsze musi coś
> mieć zjeb... i niezgodne w dół z poprzednimi wersjami ?
Gdyby miał wszystko zgodne z poprzednimi wersjami to być dalej miał
CP/M. Chciałbyś ? Albo inny przykład - zerknij na "technologię" x86 -
czy nie wygląda to jak załatany procesor 8 bitowy ? Nikt nie miał odwagi
zerwać zgodności w dół ... i siedzimy w tym bagnie do dzisiaj.
> Najlepiej w ogóle
> się nie topić w badziewny aktualny system tylko wybrać inny albo zrobić
> sterownik odpowiedzialny za samą komunikację pod konkretny system - do
> następnego tak czy siak trzeba będzie pewnie nowy napisać.
Bzdura - dobry soft nie dośc, że jest kompilowalny pod wieloma
aktualnymi systemami to jeszce ma szanse bez większych poprawek pracować
przez najbliższe dziesięć lat na systemach których jeszcze nie ma. To że
taki soft nie powstaje w automatyce hobbystycznej jest lenistwem
programisty, któremu się nie chce.
>>>- Natomiast zrobienie kawalka elektroniki nie powinno byc problemem,
>>>rozwazalem rozwiazanie mikrokontroler+RS232 na poczatku, tylko wydawalo
>>>mi sie mniej czyste- po co robic tak,skoro da sie skorzystac z tego co
>>>juz jest w kompie (LPT).
> I o to chodzi - po cholerę inwestować pieniądze (nie za dużo, ale zawsze)
> i czas w tworzenie elektroniki skoro można to osiągnąć za pomocą paru
> drutów, a reszta już czeka gotowa ?
A można ? Jesteś w stanie na LPT utrzymać stabilnie 100kHz bez grzebania
głeboko w jądrze, spędzając upojne 2 miesiące dłubiąc sterownik i modląc
się, żeby Win okazał się choć trochę RT? Zamiast zrobić to samo za 15zł
+ 3 godziny pracy? Ciągle słyszę te hasła o tym, że na LPT wszystko da
się łatwiej zrobić. Owszem, miganie diodkami da się łatwiej ...
> Ogólnymi tendencjami piekło jest wybrukowane. I nie wypisuj farmazonów,
> bo do komunikacji równie dobrze może służyć zarówno interfejs szeregowy
> jak i równoległy.
Nie. Nie równie dobrze. LPT zanika. LPT nie jest bezpieczne, a nawet za
delikatne. LPT działa w takich zastosowaniach tylko pod warunkiem, że
jest obsługiwane niestandardowo przez grzebanie w portach. LPT działa na
małe odległości. LPT nie buforuje danych. LPT nie jest interfejsem typu
"wsadź i zapomnij" - trzeba ciągle machać liniami zajmując czas programu
na pierdoły. LPT się nie nadaje do sterowania w tym zastosowaniu jakie
autor chce w wątku - bo nie nadaje się zarówno win jak i lpt.
> Po prostu nie kupować płyt gdzie nie ma 1xLPT i 1xRS232,
> minimum. Robisz inaczej to sam sobie dołki kopiesz. To właśnie dzięki takim
> mądralom producenci zbijają kasę co moment wprowadzając coś nowego
> co może i jest nowsze, lepsze ale o jakieś powiedzmy 5% i absolutnie nijak
> ma się do wcześniejszego sprzętu na czym oczywiście kasę można zbić, bo
> trzeba sprzętu nawymieniać.
Bzdura - USB nie jest 5% lepsze od lpt. USB jest NIEPORÓWNYWALNIE
lepsze. A koszt dla hobbysty jego obsługi wynosi aktualnie 0zł. Bo tyle
kosztuje implementacja USB w procesorze AVR z użyciem tylko software
(nie, nie trzeba tego pisać, już jest). A pewnie, że są ograniczenia,
ale jak się nie podoba, to jest cała masa innych uCPU z USB sprzętowym.
Ja wiele w życiu zrobiłem na LPT i wiele z tych rzeczy było głupich od
samego początku. Ale musiałem to przećwiczyć sam, żeby to zobaczyć.
Dzisiaj są dla mnie tylko dwa rozwiązania: albo USB dla urządzeń do
komputera - albo RS485/422 do automatyki (ze względu na zakłucenia i
odległości). W dodatku obydwa sposoby są prostsze niż odkrywanie Ameryki
pisząc na nowo protokól komunikacyjny na LPT.
> A twoim studentom współczuję - kopa to bym
> może i zasadził, ale nie im. Po to były wymyślone te interfejsy i nie widzę
> powodu ładowania się w układy, scalaki, płytki - kilogram elektroniki itp.
Powtarzam - jeśli chcesz urobić się po łokcie pisząc soft w windowsie
który nie da rady wyciągnąć 100kHz na LPT ale "podobno" JEST PROSTY - to
wspólczuje. Ja to samo zrobie z użyciem 100 gram uC i dostanę:
a) stabilne 100kHz - bez najmniejszej skazy - od razu mówie, że to przy
krokowcu dośc ważne (dalej pozostaje otwara kwestia czy w ogóle można go
tak szybko kręcić - coś mi tu powaznie nie pasuje).
b) nie zajmujące czasu CPU głównego
c) kosztujące 10-15zł
d) komunikujące się przez RS232, RS485, lub nawet USB - bez dużego
nakładu pracy
e) optoizolowane
f) robiące 10 innych rzeczy w uCPU w przyszosci - np liczące
przyśpieszenia, badające przeciązenia silnika, liczące krzywe
g) kosztujące 3 godziny pracy z kompilatorem gcc + 3 godziny na
zrobienie prototypu (przesadzam, da się to zrobić w 4 godziny).
h) podłaczalne do czegokolwiek od serwera, przez peceta i maca po
palmtop i inny uC.
Ty natomiast oferujesz:
a) port, którego praktycznie nie ma
b) obciązenie CPU na liczenie prostokąta 100kHz
c) dłubanie w jakiś przerwaniach windowsa co do kórych nie ma pewności,
czy są dostępne teraz/w przyszłości i czy są dostepne w innych systemach
operacyjnych
d) prostokąt 100kHz - średnio - urozmaicony wieloma ważniejszymi
rzeczami jak na przykład praca dysku, myszki, dma, itd. itp. Co może
oznaczać gubienie kroków.
> Oczywiście to wszystko co naskrobałem to lekka przesada, ale nie wiem
> czemu niedługo np. mając starą drukarkę (LPT) czy sprzęt wymagający
> RS232 (a tego to już naprawde jeszcze sporo działa) miałbym to wymieniać
a) drukarek pod LPT nie musisz wymieniać - działają na większości
przelotek USB->LPT poniewaz pracują w dobrze określonym protokole. Nie,
Ty nie możesz ich użyć - bo sugerujesz rozwiązanie niestandardowe,
którego ta przelotka nie obsługuje.
b) RS232 na USB jest prawie taki sam jak wbudowany, za wyjątkiem idiotów
piszących programy z użyciem gmerania po portach zamiast funkcji systemu
operacyjnego. Ale ich po prostu należy głęboko zakopać i dobrze
przydeptać piasek.
> czy też utracić możliwość korzystania bo taka jest "ogólna tendencja".
Ogólna tendencja jest taka, że LPT jest mierne i przestarzałe. Nie widze
potrzeby korzystania z tej starej techniki w sytuacji, gdy drukarka
potrzebuje dziesiątki megabajtów na stronę. Przepychanie tego przez LPT
z lakonicznym dostepnym komunikatem zwrotnym "PAPER/ERROR" jest
zdecydowanie niewystarczające.
> Wszystkie te udogodnienia, hot-plugi itp. wodotryski są fajne, ale
> niekonieczne zawsze i wszędzie - osobiście wolę mieć do tego jeszcze
> stare sprawdzone i co najważniejsze PROSTE do wykorzystania
> możliwości.
Tak, one są zdecydowanie proste - jak trzeba pomigać diodkami. Tu się
podpisuje obydwoma rękami. Spróbuj jednak sterować fazami silnika
krokowego 100kHz jak chce autor. Z chęcią zobacze jak to zrobisz pod
windowsem używając prostego w użyciu LPT i systemu "prawie" czasu
rzeczywistego wymagającego jedynie podłaczenie się do jednego takiego
przerwania ... co do którego nawet nie wiadomo czy można ...
Powtarzam jednak jeszcze raz: jeśli mówisz o miganiu diodkami to ok.
Jeśli mówisz o temacie wątku - to nie masz szans zrobić taki soft. Chyba
że napiszesz to w czystym asm odpalanym zaraz za biosem i będziesz miał
wszystko przewidywane ...
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
=?ISO-8859-2?Q?=5Bmysql=5D_synchronizacja_struktury_bazy_?==? ISO-8859-2?Q?lokalnej_ze_zdaln=B1?=
=?iso-8859-2?Q?=5BPostgreSQL=5D_synchronizacja_danych_mi=EAdz y_bazami?=
Uzywa ktos jakiejkolwiek replikacji/synchronizacji danych ?
synchronizacja danych wielu klientow?
MySql i PostgreSQL - synchronizacja danych
[PostgreSQL] Synchronizacja struktury bazy
nested synchronized
set timing on, autotrace przez jdbc
[MySQL] podzapytanie w petli
[pgsql] pytanie laika
zanotowane.pldoc.pisz.plpdf.pisz.plmarcelq.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
