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

Thu May 28, 2009 12:34 pm   

Użytkownik sundayman napisał:

Sterownik tak czy siak jest potrzebny. Problem w tym, że soft pewnie
gada z tym konwerterkiem jak ze zwykłym RS-em przez systemowe urządzenie
COM1:


Jedyne pewne wyjście to sprzętowy RS232. Co to za komputer ? Stacjonarny
- to dorzucić kartę PCI z RS-em. Jak notebook to są sprzetowe RS-y
PCMCIA lub Express Card.

Pozdrawiam
Grzegorz

Thu May 28, 2009 12:50 pm   

Użytkownik "Grzegorz Kurczyk" <grzegorz.usun.to@control.slupsk.pl>
napisał w wiadomości news:gvlamu$shu$1@nemesis.news.neostrada.pl...

Komunikacja z urzadzeniem USB nastepuje co milisekunde, wiec jesli
wysylales po 1 znaku to nie dziwne.
Tu trzeba blokami po co najmniej 25 znakow .. choc Windows chyba i
tak powinien to jakos sam gromadzic ..

J.

Thu May 28, 2009 1:27 pm   

Użytkownik J.F. napisał:

Tzn. w jakim sensie po jednym znaku ?

Pozdrawiam
Grzegorz

Thu May 28, 2009 2:11 pm   

Komputer to normalny stacjonarny PC.

Zrobiłem taką zmianę. Podłączyłem ten "oscylosko na LPT " bezpośrednio do
portu RXD procesora PIC17C42 modułu ściemniaczy. Poprzednie rozwiązanie było
o tyle gorsze, że po pierwsze sygnały szły przez ten nieszcześliwy konwerter
RS485<>Rs232 z transoptorami, które chyba nie wyrabiają, a do tego - nie
wiadomo co jest czym na magistrali - bo przecież moduły nadają - raz jeden
raz drugi, i na tym RS485 wszystko jest wymieszane...
A tu mam tylko to, co trafia bespośrednio do procesora z układu SP483 czyli
z magistrali.

I wygląda to czytelniej chyba
http://lh5.ggpht.com/_GKMox-Hkle0/Sh6K-u98hRI/AAAAAAAAAK0/GZLnLxRs4is/s912/RXD.jpg

Po pierwsze widać, że odległość od opadającego zbocza każdego bitu startu to
ok 74 - 76 us. Zaznaczyłem to czerwonymi markerami. Tak więc na rysunku mamy
chyba 8 bajtów ( jeden ma ciut więcej niż te 74 us). Sama ramka ma w
rzeczywistośći nieco mniej - ale pewnie pomiędzy poszczególnym ramkami jest
jakaś przerwa.

Najwęższy impuls ma natomiast średnio 4 us (max 6 us) - ale te różnice to
może wynikają z nierównego próbkowania przez PC.
Czyli, jeśli dobrze rozumiem - to by potwierdzało koncepcję, że to jest
125kb ?
Bo - przypominam - w tym zakresie mamy do wyboru tylko 250kb. 125kb, 62.5kb

No i teraz - żeby sprawdzić, czy to rzeczywiście to, to muszę skombinować
jakiś lepszy RS - czyli jak koledzy wspomnieli - na PCI ?
Czy taka karta z RS pozwoli na ustawienie takiej nietypowej szybkości ?

Thu May 28, 2009 3:10 pm   

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

Ja tam nie wiem - widziales krotkie impulsy, wiec chyba wyrabiaja
:-)


No i jest klopot. 125k to 8us na bit. Czyli 72 lub 80us, a nie 76.

Albo uzyjesz lepszego oscyloskopu, bo ten LPT-towy moze troche
przeklamywac, albo dorzuc 62500Hz czy podobna na drugi kanal w celu
kalibracji, albo tam jest 1.5 bitu stopu, a moze w ogole jeszcze
inaczej - bo przerwy miedzy znakami sa w zasadzie dowolne. Moze
nawet analogowy wystarczy - przyjrzec sie bitom, maja najkrotsze te
8us+/-3% czy wiecej .

IMO - to jest juz czas gdy trzeba zalozyc ze jest 125k, i trzeba
zaczac analizowac transmisje i ewentualnie zliczac bledy, a nie
dalej rozpoznawac problem.


