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
(Gyakran az újabb gépekben is még az alaplapon ott van a párhuzamos port csatlakozó, csak nincs kivezetve a hátuljára... A gép szétszedése nélkül megnézhető pl. a BIOS-ban, hogy be lehet-e kapcsolni: ha igen, akkor érdemes belenézni. Vagy az alaplap leírása alapján.
Ha ott a tüskesor, akkor igen nagy eséllyel sokan tudunk adni olyan kábelt, ami kiviszi a portot a hátlapra. Vagyis kis szerencsével a nyomtatóportos megoldáshoz sem kell előszedned egy régi gépet...)
Köszönöm de már rendeltem egy usb programozót a nagy fal tövéböl ha nem bírok vele akkor lèpek tovább.
ATMEGA-8 programÜdv!Adott egy atmega8-al működő DCF szinkronizált óra. Szeretném ha a kettőspontok felváltva villognának amikor szinkronizál az óra a DCF vevővel. Bővebben: Link Az "asm" file elérhető Bővebben: Link. Valaki módosítaná a programot és lefordítaná hex-re -a beégetést meg tudom csinálni.. ( Csak után építeni "tudok") Köszönöm. A hozzászólás módosítva: Jún 21, 2025
I2C szintillesztés hogyan?Sziasztok!Nem teljesen AVR a téma, de hátha valaki tud segíteni. Egy áramkörben lévő eprom tartalmát kell kiolvasnom, egy adott hardverrel. A gond az, áramkörben 1,8V-os I2C vonalak vannak, az eprom olvasó hardver pedig 3,3V-ot kezel. Már megrendeltem egy pici PCA9306 szintillesztő áramkört, viszont dolgozni szeretnék amíg az megérkezik. Nincs valakinek valami megoldása/ötlete a szintillesztésre?
Csak vigyázni kell, mert a szokásos 3,3..5 V-os konverzióhoz képest itt már 1,8 V-os feszültségnél stabilan kell nyitnia a MOSFET-nek (szórással együtt), ami <1 V normál gate threshold voltage-et jelent. Ez ritkább, és egyáltalán nem biztos, hogy van otthon.
Ezek jók lehetnek, de inkább csak tippnek vedd, ne higgy nekem: : -) https://www.hestore.hu/prod_10048178.html https://www.hestore.hu/prod_10021023.html
Sziasztok!
Én is ezt találtam, rendeltem a néhány fajta mosfetet, kell pár nap mire megjön, addig várnom kell... Amit itthon találtam azzal nem/nem jól működött a dolog... kevés az 1,8V... 3,3V és 5V között ok! FelejtésSziasztok!Most előtúrtam pár 15-18 éves készüléket (mérnöki példány, itt marad, ne kelljen Dél-Afrikába menni egy sor módosításáért ugye...). 6 látványprogramot tudó VU-méter, ha nincs hang, unatkozik=lágy átmenetekkel elvan. Kivéve, ha egy bizonyos program fut, akkor vibrál. Ugyan az a rutin van meghívva, semmi különleges (nem lehet időzítési gond, WS2812, kitanultuk anno), visszaolvasva, 1 bit hiba. Másik dolog (GPU-t csinált barátom mono LCD-hez), tökéletes a megjelenítés, de egy programrész nem megy. Visszaolvasva, 1 bit hiba. (ez kb 15 évig volt fiókban). Ti találkoztatok ilyennel, hogy 10-15 év után elmegy a flash? (ezeknél a példáknál kideríthetetlen, ki-mivel megy el az erdőbe, de nem okoztak itt nagy hibát, de nem ASM, tehát lehetetlen rájönni, mit okoz egy bithiba...másutt teljes összeomlást, itt csak egy kérdést). Ezekben Mega32 és M328 van, a bénább látvány VU-ban csak Attiny84, az meg elvan, nem felejt. Na, akkor ne tervezzek semmit 10+ évnél hosszabb időre? (félőbb, ha balesetet okoz egy cucc, most akkor én vagy a gyártó a hibás?)
Létező dolog, különösen nagyon nagy integráltságú chip-eknél.
Van ahol figyelik is: Idézet: „serSupervisionTimer This attribute is used for activating or deactivating Soft Error Rate (SER) checking for Digital Signal Processors (DSP) on *** Board, and providing the periodicity of the Cyclic Redundancy Check (CRC). Note: SER faults are generated when high-energy sub-atomic particles collide with the DSP silicon and alter the DSP memory content by one bit. The source of the particles is, for example, the encapsulation material of the DSP or cosmic radiation. SER faults occur seldom and are considered expected behavior.”
Mondjuk, a cipősdoboz maximum az alfa-béta sugárzás ellen véd...ami érdekes, hogy egy (ugyanolyan idős) készülék kiszögelve a falra évente 4-5 alkalommal be van kapcsolva, annak semmi baja, talán a flash olvasóerősítő, ha látja, hogy a töltés mondjuk 70% alá esik, visszatölt (???). Chip-en bármit el tudok képzelni. Van olyan AVR-es áramkör, ami iparban 20+ éve megy éjjel-nappal, semmi gond. Csak a lezsírozott, elfeledett, "minekszedjemszét" áramkörök esetén jött elő. (nem ártana itt már egy nagytakarítás/selejtezés is)
 Köszönöm! Atmega 2560 jtag debuggerSziasztok,Atmega 2560 Jtag olvasásra- ra mit javasoltok? ATMEL MKII ha jól tudom csak programozó. Köszi! ATtiny85 LED füzér vezérlésSziasztok!Közeledik a karácsony, így előkerültek a fiók mélyéből az elemes LED füzérek. Van itthon jó sok. Az egyik részük időkapcsolós (van benne beépítve timer), ami 6 órán keresztül engedi világítani, majd 18 órán keresztül pedig kikapcsolva tartja a LED füzért. Ezek szinte mindegyike 2 db AA ceruza elemről működnek. Persze van 1-2 db, ami 3 db AA ceruza elemet igényel. Mivel van itthon jó pár olyan is, ami nem időkapcsolós, és van itthon jó pár ATtiny85 chip-em is (SOIC-8 tokozású), ezért kitaláltam, hogy "felokosítom" ezeket a LED füzéreket is. Ezek is legyenek időkapcsolósosak! Minimális kódolást igényel, ez nem gond (max. segít a ChatGPT ). Viszont nem tudom eldönteni, hogy tranzisztorral (BCX56-16, és egy 1k ellenállás a bázisra) vagy FET-el (AO3400, és egy 10k lehúzó ellenállás, és egy 10 Ohm ellenállás a Gate-re) legyen megoldva a LED füzér kapcsolgatása. Azt megmértem Amper mérővel, hogy 240 mA áramot igényel a LED füzér 2 db AA ceruza elemről.Szerintetek melyik megoldást érdemes választani, és jól gondolom-e, hogy elég csak ennyi alkatrész?
