Czasy nadawania 89C2051 po Rs232



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Gift" <witek_at_nospam_cordef.net.pl>
Subject: Czasy nadawania 89C2051 po Rs232
Date: Sat, 6 Jul 2002 23:58:53 +0200


Witam!
Układ 89C2051+Max232 podłączony jest COM w PC. Wysyłam z PC dane do uP, ten
je odbiera i zwraca te same dane jako swego rodzaju potwierdzenie odbioru.
Program obsługi w Delphi. Problem jest taki, że na trzy wysłane bajty
(powiedzmy 1,2,3) uP zwraca dwa (1,2 lub 1,3), a tylko czasem wrói poprawnie
1,2,3. Zjawisko jest przypadkowe i nie wiem od czego zależy. W Delphim
uzywam komponentu TCommPortDriver. Manewrując delayami w Delphi między
wysyłanymi kolejnymi bajtami sytuacja albo się ciut poprawia, albo się
pogarsza. Czy przerwa między nadaniem dwóch kolejnych bajtów powinna być
określonej długości?? Jeśli tak to jak ją ustalić? Może ktoś mi pomoże......

Witek


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Sun, 07 Jul 2002 01:21:00 +0200


A pamietasz o tym, ze procek ma jednobajtowy bufor? Moze zwyczajnie go
przepelniasz?
--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: "Piramid" <funak_at_nospam_wp.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Sun, 7 Jul 2002 02:53:18 +0200


Witam!!!

Układ 89C2051+Max232 podłączony jest COM w PC. Wysyłam z PC dane do uP,
ten
je odbiera i zwraca te same dane jako swego rodzaju potwierdzenie odbioru.
Program obsługi w Delphi. Problem jest taki, że na trzy wysłane bajty
(powiedzmy 1,2,3) uP zwraca dwa (1,2 lub 1,3), a tylko czasem wrói
poprawnie
1,2,3. Zjawisko jest przypadkowe i nie wiem od czego zależy. W Delphim
uzywam komponentu TCommPortDriver. Manewrując delayami w Delphi między
wysyłanymi kolejnymi bajtami sytuacja albo się ciut poprawia, albo się
pogarsza. Czy przerwa między nadaniem dwóch kolejnych bajtów powinna być
określonej długości?? Jeśli tak to jak ją ustalić? Może ktoś mi
pomoże......

Ja proponuję ustalić parametry transmisji z 2 bitami stopu.
Ja coś w tym stylu robiłem, że wysyłałem z kompa do uC, a on natychmiastowo
zwiększał o 1 wart. odebraną i wpisywał do SBUF.
Przy jednym bicie stopu dane przesyłane były błędnie, a przy 2 bitach stopu
prawidłowo, nawet przy takiej szybkości
przesyłania.

Czyli nie ma tu mowy o jakimś bardzo długim zwolnieniu i nie nadania w
określonym czasie.
Pamiętaj: przy 57600 bps czas na odpowiedz wynosi(1 startowy,8 bit dane ,1
bit stopu(SMOD=1)):
16*10=160 cykli maszynowych.
Przy 2 bitach stopu:
16*11=176 cykli. Dużo czasu!

Myślę, że to Twój problem tkwi właśnie w tym.

A jeżeli nie, to obstawiałbym winę Twojego programu.
Nie wyrabia i odpowiada z opóźnieniem.
Powoduje nałożenie bajtu na drugi i w ten sposób w zależności od trafionego
bitu stopu przyjmuje Ci dane komputer
albo je ignoruje(brak bitu stopu(stan linii w chwili próbkowania bitu stopu:
0).


Pozdrawiam

--
Piramid
mail: funak(at)wp.pl funak(at)skrzynka.pl
news: pl.comp.lang.pascal pl.comp.lang.c pl.misc.elektronika
www: http://strony.wp.pl/wp/funak/index.htm
GG-2949256






Poprzedni Następny
Wiadomość
Spis treści
From: "Mariusz Ł." <elprojekt_at_nospam_poczta.onet.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Sun, 7 Jul 2002 09:09:17 +0200


Dzień Dobry,

czy wynik poprawny/niepoprawny jest zależny od zawartości tych zwracanych
bajtów ?

Pozdrawiam,
Mariusz Ł.

Użytkownik "Gift" <witek_at_nospam_cordef.net.pl> napisał w wiadomości
news:ag7pl7$cif$1_at_nospam_news.tpi.pl...
Witam!
Układ 89C2051+Max232 podłączony jest COM w PC. Wysyłam z PC dane do uP,
ten
je odbiera i zwraca te same dane jako swego rodzaju potwierdzenie odbioru.
Program obsługi w Delphi. Problem jest taki, że na trzy wysłane bajty
(powiedzmy 1,2,3) uP zwraca dwa (1,2 lub 1,3), a tylko czasem wrói
poprawnie
1,2,3. Zjawisko jest przypadkowe i nie wiem od czego zależy. W Delphim
uzywam komponentu TCommPortDriver. Manewrując delayami w Delphi między
wysyłanymi kolejnymi bajtami sytuacja albo się ciut poprawia, albo się
pogarsza. Czy przerwa między nadaniem dwóch kolejnych bajtów powinna być
określonej długości?? Jeśli tak to jak ją ustalić? Może ktoś mi
pomoże......

Witek




Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 7 Jul 2002 14:35:04 +0200


1,2,3. Zjawisko jest przypadkowe i nie wiem od czego zależy. W Delphim
uzywam komponentu TCommPortDriver. Manewrując delayami w Delphi między
wysyłanymi kolejnymi bajtami sytuacja albo się ciut poprawia, albo się
pogarsza. Czy przerwa między nadaniem dwóch kolejnych bajtów powinna być
określonej długości?? Jeśli tak to jak ją ustalić? Może ktoś mi
pomoże......

Witek

1. ustal jakąś metodę przesyłania paczek. uP musi tylko odbierać bajt,
zapisać w tablicy
wyjść z przerwania. Pętla sprawdza czy już odebrano paczkę.
2. pecety potrzebują chwilkę czasu na przełącenie się z nadawania na odbiór.
Swego czasu zmusiło to mnie do robienia paczek po 8kb i ich transmisji
aby zmieścić się w czasie zanim następna paczka będzie gotowa.
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Sun, 07 Jul 2002 21:16:25 +0200


1. ustal jakšś metodę przesyłania paczek. uP musi tylko odbierać bajt,
zapisać w tablicy wyjść z przerwania. Pętla sprawdza czy już odebrano paczkę.

O przepraszam....proste echo wyjdzie na kazdym procku i to w samym przerwaniu. To
raczej PC powinno kontrolowac przepelnianie bufora uP (jeśli robi jako master i na
dodatek nie ma zadnej sprzętowej kontroli transmisji, a tak chyba najczescie jest
przy komunikacji z prostymi uP)

2. pecety potrzebujš chwilkę czasu na przełšcenie się z nadawania na odbiór.
Swego czasu zmusiło to mnie do robienia paczek po 8kb i ich transmisji
aby zmieścić się w czasie zanim następna paczka będzie gotowa.

To nie tak....PC maja osobne burofy nadawcze i odbiorcze. W zaleznosci na jakim
poziomie piszesz masz do dyspozycji roznej wielkosci bufory (czasem doslownie 8
bajtow, czasem 4k....) i trzeba o tym pamietać! ;-))
Bez problemu natomiast wszystko może chodzić dupleksowo.

--
PZD, Irek.N.


Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 8 Jul 2002 00:06:53 +0200


1. ustal jakšś metodę przesyłania paczek. uP musi tylko odbierać bajt,
zapisać w tablicy wyjść z przerwania. Pętla sprawdza czy już
odebrano paczkę.

O przepraszam....proste echo wyjdzie na kazdym procku i to w
samym przerwaniu. To
raczej PC powinno kontrolowac przepelnianie bufora uP (jeśli robi
jako master i na
dodatek nie ma zadnej sprzętowej kontroli transmisji, a tak chyba
najczescie jest
przy komunikacji z prostymi uP)
No tak, ale pecet musi znać wielkość bufora która jest jednocześnie
wielkością paczki.
Czyli pecet wysyła paczkę o sciśle określonej wielkości bufora w procku, lub
kończy paczkę określona sekwencją nie możliwą do wystąpienia przy
przesyłanych danych.
Np. ja używam stałego kodu FFh jako początku paczki i następnych
dwóch/jednego bajtu zawirającego
ilość bajtów w paczce. W ten sposób procek wie kiedy nastąpi koniec paczki.
Oczywiście kolejne bajty zawierają inne informacje niezbędne do prawidłowego
funkcjonowania
ale do prostego wystarczą te dane. Po odbiorze procek wysyła kod pseudoCRC i
odpowiedź.
Pecet stwierdzając poprawość pseudoCRC przyjmuje odebrane dane do wiadomości
lub wysyła paczkę
ponownie zaznaczając w ostatnim bajcie, że to jest powtórne wysłanie.
Całość jest troszke bardziej skomplikowana i od strony peceta nie znam
szczegółów, natomiast znam
protokół jako taki.

2. pecety potrzebujš chwilkę czasu na przełšcenie się z
nadawania na odbiór.
Swego czasu zmusiło to mnie do robienia paczek po 8kb i
ich transmisji
aby zmieścić się w czasie zanim następna paczka będzie gotowa.

To nie tak....PC maja osobne burofy nadawcze i odbiorcze. W
zaleznosci na jakim
poziomie piszesz masz do dyspozycji roznej wielkosci bufory
(czasem doslownie 8
bajtow, czasem 4k....) i trzeba o tym pamietać! ;-))
Bez problemu natomiast wszystko może chodzić dupleksowo.
Rozmawiamy teraz o komponentach Delphi, i synchronicznym przesyłaniu danych.
Przynajmniej mnie sie tak wydaje. ;-)
Standardowe przy transmisji synchronicznej, czyli wysyła dane i czeka na
reakcję potrzebują chwilkę
na przełączenie się programu/windowsów.
Oczywiście przy transmisji asynchronicznej tego ograniczenia nie ma, tylko
trzeba dołozyć w nagłówku informację
której paczki wysłanej dotyczą się odebrane informacje. To trochę komplikuje
program, ale przyspiesz przesyłanie paczek o niewielkiej pojemności.
W ten sposób ja rozwiązałem swoje problemy z transmisją, jeśli ktoś ma
lepsze pomysły,
chętnie (bardzo ;-) ) przeczytam.

