🚀 go-pugleaf

On 11 Feb 1998 17:29:31 GMT, laser@priam.umcs.lublin.pl (Marcin
Laszewski) wrote:

>Mam prztwornik A/C z ktorego co 1/10 sekundy (a dokladnie 1/13 i wszycy
>wiedza dlaczego) wczytuje dane. Jak ich sie juz sporo nazbiera
>to trzeba bedzie je hurtem na dysk zrzucic. Poniewaz, pod DOS-em
>to zawsze jest problem z wywolywaniem funkcji systemowych z rezydentow
>wiec chcialem zapytac czy sa problemy jak sie dane wczytuje w procedurke
>podpieta pod przerwanie zegarowe (tylko czytanie z portu), a zapis
>na dysk jako zadanie normlane.
>
>Tzn, program glowny bedzie sobie flage sprawdzac (i moze cos jeszcze).
>Jak sie buforki napelnia to je zapisze i semafor podniesie.
>
Bardzo sluszna idea!
Ja bym dodal do tego jeszcze podwojne buforowanie, tzn.
- Jezeli petla sprawdzajaca, czy bufor jest pelny stwierdzi ze tak
(pelny w przyblizeniu, powiedzmy), to blokuje przerwania (cli - czy
jakos podobnie - dawno nie posalem programow) i przemieszcza dane w
"swoje" miejsce. Odblokowuje przerwania i potem spokojnie zrzuca to na
dysk.

>Czy jesli w trakcie zapisu na dysk zegar zasugeruje, ze czas cos pomierzyc
>to co sie stanie? Przerwie sie na chwile zapisywanie i wykona pomiar?
>W ogole przerwanie zegarowe nie jest generowane w tym czasie? 

No bez przesady. Przy zapisie do dysku PCet wstrzymuje przerwania.
Ale to sa BARDZO krotkie przerwy, krotsze niz ta 1/13 s.
Nie boj sie, twoje przerwanie nie zginie. Zostanie wstrzymane w
kontrolerze przerwan i wywolane, jak BIOS zapisze dane na dysk.

>Najlepiej by bylo te dane jeszcze w swiat wysylac przez tcp/ip.
>Dotychczas uzywalem pod DOS-em Waterloo TCP. jakos tam sobie radzilem.
>Tyle, ze jako, iz to tez na przerwaniach oparte to nie wiem co bedzie
>jak sie jeszcze zegar napusci - pogryza sie, czy co ?
>
Przy okazji, prosze, wyslij mi na e-mail (bo tej listy to nie czytam),
gdzie moge sciagnac Waterloo TCP.

Z gory dziekuje,

Karol

Problem z zapisem w przerwaniach nie polegał na tym, że coś tam może
zabruździć (inne przerwanie), tylko na tym, że kod DOSu nie jest
reentrant. Tak, że jak będziesz zapisywał/wysyłał dane z głównego programu
to nic nie powinno się dziać.

_______________________________________________________________________________
Michał Kaczmarczyk  mailto:mik@iname.com http://student.uci.agh.edu.pl/~kaczmar

Michal Kaczmarczyk wrote:
> 
> Problem z zapisem w przerwaniach nie polega³ na tym, ¿e co¶ tam mo¿e
> zabru¼dziæ (inne przerwanie), tylko na tym, ¿e kod DOSu nie jest
> reentrant. Tak, ¿e jak bêdziesz zapisywa³/wysy³a³ dane z g³ównego programu
> to nic nie powinno siê dziaæ.

Problem polega na tym, kiedy mozna wywolywac funkcje systemowe z
programu, ktory zostal zainstalowany jako program obslugi przerwania,
zwlaszcza 8 (zegar), czy 9 (klawiatury), tj. przerwan sprzetowych,
de facto asynchronicznych. Zajmowalem sie tym kiedys i napisalem
kilka programow w asemblerze 0x86, ktore przejmowaly przerwania
zegara i/lub klawiatury i "pod przerwaniem" pisaly do pliku dyskowego.
Dzialaly bez zarzutu. Rzecz nie jest trywialna, chociaz nie az tak
skomplikowana, jakby sie moglo wydawac. Wykorzystuje sie tzw.
znacznik INDOS (funkcja 34H), ktory sygnalizuje, czy w danym
momencie DOS jest aktywny, czy nie. Oprocz tego korzysta sie
z tzw. przerwania stanu jalowego (28H), ktory DOS generuje,
ilekroc "nie ma nic do roboty" (trzeba to przerwanie przejac).
  Niegdys byly to tzw. nieudokumentowane opcje DOS-u.
Zostaly opisane juz w DOS Technical Reference 5.0, a takze
w podreczniku MASM 6.0.
  Jest jeszcze jedna technika, wykorzystujaca SDA (Swappable
Data Area). Pole to zawiera tzw. kontekst systemowy programu,
w tym m.in. numer segmentu PSP, adres biezacego pola DTA,
znacznik bledu krytycznego, itd. Poprzez to pole wlasnie DOS
"widzi" program. Technika polega na wymienianiu zwartosci pola
SDA - DOS widzi raz glowny program, raz procedure przejmujaca
przerwanie. Jest to skuteczna technika, ale bardziej
skomplikowana od metody INDOS + INT 28H. Napisalem wprawdzie
program, podmieniajacy dynamicznie SDA, ktory w koncu uruchomilem,
ale trzeba bylo kilka rzeczy sprawdzac empirycznie, jako
ze jest to technika calkowicie nieudokumentowana. Najwyrazniej
Microsoft nie chce dopuscic, by programisci grzebali w
strukturach systemowych DOS-u. Moze i slusznie. :-)


  Pozdrawiam

  Marek Kotowski

