Sytuacja na rynku procesorów 8 i 32 bitowych

Question

Dla mnie z kolei największą wadą PICów jest ich mała moc obliczeniowa i prosty assembler (ta prostota to podobno zaleta ale nie dla mnie).Większości...

UDMA · Accepted Answer

AVR 16MIPS, PIC18 12MIPS - żadna różnica w praktyce. Dodatkowo PIC robi mnożenie 8x8->16 w 1 cyklu, AVR w dwóch:) W mojej opinii wszystkie 8-bitowce to złom w porównaniu do cacek z rdzeniem ARM Cortex-M0, M3 czy M4.

tmf · Accepted Answer

Trochę się mylisz kolego - 16MIPS to miały staruteńkie AVRy, nowe mają 20MIPS (przy założeniu MIPS/MHz) lub 32 - seria XMega. Dodatkowo XMega mają 4 kanały DMA, co znakomicie odciąża procesor. A to wszystko za niewielką cenę. A jak ktoś potrzebuje procka startującego przy niskim napięciu to są ATTiny z wbudowaną przetwornicą, działające od 0,9V.
No i porównując dostępny soft - kompilatory, IDE itd. to dla hobbysty wybór jest oczywisty - AVR. Po co mam płacić za coś, albo używać z ograniczeniami, skoro mam full wersje za darmo?

trol.six · Accepted Answer

Żadne tam cacko. Amd64 robi nawet operacje 128 bitowe (SSE3), w dość przystępnych czasach. Tylko na co mi takie cacko do programu co ma raptem 400 linii? Każdy projekt ma inne założenia. Z tego co widze czasem lepiej sprawdzi sie PIC czasem AVR.O PICach myślałem od dawna, jednak trzeba rzeczywiście przestać tylko myśleć.

mirekk36 · Accepted Answer

atom1477 --> dobrze napisał

ja już nie chciałem wkładać kija w mrowisko ale dokładnie mam takie same odczucia z tymi prędkościami - ZAZNACZAM porównywalnych procków serii AVR i PIC (Nie mówię o żadnych ARM'ach i DSPIC'ach a nawet XMEGACH).

16 czy 20 MIPS a 12MIPS to w praktyce żadna różnica? wolne żarty. Ale już nawet to nie ważne bo przesiadki na dowolny AVRek z innego AVRka to poezja a już w samych PIC'ach staje się to masakrą - już choćby ze względu na długość słowa , inne kompilatory itd.

Odnośnie jeszcze tych gimnazjalistów .... ja akurat sam prowadzę własną firmę i liczę każdy grosz. Robię sporo układów i sterowników różnych na sprzedaż i jak na razie tylko na AVRkach. Nie muszę wydawać kasy na różnorakie środowiska czy dziwne programatory.

Jak ktoś pisze że 8-bitowce to złom, to chyba ma dosyć wąskie pojęcie o możliwościach samych procków , o praktyce programowania, o rzeczywistości i o zarabianiu. Śmierć 8-bitowców to już miliony ludzi wróżyło odkąd pojawiły się ARMy i inne tego typu procki (skąd innąd super do pewnych zastosowań)

Ale jak ktoś majcy klapki na oczach pcha ARMa TQFP milion pinów, megabajty pamięci różnorakich, - do sterownika, który można zbudować na ATtiny13 czy na ATmega8 to , to już zaczyna być chore niestety. Dokładnie tak jak powiedział trol.six - można by równie dobrze do sterownika akwarium zastosować np Intel Core DUO albo jakiego AMD Athlona64 - bo po co ARMy - takie powolne hyhyhyhyhy

Dołącz do Kursu C dla mikrokontrolerów - zajrzyj na stronę i zapisz się !
https://akademia.atnel.pl nauczysz się programować w języku C

Selling:
13.11.2007 Wyświetlacz PLED(OLED) 2x16 WINSTAR WPI1602B-Y-JCS

voland · Accepted Answer

No więc właśnie... wielką zaletą AVR jest ich jednolitość, jeśli możesz napisać program na Mega8 to z tym samym hardware i software i wiedzą możesz tworzyć aplikacje na wszystkich innych AVR. Jeśli ktoś twierdzi że 8bit AVR to przeżytek bo są army to oznacza że potrafi programować tylko army a za 8bit się nie bierze bo mus się nie chce i uzasadnia to lenistwo bezsensowością istnienia 8bitowej platformy. Przecież wiadomo że jak ktoś realizuje np. projekt seryjnie produkowanego sterownika realizującego jakąś funkcje logiczną to poco 32bitowa architektura(ATtiny rules). Oczywiście jak ktoś umie programować tylko PLC to zrobi sterowanie na s7-200 za kila stów.

