Jak zrealizować 2 UART-y w urządzeniu z AT89Cxx i RS232C?

Question

Problem polega na tym, że musze zrobić sterownik urządzenia komunikującego się przy pomocy RS232C. Dodatkowo sterownik ten jest kontrolowany przez komputer również przez RS232C. Sterownik musi być oparty o atmelowski AT89Cxx. Niestety nie mogę nigdzie dostać Atmeli z dwoma UART-ami. Oto kilka...

Marek81 · Answer

Skłaniałbym się do opcji nr. 1. Stosowny układ przełączający możesz zrobić np. na CD4066 i sterować go z nóżki procesora. W ten sposób procesor będzie wiedział z kim gada. Pozdrawiam.

Maciej256 · Answer

Witaj. czy oba uarty mają być wykorzystywane w tym samym czasie? jak nie to można zrobić przełącznik sygnału który będzie przełączał pojedyńczy uart do pc oraz do tego urządzenia.

h-doc · Answer

Właśnie oba uarty muszą chodzić z grubsza w tym samym czasie - sterownik cały czas musi nasłuchiwać hosta i urządzenia. Komendy powienien realizować w miarę szybko i szybko wysyłać odpowiedzi do hosta, bo aplikacja wymaga dosyć szybkich reakcji. Również obsługiwane urządzenie nie może zbyt długo czekać na obsługę. Plusem jest przynajmniej to, że nie muszę przepychać wielkich ilości danych (po kilkanaście bajtów). Dodatkowo sterownik robi jeszcze kilka innych rzeczy, które są dosyć krytyczne czasowo.

elektryk · Answer

Ja bymbył za rozwiązeniem 2 lub 4, przy czym 2 jeśli Ci zależy na cenie i na mniejszych rozmiarach a 4 jeśli Ci zalezy na stosunkowo prostym programie.

h-doc · Answer

no właśnie chyba zastosuję rozwiązanie 4, ponieważ sprzętowa obsługa RS zaowocuje faktycznym uproszczeniem kodu. Poza tym sterownik na pewno nie zgubi żadnego nadchodzącego bitu a przy znacznym napływie danych będzie je można łatwo kolejkować.

Dzięki za propozycje!

Tdv · Answer

A ja proponuje inne rozwiązanie: ATmega162, ATmega64 lub ATmega128 - wszystkie trzy mają wbudowane po dwa UARTY - to chyba będzie najprostsze... AVR'y to też Atmele...

h-doc · Answer

ok - też o tym myślałem. Ale niestety mam za mało czasu. '51 mam zgrubsza opanowane, mam do tego programator, środowisko itd. AVR nie znam. Ale jeśli przy moim następnym projekcie będę miał trochę więcej czasu, to na pewno sięgnę po AVR.

tadzioor · Answer

