Analiza dziwnego oscylogramu RS485 z PIC17C42 nieprawidłowy format transmisji?

Wed May 27, 2009 12:58 pm   

Za poradą grupowiczów zmontowałem sobie (duże słowo wtyczkę do LPT (nie
mam cyfrowego oscyloskopu), i za pomocą programu Digitrace zacząłem
podglądać co się dzieje
na łączu RS485 (dla przypomnienia - próbuję wyczaić, jaka jest prędkość i
format transmisji pomiędzy modułami pewnego systemu, opartego na PIC17C42 z
zegarem 16Mhz).

No i prawdę mówiąc lekko jestem w polu, bo to co widać, wygląda chyba
dziwnie...

Tutaj można zobaczyć jak toto wygląda :
http://www.savefile.com/projects/808769424

(1 plik to dane z Digitrace, 2 i 3 to zrzut ekranu pokazujący przechwycone
dane).

Patrzę na toto i za cholerę nie widze w tym jakiegoś sensownego formatu typu
bit startu, bity danych, parzystosc, stop... i w dodatku ten pojedynczy
"bit" następujący po całej sekwecji.
Kiedy patrzę na to na oscyloskopie to wygląda podobnie (oscyloskop analogowy
więc trudno złapać, ale ogólnie to samo - czyli nie jest to raczej błąd
"przechwytywania" przez LPT).

USART w PIC17C42 jest do bólu standardowy. Tyle, że parzystość nie jest tam
generowana sprzętowo, co każe domniemywać, że pewnie nie jest uzywana, bo
musiałaby być obliczana
programowo. No ale to mniejsza. Prędkości transmisji też są do obliczenia
(Fosc / (64*(n+1)), gdzie n=0 do n=255.
Czyli max. 250 kbit dla tego kwarcu (16.000.000 / (64*1)) = 250.000

Może ktoś spojrzy i się wypowie, bo już nie wiem...

No nie chce mi się wierzyć, że program jakoś "ręcznie" manipuluje w
transmisji, bo to są dość proste moduły ("centralka" i moduły ściemniaczy do
żarówek).
Żaden kosmos.

Co myślicie ?

Wed May 27, 2009 1:01 pm   

zauważyłem że serwis na którym umieściłem zdjęcia dodaje do rozszerzenia
pliku "htm" nie wiadomo po co...zatem gdyby był po ściągnięci problem z
otworzeniem, trzeba zmienić rozszerzenie na jpg rzecz jasna

Wed May 27, 2009 2:30 pm   

Użytkownik "sundayman" <sundayman@poczta.onet.pl> napisał w wiadomości
news:gvj9t1$be9$1@news.onet.pl...


Po pierwsze, nie wiem w którym miejscu zdejmujesz ten sygnał, ale wygląda
on jakby odwrotnie. W każdym razie to długie 0 jest lekko bez sensu. Poza
tym wszystko wygląda w miarę normalnie - jak dla mnie to, co zaznaczyłeś
znacznikami to pojedyncza transmisja wartości 0 (na nieznanej liczbie
bitów), przy czym bit stopu wygląda na przedłużony. Prędkości z tego nie
odczytasz, bo jeśli transmisja nie jest automatycznie buforowana, to czas
po bicie stopu może być dowolny. Ilość bitów danych też może być różna. Co
jakiś czas jednak pojawiają się krótciutkie impulsy i to one powiedzą Ci,
jaka jest prędkość transmisji. Musisz znaleźć najkrótszy z tych impulsów i
sprawdzić, czy dłuższe są jego wielokrotnością - z tego od razu wyjdzie
ilość bitów danych.

A serwis, w który to wrzuciłeś... delikatnie mówiąc mocno zniechęca do
zapoznania się z Twoim problemem...

e.

Wed May 27, 2009 2:42 pm   

No tak, racja, tak na szybko szukałem, przepraszam za niewygodę...poprawię
się na przyszłość :)

Sygnał jest zdejmowany bezpośrednio z pinu 2 (RXD) złącza RS232 tego
konwertera RS485 <> RS232.
Zrobię jeszcze jedną rzecz za chwilę - odwróce polaryzację sygnałów na
Rs485, bo wcześniej mi to nie przyszło...

Wed May 27, 2009 3:06 pm   

No cóż, po odwróceniu polaryzacji odwrócił się po prostu sygnał Czyli
teraz tam gdzie była "1" jest "0" i na odwrót...

teraz wygląda tak
http://picasaweb.google.com/lh/photo/e4TDKTBoSw3z31ZOeJRikw?authkey=Gv1sRgCKygrJDX6Njf8QE&feat=directlink

(mam nadzieję, że tutaj będzie lepiej z obrazkami :)

A co do szybkości...hmmm... wychodziłoby, że przy najwyższej dostępnej
szybkości czyli 250kb. to długość "bitu" to 40us. Czyli teoretycznie krótsze
impulsy nie mają prawa się pojawiać. A pojawiają się jak najbardziej - na
przykład 7uS :)

