Użytkownik "Atlantis" <m...@w...pl> napisał w wiadomości
news:kbuk07$ul1$1@portraits.wsisiz.edu.pl...
>W dniu 2013-01-01 12:52, Anerys pisze:
>
>> A to nie pojawia się natychmiast? Nie znam komórkowego, bawiłem się
>> tylko POTS-owymi.
>
> Pojawia się. Modem wysyła przy każdym sygnale dzwonka ciąg znaków
> "RING\r\n\" które są zapisywane w kolejnych slotach bufora (circular
> buffer). Program musi odczytać odczytać kolejne nieodczytane znaki i

Nasunął mi się taki pomysł - nie porównywać całości, ale po pojedynczym
znaku. Dopiero, jeśli się zgodzi, porównać następny i tak da capo al fine,
aż do końca.

> porównać je z oczekiwanym ciągiem. Funkcja porównująca zwraca wartość
> "fałsz", jeśli w ustalonym czasie w buforze nie pojawią się znaki
> składające się na oczekiwany komunikat. Jeśli pojawią się wcześniej -
> zwraca wartość "prawda".

Już tu mam wrażenie (nie znam środowiska w którym programujesz), że za
bardzo się koncentrujesz wokół odbioru informacji z bufora, zaniedbując
odbiór impulsowania... Ale to tylko takie bardzo luźne wrażenie.

> Problem w tym, że operacja chwilę zajmuje. Jeśli właśnie wtedy kręci się
> tarcza, program może nie zauważyć jakiegoś impulsu...

To może skoncentruj program wokół odbioru impulsowania, a jak znak z bufora
przyjdzie te kilka ms pźniej, to czyżby miał się przekłamać?

>> A nie lepiej sprawdzać stan linii... Oj... zaciemnienie, muszę
>> odkimać... Ale zajrzałem tu i mam wrażenie, że tu się da coś znaleźć...
>> http://pl.wikipedia.org/wiki/RS-232
>
> Tak, wiem - linia RI. To jest następny pomysł, jeśli nic innego nie

Może to podpiąć pod obsługę przerwania i wtedy odebrać szybciutko bufor,
może się wyrobi w 33 ms (czas zwarcia - nominał w .pl to 33/67 ms
zwarcie/przerwa)?

> wypali. Po prostu chciałem uniknąć korzystania z kolejnej linii, gdyby
> dało się to zrobić inaczej - w końcu linia RX i tak odbiera redundantną
> informację o połączeniu przychodzącym.

Trudno mi podać ci przepis, ale tak sobie pomyślałem, że zamiast np.
oczekiwać zboczy impulsów, to badać stan 0/1, co nawet przy przegapieniu
zbocza, jeśli dało by się np. oszacować, ile czasu straciliśmy na odbiorze
znaków, przypasować do jakiegoś wirtualnego szablonu, odtworzyć szybciutko
przebieg - i od tego uzależnić dalsze działania...
>
>
>> To buforować impulsy z tarczy (choćby nawet układem autonomicznym, nie
>> angażującym procesora), a cyfrówce podawać już gotową informację.
>
> To jest kolejny pomysł. Można by wykorzystać jedno z przerwań,
> generowanych w przypadku zmiany stanu jednej linii (tarcza zwiera jedną
> parę styków na czas zliczania impulsów składających się na jedną cyfrę
> numeru).

Ja myślę, żeby nawet to bardziej dla procka uprościć - śjakiś licznik
dziesiętny (na pierwszy ogień idzie 7490, ale on w BCD podaje, chyba da się
oprogamować?), który po zakończeniu cyfry da prockowi znak (nie sam licznik,
ale jego prosta oprawa) "odebrałem coś", procek piorunem zrobi przerwanie,
może nie straci się znaku z bufora?
Znów kojarzę to z komputerem Commodore i jego stacją dysków... Zasadniczo,
podczas transmisji stacja dysków - komputer, przerwania i reszta programu
schodza na daleki plan - jeśli gra muzyka, na czas transmisji jest
wstrzymywana. Ale jakaś grupa popełniła demko, które działa tak: Turbo ok.
10 razy, sample doczytywane on-line (jest ich więcej, niż mieści się w
pamięci), ale nie cały czas, proces przypomina nieco tzw. swapowanie pamięci
(stosowane w GEOSie), bez przerywania grania muzyki, nawet, gdy nastąpi błąd
odczytu, muzyka nie jest przerywana, a jedynie niemożliwy do wczytania
fragment jest pomijany, co czasem daje dość niecodzienny efekt, jak muzyka
nagle przeskoczy, czy się zapętli.
Podrzucam Ci to jako inspirację :)

--
Pod żadnym pozorem nie zezwalam na wysyłanie mi jakichkolwiek reklam,
ogłoszeń, mailingów, itd., ani nawet zapytań o możliwość ich wysyłki.
Nie przyjmuję ŻADNYCH tłumaczeń, że mój adres e-mail jest ogólnodostępny
i nie został ukryty. Wszelkie próby takich wysyłek potraktuję jako stalking.