Freddie Chopin · Accepted Answer

Oczywiście... Tyle że jak ten ARM kosztuje kilka złotych, na płytce wymaga wielu elementów mniej (np nie trzeba kwarcu, żeby działał z DUŻĄ i DOWOLNĄ prędkością), ma 100x więcej układów peryferyjnych, a pisanie programów jest 100x prostsze, to... sorry, ale pchanie na siłę wszędzie AVRa ("bo się przecież wyrobi!") jest właśnie "chore"...

Argument o obudowach "TQFP milion pinów" - nietrafiony - faktycznie, najmniejszy dostępny w ludzkich obudowach to LQFP-48, ale... ATmega 16 ma obudowę o TEJ SAMEJ POWIERZCHNI, więc... ?

Jak dla mnie zastosowanie AVR jest tylko wtedy gdy można użyć procka który kosztuje mniej niż 10zł (a więc ATmega 8 albo 16), powyżej tego nawet nie ma się co zastanawiać, skoro za kilkanaście zł jest ARM...

Z waszej perspektywy pakowanie 32-bitów wszędzie gdzie się da jest głupie. Z naszej zaś, pakowanie 8-bitów wszędzie gdzie się da wygląda podobnie [;

4\/3!!

See also:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

voland · Accepted Answer

Nie pisałem, że wszędzie gdzie się da, wiadomo że atmega128 nie ma szans z popularnymi armami i jest tylko dla maniaków AVR, ale tak jak pisałeś tam gdzie trzeba zastosować proste algorytmy użycie arma jest przewymiarowaniem. Sam piszę systemy na AVR8 i ARM. Poza tym pisanie na ARM nie jest wcale łatwiejsze wręcz przeciwnie... przynajmniej nie jeśli chcesz się opierać tylko na narzędziach GNU, nie znam komercyjnych środowisk.

janbernat · Accepted Answer

No ale jakie są ceny za 1k elementów u producenta?
Bo my to jesteśmy "pasożyty".
Jak jakiś producent chce zwiększyć sprzedaż- to daje darmowe wsparcie.
Jeśli to wymaga wiedzy u kupca- programisty np. -to to się opłaci po paru latach.
Dostanie na uczelni albo wręcz do domu darmowe środowisko- no to go mają.
Jak jakaś firma robi miliony elementów- to w zasadzie czy to będzie NE555 czy procesor to koszt dystrybucji jest znaczący dla nas- a nie dla producenta.
A nie za ile w TME czy gdzieś- koszt zatrudnienia pracownika do pakowania, wysyłki, fakturowania itp.

utak3r · Accepted Answer

Tak jak przewidywałem, dyskusja dryfuje już w tym kierunku, co myślałem

Jeszcze co do nieporozumienia co do PICów - nieprawdą jest, jakoby do każdego procka trzeba było brać inny kompilator, inny programator itp. Każdy jeden robi się tym samym zestawem narzędzi.

Co do dyskusji o dobieraniu odpowiedniej skali... dla mnie w tej chwili procek 8-bitowy jest ok, jeśli kosztuje < 20zł. Jako hobbysta bez zaplecza sprzętowego, dochodzi tutaj jeszcze problem samej obudowy, gdyż sam mogę polutować tylko przewlekane i SOICa ewentualnie. Ale, do projektów firmowych, gdzie wytworzeniem płytki zajmują się ludzie od tego... w tej chwili większość moich produkcji firmowych to ARMy, z wyjątkiem jakichś rzeczywiście malutkich układów, typu sterownik jakiegoś tam czujnika czy serwa.

Słówko o środowisku do ARMów... akurat to jest tak: jeśli na jakąś platformę jest gcc i gdb - to nic innego nie potrzeba, bo to jest imho najlepszy kompilator - i tyle. A widziałem ich naprawdę dużo, to mój zawód. Więc ten zarzut jest kompletnie nietrafiony.

A wybór AVR - PIC... tak naprawdę kwestia przyzwyczajenia. Można tutaj przytaczać z obu stron różnorakie argumenty - a i tak nikt nikogo nie przekona. Moim zdaniem PICe są lepsze, kto inny sądzi inaczej. I tak już zostanie, więc nie ma sensu toczyć tej rozmowy...

tmf · Accepted Answer

No bez przesady. Programuje się go akurat trudniej, przecież masz różne tryby 16 i 32 bitowe, złożone adresacje itd. Co do układów peryferyjnych to po co mi procesor, który ma ich 100x więcej, skoro mogę dobrać procesor tak, żeby miał te, które wykorzystuje? AVRy też nie wymagają kwarcu i nowsze dzięki prescalerowi, a wszystkie dzięki OSCCAL mogą działać też praktycznie z dowolnym zegarem. Co oczywiście nie znaczy, że są lepsze od ARMów, są po prostu inne. Myślę, że zastosowania 8-bitowców i 16/32-bitowców nie do końca się pokrywają, więc pisanie co jest lepsze jest bez sensu.Z drugiej strony jeśli ktoś ma awersje do 8-bitowców to ma przecież AVR32 - poważny procesorek, lub całą rodzinę UC3 - też 32-bitowe procesory, ale uproszczone. Analogicznie jak ARMy mają różne bajery, typu USB, ethernet itd. za przystępną cenę. A zaleta jest taka, że można je programować i debuggować tymi samymi narzędziami co 8-bitowe AVRy, w tym samym środowisku (Eclipse) i za pomocą tego samego kompilatora - gcc. Czyli przesiadka jest bezbolesna.

Freddie Chopin · Accepted Answer

A co mnie to obchodzi pisząc w C albo C++? Nic. Programuje się to prościej, m.in. dlatego że jak chce mieć stałą we flashu, to piszę "const" i już, a nie niekończące się zabawy z PROGMEM i wszystkie związane z tym problemy (różny sposób odczytu RAM i ROM, niemożność stworzenia uniwersalnych funkcji przyjmujących wskaźnik na coś, ładowanie do RAM stałych napisowych włączonych do kodu, vtable w RAM, ...). W assemblerze zresztą też jest łatwiej... Pozatym prostota programowania polega na tym, że jak chcę podzielić sobie dwie liczby typu double, to po prostu to robię, a nie kombinuję przez 3 dni jak tu uniknąć takich operacji, bo się AVR "nie wyrobi". Pomijając już nawet to, że w avr-gcc dla 8-bitowych układów nie ma liczb typu double...Tylko co to za różnica, jak w jeden i drugi kosztuje tyle samo?Tak? To powiedz jak puścić ATmegę 16 na 16MHz bez kwarcu i zewnętrznego zegara. Albo jak ustawić ATmega8 na dowolną, ściśle określoną częstotliwość BEZ długotrwałego procesu kalibracji. Albo jak zmienić tą prędkość podczas pracy programowo?Zgadza się, ale to nie ja zacząłem, ani nie zmuszałem Cię do kontynuowania <;Mają też jedną poważną wadę (poza okrutnie [!] wysoką ceną) - nie są ARMem [; . Jeśli ktokolwiek nie wierzy w całkowitą dominację architektury ARM, to niestety jest w błędzie. Dlaczego to problem? Jak zrobisz coś na tym procku, a firma Atmel upadnie, to przeprojektowywujesz WSZYSTKO. Jeśli analogiczna sytuacja zdarzy się projektowi korzystającemu z rdzenia ARM, to po pierwsze są inne firmy które produkują takie procki, po drugie można sobie taki wyprodukować (lub zaimplementować w FPGA) samemu (wystarczy zakupić licencję od firmy ARM), a więc przeprojektowywujesz już zdecydowanie mniej. Pozatym firma Atmel jest znana z tego, że nagle przestaje produkować popularne elementy...Dyskusja z fanboyami Atmela jest zawsze zabawna - AVRy mają przecież same zalety [; "Uderz w stół, a nożyce same się odezwą"4\/3!!

tmf · Accepted Answer

Tu mylisz upierdliwość kompilatora z wadą procesora. Są kompilatory które działają tak jak to opisałeś w przypadku ARMa. Po prostu gcc obsysa, co zreszta ma się zmienić bo powoli wchodzą named address spaces, które rozwiążą problem. Zresztą z drugiej strony to umożliwia zaoszczędzenie pamięci na wskaźnikach - 16 bitowe są wystarczające, a tak musisz mieć co najmniej 24-bitowe, co na małych procesorkach może być niezłym overkilem. co do dzielenia double (których zresztą na AVR nie ma, są tylko float, double=float), to po dołączeniu odpowiedniej biblioteki - nie tej z gcc, tylko z AVR-libc nie jest źle. Aczkolwiek trzeba pamiętać, że 8-bitowiec to nie Pentium.No właśnie żadna różnica. Stąd nie jest to argument ani za, ani przeciw.Pokazujesz procesory, które są już obsolete. Popatrz po nowych. A ATMege8 można przestawić w trakcie pracy za pomocą rejestru OSCCAL, tyle, że pisanie o ściśle określonej częstotliwości w przypadku generatora RC jest jakby bez sensu.No jak okrutnie wysoka cena? UC3 są w podobnej cenie jak porównywalne ARMy. Owszem są tanie ARMy ale one raczej możliwościami i peryferiami nie są porównymwalne z UC3. Co do upadku Atmela - myślę, że akurat dla hobbystów jest to bez znaczenia. To może być argument dla kogoś kto planuje długie serie przez najbliższe 20 lat.

Freddie Chopin · Accepted Answer

Błagam... Nigdy nie realizowałeś projektu w którym założenia zmieniły się w trakcie jego trwania kilkukrotnie? No i teraz posiadanie układu z wieloma bonusami zamiast takiego "na styk" nie jest zaletą?Porównuje te, które były, są i będą (jeszcze długo) najpopularniejsze.Nie pisałem tego w kontekście dokładności, a jedynie... hmmm... "jawności" tej częstotliwości. Np. chcesz mieć 12.5MHz, albo 7.5MHz.Wchodzę na TME i widzę tam 2 wycenione układy UC3 - obydwa po 35zł netto. Teraz biorąc pod uwagę fakt, że średnia cena ARMa to (IMHO) 20-30zł, to 35zł wydaje się jednak okrutnie wysokim kosztem... Za tą kasę można mieć ARM7 z 2x tyle pamięci Flash...4\/3!!

mirekk36 · Accepted Answer

Freddie Chopin --> oooj widzę, że boli cię ta dużo mniejsza popularność ARMów na korzyść zwykłych AVRków

(mówię popularność! bo ty zaraz zaczniesz wykrzykiwać znowu że ktoś się z tobą spiera o wyższość jednych nad drugimi) ... Gdzie by tylko ktoś nie wspomniał coś o jakichkolwiek aspektach ARMów w kontekscie AVRów to zaraz ciebie pełno i głoisz swoją "prawdę" - ciekawe tylko dlaczego wciąż w dziale elektrody "Mikrokontrolery AVR" - przecież ktoś taki jak ty, kto nienawidzi 8-bitowców a szczególnie AVRów - nie powinien nawet tutaj zaglądać. Spójrz też sobie na ilości tematów czy postów odnośnie AVR a innych procków.

Jeden woli zrobić projekcik na np ATmega64 a ty to samo wolisz zrobić na ARM - i co z tego? "wolność tomku w swoim domku" - ale tobie najwyraźniej ciężko to zrozumieć. (a jeszcze trzeci, który nie zna się na mikro-prockach zrobi to samo na PC'cie - i co z tego?)

Dołącz do Kursu C dla mikrokontrolerów - zajrzyj na stronę i zapisz się !
https://akademia.atnel.pl nauczysz się programować w języku C

Selling:
13.11.2007 Wyświetlacz PLED(OLED) 2x16 WINSTAR WPI1602B-Y-JCS

Freddie Chopin · Accepted Answer

LOL... popatrz sobie KTO zaczął tą dyskusję. Zaczęliście pisać pierdoły o ARMach, to je sprostowałem i tyle, a że pogrążacie się dalej w "Nie, nie, to Atmel i wszystko co wyprodukowali jest najlepsze na planecie!" oraz w "Ci co wolą ARMy to jakieś matoły, które nie potrafią programować super 8-bitowców", to dalej was prostuję <;

No i oczywiście dodam, że wypisywanie postów w stylu "Nie chcę mówić, które są lepsze, ale AVRy są najlepsze" jest śmieszne [;

Pozatym - porównanie popularności ARMów do AVRów nie ma dla mnie znaczenia (pomijam fakt, że AVRy są popularne jedynie w PL, w innych krajach to jest zasadniczo "ciekawostka", taka jak u nas PICe, oraz to, że ARM jest obecnie używany chyba w co drugim urządzeniu embedded na tej planecie, a AVR ma może jakiś ułamek rynku 8-bitowego, 100km za Microchipem i Renesansem). Zresztą - AVRy też znam (m.in.), wy nie znacie ARMów <;

Jeszcze coś dodam. Jestem osobą która robiła projekty na PICach (małych i dużych), ARMach, AVRach, '51 i MSP430. Wy natomiast wszędzie pakujecie AVRa... No i kto tu jest uprzedzony? [;

pwnd

4\/3!!

See also:
07.03.2015 [C++11][Cortex-M3/M4] - distortos - obiektowy RTOS dla mikrokontrolerów w C++
10.02.2013 bleeding-edge-toolchain - kolejny toolchain dla ARM

utak3r · Accepted Answer

Ciekawe, jak by u nas wyglądał rynek 8-bitowców, gdyby nie słynna Ośla Łączka... to się nazywa potęga: jeden cykl artykułów w jednym czasopiśmie lata temu ustawił cały polski rynek hobbystów na lata

Panowie, rozdzielmy sprawy hobbystów i zastosowań profesjonalnych... tutaj rynek układa się znacząco inaczej. Dlaczego? Z powodów wymienionych przez Freddiego, w tym m.in. z powodu life-time'u produktu, który np. po kilku latach będziemy modernizować. Nie raz skórę uratowało wsadzenie procka "na wyrost" i pozwoliło uniknąć kosztów w przyszłości. Co innego w domu...

_Robak_ · Accepted Answer

Dyskusja robi się trochę nerwowa;) Myślę że po wyjściu cortexów M3 i M0, od NXP stosowanie AVRów w projektach przemysłowych/zawodowych (czy jak to nazwać Dla sztuk więcej jak 10) jest bez sensu. Sam rok temu zacząłem robić większy projekt na ATmedze 1280 i teraz bym w życiu tak nie postąpił. I nie postąpiłem, ostatni projekt robię na dużym LPC2478 i zaoszczędziłem miliona bramek i układów;)Prawda jest taka że z punktu widzenia ekonomicznego nie opłaca się używać AVRów, oczywiście jeśli ktoś zna zawodowo tylko AVRy i musiałby poświęcić trochę czasu na przesiadkę to może być problem. Ale dobry inżynier idzie z duchem czasu, ba musi iść, i nie można sobie pozwolić na pozostanie w tyle. To tak jak by powiedzieć idę do sąsiada 500m dalej to nie biorę auta tylko osła bo po co mam w 10 sekund pojechać. Cenowo ARMy i AVRy wychodzą podobnie, możliwości pierwszych są znacznie większe. Na forum królują AVRy tylko dlatego, że jest tu znaczna większość hobbystów, a szkoda. Ostatnio kolega atom1477 się śmiał że niektórzy uczą się ARMów tylko po to żeby diodą zamrugać, i bardzo dobrze, trzeba być przygotowanym na to co nas spotka:) Także, hobbystycznie, czy tam do testów, czy pojedynczych układów AVRy są ok, ale zawodowo już raczej nie widzę miejsca dla AVRów. Myślę że ATmel sam widzi sytuację i dlatego wypuścił ATXmegi, tutaj już jest inna sprawa ale czy warto robić konkurencję dla ARMów? Nie sądzę. Inna sprawa jest taka, że teoretycznie nawet do bardzo wielu zastosowań, 8 bit i te 20MHz starczy, w końcu same PLCki, z tego co kojarzę, nie są wiele szybsze, ale niech już by miały te procesory jakieś ficzersy do pracy w warunkach przemysłowych/ciężkich/nietypowych. Ale wiadomo im bardziej wyspecjalizowany układ, tym więcej musi być rodzajów, coś jak z PICami. Chcesz małego procka z 4 UARTami, proszę bardzo, z przerwaniami na wszystkich portach, proszę wybrać Nie mówię że Microchip dokładnie takie ma, ale że ATMEL mógłby pójść w tą stronę. Coś takiego by mogło spowodować wejście ATmela na bardziej "profesjonalny" rynek. Na szczęście dyskusja ta jest o tyle fajna, że nie ma problemu z wyborem;] Jak ktoś chcę zostać w tyle, jego sprawa ale, co najważniejsze, są układy tanie i dobre:)

