CRC dla DS1990



Masz problem? Zapytaj na forum elektroda.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "Mister" <wojp_at_nospam_polbox.com>
Subject: CRC dla DS1990
Date: Thu, 2 Nov 2000 08:38:20 +0100


Witam,

Czy ktos probowal napisac w C procedurke liczenia CRC dla pastylek Dallas
DS1990?

Prosilbym o pomoc gdyz wlasnie probuje z miernym skutkiem.

Mister



Poprzedni Następny
Wiadomość
Spis treści
From: Andrzej =?iso-8859-2?Q?Zy=B6k?= <azysk_at_nospam_st.com.pl>
Subject: Re: CRC dla DS1990
Date: Thu, 02 Nov 2000 11:25:12 +0100


Mister wrote:
=

Witam,
=

Czy ktos probowal napisac w C procedurke liczenia CRC dla pastylek Dall=
as
DS1990?
=

Prosilbym o pomoc gdyz wlasnie probuje z miernym skutkiem.
Procedura CRC w C znajduje si=EA w notach aplikacyjnych AVR - AVR350, opi=
s
algorytmu - AVR236 =

http://www.atmel.com
-- =

Andrzej Zy=B6k
Security Technologies Sp. z o.o.
ul. Joteyki 20 =

02-317 Warszawa

Poprzedni Następny
Wiadomość
Spis treści
From: "peters" <peters_at_nospam_poczta.onet.pl>
Subject: Re: CRC dla DS1990
Date: Thu, 2 Nov 2000 10:42:39 +0100


Czy ktos probowal napisac w C procedurke liczenia CRC dla pastylek Dallas
DS1990?
Niestety nie probowalem, lecz po prostu napisalem :)
Jak bardzo chcesz to poszukam i Ci przesle :)
To bylo pisane na 8-nozkowego PICa.

--
pozdrawiam, peters
peters_at_nospam_poczta.onet.pl
http://peters.republika.pl (strona Petersa dla elektroników)



Poprzedni Następny
Wiadomość
Spis treści
From: verox_nospam_at_nospam_matrix.torch.net.pl (Verox)
Subject: Re: CRC dla DS1990
Date: 2 Nov 2000 10:40:46 GMT


On Thu, 2 Nov 2000 08:38:20 +0100, Mister napisał:
Witam,

Czy ktos probowal napisac w C procedurke liczenia CRC dla pastylek Dallas
DS1990?


Prosze bardzo:


unsigned char compute_crc(data,n)
unsigned char* data;
int n; /* No. of bits */
{
unsigned char data_copy=0;
unsigned char ret = 0;
int i,j=0, byte_no=0;
int input;
data_copy = *data;

for (i = 0; i< n; i++) {

input = ( ret & 0x1) ^ (data_copy & 0x1);
ret >>=1;

ret ^= (input << 2) | (input << 3) | input<<7;

data_copy >>=1;
if ( (++j / 8) && (i < (n -1))) {
if (data_copy)
printk("Something wrong with your architecture!!!\n");
data_copy = *(data+ ++byte_no);
j = 0;
}
}
return ret;
}


--
Tomasz Brol, Network Administrator PiK-NET Sieci Rozlegle
Toszecka 102, Gliwice Poland, voice +48 32 232-70-70, fax: +48 32 232-70-00
e-mail: verox<at>pik-net.pl

Poprzedni Następny
Wiadomość
Spis treści
From: "peters" <peters_at_nospam_poczta.onet.pl>
Subject: Re: CRC dla DS1990
Date: Thu, 2 Nov 2000 12:17:50 +0100


unsigned char compute_crc(data,n)
unsigned char* data;
int n; /* No. of bits */
{
unsigned char data_copy=0;
unsigned char ret = 0;
int i,j=0, byte_no=0;
int input;
data_copy = *data;

for (i = 0; i< n; i++) {

input = ( ret & 0x1) ^ (data_copy & 0x1);
ret >>=1;

ret ^= (input << 2) | (input << 3) | input<<7;

data_copy >>=1;
if ( (++j / 8) && (i < (n -1))) {
if (data_copy)
printk("Something wrong with your architecture!!!\n");
data_copy = *(data+ ++byte_no);
j = 0;
}
}
return ret;
}

Nie chcialbym krytykowac, ale crc przy szeregowym odczycie dobrze jest
obliczac w tej samej petli co odczyt poszczegolnych bitow! To co napisales
jest okropnie nieefektywne. W malym procku nie do zaimplementowania.

--
pozdrawiam, peters
peters_at_nospam_poczta.onet.pl
http://peters.republika.pl (strona Petersa dla elektroników)



Poprzedni Następny
Wiadomość
Spis treści
From: verox_nospam_at_nospam_matrix.torch.net.pl (Verox)
Subject: Re: CRC dla DS1990
Date: 2 Nov 2000 16:03:43 GMT


On Thu, 2 Nov 2000 12:17:50 +0100, peters napisał:
unsigned char compute_crc(data,n)
unsigned char* data;
int n; /* No. of bits */
{
unsigned char data_copy=0;
unsigned char ret = 0;
int i,j=0, byte_no=0;
int input;
data_copy = *data;

for (i = 0; i< n; i++) {

input = ( ret & 0x1) ^ (data_copy & 0x1);
ret >>=1;

ret ^= (input << 2) | (input << 3) | input<<7;

data_copy >>=1;
if ( (++j / 8) && (i < (n -1))) {
if (data_copy)
printk("Something wrong with your architecture!!!\n");
data_copy = *(data+ ++byte_no);
j = 0;
}
}
return ret;
}

Nie chcialbym krytykowac, ale crc przy szeregowym odczycie dobrze jest
obliczac w tej samej petli co odczyt poszczegolnych bitow! To co napisales
jest okropnie nieefektywne. W malym procku nie do zaimplementowania.

Masz racje, ale dziala. Zostalo to napisane dla mojego termometru.

Źródełka tutaj: http://www.matrix.torch.net.pl/~verox/dziela.html

--
Tomasz Brol, Network Administrator PiK-NET Sieci Rozlegle
Toszecka 102, Gliwice Poland, voice +48 32 232-70-70, fax: +48 32 232-70-00
e-mail: verox<at>pik-net.pl

