Igen, erre celoztam a 'magabiztos idozites'-el

Köszi a gyors válaszokat!
Lehetséges, hogy maga az időzítés jó, csak az időmérésből jön ki hülyeség és hogyan mérjek időt a megszakítások között ha nem ajánlott a megszakításban?

(Az 1 - 2 hozzászállásodból nem tudom megítélni a gyakorlati tudásod!)
De ilyen gyors időzítésekhez jobb lenne ez a lapka: Bővebben: Link

CPU sped 72MHz
És konfigurálhatóak a megszakítások, nincsen összeakadás.
Arduinoban is könnyen programozható.

Vagy ha kellenek az arduinos csatlakozók itt egy komolyabb: Bővebben: Link

Én is gondoltam egy gyorsabb hardverra: esp32-est szeretnék, csak még nem érkezett meg(szállítás alatt van), ezért gondoltam, hogy arduinoval próbálom ki a szoftveres részét és itt akadtam el.

Az igaz, hogy egyszerre 1 ISR fut, és az nem megszakítható (hacsak azzá nem tesszük, de az valóban tűzzel játszás kategória, ha ész nélkül csináljuk), de attól még a micros hívás működik. Ha megnézed a belsejét, akkor látod, hogy az óra átfordulást helyesen kezeli feltéve, hogy a teljes periódusnak a felénél ne hosszabb az ISR-ek futása.

Viszont a várakozás ISR-ben tényleg nem jó ötlet, és SZVSZ esélyes, hogy elrontja az óra értékét, mert 1-2 átfordulást nem tud számontartani a rendszer a túl hosszú ISR blokkolás miatt. (Hogy konkrétan veszélyes-e, az abból derül ki, hogy mennyi az átfordulás periódusideje, és ehhez a delay-hez hogyan viszonyul. Illetve a delay belső megvalósításán is sok múlik, mivel pont az időalapot rontjuk el, a delay lehet, hogy eleve rosszul fog működni...)

Minden megoldható, de van amit nem érdemes! Megszakításban várakozni pont ez a kategória.

Azért azt nem hinném, hogy az ATMega pontossága nem volna elegendő! Ha kellően ügyesen programozod, akkor kb 1 órajelnyi pontosságot is el tudsz érni tetszőleges késleltetés mellett. Ami ugye 1/16 us, nem túl sok idő.

Nem bunkóskodni akarok, de ha ezzel a csippel nem tudod elérni a kellő pontosságot, arra nem lesz megoldás egy gyorsabb csip sem, mert végsősoron azt is programozni kell, és ugyanezeket a hibákat ott is el lehet követni.

Szerintem annyi hiányzik a programból, hogy a jel függvényben a TCNT1 számlálót nullázni kellene a compare interrupt engedélyezése előtt. TCNT1=0

Ha növelni kell a pontosságot, akkor ezeket a trükköket lehet alkalmazni:

* attachInterrupt helyett közvetlen módon írni pin change ISR-t és a csip adatlapja szerint konfigurálni (az attachInterruptnak van egy több mint 30 órajelnyi overheadje, mert függvény kihíváskor az összes regisztert menti).
* digitalWrite helyett közvetlen portkezelés (100-as nagyságrendű órajel helyett 1-2 órajel)
* Pin change helyett input capture-t lehet használni: ezzel pontosan le lehet olvasni, hogy mikor történt a bemenet.
* timer+digitalWrite helyett a timer PWM kimenetével is elő lehet állítani a kimeneti jelet. Persze sokkal bonyolultabb, de az input capture-rel kombinálva ezzel a megoldással valóban el lehet érni órajel pontosságú reakciót.
(Az utóbbi kettőhöz azokra a lábakra kell költöztetni a funkciókat, amiken ezek a funkciók működnek.)

Persze mint a digitalWrite, mint az attachInterrupt késleltetése fix, tehát nem okoz szórást csak egy fix eltolást időben, ezért ha csak a pontosságot kell növelni, az is megoldás, ha ezeknek a késleltetését kiméred, és utána a kódban az OCR1A regisztert állítgatva kompenzálod.

Azt írtad, hogy a micros nem működik: a micros az idő lekérdezése, ami tökéletesen működik, és teljesen normális is használni - bár érdemes lehet inline-osítani, ha tényleg gyors rendszert kell csinálni.

