Nimitz wrote:
> Wszyscy wiemy, że zwykły 8051 dzieli zegar przez 12, więc jakie to ma
> znaczenie dla programisty?

Np takie:
8051 - 5zł - ~1Mips.
2313 - 5zł - ~12Mips

W praktyce wygląda to tak, ze kiedy '51 liczy cykle zegara żeby mu
staczyło na przerwanie AVRowiec pisze elegancki kod w C majac zapas w
razie zmiany koncepcji.

> Porównuj 8051 12MHz z AVR 1MHz.

Nie ma potrzeby, AVR to nie średniowiecze technologiczne, da radę
więcej, naprawde. Uczciwe jest porównanie tylko takie ktore pokazuje
wlasnie ta przepaść prędkości w tej samej cenie.

> Nawet dzisiaj można sobie wyobrazić jakieś zastosowania - program może
> sam siebie modyfikować.

Zazwyczaj znikomo przydatne w poważnym kodzie - uniemożliwia tworzenie
kodu ktory np. jest w stanie pracować z cache w niektorych
konfiguracjach, utrudnia debugowanie, itd. Pisząc kod samomodyfikujący
balansujesz na krawędzi w dodatku silnie uzależniasz się od arch.

> Nie zapominajmy, że 8051 to konstrukcja lat 70, ale ciągle trzyma się
> świetnie.

Tylko tam gdzie daje z trudem radę się jeszcze utrzymać w starym
hardware. Przegrywa walkę wszędzie od ceny po wydajność ze _wszystkim_
innym co jest na rynku w tej skali.

do góry

T.M.F. pisze:

>> Każda w podanych metod wymaga wykonania przynajmniej kilku instrukcji,
>
> Tylko te kilka instrukcji dla AVRa wykona sie w czasie krotszym niz
> jedna instrukcja dla '51. Na wykonanie jednej instrukcji '51 wymaga co
> najmniej 12 taktow zegara, AVR w tym czasie zrobi 12/24 instrukcje.

nie lubię '51
gimnastyki przy pobieraniu danych z pamięci programu AVR-a też nie ;-)
ale _współczesne_ wariacje '51 już nie potrzebują 12 cykli

> Zartujesz? AVR moge taktowac zegarem 20MHz,

współczesne (jednotaktowe) '51 są też 33MHz, szybsze chyba też były
(Dallas?)

--
Pozdr.
Michał

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał w wiadomości
news:gp3pmb$nus$1@achot.icm.edu.pl...

> > Jak radzisz sobie z błędami w prockach ? Tak samo ? Może to wyjaśnia,
> > dlaczego niektórzy trzymają się 51 :)
>
> Biorę procek z poprawionym hardware.

Jak jest. Teraz są procki nie do końca stestowane i nie można powiedzieć, że
są poprawione albo nie poprawione bo czasem nawet błędy nie są
poidentyfikowane.

> W '51 nie ma się co popsuć bo ma
> dośc prymitywne bebechy

Nie, nie dlatego. PIC-e mają prymitywne bebechy a zdarzały się wpadki, tak
się niechluje śpieszyli. 51 jest po prostu stary i dlatego jest poprawiony.
Do czego dążę: zwracam uwagę, że w niektórych zastosowaniach to może być
jakiś argument.

> i wszyscy klepia go z grubsza na jedno kopyto.

Wszyscy w asm ? Akurat w przypadku 51 - wątpię. Bo jeśli chodzi o C to po
prostu producenci kompilatorów klepią wszystko na jedno kopyto i po
najmniejszej linii oporu, choć mieli jakieś 10 lat na udoskonalenia.

> Koszt wymiany AVR->ARM wynosi u mnie czas przepisania prostych driverów
> sprzetowych bo nie umoczyłem d... używając niszowego i jedynego w swoim
> rodzaju kompilatora jak to jest w przypadku '51 oblepiając go
> workaroundami na bugi w kompilacji.