W poprzednim odcinku Marcin Laszewski <laser@priam.umcs.lublin.pl> naskrobal:
: Czy jesli w trakcie zapisu na dysk zegar zasugeruje, ze czas cos pomierzyc
: to co sie stanie? Przerwie sie na chwile zapisywanie i wykona pomiar?
: W ogole przerwanie zegarowe nie jest generowane w tym czasie? 

Moim - niekoniecznie slusznym - zdaniem zrobisz, jezeli bedziesz wykonmywal
dumping danych po zaplenieniu bufora. I to nie w przerwaniu zegarowym, lecz
zaraz po dokonaniu pomiaru. I lepiej, zebys sie zmiescil w czasie przed
nastepnym pomiarem.

Bardzo czesto zdarza sie, ze przerwania wykorzystywane sa do przesady.
Nie dajmy sie zwariowac! Duzo wiecej czasu, nerwow i pracy zaoszczedzisz
rezygnujac z dumpowania w przerwaniu zegarowym, a dumpujac po zapelnieniu
bufora w tym samym przerwaniu, ktore dokonuje pomiaru. Nie wiem, czy tak
znowu mozesz sobie pozwolic na to, zeby przerwac zapisywanie na czas
dokonywania pomiaru. Raczej powinienes zmiescic sie z tym zapisywaniem w czasie
przerwy. Do tego musisz oczywiscie dobrac wielkosc bufora.

Przerwanie zegarowe jest generowane, ale to jest IRQ i mozna go zamaskowac.
Ale chyba nie byloby to dla ciebie specjalnie szczesliwe.

: Najlepiej by bylo te dane jeszcze w swiat wysylac przez tcp/ip.
: Dotychczas uzywalem pod DOS-em Waterloo TCP. jakos tam sobie radzilem.
: Tyle, ze jako, iz to tez na przerwaniach oparte to nie wiem co bedzie
: jak sie jeszcze zegar napusci - pogryza sie, czy co ?

To akurat mozesz wywolywac w przerwaniu zegarowym raz na jakis czas.
Procedurka, ktora wysylalaby zdumpowane dane w siec, bedzie oczywiscie
przerywana na dokonanie pomiaru, ale to akurat nie bedzie mialo znaczenia.
Oczywiscie - jak powiedzialem - nie wiem, jakiego procesora uzywasz, jezeli
jednak nie posiada on hierarchii przerwan, to nic sie nie dzieje. Gdyby je
jednak mial (jak np. 68000 ), musialbys sie jeszcze upewnic, ze przerwanie
zapisujace na dysk nie ma wyzszego priorytetu nad zegarowym, bo jesli tak,
to pomiar w czasie zapisu na dysk sie nie dokona (przerwanie o wyzszym
priorytecie po wywolaniu blokuje de facto wszystkie przerwania o nizszym
priorytecie).

: Pomiary chce wykonywac w tle, a program glowny bedie sobie flage sprawdzac
: (i moze cos jeszcze). Jak sie buforki napelnia to je zapisze i semafor
: podniesie.

Tu musialbys bardzo uwazac. Jezeli przerwanie dokonujace pomiaru "nadepnie" ci 
na dumpowanie bufora, to przepelnisz bufor. A skutki tego moga byc rozne, nie
beda jednak szczesliwe.

Pozdrawiam,


-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

On 12 Feb 1998 sektor@mud.org.pl wrote:

> W poprzednim odcinku Marcin Laszewski <laser@priam.umcs.lublin.pl> naskrobal:
> : Czy jesli w trakcie zapisu na dysk zegar zasugeruje, ze czas cos pomierzyc
> : to co sie stanie? Przerwie sie na chwile zapisywanie i wykona pomiar?
> : W ogole przerwanie zegarowe nie jest generowane w tym czasie? 

To nie do konca tak. To jest mechanizm DMA, a ja sie na nim nie znam.
Podejrzewam jednak rownoleglosc.

> 
> : Najlepiej by bylo te dane jeszcze w swiat wysylac przez tcp/ip.
> : Dotychczas uzywalem pod DOS-em Waterloo TCP. jakos tam sobie radzilem.
> : Tyle, ze jako, iz to tez na przerwaniach oparte to nie wiem co bedzie
> : jak sie jeszcze zegar napusci - pogryza sie, czy co ?
>

Podejrzewam ze ten problem jest takim samym problemem jak np. zapisywanie
do karty graficznej, itp. Mysle ze kolega ma nieco zle podejscie do
sprawy. Jezeli juz koniecznie pod DOSem, to najlepiej skorzystac z
DJGPP i kilku dostepnych bibliotek do obslugi watkow - np. newlwp. Nie 
wiem czy zostal juz do oficjalnej dystrybucji wlaczony kod fork() i 
pokrewnych, jednak ja widzialem go na wlasne oczy, w miare stabilny,
wyszedl od DJ Delorie. 

pozdrawiam
c. 

--
Codematic                            
 code@beta.cku.pwr.wroc.pl.strasznie.mi.sie.podobaja
 mmochol@elka.pw.edu.pl.te.smieci.na.koncu.adresu.email
 http://home.elka.pw.edu.pl.i.www.rowniez/~mmochol