Legjobb tudomásom szerit PIC-nél ez úgy néz ki, hogy egy utasítás végrehajtás alatt egy fetch ciklus is van, azaz a következő utasítás elővétele. Ezek így átlapolódnak. Kivétel az ugró utasítások, mivel ott az elágazás kétfelé mehet, ezért nem tudjuk egyből előhúzni a következő utasítást (mert nem tudjuk melyikre ágazunk majd el)

Akár AVR, akár PIC, nem tudom, hogy a filléres árak mellett érdemes-e árak összehasonlításával foglalkozni. Egy IC fillérekbe kerül, míg a beletöltött program esetleg százezerbe. A költségkímélésnél talán a könnyebb szoftverfejleszés lehetne a fontosabb mérce, (persze más dolog a sorozatgyártás, több tízezres darabszám-de ezt inkább máskor tárgyaljuk, hogy ne dumáljunk mindenről egyszerre).

Nekem fontosabb, hogy a PIC-nél "minden" utasítás 4T, mint az, hogy gyors vagy még gyorsabb. Könnyű figyelemmel tartani az ugrásokat(8T).

A bő PIC választék miatt kényelmes dolog leosztani a feladatokat több kisebb PICre.

Nem tudom tudjátok-e, a felhasznált uP 80%-a max. 20lábú IC.

Kinek a Pap? Kinek a Papné? Spec. nekem a lánya...
Alapon szeretnék szeretnék a topichoz hozzászólni. Meglepett, hogy egy ilyen egyszerü kérdés is milyen vitát tud kiváltani!
Most a saját életemet írom le, ebben sokminden elöfordúlt már és meglehetösen pártatlan vagyok, talán pont ezért.
Az elsö lépés még a 8080 volt. De párhuzamosan jöttek az egy csippes procik. 6500, 6800. Majd a Z80, Z8. A Zilog ezekkel akkorát dobott, hogy csodálkozom miért is tünt ennyire el? (Természetesen az ára miatt!) Jött egy rövidebb szünet amikor ismét az Intel került elötérbe. A 87C5x és az MCs48 család. Egyszer csak ezek is kihaltak, megdrágultak. Ebben az idöben kedvencem volt a 80c35 és 81C51+externál ROM konfig. Ezután jött a mások már nagyobb feladatokat is megoldanak mással idöszak.
A PIC valóban mint sokan említik a csapból is folyt. De! Illetlenül drága volt maga a chip nem beszélve a tartozékok, vagy a szükséges software áráról.
Ekkor volt szerencsém -egy interface-t “dongle-t” kaptam javításra. Amikor belenéztem -csoda- de a passzív cuccokon kívül mindössze 2 db IC egy ’232’-es és egy 20 lábú valami at89s1200? Soros - párhuzamos átalakítást végzett némi konverzióval, mert az UNIX sorvége más mint a megszokott CR+LF, LF only.
No ekkor belevetettem magam az ATMELL dolgokba.
Egy olyan barátságos ‘társaságot’ találtam magamnak amit nem hagynék el semmi pénzért! Márpedig itt pénzröl van szó!
Itthon beszerezhetö ‘szinte bármelyik’, de alaptipus szerint a legtöbb. A legdrágább nettó ára 2300HUF+fa.
A software ellátottság több mint elegendö, ráadásul ingyenes(!) LINUX alatt. De szerintem W$ alatt is lelhetöek free progik. Mivel ezt nem haszálom nem biztos, de láttam már ilyet.
Nos most összefoglalom a fenti halmazt.
Voltak elég, söt nagyon jó uC-elek (Z8) , vannak ma is 8751 procik. Hiszen ipari szabvány. De ennek még az ATMEL változata is igényel +12V-ot (programozáskor). Ami elkerülhetetlenül bonyolúltabbá teszi a flash programozását.
Viszont a ’89Sxxxx’ család a mentes mindezek nehézségektöl. Az SPI programozással eddig még semmi gondom nem volt. Hivatkozom honlapomra. http://w3.externet.hu/~szal ahol megismerheti bárki a “fejlesztö eszközeimet”...
Szerintem tehát a kát tipus sem árban, sem tudásban nem és
nem is lehet riválisa egymásnak. Viszont egymás mellett is
jól megférnek.
Szép napot mindenkinek!
SzaL.

