A MIPS a mikrokontrollerek világában, és úgy komplettül az informatikában: Million Instruction Per Second.

És ebben biztos lehetsz. A MIPS-re a "Meaningless Indicator of Processor Speed" egy vicc. Ugyan olyan, mint a "Meaningless Information Provided by Salesmen", "Meaningless Information per Second",
"Microprocessor without Interlocked Pipeline Stages" (ezutóbbi egy tényleges Architectúra)

Nem vitaalap, de egy ilyen kis lapot pont tavaly szereztem mikor kinnt voltam Nürnbergben, az Embedded World kiállításon.
Egy papír, és még ezernyi ilyen vicces MIPS alternatíva... Azthiszem a Freescale osztogatta a nagy 32 bites processzorainál...
Pontosan ott volt rajta is, hogy ez egy vicc, amit sokan elhisznek és követnek. Ez olyan urban-legend szagú dolog.

Mind az informatikában, mint a hardver tervezésben a MIPS millió utasítás / másodpercet jelent.

És a MIPS érték a tényleges mutató, nem az alutasítások és lépések száma! Hisz gondolj csak bele. Kit érdekel, hogy RISC esetén egy utasítás mondjuk 4 részben hajtódik végre. A végeredmény mégis az, hogy hány tényleges utasítás hajtódik végre másodpercenként.
Mert ha egy PORT-be, PORT-ki utasítást nézel. Ki a fenét érdekel, hogy az egy IO utasítás valójában hány al utasításra vagy hány darabra bomlott. Ez senkit nem érdekel. Az már érdekes, hogy ezt BE-KI párost delay-nélkül loopban kiadva, melyik processzor milyen frekvenciájú négyszögjelet produkál a kimenetén. És ez bizony megint MIPS függő.

És ez a MIPS, nem a vicces "értelmetlen mutató a processzor sebességére" rövidítése. Javaslom, ez előbbit azért ne nagyon terjeszd.

Úgytűnik valaki csúnya tréfája áldozata lettél, és hűen követed.

Bővebben: Link

