logo elektroda
logo elektroda
X
logo elektroda
REKLAMA
REKLAMA
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

RS232 programowanie:gdzie znaleźć bufor odbiorczy (wielkość)

SonicAL 24 Kwi 2008 21:28 3014 4
REKLAMA
  • #1 5073822
    SonicAL
    Poziom 13  
    Cześć!
    Właśnie robie transmisje po rs232 między komputerami od całkowitych podstaw na in(out)port'ach - wersja korzystająca z pollingu.

    Mam już prawie wszystko zrobione, ale jeszcze brakuje mi kontroli przepływu XON / XOFF.
    Zgodnie z teorią jak bufor odbiorczy się zapewni do pewnego stopnia, trzeba wysłać XOFF... ale jak dobrać się do bufora odbiorczego? Jak sprawdzić w jakim stopniu jest zajęty, jaki jest wielki?

    Doświadczalnie sprawdziłem że jego wielkość to chyba 16 bajtów - chyba że wynika to z innego błędu w programie.
    Któryś z rejestrów COM'a to przechowuje? Bo jak na moje oczy to nie, chyba że źle patrze.

    Korzystam głównie z BeyondLogic:
    http://www.beyondlogic.org/serial/serial.htm
  • REKLAMA
  • #2 5076796
    bis
    Poziom 21  
    Jeżeli masz na myśli bufory "wewnątrz" układu UART to sterowanie XON/XOFF jest możliwe tylko dla nielicznych realizacji UART i odbywa się przez programowanie odpowiednich rejestrów UART-u ( próg zadziałania, próg wznowienia, kody znaków XOFF i XON). W wiekszości przypadków sterowanie XON/XOFF dotyczy obsługi programowej, realizowanej na przerwaniach i wielkość bufora oznacza wielkość pamięci w której program odbierający znaki je umieszcza (np bufor cykliczny) a wysyłanie znaku XOFF następuje w reakcji na sprawdzenie liczników ile jeszcze zostało wolnego miejsca. Bufor zwalniany jest poprzez odczytywanie znaków jakimś innym procesem (inne przerwania lub pętla główna) i wtedy odpowiednie liczniki/wskaźniki są zmieniane zwiększając pojemność bufora. Jeżeli wolne miejsce w buforze przekroczy odpowiedni próg to oprócz odczytania znaku należy wysłać znak XON. Jeżeli obsługujesz nadchodzące znaki/komendy w poolingu to jedyny sens XOFF/XON jest taki że wysyłasz je gdy obsługa tego co już zebrałeś jest czasochłonna (może trwać dłużej niż odebranie i możliwe buforowanie w UART) a kiedy znowu możesz czekać na nastepne znaki (po powrocie z takiej czasochłonnej funkcji) wysyłasz XON. Takie realizacje kryja wiele, trudnych do zdiagnozowania, pułapek.
    Generanie XON/XOFF jest programowe a nie sprzętowe i raczej dla odbioru i buforowania znaków na przerwaniach a nie poolingu.
    bis
  • REKLAMA
  • #3 5078046
    SonicAL
    Poziom 13  
    Teraz tak patrze dokładniej... czyli wychodzi na to że rejestr: First In / First Out Control Register będzie odpowiedzialny za moje bufory.
    To by się zgadzało z praktyczną realizacją.
    Póki co rozwiąże to prymitywnie poprzez liczenie liczby transmisji.
    W moim pollingu transmisja kolejnych znaków jest tak szybka, że zapycha bufor.
    Teraz jeszcze musze się zająć kontrolą CTS/RTS.
  • REKLAMA
  • #5 5086407
    SonicAL
    Poziom 13  
    No niezłe kompedium. Na BeyondLogic wszystko jest bardziej zgrabnie podane, ale na pewno te wiki sie przyda. Dzieki!
    Już zrobiłem program, sypie się jeszcze, ale jutro go poprawie :)
REKLAMA