Ahogy nézem még ellenállás sem kell a FET-hez.:
Idézet: „Port B is a 6-bit bi-directional I/O port with internal pull-up resistors (selected for each bit). The Port B output buffers have symmetrical drive characteristics with both high sink and source capability.” Ugyan kicsi a feszültség, de a FET adatlapja alapján működhet.
Egyik sem kell? Se a soros ellenállás, se a lehúzó ellenállás a Gate-hez?
Úgy emlékszem, hogy a felhúzó ellenállás csak input módban működik, mert a PORTx regiszterrel lehet állítani.
Az eredeti kérdéshez: a 240 mA a MOSFET-el működni fog. Szerintem nem kell ellenállás a gatere, mehet direktben. A bipoláris is jó, de a CE szaturáció elég nagy, ami csak fölöslegesen viszi el a teljesítményt. Arra figyel, hogy a LED sor melyik végére teszed a tranzisztort, mert a bipolárist a táp és a szalag közé, addig a MOSFET-tet a szalag és a test közé kell tenni. A tapasztalatom szerint a ChatGPT az időzítés hosszába szokott belezavarodni, abban szerintem tudunk itt segíteni, ha van már kód. Ami szűk keresztmetszet lehet, hogy az Attiny milyen alacsony feszültségen tud működni. 1 MHz-en 1,8 V-on biztosan megy. Szerintem lehet itt trükközni hogy alacsonyabb frekiről megy. Sőt érdemes lehet a power savinggel is játszani.
Ó, karácsonyi LED villogót én is készítettem pár éve. Ha érdekel, előtúrom a kódot.
Megmerem kockáztatni, hogy ezt egyszerűbb lenne megoldani néhány 4000-es sorozatú IC-vel, mint egy ATtinyvel.
Megköszönöm, ha megkeresed.
Megkérdeztem a ChatGPT-t, mivel nem vagyok annyira otthon az AVR programozásában, és adott egy kódot (az elvárás, hogy bekapcsoláskor indít, 6 órán keresztül világítanak a LED-ek, majd 18 órára aludni megy):
Nem tudom ez mennyire lesz jó, de majd kipróbálom. A NYÁK készítése még folyamatban van. Nabukodonozor Lehet egyszerűbb lenne, de azért esett a választávom az ATtiny85-re mert ilyen van itthon (SOIC-8), és a hely ahova be kell férnie (25 mm x 10 mm), adja magát. A hozzászólás módosítva: Hé, 11:41
Szerintem működőképes a kód, csak nem jó. : -) Ugyanis a watchdog timernek, ha ez is belső R-C oszcillátor, 10-20%-ot is eltérhet az értéke, és ez az eltérés ebben a kódban egyfolytában halmozódik, tehát ha ennyire egyszerűen csinálod meg, akkor valamennnyivel biztosan el fognak csúszni a napok, és szerintem gyorsan. Azt hiszem, külön RTC nélkül nincs igazán kisfogyasztású megoldás, de majd valaki megmondja.
A másik egy itt jelentéktelen probléma: elmehet a levegőbe egy-egy ébresztés, ha a WDT-megszakítás pont akkor csattan be, amikor a kód a sleep_enable() és a sleep_cpu() között jár, így a sleep_enable() előtt tiltani kellene a megszakításokat, utána meg engedélyezni. De 1 másodperces ismétlődésnél és az egész rendszer pontosságát tekintve ez amúgy sem tétel.
Igazából több sebből vérzik a kód, például:
- az ISR-nél nincs explicite jelölve, hogy a megszakítás hogyan kezelődjön - a wdt_wake-t védeni kellene azzal, hogy előtte tiltani kellene a megszakításokat, utána megengedélyezni. Igazából elég lenne meghívni a wdt_enable-t. - a 15. 16. sorok is viccesek, először szépen bit vagyolja a regisztert, aztán simán felülírja az egészet - az i változónak elég a uint16_t típus - akárhogy nézem, de nem találom a main-t, de szerintem ott van az csak nem lett bemásolva. És egyébként a wdt_wake-t nincs is használva. De az utolsót leszámítva ezek nem okoznak semmilyen gyakorlati problémát ebben a programban. A sleephez egyáltalán nem értek. Idézet: „amikor a kód a sleep_enable() és a sleep_cpu() között jár, így a sleep_enable() előtt tiltani kellene a megszakításokat, utána meg engedélyezni.” Ezt miért így kell csinálni?
A setupot most nem nézem meg a vagyolgatással és az értékadással, de nyilván arról van szó, hogy kétlépcsős a regiszter átállítása biztonsági okokból; először engedélyezzük a beállítást, aztán beállítjuk.
Az viszont igaz; hogy ha jól akarjuk csinálni, a wdt_wake változót is meg kell védeni. Így képzelem, aztán majd kijavítasz: a WDT timer szabadon fut, így bekapcsolás után először bármikor megjöhet egy másodpercen belül a WDT interrupt. Itt lehet egyedül race condition. Amikor a WDT timer túlcsordul, az nekünk nem gond, az az ő dolga. A cli() ... sei()-n belülre kell rakni a wdt_wake változó hamisra állítását is, amit jelenleg semmire sem használunk. A set_sleep_mode()-nak meg mindegy, jön-e megszakítás előtte-utána - ha minden igaz, a bitjeit semmi sem változtatja meg, csak a biztonság kedvéért állítjuk be minden alkalommal. Azt meg biztosan tudod, hogy: - az sei() garantálja, hogy a következő utasításig nem lesz interrupt, - a sleep_cpu() pedig nem egy függvény, hanem egy makró, egyetlen Assembly utasítás, vagyis nem lehet előtte interrupt. Vagyis így nem lehet race condition: ...sei(); sleep_cpu();... Források: - "Timed Sequences for Changing the Configuration of the Watchdog Timer" egy doksiban (mégis megnéztem), - https://github.com/avrdudes/avr-libc/blob/main/include/avr/sleep.h a sleep függvényekhez, - https://ww1.microchip.com/downloads/en/DeviceDoc/AVR-Instruction-Set-Manual-DS40002198A.pdf, 5.104.1-es bekezdés. Itt mit hiányolsz: "az ISR-nél nincs explicite jelölve, hogy a megszakítás hogyan kezelődjön"?
Nálunk ezzel megy a karácsonyi fényfűzér. Feleségem reklamált, hogy a gyári programban túl hirtelen változik a fényerő. Ez tulajdonképpen egy potméterekkel állítható paraméterű fader.
Olyan időzítést pont nem tud, amit te szeretnél, de nem macera beletenni.
A WDTCR állítás: megnéztem a datasheetet és azt értem, hogy miért történik két lépcső, de azt nem hogy először miért "|=" a "=" helyett.
Igazából sosem mélyültem el a watchdog lelki világában és eddig csak védelemre használtam olyan szempontból, hogy ha valami beakad, akkor a WD resetelje az CPU-t. Csak simán meghívom a wdt_enable(...) és a wdt_reset() függvényeket innen: Bővebben: Link Ah, szóval a race condition ott van, hogy a WD interruptja akkor hívódik meg mielőtt a sleep megtörténik. Szóval, lesz egy igazából hatástalan interrupt, mert nincs minek feldolgoznia és a CPU meg megy aludni. Az ISR esetén erre gondolok: Bővebben: Link (ha van beállított LSP clangd-vel, akkor az jelzi is, hogy az ISR() paraméterei hiányosak). Ezer köszi az infókat! Bőven vannak hiányosságaim az AVR területen, de a C-ben és a szoftverfejlesztés körüli dolgokban úgy gondolom, hogy erős vagyok.
Végül is igaz, ez a proci úgysem eszik többet néhány milliampernél 8 MHz-nél sem, az meg szinte elhanyagolható a világítás mellett. Mindig a legegyszerűbb megoldás marad ki. : -)
Csakhogy... a cucc 24 órából, ha jól értettem: - 8 órában világít 240 mA körüli árammal, procival együtt ez max. 250 mA, - 16 órában pedig magában fut max. 10 mA fogyasztással. Egy (találomra mondom) 2,5 Ah-s akkupakkból, mert az elemeket felejtsük el, a 8 óra elviszi a töltöttség 80%-át, a 16 óra magában futás pedig a maradék energia kb. egyharmadát. A probléma csak az, hogy egy újabb 8 órás világítási periódushoz úgyis tölteni kell az eszközt, ahhoz meg be kell dugni vagy kivenni az akkukat, foglalkozni vele, vagyis az éjszakai időzítésnek, önműködésnek gyakorlatilag nem lesz értelme - csak sokkal nagyobb akkumulátorral. Nem is tudom, miért árulnak ilyeneket, elemmel sem mehet tovább, hacsak nem villog kis kitöltéssel. A hozzászólás módosítva: Sze, 19:23
"az ISR() paraméterei hiányosak"
Ha csak ennyire gondolsz, az ISR makrónak változó argumentumlistája van, valamint nyilván az ISR_BLOCK a defaultja, azt az attribute-ot nem kell külön megadni. És el van rejtve a warning. Vagy akármi. : -) https://github.com/vancegroup-mirrors/avr-libc/blob/master/avr-libc...rupt.h:
Megnéztem pár régi kódomat, vegyesen volt benne megadva és nem megadva a kezelés módja, de az már minimum tíz éve volt: - ISR(INT2_vect) - SIGNAL(SIG_OUTPUT_COMPARE1A) A hozzászólás módosítva: Sze, 20:04
Igen, ez érthető. Nálunk telefon töltőről megy. A szoftver azért kellett, hogy szépen halványítson, ne villogva, mint a gyári vezérlő. Azért hátha van benne hasznos rész neked is.
|
Bejelentkezés
Hirdetés |