Zasadniczo nie mając uprzedzeń co do żadnej z rodzin mikrokontrolerów (co
nie znaczy, że pewnych serii nie omijam szerokim łukiem) mogę powiedzieć, że
owszem, nowe rodziny bardzo sobie chwalę, używam, ale jakbym miał
argumentować na ich korzyść, to zdecydowanie temat błędów w kompilatorach
czy ogólnie błędów trapiących programistę zostawiłbym w spokoju. Byłem
zmuszony używać workaroundów w każdej rodzinie i w każdym kompilatorze
którego używałem. Kląłem na to, ale ma to i swoje plusy - po pewnym czasie
masz w miarę ustalone metody postępowania z kompletem procek-kompilator. Z
drugiej strony jeśli jakiś kompilator jest cały czas poprawiany, w pewnym
momencie przy odrobinie nieuwagi można sobie z programu działającego zrobić
niedziałający zamiast odwrotnie :)

> Mam pewien kod kompilujący się do AVR, ARM i PC (Linux + Windows). Tylko
> tak mogę go testować. Jestem przekonany że dodanie <wsadź tu arch
> supportowany przez gcc> kosztowalo by mnie popołudnie roboty - musze
> napisac tylko drivery do timerów, spi i portów.

Cóż, jest to fajne, że przenosisz kod bez grzebania w nim, ale - jak sam
zauważasz - i tak musisz grzebać gdzieś obok i z tym popołudniem to różnie
może być :). Kompilatory ani język C sam w sobie nie rozwiązują w cudowny
sposób nawet drobnych hardware'owych różnic między prockami. Nie wszystko
przewidzisz.

e.

do góry

entroper wrote:
>>>Jak radzisz sobie z błędami w prockach ? Tak samo ? Może to wyjaśnia,
>>>dlaczego niektórzy trzymają się 51 :)
>>Biorę procek z poprawionym hardware.
> Jak jest.

Zazwyczaj jest. Od tego jest faza prototypowania żeby ustalić arch po
dogłębnym przetestowaniu. Nie ma na to czasu ? Cóż, twoje ryzyko. Nikt
nie obiecuje gładkiego postepu.

>>i wszyscy klepia go z grubsza na jedno kopyto.
> Wszyscy w asm ?

Nie, wszyscy klepiący podstawowe hardware '51 robią to tak samo wiec CPU
wszelkie bugi ma znalezione, poprawione i działa. Problem w tym, ze to
dośc prymitywny procesor jest i jesli chcesz jakiś bardziej wypasiona
wersje to wdepniesz w to samo co u innych - bugi, niedorobiki, itd.

> zmuszony używać workaroundów w każdej rodzinie i w każdym kompilatorze
> którego używałem.

Jednak cała przyjemnośc polega na tym, ze jesli jakis arch jest źle
supportowany to zmieniam arch. Na kompletnie inny. Kod pozostaje bez
rewolucyjnych zmian.

> może być :). Kompilatory ani język C sam w sobie nie rozwiązują w cudowny
> sposób nawet drobnych hardware'owych różnic między prockami.

Do tego jest abstrakcja sprzetu w programie. Jesli masz doswiadczenia z
4 rodzinami CPU to raczej jestes w stanie przewidzieć 3 inne
przynajmniej tak aby nie popełniać szkolnych błędow w projekcie. W
gruncie rzeczy podstawowe hardware wygląda bardzo podobnie.

> Nie wszystko
> przewidzisz.

To refaktoruje. Różnica polega na tym ze w ogóle mogę mając w ręku ten
sam kompilator na wiele różnych arch.

W gruncie rzeczy '51 byla by czasami ok o ile miala by gcc. Nie stac
mnie na implementowanie w jakimś specjalnym kompilatorze tego samego
algorytmu co dla 30 innych arch.

do góry

Michał Baszyński pisze:
> T.M.F. pisze:
>
>>> Każda w podanych metod wymaga wykonania przynajmniej kilku instrukcji,
>> Tylko te kilka instrukcji dla AVRa wykona sie w czasie krotszym niz
>> jedna instrukcja dla '51. Na wykonanie jednej instrukcji '51 wymaga co
>> najmniej 12 taktow zegara, AVR w tym czasie zrobi 12/24 instrukcje.
>
> nie lubię '51
> gimnastyki przy pobieraniu danych z pamięci programu AVR-a też nie ;-)
> ale _współczesne_ wariacje '51 już nie potrzebują 12 cykli

