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
A PWM _NEM_ 0...5V folyamatos jel. Vagy 0V vagy 5V és ezek aránya változik!
Diódával lehúzni még 0.5V-ot?
Az ATMega328-as chipben van a hardwareban, sziliciumon: 1 byte az épp vett karakternek, és 3 byte memória a további vételhez (buffer). Azaz ha jön a 2. karakter, akkor az 1. vett karakter megy a FIFO léptetés alapján a bufferbe és a 2. karakter lesz a vételi tárban. Amikor a sorosportot olvasod, és több karakter van, akkor a FIFO elv alapján szolgál ki (FiFo: Firtst in firtst out).
Ha a 3+1 karakter vételénél _rövidebb_ a timer rutin, akkor nincs adatvesztés. Ha nem szabad INT vesztésnek lennie, TILOS INT-et tiltani. Sorbaállítás van az interruptok közt, azaz amíg egyikben vagy és beesik egy másik, annak jelzőbitje bebillen. Az épp futó intből való kilépés után a következő legmagasabb priorítású INT hajtódik végre. Ha elfogytak, akkor a főprogram.
"a következő legmagasabb priorítású INT hajtódik végre" Ezek szerint mégis van priorítás?
Talán a megszakítási vektortábla határozza meg a megszakítás sorrendjét? Leporoltam egy korábbi munkámat, abban UART-ot dolgoztam fel megszakítással, ez egy tök jó példa. A feladat a következő volt: Folyamatos adásban küldi a karaktereket egy eszköz. Ez a karaktersorozat egy sztringet alkot, amiben van egy karakter, amit figyelek (sajnos az ilyenkor használandó sorvége jelet nem egyszer küldi, ezt nem tudtam figyelni.). Tehát, jön a várt karakter, ez utáni karaktereket elmentem egy tömbbe. Ha ismét jön a kiválasztott karakter, akkor vételre és mentésre került az egész sztring. Ennél a pontnál gondoltam azt, hogy tiltom az UART-ot, addig, amíg az adatokat feldolgozom. Szerettem volna én meghatározni, hogy milyen "időszeletek" állnak rendelkezésre a program különböző funkciókat ellátó egységeinek. 1, UART eng. 2, adat sorvégéig beolvas, ment 3, UART tilt. 4, adat feldolgoz 5, goto 1 Ha jól értem amit mondasz, akkor ne babráljam a megszakítást, hanem függvényben kezeljem a le a problémát. pl. így: 1, folyamatosan jönnek a karakter 2, megvizsgálom, hogy volt-e már sorvége jel 3, ha igen akkor a következő karaktereket nem mentem (tömb feltöltve) 4, feldolgozom az adatokat 5, törlőm a sorvége jelzőbitet (általam létrehozott változó) 6, goto1 Ebben az esetben nem az UART int-et tiltom, hanem a vett karakterek feldolgozását.
És miért nem használsz 2*es vételi tömböt körbe futó indexeléssel töltöd fel az int-ben?
A főprogramban Folyamatosan feldolgozhatod, figyelve az int index mutatóját. Ami a pillanatnyi string végét jelzi. Így nem vesztenél karaktereket!
Igen, erre is gondoltam.
1, tömböt feltöltöm a sorvége jelig 2, átmásolom egy másik tömbbe, amit folyamatosan feldolgozok 3, megadott számú sorvége jel érkezése után frissítem az adatokat (goto2) Erre gondoltál? Egyébként működik a ketyere, csak nem tartom "szépnek" az INT és az adatmentés programrészletet.
Nem egészen így gondoltam!
Minek másolgatsz? Tárolni akarod az árkezet, adatokat? Vagy csak kiértékelni, és az alapján valamilyen műveletet végrehajtani? Az INT megy folyamatosan, veszi és tölti az adatot a pufferbe. Ha a végére ért, kezdi az elejére tölteni a karaktereket. Közben figyeli az elválasztó karakter érkezését, és akkor 1 jelző Bytebe be teszi az aktuális index értékét. Ezt figyeled a főprogramban, és tárolod az elsőt, ez lesz a stringed eleje. 0-zod, és várod a következő nem 0 értéket, ami a string végét jelzi és egyben ez a következö eleje. Indulhat a feldolgozás. Mivel a soros porton érkező adatfolyam jóval lassabb, mint a 16MHz-en történő feldolgozása! Szerintem jó szervezéssel Pufferhossz = adathossz*2.5 simán elmegy adatvesztés nélkül. A hozzászólás módosítva: Aug 22, 2014
Ha jól látom a 126-os egy 3state buffer. Ennek kimenete nagyimpedanciás amikor az OE-vel tiltod. Mi van még az IC és a nMOSFET között ami definiálja az állapotot erre az esetre? Egy nagyimpedanciás kimenetet és egy bemenetet nem szabad magára hagyni mert nem definiált állapot jön létre. Pl. zavarérzékeny lesz.
Köszönöm a választ. Az IC kimeneteit egy ellenállással a földre kellett húzni, így már megszűnt a zaj és rendesen működik.
Jelenleg úgy csinálom,ahogy Te írtad.
A sorvége jel után kezdem a karakterekkel feltölteni a tömböt. Ha megérkezett minden karakter, törlöm a számlálót és minden kezdődik elölről. Működik, de nem tartottam "szépnek" a kódot. Arra gondoltam, hogy ha feltöltöttem a tömböt, akkor tiltom a megszakítást, ha feldolgoztam vagy ismét szükségem lesz adatra, akkor engedélyezem az INT-et. De az ötleted, ötleteitek alapján már látom, hogy min kell változtatnom a kódon, hogy átláthatóbb, "szebb" legyen, annak ellenére, hogy tökéletesen működik a jelenlegi is.
Sziasztok, mennyire jelent az problémát, ha az AVCC közvetlenül megy a tápra, nem induktivitáson keresztül? Egy analóg csatornát használni fogok, nagyon ugrálnak majd a mért értékek?
Szia! Én mindig beteszek néhány ohm és 220nF- 1µF-ot. Jó szokott lenni.
Az AVCC és a GND között nekem is van egy 100nF kondi, de az adatlap javasol egy 10uH-s induktivitást is.
A 10uH az az analóg tápágba kell a Vcc és a VccA közé.
Én is tudom, a kérdés az, hogy mi van, ha ezt elhagyom?
Az analog jeled zajosabb lesz, mozog kissé a referenciafesz., és a chip belső digitális zaja átszűrődik az analóg mérésbe.
És vajon ez okoz problémát ha az analóg bemeneten csak egy ellenállássor van nyomógombokkal (5 gombhoz nem akartam 5 kivezetést elhasználni)? Tehát annyira nem kritikus a pontosság, de azért jó lenne kitalálni, hogy melyik gomb lett megnyomva.
Valószínű hogy nem probléma az alkalmazásodnál.
Üdv!
Breadboardon dolgozva véletlenül a GND helyére dugtam be egy külső táp pozitívját (11,5V), ez pedig össze volt kötve az Arduino Mega GND-jével. A windows lecsatlakoztatta az USB eszközt és azóta hiába dugom be, nem ismeri fel, "az eszköz meghibásodhatott, a windows nem ismeri fel az eszközt" hibaüzenetet kapom, eszközkezelőben pedig "Device Descriptor Request Failed" kapom meg ha frissíteni próbálom a szoftvert. Az arduino boardnak látszólag semmi baja, ledek ugyanúgy világítanak ahogy eddig, a legutoljára ráírt program pedig tökéletesen fut rajta. Mit lehetne ez esetben tenni, illetve mi a biztos jele ha tönkrement?
Az USB illesztő ATMega16U2-es illesztőchip halt meg.
MLF tokozás: cserélhetetlen házi körülmények közt.
Erre gondolsz ugye ?
Talán a cserét meg tudom oldani, a kérdés az, hogy ilyen chipet lehet e kapni külön ?
Igen. Lehet kapni.
Sziasztok
Atmega16-al próbálkozok. Alapoknál járok. Itt az oldalon van fent led villogtatós cikk. De sajnos nálam nem hajlandó világítani egy led sem. Próbáltam combosabb(külső 5V) tápról ne a jtag programozóról de akkor sincsen semmi. A b portra kötöttem egy 5mm es víztiszta piros ledet egy 220ohm-os ellenálláson keresztül. Az is lehet hogy a mikrokontroller nem tud a kimenetén felvillantani egy ekkora ledet?
Valamivel nagyobb ellenallast tehetsz, de az nem kene gond legyen. Forditasnal/programozasnal nem ad semmilye hibat/figyelmezetest? Minden tap es test be van kotve a mikrokotolleren?
Szia!
DC Current per I/O Pin ............................................... 40.0 mA Simán meg kell hajtania!
Sziasztok! Nincs valami ötletetek hogyan lehet USB webkamerából IP cam-ot csinálni?
Ez nagyon nem ide tartozik... De pl WebcamXP Pro szoftver és máris bárhonnan láthatod a kamerád képét a neten keresztül.
PC nélkül gondoltam.
Érdemes?
Távvezérelhető, Wifi/LAN kamera az Aldiban most 16eFt 3 év garanciával.... |
Bejelentkezés
Hirdetés |