Hali!
Én ennek a "mérésnek" nem hinnék. Ha már kiderült hogy a szoftver is hagy kívánnivalót, az áramot nem méri, a pwm-ből kalkulálja, ettől kezdve még saccolókának sem jó szerintem.
Persze farigcsálni lehet még kicsit a programon, ha máshogy nem akár korrigálhatod az időt, hogy percenként hozzáadsz 16mp-t és "pontos" lesz.
Valaki írta hogy a millis függvénnyel méri az időt, de a progiban egy fia millis() sincs... viszont van delay (1000), hibásan mivel a többi progi utasítás végrehajtása is időbe kerül amit elfelejt korrigálni, meg még időnként egy csomó más delay(xx). Valahonnan koppintotta a kódot, ahol még normálisan meg volt csinálva timerinterrupt-al (mint a fg. neve mutatja) aztán ezt sikerült jól elrontani. Szóval azzal is játszhatsz hogy a delay(1000) helyett pl csak delay(900)-at használsz. De soha nem lesz pontos. A minimum hogy újra kéne írni a szoftvert, de erre a hw-ra szerintem nem érdemes...

Serintem én írtam, de valójában azt írtam, hogy arra kellene visszavezetni. Mert nincs benne sehol sem.

Ja nem! Bocs, nem olvastam rendesen mindent el!

Olvassad el a libeket is. JC_Button.h

Nem rágtam át magam mindenen, azt látom "felületesen megnézve" a loopban meghívja a timerinterrupt nevű függvényt, (aminek köze nincs interrupthoz) abban növeli a másodpercet(időt)(megcsinál még kismillió időzabáló dolgot) és a loop végén ott figyel a delay(1000).

Ez egyértelmű Ez a program semmirevaló.

Nem lehet hogy a jcbutton lib-ben a csak a saját gombnyomás időzítéshez használja a millist, de a főprogram órájához-időszámlálójához köze nincs?

Annyira nem rágtam át rajta magamat. ha ilyent akarnék csinálni, akkor a timer1-et belőném 1 Hz-re, akasztanék rá egy megszakítást az időméréshez. A feszültség méréshez pedig a belső referenciát használnám, nem a tápot.

Mindenkinek köszönöm a hozzászólásokat. Igen az áram értékeket megváltoztattam úgy hogy soros áram mérővel mértem az egyes értékeket és arra átírtam a programban. azokkal nincs is semmi gond szépen tartja végig azokat.
jó lesz ez szerintem ha a számolást korrigáljuk. Köszönöm!

Korrektül van megoldva, de kisebb kompromisszumok kerültek bele. 64-es előosztóval megy, és minden túlcsorduláskor (256) lép egyet a számláló, amikor megszakítás van. Lehetne pontosabbra is csinálni, ha a timer0 nem 256-ot osztana, hanem csak 250-et. Ekkor még órát is csinálhatnánk vele. De ekkor a PWM funkciók nem működnének vele mindkét kimeneten, hanem csak az egyiken, mivel más üzemmódban kellene működtetni. És csak 249-ig lehetne állítani a kitöltési tényezőt. Bután nézne ki. Így most nem pontos, de elegáns.

"Így most nem pontos, de elegáns." - nem értem, mi a nem pontos.
A millis() elméletileg tökéletesre van megírva, nézd meg a kódját! A hibát csak a kvarc órajelének pontatlansága okozhatja, mivel a millis() 16 000 000Hz-et vesz órajelnek pontosan.

16000000/64=250000. Tehát az órajel osztva az előosztóval. 250000/256=976,5625. Az előosztóból kijövő jelet a timer0 leosztja 256-tal. Ez 976,5 hertz. Másodpercenként 976,5 megszakítás a millisnek. Ezt nem nevezném pontosnak.

Nem nézted meg a forráskódját a millis-nek, ez 100%. Ha te is tudod, hogy 976.5Hz-ként jön a megszakítás, akkor miért is kellene 1ms-mal növelni a változót az 1.024ms helyett? Pont ezt írom már le kb. 3-szor! A függvény tudja, mennyi időnként jön a megszakítás, és figyelembe is veszi...

Szaisztok!

Van egy érdekes probléma, amit mintha megértettek volna egy másik fórumon, de én még nem értem pontosan.

A lényeg, hogy az ATMEGA328PB képes a feltöltött kódot felülírni bizonyos esetekben. A kérdező ezt a linket küldte:
Bővebben: Link



Itt valami olyasmi van, hogy bizonyos esetekben képes olyan hibát generálni, hogy átugrasztja egy másik memória címre a stack-et(?) vagy a belépési pont címét(?) változtatja meg ez a hiba. A bootloader hibátlan marad, míg a feltöltött kód nem futtatható tovább.

Valaki érti pontosan mi is ez? Megtenné, hogy elmagyarázza ennek a hibának a mibenlétét és hogyan lehet kiküszöbölni?

Köszi!

Azt írja, hogy ha valaki nem használja a Brown Out Detection-t (alacsony tápfeszültség érzékelés), vagy kicsire veszi a küszöbértékét, hogy az utolsó leheletet is kicsikarja a telepből, akkor a mikrokontroller váratlan dolgokat csinálhat az alacsony tápfesz miatt és akár a bootloader-re is ugorhat a vezérlés, aminek eredményeképpen a feltöltött kód felülíródhat. Ha valaki nem használja a bootloadert ilyen üzemmód mellett, akkor nem találkozhat ezzel a problémával, a bootloader nem ronthatja el a kódot - mert ugye nincs is ott.