pzdr
Artur
PS
No i oczywiście miłego nowego tygodnia.
;-)


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 08 Jul 2002 09:01:39 +0200


{ciach}

xon/xoff By Ziel ;-)))
Dla echa wystarczy tylko poczekać z nadawaniem po stronie PC, aż procek odpowie
znaczkiem na właśnie otrzymany znaczek i już bufor procka jest bezpieczny ;-)

Rozmawiamy teraz o komponentach Delphi, i synchronicznym przesyłaniu danych.
Przynajmniej mnie sie tak wydaje. ;-)

Yyy...nie znam komponentów Delphi.....:-(
Synchronicznym??? Ktoś robi synchroniczną transmisję z prockami?

Standardowe przy transmisji synchronicznej, czyli wysyła dane i czeka na
reakcję potrzebują chwilkę na przełączenie się programu/windowsów.

Nie ma chyba znaczenia czy transmisja jest synchroniczna czy asynchroniczna -
dane przychodza i zapełniają bufor tak samo (choć niekoniecznie w tym samym
czasie ;-) ). Nie wiem co to znaczy czeka na reakcję, ale wygląda mi to na
sprzętowe sterowanie transmisją. Nie chcesz chyba powiedzieć, że ciągniesz
dodatkowe linie i wykorzystujesz piny procka via MAX do sprzętowego sterowania
transmisją?

Oczywiście przy transmisji asynchronicznej tego ograniczenia nie ma, tylko
trzeba dołozyć w nagłówku informację której paczki wysłanej dotyczą się
odebrane informacje. To trochę komplikuje
program, ale przyspiesz przesyłanie paczek o niewielkiej pojemności.

A to mi wygląda na programową kontrolę....pogubiłem się :-(

W ten sposób ja rozwiązałem swoje problemy z transmisją, jeśli ktoś ma lepsze
pomysły, chętnie (bardzo ;-) ) przeczytam.

Artur ale o czym? O sposobie podłączenia, o możliwościach sprzętowej kontroli
czy o protokołach komunikacyjnych?
Pierwotnie było o czasie potrzebnym na przełączanie z nadawania na odbiór.
Takiego czasu nie ma....bufory PC-ta mogą pracować jednocześnie. To natomiast
jak niedopuścić do przepełnienia któregokolwiek z czterech buforów - to osobny
temat ;-) i zadanie dla układów/rozwiązań kontroli transmisji.

No i oczywiście miłego nowego tygodnia.
;-)

Dzięki i wzajemnie, o ile Pn może być miły (znaczy inspirujący) ;-)

--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 8 Jul 2002 09:55:01 +0200


xon/xoff By Ziel ;-)))
Dla echa wystarczy tylko poczekać z nadawaniem po stronie PC, aż
procek odpowie
znaczkiem na właśnie otrzymany znaczek i już bufor procka jest
bezpieczny ;-)
Proszę mnie nie ciągnąć za język. ;-)
Idzie przez radio, więc RTS DTR odpada.


Rozmawiamy teraz o komponentach Delphi, i synchronicznym
przesyłaniu danych.
Przynajmniej mnie sie tak wydaje. ;-)

Yyy...nie znam komponentów Delphi.....:-(
Synchronicznym??? Ktoś robi synchroniczną transmisję z prockami?
;-) Ja. Tak mi sie kiedyś wydało, że to najwygodniej, ;-)


Standardowe przy transmisji synchronicznej, czyli wysyła dane i czeka na
reakcję potrzebują chwilkę na przełączenie się programu/windowsów.

Nie ma chyba znaczenia czy transmisja jest synchroniczna czy
asynchroniczna -
dane przychodza i zapełniają bufor tak samo (choć niekoniecznie w
tym samym
czasie ;-) ). Nie wiem co to znaczy czeka na reakcję, ale wygląda mi to na
sprzętowe sterowanie transmisją. Nie chcesz chyba powiedzieć, że ciągniesz
dodatkowe linie i wykorzystujesz piny procka via MAX do
sprzętowego sterowania
transmisją?
Nie. Podłączyłem się pod kartę grafiki i czekam aż kontrolka TX zgaśnie.
;-)
Nigdy nie napisałem żadnego programu w Delphi, ale wygląda to tak, że
po nadawaniu i natychmiastowym przejściu do odbioru, uP musi czekać
na tego wielkiego szybkiego i wspaniałego peceta około 1-2 milisekundy.
Niezależnie od wielkości paczki. Może to windoza tak się spowalnia?
Oczywiście piszę teraz o synchronicznym.


Oczywiście przy transmisji asynchronicznej tego ograniczenia
nie ma, tylko
trzeba dołozyć w nagłówku informację której paczki wysłanej dotyczą się
odebrane informacje. To trochę komplikuje
program, ale przyspiesz przesyłanie paczek o niewielkiej pojemności.

A to mi wygląda na programową kontrolę....pogubiłem się :-(
Ułatwię. Pecet jest dołączony do radia i komunikuje się z kilkunastoma uP.
Co będzie wysłane do następnego uP jest zależne od tego co zostało odebrane.
Czyli muszę zachować kolejność i dokładnie wiedzieć na jakie pytania
odpowiadają uP.


W ten sposób ja rozwiązałem swoje problemy z transmisją, jeśli
ktoś ma lepsze
pomysły, chętnie (bardzo ;-) ) przeczytam.

Artur ale o czym? O sposobie podłączenia, o możliwościach
sprzętowej kontroli
czy o protokołach komunikacyjnych?
Pierwotnie było o czasie potrzebnym na przełączanie z nadawania na odbiór.
Takiego czasu nie ma....bufory PC-ta mogą pracować jednocześnie.
To natomiast
jak niedopuścić do przepełnienia któregokolwiek z czterech
buforów - to osobny
temat ;-) i zadanie dla układów/rozwiązań kontroli transmisji.
Protokół i sprzętowa realizacja połączenia, czyli jak napisać program
abym nie musiał czekać przy przechodzeniu z nadawania na odbiór.


No i oczywiście miłego nowego tygodnia.
;-)

Dzięki i wzajemnie, o ile Pn może być miły (znaczy inspirujący) ;-)
Ja go nie będę miał :-(, ale chciaż innym pożyczę. ;-)
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 08 Jul 2002 10:32:36 +0200


Proszę mnie nie ciągnąć za język. ;-)

-)) co Ty. (co Ja?)

Idzie przez radio, więc RTS DTR odpada.

Tylko Tx/Rx - OK.

Nie. Podłączyłem się pod kartę grafiki i czekam aż kontrolka TX zgaśnie.
;-)
Nigdy nie napisałem żadnego programu w Delphi, ale wygląda to tak, że
po nadawaniu i natychmiastowym przejściu do odbioru, uP musi czekać
na tego wielkiego szybkiego i wspaniałego peceta około 1-2 milisekundy.

Bo TAKĄ masz komunikację. Skoro PC nie wie co ma odpowiedzieć, bo to zależy od
tego co przyjdzie, to jak ma być full dupleks? Ma pchać smiecie dla _zabicia
czasu_? ;-)) Swoją drogą - winda nakłada sporo swojego czasu na procedury
nazwijmy to komunikacyjne.

Oczywiście piszę teraz o synchronicznym.

Co Ty masz z tą synchroniczną transmisją? Skąd bierzesz zegar i jak go
propagujesz?

Ułatwię. Pecet jest dołączony do radia i komunikuje się z kilkunastoma uP.
Co będzie wysłane do następnego uP jest zależne od tego co zostało odebrane.
Czyli muszę zachować kolejność i dokładnie wiedzieć na jakie pytania
odpowiadają uP.

No i dlatego masz przełączanie nadawanie/odbiór, dlatego też masz
przerwę...musisz przygotować dane, wypełnić nimi bufor nadajnika RS-a itd....Co
tu jest nienormalnego?

Protokół i sprzętowa realizacja połączenia, czyli jak napisać program
abym nie musiał czekać przy przechodzeniu z nadawania na odbiór.

Zawsze będziesz czekał przy założeniach jakie masz...
Chyba że ktoś Ci napisze program prognozujący jakie dane będą wysyłane ;-))

Ja go nie będę miał :-(, ale chciaż innym pożyczę. ;-)

Aż tak źle?

--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 01:41:15 +0200


Bo TAKĄ masz komunikację. Skoro PC nie wie co ma odpowiedzieć, bo
to zależy od
tego co przyjdzie, to jak ma być full dupleks? Ma pchać smiecie
dla _zabicia
czasu_? ;-)) Swoją drogą - winda nakłada sporo swojego czasu na
procedury
nazwijmy to komunikacyjne.
Patrząc się na transmisję ze strony programu na pececie: inicjalizacja
bufora nadawczego i odbiorczego, zapełnienie bufora nadawczego i sruuu,
jeśli natychmiast po zakończeniu nadawania prcek np. wyśle CRC, to pecet
nie odbierze, tzn. albo odbierze śmieci, albo ostatni bajt.
Procek po odebraniu danych, przed wysłaniem danych musi zaczekać te 2
milisekundy.
Testowane było ze cztery komponenty różnych autorów i zawsze był ten sam
efekt.
W praktyce specjalnie mi to nie przeszkadza, bo i tak procek musi zebrać
dane
przed ich wysłaniem, ale taki drobiazg może być denerwujący.

Co Ty masz z tą synchroniczną transmisją? Skąd bierzesz zegar i jak go
propagujesz?
Ekhm, tego, no ... sychronicznie idą dane względem siebie, nie względem
zegara.
Sprzętowo to jest asynchroniczne łącze. ;-)

No i dlatego masz przełączanie nadawanie/odbiór, dlatego też masz
przerwę...musisz przygotować dane, wypełnić nimi bufor nadajnika
RS-a itd....Co tu jest nienormalnego?
Procek pseudoCRC oblicza w locie i teoretycznie mógłby natychmiast odesłać,
ale pecet tego nie zauważy. Z mojego punktu widzenia wygląda to tak jakby
windoza siadała. To jescze dodam, ż echodzi o win2000.