utak3r · Accepted Answer

Hm, dobrze prawisz... ja bym na przykład chętnie ujrzał układy - odpowiedniki dzisiejszych małych 8-bitowców - ale wyposażone już od razu w np. interfejsy rs485, rs232, usb i ethernet naraz

Bo na teraz to takie rzeczy występują tylko w tych większych egzemplarzach - a cholernie często zdarza się, że potrzebujemy jakiegoś zwykłego czujnika + jakieś serwo, na co by wystarczył typowy 8-pinowiec - ale chcemy go przez ethernet, modbus, can i usb puścić

no i się robi wyolbrzymiony układ, całkiem bez sensu. Tutaj widzę spore pole do popisu w dziedzinie małych układów dla producentów.
A co do robienia konkurencji - chyba by Atmel lepiej wyszedł na robieniu układów z licencją ARMa. Wystarczy spojrzeć na NXP.

marekos · Accepted Answer

Ja akurat tak nie myślę, podejrzewam że Atmel pracował nad tymi układami od dość dawna, można tylko przypomnieć od jak dawna były zapowiedzi tych mikrokontrolerów i szkoda po prostu było im pracy włożonej nad nimi i takie coś wyszło na rynek. Jakieś półtora roku temu byłem bardzo nimi zainteresowany, ale jak zacząłem je analizować głębiej to zawsze coś mi nich nie pasowało, a to że na przykład do programowania i debugowania mogą służyć drogie narzędzia tylko od Atmela. Jestem przekonany że na rynku uK ta rodzina niczego nie osiągnie. Nie przekreślałbym mimo wszystko AVR8 są to naprawdę dobre układy i mają wiele zalet i wcale to nie jest prawdą że na świecie AVR8 jest traktowany jako ciekawostka, a tylko w Polsce zdobył popularność dzięki temu słynnemu kursowi. Wiem to stąd że układy ATMEGA widziałem w urządzeniach wielu ceniących się producentów np. w urządzeniach automatyki przemysłowej Siemensa. To że AVR8 ostały się do tej pory to jest siła rozpędu wielu inżynierów je zna od podszewki w bardzo wielu układach nie trzeba nic lepszego, oprogramowania gotowego jest napisane olbrzymie ilości i przede wszystkim dziesięć lat temu nie było nic lepszego, ba nawet trzy lata temu już zaczynał ARM rządzić ale mimo to w bardzo wielu aplikacjach jednak był AVR. Myślę że rozpoczął się zmierzch tych uK i powoli trzeba przesiadać się na coś innego w nowych urządzeniach, a im szybciej się to zrobi tym chyba lepiej.Prosiłbym również żeby nie złorzeczyć tak na samą firmę Atmel, bo robi genialnego ARM926EJ-S AT91SAM9260 układ rewelacja, ale też nie wszędzie. Piszę również tak ponieważ jakoś tak się złożyło że swoją przygodę z uK rozpocząłem z Atmelem na 8051, potem AVR8 i teraz ARM9 i wszystko Atmel, ale dalej będzie ST albo NXP.W tej chwili rozpoczynam przygodę z STM32, ale naradzie teoretycznie myślę że za parę lat to będzie wiodąca linia uK, prawdopodobnie te seminaria organizowane dość ostatnio intensywnie przyniosą skutek.

