"Mit kellene még tudnom?"
Azt, hogy az I2C egy busz, amit arra találtak ki, hogy több perifériát is rá lehessen kötni. Ha több kijelzőt használsz (max. 8, mivel feltételezem, hogy PCF8574-es expanderrel szerelt LCD illesztő panelt használsz), akkor csak a meghajtó panelen kell átállítani a PCF8574 címét. De ha ennél többet, akkor ugyanez a típus más gyártónál másik bázis címen van, ezért az +8-at jelent, tehát 16 kijelzőig (ill. PCF8574-ig) bővítheted. Ha ennél több expandert szeretnél használni, akkor van értelme a másik I2C busz használatának.

Abban az esetben is célszerűnek tartom, ha mind a 8 ADC le van foglalva, mint például jelen esetben.

Nem működött. Pedig szerintem simán tudnia kellene lemérni ennek a kódnak 250us időtartamot. Az az érdekes, hogy a mért 500 értékből 2-3 bomlik fel 250us és 750us értékre, tehát működőképes a dolog, az maradék majd 500 az 1000us körüli értéket adja.

Nem lehet hogy összemérhető a mintavétel ideje a mért jellel? Hátha interferál, vagy aliasing jelenség lép fel. Nincs több ötletem.

Miután a mintavétel megszakításban zajlik, ezért mintavételi idő nincs. Csak arra tudok gondolni, hogy a megszakítás kérés és a megszakításban lévő utasítás végrehajtásához több idő szükséges, mint amilyen hosszú az afatsorban lévő legrövidebb időtartam (~250us). Ami azért érdekes, mert kb. 0,5us alatt hajt végre egy utasítást és nincs 500 utasítás a megszakításban, hogy kifussak a 250ud-ból, illetve ~350us időtartamot simán mér. A megszakítás kérés és futtatás közt nem tudom mennyi idő telik el.
Végülis mindegy. A jelet számítógéppel ki tudom rajzolni és leszámolom manuálisan a biteket.

Jogos. Részemről a távgyógyítás ennyit tudott felmutatni.

Előre jelezném hogy nem vagyok egy arduino guru, lehet csak ezért nem értek 1-2 sort ...


static unsigned long lastTime = 0;

Létre hozzod a lastTime változót, és 0-ra állítod, nem nullázza le mindig amikor belép a függvénybe?

const long time = micros();
const unsigned int duration = time - lastTime

Hogy lehet konstans a time változó?

Nem, mert statikus. A függvény első futásakor megkapja a kezdőértéket, onnantól kezdve pedig megtartja, bármit is írsz bele. Két függvényhívás között is.

Úgy, hogy azt meg minden híváskor létrehozza.

Sziasztok!
Kezdő vagyok, nyomógombot szeretnék szoftveresen megszakításban prellmentesíteni. Az a problémám, hogy a prellezés miatt a megszakításban folyó műveletet is megszakítja majd ismét...
A noInterrupts() / Interrupts() függvény úgy tűnik hogy nem működik a megszakítási alprogramban.

Egy egyszerű példa:

volatile int state = LOW;
void setup() {
pinMode(11, OUTPUT);
pinMode(3, INPUT_PULLUP);
attachInterrupt(1, blink,CHANGE);

}

void loop() {
delay(10000);

}
void blink() {
noInterrupts();
state = !state;
digitalWrite(11, state);
delay(100);
interrupts();
}

Lehet, hogy ezek a fv-ek nem működnek megszakításban. Szerintem cli() és sei().
De lehet, hogy az a baj, hogy működnek, mert a delay()-nek szüksége van timer megszakításokra.
És egy tizedmásodpercig soha ne akarj megszakításban lenni. Nem csak várni, úgy egyáltalán lenni. A megszakítás _nagyon_ nem erre való.

A megszakításban csak flaget állíts, és mentsd el az esmény időbélyegét. A main loop fogja kivárni a pergésmentesítési időt.