Wiekszosc kart pecetowych bedzie miala z tym problem. Nastawione sa
raczej na wielokrotnosci 300, czyli 115200, co lepsze 230400,
460800 i 921600.
Zeby zmienic predkosc to najwygodniej byloby zmienic kwarca, co z
kolei moze doprowadzic do niedzialania PCI czy USB.
Mozna tez sprobowac zmienic kwarce na tych plytkach .. i liczyc na
to ze nie przeszkodzi im to w dzialaniu, co niestety nie takie
pewne, biorac pod uwage ze maja sterowanie fazowe na 50Hz
realizowac.

Jakis wlasnej produkcji interfejsik by sie tu przydal, moze FT232
da rade ?

J.

Thu May 28, 2009 3:31 pm   

No impulsy były, ale nierówne - może po prostu "jak tam zaskoczyło" tak było
:)


Nie wiadomo jak ten LPT łapie równo, rzeczywiście, zaraz zapodam na drugą
linię zegar jakiś i będzie wiadomo...



Ano tak. Tyle, że teraz to nie wiem, czy ten pomysł USB<>RS jest ok. Bo niby
jak probowałem wysyłać loopbackiej jakieś testowe dane (typu ciąg
klikudziesięciu znaków) to wszystko było ok.
(mowa o tej chińszczyźnie której używałem).
Ale któryś z kolegów napisał, że przy dłuższych blokach danych może nie
wyrabiać ?

Co FT232 mam tu nawet jakiś interfejs USB<>RS na nim, ktory sobie robiłem
kiedyś - ale czy to się będzie różnić od takiego typowego "chińskiego"
badziewia ?

Thu May 28, 2009 5:08 pm   

Użytkownik "J.F." <jfox_xnospamx@poczta.onet.pl> napisał w wiadomości
news:gvm60a$q7r$1@news.onet.pl...


Z niepewnym sprzętem nie ma sensu. Poza tym jeśli pomyłka będzie w tę
stronę, że bajt słany będzie krótszy niż oczekiwany - może nie być żadnych
błędów. IMHO lepiej ponad wszelką wątpliwość raz a dobrze ustalić, jaka
jest tam prędkość i ilość bitów (jakimś cyfrowym oscyloskopem /
analizatorem z rozdzielczością przynajmniej 10 razy lepszą od długości
bitu) niż zakładać że jest ileśtam i potem mieć kwiatki w rodzaju
zmieniających się tajemniczo bitów. Jeśli ja słyszę tutaj wartości 4us,
6us, 7us na bit i _żadna_ z tych wartości nie jest do końca pewna, to
chyba przechodzenie teraz do etapu analizy danych jest zabieraniem się od
d.. strony do problemu. Z takim podejściem można miesiącami to analizować
bez wiążących wniosków.

Podsumowując: zmierzyć k..wa długość bitu. Jak nie ma czym zmierzyć,
załatwić sprzęt pomiarowy. Nie zgadywać.

e.

Thu May 28, 2009 5:41 pm   

No, k..wa racja
Dobra , na razie zapodałem sygnał zegarowy (czyli 16Mhz) podzielone przez
CD4040
I mamy co następuje
http://picasaweb.google.pl/lh/photo/EG1i87i3j8N2Db1Am2DaNA?feat=directlink

Poszczególne kanały :