Poprzedni Następny
Wiadomość
Spis treści
From: this_address_is_invalid_see_signature_at_nospam_adresniewazny.com (Jaroslaw Cichorski Jr.)
Subject: Re: CRC dla DS1990
Date: Thu, 02 Nov 2000 17:38:51 GMT


"Mister" <wojp_at_nospam_polbox.com> wrote:

Witam,

Czy ktos probowal napisac w C procedurke liczenia CRC dla pastylek Dallas
DS1990?


Napisalem ale jako modul ASM linkowany z C Keila'51
Pisanie tego w C na jedoukladowca nie ma ZADNEGO sensu - za duzo trwa
i za duzo zajmuje miejsca.
Moge podeslac, jesli potrzebujesz.
Pozdr

-----
Jaroslaw Cichorski Jr <cichy_at_nospam_amart.JUNK_MAIL_PROTECTION.com.pl>
UWAGA Adres email niewazny!Zeby otrzymac prawidlowy usun JUNK MAIL PROTECTION.
WWW http://www.amart.com.pl
This message will be selfdestructed in 5 seconds!!!

Poprzedni Następny
Wiadomość
Spis treści
From: "peters" <peters_at_nospam_poczta.onet.pl>
Subject: Re: C czy ASM (bylo CRC dla DS1990)
Date: Fri, 3 Nov 2000 09:36:30 +0100


Napisalem ale jako modul ASM linkowany z C Keila'51
Pisanie tego w C na jedoukladowca nie ma ZADNEGO sensu - za duzo trwa
i za duzo zajmuje miejsca.
Moge podeslac, jesli potrzebujesz.
Pozdr

No wlasnie, ciekawy temat poruszyles.
Jakies 6-7 lat temu tez uwazalem, ze pisanie w C nie ma sensu. Kod jest
dluzszy i wykonuje sie wolniej .. i calkowicie zmienilem zdanie. Teraz
programuje w C i calkiem spore 16-bitowe mikrokontrolery i te najmniejsze.
Dam przyklad.
Obsluge pastylek Dallasa, EEPROMU po I2C i wiele innych funkcji (taki
immobiliser) zrobilem na PIC12C508, ktory ma 512B EPROM i 25B RAM. I
wszystko napisane w C :))
Prawda jest taka, ze programowanie w C znacznie ulatwia sam proces tworzenia
oprogramowania, ulatwia pozniejsze modyfikacje.

Wspolczesny elektronik pisze na zmiane oprogramowanie na kilkanascie tupow
mikrokontrolerow. Gdyby mial sie uczyc na nie wszystkie asemblerow to by
szybko zglupial ! Dzieki C w jeden dzien moze zaczac programowac nowy typ
procesora. Niedowiarkom polecam CodeVision na AVRki.
(link na mojej stronie) Ten kompilator C ma wizardy. Tworzymy nowy projekt i
wybieramy np:
RS232 na przerwaniach, fifo 8B; RTC po I2C ..... funkcje poszczegolnych
pinow i po chwili mamy gotowy szkielet programu. Serce sie raduje :))

I jeszcze jedna wazna sprawa. Troche inaczej pisze sie programy w C na male
procesorki niz na te calkiem dorosle. Tego sie trzeba nauczyc. Dobrym
przykladem jak nie nalezy pisac na maluchy jest programik podeslany przez
kolege Veroxa.
Wydaje mi sie, ze warto jednak przejsc przez etap programowania w
asemblerze, by potem piszac w C zdawac sobie sprawe jak to zostanie
przetlumaczone i ile zajmie pamieci.

Nawet jesli program w C wykonuje sie troche wolniej i jest troche dluzszy to
w 99% przypadkow wart dac troszke silniejszy procesorek i po klopocie.
Szanujmy swoje zdrowie i swoj cenny czas (ktory mazna potem wykorzystac na
pisanie przydlugich listow)
--
pozdrawiam, peters
peters_at_nospam_poczta.onet.pl
http://peters.republika.pl (strona Petersa dla elektroników)





Poprzedni Następny
Wiadomość
Spis treści
From: this_address_is_invalid_see_signature_at_nospam_adresniewazny.com (Jaroslaw Cichorski Jr.)
Subject: Re: C czy ASM (bylo CRC dla DS1990)
Date: Fri, 03 Nov 2000 11:53:26 GMT


"peters" <peters_at_nospam_poczta.onet.pl> wrote:

Obsluge pastylek Dallasa, EEPROMU po I2C i wiele innych funkcji (taki
immobiliser) zrobilem na PIC12C508, ktory ma 512B EPROM i 25B RAM. I
wszystko napisane w C :))

Jaki kompilator ? HiTecha?
Ja tez zrobilem na 16C54 immobiliser, ale w ASM ;-)

Prawda jest taka, ze programowanie w C znacznie ulatwia sam proces tworzenia
oprogramowania, ulatwia pozniejsze modyfikacje.

To jest SWIETA prawda.
Jezeli chcesz tworzyc SZYBKO i w miare BEZBLEDNIE to tylko C,ale....
ASM jest konieczny, wstawki ASM trzeba umiec robic,bo w C nie wszystko
da sie EFEKTYWNIE zrobic (zrobic da sie zawsze) ;-)

I jeszcze jedna wazna sprawa. Troche inaczej pisze sie programy w C na male
procesorki niz na te calkiem dorosle. Tego sie trzeba nauczyc. Dobrym
przykladem jak nie nalezy pisac na maluchy jest programik podeslany przez
kolege Veroxa.

Tak jest,zeby dobrze napisac program w C ttzeba znac ASM i
ARCHITEKTURE procesora, na ktory sie pisze, inaczej powstaje
nieefektywny kod. Warto podgladac wynik kompilacji. NIektore C na male
jednoukladowce maja rozszerzenia i opcje umozliwiajace pelne
wykorzystanie mozliwosci procesora.

Wydaje mi sie, ze warto jednak przejsc przez etap programowania w
asemblerze, by potem piszac w C zdawac sobie sprawe jak to zostanie
przetlumaczone i ile zajmie pamieci.

Trzeba, inaczej niggdy nie bedziesz dobrym programista
jednoukladowcow.

Nawet jesli program w C wykonuje sie troche wolniej i jest troche dluzszy to
w 99% przypadkow wart dac troszke silniejszy procesorek i po klopocie.

