Szerintem csináltál te is véletlenségből sokmindent, nem okvetlenül a tájékozatlanság számlájára írnám a kizárást.

Ismét csak azt tudom mondani, hogy nem az a baj, hogy nem lehet feloldani a kizárást, hanem az, hogy az újrabejutáshoz kívülről kell odavezetni órajelet, meg van olyan, hogy le lehet tiltani a soros programozást soros programozással (attiny-k között), és akkor csak a párhuzamos programozás marad .

A Lock és a Code Protect tipusú dolog az más, azt én nem kizárásnak nevezném.

Nem akartam vitát generálni, ne füstölj

Valószínűleg mindenkinek igaza van! Ez egy szabad ország

Akkor még volt netem, nem tudtam, hogy fel lehet oldani az AVR kizárást, nekem azt mondták, hogy már használhatatlan....

Hiába van ledokumentálva minden az AVR-ről, szerintem kezdőként mindenki elkövetett néhány eszetlenkedést .

Nekem az nem tetszett az AVR-ben, hogy sok assembler utasítása van, míg a 16-os picnek csak 35.

Viszont az AVR-nek jobb a felépítése:
-nincsenek bankok
-A sok I/O-os változatok (mega 128) könnyeben beforraszthatóak

Az STK200-al nekem sem sikerült mindíg az égetés, pedig a 74hct244-es változatot használtam.

szerintem a windows a hibás ... Bascomot próbálgattam régebben de igazából a C preferálom ezért nagy hangsújt nem fekettem rá, de de nem rossz!!!!amúgy meg Linux és Avr-Gcc!!!

" lehet tiltani a soros programozást soros programozással "

Persze és, ha 1000V-ot kötsz rá akkor is kizárod magad. Ez még nem érv, de egy fontos benyomás.
Az ilyen apróságok miatt dönt ki a PIC, ki az AVR mellett.

PIC-ben is lehet hasonlóan "okos" dolgokat csinálni, és hozzánemértéssel az is csak egy kulcstartó...

Lehet kötözködni, meg hogy el kell olvasni a használati utasítást, stb., de el kell ismerni, hogy a pic-ek felprogramozása jobban meg van oldva. Bár az a debugWIRE elég ütős, de a hozzá tartozó programozó ára is ütős, klónról pedig nem tudok. Ettől függetlenül semmi bajom az AVR kontrollerekkel, a most készülő egyetemi projektben is egy AVR lesz a 8051 mellett.

Topi! a AVR PIC összehasonlító cikked után kérdezem, hogy a egy új projectbe kezdesz, akkor először a megfelelő atmel mcut keresed vagy először picet?
másik kérdésem, hogy ha nem a 16F családot hanem a 18F ből vagy még feljebbről hasonlítasz össze az atmel mikrokontrollerekkel piceket akkor is az atmel nyer? Csak kiváncsi lennék.

Szia!

Attól függ, milyen alkalmazás. A Microchip-nek van egy-két rf eszköze, enc, stb.

18F-es összehasonlítás? Az már nehéz lenne, mert 18F már majdnem olyan mint az atmel PWM, CAN, USB verziói. Azokból már nehezebben összehasonlítani, mert egy PIC architektúrájú PWM optimalizált IC nagyon sokban más mint egy PWM-es AVR.

Csak a normál-normál széria az összehasonlítható.
18F-es széria már PIC esetében egy jólsikerült széria, bár ugyan azon tudás még mindig drágább, nemúgy mint a 24F, ami szerény véleményem szerint a microchip szégyene. Nem is csoda, ha szinte egyáltalán nem terjedt el.
18F-es szériában viszont az jópár típusnál elmondható, főleg a CAN-busz meghajtós verziókból, hogy a CAN-es AVR alig felébe kerül a CAN-es PIC-nek.

De ez igazából abból ered, hogy a gyártásban jelenleg az AVR-nek, és az ATMEL-nek áll a pálya. Hogy ez jó-e vagy nem? Ki tudja. Az biztos hogy egy-két olyan oldala van, ami elkellene a PIC-ben is.
Pl.: 1órajel/utasítás, timer full F_CPU-ról járatása. (PIC-nél mindig minden max órajel a rendszer/4) BANK-elések egy életre kiűzése. Külön kezelni a busz irány, busz adat olvasás és adat írást.
dsPIC-eknél ezt óriási hírveréssel adták közre, hogy külön szedték az írás és olvasást merthogy a dsPIC olyan nagyteljesítményű. Még a 8051-eseknél is különvolt, pedig több mint 30 éves a harvard architektúra. 30 év kellett, hogy rájöjjön a MC hogy jó az a régi módszer, mert gyorsabb.

