Dziwny problem z RS485 + AVR

Był czw, 04. sierpień 2005 19:29 gdy "dziadek Ben" snipped-for-privacy@op.pl napisał(a):

Od strony PC jest:

Od strony AVRa: procek to ATtiny2313, pull-upy obecnie to potencjometry ustawione na 670omów

program którym to testuje uprościłem już na maksa jak się dało i przy włączonym cały czas nadajniku wysyła stały znak non-stop:

#define F_CPU 8000000UL #define delay_us(x) for (loop=0; loop<x; loop++) _delay_loop_2(1000);

#include <avr/io.h>

#include <avr/interrupt.h>

#include <avr/delay.h>

#include <avr/signal.h>

#include <avr/eeprom.h>

#include <avr/sfr_defs.h>

#include "bits.c"

typedef unsigned char u08;

void usart_init(); void USART_Transmit(u08 data); volatile int data=0; volatile int adr=0; void usart_init() { // set UART options UBRRH = 0;// 19200 bps dla 8 MHz UBRRL = 25; //25,51,103 | _BV(RXCIE) UCSRB |= _BV(TXEN); //| _BV(TXCIE);// Tx Complete Interrupt & EnableTx // UCSRB |= _BV(RXEN) | _BV(RXCIE);// Rx Complete Interrupt & EnableRx UCSRC = _BV(UCSZ1) | _BV(UCSZ0);// 8N1}

void USART_Transmit( u08 data ) { /* Wait for empty transmit buffer */ while ( !( UCSRA & (1<<UDRE)) ) ; /* Put data into buffer, sends the data */ // s_bit(&PORTD,PD6); //c_bit(&PORTB,PB2); UDR = data; }

int main(void) { // Initiate Ports DDRB = (1<<PB2); //wyjscie na pb2 DDRD = (1<<PD6); //wejscia + wyjscie na pd6 s_bit(&PORTB,PB2); //zgaszone c_bit(&PORTD,PD6); //wylaczony nadajnik int loop=0; usart_init(); sei();// Enable global interrupts u08 i,pierwszy,drugi;

int licznik = 0; int interval=50; u08 bum=180;

c_bit(&PORTB,PB2); s_bit(&PORTD,PD6); /wlacza nadajnik

while(1)// Loop forever { //continue; // USART_Receive();//(u08)licznik); // USART_Transmit((u08)0x80); UDR = 123; delay_us(14);

UDR = 56; delay_us(14);

}//main loop }

Tomek Głuch napisał(a):

Jakiś czas temu wypłakałem na grupie żale do MS za spieprzone sterowanie linią RTS w win. Czy jesteś pewny, że twój port RS232 prawidłowo steruje kierunkiem ? Bo ja w końcu dałem sobie spokój i zmontowałem układ z linią opóźniającą.

PS. Coś mi się zdaje, że po dzisiejszych walkach z moim RS485 mam ochotę komuś wpie... w MS za spieprzone timeouty na RS dla krótkich czasów. Muszę sprawę obadać, ale coś mi się widzi, że znowu dali ciała.

Chyba pozostaje zrobić porządny konwerter RS232->RS485 na jakimś uC.

1. Na schemacie masz 75184 i odwrotnie popodciągane B i A. Ale zamienione są obie linie w porównaniu do 176 to może jest dobrze.
2. Po stronie PC lepiej połączyć DE z /RE bo będziesz miał echo.

3.Spróbuj wysterowacć linie ręcznie: Po stronie PC DE/RE na niski po stronie AVR na wysoki i ręcznie wymuszaj stany na lini D po stronie AVR ( możesz wyjąć procka). Powinno ustawiać AVR 5V -> RS232 -10V AVR 0V -> RS232 +10V

Był czw, 04. sierpień 2005 22:19 gdy "dziadek Ben" snipped-for-privacy@op.pl napisał(a):

No właśnie na tym polega problem, że nie jestem szczęśliwym posiadaczem oscyloskopu :( Jak włączam driver-enable od strony procka czy też PC to widać wyraźny zmian napięć na linii. Nie mam zielonego pojęcia co w tak prostym urządzeniu może być źle. Pewnie jakaś pierdoła a ja się już tym ponad tydzień męcze :(

Był czw, 04. sierpień 2005 21:44 gdy Sebastian Biały snipped-for-privacy@poczta.onet.pl> napisał(a):

Jestem szczęśliwym użytkownikiem systemu GNU/Linux i ten problem tak bardzo mnie nie dotyczy. Poza tym narazie ręcznie steruje linią RTS za pomocą specjalnego terminala który ma takie funkcje (gtkterm). Zresztą póki co transmisja jest z prędkością dźwięku w próżni :) włączam nadawanie, przyciskam literke, wyłączam, a w procku jest delay na kilka sekund i echo. Próbowałem też zapisywać do eepromu to co on dostaje ale też były zera albo same śmieci.

Był czw, 04. sierpień 2005 21:49 gdy "marco" snipped-for-privacy@wp.pl napisał(a):

W przejściówce odbiornik jest na stałe włączony a nadajnik w zaleznosci od linii RTS. Od strony uC sterowanie DE i RE jest z jednego pinu kontrolera. Poza tym jak napisałem program który stan PIND 0 przekazuje na diodę LED to ładnie migała w rytm odbieranych znaczków. Wygląda na to jakby USART nie rozpoznawał znaków. Ale jak połączyłem uC na krótko z MAX232 to program do wysyłania echo smigał pięknie.

Tomek Głuch napisał(a):

Pytanie czy linia RTS jest sterowana hardwareowo, czy też OS musi nia machać. W drugim przypadku może to być również Twój problem przy normalnych szybkościach.

Zdiagnozuj magistralę RS485.

Miernik w łapę (najlepiej analogowy) i sprawdź czy:

a) W stanie spoczynku linia A>B (najlepiej pozbądź sie terminatorów

120Ohm na końcach jesli to tylko krótki kawałek drutu). Na schemacie widze odwrotnie. b) Przy wysyłaniu ciągu znaków miernik się lekko wychyla na liniach AB. c) Czy miernik podpięty pod nogę RX procesora też się lekko wychyla. e) Bez względu na problem z polaryzacją A/B i tak przy nadawaniu procesor MUSI coś usłyszeć - jesli nie generuje przerwania, to prawie na pewno nie ma zmiany sygnału na jego nodze RX. f) Zmień scalaki na 75176, te u mnie działają :) g) Bez względu na problemy steruj u mastera RE bo echo jest złym pomysłem. h) Jeśli masz miernik częstotliwości to podepnij go pod AB i nadaj jakiś znak - powinien coś pokazać. i) Jesli wszystko zawiedzie to podesle schemat działający: Max232,75176,CD4047.