Z doswiadczenia widze, ze jezeli krotki i krytyczne czasowo procedury
tworzy sie w ASM,a szkielet w C,to na prawde trudno o wieksza
efektywnosc.Przy czym na efektywnosc sklada sie wiele czynnikow: Czas
pisania oprogramowania, czas testowania i uruchamiania,latwosc
dokonywania poprawek,szybkosc wykonywania sie kodu,i pewnie wiele
innych drobiazgow.

Szanujmy swoje zdrowie i swoj cenny czas (ktory mazna potem wykorzystac na
pisanie przydlugich listow)

;-)
Pozdrawiam

-----
Jaroslaw Cichorski Jr <cichy_at_nospam_amart.JUNK_MAIL_PROTECTION.com.pl>
UWAGA Adres email niewazny!Zeby otrzymac prawidlowy usun JUNK MAIL PROTECTION.
WWW http://www.amart.com.pl
This message will be selfdestructed in 5 seconds!!!

Poprzedni Następny
Wiadomość
Spis treści
From: "peters" <peters_at_nospam_poczta.onet.pl>
Subject: Re: C czy ASM (bylo CRC dla DS1990)
Date: Fri, 3 Nov 2000 13:05:02 +0100


Jaki kompilator ? HiTecha?
Ja tez zrobilem na 16C54 immobiliser, ale w ASM ;-)
Tak. Byla wersja 30-dniowa. Ale teraz wole AVR-y :

To jest SWIETA prawda.
Jezeli chcesz tworzyc SZYBKO i w miare BEZBLEDNIE to tylko C,ale....
ASM jest konieczny, wstawki ASM trzeba umiec robic,bo w C nie wszystko
da sie EFEKTYWNIE zrobic (zrobic da sie zawsze) ;-)
Wstawki zgoda. Ale tylko tam gdzie to istotnie wplynie na szybkosc.
Np. liczenie CRC, ale nie dla kilku bajtow ale dla kilkudziesieciu KB.
Wstawienie paru linijek potrafi skrocic czas 4-krotnie.

Tak jest,zeby dobrze napisac program w C ttzeba znac ASM i
ARCHITEKTURE procesora, na ktory sie pisze, inaczej powstaje
nieefektywny kod. Warto podgladac wynik kompilacji.

Albo przynajmniej patrzec ile wygenerowalo kodu :)) Czasem rezygnacja z
jakiegos parametru i zastapienie tego zmienna globalana przynosi spore
oszczednosci.

I jeszcze jedna wazna sprawa. Piszac w C mamy szanse wykorzystac fragmenty
kodu do innych celow. Czasem po kilku latach okazuje sie, ze cos podobnego
juz sie kiedys pisalo. Ale na inny procesor, troche do czego innego.

--
pozdrawiam, peters
peters_at_nospam_poczta.onet.pl
http://peters.republika.pl (strona Petersa dla elektroników)



Poprzedni Następny
Wiadomość
Spis treści
From: jfox_at_nospam_friko6.onet.pl (J.F.)
Subject: Re: C czy ASM (bylo CRC dla DS1990)
Date: 3 Nov 2000 13:39:02 GMT


On Fri, 3 Nov 2000 09:36:30 +0100, peters <peters_at_nospam_poczta.onet.pl> wrote:
Jakies 6-7 lat temu tez uwazalem, ze pisanie w C nie ma sensu. Kod jest
dluzszy i wykonuje sie wolniej .. i calkowicie zmienilem zdanie. Teraz
programuje w C i calkiem spore 16-bitowe mikrokontrolery i te najmniejsze.

Prawda jest taka, ze programowanie w C znacznie ulatwia sam proces tworzenia
oprogramowania, ulatwia pozniejsze modyfikacje.

IMHO - wcale nie tak bardzo, tylko trzeba "porzadnie" w assemblerku pisac.
Za to jest jeden bol - przenosnosc na inny procesor ..

Wspolczesny elektronik pisze na zmiane oprogramowanie na kilkanascie tupow
mikrokontrolerow. Gdyby mial sie uczyc na nie wszystkie asemblerow to by
szybko zglupial !

Bez przesady, wszystkie sa takie same.
A wiesz jak sie glupieje piszac na zmiane w C, Pascalu, Javie, VBasicu
itp :-)

Dzieki C w jeden dzien moze zaczac programowac nowy typ
procesora. Niedowiarkom polecam CodeVision na AVRki.

tylko najpierw trzeba trzy dni przegryzc sie przez literature czego mozna
sie po hardware spodziewac ...

RS232 na przerwaniach, fifo 8B; RTC po I2C ..... funkcje poszczegolnych
pinow i po chwili mamy gotowy szkielet programu. Serce sie raduje :))

A potem sie okazuje ze nam trzeba nie RS z fifo, tylko w procedurze przerwania
zbierac pakiety, sprawdzac sumy kontrolne i kolejkowac potwierdzenia..

I jeszcze jedna wazna sprawa. Troche inaczej pisze sie programy w C na male
procesorki niz na te calkiem dorosle. Tego sie trzeba nauczyc.

Otoz to.

Nawet jesli program w C wykonuje sie troche wolniej i jest troche dluzszy to
w 99% przypadkow wart dac troszke silniejszy procesorek i po klopocie.

To nie pecety ze jak P300 sie nie wyrabia to mozna P500 kupic ..

J.

Poprzedni Następny
Wiadomość
Spis treści
From: "peters" <peters_at_nospam_poczta.onet.pl>
Subject: Re: C czy ASM (bylo CRC dla DS1990)
Date: Fri, 3 Nov 2000 16:01:43 +0100


IMHO - wcale nie tak bardzo, tylko trzeba "porzadnie" w assemblerku pisac.
Za to jest jeden bol - przenosnosc na inny procesor ..

Wlasnie o tym mowie !!

Wspolczesny elektronik pisze na zmiane oprogramowanie na kilkanascie
tupow
mikrokontrolerow. Gdyby mial sie uczyc na nie wszystkie asemblerow to by
szybko zglupial !
Bez przesady, wszystkie sa takie same.