Zbych_ · Accepted Answer

Trochę słabo szukałeś. Spora część ARMów pomimo zasilania 3V toleruje 5V na wejściach cyfrowych.

markosik20 · Accepted Answer

Ale nie dla wszystkich urządzeń 5 voltowych 3V to na 100% stan "1".

michalko12 · Accepted Answer

Chodzi o to, że na ARMa nie ma czegoś takiego, a dla wielu C czy też C++ to prawie jak czarna magia.

User removed account · Answer

Żeby nie było. Ja też robiłem na ’51 (bardzo dużo), prawie (

) na PICach (Ale jak tylko zaczynałem to zawsze mnie coś zniechęcało), na AVRach i na ARMach.
Więcej się nie będę wypowiadał. Ja tylko dolałem oliwy do ognia

User removed account · Answer

1. Nawet większe układy nie mają interfejsów rs485, rs232 czy ethernet.
USB już prędzej. Ethernet też chyba jakieś rodzynki miały.
Ale tych poprzednich to nie ma. Jest UART, ale nie RS.
2. Atmel przecież robi ARMy.

Przypomniał mi się jeden argument przeciwko ARMom

Ale podpadnę Freddiemu Chopinowi

Miałem ostatnio taki projekt gdzie procesor w zasadzie nic nie robi.
Musiał mieć dwa UARTy, ADC i jeszcze obsługiwać parę prostych rzeczy (czujników). No i tak się złożyło że połowa z tych czujników była na 5V.
Miałem do wyboru LPC2101, jakieś STMy, ATMegę164 (i jeszcze parę innych, ale droższych) i pewnie jakieś PICe (ale szukając po TME nie znalazłem żadnego (taniego) PIC z dwoma UARTami).
No i okazało się że dość droga ATMega164 będzie najlepsza bo nie dość że uniknę konwersji 3,3/5V to jeszcze uniknę stabilizatorów 3,3V i 1,8V (przy LPC2101).
W bardzo podobnym drugim urządzeniu ale już bez tych czujników na 5V zastosowałem oczywiście STMa (Mimo że jego pozostałe peryferia oraz moc obliczeniowa się marnują. Ważne że kasa z mojej kieszeni się nie marnuje.).
Dość tanie i bardzo fajne LPC1xxx niestety odpadły bo miały tylko jednego UARTa.
Te 2 UARTy okazały się o wiele większym problemem niż myślałem.

