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

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 ?

Reply to
sundayman
Loading thread data ...

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,

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.

Reply to
entroper

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

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

Reply to
sundayman

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.

Reply to
J.F.

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.

Reply to
entroper

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.

Reply to
entroper

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.

Reply to
J.F.

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.

Reply to
Sundayman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.