Racja, takie male czarne :) To porownaj asemblera na 80C166 Siemensa z
asemblerem na PICa
Nauczenie sie dobrze tego pierwszego zajmie Ci sporo czasu, powiedzmy 2-3
miesiace.
Pisanie w C zwalnie z koniecznosci uczenia sie roznych glupot. Np baki
pamieci programu dla starych PICow albo problemy z dlugimi skokami na 51.
Kompilator to robi za Ciebie.

A wiesz jak sie glupieje piszac na zmiane w C, Pascalu, Javie, VBasicu
itp :-)
No pewnie, prawdziwi twardziele pisza w asemblerze nawet pod Windowsy a
druki projektuja na kalce technicznej.

Dzieki C w jeden dzien moze zaczac programowac nowy typ
procesora. Niedowiarkom polecam CodeVision na AVRki.

tylko najpierw trzeba trzy dni przegryzc sie przez literature czego mozna
sie po hardware spodziewac ...
Mam prosbe, najpierw to wyprobuj a dopiero potem krytykuj. Podlaczenie
wyswietlacza LCD, uruchomienie przetwornika AC i wyswietlenie wyniku zajmie
2 minuty i 3 linijki tekstu. Ile Ci to zajmie w asemblerze bez znajomosci
procesora??
Nie 3 dni, patrzysz sobie na zestawienie co ma dany procesor:
-ile pinow,
-RS232
-SPI
-A/C
..itd
Wybierasz co potrzeba i masz. Jesli potrzebujesz sie odwolac bezposrednio do
sprzetu to piszac program zagladasz do pdf-a :)

RS232 na przerwaniach, fifo 8B; RTC po I2C ..... funkcje poszczegolnych
pinow i po chwili mamy gotowy szkielet programu. Serce sie raduje :))

A potem sie okazuje ze nam trzeba nie RS z fifo, tylko w procedurze
przerwania
zbierac pakiety, sprawdzac sumy kontrolne i kolejkowac potwierdzenia..
To uruchamiasz RS bez fifo. Tam sie wszystko definiuje w ladnym okienku
dialogowym!
I to naprawde dziala. W dodatku kosztuje tylko kilaset zlotych.

Nawet jesli program w C wykonuje sie troche wolniej i jest troche dluzszy
to
w 99% przypadkow wart dac troszke silniejszy procesorek i po klopocie.

To nie pecety ze jak P300 sie nie wyrabia to mozna P500 kupic ..

AVR-ki np masz dostepne w roznych szybkosciach i o roznej wielkosci pamieci.
Jak sie nie zmiesci w jednym to kupujesz minimalnie drozszy i po sprawie.

Pisze o tym dlatego bo uwazam, ze postep w dziedzinie procesorow i
oprogramowania w zasadniczy sposob wplywa na sposob pracy inzyniera. Koncza
sie czasy pisania w asemblerze.
Dzieki takim programom jak CodeVision mozna sie skupic na istocie
zagadnienia a nie sleczec tracac wzrok nad kodem programu.
Oczywiscie dobry programista powinien zaczynac nauke od asemblera albo nawet
kodu maszynowego ale nadeszly czasy, ze wiele nie zarobi jak sie na tym
etapie zatrzyma.

--
pozdrawiam, peters
peters_at_nospam_poczta.onet.pl
http://peters.republika.pl (strona Petersa dla elektroników)



Poprzedni Następny
Wiadomość
Spis treści
From: Milosz Skowyra <mewash_at_nospam_bet.po.opole.pl>
Subject: Re: C czy ASM (bylo CRC dla DS1990)
Date: Fri, 03 Nov 2000 18:08:18 +0100


peters wrote:

A wiesz jak sie glupieje piszac na zmiane w C, Pascalu, Javie, VBasicu
itp :-)
No pewnie, prawdziwi twardziele pisza w asemblerze nawet pod Windowsy a
druki projektuja na kalce technicznej.

Prawdziwi twardziele robia "dd /dev/audio /dev/hda" i wygwizduja sobie
kernela...

--
Regards.
|-----------------------------------------------------|
| Milosz Skowyra |
| miloszek_at_nospam_fidonet.org.pl 2:484/2.47 on fidonet |
| GSM Mobile +48608888899 |
|-----------------------------------------------------|

Poprzedni Następny
Wiadomość
Spis treści
From: "Scoobie" <NOSPAMscoobie_at_nospam_apator.torun,pl>
Subject: Re: C czy ASM
Date: Sat, 4 Nov 2000 12:56:34 +0100


Dobry :-)
Mogę swoje "trzy grosze"?
"W ogólności" podpisuję się pod Petersem, klepanie w asemblerze
jest dobre nie dla tych, którzy są "lepsi" w te klocki ani dla
tych, którzy są "gorsi" w te klocki, tylko dla tych, którzy...
mają czas!
Jak wiadomo, mamy do czynienia z kodem:
a) trudnym, ciekawym, spryciarskim i... zwykle krótkim (procedury
blisko sprzętu, czasem jakieś fikołki stałoprzecinkowe,
manipulacja niewielkimi strukturami danych, itepe itede)
b) łatwym, nudnym, bezmyślnym i... zwykle dłuugim i rozbudowanym
(np. skomplikowany interface użytkownika)
c) mieszanka a) i b) w dowolnych proporcjach

Kod "typu a)" można napisać w C bardzo wydajnie, jednak
najprawdopodobniej będzie trzeba zaglądać w wyniki pracy
kompilatora i nauczyć się, jaki kod generuje z jakich struktur w
programie. Chociaż... niekoniecznie - C jest całkiem
niskopoziomowy jak na język wysokiego poziomu (np. operacje
bitowe) i czasami pisząc w C widzi się "oczyma wyobraźni" jakie
instrukcje wygeneruje kompilator.
Tak czy siak, w przypadku kodu "typu a)" korzystanie z C może być
problematyczne i możemy się spierać w nieskończoność, czy warto,
czy niewarto. OCZYWIŚCIE cały czas zakładam, że interesuje nas
otrzymanie naprawdę "wyczynowego" kodu!!! W innym wypadku w ogóle
bym olał asembler - po co się szarpać???
Natomiast kod "typu b)" jest tak żmudny i upierdliwy do pisania w
asemblerze, że osobiście uważałbym to za prześladowanie, gdyby
ktoś zabronił mi pisać tego typu rzeczy w C. Np. że "jak
wciśniesz '1' a potem '023', to ma się wyświetlić lista
czegoś-tam, listę przewijamy klawiszem '>' do przodu i '<' do
tyłu a wychodzimy przez 'Esc' i tak dalej...
Po co asember tam, gdzie przez jego użycie nie damy rady nic
zyskać???
Podpisuję się również pod Petersem, jeśli chodzi o częste
przesiadanie się z kontrolera na kontroler albo pisanie
równolegle na kilka różnych - schizofrenia murowana!