michalko12 · Answer

Zaleta AVR - ma rdzeń który po prostu się zna, nie ma żadnych wydziwień jest prosty w opanowaniu jak 51. Z peryferiami jest dokładnie to samo. Żaden ARMowski rdzeń już taki prosty nie jest. Porównując kontrolery przerwań AVR i ARM to wychodzi na to że w AVR nic takiego nie ma. Niby w Cortexie jest juz prościej, ale jak ktoś zaczyna czytać o priorytetach, o grupach i podgrupach priorytetów, offsetach tablicy wektorów przerwań i wszystkich ograniczeniach z tym wszystkim związanych, do tego ilość tych rejestrów do zarządzania tymi przerwaniami to już tak różowo nie jest. Peryferia też są bardziej rozbudowane i bardziej skomplikowane z bardziej rozbudowaną obsługa przerwań. Kolejna sprawą jest to że niektórych przerażają liczby typu 0xA345DE41, a to jest normalne przy 32 bitach. Środowiska też się różnią, niby jest GCC na AVR i ARM ale to nie to samo. W przypadku AVR wiele tam opcji nie ma, Makefile czy skrypt linkera są proste, a w przypadku ARM też nie jest już tak kolorowo, można korzystać z gotowców ale to jest do czasu. Przychodzi taki moment, że trzeba coś dostosować pod swoje potrzeby i tu zaczynają się schody bo trzeba poznać składnię jednego i drugiego , a to są setki stron dokumentacji. Dokumentacja to kolejna przeszkoda tysiące stron w przypadku ARMów. Dla przykładu ja nie trawię dokumentacji od ARM. AVR czy PIC naprawdę mają przejrzystą dokumentację w porównaniu do dokumentacji procesorów z ARM. Ta dokumentacja jest pisana dla ludzi którzy maja juz wyrobioną intuicję panowania nad takimi urządzeniami i wiele spraw jest nieporuszanych lub opisanych po łebkach bo to jest przecież oczywiste i każdy kto jest w temacie wie o tym.

