Fórum témák
» Több friss téma |
Fórum » PIC vagy AVR
Témaindító: (Felhasználó 466), idő: Okt 5, 2005
Témakörök:
Idézet: „Fejlesztői eszköz Egyazon tudás alapján: ICD2 MPLAB ICD2 = 27 000 Ft AVRDragon ATAVR Dragon = 13 000 Ft” ICD2 meg Pickit 2 lassan kezd közel ugyanazzal a tudással rendelkezni. Hiszen programoz, és debuggol (és egyre bövitik a listát amit támogat) Pickit2 támogatott mcu listája Idézet: „Szanaszét pakolják a programozó lábakat, nehéz bekötés (1-esen reset, 39-40-esen PGD PGC, középtájon a tápfesz).” Hát itt inkább csak azt irtad volna hogy a programozáshoz szükséges lábak és a tápfesz van külön szerintem a többi tokozástol függetlenül egy csokorban van  DIL ic tetejénelél MCRL, rb7, rb6 bár ez már magánvélemény  Idézet: „Programozás sebessége Lassabb. Gyorsabb, AVR-nél a cél a gyártásban való maximális sebesség. Gyártásban, ipari célokra előszeretettel használják.” Sebessegég szerintem nagyban függ az eszköztöl amit használsz. Hobbi alkalmazásban szerintem mindegy hogy 10 vagy 20 sec Ha tényleg nagyon sokat kell felprogramozni akkor ott a lehetőség hogy microchipnek elküldöd és ök rendelésre előre gyárilag programozott és tesztelt ic küldenek  Idézet: „Maximum = F_CPU/4 Timerek nem képesek a rendszer órajel 1/4-énél gyorsabb járásra. Maximum = F_CPU Tehát, a timer képes a rendszer oszcillátor-sebességével járni.” Ha ez zavar gondolj arra hogy pic16/18 családnál belül minden ugy müködik mintha külső órajel 1/4 vennéd. Innentől kezdve meg természetes hogy 1 utasítás is meg egy timernövelés is minden 4. órajelre következik be (ha nagyon bántotta volna microchipet ez külső órajel elé rak egy PLL hogy felszorozza 4-el) és te ne tudd mi történik belül. Idézet: „PIC16F877 = 14K/1350Ft => 96,4 Ft/kB ” Pic16f877 hivatalosan elavult uj "dizájnhoz" nem ajánlott chipcad árlistábol: PIC18F4550-I/P PDIP.............. 740 Ft +áfa PIC16F887-I/P PDIP.............. 370 Ft + áfa PIC16F887-I/P: 14k/ 444 ft ........ 31.71 Ft/kb?? nem teljesen igaz mert nem 8 bites a flash memória rekesze PIC18F4550-I/P: 32k/888 ft ........ 27,75 Ft/kb (itt már tényleg kilobájt) ui: 877a a hivatalos utódja 877 de van külön dokumentálva a honlapon a "migráció" 887-re vagyis a doksi ami a külömbségekre van kihegyezve pl fejlettebb perifériák, egyszerre több bájtot ir és töröl "önprogramozáskor" Ja és természetesen az ic-k ár-arány nagyban függ a "népszerüségtől" ill kereslettől tehát nagyban függ a választott tipustol
Ismered mindkét márkát vagy csak nyomod a monológot ?
Ja és nekem egyértlemünek tünt hogy pic16 családot vetted csak figyelembe (abbol is a régi tipust) a cikk megirásakor és nem igazán értem miért?
pic 18 család iagzán alkalmas lehet kezdöknek szerintem még valami c -ben való programozással meg mi a bajotok ha nem kell nagyon preciz, nagyon gyors rész akkor megirod c-ben (gyorsabb egyszerübb) a kritikus dolgokat meg megoldod asm betétként. és szerintem 2-4 kantitással meg megnézheted milyen asm kódot generált belőle a fordító. ha nem bizol benne. üdv.: egy unatkozó munkanélküli aki azt se tudja mifán terem a mikrokontroller és nyugottan javitsatok ki ha valahova hülyeséget irtam Ja és még 1 dolog: ic simert hibái mindeg letölthetők a Microchip honlapról kiküszöbölésükkel együtt
Mivel nem irtam semmit a AVR-ekről igy gondolhatod:
-AVR ekkel futólag találkoztam csak
Szerintem teljesen fölösleges a felprogramozás idejét firtatni. Gondoljatok bele abba amikor tok ki, programozóba be, áramkörbe vissza, anyázás, és ugrás az első pontra. Nuku ICD meg Logic Analiser. Ehhez képest arany az életünk... Minden a képernyőn van...
ASM: Én ASM-et két okból használok. Egyik hogy próbáltam a C-t de valahogy nem fekszik. Óriási hiányosság nekem ez, mert majd ha a CRX-hez a PC szoftvert kellene írni nos ott lesz orális szex.... Másik pedig, hogy meggyőződés. Anno amikor PIC-el kezdtem foglalkozni mindent kipróbáltam csak hogy ASM-et ne kelljen. 6 hónap után beláttam hogy ASM ami kell. Nem mondom hogy a C nagyon fölösleges de MCU-nál véleményem szerint egy bizonyos szintet nem lehet átugrani ASM nélkül. Tehát C nélkül megélhet az ASM programozó MCU-n, de aki csak és kizárólag C-ben tudja használni az MCU-t és nulla kilóméteres az ASM-ben az szerintem halálra ítélt hosszú távon. Egyszerűen a hibakereséshez és a 100% képben léthez tudni kell lépésről lépésre hogy mi történik. PIC24 ECAN-nál a lapozós ECAN SFR regiszterek miatt pl át kellett rendeznem az init sorrendjét. Először logikusan csináltam a sorrendet. Bit timing, mask, filter, bufferek, stb. Utánna meg úgy kellett hogy először a 0-ás lap aztán az egyes. Mert másképp nem ment. Na ezért kell az ASM. Képbe lenni... Idézet: „Timerek nem képesek a rendszer órajel 1/4-énél gyorsabb járásra.” Már hogyne lennének képesek? Most éppen 25 MHz-cel kergetem az egyébként 8 Mz-en ketyegő PIC16F690 Timer0-ját, de 50 MHz-ig is hajhatnám, ha lenne hozzá órajelgenerátorom. A Timer1 pedig az adatlap szerint kb. 33 MHz-ig hajtható. Na, ha jól vagyok tájékoztatva, akkor EZT nem tudják az AVR-ek, ezért maradok a PIC-nél, mert nekem éppen nagy sebességű (kis holtidejű) impulzusszámlálók kellenek. Persze, a PIC16F690-nl most flancolok (kényelmes, hogy a soros portján és a PicKit2-őn keresztül mindjárt a képernyőre is kiírathatom a tesztprogramból az eredményt), de a végleges változatban a 8 lábú PIC12F629 is ugyanigy megfelel.
Nem olvastad el rendesen azt a mondatot, amit idéztél. Rendszeren belüli timer "ketyegésről" van szó. Nem rendszeren kívüli órajellel való hajtásról.
AVR-ek esetén is hajthatod a timert külső órajel esetén akár gyorsabban is, de itt én a belső rendszer órajel és a belső timer kapcsolát írtam le. Idézet: „Ha, ha jól vagyok tájékoztatva, akkor EZT nem tudják az AVR-ek” Rosszul vagy tájékoztatva. AVR esetén is lehet a timert más órajelről hajtani, ott is, akár 50MHz-es is, minden gond nélkül. XMEGA esetén meg jócskán képes 32MHz-es RENDSZER ÓRAJEL-ről működni. Idézet: „Rendszeren belüli timer "ketyegésről" van szó.” Ebben nincs különbség: PIC-nél és AVR-nél is 1 utasítás az időalap. Annak nincs gyakorlati jelentősége hogy egy utasítás hány órajelfázisra oszlik belül. Annak van jelentősége, hogy a PIC 16F sorozat "csak" 5 MIPS, az AVR meg 16 MIPS. De akit ez izgat, az használhat 18F sorozatú PIC-et (10-12 MIPS) vagy 16 bites PIC-et (16-40 MIPS). Idézet: „AVR esetén is lehet a timert más órajelről hajtani, ott is, akár 50MHz-es is, minden gond nélkül.” Konkrátan melyiknél? Mert az Atmega16-nál azt olvasom az adatlapban, hogy a külső órajelet szinkronizálja, s az emiatt nem lehet nagyobb, mint a belső órajel fele (tehát 16 MHz-es órajel esetén 8MHz)! Idézet: „Each half period of the external clock applied must be longer than one system clock cycle to ensure correct sampling. The external clock must be guaranteed to have less than half the system clock frequency (fExtClk < fclk_I/O/2) given a 50/50% duty cycle. Since the edge detector uses sampling, the maximum frequency of an external clock it can detect is half the sampling frequency (Nyquist sampling theorem). However, due to variation of the system clock frequency and duty cycle caused by Oscillator source (crystal, resonator, and capacitors) tolerances, it is recommended that maximum frequency of an external clock source is less than fclk_I/O/2.5. An external clock source can not be prescaled. ” Idézet: „XMEGA esetén meg jócskán képes 32MHz-es RENDSZER ÓRAJEL-ről működni.” Nem vitatom, hogy az XMEGA nagyon sok vonatkozásban felülmúlja a PIC16F629-et vagy a PIC16F690-et.
Atmega16 adatlapjában úgy néz ki mintha a timer1/counter1-ben nincs ilyen kikötés, csúnya lenne ha az AVR ne tudna ilyet...
De én még nem próbáltam ki...
Idézet: „Atmega16 adatlapjában úgy néz ki mintha a timer1/counter1-ben nincs ilyen kikötés” A 16 bites Timer/Counter1-ről beszélsz? Ott azért nincs leírva ilyen kikötés, mert visszahivatkozik a 87. oldalra, ahol az a szöveg található (a T1/T0 bementre vonatkozóan), amelyet előző hozzászólásomban már beidéztem. Idézet: „The Timer/Counter can be clocked by an internal or an external clock source. The clock source is selected by the clock select logic which is controlled by the clock select (CS02:0) bits located in the Timer/Counter Control Register (TCCR0). For details on clock sources and prescaler, see “Timer/Counter0 and Timer/Counter1 Prescalers” on page 87.” Én ebből azt a tanulságot vontam le, hogy ugyanaz a megkötés vonatkozik rá, mint a 8 bites számlálókra.
Csak egy idézet a Timer2 összefoglalóból:
Idézet: „Allows clocking from External 32 kHz Watch Crystal Independent of the I/O Clock” Mivel a fentebb említett proci (mega16) Timer2 modulja direkt órakristályra lett tervezve, így a rendszer órajeltől teljesen független működésű. Nem fő típust választva, hanem altípust választva (pl. mint a 16 helyett, 16x, 32 helyett 32x vagy mega128) ott már eltérnek a timerek belső felépítése is, mega128 esetén már több teljesen független timere is van. Ami tetszőlegesen hajtható. AVR esetén nem minden timert lehet hajtani rendszer órajeltől függetlenül, mert viszont AVR-eknél lehetőség van timerek 100%-ig szinkronban tartására. Pl. Phase Corrected PWM-nél és/vagy más olyan folyamatnál ahol két timernek független előosztástól, együtt kell járnia, ott csak a közös órajelről való mintavételezés a nyerő. (Nyquist) Egy szó mint száz, van olyan Timer modul a legkommerszebb prociban is ami hajtható függetlenül a rendszer órajeltől. Még az 1.8V-ról működü picoPower típusok is (pl 644p) is képes, 10MHz-es rendszer órajel esetén timert számoltatni 20MHz-ről. Míg PIC esetén 40 lábnál 36 IO-nál esetenként akár több timer is hajtható külön rendszernél nagyobb órajelről, ugyan azon lábszám mellett, a neki megfelelő AVR-ben mindig csak egy-egy, külön erre a célra méretezett timer van. Bár nem egyik vagy másik mellé szólás képp, de nem sok értelme van egy 10MHz-es rendszer órajelhez pl. két 20MHz-es timert járatni. Értelme = 0 Idézet: „Mivel a fentebb említett proci (mega16) Timer2 modulja direkt órakristályra lett tervezve, így a rendszer órajeltől teljesen független működésű.” Mármint 32 kHz-es órakristályra. Kösssz!  Illetve elvileg megkergethető a belső órajel negyedével: Idézet: „The Oscillator is optimized for use with a 32.768 kHz watch crystal. Applying an external clock to the TOSC1 pin may result in incorrect Timer/Counter2 operation. The CPU main clock frequency must be more than four times the Oscillator frequency.” Ennél tehát határozottan jobb a szinkronizált bemenőjelű számlálók számlálási sebessége. Idézet: „Pl. Phase Corrected PWM-nél és/vagy más olyan folyamatnál ahol két timernek független előosztástól, együtt kell járnia, ott csak a közös órajelről való mintavételezés a nyerő.” Valóban, beismerem, hogy az igényeim speciálisak, nem szokványosak. Ez az Application Note adta az ötletet az elinduláshoz. Idézet: „Mármint 32 kHz-es órakristályra. Kösssz!” Igen. Ezt emeltem ki. Hogy órakristály. Akkor felesleges rákontrázni, hogy kössz... Igen, az órakristály 32,768KHz-es. És igen, ez ahhoz lett direkt méretezve. Ez nem egyenlő azzal, hogy minden timere minden típusnak órakristályra van tervezve. Áhh... Mindegy.
Lemaradtam valamiről? mi történt?
Még semmi. Majd történni fog.
Hát, ....
Nekem kicsit ellenségesnek tűnik a Microchip vásárlási szándéka, főleg, hogy az ON Semi-vel közösen támad. Piacot akarnak venni, vagy technológiát? A mi szempontunkból ez az érdekes. A MCHP jó a gyártásban (ennyiféle processzorváltozatot gyártani, nem is értem, hogy éri meg), plusz van pénze, nagy megrendelései (tuti, hogy az autóiparból élnek - ugrókódos távnyitók.) Az ATMEL oldalán a komolyabb, skálázhatóbb architektura, professzinálisabb vevőkör áll. TKP. win-win is lehetne, a verseny sem szűnne meg, van még konkurrens gyártó, de az egycsipes szegmensben tuti letarolnák a piacot. Kiváncsian várom a fejleményeket... Az USA helyzetét tekintve nem csodálkznék, ha belemenne az ATMEL. Keep us informed!
Az lenne a nagy gól, ha a két típus előnyeit ötvöznék, s kijönne egy harmadik uPsorozat.
Idézet: „Nekem kicsit ellenségesnek tűnik a Microchip vásárlási szándéka, főleg, hogy az ON Semi-vel közösen támad.” A Microchip-nek nem kell az egesz gyar. Vilagosan leirta nem akarja az ASIC reszleget, ezert vont bele mast is, hogy ok a "maradekra" licitaljanak. Idézet: „Piacot akarnak venni, vagy technológiát? A mi szempontunkból ez az érdekes.” Hat 8 bitesek kozott nincs mit technologiat az Atmeltol atvenniuk. AVR nem nyujt semmi olyat amit a PIC-ek ne tudnanak. Viszont Atmel gyart ARM-eket is, ezt ne felejtsuk el! Ez jol johet most az uj PIC32 fejlesztesekhez is, az AVR32 meg amugy sem ment valami fenyesen. Idézet: „Az USA helyzetét tekintve nem csodálkznék, ha belemenne az ATMEL.” Igen, hat a piac eddig sem ment tul jol nekik, es most az amerikai valsag miatt valoszinuleg meg rosszabb a ehlyzetuk. De ugyis Norvegiaban dol majd el minden.
Ezt írtad:
Halihó! Először is bocsi, hogy egy egy hónappal ezelőtti off dologra reagálok de lenne pár apró hozzáfűzni valóm. Idézet: „Könyvek is jelezni szokták, hogy ne használjuk goto-t. Azért, mert mindent meg lehet oldani nélküle.” Elméletben mindent. Valójában néha C-ben is hasznos megoldás a goto olyan esetben amikor már nagyon "tele van" a hardver és/vagy bonyolult a kód. (A kódstruktúra megtartása túl sok memót vagy megnövekedett végreajtási időt igényelne és/vagy az adott kódrészlet utólagos absztrakciója értelmetlenül sok munkával járna...) zsimon Idézet: „megmondtam nekik hogy egy igazi férfi asm-ben programoz” Ez ugye csak vicc. Hogy is fogalmazzak... Nem tudom láttál-e már mondjuk egy USB vagy inkább egy IP stack forráskódját ?!? Egy kis Web,FTP-szerver, DHCP és máris 20-30 darab C modulnál tartunk. Na ezt ird meg és lásd át ASM-ben ( közben persze még X hardvert is helyesen működtessen) ! Persze, hogy jó képben lenni, hogy mikor mit csinál az adott fordító és hardver (uC/uP) de szerintem ehhez nem feltétlen kell ASM tapasztalat ... vagy legalábbis nem feltétlen az adott rendszerben szerzendő. Nyilván aki tudja, hogy miként működik egy multiplexer, az az MCU adatlapjából is megérti, hogy milyen hatással van ha átkapcsolja az oszcillátor szelekciós biteket (az ehhez tartozó kód kvázi ugyanannyi C-ben és ASM-ben is csak az előbbi még szabványos is). Lehetne még folytatni de ez szerintem kitérő, mégegyszer bocs a sok offért!
Van itt egy hírlevél, érdemes elolvasni:
Atmel - Microchip A lényeg, at Atmel nem adja magát (huhh....)
Szerintem az Atmel jol jart volna ezzel, de hat ez van. Mindenesetre most mar a Microchip-nek Januar vagy Februarban kijon az enhanced mid-range tipusa ami teljesitmenyben verni fogja az AVR-eket, es hat az ARM-ekkel pedig a 32 bites fronton probal teret hoditani - pl a uC Linux nemsokara kint van a 32 bites PIC-re. Remelem ezekbol a harcokbol mi felhasznalok csak a jo dolgokat fogjuk latni, bar meg kell jegyezni sajnos az Atmelnek nem megy tul jol mostanaban, es a Microchip bar joval nagyobb ceg neki is vannak gondjaik foleg az azsiai piacon - klonozzak a PIC-eket igy eleg nagy veszteseguk szarmazik, es raadasul a klonozo ceg sikerrel megtamadta par szabadalmukat, ami eleg erdekes fejlemeny. De hat Kinaban mint tudjuk nem eppen demokratikus modon intezik a dolgokat
Szia
Szerintem nem ) 1, a konkurencia versenyt gerjeszt, ami a felhasznlóknak (neked-nekem) jó. Kevésbé érdekel, hogy egy cég monopol helyzetben jobban jár. 2, szerintem az ATMEL jobb... PIC32 nemrég jött ki 72Mhz és az alap dolgokat tudja AVR32 már kiforottabb, és 150Mhz, LCD vezérlés max2048x2048(!!), camera interface, 2 ethernet, USB OTG, SDcard, AC97... és a többi alapcucc benne van... szerinted? És nem csak lesz rá linux, hanem évek óta van rá linux. Nekem is ilyen van AT32AP7000 Az Xmega sorozata (8bit) az ATMELnak 32 Mhz, ez olyan, mintha a PIC 128Mhz-s lenne... van ilyen? Évek óta használok PIC-eket és AVR-eket... kultúráltabb az AVR. Engem pl idegesít, ha össze vissza vannak a portlábak és azokból is lyukasan van a többség (pl PIC32) De nézzük (szerintem) miben jobb az AVR a PICnél XMEGA vs PIC enhanced pár dolog, ami az alapban is van: PIC 14 bites ATMEGA 16 bites Ez azért fontos, mert ha egy fix táblázatot teszel a programmemóriába (karakterkészlet, grafikus kép, zene, adat) akkor 2x annyi adat fér az AVR-be (16 bitre tesz 2x8bitet) és az kezelni is tudja a memóriából való olvasást: lpm temp,Z (1db utasítás). Ellenben az alap PIC-ekben ezt retw-vel tudod megúszni, ami 1byte/programhely és kb 3-5 utasítás kell hozzá, ami több utasitásciklus lesz a végén... A 8bites kategóriában az AVR 1 órajel/utasításciklus amíg a PIC 4 órajel/utasításciklus. Tehát a 16-20Mhz AVR messze veri a 48Mhz-s PIC-eket. Az Xmega az már 32 Mhz... Lesz a PIC-enhc 128Mhz? Xmega: PFlash: 256Kbyte 32Mhz 12 bites AD és DA is van! SRAM 4/8/16 Kbyte (hardver szinten bővíthető) 36-78 IO RTC 4 DMA stack: akár 4K + van benne szorzás: mul PIC enhc: PFlash: 56Kbyte ?Mhz (nem találtam konkrét adatot, de 40% gyorsulást említenek, de ez is 4órajel/cuklus) SRAM max 4Kbyte stack: max 16byte - Ami még lehuzza a PIC-et, az a bankolgatás, mostmár 32 lesz.. és a PCLATH Persze lehet C-ben ezeket észre sem lehet venni, de én ASM-ben használtam és látom, hogy mennyivel gyorsabb... A PIC32 nem ellenfele az ARM-nak... ARM11 már több mint 666Mhz, ellenben a PIC32 csak 72Mhz Rengeteg GPS típust/ mobilt javítottam, de PIC-el még nem találkoztam benne, ellenben a 70%ban különféle ARM procis volt. Még a GPS vevő modulokban is ARM van... (ha valami pontatlan, javítsatok ki nem volt sok időm)
Par megjegyzes ahhoz amit irtal
Eloszori is ez az 1 ora / 4 oras osszehasonlitas messze nem igaz, ezt az Atmel merketing osztalya talalta ki es baromi jol hangzik de egy igazi termek eseten nem lehet realizalni. Nagyon sok utasitas 2 ciklus, azonkivul abban a pillanatban hogy hozza kell nyulni a RAM-hoz mar az ebbol fakado sebesseg kulonseg eltorpul. LDS 2 ciklus, muvelet (mondjuk egy egyszerubb) 1 ciklus, STS 2 ciklus megint. PIC-nel 2x4 orajel (2x1 ciklus) ugyanez. Ket RAM tartalom osszeadasa meg ennel is kisebb kulonbseget eredmenyez: LDS 2 cilkus, LDS 2 ciklus, muvelet 1 ciklus, STS 2 ciklus... PIC-nel ugyanugy 2x1 cilius azaz 2x4 orajel... Ja, igen, az enhanced az 32MHz-et tud... A 40%-os sebesseg es 50% kodmeret csokkenes valos alkalmazasokon mertek le, pl IIR filteren, es ugyanazon orajel mellett! Namost a 32MHz az belso orarol megy! Menet kozben valtoztathatod az ora frekijet kenyed kedved szerint, tehat mikor nem szukseges alacsonyabb fogyasztasu modra kapcsolhatsz, es mikor hirtelen kell a szamitasi sebesseg felkapcsolod turbora Ami a tablazatosdit illeti: Tevedes! A PIC kepes a teljes 14 bitet kiolvasni az EEPROM interface-en keresztul! Csak kevesen hasznaljak, es a regebbi tipusok nem tudtak ezt. Azonkivul az enhanced mar a normal indirekt cimzesen keresztul kepes elerni a program memoriat is, sot a GPR-eket lineari memoria tartomanyba szervezve is kepes elerni, tehat a lapozgatas megszunik. Amugy 32 bankja van igen, de bevezettek egy uj regisztert amivel egyetlen utasitassal lehet lapozni, ill sok SFR ill a GPR-ek egy resze mindegyik bankrol elerheto igy rendkivul jol lehet optimalizalni a kodot hogy minel kevesebb bankolasra legyen szukseg! Azonkivul hogy a teljes RAM regiszterkent kezelodik leegyszerusiti a chip mukodeset, mivel mindenhol ugyanazok az utasitasok es cimzesi modok hasznalhatoak... Nincs pl kulonbozo cime az IO-nak ha ilyen vagy olyan utasitassal fer hozza az ember, nincs kulon RAM vagy regiszter tar, es nincs kulon utasitas az indirekt cimzesekhez - na jo, az enhancedben mar van hehe Ami a 16 vs. 14 bitet illeti: Valoban, a mid-range 14 bites... Nagyon sokmindenre jo az, sokkal tobb mindenre mint az ember hinne! Mindazonaltal en mindig azt mondtam, hogy az Atmel AVR felepitese sokkal inkabb osszevetheto a PIC 18F -ekhez, ami ugye mar ugyanugy 16 bites, es hasonlo parameterekkel bir. Nehany szo a stackrol meg: Persze, 4k stack meg 16 byte stack, ez is jo marketing Csakhogy a 16 byte stack az csak es kizarolag a program szal vezerleset szolgalja, mig a valtozokat szoftveresen megvalositott stack-en taroljak. Ily modon a stack hardveresen alul- es tulcsordulas vedett es szinte tamadhatatlan, mig egy teljesen RAM teruleten megvalositott stack mindig is problemas lehet - pl meddig fog az ott neked novekedni? Meddig fog a Heap teruleted novekedni? Megjegyzendo itt, hogy a PIC-hez a legtobb C compiler un. pseudo stack-et hasznal, tehat a szoftveresen megvalositott, lokalis valtozok szamara felallitott stack merete mar forditas ill linkeles kozben ismeretes igy futas kozben nem tortenhet varatlan meglepetes, nem kell run-time checking sem stb...Meg valami: Magam is kacsintgatok az AVR-ek fele, de van jopar dolog ami nem tetszik bennuk, pl az, hogy ki lehet zarni magad az AVR-bol es hogy a szoftver fejlesztoi tamogatasa eleg gyer ossze hasonlitva a PIC-ekkel - pl nincs olyan debugger ill szimulator ami tamogatna az automatizalt modul teszteleseket, ugye az MPSIM-ben van egy VHDL nyelvben megirhato stimulus file lehetoseg amit nem talaltam meg az AVR-eknel, sot semmilyen hasonlo lehetoseget - persze ez lehet az en hibam, es szivesen is vennem ha valaki ravilagitana hogyan lehet ilyeneket csinalni. Azonkivul zavar, hogy a GPR-ek az AVR-ben #define-okkal vannak megoldva, nincs strukturakba foglalt bitfield muvelet lehetoseg a portlabakon. Mikor kikenyszeritettem hogy legyen ilyen, es hogy a definiciok a megfelelo RAM helyre keruljenek kiderult a fordito azt mar nem kepes kioptimalizalni - ugy tunt nekem ez az optimalizalas csak egy eros trukk, tehat nem a forditando kod van optimalizalva, hogy a "PORTB &= 1<<5" -bol SBI legyen, hanem a forras maga.>> |
Bejelentkezés
Hirdetés |
