max485 i AVR

Paweł napisał(a):

Nie potrzeba, mozna zewrzec i sterowac jednym pinem /odbior i nadawanie

Tak, odbieralbys to samo co wysylasz, tak samo jakbys zwarl RxD z TxD w procku. Czasem jest to przydatne - kontrolnie mozesz sprawdzic czy magistrala rs485 nie jest zwarta - jesli by byla (albo uwalony driver) to bys nie odebral.

Na koncach magistrali potrzebujesz terminatory (dla skretki okolo

- po co grzac caly czas ~5v w 60ohm (2 terminatory) przez driver jak wystarczy duzo mniejszy prad by zdecydowanie okreslic poziom.

Od strony programowej je¶li to jest master to umiejêtnie trzeba wykryæ kooniec nadawania ¿eby wy³aczyæ nadajnik (w slave te¿ to trzeba zrobiæ). W AVR transmisja zaczyna siê po za³adowaniu rejestru i trwa jeszcze jak±¶ chwikê normalnie procedurka wys³ania bajtu wyglada tak (w asm):

USART_Transmit:

; Wait for empty transmit buffer

sbis UCSRA,UDRE

rjmp USART_Transmit

; Put data (r16) into buffer, sends the data

out UDR,r16

ret

Bit UDRE w rejestrze UCSRA informuje o gotowo¶ci do przyjêcia nastêpnego bajtu do wys³ania ale nie o zakoñczeniu transmisji! ¿eby poprawnie rozpoznaæ koniec transmisji mo¿na wykorzystaæ stosowne przerwanie lub (ja tak zrobi³em i dzia³a) wykorzystaæ bit TXC (Transmision complet) w rej. UCSRA. Bit ten informuje ¿e bajt zosta³ wyemitowany, ale uwaga je¶li nie korzystasz z przerwañ to bit ten jest w stanie niskim (0) czyli nie bedziesz wiedzia³ ¿e jeszcze wysy³a. Ja to zrobi³em tak, przed wys³aniem ostatniego bajtu ustawiam bit TXC, potem wysy³am bajt i nastêpnie czekam a¿ bit zostanie wyzerowany. Je¶li zosta³ wyzerowany to wy³±czam nadajnik ( u mnie na linii D7)

sbi UCSRA,TXC rcall USART_Transmit wait_transmit2: ;czeka na opró¿nienie bufora transmisji sbis UCSRA,TXC rjmp wait_transmit2 cbi PORTD,7 ;Wy³±czenie nadajnika

Paweł napisał(a):

Możesz spokojnie zewrzeć i używać jednej linii.

Musisz odczekać koniec nadawania, dopiero wtedy przełączasz na odbiór.

Tak.

Jak pod sprzętowy port RS procka się podłączasz potrzebujesz inwerter między prockiem a max'em. Chyba że robisz RS'a całkowicie programowo, to w programie możesz odwrócic. No i nie znam AVRa, może jest opcja odwrócenia, w PIC'u nie ma.

U¿ytkownik "Piotr [PKi]" snipped-for-privacy@wp.pl napisa³ w wiadomo¶ci news:e4kalv$7kh$ snipped-for-privacy@nemesis.news.tpi.pl...

Pierwsze s³yszê ! P.G.

Piotr Gałka napisał(a):

No dziwne, u mnie tak działa, bez inwertera nie działało, odbierałem tylko jakieś bzdety, po odwróceniu sygnały między prockiem a maxem ruszyło normalnie.

Czy zmiana kierunku w pętli prądowej (A-B) może mieć wpływ?

Piotr [PKi] napisał(a):

Oczywiscie, zmiana petli A-B daje dokladnie to samo, co wstawienie negatorow na liniach RxD i TxD ;) Niektore drivery lini 485 maja wlasnie taka fajna nozke - wlaczajaca negacje, dzieki czemu mozna softowo zrobic korekte "jesli nic nie dziala, to moze klient odwrotnie kable podlaczyl"

U¿ytkownik "Piotr [PKi]" snipped-for-privacy@wp.pl napisa³ w wiadomo¶ci news:e4pp1t$59b$ snipped-for-privacy@nemesis.news.tpi.pl...

Je¶li nie masz rezystorów ustawiaj±cych A wy¿ej od B (o minimum 0,2V w ka¿dym punkcie sieci) to w stanie gdy nikt nie nadaje (A=B) odbiornik ma stan nieokre¶lony (zale¿ny od egzemplarza), a UART chcia³by mieæ 1-kê. Je¶li trafi³e¶ na egzemplarze, które dla A=B daj± 0 to negatory pomog³y, ale to pod warunkiem, ¿e wszystkie drivery w sieci mia³y akurat tak samo. Jak zbudujesz kolejny egzemplarz mo¿esz trafiæ na driver, który ma odwrotnie i ju¿ go do tej sieci nie pod³±czysz. P.G.