51

Kiedy¶ troszkê _próbowa³em_ siê bawiæ elektronik± cyfrow± i eksperymentowaæ z 80C51 - bardzo mi siê to podoba³o i dlatego z ciekawo¶ci pytam, co takiego jest z³ego w architekturze 51 ? Bo o ile sam pamiêtam, to by³a do¶æ klarowna i ³atwa do implementacji urz±dzeñ na tym procku...

Jestem programist±, a nie elektronikiem, wiêc proszê o odpowied¼ w miarê mo¿liwo¶ci ³opatologiczn±...

Bardzo zlego to w zasadzie nic, ale inne sa lepsze. Nie ma 12 cykli na rozkaz, nie ma trzech pamieci sprawiajacych klopoty w jezykach lepszych niz assembler, architektura ulatwiajaca operowanie na liczbach wiekszych niz 256, timery lepiej dostosowane do typowych zadan, wiecej peryferii itp.. to jest jednak malutki procek sprzed 25 lat ..

J.

No i do malutkich zastosowañ najlepiej siê IMHO nadaje.

Z mojego, programistyczno-biznesowego punktu widzenia, do zastosowañ wiêkszych nie ma sensu u¿ywaæ lepszych procków zintegrowanych, gdy¿ zbyt drogo kosztuje stworzenie softu do takich uk³adów. Lepiej po prostu wstawiæ x86.

Domy¶lam siê, ¿e moje podej¶cie jest w wielu sytuacjach do obalenia i w³a¶nie chcia³bym poznaæ powody, dla których jednak warto siê w te procki bawiæ.

U¿ytkownik "BLE_Maciek":

A jak AVRem zmierzyc krotki czas wypelnienia sygnalu (z wyeliminowaniem przypadkowego niewykrycia zdarzenia) tak jak to mozna zrobic na 8051 wykorzystujac zewnetrzne sterowanie wlaczaniem i wylaczaniem licznia (GATE=1 z rejestru TMOD) ? Oczywiscie przy porownywalnych zegarach, czyli dla kwarcu stosunek 12:1 dla

Heliogabal

W dniu 15-11-2006 22:57, Adam Dybkowski napisał:

Jakie złe nawyki masz na myśli?

Any User napisał(a):

Wszystko zależy od tego, co rozumiesz pod pojęciem "większych zastosowań". W firmie z powodzeniem stosujemy przeróżne ARMy (ostatnio AT91SAM9261) do całkiem niemałych urządzeń (w sensie komplikacji projektu a nie rozmiaru PCB). Mamy swój własny system operacyjny czasu rzeczywistego, sprawdzający się dobrze przy naszych potrzebach (nad średnim projektem pracuje równolegle kilku programistów a kod źródłowy całości ma kilka MB plików .c i .h). Wykorzystanie czegokolwiek z rodziny x86 skomplikowałoby mocno projekt - trzeba by użyć jakiś chipset "pecetowy", co wpłynie na stopień złożoności i rozmiar PCB. Jak dotąd w naszych urządzeniach wystarczało kilka MB pamięci RAM a cały wynikowy kod binarny mieścił się w 1-2MB Flash'a.

Krzysiek napisał(a):

Znając w miarę dobrze AVRy i ARMy dużo niemiłego mogę powiedzieć na temat architektury '51:

- jeden akumulator, przez którego trzeba ciągle przepychać nawet najprostsze operacje

- jeden rejestr wskaźnikowy 16-bitowy DPTR (proste skopiowanie bloku pamięci staje się koszmarem; 2 pary DPTR w niektórych '51 to już całkiem nieporozumienie); a wyobraź sobie prostą funkcję dodającą 2 bloki liczb

- rozdzielone przestrzenie adresowe, chociaż niekiedy mające dużo zalet (np. w DSP'kach) to generujące często problemy - np. jak załadować do RAMu kod i go uruchomić (konieczne sztuczki z bramkami na zewnątrz procesora itp. obejścia)

- ograniczone do 16 bitów adresowanie (nawet w AVR'ach można mieć 256KB Flash'a), to oczywiście nie ma znaczenia przy super małych projektach

- 12 cykli zegara na najprostszego NOP'a, a co za tym idzie - UART działający na 115200 bps wymaga zegara 22,1184 MHz, dla porównania w procesorze AVR wymagany zegar tylko 1,8432 MHz

- brak programowania w systemie w większości '51 (BTW: chwała Atmelowi za serię AT89S)

- asembler kompletnie niedopasowany do potrzeb programów pisanych w C

- ceny średnio atrakcyjne biorąc pod uwagę wydajność i pobór prądu, nawet w najprostszych zastosowaniach: najmniejsza '51 programowana w systemie czyli AT89S2051 kosztuje 7,80 zł; najmniejszy AVR (ATtiny13)

Całkiem niezależnie mogę się rozwodzić nad zaletami architektury ARM, ale tu już o tym pisałem i można znaleźć w archiwum. A najmniejszy sensowny ARM (AT91SAM7S64) kosztuje 24,40 zł i bije na głowę wydajnością i możliwościami nawet znacznie droższe '51 czy AVRy.

Użytkownik Adam Dybkowski napisał:

To mi zabrzmialo jak zwalanie winy za brak umiejetnosci na sprzet, od jakiegos czasu jest taka tendencja ze dopasowuje sie sprzet do potrzeb programu a nie odwrotnie, a programy pisane sa w coraz bardziej pogietych jezykach sluzacych tylko do napedzania rynku sprzetowo-programistycznego. Kiedys w kilku kB kodu byly rozbudowane dema i programy, ludzie po prostu umieli pisac dobre szybkie i male programy, teraz to samo w wybajerzonej oprawie graficznej zajmuje dziesiatki MB

Eeee, to moje projekty by³y oparte na 80C51, 27C64 i 1-4x 62256 - jak wiêc widzisz, nieco mniejsza klasa zastosowañ :)

A mo¿esz napisaæ, do czego mniej wiêcej je stosujecie? Tak z ciekawo¶ci pytam, gdy¿ chcê ogarn±æ, do czego mo¿na tworzyæ w³asny RTOS na dziwny procek, zamiast kupiæ co¶ gotowego...

J.F. napisa³:

Ale wykonuje pojedyncz± instrukcjê w 10 ns !, co od 2 lat z powodzeniem wykorzystujê (mikrokontroler C8051F121 Cygnala - obecnie Silicon Labs).

"Adam Dybkowski" napisa³ :

W DS80C400 s± cztery DPTR 24 bitowe (z mo¿liwo¶ci± autoinkrementacji i autodekrementacji przy niektórych instrukcjach).

DS80C400 ma adresowanie 24 bitowe w przestrzeni ci±g³ej (RAM i FLASH).

W DS80C400 4 cykle.

Na szczê¶cie w DS80C400 jest - bez tego bym ca³kiem osiwia³, pracuj±c na nim od 4 lat.

Jeszcze pytanie ile on, oraz ten cygnal, kosztuja, i czemu drozej niz ARM :-)