Protokół i sprzętowa realizacja połączenia, czyli jak napisać program
abym nie musiał czekać przy przechodzeniu z nadawania na odbiór.

Zawsze będziesz czekał przy założeniach jakie masz...
Chyba że ktoś Ci napisze program prognozujący jakie dane będą
wysyłane ;-))
Albo nowy sytem. ;-) Przy najbliżej okazji, pomęczę znajomego o napisanie
takiej transmisji pod Linuxa. Ciekawe czy też będzie konieczna taka zwłoka?


Ja go nie będę miał :-(, ale chciaż innym pożyczę. ;-)

Aż tak źle?
Zbyt dobrze. Czym więcej pracy, tym więcej kłopotów. ;-)
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Tue, 09 Jul 2002 09:21:44 +0200


Patrząc się na transmisję ze strony programu na pececie: inicjalizacja
bufora nadawczego i odbiorczego, zapełnienie bufora nadawczego i sruuu,
jeśli natychmiast po zakończeniu nadawania prcek np. wyśle CRC, to pecet
nie odbierze, tzn. albo odbierze śmieci, albo ostatni bajt.

????? a wiesz dlaczego?

Procek po odebraniu danych, przed wysłaniem danych musi zaczekać te 2
milisekundy.
Testowane było ze cztery komponenty różnych autorów i zawsze był ten sam
efekt.

No to popatrz na ...wiesz co i przyjmij do wiadomości że lata tam 115k2 w obie
strony NA RAZ i żadnego bajtu nie tracę.....nawet jak przepycham przez to ucho
1M bufor (z ktorego na RS-ie robi sie juz 4M).
Co dokomponentów - pytać autorów dlaczego, ale sądzę że to nie ich wina.

Ekhm, tego, no ... sychronicznie idą dane względem siebie, nie względem
zegara.
Sprzętowo to jest asynchroniczne łącze. ;-)

OK nareszcie :-))

Procek pseudoCRC oblicza w locie i teoretycznie mógłby natychmiast odesłać,
ale pecet tego nie zauważy. Z mojego punktu widzenia wygląda to tak jakby
windoza siadała. To jescze dodam, ż echodzi o win2000.

To nie ma znaczenia....co prawda goście z mało-miękkiego dali _d..._ w 2k oraz
XP i lekko zmienili _podejście_ do RS-a, ale generalnie wszystkie systemy
spokojnie radzą sobie z full dupleksem (przynajmniej wszystkie jakie
sprawdzałem, czyli 98, 98SE, ME, 2K, XP, NT4).

Albo nowy sytem. ;-) Przy najbliżej okazji, pomęczę znajomego o napisanie
takiej transmisji pod Linuxa. Ciekawe czy też będzie konieczna taka zwłoka?

Artur - to naprawdę nie jest wina PC-ta. Daj mi założenia to trzasnę Ci
szybciutko monitorek-sterowniczek i sam się przekonasz. Zresztą -
port-monitorów w sieci od groma, co za problem podpiąć i zlikwidować przerwę (o
ile tylko tory radiowe przeniosą).

Zbyt dobrze. Czym więcej pracy, tym więcej kłopotów. ;-)

Ale też więcej $ i być może satysfakcji ;-)

--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 17:00:58 +0200


Patrząc się na transmisję ze strony programu na pececie: inicjalizacja
bufora nadawczego i odbiorczego, zapełnienie bufora nadawczego i sruuu,
jeśli natychmiast po zakończeniu nadawania prcek np. wyśle CRC, to pecet
nie odbierze, tzn. albo odbierze śmieci, albo ostatni bajt.

????? a wiesz dlaczego?
Mnie osobiście wydaje się, że to wina win. Tzn. zarządzania buforami, po
nadawaniu
system potrzebuje trochę czasu na poinformowanie wszystkich zainteresowanych
procesów
o zakończeniu wysyłania, następnie musi się zorientować w sprawie bufora
odbiorczego
i całą resztą zarządzania procesami, co, dla kogo i po co. Generalni ma co
robić
po zakończeniu transmisji, to nie to co w procku ustawić bufor, wektory
przerwań
i do widzenia ;-).
Zresztą sam wiesz najlepiej. ;-)

No to popatrz na ...wiesz co i przyjmij do wiadomości że lata tam
115k2 w obie
strony NA RAZ i żadnego bajtu nie tracę.....nawet jak przepycham
przez to ucho
1M bufor (z ktorego na RS-ie robi sie juz 4M).
Może masz zgodność opóźnień? ;-)
Że se lata tam i nazad cuzamen do kupy na raz, to ja widzę,
ale wzrok mam trochę słaby i tej pojedynczej milisekundy się nie mogę
dopatrzyć.;-)
Ale możesz napisać program który wyśle kilka bajtów na com i natychmiast
przełączy się
na odbiór. W procku daj program który po odebraniu tych kilku bajtów
(paczka)
natychmiast odeśle kurc galopem do peceta.
W/g mnie powinno się wyłożyć już przy 9600.
Tylko w razie czego, na litość boską nie poprawiaj tego programu który już
działa
i to dobrze działa. ;-)

Co dokomponentów - pytać autorów dlaczego, ale sądzę że to nie ich wina.
Raczej nie ich, nikt nie ma możliwości przetestowania programu na wszystkich
komputerach, zresztą teraz czort wie co teraz wkładają do tych kompów.
Kiedyś był problem z kartą grafiki S3 i portem szeregowym, teraz może się
okazać, że pecety ze względu na swoją dużą szybkość muszą wykonać program
pięć razy zanim ich wewnętrzne peryferia załapią temat.;=)

Sprzętowo to jest asynchroniczne łącze. ;-)

OK nareszcie :-))
No przecież cały czas tak pisałem ;-)

XP i lekko zmienili _podejście_ do RS-a, ale generalnie wszystkie systemy
spokojnie radzą sobie z full dupleksem (przynajmniej wszystkie jakie
sprawdzałem, czyli 98, 98SE, ME, 2K, XP, NT4).
Wiem, widziałem.
No i może coś mnie teraz olśniło. ;-)
Skoro full duplex chodzi bez problemu, to może rzeczywiście wysyłać
z procka śmieci bez przerwy. Pecet sobie bez problemu wyłapie początek
transmisji. ;-)
Żartuję. ;-)

Artur - to naprawdę nie jest wina PC-ta.
A co? Może moja? ;-)

Daj mi założenia to trzasnę Ci
szybciutko monitorek-sterowniczek i sam się przekonasz. Zresztą -
port-monitorów w sieci od groma, co za problem podpiąć i
zlikwidować przerwę (o
ile tylko tory radiowe przeniosą).
Zaraz będzie pracował. Słoneczko świeci, cieplutko, środek wakacji, a Ty
będziesz
z nosem w monitorze ślęczał.;-)
Ten problem występuje, z tego co zauważyłem, tylko w Delphi. I nie jest on
dla mnie przeszkodą
gdyż ten bezużyteczny/wymagany czas zwłoki zużywam do ściągania danych, więc
mi nie przeszkadza.
Ja tylko tak informuję, że taki problem występuje i ewentualnie jestem
ciekaw czy dotyczy
on tylko Delphi.

Ale też więcej $ i być może satysfakcji ;-)
Satysfakcji to nigdy nie będzie, gdyż nie istnieje program/urządzenie
doskonałe. :-(
Zawsze się ludzie o coś będą czepiać.
A czym więcej $ tym większe wydatki i ciekawe zjawisko, czym więcej
pieniędzy tym więcej ich brakuje.
;-)
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Tue, 09 Jul 2002 22:33:34 +0200


Mnie osobiście wydaje się, że to wina win. Tzn. zarzšdzania buforami, po
nadawaniu system potrzebuje trochę czasu na poinformowanie wszystkich
zainteresowanych
procesów o zakończeniu wysyłania, następnie musi się zorientować w sprawie
bufora
odbiorczego i całš resztš zarzšdzania procesami, co, dla kogo i po co.

Grrrr...ten znowu swoje....jak wepchne w jedna petle pisanie i czytanie po
buforach to nawet jednym wštkiem zalatwie fulldupleks!

Generalni ma co robić po zakończeniu transmisji, to nie to co w procku ustawić
bufor, wektory
przerwań i do widzenia ;-). Zresztš sam wiesz najlepiej. ;-)

Zaraz...Ty chyba nie zamykasz portu po wyslaniu kazdej paczki? Co ile te paczki
lataja?

Może masz zgodność opóźnień? ;-)

Tia....;-)))

Że se lata tam i nazad cuzamen do kupy na raz, to ja widzę,
ale wzrok mam trochę słaby i tej pojedynczej milisekundy się nie mogę
dopatrzyć.;-)

Bo jej nie ma...podlacz oscylka i sprawdz sobie...albo chociaz portmonitor.

Ale możesz napisać program który wyśle kilka bajtów na com i natychmiast
przełšczy się na odbiór.

Moge napisać Ci szczeniaczka ktory JEDNOCZESNIE bedzie nadawal i wyswietlal to
co odebrallllll.....tak działa nawet terminal z NC :-)))
Co Ty masz z tym przelaczaniem?
Nawet poczciwa 51 ma mozliwosc jednoczesnego nadawania i odbioru..sadzisz że PC
jest gorsze? ;-)

Dawaj parametry transmisji....
Zdefiniuj tabele ktorš ma wysyłać....

W procku daj program który po odebraniu tych kilku bajtów
(paczka) natychmiast odeśle kurc galopem do peceta.
W/g mnie powinno się wyłożyć już przy 9600.

A jak ja mam? Urzadzonko dostaje na starcie 90 znakow _at_nospam_ 115k2 i jak tylko moze
najszybciej odpowiada....
W praktyce jest to dosłownie kilkanaście, może małe kilkadziesišt cykli AVR-a
_at_nospam_9.216M opóżnienia...
PC słucha i jak tylko coś odbierze to natychmiast dopełnia bufor
urzšdzonka....wysyłajšc kolejne znaczki.
Jakoś się toto nie wykłada....powiem więcej....zastanawiałem sie nad jeszcze
szybszš transmisjš....wiesz - druga strona urzšdzenia jest niekiedy prawie 5x
szybsza ;-)