Ogólnie - C RULEZZZ!, asembler... jak trzeba, to trzeba, ale
generalnie SUCKS!!
Może jestem tendencyjny, ale przyzwyczaiłem się do komfortu
(no... względnego komfortu ;-)) pisania programów na PCta i
czasem mi niedobrze na myśl o uczeniu się kolejnego asemblera
tylko po to, żeby zrobić jedno urządzenie a potem wszystko
zapomnieć.

A tak swoją drogą - zastanawiam się, kiedy kontrolery i pisacze
kompilatorów urosną na tyle, żeby można klepać programy w C++, bo
przyznam szczerze, że czasami program aż się prosi o obiektówkę
(zazwyczaj duży program).


Scoobie

P.S. Aha! Ja Ci (Peters) dziękuję za zaczynanie nauki od
maszynówki!!! ;-) Chciał nie chciał, ze mną tak właśnie było, bo
komputera nie miałem (w domu się nie przelewało), kupiłem sobie
CA80 (p. Gardynika) i... do dzisiaj pamiętam sporo kodów
maszynowych Z80! No i po co mi to??? ;-)
P.S. Najwięcej klepię na "dorosłe" PICe (17C756A jest dorosły?),
kompilując moje "mądrości" HI-TECHem i zbytnio nie narzekam.


Poprzedni Następny
Wiadomość
Spis treści
From: Marcin Wolcendorf <wolcendo_at_nospam_free.polbox.pl>
Subject: Re: C czy ASM
Date: Sat, 04 Nov 2000 13:38:27 +0100


Cześć,

Pozwolę się dołączyć.

Scoobie wrote:

Podpisuję się również pod Petersem, jeśli chodzi o częste
przesiadanie się z kontrolera na kontroler albo pisanie
równolegle na kilka różnych - schizofrenia murowana!

A co, kiedy kod ma być przeniesiony później na wielowątkowy system
operacyjny z ochroną zasobów i wywłaszczaniem (w oryginale takiego nie
ma, niestety)?



Ogólnie - C RULEZZZ!, asembler... jak trzeba, to trzeba, ale
generalnie SUCKS!!

Jest jeszcze jedno miejsce, gdzie się przydaje. Jeśli z założeń
wynika, że nie można użyć nowoczesnego i (w sumie) drogiego procesora, a
pobór mocy ma być malutki (średnio poniżej 30uA _at_nospam_ 3V) i trzeba w
rezultacie 'rzeźbić' w 4.bitowcach... Czy muszę dodawać więcej? (to też
w sumie śmieszne- lista rozkazów takich pchełek wydaje się być o niebo
wygodniejsza od 'ośmiobotowego' ST62)


Może jestem tendencyjny, ale przyzwyczaiłem się do komfortu
(no... względnego komfortu ;-)) pisania programów na PCta i
czasem mi niedobrze na myśl o uczeniu się kolejnego asemblera
tylko po to, żeby zrobić jedno urządzenie a potem wszystko
zapomnieć.

Ech... Ale czasami, niestety, to, co wyczynia kompilator, podnosi
włosy na głowie. Jak zaczynałeś od Z80 to pewnie pamiętasz jeszcze, jak
działa rozkaz LDI. Widziałem implementację strcpy w jakimś kompilatorze
(mam wrażenie, że to było IAR) na Z80. IX, IY, BC, stos, A i zdaje się
jeszcze kilka rejestrów było potrzebnych...


A tak swoją drogą - zastanawiam się, kiedy kontrolery i pisacze
kompilatorów urosną na tyle, żeby można klepać programy w C++, bo
przyznam szczerze, że czasami program aż się prosi o obiektówkę
(zazwyczaj duży program).

Już urosły. Popatrz na Hitachi (H8/300 H8S, SH, btw- na SH-4
zbudowano jakąś _nową_ konsolę do gier) i GCC, które na 'dzień dobry'
jest kompilatorem C++ i obejmuje również te procki. Sam jestem ciekawy,
kiedy SDCC (kompilator z wyboru- darmowy- na '51 i Z80) rozrośnie się na
tyle, by objęło też C++.



Pozdrawiam,

Marcin.

--
'My experience is that it is hard to find software producers that aren't
fuzzy.'




Poprzedni Następny
Wiadomość
Spis treści
From: "Scoobie" <NOSPAMscoobie_at_nospam_apator.torun,pl>
Subject: Re: C czy ASM
Date: Sat, 4 Nov 2000 14:25:44 +0100


Witam :-)
A co, kiedy kod ma być przeniesiony później na wielowątkowy
system
operacyjny z ochroną zasobów i wywłaszczaniem (w oryginale
takiego nie
ma, niestety)?
Strach i nędza III Rzeszy. Osobiście polecałbym 386EX (386 tyle,
że obudowany jak kontroler) + QNX (taki real-time OS do systemów
wbudowanych, podobny do Unixa, bardzo fajny, tylko... kilkaset
baniek trzeba wydać).
Naprawdę każą Ci pisać OSy na kontolerach? 8-|
Czy wolno im Cię do tego zmuszać? Czy to jest zgodne z konwencją
genewską... a karta praw człowieka!? ;-)