J.

ciach

No ale badzmy sprawiedliwi to architektura z 1980 roku - wtedy nie uzywano C do programowania uC, uC realizowaly znacznie mniejszy zbior funkcji... A ARM ma tez swoje wady i nie jest panaceum na wszystkie problemy... Nie osadzajmy 51 zbyt surowo - mimo uplywu czasem to dalej atrakcyjna platforma chocby ze wzgledu na stabilnosc i przewidywalnosc...

A mnie to zabrzmia³o jak fakt, ¿e nigdy nie programowa³e¶ tej pogiêtej architektury. Potwierdzam wszystko, co na jej temat napisa³ Adam.

Pozdrawiam Piotr Wyderski

Prze³±czane inkrementacj± selektora?

Czyli je¶li masz bardzo szybki jak na mikrokontroler zegar 48MHz (USB), to osi±gniesz na nim zaledwie 12 MIPS, i to jeszcze tych u³omnych instrukcji '51, wymagaj±cych skomplikowanych sekwencji rozkazów do zrobienia podstawowych rzeczy. Inne rodziny nie maj± tych problemów (jedna instrukcja na cykl, wiêcej rejestrów) i s± na nie dostêpne porz±dne darmowe kompilatory (GCC) -- po co wiêc sobie utrudniaæ ¿ycie?

Pozdrawiam Piotr Wyderski

Wiêc pytanie brzmi: CO ONA TU JESZCZE ROBI?! Wnios³a swój wk³ad w rozwój elektroniki, ale jej czas ju¿ dawno min±³. Jednak z jakich¶ dziwnych powodów wiele firm dok³ada ten rdzeñ jako kontroler nowoczesnych peryferiów -- na przyk³ad dzia³aj±cy na pó³ gigaherca FX2 daj±cy rewelacyjne mo¿liwo¶ci sprzêgania elektroniki z PC przez USB2.0 jest nadzorowany przez 48MHz rdzeñ '51.

Podaj proszê te powody atrakcyjno¶ci, bo ja widzê same wady. Nawet atrakcyjnego kompilatora C na nie nie ma

-- Keil jest drogi, a SDCC jest ¿a³osny. Natomiast co do przewidywalno¶ci, to w przypadku innych architektur jest ona co najmniej taka sama.

Pozdrawiam Piotr Wyderski

AlexY napisał(a):

Akurat czysty język C uważam za najlepszy do programowania blisko związanego ze sprzętem. Dobrze znając kompilator i architekturę procesora AVR, pisząc program C już praktycznie wiesz, co z tego wyjdzie w asemblerze. I bardzo często byś tego samego w 100% pure ASM optymalniej nie napisał.

Mówiąc w skrócie: pisząc program w C, oszczędzasz sporo czasu a kod wynikowy jest praktycznie tak samo optymalny jak pisany prosto w ASM. Uwaga: nie dotyczy to najmniejszych procesorków o małej pamięci (Flash i RAM), gdy liczy się każdy bajt Flasha albo cykl pracy procesora.

Radzę spojrzeć na porównanie architektur '51 i AVR. To oczywiście reklama Atmela, ale właściwe wnioski można samemu wyciągnąć: "The AVR Microcontroller and C Compiler Co-Design"

AlexY napisał(a):

BTW: Jeszcze jedno porównanie małych procków, tym razem pod kątem rozmiaru typowej implementacji kilku algorytmów:

Any User napisał(a):

Ostatnio głównie w szyfrujących urządzeniach telekomunikacyjnych - telefony na linie analogowe, ISDN, centralki ISDN BRI, karty centralowe ADSL. Robiliśmy też urządzenia pomiarowe z ARMem na pokładzie. Ten sam system (okrojony) mamy oprócz ARMa przeniesiony na AVRy i DSP Texasa.