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

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

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

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


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

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 ?

do góry

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

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

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.

do góry

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

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/EG1i87i3j8N2Db1A
m2DaNA?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...

do góry

On Thu, 28 May 2009 18:08:08 +0200, entroper wrote:
>Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
>> 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.
>
>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 [...]

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

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.

do góry

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

> 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 ? :-)

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.

do góry

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

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

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

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

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

e.

do góry

On Thu, 28 May 2009 18:41:18 +0200, sundayman wrote:
>> Podsumowując: zmierzyć k..wa długość bitu. Jak nie ma czym zmierzyć,
>> załatwić sprzęt pomiarowy. Nie zgadywać.
>
>No, k..wa racja :)

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

>http://picasaweb.google.pl/lh/photo/EG1i87i3j8N2Db1
Am2DaNA?feat=directlink
>
>1. sygnał RXD
>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)
>
>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.

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

>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

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.

do góry

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.

do góry