Ech... Ale czasami, niestety, to, co wyczynia kompilator,
podnosi
włosy na głowie.
Z przykrością muszę Ci przynać rację :-(
No cóż... pisanie kompilatorów to nie takie hop-siup. Zresztą, o
czym my mówimy - jeśli np. taki IAR "strzela" kompilatorami, jak
z kałacha, to cóś mi się wydaje, że mają "szablonik" kompilatora
i uzdatniają go tylko do użycia z konkretnym typem kontrolera.
Podejście słabe (delikatnie mówiąc), ale co zrobić - goście z
IARa też mają żony i dzieci i muszą wlewać paliwo do swoich
samochodów itd. ;-)
Jeśli chodzi akurat o PICe, to wydaje się, że HI-TECH jest
jednym z najlepszych, natomiast generalna zasada jest taka, żeby
(zwłaszcza na początku) zaglądać w absolute listingi i patrzeć,
jak zostało rozwinięte jakieś "switch(cos_tam)" itd.
Niemniej - jeśli jest zapas szybkości kontrolera i zapas pamięci
programu, to hulaj dusza, piekła nie ma!
i jazda - void main(){...
...i program powstaje w takim tempie, że w asemblerze nie dałbyś
rady.

kompilatorów urosną na tyle, żeby można klepać programy w
C++, bo
Już urosły. Popatrz na Hitachi (H8/300 H8S, SH, btw- na
SH-4
O! Jak zwylke jestem zacofany. Ale C++ z obiektówką? Czy tylko
jakieś przeciążanie funkcji, operatorów i tego typu wynalazki?

Pozdrawiam,
Scoobie


Poprzedni Następny
Wiadomość
Spis treści
From: Marcin Wolcendorf <wolcendo_at_nospam_free.polbox.pl>
Subject: Re: C czy ASM
Date: Sat, 04 Nov 2000 16:18:43 +0100


Cześć,

Scoobie wrote:

Witam :-)
A co, kiedy kod ma być przeniesiony później na wielowątkowy
system
operacyjny z ochroną zasobów i wywłaszczaniem (w oryginale
takiego nie
ma, niestety)?
Strach i nędza III Rzeszy. Osobiście polecałbym 386EX (386 tyle,
że obudowany jak kontroler) + QNX (taki real-time OS do systemów
wbudowanych, podobny do Unixa, bardzo fajny, tylko... kilkaset
baniek trzeba wydać).

No właśnie... Inną opcją jest GCC + Linux (jakaś wersja 'embedded'
pewnie by się znalazła) albo i uC-OSII (taniutki). Ale to będzie
działało na PC-cie (btw. pod Linuxem :-) ), a moja praca będzie jedynie
częścią całości.


Naprawdę każą Ci pisać OSy na kontolerach? 8-|
Czy wolno im Cię do tego zmuszać? Czy to jest zgodne z konwencją
genewską... a karta praw człowieka!? ;-)

Nie, nie, jeszcze tak źle to nie jest. Chodzi po prostu o to, że
przy przenoszeniu na system z wywłaszczaniem (dostanę, nie będę musiał
się z tym bawić :-) ) będę musiał całość napisać na nowo, bo obsługę
dwóch urządzeń, którą przy braku systemu robię tak, że zapamiętuję sobie
stan jednego, idę do drugiego i tak w kółko (tania symulacja
wielowątkowości), a przy systemie włoży się obsługę każdego urządzenia
do rozdzielnych wątków, a stan będzie trzymał system- usypiając mi wątek
przy czytaniu z niegotowego urządzenia.


Ech... Ale czasami, niestety, to, co wyczynia kompilator,
podnosi
włosy na głowie.
Z przykrością muszę Ci przynać rację :-(

To po prostu trzeba wiedzieć, żeby się nie zdziwić. A i tak jestem
za pisaniem w C. Na asembler szkoda czasu.


No cóż... pisanie kompilatorów to nie takie hop-siup.

Ależ nikt nie każe Ci go pisać. Bierzesz gramatykę (którą trzeba
stworzyć, niestety- ale do tego chyba też są gotowe narzędzia),
zapuszczasz yacc i masz kompilator. Wszystko. Później ew. pogrzebanie w
tym, co wyjdzie zostaje :-). Ale przyznaję- nigdy tego nie robiłem.


Zresztą, o
czym my mówimy - jeśli np. taki IAR "strzela" kompilatorami, jak
z kałacha, to cóś mi się wydaje, że mają "szablonik" kompilatora
i uzdatniają go tylko do użycia z konkretnym typem kontrolera.

Patrz wyżej :-).


Podejście słabe (delikatnie mówiąc), ale co zrobić - goście z
IARa też mają żony i dzieci i muszą wlewać paliwo do swoich
samochodów itd. ;-)

Nie zgadzam się. Po prostu nie ma czasu na 'dopieszczanie' idealnego
oprogramowania. Ono ma być optymalne, nie idealne. Ma wejść na rynek na
tyle szybko, by nie trzeba było 'wygryzać' zadomowionej na nim
konkurencji, z drugiej strony powinno być na tyle dopracowane, by ludzie
chcieli go używać. To wystarczy i, z reguły, przynosi max. zysk. A o to
przecież chodzi, prawda?


Jeśli chodzi akurat o PICe, to wydaje się, że HI-TECH jest
jednym z najlepszych, natomiast generalna zasada jest taka, żeby
(zwłaszcza na początku) zaglądać w absolute listingi i patrzeć,
jak zostało rozwinięte jakieś "switch(cos_tam)" itd.

I szukać głupich błędów :-). Jak ja ostatnio :-). 'Zapomniałem' o
jednym, małym '&'... Zdaje się, że kompilator wypluł jakiś tam warning,
ale że wypluł ich więcej, jak również dlatego, że pluł coś o
optymalizacji, to nie zwróciłem uwagi ;-).