Viszont annó, még csináltam egy összehasonlítást és az AVR-GCC jócskán jobb hatásfokú mint a HI-TECH C.
Ugyan az a feladat: Többszálú real-time szabályzás.

kimerítő válasz , köszönöm! úgy veszem le, hogy ha teheted Atmelt használsz. Na majd ha felnövök áttérek Atmelre... Aki egyszer áttért az nem tér vissza pichez, mindehol ezt olvasom, hallom, tehát valószínüleg Atmel a "jobb"...

Hát hogy jobb-e azt nem tudom. AVR-el kezdeni nem célszerű, mert bonyolultabb.
Nálam fejlesztésben az a cél, hogy egy termék minnél jobban tömeggyártható legyen (ehhez elkell a programozás stabilitása és gyorsasága) és minnél olcsóbb legyen.
Pont a napokban készült el egy régi termékünk avr-esített változata. Régi anyagköltség: 2500Ft. Új anyagköltség 980Ft.

Olcsóbb processzor, a bazisok belső cucc miatt kevesebb külső alkatrész, stb.
Namost mivel ebből havi több ezer készül, már tetemes a különbség.

Sokévet lehúztam PIC-ek társaságában, és állíthatom hogy az a sok szenvedés. (programozó nem ismeri, rosszul megírja. Ismeretlen 0x0000-ás hibaüzenetek stb, mind hiányzik)
Microchip-eseknek jó marketing szakemberei vannak, csillivilli website-juk. Az ATMEL olyan szép kis csöndes.

Annyi biztos, hogy a most ezévi Nürnbergi Embedded World kiállításon a Microchip egy vegyesboltnyi területen, az ATMEL meg egy háztömb méretű standon volt. ATMEL-esek nagyon értik a dolgukat, hogy kell eladni valamit. Vitrinekben ezrével demo board-ok. Úton útfélen ingyen osztogatták a demo boardokat, programozókat. Origi dobozos MkII-ket.

(Tudom, mert kinntvoltam a kiállításon, én is szereztem magamnak dolgokat)
A microchip a kis tűzpiros standján (ami mellesleg nagyon design-os volt) egy-két cuccal meg prospektussal tolták ki a pofájukat)

Érdemes kijárni ilyen nemzetközi kiállításokra. Jó kapcsolatokat lehet találni (nekem sikerült egy két kínai és német ottlévő gyártóval/forgalmazóval azóta egész jó kapcsolatot létrehozni)

Voltak olyanok, hogy magyarországra még vagy 10 év mire be fog törni. alig 10cm-es kijelző. Touchscreen-es és 1280x1024-es felbontás. Meghökkentő milyen dolgok vannak egy ilyen nemzetközi kiállításon.
Javaslom mindenkinek a kilátogatást. Sokezer kilóméterre van sajnos németországban. de megéri)
Félni nem kell a nyelvi problémáktól. A kiállítók mind beszélnek angolul, nohmeg a boltosok is nürnbergben (mivel az egy kiállító város. kb csak az van) tudnak angolul.

Anélkül, hogy vitát indítanék, lenne pár észrevételem a cikkel kapcsolatban:

- 16F (tehát generációban régebbi) sorozatú, erősen kifutó terméket (16F877) hasonlítasz össze egy épp aktuális generációba tartozó AVR-el. Emiatt az ár/tudás arány nagyon felborult. Szerintem illene legalább azonos generációba tartozó, vagy legalábbis nem kifutó termékeket összehasonlítani (16F887 vagy 18F4520). A mérleg továbbra is az AVR oldalára billen, csak kisebb mértékben

- PIC-hez gyári fejlesztőeszköz: Pickit2, kb. 6500Ft

- PIC-hez C18 fordító - némi korlátozással ingyenesen használható

- AVR-nél van a debugWire debug rendszer, egyetlen vezetéken keresztül debuggolható a chip, míg PIC-nél ez három vezetéket jelent

- PIC-nél a timerek külső órajelről akár a rendszerórajeltől (nem a negyedelt) magasabb órajelen is tudnak járni aszinkron módban.

- Bankok: ismét csak nem két eltérő generációt kellene összehasonlítani...

C18 igaz, de az csak 18F-hez. Tehát azért nem olyan kerek a dolog.

Tudsz akkor javasolni konkrétan két típust? Mert ha van érdeklődés, akkor megcsinálom a komolyabb összehasonlítást. Ahol nem csak külsőségről van szó, hanem egy-azon utasítás szigorúan assembly-ben megírva, azonos órajelről. Ilyen "ki fejezi be előbb" teszt.

Gondolom ez sokmindenkinek segíthet. Konkrét ötleted, típus javaslatod van akkor?