Tylko w razie czego, na litość boskš nie poprawiaj tego programu który już
działa i to dobrze działa. ;-)

Którego? Mojego czy Twojego? ;-)) Nie mów że to odpaliłeś?...nic się nie
chwalisz :-( (prv?)

Co dokomponentów - pytać autorów dlaczego, ale sšdzę że to nie ich wina.
Raczej nie ich, nikt nie ma możliwości przetestowania programu na wszystkich
komputerach, zresztš teraz czort wie co teraz wkładajš do tych kompów.
Kiedyś był problem z kartš grafiki S3 i portem szeregowym, teraz może się
okazać, że pecety ze względu na swojš dużš szybkość muszš wykonać program
pięć razy zanim ich wewnętrzne peryferia załapiš temat.;=)

I tak też się dzieje....kiedyś liczyłem ile razy pętla odpowiadajšca za
komunikację mi się przewinie zanim odkryje że jakiś znaczek przyszedł lub
wyszedl na tych 115k2...wychodziło mi że znaczek vis znaczek to jest kilkanaście
obiegów prostego while (coś tam) na PIII_at_nospam_550 ;-)) PC-ty sš szybkie, ale nie
gubiš niczego :-) Co najwyżej programista o czymś zapomina ;-)

OK nareszcie :-))
No przecież cały czas tak pisałem ;-)

??? Moim zdaniem cały czas wmawiałeś nam że masz transmisję synchronicznš -
drogš radiowš ;-)))

Wiem, widziałem.
No i może coś mnie teraz olśniło. ;-)
Skoro full duplex chodzi bez problemu, to może rzeczywiście wysyłać
z procka śmieci bez przerwy. Pecet sobie bez problemu wyłapie poczštek
transmisji. ;-) Żartuję. ;-)

Dlaczego....ja tak mam w jednym miejscu...możesz pchać co Ci sie podoba...a jak
w transmisji bedzie kod poczatku i w odpowiednim miejscu kod konca to ramka
zostanie przyjeta (jeśli dane sš poprawne oczywiscie) :-)

A co? Może moja? ;-)

Noo...tak ;-) albo programisty który to dla Ciebie pisał.

Zaraz będzie pracował. Słoneczko świeci, cieplutko, środek wakacji, a Ty
będziesz z nosem w monitorze ślęczał.;-)

Noo.. jeśli pomoze Ci to w czymś....czemu nie ;-)

Ten problem występuje, z tego co zauważyłem, tylko w Delphi. I nie jest on
dla mnie przeszkodš gdyż ten bezużyteczny/wymagany czas zwłoki zużywam do
ścišgania danych, więc
mi nie przeszkadza.

OK. ale to nie jest sprawa delphi....moze komponentu albo zastosowanego
algorytmu....nie wiem.

Ja tylko tak informuję, że taki problem występuje i ewentualnie jestem
ciekaw czy dotyczy on tylko Delphi.

Grrr....;-))

Ale też więcej $ i być może satysfakcji ;-)
Satysfakcji to nigdy nie będzie, gdyż nie istnieje program/urzšdzenie
doskonałe. :-(

O...idealista?

Zawsze się ludzie o coś będš czepiać.
A czym więcej $ tym większe wydatki i ciekawe zjawisko, czym więcej
pieniędzy tym więcej ich brakuje.

A tak...więcej zarabiasz, więcej potrzebujesz - ciekawe zjawisko ;-)

Miłego wieczoru Arturze.

--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 10 Jul 2002 00:58:43 +0200


Zaraz...Ty chyba nie zamykasz portu po
wyslaniu kazdej paczki? Co ile te paczki
lataja?
Ja? Nie. Kto inny pisze programy na peceta.
Uchylę rąbka tajemnicy. ;-)
Dwa mega128 jako transmiter. Do 250 urządzeń z
mega128
z transmisją radiową i do każdego z nich do 16 szt
AT90S8515.
Paczki różnej długości, dane też różne, m.in. małe
tablice.
Maksymalny czas na oblecenie całości przez peceta
to 1 sekunda,
jeśli się któreś urządzenie nie zmieści w czasie
wysyła swoją paczkę
przy następnym cyklu.
Jak On to zrobił, że się nie rozsypuje, to nie mam
bladego pojęcia ;-).

Bo jej nie ma...podlacz oscylka i
sprawdz sobie...albo chociaz portmonitor.
W portmonitory nie wierzę, a skąd mam wiedzieć na
oscylku,
że to jest opóźnienie nieumyślne? ;-)

Moge napisać Ci szczeniaczka ktory
JEDNOCZESNIE bedzie nadawal i wyswietlal to
co odebrallllll.....tak działa nawet
terminal z NC :-)))
Co Ty masz z tym przelaczaniem?
Nawet poczciwa 51 ma mozliwosc
jednoczesnego nadawania i odbioru..sadzisz że PC
jest gorsze? ;-)
Na '51 systemy/programy piszą fachowcy. ;-)


Dawaj parametry transmisji....
Zdefiniuj tabele ktorš ma wysyłać....
Na pewno nie chcesz.
64str. opisu transmisji i jakieś 200str. opisu
komunikacji,
polecenia, rozkazy (to co innego niż polecenie),
itd.

A jak ja mam? Urzadzonko dostaje na
starcie 90 znakow _at_nospam_ 115k2 i jak tylko moze
najszybciej odpowiada....
W praktyce jest to dosłownie
kilkanaście, może małe kilkadziesišt cykli AVR-a
_at_nospam_9.216M opóżnienia...
PC słucha i jak tylko coś odbierze to
natychmiast dopełnia bufor
urzšdzonka....wysyłajšc kolejne znaczki.
Jakoś się toto nie wykłada....powiem
więcej....zastanawiałem sie nad jeszcze
szybszš transmisjš....wiesz - druga
strona urzšdzenia jest niekiedy prawie 5x
szybsza ;-)
Też fakt. Lata, jak głupie, właściwie powinienem
się zapytać dokładniej skąd to opóźnienie po
nadawaniu,
tak się teraz zastanawiam, czy to nie są jakieś
pozostałości po poprzednich wersjach.
Jak to w windozie bywa ;-)


Którego? Mojego czy Twojego? ;-)) Nie
mów że to odpaliłeś?...nic się nie
chwalisz :-( (prv?)
Twojego, mojego też nie. Nie należy naprawiać
czegoś co nie jest zepsute. ;-)
Odpalić, odpaliłem, tylko coś namieszałem.
TO było chyba ze dwa dni temu i z powodu
kociokwiku
jaki miałem ostatnio, teraz nawet nie pamiętam co
źle zrobiłem. Ale pamiętam, że to ja źle zrobiłem
;-)


PIII_at_nospam_550 ;-)) PC-ty sš szybkie, ale nie
gubiš niczego :-) Co najwyżej
programista o czymś zapomina ;-)
Albo zapomniał o jakiejś ułomności peceta. ;-)

??? Moim zdaniem cały czas wmawiałeś
nam że masz transmisję synchronicznš -
drogš radiowš ;-)))
Iii... zbyt skomplikowane, aby mi się chciało
tak robić ;-)
Ale pierwsze wersje radiówek opierały się na
wyimaginowanym sygnale CLK,
procek niby go odtwarzał i taki sygnał wysyłał do
układów peryferyjnych
HCT164, TPIC6... coś tam (bardzo fajne wejście
szeregowe z synchronicznym
wpisywaniem na wyjścia mocy), i inne o podobnym
skomplikowaniu.

A co? Może moja? ;-)

Noo...tak ;-) albo programisty który to
dla Ciebie pisał.
W/g mnie raczej Gatesa. To takie modne. ;-)

Ja tylko tak informuję, że taki
problem występuje i ewentualnie jestem
ciekaw czy dotyczy on tylko Delphi.

Grrr....;-))
No co? Spytać się nie można? ;-)


Ale też więcej $ i być może satysfakcji ;-)
Satysfakcji to nigdy nie będzie, gdyż
nie istnieje program/urzšdzenie
doskonałe. :-(

O...idealista?
Realista. :-(
Szczególnie w elektronice. Jak zobaczyłem '51
Cygnal'a
z zegarem 100MHz to mi kopara opadła.
Zresztą jak zobaczyłem, że w BASCOM'ie można usiąć
i prawie
od ręki napisać program z grafiką, pwm, adc i
innymi bajerami
bez grzebania w sieci i tracenia czasu na naukę
programu.

A tak...więcej zarabiasz, więcej
potrzebujesz - ciekawe zjawisko ;-)
Ale z drugiej strony ludzie bez pieniędzy
nie maja tych problemów. :-(
Miłego wieczoru Arturze.
Wzajemnie, a właściwie miłego dnia. ;-)
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Wed, 10 Jul 2002 09:13:21 +0200


{ciach}

Artur...może wykonamy podprogram PASS? ;-)
Jest tyle ciekawszych tematów....np: AVR GCC, VHDL......

Miłego dnia.
--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 11 Jul 2002 11:57:17 +0200


Artur...może wykonamy podprogram PASS? ;-)
Jest tyle ciekawszych tematów....np:
AVR GCC, VHDL......
Hmm... spodobał mi się CV, a AVRGCC nie bardzo
chciał się zainstalować, zresztą, z tego co
oglądałem
to dużej różnicy w podstawach między nimi nie ma,
więc w zasadzie napisane podprogramy w jednym
powinne bez większych kłopotów działać i na
drugim.
Za VHDL to się wezmę dopiero w sierpniu, ale za to
ciurkiem ;-)

Miłego dnia.
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Thu, 11 Jul 2002 13:04:40 +0200


Hmm... spodobał mi się CV, a AVRGCC nie bardzo
chciał się zainstalować, zresztą, z tego co
oglądałem to dużej różnicy w podstawach między nimi nie ma,
więc w zasadzie napisane podprogramy w jednym
powinne bez większych kłopotów działać i na
drugim.

Wiesz..jesli masz potrzeby/motywację do zakupu CV to świetnie - zostań
przy nim (mnie też się podoba).
Ja natomiast na AVR-ach sporadycznie przekraczam 2k (wogóle mało ich
używam), wiec....sam rozumiesz ;-)

Za VHDL to się wezmę dopiero w sierpniu, ale za to ciurkiem ;-)