Teoretycznie z w/w powodów AVR są lepszy wyborem dla wielu, ale jak przejdzie się przez to wszystko to wtedy praktycznie nie ma co porównywać.

Edit:
Zapomniałem dodać o jeszcze jednym bardzo ważnym atucie AVR. Jest to BASCOM. Dla wielu jest to pewnie jedyny wystarczający powód wyboru AVR.

tmf · Answer

Prawdę mówiąc jeszcze nigdy mi się nie zdarzyło coś takiego. Ilość ADC, timerów, UARTów, przecież większość procesorów ma ich tyle, że nie sposób w jednym projekcie to wykorzystać. Z kolei USB, ethernet i inne bajery wymagają tylu elementów dodatkowych, że trzeba i tak przeprojektować płytkę. A jak muszę ją zmienić to przecież moge wsadzić przy okazji odpowiednio większy procesor z rodziny.A jakie jest dla tego uzasadnienie? Widac ktoś kto używa ATMega8 nie potrzebuje mieć dowolnej częstotliwości, bo jak by potrzebował to wziąłby nowszy odpowiednik. Swoją drogą do czego wykorzystywałeś możliwość ustawienia dowolnej częstotliwości taktowania? Bo problem wydaje mi się dosyc wyimaginowany. Jedyne praktyczne zastosowanie tego to okresowe obniżenie taktowania dla zaoszczędzenia prądu przy pracy na baterii.Po co?No popatrz, a ja wchodzę na Seguro i TME i widzę, że porównywalne układy ARM i UC3 są w cenach niemalże identycznych, raz tańszy jest UC3, a raz ARM. Dodano po 4 [minuty]: Hmm, przecież RS485 i RS232 są realizowane za pomocą tego samego portu UART (USI), który jest w każdym procesorku. Jedyne co potrzebujesz to transceiver, którego po prostu nie ma sensu pakować w procesor z prostego powodu - w zależności od sieci potrzebne są różne transceivery. USB i ethernet powoli też ma każdy procesorek. USB mają już ATMegi, ethernet malutkie UC3.Jak potrzebujesz sterować serwem przez CAN to masz przecież AVRy serii automotive, podobnie z USB. 8-bitowiec nie wysteruje ethernetu z braku pinów, ale już 48-pinowiec owszem. Dodano po 14 [minuty]: Trochę w tym racji jest. Jeśli mam wielgachną ATMegę 256, w której ze względu na ilość pamięci adresacja jest upierdliwa to też myślę, że jest to dziwne i jakiś 32-bitowiec byłby lepszy. Jedyne co skłania mnie do pozostania w takiej sytuacji przy AVR jest to, że już go znam i nie muszę poznawać innego rdzenia. Z drugiej strony nie zawsze ARMa się wsadzi. Np. najmniejsza dostępna obudowa jest 48 pinowa, a ATTiny jest w 6-pinowej. Istnieje więc pewna klasa zastosowań, w których prościej i ekonomiczniej jest zastosować AVR za parę centów niż ARMa za parę dolarów + cena miejsca na płytce.Co do aspeektu ekonomicznego to już wyżej pisałem, że są zastosowania w których wykorzystanie AVR jest bardziej opłacalne. Przecież dla jaj producenci nie wypuszczają procków w obudowach 6- lub 8-pinowych. Co do ATXMega to nie jest to konkurencja dla ARM, tylko rozwinięcie rodizny ATMega. Konkurencją dla ARMa są 32-bitowe procesory Atmela AVR32/UC3. A robią konkurencję bo dzięki temu nie muszą płacić opłat licencyjnych. Przecież dokładnie tak ma:http://www.atmel.com/dyn/products/param_table...p?family_id=607&OrderBy=part_no&Direction=ASCTrudno wymyślić konfigurację, której nie mają.