Legyen akkor a 18F45K20 az egyik. Mivel AVR tipusokat nem követem, nemtudom ott melyik a csúcsváltozat, inkább rád bízom a választást.

De ennek a ki fejezi be előbb tesztnek szerintem nem sok értelme, főleg azonos órajelről. Talán a maximális órajelről járatva mindkettőt, lenne értelme összehasonlítani a sebességet. PIC-nél ez jelenleg 64MHz egy 18F45K20 esetén, ami 16 millió utasítást jelent durván számolva. AVR-nél talán 20MHz (de lehet, hogy egyes tipusoknál magasabb) a max órajel, ami 20 millió utasítást jelent másodpercenként. Tehát sebességben szinte biztosan az AVR jön ki jobbnak. De a nyers erőre ritkán van szükség, szerintem a külsőségek összehasonlítása gyakran többet jelent.

Az a baj, hogyha csúcstípust választok akkor megint nem valós az összehasonlítás.
Mert akkor fogok egy MP3-as processzor típust. Benne az mp3 dekóder, benne DAC, benne a CF+MMC+SD kezelés, benne a kijelző meghajtó, benne a step-up és a charger controller, USB2.0. És mindez egy 1500Ft-os processzorban.

USB alapján összehasonlítás terén meg az AT90USB tapasztalat alapján jóval gyorsabb pl. mint mass storage drive.
CAN alapján a PIC CAN típusokat annyira nem ismerem, egy típussal volt eddig dolgom, így abban csak az AVR terén tudok tapasztalattal szolgálni.

Egy 18F452 vagy 18F4520 és egy ATmega32 lenne talán a jó összehasonlítási alap.
Mindkettő 32K-s. És mindkettő kommersz, nem cél specifikus mikrovezérlő.

Vélemény, ötlet?

topi!

elolvastam az összehasonlítást, és egyetlen apró dolgot hiányolok belőle, méghozzá a termékek elérhetőségét. azaz magyarországon mennyire hozzáférhető az egyik és mennyire a másik. a dokumentáltságról volt szó, de a "bemegyek a sarki boltba és leveszem a polcról, vagy úgy kell vadászni egy-egy példányra" szintén egy komoly összehasonlítási alap. ja és itt leginkább arra gondolok, hogy azon kívül, hogy könnyedén beszerezhető, mennyire van megkötve az ember keze vásárláskor a mennyiséget tekintve.

félreértés ne essék, én még egyiket se próbáltam ki. de! az atmega8515 lett volna az első áldozat, ha sikerül hozzájutnom, mivel csak azzal találtam 640*480-as monokróm lcd panel meghajtót, de sajnos sehol nem sikerült venni, és ahol egyáltalán forgalmaznák, ott 10-es tétel volt, amit legalább venni kellett volna (persze egyet elfüstölök a hozzánemértés miatt, egyet véletlen elvesztek, egyet megeszik a kutya, de a maradékkal mit kezd az átlagember?)

amúgy az összehasonlítás nagyrészt kielégíti a kíváncsiságom, köszönöm, hogy elkészítetted.

Sziasztok
Olvastam a cikket és ahogy Topi leírta kb 4szer, hogy évek óta fejleszt én is hasonlóképpen évek óta fejlesztek mikrokontrollerekre. Néha több száz példányos projecteket tervezek.
A cikk kicsit rövid lett hiányolom a személyes tapasztalatokat, történeteket, nem csak kezdőknek.
Pár infóval, tapasztalattal bőviteném a közös infóhalmazt, nem korlátozva 1-1 procira.

AVR programozása:
-ISP ez szinte mindegyik procinál megtalálható, kell az oszcillátor és soros (LPT 300Ft)
-JTAG ez nem csak debuggol, hanem programoz is! Azaz egy csatlakozón (TMS TSCK TDI TDO) lehet debuggolni és programozni is, ehhez is kell oszcillátor.
(pl JTAG ICE)
Ez nagyobb prociknál van ATMEGA32>
-Nagyfesz programozás. Ez akkor jön jól, ha "kizártad" magad a chipből. 12V körüli fesz kell neki és párhuzamossan oszcillátor nélkül újraprogramozza a procit / fuse biteket
-És van a bootloader.