Jasne.
--
PZD, Irek.N.
ps. kostki do zabawy już dotarły, pcb jeszcze nie.. ;-))


Poprzedni Następny
Wiadomość
Spis treści
From: Marcin Stanisz <mstanisz_at_nospam_poczta.onet.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: 12 Jul 2002 11:13:32 GMT


W artykule <3D2A8F08.EB564D0F_at_nospam_multispedytor.com.pl>
Ireneusz Niemczyk napisal(a):
To nie ma znaczenia....co prawda goście z mało-miękkiego dali _d..._ w 2k oraz
XP i lekko zmienili _podejście_ do RS-a, ale generalnie wszystkie systemy
spokojnie radzą sobie z full dupleksem (przynajmniej wszystkie jakie
sprawdzałem, czyli 98, 98SE, ME, 2K, XP, NT4).

...i 95 :-)

Marcin Stanisz
--

"A lie will go round the world before the truth has got its boots on"
Terry Pratchett, "Truth"

Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Fri, 12 Jul 2002 17:46:41 +0200


...i 95 :-)

O właśnie, i 95 :-)
THX.
--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: jfox_at_nospam_poczta.onet.pl (J.F.)
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 08 Jul 2002 16:30:44 GMT


On 8 Jul 2002 09:55:01 +0200, ziel wrote:
Idzie przez radio, więc RTS DTR odpada.
[...]
Nigdy nie napisałem żadnego programu w Delphi, ale wygląda to tak, że
po nadawaniu i natychmiastowym przejściu do odbioru, uP musi czekać
na tego wielkiego szybkiego i wspaniałego peceta około 1-2 milisekundy.
Niezależnie od wielkości paczki. Może to windoza tak się spowalnia?

Idzie przez radio. Full duplex ?
Bo inaczej - jaki radio ma czas przelaczania Tx/Rx ?

Oczywiście piszę teraz o synchronicznym.

Pecet i synchronicznie ? Specjalna karta czy programowo ?
Czy moze inaczej nalezy "synchronicznie" rozumiec ?

Ułatwię. Pecet jest dołączony do radia i komunikuje się z kilkunastoma uP.
Co będzie wysłane do następnego uP jest zależne od tego co zostało odebrane.
Czyli muszę zachować kolejność i dokładnie wiedzieć na jakie pytania
odpowiadają uP.


J.


Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 01:41:16 +0200


Idzie przez radio. Full duplex ?
Bo inaczej - jaki radio ma czas przelaczania Tx/Rx ?
Teoretycznie tak, kazdy procek ma niezależny nadajnik i niezależny
odbiornik. W praktyce i tak tylko jedno z nich w danym czasie pracuje.

Oczywiście piszę teraz o synchronicznym.

Pecet i synchronicznie ? Specjalna karta czy programowo ?
Czy moze inaczej nalezy "synchronicznie" rozumiec ?
A to są jakieś problemy z sychronicznym (sprzetowym) nadawaniem w pececie?
W tym wypadku synchroniczne są dane względem siebie, nie taktowane
zegarem. Chociaż tak do końca to też nie jest prawdą, bo sygnał z peceta
zanim trafi do nadajnika, ma jeszcze po drodze kawałek sprzętu.
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: jfox_at_nospam_poczta.onet.pl (J.F.)
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Tue, 09 Jul 2002 17:14:46 GMT


On 9 Jul 2002 01:41:16 +0200, ziel wrote:
Idzie przez radio. Full duplex ?
Bo inaczej - jaki radio ma czas przelaczania Tx/Rx ?
Teoretycznie tak, kazdy procek ma niezależny nadajnik i niezależny
odbiornik. W praktyce i tak tylko jedno z nich w danym czasie pracuje.

Pasma wystarczajaco inne ? Zeby nie bylo tak ze wlaczony nadajnik
peceta blokuje odbiornik..

Oczywiście piszę teraz o synchronicznym.
Pecet i synchronicznie ? Specjalna karta czy programowo ?
Czy moze inaczej nalezy "synchronicznie" rozumiec ?

A to są jakieś problemy z sychronicznym (sprzetowym) nadawaniem w pececie?
W tym wypadku synchroniczne są dane względem siebie, nie taktowane
zegarem.

Co znaczy "synchroniczne" powtorze sie.
Z trybami powszechnie uznawanymi za "synchroniczne" [BSC, HDLC itp]
klopot jest taki ze standardowy port w pececie w ogole ich nie
obsluguje..

J.


Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 19:51:16 +0200


Pasma wystarczajaco inne ? Zeby nie
bylo tak ze wlaczony nadajnik
peceta blokuje odbiornik..
Wystarczająco. Oddzielne moduły nadawcze i
odbiorcze z własnymi
antenami.

Co znaczy "synchroniczne" powtorze sie.
Z trybami powszechnie uznawanymi za
"synchroniczne" [BSC, HDLC itp]
klopot jest taki ze standardowy port w
pececie w ogole ich nie
obsluguje..
Jednak obsługuje ;-)
We wcześniejszej wersji dane były synchronizowane
zegarem wychodzącym z peceta.
Oczywiście nie przez pin Rx ;-)
Ale było do d..., więc poprosiłem o zmianę i
obecnie przyjmuję dane a'la RC5,
ale synchronizowane w czasie, tzn. jest określony
czas nadawania, odbierania i czasu
trwania transmisji.
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Marek Lewandowski <nospam_at_nospam_poczta.onet.pl>
Subject: Re: RE: Czasy nadawania 89C2051 po Rs232
Date: Tue, 09 Jul 2002 20:18:25 GMT


on 9 Jul 2002 19:51:16 +0200 in
<DOELJDHHJKPIEKPIGAMEKEAMDIAA.zielpro_at_nospam_cavern.pl> ziel wrote:

Pasma wystarczajaco inne ? Zeby nie
bylo tak ze wlaczony nadajnik
peceta blokuje odbiornik..
Wystarczająco. Oddzielne moduły nadawcze i
odbiorcze z własnymi
antenami.

Mogą być nawet w osobnych obudowach, jak nadają na zbyt bliskich
częstotliwościach / zbyt szeroko w paśmie / sieją harmonicznymi to się
zatkają nawzajem.
--
Marek Lewandowski ICQ# 10139051
locustXpoczta|onet|pl
http://locust.republika.pl
[! Odpowiadaj pod cytatem. Tnij cytaty. Podpisuj posty. !]

Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: RE: Czasy nadawania 89C2051 po Rs232
Date: 10 Jul 2002 00:58:55 +0200


Mogą być nawet w osobnych obudowach,
jak nadają na zbyt bliskich
częstotliwościach / zbyt szeroko w
paśmie / sieją harmonicznymi to się
zatkają nawzajem.
I dlatego mają osobne antenki. Na wspólnej
czasami odbiornik wymagał chwili aby się
"odetkać".
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: jfox_at_nospam_poczta.onet.pl (J.F.)
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Tue, 09 Jul 2002 22:39:02 GMT


On 9 Jul 2002 19:51:16 +0200, ziel wrote:
Co znaczy "synchroniczne" powtorze sie.
Z trybami powszechnie uznawanymi za "synchroniczne" [BSC, HDLC itp]
klopot jest taki ze standardowy port w pececie w ogole ich nie
obsluguje..
Jednak obsługuje ;-)
We wcześniejszej wersji dane były synchronizowane
zegarem wychodzącym z peceta.
Oczywiście nie przez pin Rx ;-)
Ale było do d..., więc poprosiłem o zmianę i
obecnie przyjmuję dane a'la RC5,
ale synchronizowane w czasie, tzn. jest określony
czas nadawania, odbierania i czasu trwania transmisji.

Czyli nie jest to standardowa transmisja "asynchroniczna" ?
Bit startu, bity danych, bit stopu rownomiernie rozlozone w czasie?

To pretensje do tego kto program pisal ..

J.


Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 10 Jul 2002 02:05:16 +0200


Czyli nie jest to standardowa
transmisja "asynchroniczna" ?
Bit startu, bity danych, bit stopu
rownomiernie rozlozone w czasie?

To pretensje do tego kto program pisal ..

J.
Jakby mi to przeszkadzało, to i owszem.
W zasadzie ta transmisja wygląda na typową,
i zdawało mi się, że używa standardowych
komponentów.
Ale teraz po przemyśleniu chyba musiał zrobić coś
innego
niż użycie normalnego przesyłania danych.
Bity startu, parzystości i stopu występują, tylko
nie
wiem jak zrobił kodowanie danych.
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Janusz_K <Janusz_k.anty_at_nospam_um.bielsko.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Thu, 11 Jul 2002 13:06:56 +0200



Oczywiście piszę teraz o synchronicznym.

Pecet i synchronicznie ? Specjalna karta czy programowo ?
Czy moze inaczej nalezy "synchronicznie" rozumiec ?
A to są jakieś problemy z sychronicznym (sprzetowym) nadawaniem w pececie?
W tym wypadku synchroniczne są dane względem siebie, nie taktowane
zegarem. Chociaż tak do końca to też nie jest prawdą, bo sygnał z peceta
zanim trafi do nadajnika, ma jeszcze po drodze kawałek sprzętu.
Ej kolego mieszasz pojęcia z tym synchronicznym, to jak sobie wysyłasz
dane
względem siebie to twoja sprawa, a transmisja synchroniczna tym się
wyróznia
do asynchron że transmisja trwa w sposób ciągły, jak jest brak danych to
jest wysyłany jakiś znak
( teraz nie pamiętam) ale oznaczający puste (null), a dane poprzedzane
są odpowiednim
znakiem i kończone znakiem . To tak w dużym skrócie.

--
Pozdr.

Janusz
PS. Uwaga z adresu usuń '.ANTY'

Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 11 Jul 2002 22:58:49 +0200


