Ponownie: Komunikacja PC->Atmel
Masz problem? Zapytaj na forum elektroda.pl z bramką pl.misc.elektronika!
From: krisp_at_nospam_bbs.chip.pl (Krisp)
Subject: Ponownie: Komunikacja PC->Atmel
Date: Sun, 13 Dec 1998 20:59:52 GMT
Nie wiem jak zrobic transmisje z PC do atmela po rs232, tak aby na
chwile przerwac transmisje, zrobic cos z odebranymi danymi i
kontynuowac odbior. Transmisja odbywa sie komenda "copy com plik.hex
/b". W zwiazku z tym moge sterowac tylko z atmela. Oto zalozenia
techniczne:
-kwarc 11,0952, szybkosc >=1200 (zalezy jak szybko sie uda bez bledow)
-transmisja 8-bit bez parzystosci, z 1 bitem stopu
-wysylam plik ascii w formacie intelhex. Chce po kazdej linii (max 64
bajty) zatrzymac transmisje.
-po otrzymaniu 1 rekordu, dekoduje go i zapisuje w pamieci
eeprom(28C64).
Pozdrowienia
Krzysztof Pawlewicz
From: Nicieja =?iso-8859-2?Q?Pawe=B3?= <nita_at_nospam_darmo.alter.pl>
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Sun, 13 Dec 1998 23:08:44 +0100
Może należałoby tu wykorzystać linie CTS (czy coś takiego) podanie jakieś
tam stanu powoduje wszczymanie wysyłania danych przez PC
Więcej informacji możesz znaleść w Nowym Elektroniku 4/98
Nita.
From: Olgierd Cybulski <cybulski_at_nospam_pkpf.if.uj.edu.pl>
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Mon, 14 Dec 1998 14:55:01 +0100
Krisp wrote:
Nie wiem jak zrobic transmisje z PC do atmela po rs232, tak aby na
chwile przerwac transmisje, zrobic cos z odebranymi danymi i
kontynuowac odbior. Transmisja odbywa sie komenda "copy com plik.hex
/b". W zwiazku z tym moge sterowac tylko z atmela. Oto zalozenia
techniczne:
"Copy" to kiepska rzecz.
Może różnie działać na różnych komputerach.
Lepiej samemu sobie napisać programik z testowaniem
handshake'ów.
A jeśli koniecznie ma to być COPY, to może
spróbuj z linią CTS .
Albo zrobić obsługę portu szeregowego ATMELka
na przerwaniu, które ładuje odebrane bajty do bufora.
Oczywiście ma to sens tylko wtedy, gdy procesor zdąży obrobić
dane zanim bufor się przepełni.
Nie wiem, ile u Ciebie trwa zapis do eepromu.
I czy procedurę zapisującą można przerwać przerwaniem :-)
-------------------------------------------------
wśród blasku laserów i szumu wentylatorów
-------------------------------------------------
From: "Tomasz Gumny" <gumny_at_nospam_ikp.atm.com.pl>
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Mon, 14 Dec 1998 19:08:58 GMT
Olgierd Cybulski napisał(a) w wiadomości:
<367518B5.57D5_at_nospam_pkpf.if.uj.edu.pl>...
Krisp wrote:
Nie wiem jak zrobic transmisje z PC do atmela po rs232, tak aby na
chwile przerwac transmisje, zrobic cos z odebranymi danymi i
kontynuowac odbior. Transmisja odbywa sie komenda "copy com plik.hex
/b". W zwiazku z tym moge sterowac tylko z atmela. Oto zalozenia
techniczne:
"Copy" to kiepska rzecz.
Może różnie działać na różnych komputerach.
Moze i kiepska, ale dostepna "zawsze i wszedzie",
tzn. nie tylko na PC. Ja bym to zrobil tak:
1. Zakladam bufor na dwie linie pliku HEX
- juz odbiornik moze zamieniac pary znakow na bajty;
2. Gdy jedna odbieram - druga obrabiam i zapisuje;
3. Predkosc transmisji ustawiam (MODE) na tyle mala,
zeby podczas odbierania jednej linii starczylo czasu
na sprawdzenie poprzedniej i zapis do EEPROMu.
TG
From: krisp_at_nospam_bbs.chip.pl (Krisp)
Subject: Re: Re: Ponownie: Komunikacja PC->Atmel
Date: Tue, 15 Dec 1998 20:28:01 GMT
On Mon, 14 Dec 1998 19:08:58 GMT, "Tomasz Gumny"
<gumny_at_nospam_ikp.atm.com.pl> wrote:
Moze i kiepska, ale dostepna "zawsze i wszedzie",
tzn. nie tylko na PC. Ja bym to zrobil tak:
1. Zakladam bufor na dwie linie pliku HEX
- juz odbiornik moze zamieniac pary znakow na bajty;
2. Gdy jedna odbieram - druga obrabiam i zapisuje;
??? Wielozadaniowy Atmel ?? Czegos tu nie rozumiem. Prosze o
wyjasnienie.
Pozdrawiam
Krisp
From: "Tomasz Gumny" <gumny_at_nospam_ikp.atm.com.pl>
Subject: Re: Re: Ponownie: Komunikacja PC->Atmel
Date: Tue, 15 Dec 1998 21:40:45 GMT
Krisp napisał(a) w wiadomoci: <36776f35.12830979_at_nospam_news.chip.pl>...
On Mon, 14 Dec 1998 19:08:58 GMT, "Tomasz Gumny"
<gumny_at_nospam_ikp.atm.com.pl> wrote:
Moze i kiepska, ale dostepna "zawsze i wszedzie",
tzn. nie tylko na PC. Ja bym to zrobil tak:
1. Zakladam bufor na dwie linie pliku HEX
- juz odbiornik moze zamieniac pary znakow na bajty;
2. Gdy jedna odbieram - druga obrabiam i zapisuje;
??? Wielozadaniowy Atmel ?? Czegos tu nie rozumiem. Prosze o
wyjasnienie.
Odbierac i zapisywac do bufora linii mozesz na przerwaniu.
Sprawdzenie poprawnosci i zapis do EEPROMu poprzedniej linii
moze robic niezaleznie program glowny.
TG
From: Olgierd Cybulski <cybulski_at_nospam_pkpf.if.uj.edu.pl>
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Mon, 21 Dec 1998 17:07:56 +0100
J.F. wrote:
Co nazywasz oryginalnym przedpotopowym UART'em ?
8251 [nie 8051, tylko 8251] ?
Mial juz dodatkowy rejestr nadajnika.
Jednobajtowy :-)
Jesli po stronie odbiorczej zadecydowales ze chwilowo wiecej danych
nie chcesz, to licz sie z tym ze wlasnie sie transmituje nastepny
znak, a przed momentem nadajnik wlasnie wywolal przerwanie i kolejny
bajt czeka na wysylke. Razem - dwa bajty dotra w najblizszym czasie.
Jesli jeszcze np spozniles sie z przyjeciem przerwania troche - to
kolejny bajt czeka w buforze odbiornika :-)
Polemizowałbym. Jeśłi przerwanie od odbiornika jest priorytetowe,
to można zdążyć zablokować CTS na tyle szybko, że nadajnik
z pewnośćią nie zacznie jeszcze transmitować następnego znaku.
Bądź co bądź 8051 to nie PC, w 8051 wiadomo jaki jest
maksymalny czas czekania na obsługę przerwania, zwłaszcza,
gdy się samemu pisze jego programik :-)
Oczywiście powyższa uwaga nie dotyczy dużych szybkości
pracy UARTu.
Jeśli znasz jakieś oprogramowanie, które korzysta ze sprzętowych
buforów nowoczesnych UARTów, to napisz jakie, tylko
najpierw się upewnij, że są to bufory sprzętowe, a nie sostware'owe
bufory okrężne.
A kazde nowsze. Nie widziales zakladki w Control Panel do wlaczania
buforka 16550 ? Niewiele go, 16 bajtow, ale zawsze.
Nie widziałem. Mówisz o świndowsach 95 / 98 ?
Nie znam, nie używam :-)
juz XT umozliwial 115200, tylko wlasnie dopiero buforek w 16550
umozliwia wykorzystanie tej predkosci bardziej zaawansowanym od DOS
systemom...
Dzięki, nie wiedziałem.
O.C.
-------------------------------------------------
wśród blasku laserów i szumu wentylatorów
-------------------------------------------------
From: krisp_at_nospam_bbs.chip.pl (Krisp)
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Tue, 15 Dec 1998 20:27:54 GMT
On Mon, 14 Dec 1998 14:55:01 +0100, Olgierd Cybulski
<cybulski_at_nospam_pkpf.if.uj.edu.pl> wrote:
"Copy" to kiepska rzecz.
Mo=BFe r=F3=BFnie dzia=B3a=E6 na r=F3=BFnych komputerach.
Lepiej samemu sobie napisa=E6 programik z testowaniem
handshake'=F3w.
Slyszalem tylko ze jest cos takiego. Czy Moglbys powiedziec cos
blizej? Ewentualnie podac literature.
A je=B6li koniecznie ma to by=E6 COPY, to mo=BFe
spr=F3buj z lini=B1 CTS .
Nie sprawdzalem tego fizycznie, ale w pewnej ksiazce wydawnictwa
Helion (o RS-ach) przeczytalem ze zgaszenie cts zrywa transmisje.
Takze chyba sie nie nada.
Albo zrobi=E6 obs=B3ug=EA portu szeregowego ATMELka=20
na przerwaniu, kt=F3re =B3aduje odebrane bajty do bufora.
Oczywi=B6cie ma to sens tylko wtedy, gdy procesor zd=B1=BFy obrobi=E6
dane zanim bufor si=EA przepe=B3ni.
Zrobie tak jak nie uda sie zatrzymac przesylania.
Nie wiem, ile u Ciebie trwa zapis do eepromu.
I czy procedur=EA zapisuj=B1c=B1 mo=BFna przerwa=E6 przerwaniem :-)
raczej nie :((
-------------------------------------------------
w=B6r=F3d blasku laser=F3w i szumu wentylator=F3w
-------------------------------------------------
niezbyt przyjazne stanowisko pracy ;)))
Pozdrawiam
Krzysztof Pawlewicz
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: 16 Dec 1998 16:37:07 GMT
On Tue, 15 Dec 1998 20:27:54 GMT, Krisp <krisp_at_nospam_bbs.chip.pl> wrote:
On Mon, 14 Dec 1998 14:55:01 +0100, Olgierd Cybulski
A jeśli koniecznie ma to być COPY, to może
spróbuj z linią CTS .
Nie sprawdzalem tego fizycznie, ale w pewnej ksiazce wydawnictwa
Helion (o RS-ach) przeczytalem ze zgaszenie cts zrywa transmisje.
Takze chyba sie nie nada.
zrywa jak zrywa. jak wczesniej ustawisz mode com1:.....,p to nie zerwie,
tylko wstrzyma, a dokladniej - potrzebny jest stan aktywny na tej linii,
zeby BIOS zechcial wyslac cokolwiek. Podobnie na lini DSR .
Tyle ze copy potrafi pogubic pewne znaki. W transmisji .HEX to nie przeszkadza.
ale binarki nie przeslesz...
J.
From: "Tomasz Gumny" <gumny_at_nospam_ikp.atm.com.pl>
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Wed, 16 Dec 1998 18:54:49 GMT
Olgierd Cybulski napisał(a) w wiadomości:
<3678072C.762F_at_nospam_pkpf.if.uj.edu.pl>...
J.F. wrote:
Tyle ze copy potrafi pogubic pewne znaki. W transmisji .HEX to nie
przeszkadza.
ale binarki nie przeslesz...
Niestety, nie pomaga tu nawet switch "/b" .
Kretyństwo, no nie ?
O.C.
Mozecie napisac cos blizej o tym gubieniu znakow?
Od pol roku przesylam przez COPY pliki BIN
do programatora i nie zdazylo sie zeby cos
zginelo, ale w tym przypadku lepiej dmuchac
na zimne.
TG
From: Olgierd Cybulski <cybulski_at_nospam_pkpf.if.uj.edu.pl>
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Thu, 17 Dec 1998 15:39:47 +0100
Tomasz Gumny wrote:
Mozecie napisac cos blizej o tym gubieniu znakow?
Od pol roku przesylam przez COPY pliki BIN
do programatora i nie zdazylo sie zeby cos
zginelo, ale w tym przypadku lepiej dmuchac
na zimne.
Niestety, nie pamietam dokladnie gdzie tkwi blad.
O ile pamietam, COPY /B dotyczace kopiowania
plikow binarnych do plikow binarnych dziala zawsze
dobrze (nawet, gdy dodaje sie kilka plikow do pliku
wynikowego). Natomiast jesli kopiuje sie do RS lub
do LPT, to kopiowanie wywala sie na pewnej kombinacji
dwoch bajtow, nie pamietam ktorej (na pewno oba bajty
mniejsze od 32, tzn. jakieś znaki specjalne).
Dzieje się tak dlatego, że LPT i RS są plikami tekstowymi,
więc nawet instrukcja COPY /B nie jest w stanie zmienic
ich traktowania tak, by staly sie plikami binarnymi.
Testowalem to w ten sposob, ze przesylalem do portu (konkretnie
LPT) polecieniem COPY plik LPT1 / B
plik zawierający wszystkie możliwe kombinacje dwóch
sąsiednich bajtów. Plik ten miał długość 2 * 65536 bajtów .
Podczas przesyłania COPY / B następowało przekłamanie danych,
natomiast podczas transmisji niskiego poziomu (tzn. na poziomie
zaspisu do portów) wszystko było w porządku.
Może do tej pory owa felerna kombinacja u Ciebie nie wystąpiła.
A może ja coś spieprzyłem w swoich testach, i tak naprawdę
COPY /B jest w porządku ?
W każdym razie wszystkie moje programy używające drukarki
i przesyłające do niej np. bitmapy, lub wzory fontów true-type
używają transmisji niskiego poziomu, i dzięki temu błędów nie ma.
O.C.
-------------------------------------------------
wśród blasku laserów i szumu wentylatorów
-------------------------------------------------
From: Olgierd Cybulski <cybulski_at_nospam_pkpf.if.uj.edu.pl>
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Wed, 16 Dec 1998 20:17:00 +0100
J.F. wrote:
zrywa jak zrywa. jak wczesniej ustawisz mode com1:.....,p to nie zerwie,
tylko wstrzyma, a dokladniej - potrzebny jest stan aktywny na tej linii,
zeby BIOS zechcial wyslac cokolwiek. Podobnie na lini DSR .
Właśnie. Można zmienić stan linii CTS nawet podczas przesyłania znaku.
Wówczas zostanie on wysłany do końca, dopiero przed wysłaniem
następnego transmisja zostanie wstrzymana na czas zależny od ustawień
portu (a raczej transmisji).
Tyle ze copy potrafi pogubic pewne znaki. W transmisji .HEX to nie przeszkadza.
ale binarki nie przeslesz...
Niestety, nie pomaga tu nawet switch "/b" .
Kretyństwo, no nie ?
O.C.
-------------------------------------------------
wśród blasku laserów i szumu wentylatorów
-------------------------------------------------
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Wed, 16 Dec 1998 23:00:28 GMT
On Wed, 16 Dec 1998 20:17:00 +0100, Olgierd Cybulski wrote:
J.F. wrote:
zrywa jak zrywa. jak wczesniej ustawisz mode com1:.....,p to nie zerwie,
tylko wstrzyma, a dokladniej - potrzebny jest stan aktywny na tej linii,
zeby BIOS zechcial wyslac cokolwiek. Podobnie na lini DSR .
Właśnie. Można zmienić stan linii CTS nawet podczas przesyłania znaku.
Wówczas zostanie on wysłany do końca, dopiero przed wysłaniem
następnego transmisja zostanie wstrzymana na czas zależny od ustawień
portu (a raczej transmisji).
Biorac pod uwage bufory to nalezy sie liczyc z wieksza iloscia znakow.
Tyle ze copy potrafi pogubic pewne znaki. W transmisji .HEX to nie przeszkadza.
ale binarki nie przeslesz...
Niestety, nie pomaga tu nawet switch "/b" .
Kretyństwo, no nie ?
Caly ten IBM PC jak mu sie przyjrzec to jedno wielkie kretynstwo.
No ... mam mieszane zdanie co do klawiatury..
J.
From: Olgierd Cybulski <cybulski_at_nospam_pkpf.if.uj.edu.pl>
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Thu, 17 Dec 1998 15:47:11 +0100
J.F. wrote:
Właśnie. Można zmienić stan linii CTS nawet podczas przesyłania znaku.
Wówczas zostanie on wysłany do końca, dopiero przed wysłaniem
następnego transmisja zostanie wstrzymana na czas zależny od ustawień
portu (a raczej transmisji).
Biorac pod uwage bufory to nalezy sie liczyc z wieksza iloscia znakow.
Znowu jakieś bufory...
W oryginalnym, przedpotopowym uarcie nie ma żadnych buforów.
Tzn. jest bufor, ale jednoznakowy :-) .
Jeśli znasz jakieś oprogramowanie, które korzysta ze sprzętowych
buforów nowoczesnych UARTów, to napisz jakie, tylko
najpierw się upewnij, że są to bufory sprzętowe, a nie sostware'owe
bufory okrężne.
Bo według moich informacji znakomita większość oprogramowania
pisana jest tak, jakby na świecie nie było RSów innych niż
te, co w pierwszych PC-tach.
Jeśli są jakieś unowocześnienia w programach, to
jedynie dotyczące szybkości transmisji 19 kbd i większych,
to chyba jedyna wykorzystywana własność nowych UARTów.
O.C.
-------------------------------------------------
wśród blasku laserów i szumu wentylatorów
-------------------------------------------------
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: Ponownie: Komunikacja PC->Atmel
Date: Thu, 17 Dec 1998 21:44:57 GMT
On Thu, 17 Dec 1998 15:47:11 +0100, Olgierd Cybulski wrote:
J.F. wrote:
Biorac pod uwage bufory to nalezy sie liczyc z wieksza iloscia znakow.
Znowu jakieś bufory...
W oryginalnym, przedpotopowym uarcie nie ma żadnych buforów.
Tzn. jest bufor, ale jednoznakowy :-) .
Co nazywasz oryginalnym przedpotopowym UART'em ?
8251 [nie 8051, tylko 8251] ?
Mial juz dodatkowy rejestr nadajnika.
Jesli po stronie odbiorczej zadecydowales ze chwilowo wiecej danych
nie chcesz, to licz sie z tym ze wlasnie sie transmituje nastepny
znak, a przed momentem nadajnik wlasnie wywolal przerwanie i kolejny
bajt czeka na wysylke. Razem - dwa bajty dotra w najblizszym czasie.
Jesli jeszcze np spozniles sie z przyjeciem przerwania troche - to
kolejny bajt czeka w buforze odbiornika :-)
Jeśli znasz jakieś oprogramowanie, które korzysta ze sprzętowych
buforów nowoczesnych UARTów, to napisz jakie, tylko
najpierw się upewnij, że są to bufory sprzętowe, a nie sostware'owe
bufory okrężne.
A kazde nowsze. Nie widziales zakladki w Control Panel do wlaczania
buforka 16550 ? Niewiele go, 16 bajtow, ale zawsze.
Bo według moich informacji znakomita większość oprogramowania
pisana jest tak, jakby na świecie nie było RSów innych niż
te, co w pierwszych PC-tach.
Jeśli są jakieś unowocześnienia w programach, to
jedynie dotyczące szybkości transmisji 19 kbd i większych,
to chyba jedyna wykorzystywana własność nowych UARTów.
juz XT umozliwial 115200, tylko wlasnie dopiero buforek w 16550
umozliwia wykorzystanie tej predkosci bardziej zaawansowanym od DOS
systemom...
J.
From: krisp_at_nospam_bbs.chip.pl (Krisp)
Subject: =?ISO-8859-1?Q?Teraz_wszystko_jasne:))__(by=B3o:Ponownie:_Komunikacja_PC-?=
Date: Fri, 18 Dec 1998 19:36:06 GMT
On 16 Dec 1998 16:37:07 GMT, jfox_at_nospam_friko6.onet.pl (J.F.) wrote:
zrywa jak zrywa. jak wczesniej ustawisz mode com1:.....,p to nie zerwie,
Aaaaaaaaaaahhhhhaaaaaaaaaaaa. Gdybym wiedzial ze mozna cos takiego
ustawic to nie byloby problemu.
Bardzo dziekuje wszystkim za odpowiedzi!=20
Teraz czas zabrac sie do roboty:))))
Pozdrawiam
Krzysztof Pawlewicz