To prawda, ale za to masz jednoczesnie 64kB FLASH i 64kB SRAM i ciagle
uzywasz tylko 16-bitowego wskaznika. Jest to pewien zysk, szczegolnie
przy operacjach arytmetycznych na wskaznikach. Programujac w c/c++
mozesz tej niewygoty praktycznie niezauwazyc.

>> Zartujesz? AVR moge taktowac zegarem 20MHz,
>
> współczesne (jednotaktowe) '51 są też 33MHz, szybsze chyba też były
> (Dallas?)

Nawet przy skroceniu ilosci cykli do 3 (a ile instrukcji '51 jest
jednocyklowych?) to daje nam ledwie 11 MIPS, dla AVR mamy 16-32MIPS w
zaleznosci od wersji, w dodatku przy co najmniej 3x wolniejszym zegarze,
co jest nie bez znaczenia dla peryferii (np. zewnetrzny latch do pamieci).

do góry

T.M.F. pisze:

> Nawet przy skroceniu ilosci cykli do 3 (a ile instrukcji '51 jest
> jednocyklowych?) to daje nam ledwie 11 MIPS, dla AVR mamy 16-32MIPS w
> zaleznosci od wersji, w dodatku przy co najmniej 3x wolniejszym zegarze,
> co jest nie bez znaczenia dla peryferii (np. zewnetrzny latch do pamieci).

'51 używam bardzo rzadko, najchętniej wcale bym nie używał, ale najpierw
bardzo poproszę o AVR-a z porównywalnym ADC jak w MSC1210 TI albo serii
ADUC Analoga.. ;-)

--
Pozdr.
Michał

do góry

Michał Baszyński pisze:
> T.M.F. pisze:
>
>> Nawet przy skroceniu ilosci cykli do 3 (a ile instrukcji '51 jest
>> jednocyklowych?) to daje nam ledwie 11 MIPS, dla AVR mamy 16-32MIPS w
>> zaleznosci od wersji, w dodatku przy co najmniej 3x wolniejszym zegarze,
>> co jest nie bez znaczenia dla peryferii (np. zewnetrzny latch do pamieci).
>
> '51 używam bardzo rzadko, najchętniej wcale bym nie używał, ale najpierw
> bardzo poproszę o AVR-a z porównywalnym ADC jak w MSC1210 TI albo serii
> ADUC Analoga.. ;-)
>
Chcesz porzadny ADC to zastosuj zewnetrzny ;P

Ale idac tym tropem - pokaz mi '51 ktora ma drivery do LCD, interfejs do
SDRAM, wbudowane DMA, albo sprzetowe RSA?

do góry

T.M.F. pisze:

> A podasz jakis przyklad w ktorym priorytety przerwan sa niezbedne?

Wtedy, gdy chcesz decydować, _które_ przerwania mogą przerywać inne. W
starych AVR możesz odblokować wszystkie, albo żadne.

> Zawsze moge w pierwszej instrukcji odblokowac przerwania

Aha, spróbuj to zrobić w przypadku UARTa.

do góry

T.M.F. pisze:

> Ale idac tym tropem - pokaz mi '51 ktora ma .. wbudowane DMA?

ADUC 816?
albo AVR-a z USB z trybem High-Speed ? ;-)
Nie ma jednej rodziny uC, która byłaby dobra do wszystkiego i uważam, że
uC powinien być dobrany do konkretnych potrzeb.

--
Pozdr.
Michał

do góry

Michał Baszyński pisze:
> T.M.F. pisze:
>
>> Ale idac tym tropem - pokaz mi '51 ktora ma .. wbudowane DMA?
>
> ADUC 816?
> albo AVR-a z USB z trybem High-Speed ? ;-)

AVR z USB HS sa dostepne.
Masz '51 z wireless?:)

> Nie ma jednej rodziny uC, która byłaby dobra do wszystkiego i uważam, że
> uC powinien być dobrany do konkretnych potrzeb.

To z pewnoscia. Tyle, ze trudno wskazac do czego dobre sa '51 :)

do góry