Várakozni valóban nem kellene, ezzel egyetértek. De a delayMicroseconds egyébként tudtommal nem használ interruptot, hanem sima busy wait loop megvalósítása van, így éppenséggel pont működik is ez a megvalósítás SZVSZ...

Ja, és nem akarok az ördög ügyvédje lenni, de ha mást nem csinál a csip, akkor a jel megszakításban is várakozhatsz akár már az első kiadandó élig is, aztán tovább a második élig.

Sőt, ha nem csinál mást a program, akkor a legegyszerűbb, ha az egész logikát megírod a loop-ban:

* Jött input? Nem akkor pörgünk továb, igen akkor:
** Várunk
** kiadjuk az első élet
** várunk
** kiadjuk a második élet
** pörgünk tovább

Ezzel is néhány tíz órajelnyi pontosságot el lehet érni, mert az üres loop-ban az input ellenőrzése kb ennyi időnként lefut. Ha beteszel egy pin toggle parancsot (PINB=PORT_MASZK - az inputra írás port toggle-t jelent, lásd adatlap - egyetlen utasítás, alig változtatja meg a mért rendszert), akkor szkópon meg tudod nézni, hogy milyen periódussal ellenőrzi a program a bemenetet a négyszögjel mérésével.

Mennyire rövid a bemeneti jel, és mekkora pontosság kell?

Teljesen igazad van, hogy a gyorsabb chip nem segít. Ezért kérek tanácsot a kódhoz.
Valamiért a TCNT1 számláló nullázása nem segített, legalábbis a soros monitor tartalma alapján nem változott semmi. A tippeket igyekszem minél előbb kipróbálni.

Emellett egy kijelzőt vezérel és két gomb segítségével még pár értéket átállít. Az a része jól működik és bízom benne, ha a megszakítás része frankó lesz, akkor össze tudom ollózni a kettőt.
A jel megszakításban 500 us késleltetés felett csinált hülyeségeket az időmérésnél (gondolom ezért nem ajánlott késleltetni megszakításban) és nekem szükségem lenne élesben is a micros értékre.
Néhány tíz órajelnyi pontosság bőven megfelelne. Sőt még valamit el is kéne rontani, mert túl jó lenne.
Kb 5. 10 us-es megbízható pontosság mind a jel érzékelésben mind a késleltetésben elég lenne.
A jelem egyébként 10, 15 us-es időtartalmú, ezért is gondoltam a megszakításra, hogy ne maradjon le véletlenül egy jelről sem, de ha ezt meg lehet csinálni loopon belül akkor én hallgatok rád.

Fog kelleni a megszakítás. Valamint 1 adatot még nem közöltél. Azt írtad, hogy az impulzus az rövid, de azt nem, hogy milyen időközönként érkezik. Ahogy asch írta, ha nem túl sűrű akkor lehet várakozgatni.

Ahogy számolom a legrövidebb ídőköz kb. 6 ms. Gondolom akkor ez ritkának számít.

Mi a konkrét hibajelenség? Egyáltalán nem ad választ a bejövő impulzusra a rendszer, vagy valamit rosszul ad? Kiderül, hogy mi akad el? A jel() függvény sem fut le, vagy csak az időzítő nem működik? A számláló összes paraméterét végigellenőrizted? Én csak ránézésre mondtam, hogy a TCNT1 nullázása hiányzik, de ettől még a konfiguráció is lehet rossz, azt nem ellenőrizgettem végig. Elég időigényes az adatlappal összevetni az összes regiszter értékét...

A serial kommunikáció Arduino alatt szinkron, azaz ha kiiratsz valamit, akkor addig nem fut tovább a kódod, ameddig át nem ment serialon. Emiatt realtime dolgok debuggolásában nem lehet egyszerűen használni. (1 vagy két bájtnyi puffere van - nem emlékszem pontosan, ha csak annyit írsz egyszerre, akkor lehet vele várakozás nélkül adatot küldeni.)
(Ha nagyon muszály seriallal debuggolni, akkor lehet írni saját pufferelten küldő serial libet, de inkább ésszerűbb szkóppal nyomkövetni a történéseket, akár 1-2 lábra debug kimeneteket téve)

Oszcilloszkópod van? Én olyan mérési elrendezést csinálnék, hogy egy másik Arduinoval adnám a trigger jelet - mondjuk periódikusan, ezt tenném az egyik csatornára, és erre triggerelném rá a szkópot.

