Mikrokontrolery ATMEL dla początkujących: Książki, zestawy i zasoby do automatyki domowej

Mon Mar 09, 2009 5:50 pm   

Użytkownik "T.M.F.":

Każda w podanych metod wymaga wykonania przynajmniej kilku instrukcji, więc
może się okazać, że krótki impuls może zostać albo zgubiony, albo zmierzony
z dużym błędem, a więc - 8051 nadal górą!
Dodam jeszcze, że w 8051 można (przez mały trick) wykonać program z
zewnętrznej pamięci RAM, co kiedyś miało bardzo duży walor edukacyjny.
Czasem także przydaję się dwupoziomowy priorytet przerwań. Asembler też jest
łatwiejszy niż w AVRach. A jeśli chodzi o C to zauważyłem, że Keil 8051
potrafi skompilować krótszy kod niż GCC AVR. Oczywiście AVR są fajne i mają
wiele zalet, ale jeśli chodzi o rdzeń to osobiście wolałbym architekturę
6502 ;-)

Admirał

Mon Mar 09, 2009 6:15 pm   

Hello Sebastian,

Monday, March 9, 2009, 4:45:12 PM, you wrote:


Z NTG - sio na pl.comp.os.advocacy

--
Best regards,
RoMan mailto:roman@pik-net.pl
Spam: http://www.squadack.na.allegro.pl/

Mon Mar 09, 2009 6:35 pm   

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.
Inna sprawa, ze w podanych metodach jedyne co musisz zrobic to odczytac
zawartosc 8/16 bitowego rejestru, czyli dokladnie tyle samo co w '51, bo
przeciez jakos wynik musisz odczytac, prawda?


Zartujesz? AVR moge taktowac zegarem 20MHz, minimalny czas trawania
impulsu dla tego wariantu to 100ns, zadna '51 nie odczyta portu z taka
rozdzielczoscia. A XMega maja juz taktowanie 32MHz/32 MIPSy.


A jaki ma to walor praktyczny? To moze bylo ciekawostka w czasach kiedy
nie bylo programowalnych FLASHy.


Znowu sobie zartujesz. Porownujesz regularna liste rozkazow AVR z
potworkiem '51?


Nie jest to dziwne biorac pod uwage, ze gcc jest portowany z duzych
prockow i np. nie obsluguje modeli pamieci, co jest problemem przy
duzych AVRach, bo wymaga uzycia 32-wskaznikow (gcc nie supportuje
wskaznikow 24-bitowych).
Podobnie obsluga arhitektury harwardzkiej przez gcc to tylko proteza, bo
ten kompilator nigdy do takiej arhitektury nie byl projektowany.
Jak chcesz porownywac to porownuj podobny kompilator na '51 i AVR,
zdziwisz sie. Lista rozkazow AVR byla projektowana z mysla o kompilatorze c.

Mon Mar 09, 2009 6:42 pm   

Użytkownik "Nimitz" <Nimitz@onet.eu> napisał w wiadomości
news:gp3htg$dgs$1@nemesis.news.neostrada.pl...

Mocne

Mon Mar 09, 2009 7:11 pm   

Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał w wiadomości
news:gp0g1h$1ih$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 :)

e.

Mon Mar 09, 2009 7:13 pm   

Użytkownik "T.M.F." :

Wszyscy wiemy, że zwykły 8051 dzieli zegar przez 12, więc jakie to ma
znaczenie dla programisty? Porównuj 8051 12MHz z AVR 1MHz. Owszem, w
konsekwencji możemy uzyskać znacznie szybszy AVR, ale do rzetelnego
porównania muszą być zachowane podobne warunki.


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


Mam uraz do stałych w AVR. A o priorytecie przerwań niczego nie napiszesz?
;-)

Nie zapominajmy, że 8051 to konstrukcja lat 70, ale ciągle trzyma się
świetnie. AVR to jeden producent, dzisiaj jest, jutro może nie być.

Admirał.

Mon Mar 09, 2009 7:35 pm   

