Fórum témák
» Több friss téma |
WinAVR / GCC alapszabályok: 1. Ha ISR-ben használsz globális változót, az legyen "volatile" 2. Soha ne érjen véget a main() függvény 3. UART/USART hibák 99,9% a rossz órajel miatt van 4. Kerüld el a -O0 optimalizációs beállítást minden áron 5. Ha nem jó a _delay időzítése, akkor túllépted a 65ms-et, vagy rossz az optimalizációs beállítás 6. Ha a PORTC-n nem működik valami, kapcsold ki a JTAG-et Bővebben: AVR-libc FAQ
Idézet: „Nem inline! Hiszen várakozás. Miért legyen gyors?” Bocsánat, nem szőrszálhasogatásként mondom, de adott esetben igenis van értelme a késleltetést inline függvényként fordítani! Az inlining ugye arra jó, hogy a paraméterátadás/hívás/veremfoglalás/felszabadítás/visszatérés adminisztrációjával járó pluszmunkát kiiktassa egy függvénynél. Ez ugyan nem túl sok, de mégis nem nulla időt igényel, ami minden egyes híváskor hozzáadódik a függvényben eltöltött időhöz. Van amikor ez elhanyagolható, gyors függvények esetén azonban ez számottevő lehet (ezért is találták ki). Egy _pontos_ időzítőfüggvénytől azt várjuk el, hogy benne a MCU n*m időt töltsön, 'n' a függvény paramétere, 'm' az időzítő felbontása, pl. 100 ns. Egy nem inline időzítőrutin viszont n*m + a időt vesz igénybe, ahol az 'a' a pluszadminisztráció ideje. Ha 'a' összemérhető n*m-el, akkor ennek az elvárásnak nem tesz eleget a függvényünk. Ekkor már csak azt mondhatjuk, hogy a függvény _legalább_ annyi időt emészt fel, mint amit a paraméter alapján megszabtunk, ami lényeges eltérés az elsőhöz képest! Pl., maradva a fenti felbontásnál, ha az adminisztráció ideje a=80 ns, akkor egy n=2 paraméter által megadott 200 ns időzítés helyettt 280 ns időt fog eltölteni a MCU a feldolgozással, ami 40%-os eltérés a kettő között! Röviden, a pluszteher kiiktatásával tehát más követelményeknek tesz eleget a késleltetőrutin. Attól függően, hogy milyen működést vársz el tőle, úgy kell inlininggel vagy anélkül fordítanod a függvényedet. Persze szép az elmélet, az igazság az, hogy az inline függvény is igényelhet járulékos adminisztrációt, és ráadásul a fordítótól függ, hogy mennyit, tehát nincs ráhatásunk, viszont az szinte biztos, hogy sokkal kisebb teherrel jár. Szólottam. Uff! 
Igazad van!
Amikor 1Wire RAM-ot használtam pontos időzítés kellett és ott így ment. Viszont az említett példában egy buzzer csipogási idejét kellett meghatározni, ahol néhány us vagy ms nem volt lényeg. És mivel sok helyen kellett csipogni...
Bocsanat, hogy en is kozbe kotyogok, de az inline kulcsszo csak egy jelzes a forditonak, hogy a fuggveny ha lehetseges inline-kent legyen forditva. De ettol fuggetlenul meg a fordito donthet ugy, hogy a fuggveny normal fuggveny lesz. Ha mindenkeppen inline kell, akkor jobb bemakrozni inkabb...
Na pontosan ez az amiert en nem hasznalok inlinet, inkabb makrot. Igazabol nem is ertem ezt a -- jolenne ha a hivashoz beforditanad, de ha megsem, az sem gond -- dolgot. Igaz inlineal meg vannak mas trukkok is, pl externnel kozosen.
Az inline-t legjobban ugy lehetne elkepzelni, mint egy udvarias felkerest a 19. szazadban:
Mr Programozo: "Uram, nagy oromomre szolgalna, ha ezt a fuggvenyt megsem fuggvanykent tenne be, hanem egyszeruen beszurna a kodot a megfelelo helyekre!" Mr Compiler: "Mindent megteszek, hogy O meltosaga elegedett legyen!" Aztan pl. ha nem fer bele a program memoriaba, mert 800 helyen kellene kibontani a fuggvenyt, akkor nyilvan inkabb meghagyja fuggvenynek es ezzel rengeteg helyet fog megtakaritani. Donthettek volna a C fejlesztoi ugy is, hogy a dontes meghozatalat a programozora bizzak, de valamilyen oknal fogva nem igy tettek...
"Viszont az említett példában egy buzzer csipogási idejét kellett meghatározni, ahol néhány us vagy ms nem volt lényeg. "
Na, erről lemaradtam... De mindegy, egy csipogónál persze, hogy nem számít.
Igen, ez így van, ez már annak a kérdése, hogy hogyan veszed rá a fordítót, hogy ne hívást használjon, hanem befordítsa a függvényt.
Ez nem véletlen, ugyanis annak eldöntése, hogy mi legyen inline és mi nem, nem is olyan triviális. Függ pl. attól, hogy milyen architektúrára fordítasz, mekkora a cache a CPU-ban illetve mellette (mikrovezérlőkben nem nagyon van), hány paramétert adsz át, az adott helyen adott regiszterszám és -kihasználtság mellett tényleg javít-e a futtatás sebességen, mekkora a befordítani kívánt függvény, hívja-e direkt vagy indirekt módon rekurzívan saját magát a függvény, vagy pontosan az amit te is említettél, hogy elférünk-e az adott eszközön, vagy sem. Az inlining elsősorban sebességoptimalizálásra kitalált módszer, és a sebesség sok mindentől függ. És persze nem követelmény csak cél, amire törekszünk adott feltételek mellett. A fordító elsődleges feladata a forráskódnak megfelelő működésű tárgykód létrehozása, a minél nagyobb sebesség vagy minél kisebb méret másodlagos.
Nagyon elkalandoztunk már az inline pókfonalán...
De sajnos az eredeti nem inline EEPROM kezelésem még mindig függőben van. Sajnos a teljes fordítós noinline nem jó, mert van olyan függvényem, aminek inline-nak kell lennie. Ha törik, ha szakad... És sajnos nem helyettesíthető #define makróval.
És amit janyjozsef javasolt, az sem járható?
Idezet a gcc doksibol:
Idézet: „As required by ISO C++, GCC considers member functions defined within the body of a class to be marked inline even if they are not explicitly declared with the inline keyword. You can override this with -fno-default-inline; see Options Controlling C++ Dialect. GCC does not inline any functions when not optimizing unless you specify the `always_inline' attribute for the function, like this: /* Prototype. */ inline void foo (const char) __attribute__((always_inline));” Nem probaltam ki WinAVR-el, de talan meger egy probat...
Sziasztok!
Valaki legyen szíves megmondani, hogy avr dragonnal lehet-e ATmega 8-at programozni, mert az avr studio nem engedi kiválasztani?
Ha a sokat emlegetett inline függvény mondjuk csak néhány utasítást tartalmaz, akkor egy lehetőség a #define függvényszerű makrók használata is, abban az esetben, ha a függvénynek nincs sok bemenete. Ebben az esetben a kvázi függvény be lesz szúrva a programkódba és a függvény természete is megmarad.
Ezt én értem, de fentebb tisztáztam, hogy sajnos nem jók nekem a define makrók erre.
Sziasztok! Azt szeretném kérdezni hogy indulásnak szerintettek melyik AVR32-es uC lenne jó? először az AT32UC3A0128-at néztem ki magamnak, de az 2800Ft. Olcsóbb fajta nincs?
Sziasztok!
Nekem 1 kérdésem lenne. Ki akart belépni a nevemben?  Be akartam lépni és azt mondta, hogy le vagyok tiltva, mert már 5 -ször elrontottam. Na mindegy.
Egyébként MP3 lejátszás, videó, fat stb 2800HUF-rt nem drága + letölthető könyvtár DSP utasítások stb. Én ezt ajánlanám: AT32UC3B0256-A2UT Én is ezzel tervezek most egy É.K. LCD vezérlőt. Viszont a hivatalos JTAG programozója kicsit drága. Van olcsóbb. De az ARM7 maggal 900HUF-tól. (TEM) Nem tudom, hogy itt nézted e? Bővebben: Link
Sziasztok
Érdeklődni szeretnék, hogy tudna-e valaki segíteni egy olyan kapcsolásban/ programban amivel egy labortáp feszültségét és áramát tudnám kijelezni. 2*16-os vagy 1*16-os lcd-vel szeretném megoldani. 0-50V-ig és 0-5A-ig szeretném, hogy mérjen. Kivitelezhető ez? Köszönöm előre is
Szia!
Az alábbi oldalt tekintem eredeti forrásnak, ezen több program is van a multiméterhez, igény szerint!  Bővebben: Link
Sziasztok valaki megmondaná hogy mi a külömség az atmega8-16pc 16pu között mert az első kell, de a második kapható.
Sziasztok szeretném felprogramozni a Topi féle AVR-Doperben lévő Atmega8-at egy STK200-al és a Ponyproggal ,kérdésem a fuse biteknél mit kell beálítani? Előre is köszönöm
Sziasztok!
Az alábbi kapcsolásban rajt lehet hagyni az ic-t az avr-en programozás közben(isp-vel)? Mi a feltétele annak, hogy ne kelljen kiszedni az áramkőrből? A másik kérdés, hogy mit jelent az optimalizáció és mikor melyiket kell kiválasztani? Miért hallatszik enyhe zúgás a labortápból, ha rádugom az isp-t az avr-re(nincs rajt semmi csak a programozó) és a számítógépregépre is? A válaszokat köszönöm.
Szia!
Az említett IC-k nem fogják befolyásolni a programozást. Az ISP rövidítése In-System Programmer, azaz "Rendszerben programozó", ami pont az ilyen esetekre utal. Ha valami gond van a programozó szoftver kiírja, tehát nyugodtan kipróbálhatod. Például ha a MISO és a MOSI láb közt egy dióda van, na akkor ki kell szedni. Az optimalizációról bővebben az AVR Studio súgójában olvashatsz angolul, az alapbeállítást ajánlom. Valószínűleg azért hallasz enyhe zúgást, mert a táp gerjed. Ugyan így jártam én is, a programozó pedig jelezte is, hogy valami gond van. Javaslom, hogy nézz rá oszcilloszkóppal, vagy próbáld ki egy 4.5V-os laposelemmel.
Sziasztok
Egy soreos kijelzőt szeretnék építeni, ehhez elkészítettem egy sematikus elrendezést, a képen látható is. Egy kijelző, amelyet a soros portról lehet vezérelni. A szoftverről csak elképzelésem van: Elküldöm a kiirandó szám első karakterét PB0 - PB6 ig ezzel egyidőben bekapcsolom azt a tranzisztort, amelyik helyiértékhez tartozik. Ezt mindaddig míg az összes számot ki nem írattam. Jól gondolom? A hardverrésze jó vajon? Köszi a segítséget.
Szia!
A hardware része hibás, NPN tranzisztorokat kell használni és egy 1K Ohm körüli ellenállást kell a bázisukkal sorbakötni. Egyszerűbb úgy megoldani, hogy soros porton az egész számot elküldöd! Kell egy függvény, ami frissíti a kijelzőn látható számokat. Először tölts fel egy 9 elemű tömböt úgy, hogy miután hozzárendelted a PORTx-hez a kijelződ lábait a 0. elemhez 0-t írjon ki, az 1. elemhez 1-et, a 9. elemhez 9-et. Ezután a függvénynek adj egy paramétert, ez lesz a szám amit majd kiír, legyen egész típusú. A bemeneti paramétert pedig a module-al és osztással szét tudod darabolni, például a 256-ot 2-es, 5-ös, 6-osra. Írd ki az első számot a portx-re: PORTx = tombod[bemenetiparameter%10]; És az első digit tranzisztorának bázisát emeld magas szintre pár ms-ra, majd vissza alacsony szintre. Ha a kijelzett értéket villogni látod, módosítsd az időzítést, nekem 4ms eddig mindenhová elég volt. Ha ezzel meg vagy jöhet a többi digit szépen sorban. A soros portos adatátvitelről pedig az adatlapokban olvashatsz bővebben. |
Bejelentkezés
Hirdetés |