Érdekes dolog még az overclocking. Azaz az órajel túlhúzása. Sok procit kipróbáltam PIC és ATMEL-ek közül. (Ha lehet ne csináld, mert nem garantált a sérülésmentesség)
Szóval a tapasztalat, hogy a PIC-eket kb 110%ig lehet túlhúzni, amikor még stabil és nem hibázik.
Az AVR-ek kicsit meghökkentőek. Pl ATMEGA64L (most ebből landolt sok nálam) ami az alacsony fesz miatt 8Mhz menne, túlhúztam 20Mhz-ig. Programzható és tartja is a sebességet.
Az ATMEGA88 ami 20Mhz-en menne hivatalossan, azt 54Mhz kristállyal is meghajtottam és stabilan hibamentessen futott. Azaz a frekinek beírt 54Mhz és az abból számolt 460800baudos UARTja hibátlanum kommunikált a kamerával és mindent kirakott szépen a színes LCD kijelzőre. (Ha az órajel nem lenne stabil, az UART tévesztene)
Ez akár hogy is számoljuk 250-270% futási sebesség.
Viszont 40MHz fölött nem engedi programozni magát, (ilyenkor kristálycsere volt a foglalatban)

És (ahogy Topi is leírta) azt se felejtsük, hogy amíg az ATMELnél 1 órajel az 1 utasítás, addig a PICnél 4 órajel az 1 utasítás.
Tehát egy 54Mhz-en futó ATMEL az 216Mhz-s PICnek felel meg! Uhh...
De számoljuk a legális frekvencián. Az olcsó egyszerű ATMELEK amik mennek 20Mhz-n az 80Mhz-es PIC-nek felelne meg, ha lenne.

AVR ügyben van ennél tovább is. AVR tudással jöhetnek az ARM procik. Itt az órajel már SAM7 eseknél 33-66Mhz és SAM9-eseknél (belső) 200Mhz fölötti órajelek vannak. A SAM11-család már jóval ez felett van. (600Mhz)
A mostani telefonok/PDA/PNA/GPS készülékek nagyrészében ARM proci van!

Szerintem fontos összehasonlítás még, hogy az AVR memóriája bővithető. Ami azt jelenti, hogy külső SRAM EPROM "huzalozható" a procihoz és programutasítás HW lekezeli. A PIC nem bővíthető ilyen egyszerűen.

A PIC32 már sokkal fejletteb. Én spec. még nem használtam, arra nem vonatkoznak amit leírtam.

Azt szokták mondani, hogy kezdőknek PIC javallot. Én úgy gondolom, hogy a PIC és az AVR asm-je nem nehezebb a másiknál. A proci architektúrájában talán az AVR még egyszerűbb is. És a kezdők elég árérzékenyek (programozó és halott chipek ára) Így én AVR-t választanék újra. Bár az igaz, hogy a PIC magyar nyelven támogatottabb.
Annó amikor még alig volt választék és a PIC procikat még UV fénnyel töröltük (OTP) és böszme 40eFt-s programozókkal kellet programozni, akkor nem volt ilyen választási lehetőség. Az 51-es sorozat nem kezdőknek való volt.

Szóval ha nem tudsz angolul és kezdő vagy, akkor irány a PIC. Programozó + próbapanel (amit hamar ki lehet nőni) és javaslom, hogy ne 16F-es sorozattal kezdjetek, mert a 18F nem bonyolultabb, sőt kevesebbet lehet szívni pl a memórialapozás hiánya miatt és az USB se hátrány és több memória van benne.
Ha pedig tudsz angolul, akkor olcsón meguszod az AVR-el. De javasolt egy JTAG programzó a nagyobbakhoz. Itt a fejlődés határa a csillagos ég

Most van pár durva proci nálam, amihez időt és "erőt" kell gyűjtenem. Duál core, azaz két ARM7TDMI procimag van benne. 32bites RISC, 2Mbyte Flash, 128K EPROM, 2x32K SRAM. Ha valakit ez komolyan érdekel, kooperálhatunk, proci van.

sztm

Sziasztok Inteles tanulmányaim után próbáltam áttérni PIC-re népszerűsége okán.Beszereztem a fellehető nyomtatott irodalmat,aztán értetlenül böngésztem a könyveket,jegyzeteket.Képtelen voltam jó szintre vergődni a programozásukkal annyira idegen volt a felépítés,elnevezések (hozzáteszem erről nem a szerzők tehetnek,mert nagyon jó szakírók:Kónya,Madarász),de láttam nem velem van a probléma,ha pl. egy másik cég külön macroasm készletet fejleszt a PIC-hez.Próbaképpen letöltöttem egy pár AVR doksit,rögtön láttam,hogy ez az én világom,elég volt csak a dokumentumok igényes kivitelére tekinteni.Szóval én az asm tanulhatóságot is az AVR-nek adnám, bár ez a végeredményen nem változtat

Mostanában kezdek átszokni erre a fórumra, bár már rég ismerem, de ritkán látogatom. Kezdeném egy velős flamel.