utak3r · Answer

Widzisz, nie do końca zrozumiałeś moje przesłanie. Oczywiście, że takie układy są. Ale... są po ok. 20zł na ten przykład, wkraczamy w serie uC "wszystkomających", przez co "dużokosztujących" A ja bym chciał jakiegoś malucha, powiedzmy do 20 pinów, który ma te kilka interfejsów, powiedzmy, że z pinami multipleksowanymi, właśnie dla oszczędności. Jest to pewna luka na rynku, którą można by wypełnić. Układów z 40 pinami i wyżej, które owe różne rzeczy mają, jest pełno, u każdego producenta. A teraz? Jeśli chcę do małego kontrolera dodać ethernet, to albo muszę dołożyć kolejny scalak, albo wejść cały poziom wyżej z uC, to samo tyczy się USB - dlaczego tak, wydawać by się mogło - podstawowej w dzisiejszych czasach komputeryzacji, funkcjonalności nie ma w tych najmniejszych układach? Przecież z powodzeniem nawet 8-pinowiec mógłby go mieć. Dzisiaj, gdzie komputery nadzorują kontrolery na każdym kroku... A tak, muszę znów - albo dodatkowy scalak, albo wejść poziom lub dwa wyżej z kontrolerem.

User removed account · Answer

Sorki ale wydaje mi się że mocno szukałem.Tutaj nie chodzi o to że nie tolerują 5V czy też że tolerują 5V. Musiał bym też konwertować 3,3V/5V a nie tylko 5V/3,3V.A do tego o tolerowaniu 5V słyszałem i i tak już z tego trochę skorzystałem.Po za tym mam tam DS18B20. Może pracować na 3V ale to jest na styk. A w trudnych warunkach już nie przejdzie bo na kablach odłoży się trochę napięcia. Przy 5V żeby działało musiałem dać rezystor podciągający 1k. Przy 3,3V nawet próbowałem i nie działało nawet przy 220R (a rezystor na pewno nie za mały bo przy 5V nawet przy 100R działało. Co mnie nieźle zaskoczyło w sumie ).Więc musiał bym pracować na 5V, a to wymagało by konwersji dwukierunkowej 3,3<-->5V. Dwukierunkowej to znaczy Bidirectional.Nie sądzę że przekombinowałem. Najtańszy STM był w cenie ATMegi164. Przekombinował bym właśnie wstawiając STMa.No i jeszcze I2C. Tak samo: Bidirectional.Do tego niektóre czujniki są analogowe. Przy procku na 5V obyłem się bez dzielników napięcia. A dzielniki to jednak problem bo wydajność prądowa czujników (ciśnienia) jest mała a do tego dzielnik wymagał by raczej rezystorów 1% albo lepszych.Problem nieduży, koszt mały, ale czy to powód żeby go ponosić (ten koszt)?To raczej AVR jest powodem wybrania BASCOMa a nie odwrotnie. Bez AVRów nie było by przecież BASCOMa.

janbernat · Answer

A było tak:
http://en.wikipedia.org/wiki/Intel_4004
Albo tak-jak nowocześnie:
http://en.wikipedia.org/wiki/Intel_8008
A tu:
http://en.wikipedia.org/wiki/Microcontroller
A tu w tym:
"In 1993, the introduction of EEPROM memory allowed microcontrollers (beginning with the Microchip PIC16x84) [2][citation needed]) to be electrically erased quickly without an expensive package as required for EPROM, allowing both rapid prototyping, and In System Programming.
The same year, Atmel introduced the first microcontroller using Flash memory. [6].
Other companies rapidly followed suit, with both memory types."
I to wydaje mi się kluczowe:
"The same year, Atmel introduced the first microcontroller using Flash memory."
A Bascom nie powstał ot- tak sobie.
Były mikrokontrolery przedtem.
Ale kasowanie pamięci w ultrafiolecie to ja pamiętam- bardzo czasochłonne.
No i pierwsze procesory Atmela to były 8051 a nie AVR.
I na nie najpierw powstał Bascom.