Kinek a pap, kinek a paplan... Bocs, ezt nem bírtam kihagyni!

Win alatt is vannak ingyenes cuccok az avr -hez , a winavr (avr-gcc win vwrzió), és a bascom igaz ebből a demo, de az majdnem több mint elegendő, az utóbbi basic az előbbi c ,én inkább a c - t támogtaom! avrtux

Én is pártatlan vagyok. Mint mondtam feladattól függően választok procit. De azért az AVR-t nézem meg először, akaratlanul is áttértem rá Amúgy a PIC csak itthon ilyen drága, mert egyetlen egy forgalmazója van, gondolom tudjátok melyik cég.

A fejlesztőkörnyezet pedig C és assembly nyelven mindegyikre ingyenes minden oprendszerre. De ez igaz minden proci fejlesztőkörnyezetére az FPGA-kra is.

Én elsősorban AVR-es vagyok, főleg a mocskos anyagiak miatt. Mert ahol én be tudom szerezni, ott az AVR olcsóbb.
A PIC-cel az a bajom, hogy nagyon kicsit tárhelyet mellékelnek a relatíve drága prociba. Összehasonlítás képpen egy PIC16F871 (aminek van 2 kword tárhelye van)ahol én be tudom szerezni az kb 1400Ft, egy AVR ami hasonló árban van, pl az ATmega64, az meg 64k tárhelyet biztosít. Ráadásul majdnem 4-szer gyorsabban. Annó a PIC-hez JDM-programozót használtam, de az IC-prog nem akart normálisan működni winXPalatt (megfelelő beállítások ellenére, csak minden 2-szorra ment bele a program) Az AVR-nél az STK200-as programozóval viszont semmi bajom.

Tudod én PIC rajongó vagyok. De engem is érdekel az AVR , mert már annyi jót írtok róla. Az avr.tavir.hu oldalról származik a müködőképes programozód?

Igen, onnan, de az IC-set építsd meg, sokkal stbailabb. Szerintem kezdésnek használj Bascomot mint fejlesztőkörnyezetet.

Én is azt építettem meg Kiválóan működik még a tiny2313-al is ami elég érzékeny jószág, az IC nélkülivel nem tökéletes. Fejlesztőkörnezetnek van assembly (AVR studio) is, szerintem jóval átláthatóbb mint a PIC, igaz több mint 100 utasítása van, de ennek ellenére is.

Köszi mindkettőtöknek.

Szerény véleményem szerint a vita alapja az, hogy elvakult mindkét tábor. Aki a PIC-et szidja, az még megállt a sz*r PIC16F84-nél, aki meg az AVR-eket szidja, az meg nem találkozott még soha jó AVR-el.

Pro. Az tévhit, hogy az különbözeti meg őket, hogy gyorsabb merthogy az AVR 1 órajel / utasítás rendszerű. Tudniillik a PIC18F-es sorozat kapásból veri az AVR-ek nagyrészét. (Hardware USB, rfPIC,...) Már ne 16F-es sorozatban tessék gondolkodni. Az ADC-vel kapcsolatban az a helyzet, hogy még a legbutább ADC-s PIC-ek is tudják jószámmal a 10Bites üzemet.

