A frekvenciától nem függ a kitöltési tényező! A PWM felbontását kell növelni. Ha a 8 bit kevés, akkor 16-ra.

Na igen, ez a másik, hogy 16 bites PWM-re váltani és úgy frekit növelni.

Rakj a LED elé egy soros ellenállást, amivel a maximális áram kisebb lesz, így a minimális is.

Utána van, de az sorosan mindegy. Ha növelem, akkor meg a nyitott állapot fényereje lesz kevés.
zombee: Attiny25. Nincs neki csak 8 bites számlálója.

Marad a szoftveres érték módosítás az alsó tartományban.

Köszi.

Csinálhatsz szoftveres PWM-et is, főleg, ha nem sok dolga van a mikrovezérlőnek. Vagy a két 8bit-es timer-t egymás után kötöd, és lesz 16bitesed. AVR-rel szinte nincs lehetetlen!

Összetákoltam egy NeoPixel I2C konvertert.

A probléma az, hogy ha NeoPixel protokollal LED-eket vezérelsz 8 bites AVR-rel, akkor sajnos semmi mást nem csinálsz, mert az Arduino lassú ahhoz, hogy emellett még mintavételezzen is, vagy egyéb dolgot csináljon. Kézenfekvő, hogy I2C-n keresztül kiadjuk a feladatot egy Attiny85-nek. Ez a chip minimális helyet foglal, 8 lába van és ezután a kommunikáció mehet hardveres I2C-vel is.

Ez igazából csak játék, mert erősebb DMA-zó IC-vel kellene mindezt megoldani (STM32), de nekem kissé nehézkesnek tűnt az egész az Arduino mellett, a Nodemcu (ESP8266) környezetet meg még nem ismerem eléggé. Majd rendelek fejlesztőpanelt.

Favágóztam egyet és egy 300 Ft-os Attiny85-nek kiadom, hogy csinálja a Neopixelt, az Arduino meg azt csinál, amit akar eközben, akár audio jelet is mintavézelezhet.

Szia!
Miért nem bírja egy uC az egészet? Ha egyszer kiadtál egy sorozatot, akár évekig is megmarad az adat, addig azt csinálsz amit akarsz. Szűkös esetben még a byte-ok kiküldése között is van 10-30usec időd, de az már tényleg agyon optimalizált cuccnál kellhet. (vagy valamit nagyon benéztem a project-nél) Nekem 100 LED-et hajt T85 dinamikusan, mintavételezve, effektezve (nem kisebbíti a dolgot, hogy benéztem a dolgot máshol és újra kell vésnem, de ez a hülyeségem miatt van)

800 kHz-en megy a NeoPixel. Ez azt jelenti, hogy két bit között 20 órajelciklus telik el. Minthogy hardveres támogatás nincs hozzá, ezért ezidő alatt nem történhet semmi más. Sok LED esetén jelentős idő eltelhet, amíg ezzel foglalkozom.

Audio-t szeretnék mintavételezni (39 kHz), utána FFT, utána NeoPixel.

Persze lehet, hogy mintavételezek 128 byte-ot, FFT, NeoPixel, utána megint mintavételezek. A kérdés, hogy probléma-e, ha két egymást követő mintavételezésnél kiesnek értékek.

Igen, byte kivitele közben nagyon pontosan kell időzíteni, semmi INT meg egyéb nyalánkságok, de szoros esetben byte-ok között van valamire idő, különben meg csak frame-ek között. Így a mintavétel=>feldolgozás=>kijelzés fog csak menni. Szerencsére eléggé pörögnek ezek a uC-k, szerintem a 20-30Hz ciklus lazán fog menni. (bár én még FFT-t nem csináltam). Tegnap találtam Basic-ben írt FFT-t LCD-re de ránézésre be volt áldozva a pontosság a sebességnek. Többi meg ASM, amit láttam...

Szevasztok!
Szeretnélek megkérdezni benneteket, mert a frekimérőmmel elakadtam.
Atmega16, 16.384MHz. Timer1 számol, portb, bit1, 41-es lábon megy be a frekvencia.
TCCR1A=0x0, TCCR1B=0x7, majd 1 sec. múlva TCCR1B=0x0.
Ha a TCCR1B=0x5 (/1024), a kijelzőn 16000Hz, ha =4 (/256), akkor 64000Hz, tehát jó.
Ha TCCR1B=0x7(external, felfutó él), akkor 8Hz bemenő jelnél a kijelzőn 370~520 -ig mindenféle értéket kapok.
Az Atmega lábon ott a 8Hz !
Mit rontottam el szerintetek?
Köszönettel.

Túlcsordul a számláló?

8Hz-nél még messze van a 65535-től 1 sec alatt !

Kód nélkül nehéz látni, de én is túlcsordulásra gyanakszom.

Azt gondolnám, hogy a TCNT1-ből valahogy Hz-et kellene varázsolnod. Nézd meg, hogy a köztes számolásnál nincs-e túlcsordulás. Nem használsz-e előjeles int-et, ahol a 64000 már túlcsordulásnak számít.

Gondolj bele, 65535/10 az nem ugyanaz, mint -1/10.