Niemniej - jeśli jest zapas szybkości kontrolera i zapas pamięci
programu, to hulaj dusza, piekła nie ma!
i jazda - void main(){...
...i program powstaje w takim tempie, że w asemblerze nie dałbyś
rady.

No właśnie. I tu jest sedno- nawet droższy procek jest bardziej
opłacalny, niż tańszy, jeśli dzieki niemu produkt szybciej wejdzie na
rynek i pracownicy będą krócej nad nim pracowali. (analogiczne do Ziloga
z jego manią 'kodowania' asemblera w sprzęcie, zamiast zastosować
mikrokod... Słyszał kto o 32 bitowych procesorach Z? No bo jeszcze z
labolatoriów nie wyszedł...)


kompilatorów urosną na tyle, żeby można klepać programy w
C++, bo
Już urosły. Popatrz na Hitachi (H8/300 H8S, SH, btw- na
SH-4
O! Jak zwylke jestem zacofany. Ale C++ z obiektówką? Czy tylko
jakieś przeciążanie funkcji, operatorów i tego typu wynalazki?

Normalne GCC spod Linuxa. Dokładnie takie samo. A u mnie się plącze
w (jakiejś starej- oj, bardzo starej- 2.7...) wersji pod CYGWIN-a.
Niestety, nie miałem czasu się zapoznać ;-). Zalety główne GCC to: 1)
możliwość bezbolesnego przejścia na Linux ze wszystkim (Eagle- do
projektowania płytek, StarOffice- edytor tekstów i nie tylko, gcc do
pisania programów, Netscape do HTML-i- i kilka GB wingrozy moża wyciąć z
dysku :-) ), 2) jeden 'interface' do wszystkich procesorów- począwszy od
'51 na PPC i Pentium skończywszy. Wreszcie nie trzeba się uczyć używania
kolejnego kawałka oprogramowania :-) 3) jest tanie, a dobre :-).
Zresztą- są porty na HC11/HC12 i AVR-a (nawet w jakimś wątku było o
tym). A to nie jakieś 'odrzutowce'. HC11 to prawie odpowiednik '51.


Pozdrawiam nieco 'chwalipięcko',

Marcin :-).

--
'My experience is that it is hard to find software producers that aren't
fuzzy.'




Poprzedni Następny
Wiadomość
Spis treści
From: "peters" <peters_at_nospam_poczta.onet.pl>
Subject: Re: C czy ASM
Date: Sat, 4 Nov 2000 19:52:37 +0100


A co, kiedy kod ma być przeniesiony później na wielowątkowy system
operacyjny z ochroną zasobów i wywłaszczaniem (w oryginale takiego nie
ma, niestety)?
Keil dysponuje namiastka takiego system (RTX51 Tiny i RTX166 Tiny) i powiem
Wam, ze bardzo sympatycznie to dziala. Przy bardziej skomplikowanych
zadaniach bardzo trudno sie bez tego obyc. Ale nawet na systemie z '51 i
zewnetrznym ramem ma to sens, nawet gdy do obslugi mamy tylko kalwiature i
wyswietlacz.

--
pozdrawiam, peters
peters_at_nospam_poczta.onet.pl
http://peters.republika.pl (strona Petersa dla elektronikow)




Poprzedni Następny
Wiadomość
Spis treści
From: "peters" <peters_at_nospam_poczta.onet.pl>
Subject: Re: C czy ASM
Date: Sat, 4 Nov 2000 19:48:12 +0100


A tak swoją drogą - zastanawiam się, kiedy kontrolery i pisacze
kompilatorów urosną na tyle, żeby można klepać programy w C++, bo
przyznam szczerze, że czasami program aż się prosi o obiektówkę
(zazwyczaj duży program).

Z zazdroscia spogladam na kolege co programuje obiektowo w Delphi i nie moge
doczekac sie obiecanych obiektow w Keilu na '51 i '166. Pan z EG Electronics
juz kilka lat temu opowiadal mi na jakis targach, ze juz niedlugo juz za
chwile...
No i nic. A tymczasem procesory rodziny 51 i 166 staja sie coraz mniej
atrakcyjne.

P.S. Aha! Ja Ci (Peters) dziękuję za zaczynanie nauki od
maszynówki!!! ;-) Chciał nie chciał, ze mną tak właśnie było, bo
komputera nie miałem (w domu się nie przelewało)
Ja zaczynalem czysto teoretycznie od ksiazek Misiurewicza.(polecam je goraco
tym co chca rozpoczac nauke programowania procesorkow) Potem mialem na
jakies 3 miesiace Sharpa z Z80. Prawie nie spalem. Jeszcze pozniej juz
wlasne Atari i wreszcie pierwszy wlasny systemik na 8085. PC-tow jeszcze nie
bylo wiec kody maszynowe znalo sie na pamiec. To byly czasy :))

--
pozdrawiam, peters
peters_at_nospam_poczta.onet.pl
http://peters.republika.pl (strona Petersa dla elektronikow)



Poprzedni Następny
Wiadomość
Spis treści
From: mirek-l_at_nospam_ikp.atm.com.pl (=?iso-8859-2?Q?Miros=B3aw?= LACH)
Subject: Re: CRC dla DS1990
Date: 4 Nov 2000 16:40:17 +0100




Czy ktos probowal napisac w C procedurke liczenia CRC dla pastylek Dallas
DS1990?

Służę uprzejmie. Przed rozpoczęciem obliczania CRC dla całego kodu DS1990, wyzeruj
1-bajtową zmienną CRC, potem po odczytaniu każdego bajtu z DS1990 wywolaj to, co
poniżej. Jeśli CRC po odczytaniu ostatniego bajtu i wywolaniu OblCRC8 jest zerowy,
to oznacza, że kod DS-a jest poprawny.Ta procedura została opublikowana w
materiałach technicznych Dallasa. Jest tam również przedstawiona w Pascalu oraz w
obu tych językach dla CRC-16.

OblCRC8:
; podprogram obliczania wielomianu X^8+X^5+X^4+1
; wejscie:
; acc - wartosc kolejnego bajtu
; wyjscie:
; CRC - obliczona wartosc wielomianu
; poza tym narusza zasoby:
; nie narusza
push b
push acc
mov b,#8
OCRC81:
xrl a,CRC
rrc a
mov a,CRC
jnc OCRC82
xrl a,#18h
OCRC82:
rrc a
mov CRC,a
pop acc
rr a
push acc
djnz b,OCRC81
pop acc
pop b
ret



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

Poprzedni Następny
Wiadomość
Spis treści
From: Marcin Wolcendorf <wolcendo_at_nospam_free.polbox.pl>
Subject: Re: CRC dla DS1990
Date: Sat, 04 Nov 2000 17:16:21 +0100




Mirosław LACH wrote:

Czy ktos probowal napisac w C procedurke liczenia CRC dla pastylek Dallas
DS1990?

Służę uprzejmie. Przed rozpoczęciem obliczania CRC dla całego kodu DS1990, wyzeruj
1-bajtową zmienną CRC, potem po odczytaniu każdego bajtu z DS1990 wywolaj to, co
poniżej. Jeśli CRC po odczytaniu ostatniego bajtu i wywolaniu OblCRC8 jest zerowy,
to oznacza, że kod DS-a jest poprawny.Ta procedura została opublikowana w
materiałach technicznych Dallasa. Jest tam również przedstawiona w Pascalu oraz w
obu tych językach dla CRC-16.