Aki ilyen megjósolhatatlan eseményt nem akar, az használja a Brown Out Detection-t. Vagy direkt programozza fel a mikrokontrollert. Utóbbi azért is jó, mert annak a tárhelye is használható másra. Illetve a bootloader késlelteti az Arduino indulását mintegy másfél másodperccel és lehet, hogy ez kritikus a program indulása/futása szempontjából.

Na, ez van a szövegben. A fordítás nem szöveghű, hanem értelemszerű, illetve az én magyarázatom is benne van. Remélem megteszi.

Az újabb bootloadernél az induláskori késleltetés szinte nulla! Erről is meg lehet pl. ismerni. Ez csak plusz infó. Nekem nagyon bejön.

Ha érdekel és tudsz angolul, itt egy szuper magyarázat:
Bővebben: Link Igazából a google első találata a "how millis() works" kulcsszavakra.

"At each interrupt of 1024us the millis() timer is incremented. Since 1024us is greater than 1000us, the millis() timer is too slow and needs correcting.
The idea is to store the error and accumulate it until it surpasses a threshold, upon which the millisecond timer output is corrected.

So to correct to a 1ms output,
The number of interrupts before a correction is needed is:
1000.0/24 = 41.66.
The above equation represents the number of 24us periods that add up to 1ms i.e after 41.66 interrupts the error will be 1ms. Of course you can't get 41.66 interrupts so you have to wait for the following interrupt to detect when the error is greater than 1000us. This will be when 42 interrupts have occurred.
The clever part of the algorithm is that the error accumulator is incremented by 24 every interrupt (the division is not performed - that just lets you see the idea). When this variable is greater than 41.66*24 i.e 42*24 = 1008 then the error is corrected.
The next really, really, clever part of the algorithm is that the error variable is not reset to zero - you just subtract the 1ms value (since that was what was corrected) leaving the last value of the error in the accumulator i.e. it will be 8 on this occasion. This error then accumulates again and the millis() timer is again adjusted when the error is greater then 1ms."

Megkövetlek. Felületesen olvastam el. Túlzottan a timerből indultam ki. Szoftveresen kompenzálja.
Le is teszteltem:

Köszi!

Valamivel többet értek belőle. Utánanézek és ki is próbálom a direkt programozását.

Sziasztok!
Mosfetet ráköthetek egy arduino pwm lábra a képen látható módon vagy mindenképpen szükséges mosfet driver? Mosfetből olyat választottam, ami átengedi a kívánt áramot 5V gate feszültség mellett.

Én nem ezt a MOSFET-t használnám. Abban sem vagyok biztos, hogy ha áramgenerátorként használod az LM317T-t, akkor jót tenne neki ilyenformán a PWM. De erről nyilatkozzon az, akinek van vele tapasztalata.
Milyen feszültségen mekkora áramot akarsz kapcsolni? Ehhez válassz MOSFET-t.
Ha ez megvan, akkor jöhet a gate driver kérdése. Ha elég kicsi áramot kapcsolsz, akkor fogsz találni logic level MOSFET-t. Ezzel rendben lesz a feszültség. Az áram lehet kérdéses, ugyanis a gate kapacitást folyamatosan fel kell tölteni, majd ki kell sütni. Megnézed az adatlapban, hogy a mikrokontroller adott lábának mik a sink/source paraméterei. Ez nem mindig szimmetrikus! A láb és a gate közé tegyél áramkorlátozó ellenállást, ami védi a túláramtól az MCU kimenetét.
A feladattól függ, de én inkább IRL540-t vagy AO3400-t használnék.

Nem vagyok benne biztos hogy szükség van külön fetre, szerintem lehetne a 317 adj lábánál modulálni. Találtam is rá példát: Bővebben: Link

Elnézést, egy interneten talált képet csatoltam be, ami nem volt teljesen egyértelmű. Jelenleg engem csak a FET meghajtás érdekel. A konkrét kapcsolást és a kivitelezést most csatolom. 12V a feszültség és kb. 12A az áram. Led szalaghoz készítenék egy távirányítós fényerő szabályozót. Több olyan példát is találtam, ahol a mellékelt módon hajtották meg MCU-val a FET-et.

Ez így egy az egyben jó lesz, ezzel a MOSFETtel.

Semmi baj vele. Én is használom ezt a FET-et még ellenállást sem raktam bele. Igaz, hogy védi a kimenetet, de lassítja és ezáltal melegíti a FET-et. Több éve megy PIC-el ellenállás nélkül.
De ha biztosra akarsz menni, akkor legyen ott az ellenállás, de 100ohm-nál nem kell nagyobb, valamint az IRLZ44 helyett pl.: az IRLZ34-nek fele akkora a gate kapacitása.

A freki minél nagyobb lesz, annál több lesz a FET-en a veszteség.

Köszi mindenkinek a segítséget.

A freki az Attiny85 pwm frekife lesz, ami kb. 500Hz.

Elég 100 Ω ellenállás a µC pin és a FET gate közé, illetve a gate és a föld közé tegyél még 10k-t, hogy véletlen se lebegjen.

Sziasztok

Arduinóhoz kapcsolódó nyomógombon akarok megoldani pergés mentesítést de nem szoftveresen hanem hardveresen. Itt esett szó róla és én arra lennék kivéncsi hogy ez a jó megoldás? A C ábrán láthatóra gondoltam. Kérdezem , hogy mindenképpen be kell építeni r1 ellenállást, még akkor is ha az arduinó felhúzó ellenállása aktiválva van a programba?

Az R1 ellenállás és a belső felhúzó ellenállás nagyságrendekkel eltérhet egymástól és utóbbi nem oda kapcsolódik, ahova a külső.