A másik csatornára pedig a kimenetet tenném és nézném, hogy a triggerhez képest hogyan jön, jön-e egyáltalán?

Mivel mást is kell csinálnia a programnak, ezért valóban jobb lesz interruptot használni erre a célra, ahogy el is kezdted. Egyetlen sima loop-ba tenni minden funkciót túl macerásnak tűnik.

Még nézegettem egy kicsit a kódodat:

A WGM12-t nullában hagynám, nem kell ide waveform generation mode. Az általad választott módban az OCR1A match nullázza a számlálót, azaz átfordul. Tehát nem az eredeti 65536-os periódus szerint járatod a számlálót. Nem vagyok biztos benne, és hirtelen nem találtam meg az adatlapon, de nem lehet, hogy ebben a módban nem ad TIMER1_COMPA_vect interruptot a gép? Nekünk nullázásra nincsen szükségünk csak az interruptra, ezért a legbiztosabb a Waveform Generation alrendszert teljesen kikapcsolni.

Ahogy én állítanám erre a célra a timert:

* Alapból ki van kapcsolva (TCCR1B=0)
* jel függvényben bekapcsolnám egyetlen futamra ezekkel az utasításokkal ebben a sorrendben:
** TCNT1=0
** OCR1A = 10000; //elvileg 625 us az időzítés
** TIMSK1 |= (1 << OCIE1A); // compare match interrupt enabled
** TCCR1B=(1 << CS10); //előosztót nem alkalmazok
* Interrupt handlerben pedig teljesen kikapcsolnám a timert:
** TIMSK1 = 0;
** TCCR1B = 0;
** TCNT1 = 0; // Biztonság kedvéért, hogy minden definit állapotban legyen, de valójában felesleges

Ha nincs is oszcilloszkópja, akkor meg 6$ körüli árban már kap 8 csatornás logikai analizátort. Időzítéses feladathoz szerintem létszükséglet.

Van oszcilloszkópom, ki is próbálom amit írtál. A Serial debuggolásban azért bíztam meg, mert 50 hz-es jelet küldtem egy másik arduinóval eddig is és a 2 beérkező jel között bőven van ideje kiírni a dolgokat, főleg 2.000.000 baudrate-nél. Ebből a hibakeresésből adódott, hogy kiírja az adatot, tehát biztosan jár mindkét megszakító részben, ugyanis csak ilyenkor változik a megszak1 és a megszak2 logikai értéke 1-re.
Ha az időmérés nem csap be, akkor a két megszakítás közt eltelt idő állandó 8us az OCR1A regiszer értékétől függetlenül. És ez lenne az egyetlen hiba amit nem értek. Az időzítő megszakítás működik, de a jel függvényben lévő engedélyezésétől számítva állandó, rövid idő elteltével következik be minden esetben.

Az előzőhöz még 2 dolog:
-áttértem 2M baudrate-ra, azért írtam annyit
-áttettem a timer interrupt engedélyezését a jel függvényből a loopba és szépen megszakít 625 us-es ídőközönként, ezért gondolom, hogy a konfig jó.

Csak beírom a problémám egyik okát.
Ezek a kis rádiós modulok kifejezetten érzékenyek a tápra. A probléma vélhetőleg az lehetett, hogy az XC6206-os stab, ami csinálja a 3.3 voltot, az nem szerette azt, ha nincsen terhelve. De nem csak ez, az AMS1117 sem. Ilyenkor megugrott a kimeneti fesz, vagy gerjedt, nem tudom. A lényeg az az lett, hogy a stab kimenetét le kellett terhelni 500 ohmmal. Ezek után jó lett az NRF24L01-es modul működése. Alap dolog, de pár estém ráment.