Ej kolego mieszasz pojęcia z tym
synchronicznym, to jak sobie wysyłasz
dane
względem siebie to twoja sprawa, a
transmisja synchroniczna tym się
wyróznia
do asynchron że transmisja trwa w
sposób ciągły, jak jest brak danych to
jest wysyłany jakiś znak
( teraz nie pamiętam) ale oznaczający
puste (null), a dane poprzedzane
są odpowiednim
znakiem i kończone znakiem . To tak w
dużym skrócie.
A to z kolei jakieś novum.
Synhroniczna jest wtedy kiedy dane są
zsynchronizowane z zegarem
a tenże zegar taktuje jednocześnie odbiornik.
Faktycznie sposób nadawania jest troszkę
niezrozumiały,(teraz to widzę ;-))
a określenie "transmisja sychroniczna" pozostało z
czasów kiedy
faktycznie była także sprżetowo synchroniczna. W
chwili obecnej
takt zegara jest odtwarzany w odbiorniku i używany
do odbioru
następnego bajtu.
W czasie przerwy jest przerwa i nic ne lata po
przewodach.
Inna sprawa, że taka sychroniczna jest do bani i
większość
ludzi wysyła smieci w czasie przerwy, aby wiedzieć
czy jest połączenie,
oraz do małego token-ringu gdzie zamaist śmieci
latają sobie znaczniki.
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: Maciej Czapla <mc_at_nospam_sensor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Fri, 12 Jul 2002 00:46:40 +0200


A to z kolei jakieś novum.

To jest raczej 'starum'. W pełnej synchronicznej zegar i dane leca cały czas i
najwyżej wstawiane są różne 'wypełniacze' (zob. HDLC, SDLC, etc). Przerwy to
są w quasi-synchronicznej np. SPI. Takt zegara w odbiorniku możesz odtworzyć
gdy znajdzie się on w sygnale przesyłanym (np. Manchester) i w tedy możesz
automatycznie dopasować częstotliwości taktowania. W RSie zakłada się zgodność
zegarów nadajnika i odbiornika, synchronizowany jest tylko początek bitu start
i to-to nazywa się transmisją asynchroniczną bo żadne dopasowywanie zegarów n.
i o. nie ma miejsca.

MC

Poprzedni Następny
Wiadomość
Spis treści
From: Janusz_K <Janusz_k.anty_at_nospam_um.bielsko.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Fri, 12 Jul 2002 09:11:18 +0200



wyróznia
do asynchron że transmisja trwa w
sposób ciągły, jak jest brak danych to
jest wysyłany jakiś znak
( teraz nie pamiętam) ale oznaczający
puste (null), a dane poprzedzane
są odpowiednim
znakiem i kończone znakiem . To tak w
dużym skrócie.
A to z kolei jakieś novum.
Synhroniczna jest wtedy kiedy dane są
zsynchronizowane z zegarem
a tenże zegar taktuje jednocześnie odbiornik.
Mylisz sie kolego, to o czym piszesz dotyczy np NRZ, kodu MANCHESTER
I PODOBNYCH GDZIE ZEGAR (ach ten capslock) jest wysyłany z danymi.
w rs transmisja synchroniczna znaczy to co napisałem powyżej.
Powiem jeszcze że kiedyś bardzo popularna, szczególnie na dużych
maszynach,
do pc-ta była potrzebna specjalna karta rs-a.

--
Pozdr.

Janusz
PS. Uwaga z adresu usuń '.ANTY'

Poprzedni Następny
Wiadomość
Spis treści
From: Milosz Skowyra <miloszek_at_nospam_fido.net.org.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 08 Jul 2002 12:30:52 +0200


ziel wrote:

Np. ja używam stałego kodu FFh jako początku paczki i następnych
dwóch/jednego bajtu zawirającego
ilość bajtów w paczce. W ten sposób procek wie kiedy nastąpi koniec paczki.

Troszke dziwne wartosc te FFh, bo jak zrobisz zwarcie i rozwarcie to
procek wlasnie dostanie 0FFh, moj nauczyciel na wykladach zawsze
powtarzal ze transmisje powinno sie robic na bajtach 0-127, jak jest 8
bit to odrzucac jako blad.
--
Regards. Przy odpowiedzi usun "." przed "net" z adresu!!!
|-----------------------------------------------------|
| Milosz Skowyra GSM Mobile +48 600 95 35 72 |
| miloszek_at_nospam_fido.net.org.pl 2:484/2.47 on fidonet |
|-----------------------------------------------------|
Proscie, a bedziecie prosci.

Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 01:41:16 +0200


Troszke dziwne wartosc te FFh, bo jak zrobisz zwarcie i rozwarcie to
procek wlasnie dostanie 0FFh, moj nauczyciel na wykladach zawsze
powtarzal ze transmisje powinno sie robic na bajtach 0-127, jak jest 8
bit to odrzucac jako blad.
To się nazywa chodzenie na skróty. ;-)
Dane nigdy nie przyjmują wartości FFh, a odebranie samego FFh niczego nie
zmienia.
Jest tylko wstępem do transmisji, jeśli w trakcie odbierania danych otrzyma
FFh,
wtedy program skacze do obsługi błędów, jeśli za FFh nie przyjdzie
natychmiast
określona sekwencja w działaniu programu nic się nie zmieni.
7-bitowa transmisja odpada, ze względu na duże ilości danych w krótkim
czasie.
A dane częściowo są 4-ro lub 8-io bajtowe, nawet mega128 ma niewielki
zapas czasu.
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: "Gift" <witek_at_nospam_cordef.net.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Sun, 7 Jul 2002 22:00:12 +0200


Odpowiem zbiorowo:

A pamietasz o tym, ze procek ma jednobajtowy bufor? Moze zwyczajnie go
przepelniasz?
Procek ma tak skonstruowany program, że trzy bajty odsyła po odebraniu
dokładnie trzech bajtów. Bufor jest 1b ale program ma zmienną i czeka na 3
bajty.

A jeżeli nie, to obstawiałbym winę Twojego programu.
Nie wyrabia i odpowiada z opóźnieniem.
Program w uP wysyła 3 bajty dopiero po kilkudziesięciu ms od odebrania 3
bajtów. Być może nie wyrabia program w PC (między nadaniem ostatniego bajtu
a obsługą odbioru pierwszego)

czy wynik poprawny/niepoprawny jest zależny od zawartości tych zwracanych
bajtów ?
Nie zależy. Jest przypadkowy.

W zasadzie po zwiększeniu delaya w uP między wysyłanymi bajtami %błednych
przesyłów znacznie mi spadł. Dobrałem sobie przerwy eksperymentalnie, bo
nadal nie wiem od czego to zależy i z czym jest związane.

Pozdr
Witek


Poprzedni Następny
Wiadomość
Spis treści
From: "Mariusz Ł." <elprojekt_at_nospam_poczta.onet.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Sun, 7 Jul 2002 23:36:24 +0200


Jest inny komponent freeware'owy, który przetestowałem pod WIN95/98/2000/XP.
Nie mam z nim żadnych problemów, od kiedy zrobiłem całą komunikację z uC w
ASCII.
Do programowania na PC używam Buildera C++.
Komponent jest do ściągnięcia na : http://delphi.icm.edu.pl/ jako plik o
nazwie : as200d4.zip.
Jest wersja dla Delphi.

Pozdrawiam,

Mariusz Ł.


Użytkownik "Gift" <witek_at_nospam_cordef.net.pl> napisał w wiadomości
news:aga6u7$idm$1_at_nospam_news.tpi.pl...
Odpowiem zbiorowo:

A pamietasz o tym, ze procek ma jednobajtowy bufor? Moze zwyczajnie go
przepelniasz?
Procek ma tak skonstruowany program, że trzy bajty odsyła po odebraniu
dokładnie trzech bajtów. Bufor jest 1b ale program ma zmienną i czeka na 3
bajty.

A jeżeli nie, to obstawiałbym winę Twojego programu.
Nie wyrabia i odpowiada z opóźnieniem.
Program w uP wysyła 3 bajty dopiero po kilkudziesięciu ms od odebrania 3
bajtów. Być może nie wyrabia program w PC (między nadaniem ostatniego
bajtu
a obsługą odbioru pierwszego)

czy wynik poprawny/niepoprawny jest zależny od zawartości tych zwracanych
bajtów ?
Nie zależy. Jest przypadkowy.

W zasadzie po zwiększeniu delaya w uP między wysyłanymi bajtami %błednych
przesyłów znacznie mi spadł. Dobrałem sobie przerwy eksperymentalnie, bo
nadal nie wiem od czego to zależy i z czym jest związane.

Pozdr
Witek




Poprzedni Następny
Wiadomość
Spis treści
From: "Sebcio XM" <sebcio_at_nospam_xmv6.mud.spam-acme.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 8 Jul 2002 09:47:21 +0200


Użytkownik "Mariusz Ł." <elprojekt_at_nospam_poczta.onet.pl> napisał w wiadomości
news:agacbs$r0q$1_at_nospam_absinth.dialog.net.pl...

Jest inny komponent freeware'owy, który przetestowałem pod
WIN95/98/2000/XP.
Nie mam z nim żadnych problemów, od kiedy zrobiłem całą komunikację z uC w
ASCII.
Komponent jest do ściągnięcia na : http://delphi.icm.edu.pl/ jako plik o
nazwie : as200d4.zip.

ja używam tego komponentu we wszystkich swoich aplikacjach i chodzi bez
zarzutu - używam Delphi 5.


--
* Sebcio, Gdańsk



Poprzedni Następny
Wiadomość
Spis treści
From: "Gift" <witek_at_nospam_cordef.net.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 8 Jul 2002 21:36:39 +0200


Komponent jest do ściągnięcia na : http://delphi.icm.edu.pl/ jako plik o
nazwie : as200d4.zip.
Jest wersja dla Delphi.