Szerk: Kapj elő 16F877/887 adatlapot meg egy ATmega16 adatlapot. Benne van a 877 adatlapjában hogy 200 ns az egylépéses utasítás végrehajtási ideje. Ez a mega16-nál 62,5 ns.
De ne a régi 16F-es szériát nézzük. Nézzün egy 18F4550-et, USB-s típust:
Adatlapja szerint 48MHz-es külső órajelről is 12 MIPS! Furcsa, a microchip is használja a MIPS-et. És valószínű nem azt írja az adatlapba, hogy "12 millió értelmetlen mutató a processzor sebességére".
Sőt! Az adatlapja mondja külső 48MHz-es órajel esetén, hogy az "Instruction Cycle Time" 83,3 ns. (De ha nem hiszel a microchip által megfogalmazott MIPS-ben akkor tessék: 1/83,3ns ~= 12 004 801,92 utasítás / sec.
Ez még mindig több utasításvégrehajtási idő, mint a 62,5 ns egy mezei mega16 esetén. És ez már az új, csúcs 18F széria, összehasonlítva a régi ATmega szériával. XMEGA ezen is túl tesz. Bár ott már jobb a dsPIC teljesítményre jócskán, ám sajnos hardver bőségben vannak gondok.

Ha megtehetném, gyúrnék a kettőből egyet. Lenne minden porton felhúzó, nem a logikával ellenkező port direction beállítás. Kinek jutott az eszébe, hogy a logikai 0 kimenet (PIC)... Hát a legveszélyesebb dolog. Ha a procin rajta egy másik kimenet, akkor amíg nem történt meg a port inicializáció addig kimenet-kimenetnek feszül.
Aztán meg miért kell spórolni a sima láb interruptokkal...

Topi,

Szerintem azzal mindenki tisztaban van - meg a kezdok is, nemhogy egy ven roka, mint amilyen en vagyok -, hogy mi az eredeti jelentese a MIPS betuszonak. Ezert irtam le mi a valosagos jelentese. Az alapja ezeknek a "vicceknek" az eppenseggel az, hogy mivel csak annyit fejez ki ez a meroszam, hogy egy masodperc alatt hany utasitas hajtodik vegre, ezert nem lehet ezzel kifejezni valojaban milyen hatekonyan lehet vele megoldani egy-egy feladatot.

Nyilvan az eltero memoria es IO szervezesbol, az utasitaskeszlet mikentjebol es az utasitas feldolgozo mukodesebol stb fakadoan adodik, hogy mas es mas mennyisegu utasitast kell vegrehajtani ugyanahhoz a dologhoz. Nem mindegy, hogy a hardver tamogatas mit enged meg, nem mindegy az sem, hogy van-e magas szintu nyelv tamogatas a hardverben vagy sincs - pl. PIC mid-range-nel nincs, high-performance-nel es az uj enhanced-mid-range-nel pedig van.

Ezert irtam a peldanak amit irtam, hogy hiaba tud az Atmel AVR 1MIPS / 1MHz -et (marmint ha csak es kizarolag azokat az utasitasokat vesszuk melyeknek 1 ciklus kell, mert ugye van tobb ciklusos is...) szoval hiaba tudja, ha egy-egy feladathoz tobb utasitast kell kiadni es igy teljesen mindegy a vegeredmeny szempontjabol, hogy elvegzett 10ezer utasitast mig a masik csak 2-t ha a masik is ugyanannyi iso alatt vegezte el a kivant feladatot.

Nyilvan Te is talalkoztal mar a DMIPS betuszoval is, es pontosan tudod, hogy az mar egy valosagosabb sebesseget fejez ki. Ill. leteznek masfajta elfogadott tesztelesi modszerek is - ezeket azonban nem szeretik sokan, mert esetleg konyebben osszehasonlithatova valnanak az egyes termekek. Kb mint amikor a boltban az egyik termek kaloriakat ir le a masik napi szuksegletet a harmadik pedig mit tudom en kakaos csigaban fejezi ki az energia adagjat az adott elelmiszernek.

Az almát nem a körtével kellene összehasonlítani! A 16F sorozat egy 14 bites szószélességű vezérlő, az ATmega meg tudtommal 16 bites (mármint az utasítás szélessége...).

Az ATmegák megfelelője a PIC18, ebből indulj ki. Abban igazad van, hogy a PIC18F csak 10-12 MIPS, az ATmega meg 16 MIPS. Ezt azonban nagymértékben kompenzálja a PIC hatékonyabb felépítése és utasításkészlete (minden RAM rekesz általános célú regiszterként használható!). De ha ez kevés, akkor van már PIC18F14K20 is, ami 64 MHz-es, azaz 16 Mips, akárcsak az ATmegák.

De, gondolom, ezzel nincs vége a sornak, hiszen a PIC18F14K-t meg lepipálják az XMegák (32MIPS,vagy mennyi?), az XMEGA-kat meg lepipálja a PIC24H és a dsPIC (40 MIPS és 16 bit), azokat lepipálják a 32 bites ARM-ok és így tovább... egészen a 3 GHz-es, négymagos Intel vagy AMD processzorig... s akkor jöhetnek a klaszterek.

A lényeg szerintem az, hogy mindenki megtalálhatja a számára elegendő teljesítményű és tulajdonságú eszközt (főleg, hogy a Microchipen és az Atmelen kívül még millió másik cég is gyárt mikrovezérlőket speciális vagy kevésbé speciális célokra). Egyik sem "jobb" vagy "rosszabb", mint a másik, legfeljebb egyik vagy másik alkalmazáshoz kevésbé alkalmas.

Egy példa: Lentebb már volt szó arról, hogy nagysebességű impulzusszámlálónak az AVR-t kevésbé találom alkalmasnak, mint a PIC-et. Nem azért, mintha az AVR lassabb vagy rosszabb lenne, hanem pusztán azért, mert az előosztónak nem a kimenetén, hanem a bemenetén történik a szinkronizálás. Így tervezték. Más alkalmazás lebegett a tervezők szeme előtt, ahhoz biztosan így jó. Egy ilyen esetben meddő azt bizonygatni, hogy de a MIPS ennyi meg annyi, hiszen ebben a vonatkozásban a belső órajelről járatott (1 MIPS!) PIC12F629 is lepipálja az ATmega16-ot.

Egyetértek, bár annyit pontosítanék, hogy a PIC18F-től kezdve van PLL is, tehát ugyanazon kristállyal akár 5MIPS/MHz is lehetséges (pl. dsPIC33 8MHz-es kristállyal 40 MIPS)

Bár futottunk már pár kört, hogy PIC órajel meg AVR órajel.
A példád kiragadott, hogy RAMból ki és vissza. Ez az AVR-ben több órajel.
De:
1 az összes 8bites AVR-nek 16+16 regisztere van. Add össze ezekben amit kell.
2 nem ez a jellemző utasítás sorozat amit használunk. és mivel az összes többi sokkal gyorsabb, így összeségében az egész program az lesz.
4 ellenpélda PIC-re: (neki is van lassú pontja) amit már említettem, ha megjelenítésnél (LCD,TV...) akarsz képet kirakni, vagy stringszerű üzenetet küldeni RS232-n, akkor az AVR-ben program memoriában tárolhatod és 1 utasítással elő tudod szedni! (még a legkisebbekben is ATMEGA4)
LPM temp,Z+
Egy ilyen pl 1K-s "icon" előhozása PICben jóval több utasítás lenne az ő saját sebességén.
PIC 10/12/16 sorozatban ez olyan 4-8 utasítás ciklusonként.
3 az AVR-nek nem csak RAM morzyái vannak, hanem 0,5-4K és ez pl ATMEGA64-nél is hardveresen bővithető. Azaz sima belső utasítással használni tudod a külső RAMot. Ellenben PIC-nél 8-10 utasítás kellene hasonló produkcióhoz.

Eléggé gLCD fan vagyok. LCD-ket PIC-el keztem el nyaggatni. Kezdett lassú lenni az eredmény, pedig ASM-ben dolgozok és gyorsabb lett a cucc, mint másoknak (lsd fórum) Ezért kerestem elérhető, de gyorsabb kontrollert.
Kipróbáltam AVR-eket. Könnyebb panelt gyártani rá, jobb a lábkiosztása, jobb a fejlesztőkörnyezet (AVRStudio ingyenes, a C ingyenes és korlátlan, programozó és debugger benne van)
Fél óra alatt átírtam a PIC-es ASM kódokat, ami ezután ugyan azt csinálta az AVR-ben is. Nincs optimalizálási kérdés, nincs programozói eltérés. Sokkal gyorsabb lett, az LCD már a sebesség határon volt, a kisebb Nokia LCD-knél NOP-okat kellett beletenni.

A videón bemutatott demó példában jóval gyorsabb az AVR.
Ezért raktam elég sok PIC-emet parkolópályára.
Most szinkronos 4,3" LCD-ket (480x270xRGB) hajtok meg AVR-el.
Ide már kezd kevés lenni a 20Mhz is, de PIC-el el se indulna. Ez egy elég konkrét project ahol a 8bites PIC nem rúg labdába.

Szerettem a PIC-et, sokat kerestem vele, de már csak ritkán gondolkodok benne.
Néha kacsintgatok a PIC32 felé és van kedves kolléga, aki mondta, hogy itt a demopanele vigyem, mert ő se tud vele nagyon mit kezdeni.
Akkor már inkább AVR32

Ellenben a PIC24-es sorozat pont azt a hézagot tölti ki, ahol az ATMEL nem nagyon produkál.
Amíg az alsó(8bit) és a felső(32bit) kategoriában az ATMEL mellett több érv szól, addig a középső(16bit) kategoriában a PIC kedvezőbb választás.

Ez igaz, de az hogy 14 vagy 16 bit széles a kódtárolás, az nem okoz sebességbeli növekedést, max csak több utasításkód lehetőséget.
Az adatbusz szélesség már okoz sebességnovekedést (8 -> 16 -> 32)


Az ATMega 20 MIPS még a legkisebbek is. (a 128/256 nem)

Mit szoltok egy sebességi lista felállításához?
Én valahogy így látom:

PIC10
PIC12/PIC16
PIC18
ATTiny,ATMega,(PIC18)
XMEGA
PIC24
PIC32
AVR32
ARM

Nem kétlem, hogy a PIC-nek is vannak hátrányos tulajdonságai, s köszönömamintapéldákat, amelyeket említettél. Néhány kiigazítást azonban tennék:


Ez nem olyan nagy öröm, ha el kell menteni mindet taszkváltáskor, vagy egy bonyolultabb interrupt kiszolgálásnál! PIC-nél ez szerencsés esetben egy bankváltással is megoldható.


PIC18 RAM=256-3904 byte, s a nagy lábszámúaknál (pl. PIC18F8722, PIC87F87J50) ugyanúgy rakhatsz külső memóriát (20/21 bites címzéssel), s használható mikrokontroller, mikroprocesszor, mikroprocesszor boot blokkal vagy extended mikrokontroller módot.

PIC-ben is 1 utasitas - a high-performance seriaban... Csak Hajlamosak vagytok mindig a mid-range-hez merni ami azert nem ugyanaz



Igen, MPLAB is ingyenes, tobb fajta ingyenes C forditot is kapsz PIC-ekhez meg valogathatsz is Az AVR debuggerevel azonban nyugjeim voltak, pl a szimulatorok amiket kiprobaltam meglehetosen lassuak voltak, azonkivul stimulus szeru automatizalt / regresszios teszteleseket nem sikerult az AVR studioban ill a GNU toolsettel lezavarnom. Par fordumon rakerdeztem es senki sem tudott valaszolni, googli sem talalt erre valaszt. Nekem a lepesenkenti vegrehajtas lehetosege nem vonzz mert nem oldja meg a problemaimat, vagy csak joval tobb idoraforditasokkal.



Amint mar emlitettem a video nem mondja meg milyen PIC-et ill AVR-t hasznaltak fel, azt sem mondja meg milyen forditoval es milyen forditasi opciokkal forditottak a peldat, sot a pelda forrasa sem elerheto, igy teljesen irrevelans az amit latunk. Abbol csak azt latom, hogy van egy lassabb alkalmazas meg egy gyorsabb, de azt nem latom belole mi miatt lassabb az egyik.

Ennek nem sok ertelmet latom igy Alkalmazastol is fuggenek ezek a dolgok - pl a PIC18F ill 24H csaladban van hardveresen tamogatott USB mig AVR-ben nincs, tehat abban a pillanatban egy USB eszkozt kell megvalositanod az AVR rettento nagy hatranyba kerul - es most nehogy elo hozakodjatok a bugyuta bitbang-es low-speedes USB megvalositassal, mert annak rengeteg hatranya van, tobbek kozt a szabvanyok be nem tartasa...

Sorolom:
AT90USB1286
AT90USB1287
AT90USB162
AT90USB646
AT90USB647
AT90USB82
ATmega16U4
ATmega32U4

A video konkrét példa.
De amit leírtam, az mégkonkrétabb, miszerint az AVR-re írt LCD progim sokkal gyorsabb volt mint a PIC-es és ez mind ASM-ben feladatoptimalizáltan.
De neked a konkrét példa kevés
Ok mutasd az ellenpéldát.
Mondanám, hogy csináljunk egy versenyt, de a témaválasztásban vita lenne
Vagy legyen ugyan az mint a videón, Te megcsinálod 8 bites PICben én meg 8bites AVRben?

Nem! Akkor lenne az, ha a reszletek, a teszteles korulmenyei stb dokumentalva lenne!



De Te sem irod le melyik PIC-kel csinaltad anno, igy ez sem konkret Azonban en nem tamadom, hogy az AVR-rel ugyanazon orajel mellett hasonlo aramfelvetellel valamit gyorsabban meg lehet oldani, mint a PIC-kel. Konnyen elkepzelheto, foleg, ha magas szintu nyelvnel a forditaskor a regisztereket kihasznalva optimalizaljak a RAM hozzaferest.

Amit erosen ketlek, hogy ez az 1/4 kulonbseg meglenne! Amit meg erosen ketlek, hogy az AVR fejlesztoi tamogatasa jobb lenne, mint a PIC-e. Es amiben biztos vagyok, hogy a Microchip beszallitoi halozata sokkal kifejlettebb, mint az Atmele.

De az. Azért mert kevés infód van róla, attól még a példa konkrét, egyértelmű.
Ha valaki nem tud valamiről eleget, attól az a dolog még az, létezik!
De igaz a korrekt döntéshez nem elég az infó. Be kell szerezni.


De az eset elég konkrét, mert megcsináltam és nem elméletben ötletelgetek, mint ahogy tettük ezt némely dologban eddig.
De különben a PIC 20Mhz-n ment az AVR meg 16-on, de ezek változtak alkalmazástól függően. És nem a másodpercek alapján döntöttem (amiben AVR győz), melyik a gyorsabb, hanem a kapott értéket a Mhz-re vonatkoztatva és felszorozva a leggyorsabb procikra.
Mert azt venném meg, amelyik a leggyorsabb... és ez az AVR.


Itt már kicsit alakul a vélemény. Tiltakozol az 1:4 ellen. Én is úgygondolom, hogy ez nem minden alkalmazásra igaz, de van amikor több, van amikor kevesebb.
Van amiben a PIC van amiben az AVR gyorsabb szervezésű. De én mondtam egy valóságközeli értéket, Te mit mondasz, szerinted mennyi?

És nem csak az azonos órajelre gondoltam. Vegyük a leggyorsabb 8 bites PIC és AVR kontrollert.
Készítsük el rá ugyan azt a progit (pl egy kép a képernyőre pakolása, törlés, majd ezt ismételje kb 10-szer.) mérjük le melyik a gyorsabb.
És mivel ismereteim szerin a leggyorsabb 8 bites PIC az 64Mhz-n megy és a leggyorsabb 8 bites AVR meg 32Mhz-en, ezekket lehetne összereszteni.
Tehát szerintem a fellelhető leggorsabb PIC dupla órajelen is lasabb lenne mint a leggyorsabb AVR a 8 bites kategoriában.
És még csak nem is ragaszkodok az azonos órajelhez.

De en szeretnek errol infot, de nincs!



De megegyszer, mert lehet nem eleg vilagosan kerdem: MELYIK PIC?! Mert ugye a mid-range architekturaban es utasitas keszleteben nem er fel az AVR-ekkel. 18F (vagy mas neven high-performance) igen...



Egy korrekt tesztben benne vagyok, en is kivancsi vagyok ezekre a dolgokra, de nem igerem, hogy a kovetkezo napokban de lehet hetekben lesz idom erre. Allitsunk ossze egy feladatot es nezzuk meg mit tudnak ezek a joszagok. Es termeszetesen aramfelvetelt is nezzuk meg, mert az is ertekes info lehet mindannyiunk szamara.

Szerk: A Melyik PIC ill melyik AVR -re vonatkozoan: Ha valaki azt mondja, hogy a Mercedes gyorsabb, mint a BMW akkor ez kb ugyanaz, mintha azt mondja valaki az AVR gyorsabb, mint a PIC... Ha viszont az SLK 500E kompressor tuninggal vs. BMW 750 AVG tuninggal akkor mar kozelebb kerulunk az osszehasonlitas alapjahoz.

Bocs hogy beleszólok, de nem biztos hogy 8 bitre célszerű szűkítened az összehasonlítást. Szerintem jobb lenne inkább azonos árkategóriára szűkíteni. Mert mi értelme az órajelre leggyorsabb 8 bites procit keresni, ha van olcsóbban 16/24/32 bites ? Ami esetleg gyorsabban futtatná a kódot. Nem ismerem túlságosan a pic-ek árazását, atmelt meg pláne nem. De talán ez a szempont az ami meg tudná győzni a feleket.

Ebből nagyon furcsa dolgok sülnének ki, mert némelyik PIC32 olcsóbb, mint némelyik régi PIC16!

Nem beszelve arrol, hogy most a Microchip Direct-es arakat nezzuk-e volume pricing esteben vagy a Digikey vagy Farnell arait 1 db-os eseteben - mivel Atmelnel ugy tudom nincs lehetoseg kozvetlen a gyartol rendelni?

Pont ez volt a lényege amit írtam, nem akarom megnevezni a két procit, korlátozva ezzel a lehetőségeket. Csak 1 megkötés van, hogy 8 bites legyen.
Választhatod bármelyik procit. Sőt választhatsz lasabb procit is, ha nincs 64Mhz-esed, és felszorozzuk az eredményt a 64 MHz-nek megfelelően. Korrekt?

A feladat legyen ami volt a videón is, de többször,ismételve, hogy lehessen mérni.
Azaz egy 132x132-es 8bites grafikus kép kirakása egy Nokia LCD-re majd törlés és újra kirakás...
Overlocking kizárva (AVR ebben úgy is nyerőbb, hajtottam már 54MHz-en is)

Ha kell tudok 8bites konvertált PIC-es kép adathalmazt küldeni.
Nokia LCD is van csatival.

De az is működik, hogy megírod a progit én meg beletuszkolom egy PIC18F-be.

lidi
Az ár alapján nem szabad összehasonlítani. Nem igaz, hogy minél jobb egy proci annál drágább azonos cégen belül.
És pl engem nem érdekel az ár, mert nálam számít a sebesség és többet is hajlandó vagyok egy jól kezelhető, és gyors prociért.
Pl lábszám se fontos 44/64 láb elég.
Most a fogyasztás se nagyon érdekel, mert már szinte mind picowattos és nagyságrendekkel kevesebbet fogyasztanak a többi alkatrésznél.

Ejj már, valótlan dolgokat ne terjesszünk...

Kinek jutott az eszébe, hogy a logikai 0 kimenet (PIC)... Hát a legveszélyesebb dolog. Ha a procin rajta egy másik kimenet, akkor amíg nem történt meg a port inicializáció addig kimenet-kimenetnek feszül.

Most hirtelen az első adatlapból, ami épp nyitva van:

TRISA TRISA7(1) TRISA6(1) — PORTA Data Direction Register 11-1 1111 11-1 1111

Az a sok 1-es a sor végén a POR/BOR valamint az összes más forrásból érkező reset utáni állapot. Elhiheted, hogy nem hülyék ülnek azért az MC-ben sem, hogy default kimenettel induljon bármelyik port egy uC-ben!

Nem erre értettem, hanem a klasszikus orolgatós 8051-es Harvard témára. Port initnél egybe OR-olt és komplementált bitekre.

Kényelmetlen egyszerűen a komplementáltal ÉS-elés, szemben a sima OR-olással.

Valóban, én hobbicélokra ha veszek cuccokat, akkor kb. az 1000Ft/db az a lélektani határ, ami felett már igencsak meggondolom, hogy foglalkozzak-e vele. Márpedig az általam ismert AVR-es árlistákon elég sok olyan proci van ezen a határon felül, amit esetleg még ki is próbálnék, de lehet, hogy emiatt nem fogok.

Elég, ha csak a kicsit visszább említett AT90USB-s típusokat nézem. A legolcsóbb is 1500Ft körül van és SMD tokozású, ellenben hardveres USB támogatással ellátott, DIP tokos PIC-et 600Ft körül tudok venni. Valószínűleg nem véletlen, hogy a neten nem keveset kotorászva USB-s AVR projektekre szinte kizárólag a bitbanges AVRUSB-s megoldásokkal találkoztam. Én egy ilyenbe beleástam magam, de nagyon nem vagyok tőle elájulva. Gyakorlatilag azt is lehet mondani, hogy csoda, hogy működik, annyi helyen mond ellent a szabványoknak és előírásoknak.

Azért érdemes az adatlapokat jól átböngészni, mert a gyártók előszeretettel adnak meg "nagyon kedvező" adatokat a brief-ekben, aztán a valóság már lehet, hogy sokkal csúnyább. Pl. azt sehol nem említik az ilyen kis fogyasztások hangsúlyozásánál, hogy aktív programfuttatási állapotban nagyságrendekkel többet fogyasztanak a CPU-k, de az is egyfajta "csalás", hogy a CPU-hoz és a perifériákhoz tartozó fogyasztások is sokszor kisebb órajelen és tápfeszültségen vannak feltüntetve, mint amin általában használják ezeket a cuccokat.

Egyébként az sem lenne egy utolsó dolog, hogy bizonyos feladatokat minimálfogyasztásúra hogy lehet megoldani, nekem pl. van az a PIC-es LCD-s órám, aminek kb. 5uA az átlagfogyasztása. Ha véletlenül a felhasználó megnyom egy gombot, akkor a belső felhúzó ellenálláson folyó áram miatt rögtön felugrik vagy 60-80uA-re

Tudomásom szerint ez a PIC18-nál is így van, csak ott

-nek hívják. (Table read with post incrementing.)

Szerintem a kiírás sebességét az interface maximális sebessége szabja meg - ez a legszűkebb keresztmetszet. A régebbi PIC18-nál ez max 10mbit/s volt, a PIC18F2xk20 sorozatnál elvielg (legalábbis az adatlap szerint) 16 bit/s-ig meghajtható.

Egyenlőre én is a PIC-esek táborát gyarapítom. De lehet nem sokáig...
Eddig 16F877 / 887 18F4520 és 18F8520-as procikat programoztam, de hamar a sebesség problémájába botlottam. Igazság szerint az LCD-k és a robotok vezérlése miatt kezdtem el ezekkel a témákkal foglalkozni.
Az első sebességbeli problémám pont az RCszervók vezérlésénél jelentkezett. 20ms-os jel kell nekik, aminek a kitöltése elég kicsi. 1-től 2 ms-os kitöltés lehet csak. 1ms az egyik végkitérés 2ms a másik. Ha felosztjuk azt az 1ms-ot ami a kettő között van a fokok számával, 250-el, akkor 4us-ot kapunk. Ha egyszerre akarok mondjuk 8 szervót vezérelni (nem egymás után!) akkor sehogy nem férek bele ebbe a 4us-ba! És egy tisztességes robotba nem is 8 szervó van!

A másik probléma akkor jött, amikor kaptam egy 320x240-es touch-pados LCD-t. A típusa: SHARP LM320192 Sajna az adatbusza csak 4bites, így nagyon gyorsan kell rá kiírni az adatot, mert különben villogni fog. És Villog is! Hiába próbáltam még 40MHz-es kvarcal is, sehogy nem akart jó lenni.
Viszont abban sem vagyok 100%-ig biztos, hogy jól írtam meg a progit. Megtennétek, hogy ránéztek, hátha van benne valami, ami elkerülte a figyelmemet.

Mellékelem az LCD adatlapját is, mert nem túl könnyű rátalálni.
Illetve találtam még egy HiVoltage programozót ami mindkét procit viszi! PIC/AVR Szerintem nagyon ász! Bővebben: Link

Ha emiatt akarnál áttérni AVR-re, akkor eszedbe se jusson. Inkább nézd meg a PIC32-ket, vagy ha az sem elég, akkor nézz szét más gyártóknál, hogy van-e valami mégnagyobb sebességű kontroller, vagy több kontrollerre kell elosztani a feladatot.

Szerintem inkabb gondolkozz el azon vajon miert szokas az RC servoknal hasznalatos PWM jelet PPM-mel kodolni a radio taviranyitashoz, es hogy vajon ennek mi az elektronikai vonzata.

Azt az LCD-t meg nem ismerem, es ezt a basic-es programot sem, hogy ebbol mi fordul le, mi nem, de gyanitom a program egyszerusege miatt itt valahogy ezt maskepp kellene megoldani.

Egyik cimborám küzdött PIC32 procival és szinkronos RGB LCD-vel. Pár hetet rászánt, mire lett valami eredmény. (RGB szinek kirakva)
A proci nem kezdőknek való, sőt inkább profiknak
Ellenben az AVR ATMEGA a sebessége/egyszerűsége miatt mégis komoly ellenfél ilyen esetben.
Én most hétvégén (influenzának köszönhetően otthon maradtam) nekiestem egy 320xRGBx240-es szinkronos LCD-nek.
Panelmarás, szinkron tanulmányozás, pár szin a kijelzőn, grafika tervezés...
ATMEGA32 panelen teszteltem 16MHz alatt.
Elkezdtem írni egy 'játékot'... bár az LCD tanulmányozás volt a cél.

Csináltam róla egy videót:
Link a videohoz


Van itthon pár 20MHz-s ATMEGA32 ezekre fogom tervezni a kész panelt. Bár lehet, az XMEGA procim lesz a végső.

Tom
Az adatlap alapján a monocrom LCD-d van amit gyorsabban meg lehet hajtani, mint a szinkronost.

"Az adatlap alapján a monocrom LCD-d van amit gyorsabban meg lehet hajtani, mint a szinkronost."

ezt biztosan így gondoltad?

Nem teljesen szinkronos helyett gondold az RGB-t
De a lényeg, hogy a monocromnál (320/4*240)=19.200 dotclock kell egy frame alatt, addig az RGB-nél (408*262)=106.896
Azaz azonos felbontás mellett (320x240) 5,5-ször gyorsabb lehet a monocrome, mint az RGB.
És nálam nem villogott az RGB, akkor a monocrom is tuti lenne AVR-el. Persze lehet csak programhiányosságok vannak és lowcost PIC is megbírkózna vele

Ebben bizonyos vagyok ... lehet lassabb lenne a kepernyo feltoltese es egy hasonlo videot tudna valaki csinalni mint amirol szo volt, de villoznia nem szabad - ott valami mas gond van!

Bővebben: Link