Kb. 10 éve programozok mikrokontrollereket. Először, mikor kezdtem, érdeklődtem az ismerősöktől és az AVR-t javasolták, hogy az a tutti. Mai szemmel kicsit furcsa lehet, de a 90-es évek közepe, vége felé még az igen drága percdíjas dial-up internet is csodaszámba ment. Elég kezdetleges honlapok voltak és a pdf-ek ugyan léteztek, de egy normálisabb leírás egy fél óra alatt jött le..., inkább CD-n és nyomtatott formában volt elérhető az info. Írtam a Codixnak(, akkor tudtommal ők voltak a legjobbak AVR-ben, SOS, MSC, ..., még akkor nem volt), hogy szeretnék ismerkedni az AVR-ekkel, jó volna valami info. Természetesen kifizetem a költségeket, CD, posta... Annyit írtak, hogy nem tudnak küldeni, nincs CDjük. Írtam az Atmelnek, ha jól emlékszem, nem válaszoltak. Írtam a ChipCADnek, 2 nap múlva ingyen küldtek duplaCD-t, nyomtatott anyagokat. Ezzel eldőlt a PIC/AVR kérdés.

PIC16F84-el kezdtem + Jens Dyekjaer Madsen sokat emlegetett programozójával. (bár nekem elég jól működött)

Ami szerintem a fő probléma a microchippel, hogy túl sokáig nem történt igazi fejlesztés, a PIC16 sorozatot toldozták csak. Rengeteg PICes szakit vesztettek el a 90-es évek végéig a következők miatt: hiába jött ki a 877, amibe beletették az I2C, SPI-t, USART-ot, ..., ezt kín programozni. Tudom, ez vélemény, szubjektív, de nagyon sokan mondták az, hogy ők nem fognak bankolgatni, lapozgatni, ..., ráadásul korábban normális C nem nagyon volt PICre, ezért mentek az AVR-hez. És szerintem ez az oka annak, hogy még 2008-ban is olyan kritikákat lehet olvasni ebben a topicban is a PICekről, ami már nem aktuális. Tehát a 18-as család a fő problémákat megoldotta, de túl későn. Hobbiszinten nem gond, ha az ember elbogarászik egy programmal néhány hétig, esetleg kell foldozgatni, de a hivatásosoknál ez nem nagyon működik. Egy céges munkánál viszont az idő és pontos működés jobban felértékelődik. Nekem is vannak cuccaim, ami ha kiesik, akkor napi többtízezer forint veszteséget jelent, ill. vannak, amik külföldre mennek. Ezeknél nagy gáz, ha nem jó elsőre. Ezért a PIC16-ot sose szerettem a bankváltás, lapozás, kevés ram miatt, és nem is nagyon használtam olyan helyen, ahol sok perifériával kell dolgozni. PIC18 viszont nagyon jó.

Néhány éve kíváncsiságból elkezdtem mégis AVR-ekel foglalkozni, mert annyira dicsérték az átgondolt logikus felépítésüket, itt is sokan ezt teszik. Hát nem tudom, biztos bennem van a hiba.

PIC-et C18-ban kódolom, de sokáig asm-ben kódolom. Én azt mondom, hogy kell tudni ASM-ben kódolni, ebben lehet megismerni a procit. C a gyorsaság, átláthatóság, kényelem miatt kell.

Megjegyzem, hogy több éve nem foglalkoztam AVR-el, így elég homályosak az emlékek.

Összehasonlítás:
sebesség:
Ki szokták emelni az AVR-esek, hogy a legtöbb utasítást 1 ciklus alatt végzi el az AVR, ezért alacsonyabb frekvencián is nagyobb sebességet tudnak PICel szemben. Ezzel egy baj van. Az AVR nem tud a RAMban aritmetikai és logikai műveleteket végezni, ezért mindent be kell húzni a GPR-be, elvégezni a műveletet és visszaírni RAMba. A PIC ezzel szemben a munkaregiszter és a RAMban bárhol lévő regiszter között tud műveletet végezni és közvetlenül az utasítás végén megadjuk, hogy hova kérdjük az eredményt. Tehát jóval kevesebb lépésben oldja meg a PIC. Tény, hogy RAM esetén bankolváltásra lehet szükség, de a 18-as családnál ez igen ritka több okból is. Szóval MIPS != valós teljesítmény
Még egy érdekesség, hogy én a projectjeim 90%-ához 4-10MHz-es órajelet használok. uC nem PC, különösen nem a 8 bites. Még lehetne rizsálni erről, de nem húzom.

32 GPR
Másik gyakori érv, hogy a PICnek csak 1 munkaregisztere van (W), az AVR-nek 32. Az előző pontban leírtakból kiderül, hogy a PIC esetén nem is indokolt több. Ill. az AVR esetén a 32 nem egészen 32, ugyanis nagy része nem használható, csak meghatározott feladatokra.