Może coś nie tak z tym konwerterem RS232<>RS485 ?

Wed May 27, 2009 3:10 pm   

Użytkownik "sundayman" <sundayman@poczta.onet.pl> napisał w
wiadomości news:gvj9t1$be9$1@news.onet.pl...

To co masz na dluzszym okresie sugeruje ze odczyt jest zanegowany -
tzn dolny stan na wykresie odpowiada 1 - bity stopu.
Na zblizeniu - to co zaznaczyles wyglada na jeden znak.
Jakby nadawali 00, ale troche szeroki ten krotki impuls - jakby dwa
bity, wiec moze 80 lub bit parzystosci, lub dwa bity stopu

77.52us na znak, to tak w zaleznosci od ilosci bitow na znak da
bodow:

9 116099
10 128998
11 141898
12 154798

Jesli dobrze odczytales kwarc, to obstawialbym ze predkosc wynosci
125k, choc niewykluczone ze dla kompatybilnosci z pecetem dali 115k
[o ile pic na to pozwala] i 7 bit znaku +start+stop , ewentualnie
160k - i np 8p2.


FF, choc oczywiscie moze byc inaczej.



no to jednak 125k ..


A nie jest to przypadkiem DMX ?


J.

Wed May 27, 2009 3:17 pm   

Użytkownik "sundayman" <sundayman@poczta.onet.pl> napisał w
wiadomości news:gvjhca$212$1@news.onet.pl...

Podziel jeszcze raz, ale tym razem skorzystaj z kalkulatora :-)

J.

Wed May 27, 2009 3:19 pm   

Kwarc ma na pewno 16 MHz, procesor jest wersji 20MHz, więc się zgadza.

Odwróciłem polaryzacją na RS485 i oczywiście się poziomy odwróciły - jednak
teraz na konwerterze cały czas świeci mi się led RXD - czyli na RS485 jest
jakby cały czas "1" - to jest ok ? Wydaje mi się to dziwne...

Całość nie jest przewidziana do połączenia z PC, stąd mogą bez problemu
używać nietypowego 125kb.
A czy to nie jest DMX ? Wątpię - syste, wygląda tak : centralka + panel
dotykowy LCD + moduły ściemniaczy (bardzo proste : PIC + 5 triaków
sterowanych PWM) + moduły przekaźników (jeszcze prostsze : pic + kilka
przekaźników). Wszystko to połączone tym RS485. I koniec. Oprócz tych
modułów nie jest przewidziane podłączanie czegokolwiek "obcego".

Wed May 27, 2009 5:33 pm   

a propos długości impulsów a szybkości, no faktycznie wygłupiłem się
chyba...
Bom po prostu podzielił 1 / 250000 :)

Tak, że tegooo