Kontra. Sajnos a PIC-ekben elég sebezhető pont a hardware-es interfészek. Gondolok itt az SPI-busz és a hozzá tartozó Interruptra. Most is jelenleg azzal küszködöm, hogy egy 20Megán üzemelő (egyébként 40MHz-es max órajelű 4X-es PLL-el) 18F4520-at (Kicsivel több ROM és RAM-ja van mint a vele ekvivalens tudású AVR társának) össze kell lőni kb 20db 16F877-es procival. És sajnos itt már a PIC-ekkel az ember meglehetősen nehezen boldogul, hisz közismert tény, hogy a SSPBUF és a hozzá tartozó interrupt elég vérző dolog. Kénytelen vagyok várni 10uS-et Master oldalon, mire a Slavenél beesik az interrupt és a bufferből egyáltalán tudok adatot olvasni. Ez az AVR procikkal szemben egy rossz pont, mivel azoknak a jóval egyszerűbb felépítése miatt ezek az idők jóval leredukálódnak.
Szóval sajnos a PIC-nek vannak fekete pontjai jócskán.
Az AVR-nek viszont azért vannak olyan procijaik, ami a Microchipnek soha nem lesz (A nagy eladott darabszám miatt) MP3-as Atmel proc. Egybe van az MP3 dekóder, és maga a mikroprocesszor. Így hihetetlen busz sebességet lehet elérni. Csakhát itt jön amiért magyarországon inkább a PIC kedvelt. Ezt az IC-t nem lehet beszerezni magyarországon. És erről nem - mondjuk ki bátran - a ChipCAD vagy bárki más tehet. Nekünk egy készülékhez kellett volna, de csak egy csővel hoznak be amiben ötszáz darab van. És hogy ez miért? Azért mert még nincs rá fogadó közönség. Nincs annyira marketingelve és terjesztve mint a PIC.

Szóval most így összességében. Én atmel processzorokkal dolgoznék, ha lenne jobban dokumentálva (még angolul sincs rendesen sokszor dokumentálva minden, PIC-nél sem a magyar doksi számít), jobban beszerezhető lenne. Árával nincs baj, az közel azonos. PIC-ből is vannak pár száz forintos akár 6 I/O pines változatok is.

Remélem rávilágítottam miért nem annyira elterjedt nálunk az AVR.

Egyvalamaire rákontráznék: igaz magyar doksija nincs az AVR - nek, de angol és néemt több mint elegendő..(szerintem), namost ugye a pic nél a 18Fxxxx soraozat egyel nagyobb kat. mint a 16F
tehát azért az AVR - még szerintem némelyik 18 as PIC - et is lenyomja, (csak annyi van belőlük hogy nem lehet rajtuk eligazodni), akkor nézzük az ATMEL egyell nagyobb kategóriás procijait az ARM - et tehát 200 Mips számítási teljesítmény, UART, 10/100 Mb - es ethernet ,USB és igen méretes flash memória(no meg amit nem soroltam fel..van bőven , olyan PIC - et még nem láttam ami csak hasonlóakat tudna mint az ARM), és az AVR - fejlesztő környezetei (BASCOM, AVR-GCC) szerintem sokkal jobban használható mint a PIC - es progik (ezeket is próbáltam , több mint egy évig PIC - eztem de szerintem nem túl stabil procik......munkám során is találkozok mind a két típussal , és amiknek a központi alkatrésze PIC azokkal igen sok gondunk van....de ez lehet váletlen is...bár....)


És melyik AVR nem?


Nekem a fejlesztés sokkal könnyebbé és zökkenőmentesebbé vált az AVR - használatával, és nem utolsó sorban nagyon stabilan működnek, kevésbé zavarérzékenyek mint a PIC!

Ez az én véleményem, hogy ki melyiket használja mindenki döntse el maga

Üdv!

Én nem foglalok állást a témában, de ne keverjük ide az ARM-et. Attól, hogy az Atmel "gyárt" ARM kontrollereket, még nem keverendő össze az AVR-rel, ami ugye összehasonlítható a PIC kontrollerekkel, mert mindkettő 8 bites, az ARM meg 32.

Az ADC-s kijelentésemet azért értetted félre, mert nem olvastad végig a topicot, csak leszúrtál. Fentebb említette valaki hogy "azért jobb az AVR-mert annak van 10bites ADC-je"

