8051
Masz problem? Zapytaj na forum elektroda.pl z bramką pl.misc.elektronika!
From: Jarosz Tomasz <e059_at_nospam_ucku4.uck.pk.edu.pl>
Subject: 8051
Date: Wed, 11 Mar 1998 14:10:53 +0100
Jak w kompilatorze Keil C dla 8051 podzielic port P1 na starsza i mlodsza
tetrade. Czy mozna podzielic port np. na trzy czesci.
Gdzie mozna znalesc przykladowe programy w C do 8051 lub 68hc11 ?
From: Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl>
Subject: Re: 8051
Date: 12 Mar 1998 18:30:48 GMT
In pl.misc.elektronika Jarosz Tomasz <e059_at_nospam_ucku4.uck.pk.edu.pl> wrote:
Jak w kompilatorze Keil C dla 8051 podzielic port P1 na starsza i mlodsza
tetrade. Czy mozna podzielic port np. na trzy czesci.
Gdzie mozna znalesc przykladowe programy w C do 8051 lub 68hc11 ?
A po cholere używasz takiego badziewia do programowania mikrokontrolerów ?
Najlepszy jest do tego jakiś assembler. Kompilator C dla uC sucks.
Proponuje nauczyć się assemblera, a nie bawić się jakimiś badziewiami.
--
Paweł Świrek _at_nospam_KING_CRIM on IRC, IRC-admin _at_nospam_ Cracow.PL.EU.Kewl.Org 1
Mailto: swierk_at_nospam_student.uci.agh.edu.pl 2
PGP finger: swierk_at_nospam_student.uci.agh.edu.pl 3
WWW : http://ibm.uci.agh.edu.pl/~swierk 4 :-)
From: Olgierd Cybulski <cybulski_at_nospam_pkpf.if.uj.edu.pl>
Subject: Re: 8051
Date: Fri, 13 Mar 1998 00:18:33 +0100
Pawel Swirek wrote:
Jak w kompilatorze Keil C dla 8051 podzielic port P1 na starsza i mlodsza
tetrade. Czy mozna podzielic port np. na trzy czesci.
Gdzie mozna znalesc przykladowe programy w C do 8051 lub 68hc11 ?
A po cholere używasz takiego badziewia do programowania mikrokontrolerów ?
Najlepszy jest do tego jakiś assembler. Kompilator C dla uC sucks.
Proponuje nauczyć się assemblera, a nie bawić się jakimiś badziewiami.
W zasadzie popieram - assemblera trzeba sie nauczyc, zeby w ogole
zrozumiec idee programowania mikrokontrolerów.
Jednak C też bywa potrzebny.
Kiedyś myślałem, że wszystko da się łatwo i prosto napisać w
assemblerze.
Tyle, że przy naprawdę dużych programach (kilkanaście kilobajtów) robi
się
z tego koszmar.
Po pierwsze - mnoza sie rozne identyfikatory o globalnym zasiegu
(wiekszosc assemblerow nie ma zaslaniania zmiennych).
Po drugie - niewygodnie wywoluje sie procedury.
Trzeba zawsze dbac o wpisanie na stos (lub gdzie indziej) argumentów,
o późniejsze ich zdjęcie przed powrotem - nawet, gdy funkcji uzywa sie
bardzo czesto. Napisalem sobie "preprocesor" programow assemblerowych,
dzieki ktorym moge uzywac funkcji z argumentami podawanymi w nawiasach,
jednak w wiekszosci asemblerow czegos takiego nie ma, a przydaje sie,
bo dzieki temu tzw. ramka wywolania procedury zajmuje jedna linijke,
a nie np. dziesiec, poza tym o ile czytelniej to wyglada.
Po trzecie - organizacja klasycznych petli lub instrukcji
warunkowych if-then-else, w asemblerze wyglada malo czytelnie.
Po czwarte - trudno jest laczyc moduly napisane przez rozne osoby,
trzeba sie specjalnie umawiac np. co do konwencji wywolania funkcji
itp.
Dodam, że jak dotąd programuję (mikrokontrolery) tylko w assemblerze,
ale tak bardzo brak mi czasem prostych udogodnien wyzszego poziomu,
ze sam sobie napisalem i stale rozwijam preprocesor - program,
dzieki ktoremu moge uzywac funkcji, makr, prostych petli,
bibliotek z funkcjami, itp.
Preprocesor otrzymuje na wejsciu program napisany wlasnie w takim
jezyku paraasemblerowym ciut wyższego poziomu, i przerabia ow program
na czysty asembler zrozumialy dla normalnego kompilatora.
Byc moze rozbudowujac dalej swoj preprocesor, dojde kiedys do wniosku,
ze najprostszym rozwiazaniem bylby wlasnie kompilator C z mozliwoscia
kompilacji via-assembler, z pelna kontrola wykorzystania elementow
procesora (np. glebokosci stosu, rozmieszczania zmiennych
automatycznych)
i oczywiście z możliwością używania zawsze i wszędzie wstawek
asemblerowych.
W każdym razie bez znajomości asemblera nikt chyba nie nauczy się
dobrze programować mikrokontrolery. Warto się troche pomeczyc z nauka.
Olgierd
From: amart_at_nospam_pol.JUNKMAILPROTECTION.pl (Jaroslaw Cichorski Jr.)
Subject: Re: 8051
Date: Sat, 14 Mar 1998 19:27:21 GMT
Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl> wrote:
A po cholere używasz takiego badziewia do programowania mikrokontrolerów ?
Najlepszy jest do tego jakiś assembler. Kompilator C dla uC sucks.
Proponuje nauczyć się assemblera, a nie bawić się jakimiś badziewiami.
Absolutnie sie z Toba nie zgadzam.
Programowac uC trzeba sie nauczyc od assemblera - to podstawa, ale dla
powaznych projektow 'C' to KONIECZNOSC.
W ASM mozna sobie rzezbic wlasne programiki hobbystycznie - gdy masz
na to czas na studiach, ale jezeli chcesz stworzyc profesjonalna
powazna, niezawodna aplikacje w ROZSADNYM czasie tzn chcesz byc
konkurencyjny cenowo - to musisz uzywac 'C'. Moduly krytyczne czasowo
lub takie, ktorych nie oplaca sie pisac w 'C' pisze sie w ASM i
linkuje z caloscia.
Kiedys tez tak muslalem i nie uznawalem 'C' - do czasu - teraz
zmienilem zdanie. Procesory sa wystarczajaco szybkie, pamieci sa
tanie.
Zawsze trzeba brac pod uwage kilka czynnikow: czas tworzenia
oprogramowania, czas uruchamiania, latwosc pisania, przejrzystosc,
KOMPATYBILNOSC z innymi platformami, latwosc pozniejszych modyfikacji,
mozliwie mala ilosc popelnianych bledow, ostateczny koszt projektu i
wielkosc tworzonego kodu wynikowego.
Za wyjatkiem tego ostatniego punktu (i to tez nie zawsze) 'C' jest pod
kazdym wzgledem do przodu.
Na dowod tego co pisze przytaczam coraz wieksze powodzenie
kompilatorow 'C' np. dla takich uC jak PIC.
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
e-mail amart_at_nospam_pol.JUNKMAILPROTECTION.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: gred=no=spam_at_nospam_kki.net.pl (Grzegorz Redlarski)
Subject: Re: 8051
Date: Sun, 15 Mar 1998 01:26:10 GMT
On 12 Mar 1998 18:30:48 GMT, Pawel Swirek
<swierk_at_nospam_student.uci.agh.edu.pl> wrote:
In pl.misc.elektronika Jarosz Tomasz <e059_at_nospam_ucku4.uck.pk.edu.pl> wrote:
Jak w kompilatorze Keil C dla 8051 podzielic port P1 na starsza i mlodsza
tetrade. Czy mozna podzielic port np. na trzy czesci.
Gdzie mozna znalesc przykladowe programy w C do 8051 lub 68hc11 ?
A po cholere używasz takiego badziewia do programowania mikrokontrolerów ?
Najlepszy jest do tego jakiś assembler. Kompilator C dla uC sucks.
Proponuje nauczyć się assemblera, a nie bawić się jakimiś badziewiami.
Czy masz jakies bardziej konkretne argumenty przeciw C dla uC, niz to
"badziewie"? Bo ja widze sporo konkretnych zalet. Np. w C bardzo
wygodne sa zmienne strukturalne, wskazniki, funkcje w rodzaju
sizeof(), kontrola zgodosci typow itp. itd. Oczywiscie wszystko mozna
napisac w assemblerze, ale np. napisanie hierarchicznego menu do
wprowadzania nastaw (np. ok. setki nastaw roznego typu - dyskretne,
liczbowe calkowite i "float", nastawy "powiazane" [wybor zmiany
jednoczesnej lub indywidualnej]) wydaje mi sie o wiele latwiejsze do
napisania (i modyfikacji!) w C. Oczywiscie asembler trzeba znac i
kontrolowac co C wygenerowal.
gr
PS Proponuje nauczyc sie C, a nie bawic sie wylacznie badziwiastym
asemblerem ;-)
PS2 Czy masz jakis asembler + linker do programow powyzej 64k (banki)?
Bo ja mam :-) (razem z C). Pewnie napiszesz, ze w asemblerze programy
sa mniejsze i banki nie sa potrzebne... Z moich doswiadczen wynika, ze
praktycznie mozna zmniejszyc program do 50-75% piszac recznie w asm,
ale tylko czasami ma to sens. U mnie praktcznie programy maja prawie
50:50 asm:C (zrodla, bo kod jakies 20:80) i nie uwazam by wyciskanie
na sile 100:0 mialo sens.
PS3 Na mojej www powinny byc jakies linki do ftp z programami do '51.
--
Grzegorz Redlarski (Gdansk)
mailto:gred _at_nospam_ amg.gda.pl
http://www.amg.gda.pl/~gred/
From: Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl>
Subject: Re: 8051
Date: 16 Mar 1998 18:54:18 GMT
In pl.misc.elektronika Grzegorz Redlarski <gred=no=spam_at_nospam_kki.net.pl> wrote:
Czy masz jakies bardziej konkretne argumenty przeciw C dla uC, niz to
"badziewie"? Bo ja widze sporo konkretnych zalet. Np. w C bardzo
wygodne sa zmienne strukturalne, wskazniki, funkcje w rodzaju
sizeof(), kontrola zgodosci typow itp. itd. Oczywiscie wszystko mozna
napisac w assemblerze, ale np. napisanie hierarchicznego menu do
wprowadzania nastaw (np. ok. setki nastaw roznego typu - dyskretne,
liczbowe calkowite i "float", nastawy "powiazane" [wybor zmiany
jednoczesnej lub indywidualnej]) wydaje mi sie o wiele latwiejsze do
napisania (i modyfikacji!) w C. Oczywiscie asembler trzeba znac i
kontrolowac co C wygenerowal.
Takie mam argumenty, że C nie zawsze jest efektywny. Czasem C robi głupoty.
Assembler dla '51 jest o tyle dobry, że potem można łatwo program śledzić
pod debuggerem. A poza tym w jaki sposób łatwiejsze są do modyfikacji
programy w C ?
Mnie się też wiele rzeczy wydaje :-)
PS Proponuje nauczyc sie C, a nie bawic sie wylacznie badziwiastym
asemblerem ;-)
A po cholere ? Assembler jest najlepszy.
Przesłanie danej na port P1 :
MOV P1,#dana
Odczyt z P1 do rejestru :
MOV Rx,P1 , gdzie Rx - jeden z rejestrów R0 - R7
PS2 Czy masz jakis asembler + linker do programow powyzej 64k (banki)?
Bo ja mam :-) (razem z C). Pewnie napiszesz, ze w asemblerze programy
sa mniejsze i banki nie sa potrzebne... Z moich doswiadczen wynika, ze
praktycznie mozna zmniejszyc program do 50-75% piszac recznie w asm,
ale tylko czasami ma to sens. U mnie praktcznie programy maja prawie
50:50 asm:C (zrodla, bo kod jakies 20:80) i nie uwazam by wyciskanie
na sile 100:0 mialo sens.
Tyle że uC 8051 może zaadresować normalnie tylko 64 kB.
W taki sposób :
P2 - starsza część magistrali adresowej
P0 - magistrala danych / młodsza część magistrali adresowej
A w zasadzie, to po ch** pisać na '51 programy powyżej 64kB ?
Prosta dobra aplikacja mieści się niekiedy w kilku kB.
A poza tym w zasadzie żaden emulator EPROM'ow nie pójdzie z programem > 64kB
Jak chce napisać program większy niż 64kB, to nie używam 8051. W tej
sytuacji lepszy może być np. Motorola 68000 lub Intel 8088
PS3 Na mojej www powinny byc jakies linki do ftp z programami do '51.
A do Motoroli 68HC11 też ?
--
Paweł Świrek _at_nospam_KING_CRIM on IRC, IRC-admin _at_nospam_ Cracow.PL.EU.Kewl.Org 1
Mailto: swierk_at_nospam_student.uci.agh.edu.pl 2
PGP finger: swierk_at_nospam_student.uci.agh.edu.pl 3
WWW : http://ibm.uci.agh.edu.pl/~swierk 4 :-)
From: gred=no=spam_at_nospam_kki.net.pl (Grzegorz Redlarski)
Subject: Re: 8051
Date: Sat, 21 Mar 1998 01:55:14 GMT
On 16 Mar 1998 18:54:18 GMT, Pawel Swirek
<swierk_at_nospam_student.uci.agh.edu.pl> wrote:
In pl.misc.elektronika Grzegorz Redlarski <gred=no=spam_at_nospam_kki.net.pl> wrote:
Czy masz jakies bardziej konkretne argumenty przeciw C dla uC, niz to
"badziewie"? Bo ja widze sporo konkretnych zalet. Np. w C bardzo
wygodne sa zmienne strukturalne, wskazniki, funkcje w rodzaju
sizeof(), kontrola zgodosci typow itp. itd. Oczywiscie wszystko mozna
napisac w assemblerze, ale np. napisanie hierarchicznego menu do
wprowadzania nastaw (np. ok. setki nastaw roznego typu - dyskretne,
liczbowe calkowite i "float", nastawy "powiazane" [wybor zmiany
jednoczesnej lub indywidualnej]) wydaje mi sie o wiele latwiejsze do
napisania (i modyfikacji!) w C. Oczywiscie asembler trzeba znac i
kontrolowac co C wygenerowal.
Takie mam argumenty, że C nie zawsze jest efektywny. Czasem C robi głupoty.
To, ze robi glupoty, to fakt. Dlatego trzeba sie temu przyjrzec, co
wyprodukowal.
Assembler dla '51 jest o tyle dobry, że potem można łatwo program śledzić
pod debuggerem. A poza tym w jaki sposób łatwiejsze są do modyfikacji
programy w C ?
Na emulatorze sobie sledze C w zrodle i ASM lub wymieszane... A
programy w C, zwlaszcza duze, sa czytelniejsze i dlatego latwiej je
modyfikowac. Np. dopisanie jednej pozycji do nastaw, to w C dopisanie
jednej pozycji w zmiennej strukturalnej (wartosc, zakres, typ,
jednostki itp.). W asm chyba sie nie da tego latwo zrobic aby to bylo
dopisanie tylko jednej linii programu. Poza tym, programy w C sa
krotsze i przez to latwiejsze do ogarniecia w calosci, np. funkcja,
ktora w C zmiesci Ci sie na pol strony (jeden ekran), w asm zajmie
kilka stron (np. 5 ekranow i trzeba przewijac gora dol).
Przesłanie danej na port P1 :
MOV P1,#dana
P1 = dana; // "dana" to jakas stala w Twoim przykladzie - w C to
identyczny zapis bedzie dla stalej i zmiennej, np.
#define DANA 5
char dana;
P1 = DANA;
P1 = dana;
Odczyt z P1 do rejestru :
MOV Rx,P1 , gdzie Rx - jeden z rejestrów R0 - R7
dana = P1;
Rx sa wykorzystywane jako robocze w C i nie mozna ich wprost
wykorzystywac, choc jak ktos sie uprze, to mozna.
A w zasadzie, to po ch** pisać na '51 programy powyżej 64kB ?
Czasem tak wychodzi :-(
Prosta dobra aplikacja mieści się niekiedy w kilku kB.
Mialem i taki program, ze nie mial nawet 0.5kB
(pisany w C, a jakze :-) )
A poza tym w zasadzie żaden emulator EPROM'ow nie pójdzie z programem > 64kB
Niby dlaczego?
Jak chce napisać program większy niż 64kB, to nie używam 8051. W tej
sytuacji lepszy może być np. Motorola 68000 lub Intel 8088
Jesli maja RS, timery, porty, a jeszcze przydalyby sie ADC, PWM, CCU,
watch-dog, (E)EPROM i RAM wewnetrzny, to czemu nie... (mam na mysli
cala rodzine '51)
PS3 Na mojej www powinny byc jakies linki do ftp z programami do '51.
A do Motoroli 68HC11 też ?
Trafialem je dosc czesto na www i na news, ale adresow nie zbieralem
:-(
Ostatnio trafilem na nie pod:
http://www.geocities.com/ResearchTriangle/1495/
From: amart_at_nospam_pol.JUNKMAILPROTECTION.pl (Jaroslaw Cichorski Jr.)
Subject: Re: 8051
Date: Sat, 21 Mar 1998 18:41:23 GMT
gred=no=spam_at_nospam_kki.net.pl (Grzegorz Redlarski) wrote:
<snip>
Takie mam argumenty, że C nie zawsze jest efektywny. Czasem C robi głupoty.
To, ze robi glupoty, to fakt. Dlatego trzeba sie temu przyjrzec, co
wyprodukowal.
Wynik trzeba obejrzec zawsze. To ze robi glupoty wynika glownie z
tego, ze probuje sie rozwiazywac proste problemy za pomoca
wyrafinowanych technik programowania w 'C' z uzyciem wskanikow,
wskaznikow do wskaznikow itd. Jezeli pisze sie w 'C' oprogramowanie do
ukontrolerow (zwlaszcza malych) to trzeba zapomniec o elegancji
programowania. Najlepiej uzywac prostych notacji i prostych typow
zmiennych. Duza uwage nalezy zwrocic na wybrany model pamieci i
umiejscowienie zmiennych. Kazde uzycie wskaznika (lub zmiennej
indeksowej do tablicy) umieszczonego w xdata wydluza niepotrzebnie
program. To wszystko trzeba wiedziec, a ta wiedze zdobywa sie uczac
sie najpierw programowania w ASM i sledzac wyniki kompilacji w 'C'.
Smiem twierdzic, ze dobrze napisany program w 'C' jest objetosciowo
porownywalny (moze nieznacznie wiekszy) od programu w ASM, a pisze sie
go i uruchamia kilkanascie razy szybciej.
Assembler dla '51 jest o tyle dobry, że potem można łatwo program śledzić
pod debuggerem. A poza tym w jaki sposób łatwiejsze są do modyfikacji
programy w C ?
Na emulatorze sobie sledze C w zrodle i ASM lub wymieszane... A
programy w C, zwlaszcza duze, sa czytelniejsze i dlatego latwiej je
modyfikowac.
<snip>
Tak jest, swieta racja, np. modyfikacja struktur danych nie burzy
calego programu.
<snip>
Przesłanie danej na port P1 :
MOV P1,#dana
P1 = dana; // "dana" to jakas stala w Twoim przykladzie - w C to
identyczny zapis bedzie dla stalej i zmiennej, np.
#define DANA 5
char dana;
P1 = DANA;
P1 = dana;
Odczyt z P1 do rejestru :
MOV Rx,P1 , gdzie Rx - jeden z rejestrów R0 - R7
dana = P1;
I jak obejrzysz wynik to wyglada tak samo ;-))))
Jesli maja RS, timery, porty, a jeszcze przydalyby sie ADC, PWM, CCU,
watch-dog, (E)EPROM i RAM wewnetrzny, to czemu nie... (mam na mysli
cala rodzine '51)
Np. jej 16 bitowe rozszerzenie - rodzina XA ulatwia przenoszenie
aplikacji ze zwyklej '51 dzieki kompatybilnosci i udostepnia wieksza
pamiec danych i programu.
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
e-mail amart_at_nospam_pol.JUNKMAILPROTECTION.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: gred=no=spam_at_nospam_kki.net.pl (Grzegorz Redlarski)
Subject: Re: 8051
Date: Mon, 23 Mar 1998 00:00:05 GMT
On Sat, 21 Mar 1998 18:41:23 GMT, amart_at_nospam_pol.JUNKMAILPROTECTION.pl
(Jaroslaw Cichorski Jr.) wrote:
gred=no=spam_at_nospam_kki.net.pl (Grzegorz Redlarski) wrote:
<snip>
Takie mam argumenty, że C nie zawsze jest efektywny. Czasem C robi głupoty.
To, ze robi glupoty, to fakt. Dlatego trzeba sie temu przyjrzec, co
wyprodukowal.
Wynik trzeba obejrzec zawsze. To ze robi glupoty wynika glownie z
tego, ze probuje sie rozwiazywac proste problemy za pomoca
wyrafinowanych technik programowania w 'C' z uzyciem wskanikow,
Wskazniki faktycznie nie sa mocna strona '51, czego piszac w C i nie
ogladajac kodu, mozna niezauwazyc. Natomiast slaba srona
kompilatorow jest nieraz zbyt sztywne trzymanie sie ANSII, nawet gdy
to nie ma sensu. Np. operacje na bajtach, moga byc przed wykonaniem
operacji zamienione na int, nawet gdy to nie ma wplywu na wynik. Tak
na marginesie, to czasem jednak ten wplyw na wynik niespodziewanie
wychodzi, np. char b; if(~b) zawsze bedzie prawdziwe.
gr
From: "Wojciech Wiercigroch" <Wojciech.Wiercigroch_at_nospam_ComArch.Pl>
Subject: Re: 8051
Date: 23 Mar 1998 08:28:36 GMT
Grzegorz Redlarski <gred=no=spam_at_nospam_kki.net.pl> napisał(a) w artykule
<35179058.62297059_at_nospam_news.icm.edu.pl>...
Wskazniki faktycznie nie sa mocna strona '51, czego piszac w C i nie
ogladajac kodu, mozna niezauwazyc. Natomiast slaba srona
kompilatorow jest nieraz zbyt sztywne trzymanie sie ANSII, nawet gdy
to nie ma sensu. Np. operacje na bajtach, moga byc przed wykonaniem
operacji zamienione na int, nawet gdy to nie ma wplywu na wynik. Tak
na marginesie, to czasem jednak ten wplyw na wynik niespodziewanie
wychodzi, np. char b; if(~b) zawsze bedzie prawdziwe.
gr
Jest to niewatpliwie slaba strona kompilatora, ale osobiscie
nic mi nie wiadomo o niejawnej konwersji typow w standarcie ANSI,
w przypadku, gdy nie ma takiej koniecznosci. Podany przyklad
jest ewidentnym bledem kompilatora, a nie standardu, ktory
realizuje. Byc moze sie myle, gdybys mogl podac zrodlo, z ktorego
masz takie dane o standarcie ANSI bede wdzieczny (moze na priva bo
dyskusja juz chyba zeszla calkiem na informatyke)
wosiek email:wosiek_at_nospam_comarch.pl
From: gred=no=spam_at_nospam_kki.net.pl (Grzegorz Redlarski)
Subject: Re: 8051
Date: Tue, 24 Mar 1998 11:27:49 GMT
On 23 Mar 1998 08:28:36 GMT, "Wojciech Wiercigroch"
<Wojciech.Wiercigroch_at_nospam_ComArch.Pl> wrote:
Grzegorz Redlarski <gred=no=spam_at_nospam_kki.net.pl> napisał(a) w artykule
<35179058.62297059_at_nospam_news.icm.edu.pl>...
wychodzi, np. char b; if(~b) zawsze bedzie prawdziwe.
Sorry, powino byc:
unsigned char b;
if(~b)
Kolejnosc wykonywania operacji jest nastepujaca (skupmy się na
najciekawszym przypadku, gdy b = 0xFF):
- 0xFF jest zamieniane na (int) (tego wlasnie wymaga ANSI) i wychodzi
0x00FF , choc faktem jest, ze standard nie przewiduje sposobu
konwersji. Jest jedynie pewne wymaganie, ktore dotyczy tylko "znakow
alfabetu", aby po konwersji byly dodatnie.
- liczba jest rozna od zera i warunek jest prawdziwy :-O
Prawde mowiac, ze wzgledu na niejednoznacznosc konwersji, wynik moze
byc rozny w roznych implementacjach. Taki wynik dostaje w kompilatorze
IAR do '51. Generalnie, trzeba uwazac z operacjami na zmiennych
jednobajtowych.
Jesli zas chodzi o niepotrzebne konwersje, to puscilem tu kiedys
przyklad na liste (robie forward na priv):
====
Subject: Re: 80C51
Date: Thu, 13 Mar 1997 23:31:01 GMT
Message-ID: <332ad995.6612351_at_nospam_news.icm.edu.pl>
====
Jest to niewatpliwie slaba strona kompilatora, ale osobiscie
nic mi nie wiadomo o niejawnej konwersji typow w standarcie ANSI,
w przypadku, gdy nie ma takiej koniecznosci. Podany przyklad
jest ewidentnym bledem kompilatora, a nie standardu, ktory
realizuje. Byc moze sie myle, gdybys mogl podac zrodlo, z ktorego
masz takie dane o standarcie ANSI bede wdzieczny (moze na priva bo
dyskusja juz chyba zeszla calkiem na informatyke)
Najlepiej byloby to sprawdzic w Kernighan & Ritchie. Niestety, pod
reka mam tylko Bieleckiego z 1987 roku. Cytat:
"Najpierw te argumenty operacji, ktore sa typu (char) albo (short
int), zostaja poddane konwersji na dane typu (int), [...]". Dalej jest
o wyniku operacji i w zadnym przypadku nie wystepuje (char) lub
(unsigned char).
Pisze mimo wszystko na liste, bo moze to innych rowniez zainteresowac,
choc faktycznie temat jest bardziej na pl.comp.programming . Na pcp
puscilem natomiast pytanie w sprawie konwersji char -> int.
Tak na marginesie, to spotkalem kompilator C (na DSP Motoroli,
sciagniety z ich serwera), ktory nie trzymal sie zadnych zasad
konwersji typow jesli mu sie jawnie tego nie wpisalo. Potrafil np. w
dzialaniu (long) = (int) * (int); wpisywac zupelnie dowolna wartosc
starszego bajtu zmiennej (long), a wypadaloby chyba jednak trzymac
sie jakichs zasad. W ten sposob, np. 1 * 1 moglo dac w wyniku dajmy na
to 0x123456000001 (int jest tam 24 bitowy).
gr
From: amart_at_nospam_pol.JUNKMAILPROTECTION.pl (Jaroslaw Cichorski Jr.)
Subject: Re: 8051
Date: Wed, 25 Mar 1998 01:12:26 GMT
gred=no=spam_at_nospam_kki.net.pl (Grzegorz Redlarski) wrote:
<snip>
unsigned char b;
if(~b)
Kolejnosc wykonywania operacji jest nastepujaca (skupmy się na
najciekawszym przypadku, gdy b = 0xFF):
- 0xFF jest zamieniane na (int) (tego wlasnie wymaga ANSI) i wychodzi
0x00FF , choc faktem jest, ze standard nie przewiduje sposobu
konwersji. Jest jedynie pewne wymaganie, ktore dotyczy tylko "znakow
alfabetu", aby po konwersji byly dodatnie.
- negowanie na 0xFF00
- liczba jest rozna od zera i warunek jest prawdziwy :-O
Hmm,
nie znam IAR'a uzywam Keila i HT-Soft'a, ale:
w Keilu jest cos takiego jak
#pragma INPROMOTE /NOINTPROMOTE
ktora to opcja wlacza/wylacza konwersje mniejszych typow do int.
Taka opcja powinna byc tez w IAR - sprawdz to w instrukcji.
Jezeli nie ma takiej mozliwosci to fakt ten potwierdza slusznosc
wyboru Keila.
Gdy nie ma konwersji do int, po kompilacji twoj warunek wyglada
nastepujaco:
MOV A,addr_b ; addr_b jest adresem zmiennej b
CPL A
JZ A,gdzies tam
Tak wiec w Keilu dziala to dobrze.
Czasami taki brak konwersji moze powodowac inne problemy, np funkcja
sprintf() wymaga konwersji argumentow do typu int, inaczej bierze
tylko wyzszy bajt zawsze rowny 0xFF;
tak wiec trzeba pisac:
sprintf(bfr,"%02X",(int)zmienna);
zamiast
sprintf(bfr,"%02X",zmienna);
ale ja juz wole konwertowac tam gdzie ja chce, a nie tam gdzie
kompilator chce.
Pozdrawiam
Prawde mowiac, ze wzgledu na niejednoznacznosc konwersji, wynik moze
byc rozny w roznych implementacjach. Taki wynik dostaje w kompilatorze
IAR do '51. Generalnie, trzeba uwazac z operacjami na zmiennych
jednobajtowych.
Jesli zas chodzi o niepotrzebne konwersje, to puscilem tu kiedys
przyklad na liste (robie forward na priv):
====
Subject: Re: 80C51
Date: Thu, 13 Mar 1997 23:31:01 GMT
Message-ID: <332ad995.6612351_at_nospam_news.icm.edu.pl>
====
Jest to niewatpliwie slaba strona kompilatora, ale osobiscie
nic mi nie wiadomo o niejawnej konwersji typow w standarcie ANSI,
w przypadku, gdy nie ma takiej koniecznosci. Podany przyklad
jest ewidentnym bledem kompilatora, a nie standardu, ktory
realizuje. Byc moze sie myle, gdybys mogl podac zrodlo, z ktorego
masz takie dane o standarcie ANSI bede wdzieczny (moze na priva bo
dyskusja juz chyba zeszla calkiem na informatyke)
Najlepiej byloby to sprawdzic w Kernighan & Ritchie. Niestety, pod
reka mam tylko Bieleckiego z 1987 roku. Cytat:
"Najpierw te argumenty operacji, ktore sa typu (char) albo (short
int), zostaja poddane konwersji na dane typu (int), [...]". Dalej jest
o wyniku operacji i w zadnym przypadku nie wystepuje (char) lub
(unsigned char).
Pisze mimo wszystko na liste, bo moze to innych rowniez zainteresowac,
choc faktycznie temat jest bardziej na pl.comp.programming . Na pcp
puscilem natomiast pytanie w sprawie konwersji char -> int.
Tak na marginesie, to spotkalem kompilator C (na DSP Motoroli,
sciagniety z ich serwera), ktory nie trzymal sie zadnych zasad
konwersji typow jesli mu sie jawnie tego nie wpisalo. Potrafil np. w
dzialaniu (long) = (int) * (int); wpisywac zupelnie dowolna wartosc
starszego bajtu zmiennej (long), a wypadaloby chyba jednak trzymac
sie jakichs zasad. W ten sposob, np. 1 * 1 moglo dac w wyniku dajmy na
to 0x123456000001 (int jest tam 24 bitowy).
gr
--------
Jaroslaw Cichorski Jr.
e-mail amart_at_nospam_pol.JUNKMAILPROTECTION.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl>
Subject: Re: 8051
Date: 25 Mar 1998 08:26:01 GMT
In pl.misc.elektronika Grzegorz Redlarski <gred=no=spam_at_nospam_kki.net.pl> wrote:
A w zasadzie, to po ch** pisać na '51 programy powyżej 64kB ?
Czasem tak wychodzi :-(
Tyle, że 8051 adresuje tylko do 64 kB. Więcej nie pójdzie, chyba że się
chce przełączać bloki pamięci, lecz :
- traci się po jednej linii portu P1
- jak się zrobi SETB P1.0, gdy pod tą linie podpięta jest A16, to program
pójdzie w maliny
A poza tym w zasadzie żaden emulator EPROM'ow nie pójdzie z programem > 64kB
Niby dlaczego?
Bo kostka 27512 ma TYLKO 64 kB (8*64*1024 bitów)
Jesli maja RS, timery, porty, a jeszcze przydalyby sie ADC, PWM, CCU,
watch-dog, (E)EPROM i RAM wewnetrzny, to czemu nie... (mam na mysli
cala rodzine '51)
A Z80180 ?
Trafialem je dosc czesto na www i na news, ale adresow nie zbieralem
-(
Ostatnio trafilem na nie pod:
http://www.geocities.com/ResearchTriangle/1495/
Fajny procek. Zwłaszcza, że ma 4 przetworniki A/C (ośmiobitowe niestety).
Są jego dwie wersje, które mają przetworniki A/C dziesięciobitowe
Niedogodnością jest to, że trzeba korzystać z wewnętrznego ROM'u, jak się
chce mieć jakiś ośmiobitowy port We/wy, bo jak się zajmie magistrale
danych i adresową, to niewiele tego zostanie (m.in. czterobitowe wyjście).
Chyba, że jest tego jakaś wersja, co ma więcej portów.
--
Paweł Świrek _at_nospam_KING_CRIM on IRC, IRC-admin _at_nospam_ Cracow.PL.EU.Kewl.Org 1
Mailto: swierk_at_nospam_student.uci.agh.edu.pl 2
PGP finger: swierk_at_nospam_student.uci.agh.edu.pl 3
WWW : http://ibm.uci.agh.edu.pl/~swierk 4 :-)
From: Robert Tadeusz Wrebiak <rwrebiak_at_nospam_elektron.elka.pw.edu.pl>
Subject: Re: 8051
Date: 20 Mar 1998 13:35:49 GMT
Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl> wrote:
A po cholere używasz takiego badziewia do programowania mikrokontrolerów ?
Najlepszy jest do tego jakiś assembler. Kompilator C dla uC sucks.
Proponuje nauczyć się assemblera, a nie bawić się jakimiś badziewiami.
kolega ma syndrom: Mam_Monopol_Na_Prawde. Nie przecze ze na 8051 najlepiej
podejsc z asm ale Twoja reakcja chyba troche zbyt nerwowa.
Przy okazji: zaprogramujesz mi procek neuron 3150?
(procek w interfejsach czyjnikow inteligentnych standardu Lon
Works-programowalny tylko w C-jak widzisz czasami nie ma wyjscia...)
pozdrawiam
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Robert Wrebiak
s156979_at_nospam_ir.ire.pw.edu.pl
rwrebiak_at_nospam_elka.pw.edu.pl
http://home.elka.pw.edu.pl/~rwrebiak
nick: Roobik
From: Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl>
Subject: Re: 8051
Date: 20 Mar 1998 18:16:08 GMT
In pl.misc.elektronika Robert Tadeusz Wrebiak <rwrebiak_at_nospam_elektron.elka.pw.edu.pl> wrote:
kolega ma syndrom: Mam_Monopol_Na_Prawde. Nie przecze ze na 8051 najlepiej
podejsc z asm ale Twoja reakcja chyba troche zbyt nerwowa.
Przy okazji: zaprogramujesz mi procek neuron 3150?
(procek w interfejsach czyjnikow inteligentnych standardu Lon
Works-programowalny tylko w C-jak widzisz czasami nie ma wyjscia...)
pozdrawiam
Zawsze jest wyjście. C nie nadaje się do aplikacji czasu rzeczywistego.
Na pewno jest możliwość napisania w assemblerze. A jeśli jest to zbyt duża
aplikacja, to może wykorzystać inny procek, np Z80180. Też jest ponoć niezły
i dużo lepszy niż 8051. A poza tym 8051 jest dość niewygodny, jeśli chodzi
o testowanie aplikacji (nie ma możliwości zabrania magistral, nie ma
jednobajtowego rozkazu mającego moc wywołania, tak jak SWI w Motoroli, czy
INT3 w 80x86) i adresuje tylko 64 kB (P0 i P2 - 16 linii, 2^16 = 65536,
DPTR jest również 16-bitowy).
--
Paweł Świrek _at_nospam_KING_CRIM on IRC, IRC-admin _at_nospam_ Cracow.PL.EU.Kewl.Org 1
Mailto: swierk_at_nospam_student.uci.agh.edu.pl 2
PGP finger: swierk_at_nospam_student.uci.agh.edu.pl 3
WWW : http://ibm.uci.agh.edu.pl/~swierk 4 :-)
From: Waldemar Rączka <wraczka_at_nospam_uci.agh.edu.pl>
Subject: Re: 8051
Date: Sat, 21 Mar 1998 13:21:06 +0100
Pawel Swirek wrote:
(procek w interfejsach czyjnikow inteligentnych standardu Lon
Works-programowalny tylko w C-jak widzisz czasami nie ma wyjscia...)
pozdrawiam
C nie nadaje się do aplikacji czasu rzeczywistego.
A to dlaczego sie nie nadaje ??
waldek
From: Maciej Gruszecki <mgr_at_nospam_kki.net.pl>
Subject: Re: 8051
Date: Mon, 23 Mar 1998 09:10:01 +0100
Waldemar Rączka wrote:
Pawel Swirek wrote:
(procek w interfejsach czyjnikow inteligentnych standardu Lon
Works-programowalny tylko w C-jak widzisz czasami nie ma wyjscia...)
pozdrawiam
C nie nadaje się do aplikacji czasu rzeczywistego.
A to dlaczego sie nie nadaje ??
Bo nie wiesz do konca jak dlugi kod (czasowo) wygeneruje C.
--
_/_/_/ _/_/_/ _/_/_/ _/_/ Maciej Gruszecki
_/ _/ _/_ _/ _/ _/ _/ ICQ: 5993706
_/_/_/ _/ _/_/_/ _/_/ WWW: http://www.polsl.gliwice.pl/~pear
_/ _/_/_/ _/ _/ _/ _/ e-mail: mailto:mgr_at_nospam_kki.net.pl
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: 8051
Date: 23 Mar 1998 18:15:13 GMT
Maciej Gruszecki <mgr_at_nospam_kki.net.pl> wrote:
Waldemar Rączka wrote:
A to dlaczego sie nie nadaje ??
Bo nie wiesz do konca jak dlugi kod (czasowo) wygeneruje C.
To kupujesz dwa razy szybszy procek :-)
J.
From: Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl>
Subject: Re: 8051
Date: 25 Mar 1998 08:17:27 GMT
In pl.misc.elektronika Jaroslaw Lis <lis_at_nospam_papuga.ict.pwr.wroc.pl> wrote:
To kupujesz dwa razy szybszy procek :-)
I płacić więcej. A pisanie w assemblerze nic nie kosztuje :-)
--
Paweł Świrek _at_nospam_KING_CRIM on IRC, IRC-admin _at_nospam_ Cracow.PL.EU.Kewl.Org 1
Mailto: swierk_at_nospam_student.uci.agh.edu.pl 2
PGP finger: swierk_at_nospam_student.uci.agh.edu.pl 3
WWW : http://ibm.uci.agh.edu.pl/~swierk 4 :-)
From: Michal Baszynski <michal_at_nospam_nospam.ikar.t17.ds.pwr.wroc.pl>
Subject: Re: 8051
Date: Wed, 25 Mar 1998 12:02:00 +0100
Pawel Swirek wrote:
I płacić więcej. A pisanie w assemblerze nic nie kosztuje :-)
Kosztuje, kosztuje. Najczesciej duzo zdrowia jesli jest cos bardziej
zlozonego do zrobienia, np. miernik w ktorym musisz aproksymowac
charakterystyke czujnika funkcja y=a*b^x i to gdy masz jeszcze sobie
samemu w procesie kalibracji wyznaczyc parametry rownania a i b (
jedynie x jest liczba calkowita - z przetwornika A/D, reszta liczby
rzeczywiste ). Ciekawe ile czasu zajmie to Tobie w asemblerze ?
Michal
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: 8051
Date: 25 Mar 1998 11:34:32 GMT
Michal Baszynski <michal_at_nospam_nospam.ikar.t17.ds.pwr.wroc.pl> wrote:
Pawel Swirek wrote:
I płacić więcej. A pisanie w assemblerze nic nie kosztuje :-)
Kosztuje, kosztuje. Najczesciej duzo zdrowia jesli jest cos bardziej
zlozonego do zrobienia, np. miernik w ktorym musisz aproksymowac
charakterystyke czujnika funkcja y=a*b^x i to gdy masz jeszcze sobie
samemu w procesie kalibracji wyznaczyc parametry rownania a i b (
jedynie x jest liczba calkowita - z przetwornika A/D, reszta liczby
rzeczywiste ). Ciekawe ile czasu zajmie to Tobie w asemblerze ?
Ciekawe Ci Ci sie to zmiesci w EEPROM :-)
J.
From: Michal Baszynski <michal_at_nospam_nospam.ikar.t17.ds.pwr.wroc.pl>
Subject: Re: 8051
Date: Thu, 26 Mar 1998 01:37:47 +0100
Jaroslaw Lis wrote:
Ciekawe Ci Ci sie to zmiesci w EEPROM :-)
Zalezy ktorym ;-)). Przy uzyciu starego Keila w pracowni na ul.Prusa (
budynek E-1 ) wg. linkera program zajmuje 4637B a nie byl pisany
najoszczedniej.
Michal
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: 8051
Date: 26 Mar 1998 09:57:09 GMT
Michal Baszynski <michal_at_nospam_nospam.ikar.t17.ds.pwr.wroc.pl> wrote:
Jaroslaw Lis wrote:
Ciekawe Ci Ci sie to zmiesci w EEPROM :-)
Zalezy ktorym ;-)). Przy uzyciu starego Keila w pracowni na ul.Prusa (
budynek E-1 ) wg. linkera program zajmuje 4637B a nie byl pisany
najoszczedniej.
No tak, ale 89C51 ma 4096B i ani bita wiecej :-)
J.
From: Michal Baszynski <michal_at_nospam_nospam.ikar.t17.ds.pwr.wroc.pl>
Subject: Re: 8051
Date: Thu, 26 Mar 1998 12:53:29 +0100
Jaroslaw Lis wrote:
No tak, ale 89C51 ma 4096B i ani bita wiecej :-)
Ale 89C52 ma 8192B, podobnie 89S8252.
Michal
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: 8051
Date: 26 Mar 1998 09:59:40 GMT
Michal Baszynski <michal_at_nospam_nospam.ikar.t17.ds.pwr.wroc.pl> wrote:
Pawel Swirek wrote:
I płacić więcej. A pisanie w assemblerze nic nie kosztuje :-)
Kosztuje, kosztuje. Najczesciej duzo zdrowia jesli jest cos bardziej
zlozonego do zrobienia, np. miernik w ktorym musisz aproksymowac
charakterystyke czujnika funkcja y=a*b^x i to gdy masz jeszcze sobie
samemu w procesie kalibracji wyznaczyc parametry rownania a i b (
jedynie x jest liczba calkowita - z przetwornika A/D, reszta liczby
rzeczywiste ). Ciekawe ile czasu zajmie to Tobie w asemblerze ?
Z doswiadczenia: tydzien na dopracowanie procedur FP, potem z gorki.
Z gorki na wiele projektow, jesli bedzie zbyt.
Z drugiej strony - czy twoje C ma FP ?
J.
From: Michal Baszynski <michal_at_nospam_nospam.ikar.t17.ds.pwr.wroc.pl>
Subject: Re: 8051
Date: Thu, 26 Mar 1998 12:51:10 +0100
Jaroslaw Lis wrote:
Z drugiej strony - czy twoje C ma FP ?
ma :-)))))
Michal
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: 8051
Date: 25 Mar 1998 11:37:21 GMT
Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl> wrote:
In pl.misc.elektronika Jaroslaw Lis <lis_at_nospam_papuga.ict.pwr.wroc.pl> wrote:
To kupujesz dwa razy szybszy procek :-)
I płacić więcej. A pisanie w assemblerze nic nie kosztuje :-)
Oj, kosztuje, kosztuje.
Czasem bardzo duzo - trzy miesiace, a konkurencja w tym czasie opanowuje
80% rynku...
J.
From: amart_at_nospam_pol.JUNKMAILPROTECTION.pl (Jaroslaw Cichorski Jr.)
Subject: Re: 8051
Date: Wed, 25 Mar 1998 17:44:04 GMT
"Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl> wrote:
I płacić więcej. A pisanie w assemblerze nic nie kosztuje :-)
Oj, kosztuje, kosztuje.
Czasem bardzo duzo - trzy miesiace, a konkurencja w tym czasie opanowuje
80% rynku...
To student (nikomu nic nie ujmuje), wiec jeszcze nie mysli tymi
kategoriami ;-))
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
e-mail amart_at_nospam_pol.JUNKMAILPROTECTION.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: 8051
Date: 25 Mar 1998 21:51:33 GMT
Jaroslaw Cichorski Jr. <amart_at_nospam_pol.JUNKMAILPROTECTION.pl> wrote:
"Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl> wrote:
I płacić więcej. A pisanie w assemblerze nic nie kosztuje :-)
Oj, kosztuje, kosztuje.
Czasem bardzo duzo - trzy miesiace, a konkurencja w tym czasie opanowuje
80% rynku...
To student (nikomu nic nie ujmuje), wiec jeszcze nie mysli tymi
kategoriami ;-))
Na pewno? Dzis daja piatke, za tydzien trzy, za miesiac ... bacznosc,
szeregowy :-)
J.
From: amart_at_nospam_pol.JUNKMAILPROTECTION.pl (Jaroslaw Cichorski Jr.)
Subject: Re: 8051
Date: Thu, 26 Mar 1998 09:49:50 GMT
Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl> wrote:
In pl.misc.elektronika Jaroslaw Lis <lis_at_nospam_papuga.ict.pwr.wroc.pl> wrote:
To kupujesz dwa razy szybszy procek :-)
I płacić więcej. A pisanie w assemblerze nic nie kosztuje :-)
Mylisz sie Wasc, kosztuje CZAS !!!!
--------
Jaroslaw Cichorski Jr.
e-mail amart_at_nospam_pol.JUNKMAILPROTECTION.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: amart_at_nospam_pol.JUNKMAILPROTECTION.pl (Jaroslaw Cichorski Jr.)
Subject: Re: 8051
Date: Mon, 23 Mar 1998 18:38:28 GMT
Maciej Gruszecki <mgr_at_nospam_kki.net.pl> wrote:
<snip>
C nie nadaje się do aplikacji czasu rzeczywistego.
A to dlaczego sie nie nadaje ??
Bo nie wiesz do konca jak dlugi kod (czasowo) wygeneruje C.
--
A w ASM wiesz to od razu ?
Jak dobrze zoptymalizujesz to nie ma obawy, a do sekcji krytycznej
(czasowo) zawsze mozna zlinkowac procedure w ASM, jesli trzeba.
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
e-mail amart_at_nospam_pol.JUNKMAILPROTECTION.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl>
Subject: Re: 8051
Date: 25 Mar 1998 08:16:13 GMT
In pl.misc.elektronika Jaroslaw Cichorski Jr. <amart_at_nospam_pol.JUNKMAILPROTECTION.pl> wrote:
A w ASM wiesz to od razu ?
Jak dobrze zoptymalizujesz to nie ma obawy, a do sekcji krytycznej
(czasowo) zawsze mozna zlinkowac procedure w ASM, jesli trzeba.
A zebyś wiedział, że od razu. Przecież w książce do 8051 jest podane, w ilu
cyklach wykonuje sie dany rozkaz. Można wtedy łatwo to określić.
--
Paweł Świrek _at_nospam_KING_CRIM on IRC, IRC-admin _at_nospam_ Cracow.PL.EU.Kewl.Org 1
Mailto: swierk_at_nospam_student.uci.agh.edu.pl 2
PGP finger: swierk_at_nospam_student.uci.agh.edu.pl 3
WWW : http://ibm.uci.agh.edu.pl/~swierk 4 :-)
From: amart_at_nospam_pol.JUNKMAILPROTECTION.pl (Jaroslaw Cichorski Jr.)
Subject: Re: 8051
Date: Wed, 25 Mar 1998 09:05:39 GMT
Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl> wrote:
In pl.misc.elektronika Jaroslaw Cichorski Jr. <amart_at_nospam_pol.JUNKMAILPROTECTION.pl> wrote:
A w ASM wiesz to od razu ?
Jak dobrze zoptymalizujesz to nie ma obawy, a do sekcji krytycznej
(czasowo) zawsze mozna zlinkowac procedure w ASM, jesli trzeba.
A zebyś wiedział, że od razu. Przecież w książce do 8051 jest podane, w ilu
cyklach wykonuje sie dany rozkaz. Można wtedy łatwo to określić.
Powiem tak kazde przegiecie jest niezdrowe.
Programowanie tylko w ASM i programowanie tylko w 'C' to dwie
skrajnosci. Trzeba umiec znalezc zloty srodek.
Napisalem w 'C' sporo aplikacji takze w real-time i dziala bez
problemow.
Gdybym to pisal w ASM to nie czytal bys tego postu, bo jeszcze bym nie
skonczyl tego co juz dawno napisalem dzieki 'C'.
Jezeli tego nie uznajesz - Twoja sprawa, ale to Ty na tym tracisz.
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
e-mail amart_at_nospam_pol.JUNKMAILPROTECTION.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: amart_at_nospam_pol.JUNKMAILPROTECTION.pl (Jaroslaw Cichorski Jr.)
Subject: Re: 8051
Date: Wed, 25 Mar 1998 09:10:16 GMT
Pawel Swirek <swierk_at_nospam_student.uci.agh.edu.pl> wrote:
In pl.misc.elektronika Jaroslaw Cichorski Jr. <amart_at_nospam_pol.JUNKMAILPROTECTION.pl> wrote:
A w ASM wiesz to od razu ?
Jak dobrze zoptymalizujesz to nie ma obawy, a do sekcji krytycznej
(czasowo) zawsze mozna zlinkowac procedure w ASM, jesli trzeba.
A zebyś wiedział, że od razu. Przecież w książce do 8051 jest podane, w ilu
cyklach wykonuje sie dany rozkaz. Można wtedy łatwo to określić.
W 'C' tez wiesz to od razu. Jak masz troche wyczucia to mozesz
przewidziec jak to kompilator skompiluje i odpowiednio napisac dany
fragment, a sekcje krytyczna mozesz zawsze napisac w ASM i zlinkowac.
Wynik kompilacji w postaci ASM zawsze mozna zobaczyc w listingu.
Zaiste powiadam Ci, ze wiele ciekawych trickow tam mozna podejrzec, a
w dobrym kompilatorze i z optymalizacja nie jest zle.
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
e-mail amart_at_nospam_pol.JUNKMAILPROTECTION.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: Waldemar Rączka <wraczka_at_nospam_uci.agh.edu.pl>
Subject: Re: 8051
Date: Wed, 25 Mar 1998 09:36:21 +0100
Maciej Gruszecki wrote:
Waldemar Rączka wrote:
Pawel Swirek wrote:
(procek w interfejsach czyjnikow inteligentnych standardu Lon
Works-programowalny tylko w C-jak widzisz czasami nie ma wyjscia...)
pozdrawiam
C nie nadaje się do aplikacji czasu rzeczywistego.
A to dlaczego sie nie nadaje ??
Bo nie wiesz do konca jak dlugi kod (czasowo) wygeneruje C.
wiesz, mozesz rzucic okiem do zbioru z wygenerowanym kodem asembera
NP. KEIL generuje taki zbior
waldek