Potrzebuje drugiego rs'a w 8051. Czy ktos zna lub widzial metode implementacji? Bardziej iteresuje mnie sposob odbioru danych bo wysylanie to raczej prosta sprawa.
Pozdrawiam,
Alfred
Aktyw Forum
Zarejestruj się na forum.ep.com.pl i zgłoś swój akces do Aktywu Forum. Jeśli jesteś już zarejestrowany wystarczy, że się zalogujesz.
Sprawdź punkty Zarejestruj sięDodatkowy rs na 8051
Moderatorzy:Jacek Bogusz, procesorowiec, robertw, tomasz_jablonski, r-mik, Moderatorzy
Witam
Potrzebuje drugiego rs'a w 8051. Czy ktos zna lub widzial metode implementacji? Bardziej iteresuje mnie sposob odbioru danych bo wysylanie to raczej prosta sprawa.
Pozdrawiam,
Alfred
Potrzebuje drugiego rs'a w 8051. Czy ktos zna lub widzial metode implementacji? Bardziej iteresuje mnie sposob odbioru danych bo wysylanie to raczej prosta sprawa.
Pozdrawiam,
Alfred
Witam
Chyba wiem do czego zmierzasz
Mam wolnego INT'a tylko ze za pomoca INT'a wykryje tylko ewentualna zmine sygnalu wysokiego na niski (czyli np. bit startu lub bity ustawione na 0). Chyba zeby zrobic w ten sposob, ze za pomoca INT'a wykrywac tylko bit startu a zglaszane przewania z pozostalych bitow pomijac. Przydaloby sie jeszcze jakies probkowanie sygnalu zeby stwierdzic wartosc bitu.
To jest jakies wyjscie.
Myslalem raczej o metodzie "ciaglego probkowania" to znaczy nie opierac sie na inforamcji z INT'a tylko '51 sprawdza caly czas, co pewien okres czasu, stan lini odbioru. I na podstawie tych informacji decyduje czy to bit startu, dane, itp.
Co o tym sadzisz?
Chyba wiem do czego zmierzasz
Mam wolnego INT'a tylko ze za pomoca INT'a wykryje tylko ewentualna zmine sygnalu wysokiego na niski (czyli np. bit startu lub bity ustawione na 0). Chyba zeby zrobic w ten sposob, ze za pomoca INT'a wykrywac tylko bit startu a zglaszane przewania z pozostalych bitow pomijac. Przydaloby sie jeszcze jakies probkowanie sygnalu zeby stwierdzic wartosc bitu.
To jest jakies wyjscie.
Myslalem raczej o metodzie "ciaglego probkowania"
to znaczy nie opierac sie na inforamcji z INT'a tylko '51 sprawdza caly czas, co pewien okres czasu, stan lini odbioru. I na podstawie tych informacji decyduje czy to bit startu, dane, itp.Co o tym sadzisz?
Dokładnie o takim rozwiązaniu myślałem. Ponieważ gdyby wejścia przerwań były zajęte, to wtedy nie byłoby dyskusji (stąd więc było poprzednie pytanie). Za pomocą INT dostajesz sygnał bitu startu. Po jego wykryciu robisz:
1. blokujesz przyjmowanie przerwań z tego INTA
2. programujesz tak timer by przerwał ci po czasie równym 1.5 czasu jednego bitu
Od tej chwili odbierasz bity w przerwaniach od timera, który programujesz by przerwał ci po czasie trwania jednego bitu.
Po skończeniu odbierania blokujesz timer, zezwalasz na przerwania od INT (nie zapomnij wcześniej zgasić flagi zgłoszenia przerwania, bo po zezwoleniu na przerwania natychmiast ci ponownie przerwie).
Obsługa w trybie ciągłego sensowania to zamorduje ci procek, no chyba, że on więcej nic nie robi.
1. blokujesz przyjmowanie przerwań z tego INTA
2. programujesz tak timer by przerwał ci po czasie równym 1.5 czasu jednego bitu
Od tej chwili odbierasz bity w przerwaniach od timera, który programujesz by przerwał ci po czasie trwania jednego bitu.
Po skończeniu odbierania blokujesz timer, zezwalasz na przerwania od INT (nie zapomnij wcześniej zgasić flagi zgłoszenia przerwania, bo po zezwoleniu na przerwania natychmiast ci ponownie przerwie).
Obsługa w trybie ciągłego sensowania to zamorduje ci procek, no chyba, że on więcej nic nie robi.
Witam
Calkiem fajnie wymysliles z tym sprawdzaniem stanu bitu w polowie jego trwania. To bardzo uprosci sprawe w porownaniu z kilkakrotnym probkowaniem jednego bitu. No coz ale cos za cos, wedlug mnie kilkakrotne probkowanie daje wieksza pewnosc. Ale moze Twoja metoda wystarczy. Sprobuje.
A tego z zerowaniem flagi nie bardzo rozumiem?!? Chyba nie potrzeba nic zerowac bo po przyjeciu przerwania samo sie wyzeruje, a skoro natychmiast po przyjeciu int'a blokuje go to raczej zadne juz sie nie zglosi. Oczywiscie na wszelki wypadek moza tak zrobic jak mowisz.
Pozdrawiam.
Calkiem fajnie wymysliles z tym sprawdzaniem stanu bitu w polowie jego trwania. To bardzo uprosci sprawe w porownaniu z kilkakrotnym probkowaniem jednego bitu. No coz ale cos za cos, wedlug mnie kilkakrotne probkowanie daje wieksza pewnosc. Ale moze Twoja metoda wystarczy. Sprobuje.
A tego z zerowaniem flagi nie bardzo rozumiem?!? Chyba nie potrzeba nic zerowac bo po przyjeciu przerwania samo sie wyzeruje, a skoro natychmiast po przyjeciu int'a blokuje go to raczej zadne juz sie nie zglosi. Oczywiscie na wszelki wypadek moza tak zrobic jak mowisz.
Pozdrawiam.
Po wykryciu bitu startu (poprzez przerwanie) proponuję zablokowanie przerwań od INT. Stan niski (od bitu startu) spowoduje przerwanie, jego obsługa zeruje flagę przerwania. Oczywiście na tym wejściu nadal będą spełnione warunki do zgłaszania przerwań. W rzeczywistości sygnał z INT ustawia flagę żądania przerwania. Flaga ta jest dopiero sygnałem żądania przerwania. Jeżeli będziesz miał zablokowane przyjęcie przerwania od INT, to ci nie przerwnie, ale zapamięta, że było przerwanie (jako nieobsłużone).
WitamPo wykryciu bitu startu (poprzez przerwanie) proponuję zablokowanie przerwań od INT. Stan niski (od bitu startu) spowoduje przerwanie, jego obsługa zeruje flagę przerwania. Oczywiście na tym wejściu nadal będą spełnione warunki do zgłaszania przerwań. W rzeczywistości sygnał z INT ustawia flagę żądania przerwania. Flaga ta jest dopiero sygnałem żądania przerwania. Jeżeli będziesz miał zablokowane przyjęcie przerwania od INT, to ci nie przerwnie, ale zapamięta, że było przerwanie (jako nieobsłużone).
Wydaje mi sie ze wystarczy ustawic zgloszenie przerwania opadajacym zboczem i to powinno problem rozwiazac. Chyba ze zanim zablokuje przerwanie wystapi kolejna zmiana 1->0 syganlu, ale to sie wiaze z nadejsciem 3 bitu (to jest najkrotszy czas kiedy moze zmiana 1->0 nastapic) a w tym czasie '51 z pewnoscia zablokuje przerwanie.
[ Dodano: 16-11-2004, 10:06 ]
Potrzebuje troche szybciej, jakies 9600. Ale podeslij jak mozeszJaka ma być szybkość transmisji? Wydaje mi się, że mam "gotowca", ale chodzi do 1200 bps.
Maybe
Witam
Jaki masz kwarc?
teoretycznie, przy kwarcu 11059200Hz możesz wyciągnąć 38400bps, pod warunkiem, że przy przerwaniu od bitu startu wyrobisz się z ustawieniem wszystkiego w ok. 20 cyklach zegarowych, co w assemblerze nie powinno być problemem. reszta to już pestka.
Co do pewności transmisji - próbkowanie bitu tylko w jednym punkcie nie jest zbyt dobrym rozwiązaniem, ale można zastosować chociażby kontrolę parzystości - w '51 masz znacznik parzystości akumulatora w psw, dołożysz jeszcze sumę Ex-OR i masz już całkiem pewną transmisję.
Życzę powodzenia!!!!!!!!!
Jaki masz kwarc?
teoretycznie, przy kwarcu 11059200Hz możesz wyciągnąć 38400bps, pod warunkiem, że przy przerwaniu od bitu startu wyrobisz się z ustawieniem wszystkiego w ok. 20 cyklach zegarowych, co w assemblerze nie powinno być problemem. reszta to już pestka.
Co do pewności transmisji - próbkowanie bitu tylko w jednym punkcie nie jest zbyt dobrym rozwiązaniem, ale można zastosować chociażby kontrolę parzystości - w '51 masz znacznik parzystości akumulatora w psw, dołożysz jeszcze sumę Ex-OR i masz już całkiem pewną transmisję.
Życzę powodzenia!!!!!!!!!
W książce Podstawy programowania mikrokontrolera 8051 jest rozdział poświecony programowej realizacji transmisji przez RSa. Dwa przykłady dla 4800 bod (z wykorzystaniem timera) i 115200 bod (bez timera) w obu przypadkach wykorzystane INT0.
Dzieki Krisoff !W książce Podstawy programowania mikrokontrolera 8051 jest rozdział poświecony programowej realizacji transmisji przez RSa. Dwa przykłady dla 4800 bod (z wykorzystaniem timera) i 115200 bod (bez timera) w obu przypadkach wykorzystane INT0.
Zdobylem ksiazke i przestudiowalem przyklady. Jesli chodzi o male trasmisje to rozwiazanie jest takie samo jak tu omowiane. Natomiast ciekawe jest rozwiazanie dla wiekszych predkosci.
Pozdrawiam.
Kto jest online
Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 1 gość