sorry!!! de amúgy meg nem leszúrásnak szántam a hozzászólást, csak állásfoglalásnak...én sajnos nagyot csalódtam a PIC -ben, valszínű ezért vagyok ilyen elfogult de attól függetlenül , jah akkor egy kérdés a 18Fxxx pic az 8 -bites? szerintem nem egészen már csak pbalazs hozzászólására reagálva, de lehet hogy tévedek, és Topi mégegyszer bocsi (nem leszúrásnak szántam )

Az PIC18Fxxx-es széria 8 bites. A 16 bites széria a PIC24Fxxx, dsPIC30xxx és dsPIC33xxx.

A portokat tekintve sajnos 8 bites. Ezért kellett Assembly-ben megírnom a 16bites számlálót a memória címzéshez egy egyszerű szkópban.

Nem a portokon múlik, hogy 8 bites a processzor, hanem azon, hogy hány bites adatokon végez műveletet.

Ettől független 8 bites. (de ez igaz !)

Topi!

Ha nem titkos, megkérdezhetném, hogy melyik ATMEL procit nem sikerült beszereznetek, amiben van MP3 dekóder? Csak nem az AT89C51SND1C? Mert az beszerezhető itthon

Nem egészen ide vágó a téma..de mivel nekem semmi tapasztalatom nincs az elektronikának erről a területértől, viszont egy vezérlési problémát viszonylag kevés idő alatt meg kell oldanom, s látom, nagyon sokan nagy tapasztalattal rendelkeznek az ittlévők közül a kontrollerek világából, így felvetem a problémámat.
Egy berendezés vezérléséhez szükségem van valamilyen megoldásra. A feladat röviden a következő lenne. Adott egy berendezés, melynek egy lehetséges állapotát 4 összetartozó paraméter /analóg/ határozza meg. A lehetséges állapotok száma 3000-4000 közötti érték lenne, s ezeket az öszetartozó értékeket kellene tudni bevinni egy memóriába, ott tárolni, s a berendezés működése során ezekből az állapotokból kellene adott program szerint kiválasztani a következő álapothoz szükséges új értékeket, s azt a vezérlő elektronika megfelelő bemenetére továbbítani, hogy a szükséges új beállításokat a megadott új értékre el tudja végezni.
Mivel nincs kellő ismeretem a mikrokontrollerek világáról, s a rendelkezésre álló időm rövid, hogy a kellő ismeretanyagot ennek a megoldásához megszerezzem, ezért keresek valakit, aki ennek a problémának a megoldásában tud segíteni, aki ezt a legegyszerűbben és legkedvezőbb kondíciókkal meg tudná oldani.

Sziasztok!

Foglalkozok PIC-ekkel is (16, 18-as család) és AVR-el is (ATmega128...) és a következőt tudom mondani:
a Microchip egyrészt nagyon jól marketingeli / menedzseli a termékeit és rengeteg könnyen hozzáférhető fejlesztőeszköz, program, adatlap, leírás segíti a munkát.

A 8 bites eszközökről: ha valaki most kezd el ténylegesen mikrovezérlőkkel foglalkozni, akkor ajánlott a Microchip 16-os családdal kezdeni. Könnyen átlátható, jól kezelhető, gyorsan elsajátítható (gondolok itt az assembly-re, a kevés számú utasításra (35!) ). Ezzel gyorsan eljut az ember arra a szintre, hogy bonyolultabb dolgokat akarjon csinálni -> 18-as család, itt viszont már szinte őrült aki nem használja ki a C fordító lehetőségeit.

A PIC18FXXXX család-nál viszont jobb az AVR 8 bites családja (18/28 lábú eszközöknél nagyobbakra gondolok), bár sokkal több az utasítás, de úgyis C-ben fogja programozni a tokot aki komplexebb dologra vágyik. Az AVR-nél sokkal jobb a PWM rendszer, a megszakításkezelés ugyanúgy egyszintű (bár a 18-as családnál kétszintű a megszakításrendszer, de általában az Errata-ban azt írják, hogy nem tanácsos használni, csak az egyszintűt), azonban a 8 bites AVR-nél minden megszakítás eseményhez külön ugrási cím tartozik, ami megkönnyíti a programozási munkát (nem kell külön-külön vizsgálgatni, hogy éppen mi okozott megszakítást).

