poglądanie RS485 ciąg dalszy - dziwny oscylogram...

Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:gvm60a$q7r$ snipped-for-privacy@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,

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

e.

No, k..wa racja :) Dobra , na razie zapodałem sygnał zegarowy (czyli 16Mhz) podzielone przez CD4040 :) I mamy co następuje

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...

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.

Użytkownik "J.F." <jfox snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news: snipped-for-privacy@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.

Użytkownik "sundayman" snipped-for-privacy@poczta.onet.pl> napisał w wiadomości news:gvmerd$hqm$ snipped-for-privacy@news.onet.pl...

maksymalnej > dla tego procesora, dobrze rozumiem ?

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.

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.

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.