késik az órád

A delay(1000) nek is van futásideje, a digitalWrite is késlelteti a program futását. Ha pontos mérést szeretnél, timert kell konfigurálnod hogy 16biten számoljon, előosztással, és a stoppert valahogy az AVR által indítani (vagy a szkópot rárakod), így a portművelet időigénye nem okoz eltolódást. De ezt a blink programot ne mérd szkópon, mert ez nem ad pontos eredményt.
Atmega328-nál ki lehet az órajelet az egyik lábon vezetni, nem tudom tud-e ilyet az Attiny. Ha tud, akkor szkóppal rá tudsz nézni.

Na álljunk meg egy szóra, ha valami lassítja a program futását, akkor nem gyorsabban kéne villognia,
hanem épphogy lassabban, tehát kevesebbszer. Nemde?

Egyébként úgy néz ki, van itt valami "Clock output on PORTB4; [CKOUT=0]" beállítás, az volna az órajel kivezetése jól sejtem? Már csak kíváncsiságból, lehet holnap ránézek a szkóppal.

De egyébként csak úgy mellékesen kérdem csak nekem tűnik ilyen marhanagyon pontatlannak? Vagy ez még fel sem tűnt eddig senkinek? Már úgy értem, hogy egy percen belül 1mp -t sietni, az azért óriási. Ennél ha egy jól beállított NE555 timert csinálok, az sem siet ennyit.

Jut eszembe a beállításról, az nem lehet, hogy a belső órajelet mondjuk szoftveresen kalibrálni kellene? Most hogy így nézem, az extreme burner fuse bit beállításainál van valami kalibrációs mező is...
Na majd holnap megguglizom...

Én ezt írtam: "késlelteti a program futását." - ez szerintem azt jelenti, hogy lassabban fut a program, tehát több időt kell várni, amíg a LED állapotot vált. Vagy valahol gyorsabbat írtam?
A pontosságról én csak azután nyilatkoznék, ha a "Clock output on PORTB4; [CKOUT=0]" - ot megcsinálod, és szkóppal megnézed, mekkora az órajel pontosan. Kézben a stopperrel nem lehet pontosan mérni ilyen kis egységeket.
Azt tudom, hogy a belső oszci nem pontos, a kérdés, hogy mennyire?
Ha jól számolom, 1/3600-zal kellene eltérnie a névleges frekvenciától (egy perc alatt 1mp hiba), ez 2222 Hz. 8 000 000 Hz-nél 2222Hz nem sok szerintem. 0,056% hiba. Meg kell nézni, az adatlap mennyit specifikál. Atmega328-nál van OSCCAL regiszter, azzal lehet finomhangolni a belső oszcillátort azt hiszem. Úgy is tudom, hogy ezek gyárilag kalibrálva vannak (ez a 0.056% hiba nem is olyan rossz. Ellenállásból 0.1%-osat veszünk.).
Na majd kiderül, ha megnézed szkópon.

Az, hogy a belső oszcillátorok mennyit késnek vagy sietnek a gyártási körülményektől is függenek, s általában nincsenek "jól behangolva". Némelyik mikrovezérlőnél van egy gyárilag megadott kalibrációs érték, amit a felhasználói programnak kell előkotorni és egy (vagy több) bizonyos regiszterbe beírni. Mindamellett a belső oszcillátornak van egy hőmérséklettől és egyéb paraméterektől függő instabilitása is, ami miatt nem érdemes a kalibrációt hajhászni. Ezért használunk a kritikus időzítéseket kívánó alkalmazásoknál kvarc rezonátort vagy külső kvarc oszcillátort (pl. a PIC18F4550 full speed USB perifériája miatt).

Elszámoltad, ha 1 perc alatt 1 másodperc az eltérés, akkor az nem 1/3600, hanem 1/60 hiba. És ez elég rossz.
Bár ha jól tippelek Roli akkuvédő kapcsolást csinál, ott az időzítés szerintem annyira nem kritikus, akár ennyi hiba is beleférhet. Gondolom a mikró mér egyet, és aztán elmegy aludni, ami lehet dinamikus. Pl. 10-90% töltöttség között ez lehet 1 perc, 5-10 és 90-95% között 10 sec, alatta és fölötte pedig folyamatosan figyel.

