[pso] Tema 2 linux

Adrian Stanciu pso@cursuri.cs.pub.ro
Thu, 26 Aug 2004 12:07:46 +0300


Pe scurt: Dupa ce s-a terminat operatia de FLUSH, bufferele sunt
goale, atat cele soft cat si cele hard. Acesta este rolul operatiei.
Acum nu stiu sigur daca portul serial permite FLUSH daca in buffer
exista doar un bit de trimis (sau in general mai putini de 7-8). Daca
nu permite nu permite, nu ai ce face.
Nu trebuie sa asumi nimic despre unde se duc datele, adica ce este
conectat la portul serial. Treaba driverului este sa le trimita. Deci
NU te baza pe faptul ca COM1 e conectat la COM2, asta-i un caz
particular pentru testare.

--adrian

On 26 Aug 2004 08:31:16 -0000, Ioan MANEA <ioan@home.ro> wrote:
> UART16550 - Linux (tema 2)
> Acum functioneaza aproape perfect, insa mai am cateva mici probleme:
> 
> Am modificat programul de test sa trimita 4 bytes, pentru a gasi problema.
> Iar problema este urmatoarea:
> - se trimit 4 bytes la incept pe COM1,
> - apoi se executa FLUSH pe COM1 (ceea ce implica trimiterea tuturor caracterelor, si deci se asteapta trimiterea lor fizica spre UART),
> - apoi se executa CLEAR IN pe COM2 (cand se asteapta ca cele 2 com-uri sa fie goale)
> - se trimit apoi 4 bytes pe COM1,
> - se citesc 4 bytes pe COM2.
> 
> Ar trebui sa se citeasca ultimii 4 bytes scrisi (deoarece primii 4 au fost stersi mai devreme).
> Dar intreruperile se genereaza astfel:
> OUT[0], OUT[1]...., OUT[3] (adica se genereaza INT pentru scrierea datelor, dar intre aceste OUT-uri NU se genereaza deloc intreruperi pentru citire pt. COM2
> se asteapta in FLUSH pentru ca toate OUT-urile sa se genereze, iar apoi vine imediat, din userspace, CLEAR IN pentru COM2. Se executa CLEAR IN, apoi se scriu alte 4 caractere.
> deci, se executa OUT[4], OUT[5],...OUT[7].
> Eh, si se executa citirea, unde se sleep-aiei procesul pentru ca nu avem date. Si apoi vin, finally, intreruperile de citire:
> IN[0], IN[1]... IN[7]! Adica toate datele.
> Logic, cand se executa citirea, se citesc datele scrise de OUT[0]...OUT[3], nu cele de la OUT[4]...OUT[7]. Astfel, datele sunt clar defazate prin buffere, si deci verificarile nu merg.
> 
> Este normal? In momentul in care eu am executat flush pe iesire, trebuie sa astept sa iasa datele. Ele ar trebui sa ajunga repede la destinatie, pentru a se putea da CLEAR IN (mi se pare ca am testat si cu FIFO-urile disabled)
> 
> Daca este normal sa se astepte asa de mult, am mai multe cazuri (sa-mi spuneti cum este mai bine):
> 
> 1. Sa astept in FLUSH pana cand inteleg ca nu mai are loc nici o operatie pe shift buffer (si, deci, inseamna ca TOTUL a fost trimis la iesire, unde se poate da dupaia CLEAR); dar e prea ciudat ca 8 bytes stau pe mediu pana sa ajunga la destinatie. Oricum, data verification nu da success, logic :)
> 2. Sa fac un fel de pachete, de genul: trimit cateva 0-uri, pana sunt sigur ca au ajuns dincolo, apoi un SIZE, urmat de SIZE elemente, astfel incat cand vine CLEAR IN sa astepte sosirea unui pachet (deoarece au inceput sa vina 0-uri), etc.? (si sa trimit destule 0-uri pana sa fiu sigur ca dincolo se asteapta pachet)
> 3. Sa consider ca tema va merge bine pe o masina reala (nu s-a compilat pe Fedora Core; f. multe erori din kernelul care venea cu distributia, deci nu am putut testa)
> 4. Considerand ca mai trebuie sa fac 2 teme (in windows) ca sa fiu sigur ca trec :D, si cum timpul meu este limitat :(, o dau asa sperand ca-mi scade putin :)
> 5. altceva?
> 
> Va multumesc
> 
> 
> 
> 
> ----
> 
> Home, no matter how far...
> http://www.home.ro
> _______________________________________________
> pso mailing list
> pso@cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso
>