Jak poprawnie zestawić połączenie UART ATmega8535 z komputerem na Linuxie?

Witam,

mam problem z zestawieniem połączenia UART'u mikrokontrolera ATmega8535 i kompa. Kod programu po stronie mikrokontrolera był deasemblowany, i na pewno ustawiane są poprawne wartości odpowiednich rejestrów. Zadbałem również o to, zeby ustawiane parametry po stronie kompa były takie same, tj. baud rate = 9600, 8 znaków w ramce, jeden bit stopu i brak parzystości.
Po stronie AVR'a wszystko wydaje sie działać jak potrzeba (co 200ms wysyłam coś w świat, i następują skoki napięcia na nóżce txd, na nóżce rxd sygnał wysoki cały czas - ok. 11.5V).

Pracuje na linuxie. O co jeszcze powininem zadbać aby zestawić transmisje? Dodam, ze mam poprawnie ustawione adresy portów w biosie, w jądrze obsługa portów jest wkompilowana, z poziomu aplikacji dostęp do portów uzuskałem jako root.

Wyczytałem ze są dwa standardy 9-pinowych gniazdek D-Sub, przy czym w obu zamienione są piny rxd i rxd. Czy moze to być przyczyną rozjeżdzania się transmisji?

Będę wdzięczny za wszelką pomoc.
Pozdrawiam,
dziobass.

Napisz jaki masz problem, bo do tej porty nie opisałeś istoty.

Tak jak napisałem, problemem jest to ze nie moge zestawić połączenia. Czy po stronie PC mam zadbać o ustawienie czegoś więcej niż formatu ramki (wielkość słowa, liczba bitów stopu i parzystość), oraz szybkości transferu (baud rate)?

Zanipokoiło mnie to co znalazłem na tej stronie: ttp://www.easysw.com/~mike/serial/serial.html.
Opisane są tu dwa standardy gniazdek D-Sub9. Możliwe, ze moje problemy wynikają z tego, ze te standardy zostały pomylone w sterowniku , który oprogramowuje ...

dziobass napisał:

Tak jak napisałem, problemem jest to ze nie moge zestawić połączenia. Czy po stronie PC mam zadbać o ustawienie czegoś więcej niż formatu ramki (wielkość słowa, liczba bitów stopu i parzystość), oraz szybkości transferu (baud rate)?

Kontrole przepływu ustaw na programową, jeśli wybierzesz sprzętową, to komputer będzie czekał/generował sygnał RTS/CTS/DTR/....

dziobass napisał:

Zanipokoiło mnie to co znalazłem na tej stronie: ttp://www.easysw.com/~mike/serial/serial.html.
Opisane są tu dwa standardy gniazdek D-Sub9. Możliwe, ze moje problemy wynikają z tego, ze te standardy zostały pomylone w sterowniku , który oprogramowuje ...

Raczej mało prawdopodobne, w komputerach PC jest stosowany ten standard opisany jako RS574, jedyne co mogłeś pomylić to w swoim urządzeniu, albo wziąć zły kabel.

dziobass napisał:

Po stronie AVR'a wszystko wydaje się działać jak potrzeba (co 200ms wysyłam coś w świat, i następują skoki napięcia na nóżce txd, na nóżce rxd sygnał wysoki cały czas - ok. 11.5V).

Hm, mam nadzieję, że zastosowałeś jakiś konwerter napięć i nie podajesz tyle bezpośrednio na procka? Upewnię się jeszcze, że wiesz, iż TX procka łączysz z RXD i analogicznie RX z TXD?
A wyświetlają ci się chociaż jakieś krzaki? Jeżeli tak - oznacza to, że źle dobrałeś parametry transmisji.
Pod linuxem możesz popróbować minicomem. Pogrzebałem trochę na dysku i znalazłem fragment kodu, który sobie napisałem do obsługi RS232. Może ci się przyda? Zauważyłem, że nie ma w nim obsługi prędkości, więc dogrzebałem się jeszcze czegoś, co też kiedyś napisałem - klasy do C++.

Witam,
Chciałbym zauważyć, że w RS-232C stan wysoki to napięcie ok -10V a stan niski odpowiednio +10V.
Może to jest główny problem uniemożliwiający poprawną transmisję ?

A jak juz jest taki temat to nie bede zakladal swojego tylko spytam tu

Ma ktos moze gdzies gotowy program do pogawędęk PCtowo mikrokontrolerowych przez RS232. Albo chociaz namiary na jakas stronke gdzie taki moge znalezc. Od tygodnia siedze nad teoria i mysle ze juz czas zrobic cos konkretnego
Interesowalby mnie program wlasnie na ATmega8535 i drugi od strony komputera. Jezyk C mile widziany

sprawdż stronę sprzętową jak i zastosowany w AVR kwarc. najlepiej jak by był 11.059mHz

poniżej dołączam program który odbierze to co wyślesz ( max 64 znaki ) i odeśle ci po 100 ms
dołącz kwarc 4 Mhz
prędkość koma = "9600,n,8,1"
pozdrawiam