Lehet, hogy elvesztettem a fonalat: az ATTiny85 belső oszcillátoráról van szó?
Az adatlapja szerint a gyári kalibrálás 3 V-ra és 25 C fokra vonatkozik, s a "pontossága" 10 %, statisztikusan ennyivel térhet el a névleges értéktől. Ha más feszültségen/hőmérsékleten használod az MCU-t, akkor az eltérés a névlegestől még ennél nagyobb is lehet.

Ha az OSCCAL regiszter segítségével egy adott tápfeszültségen és hőmérsékleten magad behangolod, akkor ezt kb. 1 % pontossággal tartja (ugyanazon feszültségen és hőmérsékleten). Ennyit tud.

Ez akkor nem vágom valahogy. Ha a program lassabban fut, akkor kizárt hogy a LED gyorsabban villogjon. Legalábbis az én meglátásom ez. De mindegy is, annyira ez nem is fontos...

Igen ahoz kell, és annyira engem se zavar, mivel be van tervezve a kvarc (7.3728MHz) is az alaplapra, ugyanis soros kommunikációval küldi a mért értékeket (cellafeszültség, cellahőmérséklet) a kijelzőt és a rendszert kezelő arduinonak. Nem mertem bekockáztatni a belső oszcillátoros időzítést, mert ahogy olvastam, ha a kvarc nincs jól megválasztva, még akkor is lehet hiba a soros kommunikációban...

Egyszerű soros kommunikáció AVR-rel...


Csak azért jegyeztem meg ezt a "ponosság dolgot" mert nekem nagyon szembeötlő volt...

Igen arról van szó. Van ehez egyébként valami képlet, hogy ki lehessen számolni a pontos értéket adott feszültségnél / hőmérsékletnél egyébként? Vagy ez is csak kísérleti alapon állítgatós /méregetős módszerrel kivitelezhető?

SMS-el vezérlek (SIM800l -el keresztül) arduino mini pro-t, a nagy SRAM szükséglet miatt át kell dolgoznom a kódot.
Azt vettem észre, ahogy dagad a kód, random hibák jönnek elő. Kivettem a kódból most a soros monitorra való kiirtást, a hibák előfordulása minimálisra csökkent, de tovább kell mennem, hogy minden funkció tutira működjön.

A változókat úgy osszam el, hogy globálisak csak azok maradjanak, amit több függvény használ, a többit csak abban a függvényben deklaráljam ahol használom?
Vagy, ha globálisként lefoglalom nekik a helyet akkor jobban járok?

Nos úgy néz ki az órajel nem pontos, megmértem, igaz csak DMM -el (nem akartam kibontani a szkópot)
és 8.280MHz - 8.290MHz értéket mutat, 53% -os kitöltési tényezővel (Vici VC99+).
A tápfesz az USB -ről megy 4.715V - 4.725V.

A Clock output on PORTB4; [CKOUT=0] működik, kiteszi az órajelet.

Úgy néz ki, akkor itt van az ördög elásva, így már rögtön világos, nagyobb órajel, gyorsabb villogás.
Már csak kíváncsiságból is, rákeresek lehet -e valahogy kalibrálni szoftveresen.

Egyébként a multi 60MHz -es tartományban is +-0.5% a pontossága adatlap szerint.:
VC99 datasheet / size 223kb

Szerintem amit lehet használj globálisan. Ha pl. használsz egy i nevű int ciklusváltozót az f1, f2 és f3 függvényekben is, akkor az i-t globálisan deklarálva harmadannyi helyet foglal, mintha mindhárom függvényben lokálisan deklarálnád.
Viszont az problémát okoz, ha pl. f1 az i változót használja egy ciklusban azon belül hívogatja f2-t, ilyenkor valamelyik lokális legyen

4 String-et használok, és pár float-ot, ők a legnagyobb helyfoglalók, elsősorban őrájuk gondoltam.
A string-ek csak lokális változók.

Az nem mindegy, hogy string vagy String. Ha egy mód van rá javasolt az egyszerű char array-t használni.

Bocs a pongyolaságért, Stringet használok.
Példákból vettem át részeket, azért maradtak benne, igyekszem átállni char array-ra.
De addig is globálisak vagy lokálisak legyenek?
Azt hogyan tudom megállapítani melyik a jobb megoldás? Van rá valami szabály, vagy szokás?