Ale nie ma dla Delphi 3.0 :-(((


Poprzedni Następny
Wiadomość
Spis treści
From: <wieczus_at_nospam_go2.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 07:17:02 +0200


Komponent jest do ściągnięcia na : http://delphi.icm.edu.pl/ ....
Ale nie ma dla Delphi 3.0 ....

Witam

http://www2.arnes.si/~sopecrni - ale tam jest - swietny komponent polecam
wszystkim.

pzdr Tomek

--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 08 Jul 2002 09:16:26 +0200


A pamietasz o tym, ze procek ma jednobajtowy bufor? Moze zwyczajnie go
przepelniasz?
Procek ma tak skonstruowany program, że trzy bajty odsyła po odebraniu
dokładnie trzech bajtów. Bufor jest 1b ale program ma zmienną i czeka na 3
bajty.

Czy dobrze myślę:

W takim razie pozostaje jedno pytanie - czy masz wystarczająco dużo czasu po
stronie procka, aby niezawodnie odebrać każdy z przychodzących bajtów?
Może zrób sobie podgląd ile odebrał - ilość odebranych bajtór wystaw naprzykład
na port - od razu będziesz wiedział czy procek nie zgupił czegoś.
Acha - wypadało by napisać jakie masz parametry transmisji, jeśli to 9600 to
raczej nie w tym problem, jeśli natomiast 115k2...;-))
A może zapodaj źródła....w czym to masz napisane ?

A jeżeli nie, to obstawiałbym winę Twojego programu.
Nie wyrabia i odpowiada z opóźnieniem.
Program w uP wysyła 3 bajty dopiero po kilkudziesięciu ms od odebrania 3
bajtów.

Skoro odpowiada to znaczy ze dostał 3 bajty - inaczej nie odpowie, czy tez
odpowie zawsze po kilkudziesieciu ms niezaleznie od tego ile dostał?

Być może nie wyrabia program w PC (między nadaniem ostatniego bajtu
a obsługą odbioru pierwszego)

Hmm...u mnie wyrabiał sie z full dupleksem na 115k2 nawet na słabych maszynach
(API). Myślisz że użyty komponent jest taki słaby?

Nie zależy. Jest przypadkowy.

Dla mnie przepełniasz bufor procka...tak mi to wygląda. Najmniejszy bufor PC-ta
to chyba 8 znaków...nie sądzę żebyś tutaj coś tracił.
Może natomiast masz błąd w oprogramowaniu PC? Włącz sobie monitor portu
szeregowego i będziesz wiedziałile wyszło i ile przyszło do PC-ta. Coś w końcu
musisz zacząć eliminować!!!

W zasadzie po zwiększeniu delaya w uP między wysyłanymi bajtami %błednych
przesyłów znacznie mi spadł. Dobrałem sobie przerwy eksperymentalnie, bo
nadal nie wiem od czego to zależy i z czym jest związane.

Ale po co jakieś przerwy...odebrał - niech natychmiast wyśle odpowiedź. W jakim
celu ta przerwa?

--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: "Gift" <witek_at_nospam_cordef.net.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 8 Jul 2002 21:18:11 +0200


Procek podpięty pod PC jest w zasadzie "pośrednikiem" między PC a innym
prockiem - rzeczywitym odbiornikiem, ale to nie istotne. PC wysyła 3 bajty.
Pierwszy bajt jest zawsze 1, żeby uP wiedział że leci paczka, pozostałe 2 to
bajty sterujące. uP odbiera wszystkie trzy bajty i po zapełnieniu bufora
(trzyelementowy array) wysyła je do innego uP (odbiornika). Że linia Tx
podpieta jest też pod PC - przy okazji mam kontrolę transmisji. PC odbiera
te same 3 bajty i jeśli są zgodne - jest OK, jeśli nie - ponownie wysyła te
same 3 bajty - i tak do bólu.

Delay'e w uP zastoowałem, bo wyczytałem gdzieś (a może mi się tylko tak
wydaje) że stan wysoki na linii Tx między ostatnim wysłanym bitem a
pierwszym następnym powinien trwać tyle samo ile czas wysłania wszystkich
poprzednich bitów. Delay w uP miał mi niby dopasować te przerwy między
wysyłanymi bajtami. Coś w tym musi być skoro
prinbin X1 : waitms 20
prinbin X1 : waitms 20
prinbin X1 : waitms 20
nie działało, a po zmianie 20 na 50 zaczęło chodzić w mirę przyzwoicie.

Inna rzecz, że faktycznie, że do komponentu który używam sam mam jakieś
ograniczone zaufanie.


Witek


Poprzedni Następny
Wiadomość
Spis treści
From: "Zbych" <bzb_at_nospam_poczta.onet.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 8 Jul 2002 23:06:19 +0200


Delay'e w uP zastoowałem, bo wyczytałem gdzieś (a może mi się tylko tak
wydaje) że stan wysoki na linii Tx między ostatnim wysłanym bitem a
pierwszym następnym powinien trwać tyle samo ile czas wysłania wszystkich
poprzednich bitów.

Postępowanie takie ma sens, gdy istnieje możliwość, że odbiorca zacznie
nasłuch
np. w połowie transmisji bajtu w długim ciągu danych. Jeśli zostawisz duży
odstęp między bajtami to początek każdego bajtu będzie rozpoznany
prawidłowo,
w przeciwnym wypadku nie da się odróżnić początku bajtu od jego środka.




Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 08 Jul 2002 23:51:35 +0200


Postępowanie takie ma sens, gdy istnieje możliwość, że odbiorca zacznie
nasłuch
np. w połowie transmisji bajtu w długim cišgu danych. Jeśli zostawisz duży
odstęp między bajtami to poczštek każdego bajtu będzie rozpoznany
prawidłowo,
w przeciwnym wypadku nie da się odróżnić poczštku bajtu od jego środka.

Pisze, że pierwszy bajt jest flagš, jeśli więc poprawnie napisał program to
spokojnie powinien wskoczyć w ramkę (chyba że reszta danych też będzie kodem
flagi) ;-)

--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 08 Jul 2002 23:50:13 +0200


No ale nadal niczego nie wyeliminowałeś...tak to sobie możemy gdybać wiesz dokšd
;-))
--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 01:41:26 +0200


(trzyelementowy array) wysyła je do innego uP (odbiornika). Że linia Tx
podpieta jest też pod PC - przy okazji mam kontrolę transmisji. PC odbiera
te same 3 bajty i jeśli są zgodne - jest OK, jeśli nie - ponownie
wysyła te
same 3 bajty - i tak do bólu.
Czy to znaczy, że pecet na jednym porcie nadaje, a na drugim śledzi
transmisję
między prockami?


Delay'e w uP zastoowałem, bo wyczytałem gdzieś (a może mi się tylko tak
wydaje) że stan wysoki na linii Tx między ostatnim wysłanym bitem a
pierwszym następnym powinien trwać tyle samo ile czas wysłania wszystkich
poprzednich bitów. Delay w uP miał mi niby dopasować te przerwy między
wysyłanymi bajtami. Coś w tym musi być skoro
prinbin X1 : waitms 20
prinbin X1 : waitms 20
prinbin X1 : waitms 20
nie działało, a po zmianie 20 na 50 zaczęło chodzić w mirę przyzwoicie.
Aż 50ms?!
Coś za długo. 50usek, to rozumiem, ale 50ms?
To moze zapytam inaczej, bezpośrednio, czy masz duże doswiadcznie w pisaniu
programów na uP i w jakim języku piszesz.


Inna rzecz, że faktycznie, że do komponentu który używam sam mam jakieś
ograniczone zaufanie.
Bo sporo śmieci jest, tzn. ktoś coś napisał, jemu chodzi w konkretnym
zastosowaniu,
ale przy próbie użycia w innym układzie zaczyna się sypać. Trzeba albo
dobrze
znać Delphi, albo przećwiczyć kilka komponentów.
pzdr
Artur


Witek



--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: "Gift" <witek_at_nospam_cordef.net.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 8 Jul 2002 21:45:55 +0200


Aaaa.... i jeszcz....
Acha - wypadało by napisać jakie masz parametry transmisji, jeśli to 9600
to
raczej nie w tym problem, jeśli natomiast 115k2...;-))
A może zapodaj źródła....w czym to masz napisane ?

Nie szaleję z transmisją - 2400 w zupełności mi wystarcza. W końcu są to
tylko 3 bajty.
Napisane w BASCOM. Sorry, ale dopiero się uczę - to mój pierwszy program.
Źródło? Służę uprzejmie - jeśli grupa mnie nie zakrzyczy wsadzam tu
wszystko. Nie będę ukrywał, że "szkielet" programu nie jest mojego pomysłu.

Skoro odpowiada to znaczy ze dostał 3 bajty - inaczej nie odpowie, czy tez
odpowie zawsze po kilkudziesieciu ms niezaleznie od tego ile dostał?

Odpowiada i znaczy, że dostał 3 bajty. Tylko PC mi je gubi. Myślę (teraz
coraz bardziej przekonany) że to wina komponentu. Może yo on nie wyrabia.

I listing:

$crystal = 11059200
$noinit
$serialoutput = Send

Dim Buf(3) As Byte
Dim Ind As Byte
Dim Bufor As Byte
Dim Send_ok As Bit
Rx Alias Scon.0
Tx Alias Scon.1
On Serial Serial_int

Main:
P1 = 0
Tcon = 0
Scon = &B01110000
Tmod = &B00100001
Pcon = &B10000000
Th1 = 232 'th1=232 2400
bodów
Set Tcon.6
Rx = 0
Tx = 0
Ind = 1
Send_ok = 0

Enable Serial
Priority Set Serial
Enable Interrupts

Set Scon.5
Reset Scon.4
Set P1.7 'wlaczenie
nadajnika
Waitms 30
Printbin 1 : Waitms 50 'sygnał dla PC, że uP się włączył
Printbin 64 : Waitms 50
Printbin 128 : Waitms 50
Waitms 30
Reset P1.7 'wylaczenie
nadajnika
Reset Scon.5
Set Scon.4

Do
If Ind = 4 Then
If Buf(1) = 1 Then
Ind = 1
Set Scon.5
Reset Scon.4
Set P1.7 'wlaczenie
nadajnika
Waitms 30
Printbin Buf(1) : Waitms 50
Printbin Buf(2) : Waitms 50
Printbin Buf(3) : Waitms 50
Waitms 30
Reset P1.7 'wylaczenie
nadajnika
Reset Scon.5
Set Scon.4
End If
End If
Loop
End

Serial_int:
If Tx = 1 Then
Tx = 0 : Rx = 0
Send_ok = 0
End If

If Rx = 1 Then 'odbior
jednego bajtu
Rx = 0 : Tx = 0
If Sbuf = 1 Then 'jesli pierwszy przychodzacy jest 1 resetuje
indeks
Ind = 1
End If
Buf(ind) = Sbuf 'wpisanie odebranego bajtu do bufora
Incr Ind
End If
Return