Moja propozycja - włacz jedną diodę w przerwaniu UART RX - sprawdzisz w ten sposób czy wogóle coś dostaje na wejściu.

Tomek Głuch napisał(a):

Prawdopodobnie dlatego że masz źle pullupy A i B. Ma być A do + i B do

-, wtedy masz na lini w stanie spoczynku logiczną "1" i włączenie drivera nie spowoduje zmiany stanu. Dopiero nadanie znaku spowoduje zaburzenie na lini.

Pamiętaj że w RS232 logiczne "1" odpowiada stanowi ciszy a nie 0. Ia najlepiej własnie tak spolaryzować AB.

Był czw, 04. sierpień 2005 23:50 gdy "Michał" snipped-for-privacy@wp.pl napisał(a):

no przedtem miałem diody na tx i R/T ale je wylutowałem gdyż podejrzewałem je o osłabianie sygnału (tonący brzytwy się chwyta :) Zdaje się, że będą musiały wrócić.

Był czw, 04. sierpień 2005 22:42 gdy Mariusz Dybiec snipped-for-privacy@poczta.onet.pl> napisał(a):

Narazie wyłączyłem terminatory i pull-upy. Zabrałem się za zrobienie konwertera jeszcze raz i nie na pajączku [prowizorki są bee] i zauważyłem, że w nocie MAX232 zarówno kondensatory od V+ jak i V- (nozki 2 i 5) są podłączone do masy, a na tym schemacie jeden z nich jest do +5V. Dziwne że konwersja 232/TTL działała jak należy. Po stronie AVR chyba nic już źle nie może byc :)

Był czw, 04. sierpień 2005 22:42 gdy Mariusz Dybiec snipped-for-privacy@poczta.onet.pl> napisał(a):

Narazie wyłączyłem terminatory i pull-upy. Zabrałem się za zrobienie konwertera jeszcze raz i nie na pajączku [prowizorki są bee] i zauważyłem, że w nocie MAX232 zarówno kondensatory od V+ jak i V- (nozki 2 i 5) są podłączone do masy, a na tym schemacie jeden z nich jest do +5V. Dziwne że konwersja 232/TTL działała jak należy. Teraz patrze i na róznych schematach w sieci też tak jest. np

nota nie kłamie?

Po stronie AVR chyba nic już źle nie może byc :)

Był czw, 04. sierpień 2005 22:42 gdy Mariusz Dybiec snipped-for-privacy@poczta.onet.pl> napisał(a):

Narazie wyłączyłem terminatory i pull-upy. Zabrałem się za zrobienie konwertera jeszcze raz i nie na pajączku [prowizorki są bee] i zauważyłem, że w nocie MAX232 zarówno kondensatory od V+ jak i V- (nozki 2 i 6) są podłączone do masy, a na tym schemacie jeden z nich jest do +5V. Dziwne że konwersja 232/TTL działała jak należy. Teraz patrze i na róznych schematach w sieci też tak jest. np

nota nie kłamie?

Po stronie AVR chyba nic już źle nie może byc :)

Zawsze coś może być źle. Ręcznie wymuszająć stany na wejściu D możesz sprawdzić kolejno: czy jest zmiana polaryzacji napięcia na liniach A-B, czy jest zmiana

0->5V na R i -10->+10 na T2IN. Ale można też zrobić układ od nowa licząc, że teraz nie będzie błędu :)