Nincs olyan, hogy jobb megoldás, mármint általánosságban. Mindennek van előnye és hátránya, a konkrétumok ismerete nélkül nem lehet tuti tippet adni

például így kérdezem le a térerő nagyságát:

Az eredeti példádra - egy int teroszam; berakása után - ezt adja:
Sketch uses 2962 bytes (9%) of program storage space. Maximum is 30720 bytes.
Global variables use 53 bytes (2%) of dynamic memory, leaving 1995 bytes for local variables.

Némi optimálás után:

Sketch uses 2918 bytes (9%) of program storage space. Maximum is 30720 bytes.
Global variables use 47 bytes (2%) of dynamic memory, leaving 2001 bytes for local variables.

Azaz 44 byte kódot és 6 byte adatot spóroltunk.

Kicsit átalakítva:

Sketch uses 658 bytes (2%) of program storage space. Maximum is 30720 bytes.
Global variables use 31 bytes (1%) of dynamic memory, leaving 2017 bytes for local variables. Maximum is 2048 bytes.

Ez az előzőhöz képest kb. 2250 byte kód és 16 byte adat spórolás.

(Apróság: nem tudom, hogy a GSM.signalQuality(); mit ad vissza, illetve a kódokat nem is teszteltem, csak fordítottam).

Az AVR az Harvard architektúrájú, tehát MINDEN adat a memóriába (2 kB SRAM) kerül, csak az utasítások maradnak a háttértárolón (32 kB flash), vagyis az inicializáció során mindent átmásol. Az összes változónak lefoglalja a helyet, a konstansoknak is. Sok szöveget, karakterkészletet a, PROGMEM módosítóval, illetve a kiírásokat F makróval érdemes használni. https://www.arduino.cc/en/Reference/PROGMEM

A globális változó nem jó, kerülni kell. A használatukkal nyert néhány bájt ára a karbantarthatatlan spagetti kód. Globális, több helyen is használt ciklusváltozó pedig öngyilkosság. Ez olyan trükk, aminek legfeljebb a néhány bájt memóriájú mikrokontrollereken volt létjogosultsága, és akkor is sok bosszúságot tudott okozni.

Ez elég nagy eltérés. Szerintem kalibrálható, ha szükséges. Régebben olvasgattam róla, tehát anyagot találsz majd róla bőven.
Ettől függetlenül, lehet, hogy pl. 9600-as soros porti sebesség tolerálja ezt a hibát. A másik lehetőség, hogy ezt a gyorsabb 8MHz-et definiálod az Arduinoban, akkor nem kell kalibrálnod sem, minden időzítés ezzel lesz számolva, a soros portod se fog hibázni nagyobb sebességen se. Lehet a board fájlban kell átírni a sebességet 8000000Hz helyett 8200000-ra. Majd látod hogy döntesz.

GSM.signalQuality() Striget ad vissza.
Bővebben: Link

Kétségkívül egyszerűbb az élet, ha lokális a változó, de a globális se teszi karbantarthatatlanná. Persze plusz hibalehetősés, és plusz odafigyelést igényel.

Akkor érdemben nem tudsz spórolni azzal, hogy a String objektumot kihagyod és char array-t használsz helyette. Hacsak át nem írod az egés lib-et

Az adatlap Figure 22-42. ábrája (Calibrated 8 MHz RC Oscillator Frequency vs. OSCCAL Value) mutat valami összefüggést a az OSCCAL regisztervbe írt érték és a frekvencia között. A leolvasás pontatlansága miatt én inkább a próbálgatós módszerre voksolnék.

Próbálom telepíteni a firmware-t a klón USBASP -re, de valahogy nemigazán sikerül.

FW update...

Az avrdude azt mondja, hogy nincs telepítve a driver. Pedig a libusb ott van... Most akkor mi van?

Ezt velem is eljátszotta. Az avrdudess.exe mellé kell egy libusb0.dll vagy libusb1.0.dll. A zipben megtalálod.

Úgy néz ki, ez nem nyert hangszórót. Bemásoltam azt a libusb*.dll -t is ami a gépemen van, a hibaüzenet ugyanaz, próbáltam azzal is amit küldtél, a hibaüzenet ugyanaz...

Van egy libusb0.sys is az avdudess mappájában. Az neked megvan?