Zapomniałbym, każda transmisja musi być zakończona "enterem" ( chr(13), Vbcr

Nie chciałem zakładać nowego tematu, więc z moim problemem podepną się tutaj. A mianowicie, mam wyświetlacz VFD sterowany standardem RS232. Podobno przyjmuje poziomy TTL. Złożyłem więc ukłąd jak na schemacie. Napisałem takie oto procedurki:

#define XTAL_CPU 6000000
#define CYCLES ((XTAL_CPU+500000)/1000000)
#define UB_RATE ((XTAL_CPU)/((BAUD)*16L)-1)
#define BAUD 4800

void uart_init(void)
{
UBRRH = (unsigned char)(UB_RATE>>8); // uart baud rate
UBRRL = (unsigned char) UB_RATE;
UCSRB = (1<<TXEN); // tranciver enable
UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); // asynchronous no parity 1 stop bit 8 bit frame
}
void uart_putc(unsigned char data)
{
while (!(UCSRA & (1<<UDRE)));
UDR = data;
}

Wyświetlacz na 100% sprawny, bo podłączałem go pod kompa. Problem w tym, że w tym układize nie działa. Albo nic nie wyświetla, albo idę jakieś krzaki. Spróbuje podesłać też dokumentację tego VFD. O standardzie TTL jest tam na 5 stronie. Ramka to 4800,n,8,1. Serdeczne dzięki za pomoc.

a może powinien tam być jeden inwerter...

Dodano po 2 [godziny] 33 [minuty]:

Dobra... mój błąd... faktycznie powinien być jeden inwerter. Ale problemy nadal są. Poprawnie wysyłane są tylko 2, 3 znaki... Potem znowu idą krzaki

:euromatic:

A jakie mam szanse na to zeby dostac zrodlo - znaczy cos z rozszerzeniem .c? :>

To jest dopiero mój pierwszy program w C... ale proszę...

nie mam pojęcia o co chodzi... z całego stringa odbiera tylko kilka pierwszych znaków... próbowałem zmienić z 1 bitu stopu na dwa... efekt praktycznie ten sam... używałem nawet innych bibliotek i nic...

dzieki wielkie

Wczoraj z kolegą posiedzieliśmy i udało nam sie wychwycić kilka bugów, zarówno sprzętowych jak i softwarowych. Wieczorkiem udało mi sie nawiązać połączenie pomiędzy komputerem a sterownikiem (nie udało sie ustabilizować transmisji, ale przynajmniej od strony sprzętowej zadziałało tak jak trzeba - impulsy elektryczne o właściwych wartościach). Dziś zlokalizowałem poważnego buga. Napiszę tu o nim ku przestrodze innych

Otóż w ATmega8535 rejestry UBRRH i UCSRC dzielą tą samą przestrzeń adresową (ładnie brzmi , ale w praktyce chodzi o to, że odwołania do obu rejestrów odbywają się przez ten sam adres). W związku z tym zastosowano specjalną procedure odczytywania i zapisywania tych rejestrów:
- aby odczytać UBRRH: in r16, UBRRH
- aby odczytać UCSRA: in r16, UBRRH
in r16, UCSRC
- aby zapisać UBRRH: in r16, UBRRH
in r17, UCSRC
andi r17, 0b01111111
out UCSRC, r17
out UBRRH, r16
- aby zapisać UCSRA: in r16, UBRRH
in r16, UCSRC
andi r16, 0b11111111
out UCSRC, r16
out UCSRC, r17

A teraz po krótce wytłumacze o co w tym chodzi. Otóż podczas odczytywania rejestru UBRRH nie musimy stosować żadnych sztuczek. Podczas odczytywania rejestru UCSRC, musimy dwukrotnie odczytać rejestr spod tego samego adresu (jeśli ktoś spojrzy w dokumentacje, zobaczy, ze do obu rejestrów dostajemy sie poprzez adres 0x20). Pierwszy odczyt zwróci nam zawartość rejestru UBRRH, podczas gdy drugi odczyt zwróci UCSRC.
To była ta łatwiejsza część
Czas na zapis. Otóż specyfikacja mówi, ze w momencie zapisu do rejestru UBRRH, bit URSEL (najbardziej znaczący) w rejestrze UCSRC musi byc wyzerowany. To realizuje nam instrukcja andi r17, 0b01111111, po czym dokonujemy zapisu do rejestru UCSRC. Następny zapis jest tym właściwym zapisem do UBRRH.
Podobnie sprawa wygląda z zapisem do UCSRC, z tym ze w czasie zapisu bit URSEL powinien być ustawiony.

Podobne modyfikacje powinny być możliwe poprzez instrukcje sbi i cbi. Fragmenty te napisałem nie przetestowawszy ich jeszcze, więc nie potrafie zagwarantować, że zadziałają, ale zgodnie z dokumentacją powinny .

Pozdrawiam,
dziobass.

Kod, który zamieściłem w załącznikach działa bez zarzutów. Problemem okazała się inicjalizacja portów. Nie mam pojęcia dlaczego, ale po operacjach na rejestrze DDRD USART nie chodził. Nawet jak nie zmieniałem nic w bicie TX. może pomoże najpierw inicjalizować USART a potem porty... nie wiem.. sie zobaczy. Jak na razie sprawa otwarta.

Datasheet/I/O-Ports/Alternate Port Functions/Alternate Functions of Port D s. 63 :

Cytat:

• TXD – Port D, Bit 1
TXD, Transmit Data (Data output pin for the USART). When the USART Transmitter is enabled, this pin is configured as an output regardless of the value of DDD1.
• RXD – Port D, Bit 0
RXD, Receive Data (Data input pin for the USART). When the USART Receiver is enabled this pin is configured as an input regardless of the value of DDD0. When the USART forces this pin to be an input, the pull-up can still be controlled by the PORTD0 bit.

Cudów raczej nie ma, ustawiaj bit od RXD w stan wysoki, a dla porządku od TXD też nie zawadzi...
--
Pozdrawiam, Daniel