1. sygnał RXD
2. sygał TXD (czyli jak się moduł odszczekuje - tu akurat nic nie widać
na tym rysunku, ale generalnie są odpowiedzi
3. sygnał Fosc / 64 = 250kHz (czyli okres 4 uS)
4. sygnał Fosc / 128 = 125 Khz (okres 8 uS)
5. sygnał Fosc / 256 = 62500 kHz (okres 16 uS)

Czyli zaznaczony markerem odcinek ma w rzeczywistośco 8 uS a nie - jak
twierdzi program =9.06 uS

Ponadto widać, jak nierówno program próbkuje - zwłaszcza na 3 kanale się
rzuca w oczy. Ale - wychodzi definitywnie, że bity startu są oddalone od
siebie o 64 uS.
No a jeden bit na RXD ma 4 uS - znaczy takie są najkrótsze "bity" na RXD.

Z tego jednak by wynikało, że transmisja chodzi na 250kb czyli maksymalnej
dla tego procesora, dobrze rozumiem ?
Znaczy tak (start + 8 bitów + stop) = 40us + 24 us pauza = 64 us ? To by się
jakby zgadzało, bo z tego wynika że w ciągu przynajmniej 24uS przed bitem
startu nie mają prawa się zadne dane pojawić - i faktycznie tak zasadniczo
jest - chociaż trafiłem na jeden wyjątek, ale może to jakiś błąd w
transmisji.
Myślę, że 8 bitów a nie 9 bo parzystość by musiała byc liczona prgoramowo w
tym PICu (ale nawet jakby to było 9 bitów to w sumie niewielka różnica).

Czy dobrze kombinuję ? No, teraz podstawowa sprawa, to jutro poprawię ten
konwerter tak, żeby miał szansę te 250kbit przejąć i się zobaczy...

Thu May 28, 2009 5:48 pm   

On Thu, 28 May 2009 18:08:08 +0200, entroper wrote:

Troche zaufania do techniki :-)

Znasz kwarc, znasz procka, wiesz co wchodzi w gre, obserwacje w
przyblizeniu to potwierdzaja - to trzeba pojsc za ciosem i zabrac za
kolejny etap. Jak cos nie bedzie pasowac to sie cofnie, ale jest spora
szansa ze bedzie pasowac, to po co szukac dziury w calym ? :-)

J.

Thu May 28, 2009 7:34 pm   

Użytkownik "J.F." <jfox_xnospamx@poczta.onet.pl> napisał w wiadomości
news:mnft1598j4ccuqvtkjroukcsulctas5nqa@4ax.com...


Jak się ma wyniki od 4 do 7us i na 99% zbocza HL i LH nie są odtwarzane
symetrycznie, to moim zdaniem nie ma się o co oprzeć, a przydałoby się np.
wiedzieć, ilu bitów danych się spodziewać. Bo możesz założyć źle, pomiary
wyjdą Ci dobrze a zorientujesz się, jak Ci nagle jakiś bit zacznie w
tajemniczy sposób skakać. I wtedy zagwozdka - nieznany feature sprzętu czy
błąd w założeniach. Jeśli można uniknąć takiej sytuacji należy jej unikać.
IMHO.

e.

Thu May 28, 2009 7:50 pm   

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




Wygląda na to, że masz transmisję z takim bitratem jak mówisz a co
ciekawe, pojedyncze bajty są wysyłane z jakiegoś timera (bez buforowania),
stąd te wielkie odstępy do bitu stopu do startu. Temu jednemu wyjątkowi
raczej się przyjrzyj, bo błąd w transmisji to trochę naciągana hipoteza
.



Akurat w PICu jest łatwo zrealizować 9 bitów, więc musisz to wziąć pod
uwagę.

e.

Thu May 28, 2009 9:59 pm   

On Thu, 28 May 2009 18:41:18 +0200, sundayman wrote:

No to musze jednak przyznac entroperowi racje - mocno przeklamuje ten
digitrace


Czy mozna w nie wierzyc to osobny problem - akurat na dwoch widac ze
sie przy okazji z sygnalem 3 dzieja cuda, cos tam gubi.


Troche to dziwne, bo zasadniczo wysyla sie dane czesciej w transmisji
szeregowej, ale moze tak im bylo wygodniej, albo wszystko w jednym
przerwaniu obslugiwane ...


J.

Fri May 29, 2009 4:23 pm   

Z tym 9 bitem to jest tak, co już wspomnialem, że PIC17C42 nie liczy
sprzetowo parzystosci, wiec - musieliby to robicz na piechote. Stad
podejrzewam ze bez parzystosci, no ale pewnosci nie mam. No w kazdym razie
dziekuje kolegom za zaangażowanie bede po niedzieli dalej walczyl z tym.
I z pewnoscia jeszcze sie odezwe w tej materii...
Zobaczymy, czy mi sie uda to rozgryzc... No i oprocz odczytania transmisji
jeszcze kwestia samej zawartosci ale to zupelnie inna bajka bedzie...

Dam znac, co mi wyszlo z proby odczytania tych 250kb.

pozdr.