Jeśli procedura jest wywoływana dla bajtów (nie dla bitów- w zasadzie procedura
dla bitów jest tu szczególnym przypadkiem) a wielomian jest znany z góry oraz można
poświęcić 256*(długość reszty z dzielenia przez wielomian) bajtów w ROM-ie, to
najpierw można po prostu policzyć sumę kontrolną dla bajtów o wartościach od 0 do 255,
a później brać najmłodszy bajt liczonej reszty jako indeks do tej tablicy. Wygląda to
mniej-więcej tak
r(j)- reszta, krok j-ty, din(i)- dane w-we, bajt i-ty, crc[256]- tablica policzonych
wartości.

r(j+1) = ((crc[r(j)&0xff] ^ r(j)) >> 8) ^ (din(j+1)<< (8*(dł. reszty w bajtach-1)))

Tu w zasadzie nie ma już słowa o wielomianie- cały siedzi w tablicy:

crc[i] = CRC policzone dla bajtu o wartości i

którą liczy się tylko raz, a reszta operacji jest prosta i wykonywana na całych
bajtach.

I już. Pozostaje tylko przypisanie r(0)=?.

Oczywiście można to równie dobrze zrobić dla tablicy z 2B indeksem (64 Ksłów...) albo
np. dla półbajtów... Zaletę takiego rozwiązania widać, kiedy procesor nie potrafi
przesuwać w prawo... :-)


Pozdrawiam,

Marcin.

--
'My experience is that it is hard to find software producers that aren't fuzzy.'




Poprzedni Następny
Wiadomość
Spis treści
From: mirek-l_at_nospam_ikp.atm.com.pl (=?iso-8859-2?Q?Miros=B3aw?= LACH)
Subject: Re: CRC dla DS1990
Date: 4 Nov 2000 19:27:06 +0100




Jeśli procedura jest wywoływana dla bajtów (nie dla bitów- w zasadzie procedura
dla bitów jest tu szczególnym przypadkiem) a wielomian jest znany z góry oraz można
poświęcić 256*(długość reszty z dzielenia przez wielomian) bajtów w ROM-ie, to
najpierw można po prostu policzyć sumę kontrolną dla bajtów o wartościach od 0 do 255,
a później brać najmłodszy bajt liczonej reszty jako indeks do tej tablicy. Wygląda to
mniej-więcej tak
r(j)- reszta, krok j-ty, din(i)- dane w-we, bajt i-ty, crc[256]- tablica policzonych
wartości.

r(j+1) = ((crc[r(j)&0xff] ^ r(j)) >> 8) ^ (din(j+1)<< (8*(dł. reszty w bajtach-1)))

Tu w zasadzie nie ma już słowa o wielomianie- cały siedzi w tablicy:

crc[i] = CRC policzone dla bajtu o wartości i

którą liczy się tylko raz, a reszta operacji jest prosta i wykonywana na całych
bajtach.

I już. Pozostaje tylko przypisanie r(0)=?.

Oczywiście można to równie dobrze zrobić dla tablicy z 2B indeksem (64 Ksłów...) albo
np. dla półbajtów... Zaletę takiego rozwiązania widać, kiedy procesor nie potrafi
przesuwać w prawo... :-)

Tym sposobem skomentowałeś procedurę zapisaną w Pascalu...


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

Poprzedni Następny
Wiadomość
Spis treści
From: "peters" <peters_at_nospam_poczta.onet.pl>
Subject: Re: CRC dla DS1990
Date: Sat, 4 Nov 2000 19:55:28 +0100


Służę uprzejmie. Przed rozpoczęciem obliczania CRC dla całego kodu DS1990,
wyzeruj
1-bajtową zmienną CRC, potem po odczytaniu każdego bajtu z DS1990 wywolaj
to, co

No i BLAD ! Nalezy liczyc crc jednoczesnie z odczytem kolejnych bitow a nie
bajtow !!!:))

--
pozdrawiam, peters
peters_at_nospam_poczta.onet.pl
http://peters.republika.pl (strona Petersa dla elektronikow)



Poprzedni Następny
Wiadomość
Spis treści
From: mirek-l_at_nospam_ikp.atm.com.pl (=?iso-8859-2?Q?Miros=B3aw?= LACH)
Subject: Re: CRC dla DS1990
Date: 5 Nov 2000 16:04:27 +0100


Służę uprzejmie. Przed rozpoczęciem obliczania CRC dla całego kodu DS1990,

wyzeruj
1-bajtową zmienną CRC, potem po odczytaniu każdego bajtu z DS1990 wywolaj
to, co

No i BLAD ! Nalezy liczyc crc jednoczesnie z odczytem kolejnych bitow a nie
bajtow !!!:))


Nie. Przyjrzyj sie dokladnie programowi.

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

Poprzedni Następny
Wiadomość
Spis treści
From: "peters" <peters_at_nospam_poczta.onet.pl>
Subject: Re: CRC dla DS1990
Date: Sun, 5 Nov 2000 16:51:42 +0100


Nie. Przyjrzyj sie dokladnie programowi.
Zobacz, ze mozna tak jak mowie:

#define dallas_out GP1=0; mtris&=~0x02; TRIS=mtris
#define dallas_inp mtris|=0x02; TRIS=mtris
// GP.1-Dallas
unsigned char crc

unsigned char dallas_read()
{
unsigned char i;
unsigned char slowo;
static bit inp;
slowo=0;
for(i=8;i>0;i--)
{
slowo>>=1;
dallas_out;
asm("nop"); asm("nop");
dallas_inp;
asm("nop"); asm("nop");
inp=0;
if(GP1) {slowo|=0x80; inp=1;}
// licz crc
if (inp^(0x01&crc))
{
crc^=0x18;
crc>>=1;
crc|=0x80;
} else crc>>=1;
asm("nop"); asm("nop");
}
return(slowo);
}


--
pozdrawiam, peters
peters_at_nospam_poczta.onet.pl
http://peters.republika.pl (strona Petersa dla elektronikow. Aktualizacja:
05.11.2000)