Talán a parsic nevű programból lestem, a program fut a maga útján, úgy szervezve, hogy átlagban egy konstans idő alatt érjen körbe. (loop) ha a köröket számolom, abból a kevésbé kritikus időzítések kijönnek, nem kell millis/delay. Ha hosszabb idő kell akkor 10-100 kör, ha rövidebb akkor a következő alkalom már jó. ( ha egyszerű a program, a végére illesztek egy 20-100ms -os delayt ). A prell mentesítést így automatikusan biztosított, minden körben kiolvasom a gombokat, ha nem egyezik az előző állapottal, megnyomták vagy felengedték ( jelzőbit beállítása történik) . A "köridő" pedig biztosítja a prellmentesítést. így senkire nem kell várni, akárhány gombot tudok kezelni emberi léptékkel szinte várakozásmentesen. ( gombnyomás kezelésnél nem a port állapotát figyelem, hanem a jelzőbiteket. Ami hátrány, a programot úgy kell szervezni,hogy soha nem várhat semmire, amire várni kell, azt minden körben ellenőrizni kell, de nem akadhat le.
Aztán persze programfüggő, két gombbért, egyszerű működésnél macerásabb a bonyolultabb programszervezéssel kínlódni, ott marad a delay.

Nyomógomb(ok) lekérdezését és feldolgozását sosem szoktam bemenet változás interrupt-ra tenni, hanem timer interruptba, vagy timer interrupt (ez akár lehet az 1ms-es rendszeróra is) által időzített módon a főprogramhurokba rakom. 30..40msec sűrűséggel lekérdezve nem fog a pergés gondot okozni, ráadásul lehet detektálni a rövid lenyomást, a hosszú lenyomást, a dupla klikket stb.

Plusz info: A digitalWrite önmagában egy csomó idő. Érdemes kerülni a használatát, és közvetlenül a port regisztereket írni.

Csak még 1-2 adalék, ha nem bántok meg senkit: Általában kijön egy 7-14-500Hz-es INT (500Hz-est az enkóderek esetén érdemes használni vagy a következő esetek egyikében), tehát Proba kollega megoldásához hasonló; lesz egy byte, ami INTben a bemenet állapotától függően nő vagy csökken (határok betartva, 0-255 fék vagy más). Ha 1 az értéke, akkor a gombot elengedték bit billentése, ha 254, akkor megnyomták bit billentése (iránytól függően csak egyszer következik be, ha figyeljük, hogy csak az ellenkező állapot esetén maceráljuk). Másik, a SW shiftregiszteres megoldás, hogy a gomb állapota bejut a byte-ba (carry-n vagy byte.0 úton), rotálás, ha 255 a byte, akkor megnyomták, ha 0 akkor elengedték (vagy fordítva, kinek-hogy). Ez a módszer jó, pl. optoérzékelős "átrepült a légy" kivédésére. (a HW PLC input IC-k is ezt használják, mert olcsó)

Köszönöm a sok hasznos választ, van bőven még mit tanulnom
Közben bogarásztam a megszakításokkal kapcsolatban, és megvan hogy miért nem működött az eredeti elképzelésem. Mivel az AVR Timer számlálója megszakítás során léptetődik és megszakítást nem lehet megszakítani, emiatt a delay() utasítás nem működhet egy megszakításon belül. Állítólag a fordító ki is hagyja.
Tudom, hogy nem "illik" egy megszakítában húzni az időt, csak próbaképp tettem bele egy for ciklust, és így majdnem jól működik. Nincs prell jelenség, de amikor megnyomom a gombot, a led állapota átvált majd a ciklus leteltével -a gomb állapotától függetlenül- visszavált. Ennek okát még nem látom...

Leírom, hátha valaki még hasznát veszi. Ezzel a könyvtárral és egy átírt wire könyvtárral tökéletesen működik a TWI1-en is az LCD. A könyvtárban csupán twi.h fájlban a TWI0 regisztereit kell átírni a TWI1 regisztereire.

Helló!

Érdekes a gondod, kicsit elgondolkodtam rajta. A serial is bejátszhat szerintem, de nem tudom pontosan. Azt mondod, hogy néha jó, néha nem. Az interrupt change eseményen van. Vagy az állomás nem ad olyan hosszú váltási időt, amit a mikrokontroller le tud kezelni, vagy tényleg van valami szórt kapacitás, ami nem engedi leesni a feszt, épp a láb vizsgálata körüli időpillanatban.

Vagy csak mert nincsenek szinkronban, nem egy órajelről megy a két dolog, és néha beüt egy ilyen állás. Próbáld meg az Arduino órajelét leosztani, nézd meg mennyit téveszt és az arányaiban tartja-e ezt a mostani állást. Ilyesmi is közbeléphet szerintem. Nem lehet szinkronban hajtani a kettő egységet?

Még valami. Baud 9600, ha jól láttam, és ha jól sejtem 16MHz az Arduino órajele. Ez hibás lesz mindenképpen néha-néha:

Bővebben: Link

Ezt egy itteni fórumtárs ajánlotta, de igen-igen hasznos. A másik, hogy a serial kommunikáció nem üt bele az interrupt-ba? Esetleg nem kell leválasztani az interruptot, mikor serial print esemény van?

Hello! A 0,2% hiba nem okozhat gondot egy soros adatátvitelben..

Sziasztok!
Egy kis segítséget szeretnék kérni! Van egy ESP32 Wroom panelem.Az a problémám hogy amint tápot kap a panel aktívak lesznek a kimenetek, majd gondolom ahogy lefut a port konfigurálós setup rész működik rendesen. Megoldható valahogy hogy, a program futása elött ne legyenek aktívak a kimenetek egy pillanata sem?
Tanácsokat előre is köszönöm!

Nem. Sajnos a boot loader-je jól megrángatja a kimeneteket, még a saját programod indulása előtt. Ha lényeges, akkor olyan kimenetre kell tenni, amit nem cibál meg. Infó itt: Bővebben: Link

Igen, ez lehet a megoldás, mert elkezdtem egyesével nézegetni a kimeneteket és nem mindet aktíválja induláskor. Köszönöm a segítséget!

0,3,6-11-es kivezetéseket lehetőleg ne használd. A többi elvileg nagyimpedanciás állapotban van, kivéve az 5,14,15-ös kivezetéseket, amíg más utasítást nem kap (ez az előbb linkelt leírásból is kiderül).
Sajnos nem derül ki abból, amit írtál, hogy milyen környezetben használod, ezért csak tippelek, hogy ha az ESP kimenetét egy logikai bemenetre csatlakoztatod, akkor nem az ESP-ben van a hiba, hanem a "levegőben lógó" logikai bemenet magas szintűnek tekintendő.

Csak a pontosság kedvéért...
"a levegőben lógó logikai bemenet magas szintűnek tekintendő" ha TTL áramkörről van szó...
CMOS áramköröknél a lógósok bármilyen szinten lehetnek, lebeghetnek, sőt emiatt a kimenet oszcillálhat is.
itt is volt szó róla...

Én a kalimpálós kivezetéseket úgy oldanám meg, hogy rákötözném őket egy buszmeghajtóra (pl 74245), és azzal a lábbal aktiválnám ami nem kalimpál. Feltéve hogy van legalább egy ilyen láb. Vagy akár egy egyszerű reset áramkör is indíthatná a buszmeghajtót olyan késleltetésre állítva, ami alatt már biztosan magához tért a vezérlő. Csak ez egy plusz ic, meg a resethez is kell legalább egy kondi+ellenállás. Van jobb ötlete valakinek?

Sziasztok!

Ma játszottam egy kicsit LDR-el és minden szép és jó lenne a kódba csak épp forditva csinálja a világítás szabályzását. Azt csinálja, hogy ha sok a fény az ldr-en akkor a led-re is sok fényt ad de én pont fordítva gondoltam, ha kevés a fény az ldr-en a led-re akkor adja rá a maximumot (forditott logikát kell valahol alkalmazni?)

Hmm. Kipróbáltam de csak egy alig észrevehető fényerő változás van (talán 5%)

Mérd meg, vagy írasd ki hogy az LDR-en mekkora érték / feszültség van a maximális és minimális fényváltoztatás között.