Jak efektywnie ustawiać zegar w procesorze 89s53 przez RS z komputera?

Wed Dec 15, 2004 2:23 pm   

Czy może mi ktoś pomóc w kwestii komunikacji mojego urządzenia z
procesorem 89s53 z komputerem? Komunikacja w ogóle działa czyli z
terminala coś wysyłam procek odbiera i wykonuje polecnie albo odpowiada.
Zrobiłem to na przerwaniach i działa całkiem nieźle. Zupełnie nie koliduje
z programem głównym. Ale mam problem z interpretacją danych. Np. moje
urządzenie ma zegar i chciałbym go ustawiać z komputera. Jak to zrobić?
Jak wysłać coś co będzie jednoznaczne i da się prosto rozebrać na
polecenie i dane a dodatkowo będzie pewne, że nie ma przekłamania. Wiem,
że trzeba przyjąć jakąś ramkę transmsji. Ale nie mam pomysłu jak. Chciałem
zrobić cos na wzór ModBusa ale moim zdaniem procedura analizy będzie
skomplikowana. Ma ktos jakiś sprawdzony sposób?

Pozdrawiam
PC

p.s.
Program na peceta sam sobie napiszę.

Wed Dec 15, 2004 2:39 pm   

Pablo C napisał(a):

Jeżeli nie ma być na 99% przekłamań to będzie ciężko, wtedy trzeba się
bawić w CRC itp. Jeżeli poprawność transmisji nie jest aż tak ważna to
proponuje tak:

1) wysłać jakąś unikalną liczbę (sekwencję liczb), będzie to znak dla
mikrokontrolera że zacząła się "ramka"
2) teraz wysyłasz informację o tym co np. będziesz ustawiał
3) wysyłasz kolejne liczby coś ustawiające, ich znaczenie będzie
wynikało z punktu 2.





--
Pozdrawiam
Maksymilian Dutka

-------
GG: 1493163

Wed Dec 15, 2004 3:01 pm   

Musi być kontrola poprawoności. Myślałem aby sumować modulo poszczególne
znaki wysyłanego ciągu.
Teraz pytanie skąd procesor ma wiedzieć jaką wartość wysyłam. Wartość może
być 1 a może być 123456. Czyli ramka mialaby zmienną długość. Z kolei jak
będzie miała stałą długość to trzebaby jakoś analizować jej treść i usuwać
np zera. Wolałbym aby pecet robił większość a procesor tylko to co
konieczne.

PC

Wed Dec 15, 2004 3:29 pm   

Pablo C wrote:


a nie możesz dać stałej ramki? Wysyłasz np. zawsze 8 bajtów na zapas. Inna
możliwość to wysłanie nagłówka z kodem informacji i CRC, i miproc "wie" ile
bajtów musi jeszcze odebrać.

Waldek

Wed Dec 15, 2004 3:45 pm   

Właśnie trochę przeraża mnie długośc ramki bo ja operuję głównie na
liczbach 4-bajtowych. Może by to przesyłać w hex-ach? Bajt to zawsze 2
znaki najwyżej najstarsze będą zerowe.
Czyli przyjąć ramkę np:
HH HH HH HH CC

: - początek transmisji
P - komenda
HH - poszczególne bajty danej
CC - suma kontrolna z HH HH HH HH

PC

Wed Dec 15, 2004 4:29 pm   

Pablo C wrote:




albo robisz tak, jak ja robię:
pierwszy znak to komenda. Aby było wiadomo, że to pierwszy znak, ma
ustawioną 1 na MSB (czyli komendy mają kody od 0x80 do 0xFF). Potem lecą
wartości i CRC kodowane tak, by się w 7 bitach mieściły. Mam to tak: 7
bajtów danych kastruję z MSB i pakuję je w ósmy bajt pozostawiając w nim
msb = 0. Potem CRC ze wszystkiego, trzeba tylko uważać, by CRC było >= 0 i
< 128.

Waldek

Wed Dec 15, 2004 4:34 pm   

mozna na tysiac sposobow ))


wiesz co to modbus
i nie potrafisz sam obczajic jakiegos wlasnego protokolu?!
(!?)

dziwne...

no nic;
mozesz zrobic np. tak:
wysylasz ramki, pierwszy bajt to dlugosc ramki,
kolejny to np. rozkaz, a nastepne to np. dane ,
mozesz na koncu dac jakis crc;

mozesz tez np. wysylac ramki jako stringi (nie mylic z gaciami) ascii;
i np bajt o wartosci 0 - to koniec ramki,
a jakis nie-znak (np. CR) mozesz dac jako start bajt;
/np. cos ala komendy AT.......

hm...
mozesz tez np. start i koniec oznaczac jakas sekwencja bajtow,
np. start to 00 01 a koniec to 00 02,
ale wtedy musisz dbac o poprawnosc rozpoznawania danych;
/np. jesli przed traktowac 00 00 jako jeden bajt 00;
...........

mozesz tez np. znalezc koniec i poczatek ramki
z zaleznosci czasowych, jakie sobie zalozysz.......

Boze......
od cholery tego!
/ale zadales pytanie......

Wed Dec 15, 2004 6:25 pm   

Pablo C wrote:

1 Wysyłasz łańcuchy ASCII między znakiem początku i końca (ew jeszcze
czeksuma chćby suma modulo256) i znak końca linii CR . Np
[01E1=4095]E7CR gdzie kolejno początek ramki, adres urządzenia, parametr
i wpisywana wartość, koniec ramki, suma w postaci dwóch znaków ASCII dla
dwóch półbajtów, znak CR czyli 0DH. Dodatkowo po prawidłowym odebraniu
paczki procek może odsyłać tę wartość jako potwierdzenie. Trochę obróbki
potrzebne do zmiany z dec na bin ale przydatne jak chcesz urządzenie
sterować z terminala i widzieć jakie nastawy są w twoim urządzeniu.

2 Wysyłasz tekstowo ramkę z początkiem i ew końcem a w środku bajty -
każdy jako dwa znaki ASCII np [01E7DB3C]. Przy odbiorze odrzucasz znaki
sterujące, od znaków ASCII odejmujesz 30H i masz półbajty binarnie.
Prościej się nie da - można ew pokomplikować dodając czeksumę.

3 Binarny - najmniej znaków ale najwięcej problemów. Najlepiej zrób
sobie Modbusa RTU bo bez sensu narobić się nad protokołem którego nikt
nie stosuje a tak masz już potem gotowca :)

--
Pozdrawiam
MD

Wed Dec 15, 2004 6:40 pm   

Dzięki za wszystkie rady i sugestie. Głównie miałem problem z różną
długoscią (w znakach) danych liczbowych. Teraz zamieniam wszystko na HEX-a
i jest ok. Zaczynam transmisję od ":" i kontroluję sumę poszczególnych
znaków odrzucając przeniesienia. Tyle mi wystarczy do kontroli transmisji.
Tak myślę. Teraz czas na testy :)

Pozdrawiam
PC