To jest rzetelne porownanie. Masz jakas '51 z ktorej wycisniesz 20-30
MIPSow? Co procesor robi wewnetrznie nic mnie nie interesuje, moga tam
mawet byc krasnoludki, mnie interesuje (w tym wypadku) mozliwy do
uzyskania czas odpowiedzi. Napisales oczywista bzdure, ze AVR moze
zgubic impuls, ktory '51 zmierzy.
Nie znam za dobrze '51, ale patrzac na przyklad timerow z linka, ktory
podales to w porownaniu z timerami w AVR sa one wrecz prymitywne.


Tyle, ze jest to malo zgodne z dobra praktyka programowania i bardzo
trudne do zaimplementowania w jezyku wyzszego poziomu. Mozna to
potraktowac jako ciekawostke, bez znaczenia. Chyba, ze znasz jakis
przyklad gdzie taki feature jest niezbedny/ulatwia zycie. Poprosze o
przyklad.


A podasz jakis przyklad w ktorym priorytety przerwan sa niezbedne?
Zawsze moge w pierwszej instrukcji odblokowac przerwania, co przy
predkosci AVRa spowoduje, ze bede gotowy na jego przyjecie zanim uklad
przerwan w '51 zdecyduje co zrobic z pierwszym.


Podobnie jak PIC i kilka innych niszowych procesorow.
Nawet jesli Atmel by padl to przeciez ich patenty/technologia nie
znikna. Jest rynek to ktos bedzie to kontynuowal.

Mon Mar 09, 2009 7:43 pm   

Swoją drogą są 51 które dzielą zegar na 3.

Takie porównania nie mają najmniejszego sensu!!!. Co za różnica jaki kwarc
się podczepi, nie ma pomiędzy nimi w zasadzie różnicy - kwarce kosztują tyle
samo i
tyle samo miejsca zajmują. Podczepiasz taki jaki potrzebujesz.

To co można porównać to maksymalną moc obliczeniową przy max zegarze,
albo np który ma mniejszy pobór prądy przy realizacji tego samego zadania,
albo mniej kosztują dla realizacji tego samego zadania, a i tu też nie ma
tylko
jednych 51 bo jest ich cała masa w zależności od zadania wyjdzie co innego.

Ja kiedyś używałem taką 51 co miała w środku także kawałek logiki
programowalnej - jak chcecie to z AVRem porównać albo inną 51 ? - tam można
było
sobie trochę obwodów I/O dorobić według potrzeb.

Co za różnica co za procek stosujecie - układ ma działać!



Całkowicie kierunek bez sensu - tak się nie robi, co innego dynamicznie
ładowane
kawałki a co innego modyfikowanie kodu.


Oba to już historia ale stosuje się je bo działają a to najważniejsze.


zbyszek

Mon Mar 09, 2009 8:12 pm   

entroper wrote:

Biorę procek z poprawionym hardware. W '51 nie ma się co popsuć bo ma
dośc prymitywne bebechy i wszyscy klepia go z grubsza na jedno kopyto.
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.

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.

Mon Mar 09, 2009 8:15 pm   

zbyszek pisze:

Owszem. Problem powstaje tylko jesli juz nie mozna podczepic wiekszego
kwarcu, a mocy ciagle brakuje. No i obwod na 40MHz to nie to samo co
obwod na 10MHz. Znasz jakas '51, ktora ma 20-30MIPSow? Jak jest
taktowana 90-360MHz?


Podobnie jak w przypadku AVR.


Sa AVRy z FPGA, nazywa sie to FPSLIC.


Dokladnie. A zwazywszy na ilosc i jakosc narzedzi szybciej zadziala na
AVR niz na '51.

Mon Mar 09, 2009 8:28 pm   

Nimitz wrote:

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.


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.


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.


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.

Mon Mar 09, 2009 9:15 pm   

T.M.F. pisze:


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


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

--
Pozdr.
Michał

Mon Mar 09, 2009 9:27 pm   

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


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.


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.


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.


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


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.

Mon Mar 09, 2009 9:32 pm   

entroper wrote:

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.


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.


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.


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.


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.

Mon Mar 09, 2009 9:38 pm   

Michał Baszyński pisze:

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.


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