[pso] Tema 2 linux

[Ioan MANEA]

pai nici nu presupun ca este asa (COM1 conectat la COM2), pentru ca daca era asa, era extrem de simplu: stiam ca fac flush, deci ca trimit 4 caractere, si cand venea clear in, setam ca primele 4 caractere venite sa fie ignorate, si gata. Dar tocmai pt. ca vreau sa mearga bine, trebuie sa stiu: apare acest mare delay datorita masinii virtuale (si deci sa presupun ca merge tema) sau chiar asa merge?
daca lucrurile chiar asa merg, atunci inseamna ca acel flush vine cam prea devreme din user space, si nu are ce flush-ai, si deci ar trebui sa se considere ca tema merge corect.

Pe 26 Aug 2004, la 12:02, Adrian Stanciu <adrian.stanciu@gmail.com> a scris:

>
>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
>>
>_______________________________________________
>pso mailing list
>pso@cursuri.cs.pub.ro
>http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/pso
>




----

Home, no matter how far...
http://www.home.ro