!Send:
Bitwait Send_ok , Reset
Send_ok = 1
MOV SBUF , acc
ret


Ot co.

Pozdrowionka
Witek


Poprzedni Następny
Wiadomość
Spis treści
From: Ireneusz Niemczyk <i.niemczyk_at_nospam_multispedytor.com.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 08 Jul 2002 23:59:30 +0200


Nie szaleję z transmisjš - 2400 w zupełności mi wystarcza. W końcu sš to
tylko 3 bajty.

Bardzo wolno...nie powinno być żadnych problemów.

Napisane w BASCOM. Sorry, ale dopiero się uczę - to mój pierwszy program.
Źródło? Służę uprzejmie - jeśli grupa mnie nie zakrzyczy wsadzam tu
wszystko. Nie będę ukrywał, że "szkielet" programu nie jest mojego pomysłu.

Yyy....bascom....Arturze, Januszu, ......... plisss ;-)))

Odpowiada i znaczy, że dostał 3 bajty. Tylko PC mi je gubi. Myślę (teraz
coraz bardziej przekonany) że to wina komponentu. Może yo on nie wyrabia.

Zrób tak: podłšcz inny komp w miejsce gdzie spodziewasz się tracić bajty i
zaobserwuj w np: terminalu norton commandera co tam lata. Ten terminal nawet
na 486sx25 nie gubi zadnego bajtu przy 115k2!!! co najwyżej lekko go przytka na
chwilkę ;-))

{dalej ciach, ale zapewne ktoś kompetentny się wypowie}

-)
Wiktor - zacznij eliminować elementy, bo inaczej nie pewnie nie dojdziesz zbyt
szybko do przyczyny. Ja jakoś nie wyobrażam sobie, aby przy takich parametrach
cokolwiek PC mogło gubić. Prędzej zrzucił bym to na winę paprochów jakie latajš
Ci po masie połšczenia RS-owego. Jeżeli PC sieje jak szalone, do tego
sterowniczek który jest podłšczony do niego też sieje jak szalony (zasilacze!),
to może się transmisja chrzanić....raczej będš to przekłamania niż amba, ale
warto i taki scenariusz sprawdzić. Podłšcz chassis (blachę) gniazda PC (RS-a) z
masš sterownika - na 100% nie zaszkodzi, a może pomoże :-)
--
PZD, Irek.N.



Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 09:08:01 +0200


I listing:

$crystal = 11059200
$noinit
$serialoutput = Send

Program wygląda na działający.
Ja bym się raczej przyjrzał pecetowi, ale w wolnej chwili
zobaczę jak mnie działa.
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: "Sebcio XM" <sebcio_at_nospam_xmv6.mud.spam-acme.pl>
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 8 Jul 2002 09:52:56 +0200


Użytkownik "Gift" <witek_at_nospam_cordef.net.pl> napisał w wiadomości
news:aga6u7$idm$1_at_nospam_news.tpi.pl...

Procek ma tak skonstruowany program, że trzy bajty odsyła po odebraniu
dokładnie trzech bajtów. Bufor jest 1b ale program ma zmienną i czeka na 3
bajty.

a czy czekasz na koniec transmisji ? Może najzwyczajniej nadpisujesz
SBUF'a wartościami następnych bajtów ? Może o tym doskonale wiesz ;-) ale
czy na pewno Twój program wygląda podobnie do tego poniżej ?

...
CLR TI
MOV SBUF, A
JNB TI, $
...

oczywiście to prosty program nadawczy bez buforów i obsługi w przerwaniu
ale chodzi o filozofię. Tak napisana transmisja będzie wysyłała ciurkiem
dane bez błędów - napisałem w Delphi wiele programów komunikujących się via
RS z mikrokontrolerami i to zawsze działało.

W zasadzie po zwiększeniu delaya w uP między wysyłanymi bajtami %błednych
przesyłów znacznie mi spadł. Dobrałem sobie przerwy eksperymentalnie, bo
nadal nie wiem od czego to zależy i z czym jest związane.

tak nie powinno być. Przyczyn może być wiele.


--
* Sebcio, Gdańsk



Poprzedni Następny
Wiadomość
Spis treści
From: jfox_at_nospam_poczta.onet.pl (J.F.)
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Mon, 08 Jul 2002 16:30:39 GMT


On Sun, 7 Jul 2002 22:00:12 +0200, Gift wrote:
Procek ma tak skonstruowany program, że trzy bajty odsyła po odebraniu
dokładnie trzech bajtów. Bufor jest 1b ale program ma zmienną i czeka na 3
bajty.
Nie wyrabia i odpowiada z opóźnieniem.
Program w uP wysyła 3 bajty dopiero po kilkudziesięciu ms od odebrania 3
bajtów. Być może nie wyrabia program w PC (między nadaniem ostatniego bajtu
a obsługą odbioru pierwszego)

W zasadzie po zwiększeniu delaya w uP między wysyłanymi bajtami %błednych
przesyłów znacznie mi spadł. Dobrałem sobie przerwy eksperymentalnie, bo
nadal nie wiem od czego to zależy i z czym jest związane.

A kwarc masz odpowiedni ?
3 bajty nie przekraczaja mozliwosci peceta - jak dziala na
przerwaniach to odbierze jeszcze wiecej bez problemu.

Najpierw to bym sie obawial:
1) twojego programu na uP - wyrabia sie czasowo z odbiorem czy gubi
znaki ?
2) nie masz tam jakis przelaczanych jednokierunkowych buforow ? Wtedy
trzeba poczekac.
3) prawidlowo czekasz w uP na gotowosc nadajnika ? TI musi byc
ustawione przed wpisem do SBUF.

4) zasilanie buforow - moze siada w trakcie transmisji i tylko na
dwa bajty starcza ?


Napisz program ktory w petli bedzie czekal i wysylal coraz dluzsze
ciagi znakow [np 'A', 1s przerwy 'AB', 1s , 'ABC', 1s, ..] - zobaczysz
co sie dzieje.

J.


Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 01:41:25 +0200


A kwarc masz odpowiedni ?
3 bajty nie przekraczaja mozliwosci peceta - jak dziala na
przerwaniach to odbierze jeszcze wiecej bez problemu.
No wiesz, za kogo mnie uważasz? ;-)

Najpierw to bym sie obawial:
1) twojego programu na uP - wyrabia sie czasowo z odbiorem czy gubi
znaki ?
Z niewielkim zapasem czasu w najmniej korzystnym przypadku.

2) nie masz tam jakis przelaczanych jednokierunkowych buforow ? Wtedy
trzeba poczekac.
Nie, wszystko ma swoje piny, swój RAM, swoje przerwania i swój czas.

3) prawidlowo czekasz w uP na gotowosc nadajnika ? TI musi byc
ustawione przed wpisem do SBUF.
Nie, teraz jest mega128, ale wcześniej na '51 był ten sam efekt.


4) zasilanie buforow - moze siada w trakcie transmisji i tylko na
dwa bajty starcza ?
Zasilanie jest OK. Po odczekaniu chwili można nadawać paczki nawet 8kb.



Napisz program ktory w petli bedzie czekal i wysylal coraz dluzsze
ciagi znakow [np 'A', 1s przerwy 'AB', 1s , 'ABC', 1s, ..] - zobaczysz
co sie dzieje.
Juz dawno to zrobiłem.
procek odbiera i natychmiast zaczyna wysyłać - pecet wyświetla głupoty.
procek odbiera, czeka 2 milisek. i wysyła - pecet odbiera prawidłowo.

Może bez specjalnego przekonania z tym walczyłem, ale efekt jest taki, że
to pecet potrzebuje czasu na przełączenie.
Paczki wysyłane w losowych odstępach czasu, są odbierane bez problemu,
pod warunkiem, że chwilę wcześniej pecet np. nie nadawał do innego
procka.
W końcu dałem sobie spokój, powiększyłem paczki o kilka bajtów i teraz
procek albo wysyła po 2ms paczkę albo kod błędu.
Ale gdzieś tam w głębi siedzi to pytanie : dlaczego? ;-)
pzdr
Artur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika


Poprzedni Następny
Wiadomość
Spis treści
From: jfox_at_nospam_poczta.onet.pl (J.F.)
Subject: Re: Czasy nadawania 89C2051 po Rs232
Date: Tue, 09 Jul 2002 17:14:46 GMT


On 9 Jul 2002 01:41:25 +0200, ziel wrote:
Juz dawno to zrobiłem.
procek odbiera i natychmiast zaczyna wysyłać - pecet wyświetla głupoty.
procek odbiera, czeka 2 milisek. i wysyła - pecet odbiera prawidłowo.
Może bez specjalnego przekonania z tym walczyłem, ale efekt jest taki, że
to pecet potrzebuje czasu na przełączenie.

Pecet nie potrzebuje nic na przelaczanie. Moze nadawac i wysylac
jednoczesnie.
Jedyny problem to oprogramowanie - ono moze zgubic znaki nie
odbierajac. Ale standardowa dzis kostka 16550 ma 16 bajtow buforu.

Cos wspominales o radiu ?

No chyba ze masz program calkowicie skopany i cos wyczynia
glupiego z portem w pececie .. resetuje go przed odbiorem ?

J.

Poprzedni Następny
Wiadomość
Spis treści
From: zielpro_at_nospam_cavern.pl (ziel)
Subject: RE: Czasy nadawania 89C2051 po Rs232
Date: 9 Jul 2002 20:01:17 +0200


Pecet nie potrzebuje nic na
przelaczanie. Moze nadawac i wysylac
jednoczesnie.
Jedyny problem to oprogramowanie - ono
moze zgubic znaki nie
odbierajac. Ale standardowa dzis kostka
16550 ma 16 bajtow buforu.
Ciekawe czy pecet o tym wie? ;-)

No chyba ze masz program calkowicie
skopany i cos wyczynia
glupiego z portem w pececie .. resetuje
go przed odbiorem ?
Może i skopany, ale dość złożony i pomijając ten
drobiazg
chodzi całkiem dobrze. Nie będę nikogo namawiał do
przekopania
programu z powodu zwłoki która mi nie przeszkadza.
;-)
pzdr
Arur


--
Archiwum grupy: http://niusy.onet.pl/pl.misc.elektronika