Miałem kiedyś podobny problem, rozwiązałem go robiąc drugi UART programowo (to taki polski odpowiednik słowa "software'owo"

). Nie jest to nawet takie bardzo skomplikowane, tylko, że dużych prędkości nie wyciśniesz (mój chodził na 2400kbps, a sprzętowy 19200kbps).
Natomiast jeżeli chcesz zastosować oddzielną kość, to ostatnio natknąłem się na fajną kość Maxima: MAX3100 ( http://www.maxim-ic.com/quick_view2.cfm?qv_pk=1731&ln= )

h-doc · Answer

hmmm... niezły ten MAX, ale komunikuję się po SPI, czyli kolejny protokół do zaimplementowanie. Poza tym nie ma tego układu u dystrybutora, u którego się zaopatruję...

Nemo · Answer

Zapomnij o zabawach z innymi układami. Użyj drugiego At89C2051 tak jak radzi elektryk. Sam sobie wymyślisz protokół transmisji i będziesz miał taniej i prościej. Pozdrawiam.

sLoTeRRR · Answer

Free sample i programowa implementacja SPI-jest banalna Z tymi freesamplami z maxima mam pozytywną przeszłość oprócz tych wypaśnych mikrokontrolerów z TCP i CAN'em. pozdrowionka

tadzioor · Answer

A z jaką prędkością ma działać ten drugi UART ?. Jeżeli nie większą niż 4800bps oraz nadawanie i odbiór nie odbywają się jednocześnie, to ja zrobił bym go na twoim miejscu programowo.

h-doc · Answer

już odpowiadam:
- darmowe próbki nie wchodzą w grę, bo muszę tego zrobić kilkadziesiąt sztuk
- jeszcze nie wiem z jaką prędkością będzie chodzić ten drugi UART (bo nie dostałem jeszcze specyfikacji) ale będzie to raczej jeden z wolniejszych trybów

Tdv · Answer

W takim układzie ja bym jednak polecał rozwiązanie z dodatkowym uC np. Będzie szybciej i znacznie prościej bo programowy UART to wcale nie taka prosta rzecz, szczeglnie jezeli procesor masporo zajęć.

h-doc · Answer

ok - dzięki wszystkim - decyzja podjęta. Dodatkowy UART będzie na drugej pięćdziesiątcejedynce

rav.k · Answer

Też mimo wszystko,że już po fakcie skłaniałbym się do programowego rozwiązania jeżeli już nie chcesz zmieniać na uP z dwoma UART. Programowa realizacja wcale nie jest taka straszna. Z drugiej strony dwa układy pozwolą Ci na szybsze prędkości i większą uniwersalność.

Eagle · Answer

Wiem że temat już zamknięty ;( ,

Ale idąc za wszym rozyślaniem to proponuję tak kupic najbogatszy '51 lub AVR a następnie gdy będzie potrzebny przetwornik A/D, to połaczyc zewnętrzny sprzętowy albo drugi taki sam uC z A/D, dodatkowo jeśli byśmy chcieli wysłac to RS to układ który zajmuje się konwersja A/D nie powinien tego robić weźmy kolejny. Jeszcze chciał bym zapalić diodkę to kolejny procek który będzie zajmował się tylko diodka. A jeszcze jak bym chciał posterowac buzerem to kolejny procek a co mi tam.

O.K. dosyc tej ironi a teraz na serio. Żyjemy w czasach kapitalizmu, gdzie najważniejszy jest pieniądz !. Więc jeśli zrobisz jeden projekt to gance gal bo koszty twojej prcy ( umysłowej przy pisaniu softu ) i dodatkowego układu będą podobne. Jeśli zrobisz natomiast 100 Twoich układów do jesteś dużo do tyłu z kasą bo do każdego układu muszisz dodać sprzetowy drugi
UART. Tym bardziej że jest to wykonalne -> 2 RS lecz jeśli podchodzisz do tego w en sposób -> "eh, nie chce mi się tego programować...) " to zapewnim Cię, że są osoby które zgarną kasę którą miał by zgarnąc pośrednik i producent sprzętowych UART'ów.

Pozdrawiam wszystkich leniuchów, Eagle

Hasło dnia

Złej baletnicy, przeszkadza rąbek u spódnicy.

Tdv · Answer

rav.k: przeczytałem dzisiaj kilka Twoich postów i się zastanawiam po co w ogóle coś piszesz. Pomijając fakt, że w tym poście nic nowego nie wniosłeś (w innych, które czytałem też nie) to może wykaż się swoją wiedzą i zapodaj tutaj tę softową implementację UART'a. Dobrze by było jakbyś podał też statystyki czasu potrzebnego uC do obsługi tych procedur (w zależności od szybkości transmisji) i oszacował przy jakim błędzie częstotliwości Twój S(oft)UART będzie nadal pracował prawidłowo.
Żeby nie było niedomówień: da się to zrobić ale może rav.k w końcu się wykażesz swoją wiedzą, a nie tylko propagandowymi hasłami.
Nie zapmnij podać dla jakiej częstotliwości kwarcu robisz.

h-doc · Answer

Eagle - zgadzam się z Tobą. Przy wielkoseryjnej produkcji na pewno nie mógłbym sobie pozwolić na 2 mikrokontrolery. Sytuacja jednak nie jest taka straszna, bo docelowo ma być kilkadziesiąt sztuk. Mój zleceniodawca ma poza tym trochę inne priorytety - ważniejszy jest dla niego czas realizacji całego projektu, niż końcowe koszty wyprodukowania płytki (zwłaszcza, że stanowią one niewielki procent kosztów produkcji całego urządzenia, w którym będzie pracować mój sterownik). Rozwiązanie prostsze (czyli 2 mikrokontrolery) jest szybsze a zatem korzystniejsze dla mojego zleceniodawcy (no i dla mnie też)

pozdrawiam!

rav.k · Answer

Szanowny Tdv Twoje wszechwiedza chyba Ci troszkę z kultury ujmuje. Nie życzę sobię żadnych inwektyw i kalumni z Twojej strony ponieważ nic nie mam do Ciebie więc i Ty pilnuj swego nosa a jak Ci nie pasuje to nie czytaj moich postów.
Wracając to tematu kiedyś planowałem programową transmisję i ją zrobiłem i sprawdziłem załącznik PROGR.C
Potem przesiadłem się na 517A i od tej pory korzystam z innych procedur które napisałem i dołączam tylko je do swoich projektów gdzy chce komunikacji szeregowej w rs232 lub 485. Pliki szer0.c szer1.c. Przykro mi że nie jestem kompatybilny do większości ponieważ widzę że używacie tu raczej ASSEMBLERA lub BASCOMa a ja piszę w ANSI C. Kwarc to 12MHz w komunikacji sprzętowej gdy robiłem programową to chyba miałem układ z kwarcem 11.059MHz. Dokładność programowej realizacji komunikacji jest bardzo duża wystarczy że dasz najwyższy priorytet od timera taktującego dla potrzeb komunikacji a wszystkie inne dasz na niższe priorytety. Są to pliki wyrwane z moich projektów bo nie mam zamiaru specjalnie dla Ciebie pisać programów prezentacyjnych, ale jeżeli masz zielone pojęcie o programowaniu to napewno zrozumiesz ideę działania komunikacji sprzętowej i programowej którą zastosowałem.
Pozdrawiam.

h-doc · Answer

hmmm - dzięki za listingi. Ja również preferuję C. Przyjrzałem się bliżej realizacji programowej i u mnie byłaby raczej nie do przyjęcia, ponieważ za bardzo absorbuje czas procesora. Ja muszę się komunikować z prędkością 300 bodów, co dawałoby dosyć spore zastoje w pracy mikrokontrolera, przy przesyłaniu kilku bajtów.

rav.k · Answer

dlatego uważam że należy przede wszystkim wykorzystywać to co oferuje procesor czyli sprzętowa realizacja komunikacji. Programowa jest fajna jeżeli procek nie ma nic innego do roboty oprócz odmierzania czasów na potrzeby RS. Sprawdzałeś sprzętową h-doc - u mnie sprawdza się 100% (zależy oczywiście w czym pracujesz), co do programowej realizacji nie ma alternatytwy tak musi być. Cieszę się, że nie jestem osamotniony w swoim ANSI C.

h-doc · Answer

rav.k - jeszcze nie robiłem oprogramowania - na razie kończę schemat i zaczynam projekt PCB. Oprogramowanie będę robić na końcu, jak już będzie gotowa płytka. pozdrawiam!

Tdv · Answer

rav.k: Trzebabyło zaraz coś mądrego napisać to bym się nie czepiał. Zresztą sam przejrzyj swoje posty z poprzedniego tygodnia i pokaż mi, który z nich wnosił coś NOWEGO do sparwy?
Przejrzałem pobierzenie szer1.c i nie mam większych zastrzeżeń.
Co do mojej wszechwiedzy - to nie uważam żebym taką posiadał, a wręcz przeciwnie, uważam że się muszę jeszcze sporo nauczyć (i zawsze będzie coś, czego się trzeba będzie uczyć). Co do C, BASCOMa i asm to przejrzyj moje posty - jestem chyba największym na elektorda.pl propagatorem tego języka dla uC (chidzi mi o C), choć faktycznie masz rację, że większość preferuje BASCOM'a, a całkiem sporo asm.

rav.k · Answer

Tdv - dodatkową przeszkodą w podawaniu przeze mnie gotowych przykładów jest to że od dawien dawna programuję 517A a większość używa 51 niby to samo a jednak znaczna różnica. Co sądzisz na temat programowego rozwiązania transmisji, na prawdę działało.

Tdv · Answer

Napisałem już, że tylko pobieżnie przejrzałem plik szer1.c, a trzeba by sie przyjrzeć dokladniej. Podstawowe zastrzeżenie jakie się nasu(ó)wa od razu to czasochłonność tego UART'a. Procesor praktycznie nic inneg nie będzie w stane robić, tylko orać UART'a, szcególnie przy większych szybkościach transmisji.
No ale to niestety wada S(oft)UARTA...

tadzioor · Answer

Krążą tu jakieś mity o czasochłonności porgramowego UART. Procedura, którą kiedyś napisałem przy transmisji 2400bps i kwarcu 18,432MHz zajmowała procesorowi niecałe 10% czasu, czyli przy transmisji 300bps, jak chce h-doc, obciążenie procesora wyniosło by około 1,25%. Procedura wykorzystuje timera2 i jest napisana w asm.

Tdv · Answer

tadzioor: tak z ciekawości, napisz jeszcze jaki to był procek to raz, a dwa to nie zawsze stać nas na te 10% czasu uC bo to sporo... Zresztą wkładanie kwarców 18,xxxxMHz też nie zawsze jest najlepszym rozwiązaniem bo z takim speedem toprocek będzie niezły prądzik pobierał.
Może zapodasz tę procedurkę?
PS. procedura rav.k zajmuje bardzo dużo czasu bo jest rozbudowana o komunikaty o błędach itp., jakby ją z tego ogołocić, to też wyjdzie trochę bardziej ekonomiczna wersja.

tadzioor · Answer

Procesor jak w temacie (dokładniej AT89S53). Co do wartości kwarcu, poboru prądu, szybkości itp. to wszystko zależy od konkretnej aplikacji i nie ma co tu spekulować.
Jak znajdę trochę więcej czasu to postaram się zamieścić tą procedurę. Muszę ją najpierw trochę zmodyfikować bo wyrwana z programu nie nagaje się do publikacji, zresztą nie pozwalają mi na to przepisy firmy w której pracuje.

Jak zrealizować 2 UART-y w urządzeniu z AT89Cxx i RS232C?

Jak zrealizować dwa niezależne interfejsy UART/RS232 w urządzeniu opartym o AT89Cxx, gdy oba łącza muszą działać prawie jednocześnie?

Post #1

Post #2

Post #3

Post #4

Post #5

Post #6

Post #7

Post #8

Post #9

Post #10

Post #11

Post #12

Post #13

Post #14

Post #15

Post #16

Post #17

Post #18

Post #19

Post #20

Post #21

Post #22

Post #23

Post #24

Post #25

Post #26

Post #27

Post #28

Post #29

Post #30

Podsumowanie tematu