Van egy tippem: nem állítod le a számlálót (nem úgy, ahogy javasoltam , folyamatosan pörög. Ezért el is éri az OCR1A értéket magában és bebillen az interrupt flag. Ugyanis a tiltással a TIMSK1-ből nem azt tiltod, hogy bebillenjen a flag, hanem azt, hogy ez a flag kiváltsa az interruptot! A flag tehát már aktív amikor engedélyezed az interruptot, és így azonnal(amint a pin change ISR handler visszatért) már megyünk is az időzítő ISR-be. Ezért ilyen kicsi az eltelt idő és ezért mindig ugyanannyi.

A flag törlését a státusz regiszterben a megfelelő pozícióba 1 írással lehet kérni. A számláló nullázása után volna érdemes. A példákban azért nem szokott bennelenni az IT flag törlése, mert az interrupt végrehajtása automatikusan törli, és nincs szükség manuális törlésre. A te esetedben azonban az óra periodikusan jár, ezért ezt a flaget manuálisan törölni kell az ISR engedélyezése előtt.

A másik megoldás, hogy amikor nem használod, akkor kikapcsolod a számlálót. A legjobb megoldás a kettőt vegyítése: kikapcsolod a számlálót amikor nem használod, viszont használatkor nullázod az ISR kérés flaget.

Pedig még gondolkodtam is ezen a jelenségen, amikor a javaslatomat írtam. De mégse tettem bele explicit törlést, mert ha úgy van megoldva ahogy javasoltam, akkor nincs szükség rá.

Úgy érted, hogy a modulon is van feszstab, és azzal van a gondod? Vagy ez a teáltalad épített áramkörön van?

Én 18650-ről járattam regulálás nélkül: az eleve a specifikált feszültségen belül van feltöltve, a merülést pedig mértem a mikrovezérlővel. Úgyhogy nálam nem lehetett ez a gond.

Ne a stabban keresd a hibát, annak semmi köze ehhez. Bármely tápot ha terheled lesz rajta feszültségesés, még ha csak millivoltokban mérhető is. A hiba elsősorban az ön készülékében van. Értem ezalatt, hogy ez a modul alapból elég "finnyás" és érzékeny mindenre, másrészt nem tudom, hogy az áramkört hogy alakítottad ki hozzá, de adatlap szerint 22uA a készenléti árama, azt egy jó puffernak ki kell tudni egyenlíteni.
Egyszer volt a kezem alatt ez a chip, azóta messzire kerülöm.

Ez az NRF egy zsivány dolog egyébként! Rendeltem egy szériát a fröccsentett változatból, és jel detektálásra néha tudtam használni. Aztán miután kellően felbosszantottam magam, rendeltem a rendes kocka kivitelből is, és érdekes módon pöccre ment az összes közülük.

Az vonal egyik végén 18650-ről megy direktben minden, annyi variálással, hogy a NRF betápján van egy soros 20 ohm és egy 3.6 voltos zéner, majd puffer, 100 mikrofarád. Ez az oldal működik. A másik végén az arduino 5 voltja van egy R-C tagon keresztül ráengedve egy 3.3 voltos feszstabra, kimenetén egy elő-terhelő ellenállás és egy 100 mikrofarádos puffer. Ezen az oldalon vannak a gondok.
De még mindig küzdök. Azon az oldalon, ahol az ardu 5 voltról, a rádió 3.3 voltról megy, ott nem jó valami. Ha a nyákon van összerakva, akkor problémázik. Ha 20 centis vezetékeken lóg minden, akkor jó. Ha nyákon van, és ráteszem az ujjamat a modulon a MISO-SCK lábakra, akkor kifogástalan. Lógó vezetékeken kifogástalan. De úgy, ahogyan lennie kellene, úgy nem. Mit tudok én az ujjammal mutatni neki? Ha már papír zsebkendő van az ujjam és a lábak között, akkor már nem megy.
Kiakaszt.

A fröccsentetten BK2425 csipp van. A másikon, amire NRF van írva, azon vélhetőleg SI24R1.

A megoldandó feladat számomra jelenleg az, hogy egy 32 bites változóba beletolok 3 ADC mérést és még 2 jelzőbitet. Ezt áttolom rádión a másik oldalra, másodpercenként cirka 1000-szer. A méréseket pedig a másik oldalról konfigurálom. Tehát a kapcsolat kétirányú. Nem igazán tudok más, kompakt dolgot erre a célra, de ha van jobb ötlet, azt meghallgatom.

Na EZT honnan lested le? Én a fröccsentett fotóját is percekig kerestem a neten, hogy meg tudjam mutatni

Hali!
Csak partszélről megjegyezném, hogy folyamatosan nem foglalhatod a rádiósávot, ha jól csalódom max 10% kitöltéssel adhatsz, ezt érdemes figyelembevenni.

Ha az aliexpressen rákeresel a "BK2425" kifejezésre, akkor ezeket a modulokat látod főképpen. Illetve van hozzájuk arduinós "patch" is, hogy megfelelően működjenek. Sajnos, nálam nem fordul.
BK2425 és társai.