Logikus felépítás/több utasítás.
Na ez kb. akkor omlott össze bennem, amikor ilyeneket olvastam az adatlapban, hogy bizonyos biteket (nem mindegyiket) úgy kell törölni, hogy 1-re állítjuk. SBR-el, azaz SET utasítással kell törölni. Vagy pl. amíg a PIC esetében bármelyik bitet törölni tudjuk egy BCF utasítással, legyen az Carry, Zero, Port, Flag, vagy egyszerű RAMterület, ill. BSF utasítással 1-re állítjuk, addig ugyanezt AVR esetén 20, azaz húsz utasítással tudjuk elérni. Nem mindegy, hogy portláb, GPR, ... Sajnos már megkopottak az emlékeim, de ha jól emlékszem, van amit csak maszkolni lehet, tovább rontva a helyzetet. Ugyanez igaz az adatmozgatásra is, amíg a PIC néhány MOV utasítással mindent megcsinál, addig AVR esetén ugyanerre van LOAD, STORE, MOV, IN, OUT, ... attól függően, hogy honnan hova. Az már csak vicc, hogy a PORTA, PORTB, ...-t IN-el olvasom be, a PORTF-hez LDS -kell. Mikor elkezdtem AVR kódolni, majd megőrültem, mire kikerestem az adatlapon, hogy mikor melyik utasítást kell használom.

Flash/EEprom írás száma
A legtöbb PIC18 esetén ez 100ezer/1millió
AVR 10ezer/100ezer
Fejlesztéshez bőven elég az AVR is, bizonyos alkalmazásoknál jól jön, ha viszonylag nagy területet (program memória) tudunk gyorsan írni non volatile módon. Ráadásul pl. C18 -ban ez nagyon könnyű, úgy írja, mintha a ramban lévő változót. Bootloaderes cuccoknál is jól jön a sok írás lehetősége.

kicsukás: már volt róla szó

Van egyébként egy eeprom bug is, mégpedig AVR esetén általában a 0-ás címet fenn szokták tartani, és erre állítják a címző regisztert, mert hajlamos írkálni az eepromba.

Hirtelen ezek jutottak eszembe, főbb kritikaként. Még egyszer megjegyzem, hogy sok éve nem foglakoztam AVR-el, sőt mélyen sose másztam bele, de remélem, hogy nagyjából helyesek, amiket írtam.

AVR esetén 2 nagy előnyt emelnék ki.
- vektoros interrupt
- perifériák általában jobbak, több mindent megcsinálnak hardveresen

Topi féle cikk elég sánta szerintem is, 877-et nem illik hasonlítani ATmegával. C18 szintén ingyenes a korlátai pedig lényegtelenek. Az extened instruction set használata PIC esetén meggondolandó. A free C18 tökéletes. Tudok írni én is olyan összehasonlítást, hogy 20:3 -ra nyerjen a PIC

Én csak egyet nem értek. Miért akar mindenki C-ben programozni? ASM. Ez az ami kézben tartja a hardvert. Nyomattok egy pár C utasítást és gőzötök sincs mi történik. Úgy igazából. Ha meg C library-ket használtok teljes a sötét folt.
Mondom mindezt úgy hogy PIC-hez megvan a C18 és a C30 full verziós fordítóm, tehát 8, és 16 bitre tudok full verziós korlátlan C progit írni. Anyámat előbb ölném meg minthogy C-t használjak MCU-hoz. mikrokontrollerhez mikrokód való.

10 éve használok PIC-et. ARM technikailag érdekel, de lassan barátkozom. Anno PIC16, aztán PIC18, most a kocsimhoz fejleszem a full új elektronikát CAN busszal. PIC24HJ256GP610-et használok. Mindig az adott család legerősebbét az asztalon. A 16 bitesnek ez a legbővebb változata. (igaz 3 hónapja nem néztem a katalógust...) Soha semmi bajom nem volt egyikkel sem, a váltás "csupán" a haladást jelezte.

Órajel: PIC16,18 effektív 1/4-es, a 24 az 1/2-es a PIC32 viszont már 1/1 -en fut. Tehát microchip tanul és fiigyel kifelé. Ahogy észrevesszük felfelé haladva a kínálat nem olyan széles. A 16-18nál megtanulták hogy mik azok a kulcs variációk amik kellenek:
Nekem pl az kellett hogy mindenből legyen bőven. 100 láb, 2-2-2-2 I2C, SPI, USART, CAN. Memória dögivel (256k) és kész. TQFP100. Kell több? Sajnos igen mert 800x480 szines LCD-t lehet nem tud meghajtani mert "lassú" erre asszem CPLD-t fogok használni.