Kb. ugyanazért az árért nagyobb (akár program, akár adat) memóriát és gazdagabb perifériakészletet kínál a 8 bites AVR, mint a PIC 8 bitesei.

Ha 8 bites eszközre kéne írnom programot és már konyítok valamcskét a mikrovezérlőkhöz, akkor AVR-t vennék.

Más a helyzet a 16 bitesekkel, mert ilyet csak a Microchip gyárt, itt nincs értelme összehasonlítani.
Ha valakinek szüksége van 10 (illetve 12) MPIS-nél nagyobb sebességre és eddig PIC-ekkel foglalkozott akkor a dsPIC33-at ajánlanám, olcsóbb, mint a dsPIC30, kicsit nagyobb a sebessége (nem 30, hanem 40 MIPS max) és kicsivel többet tud a PIC24-nél (mind perifériában, mind utasításkészletben (MAC...) ). Viszont a 16 bites családban nincs benne pl. az USB, illetve az Ethernet kezelésének lehetősége sem.

Ha valaki igazán komoly dolgot akar csinálni, akkor egyértelműen az ARM processzorokra tennném le a voksom. 32bites, igazán széleskörűen támogatott, jól kitalált.... processzorok, de ilyet a két gyártó (Microchip, Atmel) közül csak az Atmel gyárt. Bődületes a sebessége (architektúrától függően 60...200...400 MIPS) és szinte minden benne van ami kellhet: USB, Ethernet, CAN, USART, codec.... és árban sincs olyan távol, sőt! Azonban ahhoz nagyobb tudás is szükséges.

Összehasonlításként: megbízhatóság tekintetében nincs különbség egyik (se PIC, se AVR) között sem, mindkettő irdatlan megbízható tud lenni (megfelelő áramköri és program tervezéssel).

A Kandón a PIC-et tanítják, a BME-n meg az AVR-t, de igazi ok nincs, hogy miért egyik másik, az éppen aktuális döntéshozó így döntött.

Sziasztok

És kérek minden hozzászólót, hogy inkább kétszer olvassa el amire válaszolni/írni akar, minthogy felesleges meddő vita alakuljon ki egy elolvasás/félreértés miatt!

Köszönöm

Sziasztok!

Kicsit megérintett az hogy az ARM processzorok között van 400 MIPS-s is. Fogalmam nem volt róla. Ha előbb tudtam volna, akkor a következő szkópomat azzal építettem volna. Sajnos mostmár bevásároltam CPLD-ből meg dsPIC30-ból. Meg ezeknek az égetésére és programozására vagyok szoftveresen, hardveresen felkészülve.

Udv!

Noh, had szoljak a temahoz en is par szot.
Kb. 4 eve epitettem meg az elso PIC programozomat LPT portra, elsore mukodott, akkor meg ASM-ben programoztan. Sok programot irtam ra, ez egy univerzalis PIC, neten is rengeteg projekt hasznalja. Par erdekes kodot ki is raktam netre:

http://technik.kaotika.hu/fejleszto.html

