Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[RS232,TDA5051A]Zabezpieczenie równoległej transmisji.

06 Lip 2011 19:28 1814 2
  • Poziom 15  
    Witam!
    Mam system w którym mogą pojawić się dwa nadajniki i kilkanaście odbiorników.Wszystko działa po sieci energetycznej przy pomocy odpowiednich układów(dokładnie TDA5051A). Mam ramkę danych zrobioną, ale teraz chciałbym jeszcze zabezpieczyć programowo transmisję, aby dwa nadajniki nie zaczęły wysyłania ramek w tym samym czasie. Robię to w ten sposób, że czyszczę bufor wejściowy, odczekuję 41ms i sprawdzam, czy coś jest w buforze odbiorczym. Jeśli jest pusto, to mogę nadawać.
    Code:

    while (GetInQLen (COM_PORT))
    {
            FlushInQ (COM_PORT);
            Delay (0.041);
    }
       //---------------------------------------------------
       //Transmit frame
       //---------------------------------------------------
       FlushOutQ (COM_PORT);
       ComWrt (1, byte, 5);

    Funkcje z LabWindows. Nie wiem, czy jest to dobry pomysł na zabezpieczenie dwóch równoległych transmisji. Ramka składa się z 5 bajtów. Transmisja na prędkości 1200bps. Czas oczekiwania wyznaczyłem tak, że jeden znak to 10 bitów(start, 8bit danych, no parity, 1 stop bit), czyli 5 znaków to 50 bit. 50bit/1200bps=0,4(1)s. Nie chciałbym, aby transmisja wbiła się też w środek lecącej ramki. Proszę o odpowiedź jak nie zezwolić na nadawanie, gdy linia zajęta mając do dyspozycji tylko sygnały RX i TX, przy czym w tym samym czasie mogę tylko nadawać, bądź tylko odbierać (half-duplex). Mam tylko dwa urządzenia nadawcze, zrobiłem tak, że jednym wysyłałem za pomocą free serial port monitor cyklicznie znaki z prędkością 1200bps, a na drugim miałem odpaloną aplikację- mimo wszystko ramka dochodziła, a program nie powinien przejść do nadawania. Zmiana doświadczalnie DELAY-a na ponad 100ms pomagała, ale jest to czas oczekiwania niedopuszczalny dla mnie przy tak niskiej prędkości(nie wiem, czy po prostu to przez wizualizację Serial port Monitor nie było spowodowane. Nie wiem też, czy ramka była w całości wysyłana, czy "wstrzykiwała" się między bajtami). Na moje nieszczęście Serial Port Monitor przestał chodzić i nie mogę znaleźć na necie innej aplikacji wysyłającej cyklicznie ramki (wszystkie potrafią monitorować, a tylko ta jedna mogła wysyłać). Jak jeszcze działał to zrobiłem takie coś, że wstawiłem MessagePopup w pierwszą linijkę pętli while, funkcja GetInQLen zwracała ilość odebranych bajtów i wyświetlałem ile się odebrało- nie dość, że nie odbierało oczekiwanych pięciu bajtów, tylko co najwyżej jeden, albo zero, to po zwiększeniu delaya raz było 8, raz 16- czyli, też duży rozrzut- a z założenia powinna być wartość stała. Proszę o pomoc- jak to rozgryźć?
    Darmowe szkolenie: Ethernet w przemyśle dziś i jutro. Zarejestruj się za darmo.
  • Poziom 15  
    Postaram się napisać prościej.
    System działa na prędkości 1200baud. Jeden bajt to bit startu, jeden stopu, brak parzystości- więc 10 bitów na przesłanie jednego bajtu. Ramka ma 5 bajtów, więc wyjdzie 50 bit. 50bit/1200baud=0,041 s- jest to czas trwania jednej ramki. Przerwa między ramkami 50 ms. Więc wygląda to w przybliżeniu tak:
    XXXXX000000
    41ms 50ms
    ramka przerwa

    8ms na jeden bajt wychodzi, więc czas między pomiarami bufora wejściowego określony na 60 ms powinien zawsze wykazywać minimum 1 do dwóch bajt w tymże buforze. Mi mimo wszystko wychodzi z pętli, więc pokazuje bufor wejściowy jako zero bajt- pytanie czemu? Czy ja coś tu źle wyliczam?
  • Poziom 15  
    Podarowałem sobie przypadek transmisji z dwóch źródeł równocześnie, więc problem rozwiązałem omijając go. Ogólnie to źle główkowałem. Liczenie ilości danych w buforze dawało różne wyniki. Nie miało to nic wspólnego z prędkością transmisji.