Perifériák: Én eddig mindent meg tudtam csinálni. Vannak olyan dolgok amik persze készen kaphatók és fölösleges vele terhelni a PIC-et szoftveresen. Pl: Minek a FAT32-t kezelni 40pin-es IDE felületen ha van rá Vinculum, csak Pendrive kell hozzá.

Programozás: ebay: 50$ egy ICD2 klón. 7000Ft. Most nem mindegy hogy amiből kell egy darab az 7000 vagy 3000? Eccer kell megcsinálni....
Ok, AVR-t pár dróttal programozod. És az senkit nem zavar hogy mondjuk azon a pár dróton jól visszaüt a kísérleti panel a PC-nek? Adott esetben már lehet jobban jönne egy kevésbé mezitlábas programozó.

Egy szó mint száz, a két MCU elérte azt a szintet hogy már nem csupán észérvek sorakoznak mellette. A cégek nem hiába menedzselnek egyetemeket. Amit a diák ott megismer nagy valószínüséggel azt fogja preferálni amíg csak lehet. 50 project után most először kell újat tanulnom. CPLD. Mert muszáj. Semmi másért...

Továbbá: PIC24-nek már van 16 W-je. Igaz a stack is, de hát ha már 5. mélységben vagyok akkor jól el kell ásni magam hogy nem tudom eccerűbben megcsinálni...

Ha valóban ilyen mindenes vagy és ilyen sokmindenhez értesz ilyen mélységekben, el ne merészeld hagyni az oldalt a közeljövőben!

Nem vagyok nagy spieler. Éppen amire szükségem van abba mélyedek el rendesen. + a nagy álltalánosságok amik az ember fejében marad. Most éppen egy nagyon kezesbárány ECAN modult csinálok PIC24-en.

Teszteléshez a PIC24 saját 2 db CAN moduljait használom tehát kiküldöm 1-en, veszem 2-n... Már működik patentül, DMA meg minden. Most éppen pofásítom a programot. A cél az autó teljes ECAN busz-ra fűzése.

Egy itteni sráccal "dolgozom" össze. Bár ő nem sűrűn ér rá, de inspirál. Szóval ez van. Nem tartom magam nagy fejnek, inkább kitartó vagyok. Munka mellett 4 hónapja nyomom a CAN modult igaz közben rengeteg járulékos melót csináltam, és ne feledkezzünk meg a főállásról...

Egyébként egy történet arról hogy mennyire kell az ASM, és milyen jó a microchip support-ja.
A ECAN busz fejlesztése során kiderült hogy az ECAN regiszterei a PIC24-ben bankolva vannak. Illteve ezt tudtam a reference manual-ból. Egy bit (WIN) állítgatásával lehet lapozni. Aztán közben kiderült hogy vagy 6 regiszter noha léptetett végrehajtás során megváltozik (mert visszaolvasva kiderült hogy tényleg) a Watch window-ban nem látszott. Peírva a 24/7 Technical Support-ba a következő (most megjelent) 8.14 Mpalb verzióban kijavították az ECAN modul ilyen jellegű hibáját. Sűrű köszönetek közepette köszönték meg a segítséget. S noha próbáltak C30-ra téríteni (marketing duma), megmondtam nekik hogy egy igazi férfi asm-ben programoz, ahogy a zászlóaljparancsnokom mondta vala...

Na ez az amit az ember C-vel észre se vesz. Elsiklik fölötte. Mint aki jól végezte a dolgát. S lövés sincs róla hogy van e hiba vagy nincs. Csak a remény...Ezért kezelhetetlenek a programok....

Idézet:
„Na ez az amit az ember C-vel észre se vesz. Elsiklik fölötte. Mint aki jól végezte a dolgát. S lövés sincs róla hogy van e hiba vagy nincs. Csak a remény...Ezért kezelhetetlenek a programok...”

150%-osan egyetértek ezzel.

...20 utasítás !? tényleg nagyon régen volt ,az adatmozgatás elkülönítése sztem olvashatóbbá teszi a programot de akinek ez nem tetszik Atmel-nél van fennt egy macro erre az esetre....

Az a baj, hogy Te abból indulsz ki, hogy csak az programozik C -ben, aki asmben nem tud. Ez sokszor igaz, de mégse kellene 100% -os szabálynak tekinteni.

A másik dolog, hogy nem tudja, hogy mit csinál a uC is tévedés. A library-kben ott van minden függvény forráskódja.

