M-am dat cu capul zdravan de "timing". la viteza de 512bps pe care vreau sa o
simulez pe pinul DTR al portului serial ar trebui sa il mentin intr-o stare
timp de aproximativ 2milisecunde. Am crezut initial ca nu merge din cauza
unei latente a schimbarii starii pinului DTR si am incercat ceva mai simplu
(adica nu am mai schimbat starea pinului DTR) care a dovedit ca problema nu
era acolo:
#include <sys/time.h>
#include <sched.h>
#include <time.h>
#include <stdio.h>
int n;
const struct timespec bps512 = { 0, 1953125};
struct sched_param s;
int main (void){
struct timeval before, after;
s.sched_priority = sched_get_priority_max (SCHED_FIFO);
if (sched_setscheduler ( 0, SCHED_FIFO, &s ) == -1) {
fprintf (stderr, "Error setting scheduling policy. Aborting \n");
return 1;
}
for(n=0;n<512;n++) {
gettimeofday(&before, NULL);
nanosleep (&bps512, 0);
gettimeofday(&after, NULL);
printf ("Elapsed microseconds: %d\n",
after.tv_sec * 1000000 + after.tv_usec -
before.tv_sec * 1000000 - before.tv_usec ) ;
}
}
Linuxul meu Slack 10.0 pe un Sempron la 2800, 512MB RAM si kernel 2.4.29 Nu
are de loc precizie la folosirea nanosleep() din C. Daca dau prioritate
maxima procesului pauza este in sfarsit cea pe care o doresc dar apar alte
belele. Sistemul devine neutilizabil pe toata perioada rularii programului.Am
compilat 2.6.13 si daca ii dau prioritate maxima procesului in loc de 2ms
doarme in jur de 8 dar constant, fara ca sistemul sa se blocheze, dar tot nu
ma ajuta cu nimic.
Pe un Athlon XP 2400 parca, tot cu slack dar cu kernel 2.6.0 recompilat din
surse se mai apropie de pauza pe care o vreau de 2milisecunde dar variaza
totusi ajungand si la 4ms.
Chiar nu pot face in nici un fel sa obtin o precizie buna pt un sleep de 2
milisecunde? Exista o solutie mai buna decat cea aplicata? Cum de s-a putut
face asa ceva in dos acum 12 ani si in C sub Linux nu se poate?
Se pare ca in cele din urma singura solutie e folosirea dispozitivelor Hard
enumerate mai jos. Problema e insa ca programul ala de scris picuri care mi-a
fost recomandat e deja prea vechi si nu reusesc sa il compilez in linuxul de
acum. Poate instalez o versiune de pe atunci cu librariile C corespunzatoare.
Cele recomandate nu pot coda mesaje mai mari de aprox 60 de caractere din
cate am inteles, dar totusi ar fi un inceput.
Adrian.
>>>Pe data de Dum 04 Sep 2005 12:55, Mircea Ciocan a scris:
Salut, nu e nic un deranj, imi place sa-mi amintesc de timpurile de
demult, hai sa-ti zic care ar fi problema cu implementarea unui
encoder POCSAG in software pe sisteme multiuser/multitasking precum
Linux/Windows:
?Timing-ul !!!
?In aseamenea sisteme care nu sunt real time nu poti sti niciodata
daca schedulerul nu i-se nazare sa scrie pe disc, updateze ceva pe
video sau alte chestii lasandu-ti task-ul cu ochii in soare si
introducand jitter inacceptabil in mesaje, de aceea mai toata lumea
foloseste mici adaptoare care costa sub 100k lei si contin un PIC sau
un AVR si care sunt accesate pe serial ca un terminal oarecare, bonus,
cele bine facute se alimenteaza direct din seriala la care sunt
conectate si au ca iesire direct PTT pt comanda statiei si iesirea
catre modulator, iti recomand cu caldura ca pentru "production use" sa
platiti sau sa construiti un asemenea adaptor.
?Pentru cei FOARTE ambitiosi care vor sa faca asta strict in software,
in Linux singura solutie fezabila e sa scrii un modul de kernel care
sa se vada ca un device si care sa stea in mod kernel, neinteruptibil,
pana isi varsa mesajul SAU ( chestie mai cool si mai usor de
programat) sa folosesti o placa de sunet si sa codezi mesajul POCSAG
pentru frecventa ei de esantionare, (de obicei 44KHz) si apoi: cat
mesaj.wav > /dev/dsp si gata, am vazut demult un asemenea codor pentru
Linux si cred ca mergea si pe alte sisteme de operare capabile sa
redea un WAV. Evident aici ai de luptat cu distorsiunile introduse de
placa de sunet, dar la frecventa asta daca la iesire sarcina e de
impedanta mare s-ar putea sa obtii o forma de unda accpetabila.
Ca sa iti raspund la intrebarea cum controlezi din Linux iesirile de
uz general ale portului serial, aici ai ghidul pentru programarea
COMPLETA a portului serial, inclusiv intrarile iesirile de control
pentru modem:
http://www.easysw.com/~mike/serial/serial.html#listing6
de asemeni si:
http://www.lafn.org/~dave/linux/Serial-Programming-HOWTO.txt
( paragraful 7. Modem Control)
Ai pinii DTR si RTS ca iesiri utilizabile.
Unele exemple MINUNATE despre cum se folosesc astea pe Linux din C ai
pe aceasta pagina care se refera ( surpriza, surpriza :) la
programatoare de PIC conectate pe serial, citeste codul sursa ca e
foarte clar si usor:
http://www.grennan.com/picprog/
Si in sfarsit, daca te-ai hotarit totusi sa faci un encoder cu PIC sau
AVR acu ca ai si programator ;) ia si fa unul de aici :
http://users.rcn.com/carlott/projects.html
Daca treci prin Ploiesti te cadorisesc cu 4 pagere, 2 Motorola Memo
Express si 2 Evergreen, perfect functionale, pe care le-am primit
mostenire si am vrut sa fac ceva cu ele dar nu mai am timp asa ca
macar voi sa le gasiti ceva utilizari :)
?Sper ca acum ai tot ce iti trebuie sa te apuci de treaba si nu o sa
te superi ca fac CC si RLUG, poate mai vor si altii sa faca chestii pe
seriala si le sunt utile link-urile si sfaturile de mai sus.
? ?Mircea "ce pacat ca nu mai e timp de hecarit hardware :((" C.
On 9/4/05, Dr. Adrian Botescu-Fianu <[EMAIL PROTECTED]> wrote:
> sorry ca te deranjez pe personala.
> asa e cu timpul asta :)
> Florian e in canada, plecat definitiv, de 3 ani parca. Eu am ramas cu tot
> pagingul pe cap (de fapt ce a mai ramas din el dupa aparitia telefoniei
> mobile). Sistemul nu mai foloseste de mult codare soft a mesajelor ci
> dispozitive hard accesibile prin port serial, protocol TAP. Dupa plecarea
lui
> Florian sistemele de operare vechi (win/dos) au fost inlucuite cu Linux ca
si
> aplicatiile necesare. Din pacate din anumite cauze dupa plecarea lui "s-a
> pierdut" calculatorul lui cu toate softuletele necesare pt compilarea
> diferitelor programe facute de el si colaboratori. Noroc ca a fost baiat
> destept si a facut un beckup la surse :) dar efectiv sursa programului de
> codare pocsag nu am mai gasit-o (mai caut).
>
> Eu m-am apucat impreuna cu cineva (ca Dr vine de la medic nu de la doctorat,
> asa ca am avut nevoie de putin mai mult ajutor) de o aplicatie in C care sa
> codeze pocsag. Totul bun si frumos, se pare insa ca am ajuns in impas. Cum
> fac sa trimit spre statia radio rezultatul codarii. Portul serial mi s-a
> parut cea mai usoara solutie pana m-am lovit de bitul respectiv care mi-a
> taiat elanul. Daca ai idee de niste doace sau tutoriale din care sa invat
cum
> sa folosesc portul serial din C in linux sau ala paralel in asa fel incat sa
> controlez DTR si RTS ti-as fi recunoscator. Eu ma gandisem ca dau open
> la /dev/ttyS0, setez 1200 si scriu pe el efectiv rezultatul codarii pocsag
> dar se pare ca pot uita solutia asta.
>
> De cautat pe google am tot cautat dar nu am gasit nimic free in windows (ca
> sursa ma refer ca sa mai trag cu ochiul) iar in unix am gasit un proiect
care
> coda doar mesaje numerice pe care l-am modificat sa stie si de alfanumerice.
> Problema e ca le codeaza si atat dar de trimis .... pauza.
>
> ----------------------
>
> gooogle dupa "pocsag encoder", acu 12 ani impreuna cu Florian Necula
> v-am facut unul in Turbo Pascal care mergea chiar bine :) !!!
> Pe scurt din cauza arhitecturii USART-uluiI care echipeaza pc-urile
> "normale" nu poti controla iesirea TxData asa cum vrei tu, framingul
> se produce oricum DAR se pot controla pinii auxiliari pt. modem RTS,
> DTR whatever ca i-am uitat si eu, desi stiu ca pe seriala standard
> sunt cel putin 2 iesiri controlabile direct si la o adica iti ramine
> si portul paralel, phuterea e timingul, dar noroc ca s-au chinuit
> altii cu asta atit la emisie cat si la receptie :).
>
>
> ?Mircea "fuck, ce trece timpul :(" C.
>
> --
> DR. Adrian Botescu-Fianu
>
>>>>Pe data de S?m 03 Sep 2005 23:32, Mircea Ciocan a scris:
> gooogle dupa "pocsag encoder", acu 12 ani impreuna cu Florian Necula
> v-am facut unul in Turbo Pascal care mergea chiar bine :) !!!
> Pe scurt din cauza arhitecturii USART-uluiI care echipeaza pc-urile
> "normale" nu poti controla iesirea TxData asa cum vrei tu, framingul
> se produce oricum DAR se pot controla pinii auxiliari pt. modem RTS,
> DTR whatever ca i-am uitat si eu, desi stiu ca pe seriala standard
> sunt cel putin 2 iesiri controlabile direct si la o adica iti ramine
> si portul paralel, phuterea e timingul, dar noroc ca s-au chinuit
> altii cu asta atit la emisie cat si la receptie :).
>
>
> Mircea "fuck, ce trece timpul :(" C.
>
> On 9/3/05, Dr. Adrian Botescu-Fianu <[EMAIL PROTECTED]> wrote:
> > Pe data de Mar 30 Aug 2005 13:37, Cristian Mitrana a scris:
> > > Oldies but goldies si se aplica si la linux:
> > > http://www.easysw.com/~mike/serial/serial.html
> > >
> > >
> > > mitu
> >
> > Din cate am inteles driverul portului serial pune obligatoriu cel putin
> > un "stop bit" dupa fiecare "caracter" trimis. Ce ar trebui sa fac in
> > asa fel incat sa trimit altceva decat caractere, adica un streem binar la
> > 1200bps (eu as prefera 512bps dar vad ca nu prea am cum seta valoarea
> > asta) in care sa nu introduca nici un stop bit (lucru absolut necesar pt.
> > scopul aplicatiei)?
> >
> > Multumesc anticipat
> > --
> > DR. Adrian Botescu-Fianu
> >
> > _______________________________________________
> > RLUG mailing list
> > [email protected]
> > http://lists.lug.ro/mailman/listinfo/rlug
>
> _______________________________________________
> RLUG mailing list
> [email protected]
> http://lists.lug.ro/mailman/listinfo/rlug
--
DR. Adrian Botescu-Fianu