Írtam a probléma felvetésnél. A varázslás megtörtént. Ha órajelet mérek előosztóról, jó eredményt kapok ! TCCR1B=0x00 leállítja a számlálást, de portról vezérelt kapuval ua. a probléma és a kijelzett eredmény is.
1 sec mérés, kijelzés xxxHz, TIMER1 nullázás, ismét u.a. 8 Hz-nél elő sem fordulhat 1 sec alatt túlcsordulás, főként úgy, hogy 370~520 -ig mindenféle értéket kapok. Túlcsordulás,- ennek ellenére-, ha előfordulna 0-65535-ig mindenféle értéket kapnék, vagy 0-32768-ig. Szerintem.
Már néztem az asm. kódot is. Atmegán belüli valami kehére gondolok, de tanácstalan vagyok.
Remélem nem a MikroC szívat valamivel. Az unsigned long int-et kipróbálom, hátha ez......

MikroC ?! A futottak még kategóriában sem jegyzik avr fordítóként.

Melyik, amelyik fut avr fordítóként?

Avr gcc. Ha fizetni is akarsz érte,akkor határozottan Codevision avr.

Sziasztok!
Igen csak elakadtam egy AVRC program írásában TBirdre.
Tasztatúrakezelést szeretnék megoldani, melyben _delay nem lehet.
Egy megszakításom van, ami a 7szegmens kijelzőket villogtatja fel, ebbe illesztettem egy számláló változót, amit figyelgetek _delay helyett, de ez zsákutca.
Tippeket, kódrészleteket szívesen fogadnék.

Miert zsakutca?

Volatile-ként deklaráltad a változót?
Pl.: volatile unsigned int cnt = 0;

Normál Li-ion akkuról szeretném táplálni az Attiny2313-at. Termosztát lenne a garázsban. Kellene az időt mérnie, meg hőmérsékletet, meg rádión kommunikálnia.
Ha tartom az akkun a 3-4,2V-ot (kisütött - töltés alatt) akkor ráköthetem egyenest az akku kapcsaira az áramkörömet? Ha kvarcról megy, hibázhat valami időzítés stb.?

Simán rákötheted. Kvarccal pontos lesz az órajel, nem függ a táptól. Akartam mondani, hogy az A/D referenciára figyelj oda, de látom, hogy ebben a uC-ben nincs is A/D...

Igen rákötheted. Természetesen PTC-t vagy vmi biztosítékot azért tegyél be közéjük.
Max. 10MHz-es kristályt használhatsz, de szerintem kissebb is elég lesz (minnél alacsonyabb az órajel annál kevesebbet is fogyaszt, akkunál ez nem mindegy). Illetve alvó mód is hasznos lehet. A pontos időt nem biztos, hogy ebben az eszközben oldanám meg (ha muszáj, akkor tennék rá egy dedikált RTC IC-t 32,768kHz-es órakristállyal és backup elemmel így nem kell időt állítgatni ha lemerült az akku), ha már ott a rádiós kommunikáció, akkor egy ESP8266-al vagy kábeles ethernetes központi egységgel olvasnám a friss ídőt NTP protokollal az internetről majd időnként átfrissíteném erre az eszközre (plussz előny, internetről is kapcsolható fűtésszabályzás).

Ugye tudod, hogy ez nem működik?

Az unsigned int 2 byte-os. A 0x00FF-0x100 váltásnál simán előjöhet, hogy 0x1FF-et kapsz.

Kiolvasásnál vagy tiltod az interruptot, vagy leellenőrzöd, hogy kétszer kiolvasva is ugyanazt az értéket kapod-e.

Nem pont errol van szo azt ugye tudod?
Ha ilyen sok idod van inkabb ird le neki a megoldast.

Tudom, csak kötekszem.

Sziasztok!
Melyik a jobb döntés?
Ha beforrasztom az AVR-t a nyákba és kivezetem valahova az ISP 6 lábat vagy ilyen preciziós foglalatban mindig kiveszem?
A nyákot gyártattnám, lötstoppal. Ezért jönne szóba a SOIC vagy TQFP.
Mi hátrányom származik belőle, ha beforrasztom és utána programozom fel?

Négyszögjelet mér és UART-on kommunikál, semmi komoly.
Köszönöm, ebben elég új vagyok (még )

Azert hivjak ISP (in-circuit serial programming), hogy a programozas az aramkorben tortenjen. Semmilyen hatrany nem szarmazik belole, viszont oda kell fogyelni tervezeskor, hogy a programozo labakat ha mas funkciora is hasznalod akkor le kell valasztani ellenallassal, hogy ne zavarja a programozast.

Az előbbi választól függetlenül ha furatszerelt az IC, akkor ne spórolj a foglalattal, és természetesen az ISP csatlakozó is kerüljön a panelra. Az IC el is romolhat, ezért nem utolsó dolog ha lehet cserélni. Egy SMD kiforrasztásához csak egy meleglevegős páka kell, de egy furatszerelt soklábú IC kiszedése még gyakorlott kezekben is problémás lehet. (na jó, hullámforrasztóval könnyű!)

Köszönöm a válaszotokat!

Akkor jól gondoltam,csak megkérdezem, ne már az elején legyen rossz tapasztalatom mindennel.

Ha 2 eszközzel szeretnék UART-on kommunikálni (GPS, Bluetooth), akkor 2 AVR szükséges?
Arra gondoltam,hogy akkor legyen kettő. Szétosztanám a feladatokat és SDA/SCL-en kommunikálna a két eszköz. Ez barbár módszer?