Azon gondolkozz el, hogy a legtöbb vadászrepülőgép szofterét is C/C++ ban esetleg Modula-2 -ben írják. De az újabb autókban található nem kevés mikrovezérlőt is többnyire C/C++ -ban programozzák. Valószínűleg nem azért, mert olyan buták, hogy nem tudnak asm-ben kódolni. Ilyen helyeken top programozók vannak.

A C-nek rengeteg előnye van az ASM-el szemben, de mégis a magasszintű nyelvek közül a leginkább hardverközeli. Ezért szokták magas szintű assembly-nek is nevezni. Általában felesleges az egész programot asmben írni, ha olyan helyzetbe kerülünk, ahol szükségesnek érezzük az asm-et, akkor azt a pár sort megírhatjuk a C-ben asm betétként.

Nem akarok túl mélyen programozás elméletekbe belemenni, de tömören magas szintű nyelveknél (C, Pascal, ...) ha valaki ugró utasítást használ, az nem tud programozni. Sok tanár azt mondja, hogy 2-esnél jobb jegyet nem ad egy diáknak, ha urgó utasítást használ még akkor sem, ha jól működik a program. Könyvek is jelezni szokták, hogy ne használjuk goto-t. Azért, mert mindent meg lehet oldani nélküle. Az ugrás ill. az átlátható, szép, olvasható program összeegyeztethetetlen egyással. Viszont az asmnek szerves része, ott az ember állandóan ugrál. Asm-ben nem lehet szép, olvasható, tömör kódot írni. Még tudnék regélni, de túl hosszú lenne...

A 20-at bit törlés/ 1-re állításra írtam.

CBR, CBI, CLC, CLN, CLC, CLI, CLS, CLV, CLT, CLH

Ez 10 db, set párjával együtt 20db. Ugyanerre PIC -en van BCF/BSF. Ez 2db.

Mikor elkezdtem AVR-ezni, engem nagyon zavart ez a sok utasítás.

Az avr-nél is kettő: BSET,BCLR ...több olyan asm utasítás is van,ami ugyanazt a gépi kódot adja és a programozó eldöntheti melyik szimpatikus pl: CLI , BCLR 7

mielőtt erre járna egy avr-es és pontosítana :
ez a két utasítás 16-ot üt ki értelemszerűen az általad felsoroltakból...sbi,cbi,sbr,cbr utasítások vannak még erre a célra tehát összesen 6 db.

Imádok vitatkozni....
Szerinted aki keres a neten egy Library-t, mondjuk ECAN modulra, az át fogja nézni hogy mi van benne? Max akkor ha nem működik. De akkor is lehet előbb keres mást mint a rossz libet debuggolja.

Ok. Mit tekintesz goto utasításnak?
Mert pl egy btfss (bit test file skip if clear) is adott esetben egy goto, igaz csak a következő utasítást ugorja.
Azt mondják hogy a C nyelvű program egy csomó apró praktikus függvény hívása. Függvény = call utasítás. Nos ugyan ezt csinálom csak asm-ben.

Makrókat és call utasításos "függvényeket" csinálok. Nem lehetetlen. Szóval nagyon is lehet szép programot csinálni. Szépen használom a tab-ot pl, ahogy a képen. 42-46 sorokat ajánlom figyelmedbe. 42. sor pl azért van hogy látszódjon hogy mi micsoda. Mint egy táblázat. Nagyon sokat segít.

Az a bajom PIC C-vel hogy ICD2-t használok. nyomom F7. Egy utasítás végrehajtása. És azt látom hogy 10-et lép a program. Hogy mi történik? Ki tudja? Ja persze ha átmennék a program memory window-ba akkor persze látnám. A képen látható kommentek nélkül. Na nem...
Másik bajom: hex-hez ASM-en keresztül vezet az út. C fordító tehát egy köztes lépés, azaz hibalehetőség. Kihagyható, tehát nem kell.

Ha már egyébként hardverről volt szó, ez az én játékszerem ahogy a második képen látszik. Középen a PIC, mellette a space, egy másiknak. Jobb felül az ICD2, bal felül egy 12V-os táp. A PIC fölött a CAN transciever van összerakva a felső vékony +- dugasz panel maga a CAN busz fizikailag. Ott van visszakötve a ECAN1 modul a PIC ECAN2 moduljába. Így egy azon pic-ben lekövetem a teljes adatáramlást a buszon. Tudom ajánlani minden más perifériával kapcsolatban is. De ez kicsit off, elnézést érte.

Ezzel az a problémám csak hogy igazábol szerintem elég jól dokumentált a programozás folyamata a pic-nél
(külön adtalapban van benne) ábrákkal, folyamatábrákkal az algoritmusok std.
Pickit 2 meg "nyiltforrású" szoftver és hardver !
van még AN doksikban programozókapcsolás más is