Toltam a PIC-et vagy 3 evig, kozben persze tudtam, hogy vannak mas uP-k is, csak hat megszoktam a PIC-et rendesen. Aztan eljott az igazsag oraja... Miutan kiprobaltam sokfele kommunikacios protokolt(I2C, UART, ...), elkezdtem az ethernet utan erdeklodni, mert ugye IT technikus vagyok papiron. Szoval ossze akartam drotozni a PIC-et at ethernettel. Bongesztem a netet, eppen akkoriban jott ki az ENC28J60 nevu Microchip csoda, ami igeretesnek tunt, pl van benne ethernet frame szintu packet filter, stb... Kerestem is hozzavalo PIC-et es az jott ki, hogy bizony a 18-ast kell hasznalnom. Noh ehhez megint programozot kell epiteni, ezt nem akartam azert, mert mar PIC-hez epitettem vagy 5-ot amibol osszesen 1 mukodott rendesen es csak limitalt szamu PIC-et tudtam vele programozni. Tehat, PIC-ek szamat osszuk el mondjuk 30-cal, ennyifele programozo van amibol egyik csak Win alatt megy, masik SP2-vel nem indul, harmadik soros porton nem megy laptopon mert nincs meg a 15V, kulso tap kell ami 15V legalabb, LPT porton gondog vannak az LPT driverrel es meg sorolhatnam tovabb. Tehat PIC-nel az egyik nagy problema: ha procit valtasz, valoszinuleg programozot is valtani kell(persze ez nem biztos, de baromira korlatozza a szabadsagomat). AVR-ek szinte mindegyike SPI-n keresztul programozhato ugyanazzal a programozoval. Na ott van az ICD2 nevu csoda is, ami kis tulzassal egy tulbonyolitott JTAG-nak is nevezheto, sokba kerul es csak mostanaban kerultek fel klonok amiket utan lehet epiteni. De mivan ha az en PIC-em egy egyszeru darab es nem tamogatja az ICD2???
Masik nagy hiba: nincs PIC-hez ingyenes C fordito!!! Igazabol semmilyen ingyenes fordito nincs hozza, csak demok. AVR-hez szepen megirtak a GCC-t ami tokeletesen mukodik! GDB-t is, lehet debuggolni JTAG-on keresztul, ami olcso es konnyen utanepitheto. En mostanaban epitetem meg, elsore mukodott. Eddig nem volt JTAG-on csak egy AVR910 programozo. Na persze azt lehet mondani, hogy ASM-ben lehet optimalis programot irni, de megneznem en azt, hogy mondjuk az en esetemben a TCP/IP -t ASM-ben ki kodolta volna le!!! Szoval nalam ez a ket fo erv: ingyenes magas szintu fordito es egyseges programfeltoltesi protokol. Persze az architektura is sokkal elonyosebb, pl 32 altalanos celu regiszter, nagyobb MIPS, tobb periferia az egyszerubb AVR-ekben is, SRAM, nagyobb flash...
Azota megepitettem az ethernet projektet, van meg mit csiszolni rajta. Alapul az ingyenes uIP TCP/IP stack-et vettem. Sajnos az ENC28J60 drivert nem tettek ala igy ezt en csinaltam meg. Szepen mukodik de az atmega32 kicsit keves neki.

Az SX-ek is gyorsak 600Ft-ért 70MIPS-et kapsz

Köszi a tipet. Most inkább a CPLD-k kerültek előtérbe nálam, de azért észben tartom. Persze teljesen kezdő vagyok még benne.

Én is hasonló okok miatt tértem át AVR-re kb 2 éve(ár, programmemória, programozó, és az ingyenes fordító, stabilabb működés, és ami nagyon tetszik: mindegyik AVR teljesen ugyanúgy épül fel, csak programmemória és perifériákban másak, egyik AVR-ről másikra átérni az csak 1 sor módosítás a programban, vagyis inkább csak a fordító beállításánál.
Nekem egy szimpla STK200-as IC-vel megerősített programozóm van és eddig mindegyik AVR-t fel tudtam programozni vele amikkel eddig találkoztam

Üdv.
Feljebb írtátok, hogy a PIC azért terjedt el jobban az avr-nél, mert a microchip-nek jobb volt a marketing stratégiája. Én ezt még kiegészíteném azzal, hogy a microchip küld sample-t, az Atmel pedig tudomásom szerint nem. Ez lehet az egyik oka, miért elterjedtebb a PIC.
Nem az alkatrész árán van a hangsúly, hanem amikor egy olyan célt kell megvalósítani, amihez az alkatrészt nehéz beszerezni, akkor inkább sample-t kérek, minthogy a farnell-től kihozassam 20e HUF-ért.

Persze Mo.-n PIC-et AVR-t is be lehet szerezni könnyen, csak más országokban nem mindíg van így.