Co do ilości bitów - w grę wchodzi chyba tylko 8 albo 9 - wg. datasheeta
PIC17C42.
(tu link
http://www.alldatasheet.com/datasheet-pdf/pdf/74981/MICROCHIP/PIC17C42.html)
I chyba tylko 1 bit stopu.

Ale ale, jest też taki problem, w interfejsie użyłem transoptorów CNY17. I
to może być wąskie gardło, bo one przy 250 kHz chyba już wysiadają...
Za datasheetem : czas włączenia 3 us, czas wyłaczenia 18 us (czasy minimalne
!). zatem obawiam się że cały ten konwerter można o kant d... rozbić.
Bo przy 250 kb czasy dla poszczególnych bitów są poniżej 10 us chyba jesli
tym razem dobrze policzyłem...

Ok, jutro spróbuję zrobić to bez transoptorów zatem i zobaczę co z tego
wyjdzie.

Wed May 27, 2009 5:45 pm   

sundayman wrote:


zapomnij
W porywach niektóre pracowały mi na RS-232 na 115,2kb/s, ale to tylko
niektóre ..

--
Pozdr.
Michał

Wed May 27, 2009 5:45 pm   

Użytkownik "sundayman" <sundayman@poczta.onet.pl> napisał w wiadomości
news:gvjhca$212$1@news.onet.pl...


najbardziej - na

7us daje Ci ok. 140kbps i wszystko się zgadza. Widać nawet impulsy mniej
więcej dwukrotnie szersze - nie wiem jak dokładnie ten Twój analizator
odwzorowuje czas, ale na nich pewnie będziesz mógł dokładniej ustalić
prędkość transmisji. W rzeczywistości jest tam prawdopodobnie 115200 albo
125000bps.

e.

Wed May 27, 2009 8:07 pm   

On Wed, 27 May 2009 18:33:25 +0200, sundayman wrote:

Dobrze chciales, tylko ze z tego dzielenia wychodzi 4us a nie 40.

A prawdopodobnie jest 125kbaud, i 8 us na bit - co widzisz.


To interfejs do COM, czy teraz do LPT ?
Bo na oko to w tym LPT dobrze sobie radzi...


J.

Wed May 27, 2009 11:28 pm   

Interfejs RS232<>RS485 jest podłączony do USB przez konwerter USB<>RS232
Dlaczego - bo ten konwerter USB<>RS232 pozwala na dowolne ustawienie
szybkosci transmisji. Na standardowym RS-sie komputera nie da się ustawić
250 kb. Jak pisałem, ten konwerter USB<>RS232 wyrabia sie bez problemu przy
250kb - sprawdzalem loopbackiem.

Natomiast do LPT mam podłączony jedynie kabelek, ktory z programem Digitrace
robi mi za cyfrowy oscyloskop :)

I ostatnio podłączyłem te "wejscia" LPT do pinu RXD mojego "wirtualnego"
RS232
Taka kombinacja

Thu May 28, 2009 7:14 am   

Użytkownik Sundayman napisał:

Jaki to konwerter USB<->RS232 i w jaki sposób obsługiwany ? Tzn. Własne
procedury korzystające z biblioteki .dll konwertera czy poprzez
urządzenie COM WinAPI ? Bo jeśli przez COM, to te 250kbps jest mocno
teoretyczne. Pojedyncze bajty są nadawane z zadaną prędkością bitową
tyle, że bajty nie lecą ciurkiem a z dość pokaźnymi przerwami. Z tego co
pamiętam, jak FTDI obsługiwałem przez COM to wysłanie dłuższego bloku
danych z "prędkością" 250kbps trwało mniej więcej tyle samo co przy
9600bps. Dopiero odwołując się bezpośrednio do biblioteki .dll można
było uzyskać rzeczywiste 250kbps w obrębie całego wysyłanego bloku.

Pozdrawiam
Grzegorz

Thu May 28, 2009 10:38 am   

No to jest typowy konwerterek made in china , wyswietla mi sie toto jako
Profilic USB to serial bridge
i oczywiscie uzywam sterownika dostarczonego z tym dynksem...

No też mam pewne podejrzenia co do tego, czy to się wyrabia... Ale to jak by
to obejść ? Bo przecież nie będę przerabiał softu...
hmmm....