51

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.

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

8-bitowych i umieszczającą wynik w trzecim miejscu pamięci

- 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)

3,40 zł, AVR 20-nóżkowy ATtiny2313 6,10 zł (przykładowe ceny w Seguro); najtańsza '51 czyli AT89C2051 (trzeba ją wyciągać z płytki w celu przeprogramowania) to 5,36 zł

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ł:

[..] [ciach]

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

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...

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"

Oczywiście przy bardziej zaawansowanych architekturach (np. ARM) optymalizer ma duże pole do popisu i nigdy nie wiadomo, co wymyśli. Ale zwykle wymyśla optymalniej, niż ja. :) Staram się zawsze jak najmniej wstawek robić w asemblerze. Nigdy nie wiadomo, czy z mało skomplikowanego projektu pisanego np. na ATmega8 nie zrobi się z czasem większy, wymagający przejścia np. na AT91SAM7S64 (z powodu np. niewydolności obliczeń i wymaganego interfejsu USB).

AlexY napisał(a):

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

Co ciekawe, AVR plasuje się tuż obok Thumb(ARM).

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.

BTW: Nie chwaląc się, zaprojektowaliśmy większość urządzeń kryptograficznych certyfikowanych w Polsce: