Azt nem értem, hogy 8 és 16MHz-es ardu panelekkel idézem "szinte tökéletesen megy". Mitől szinte? Ugyanez a baja?

Az Arduino alatt be tudtad állítani rendesen a sebességet? Csak azért kérdezem, mert az F_CPU 16000000-t átírva a neked megfelelő kvarcra nem jelenti a sikert! Az egész Arduinonak belül át kell vennie a frekit. Le tudod tesztelni pl. a millis()-sel, hogy másodpercenként növekszik-e, lehetőleg legalább 10percet mérj, hogy elég pontos legyen a mérésed. A másik probléma, hogy attól, hogy a millis() jól jár, ez nem garantálja, hogy a lib-ek tudják, hogy nem 16Mhz-en járnak... Ezeket is le kell ellenőrizned, a megfelelő regiszterek kiolvasásával (baud rate megfelelőre van beállítva?).
A nyákon levő forrasztógyanta maradványok hibás adatátvitelt okozhatnak, le kell mosni a nyákor rendesen.

A Minicore bootloadernek vannak verzói szinte minden kvarc frekire. A bootloader könyvtárába beilleszted ami neked kell, utána megjelenik a listában.
A SIM800-al nem könyvtárral kommunikálok, simán AT parancsokkal.
A I2C eszközök sajnos könyvtárkkal mennek. Minden könyvtárat külön át kell nézni, vagy elég a Wire.h ?

Csak azt nem értem, ha gyári ardut használok mindegy hogy 8-16 MHz, úgy fordítom és megy.
Ott honnan tudja lib, hogy milyen kvarz van a 328 mellett?

A gyári ardu mindegyikének van saját neve, amit ki kell választani fordítás előtt. Szerintem onnan tudja.

Minicore bootloadernél nincs.
Boards.txt tartalmaz infókat, de azt meg használja a fordításkor. Szóval tudni kéne neki a 7.x frekit is.

A bootloaderben beállított frekvenciáról az applikáció nem tud. Az két külön szoftver. A bootloader semmi mást nem csinál, csak frissíti az alkalmazásodat, ha küldesz neki egy újat soros porton.
Ha továbbra is Arduino-t akarsz használni, akkor a te kvarc frekvenciádhoz létre kell hozni egy új variánst. Jelenleg melyik Arduino variánsra fordítod le az applikációdat?

Szerintem megoldható úgy is ahogy szeretnéd, főleg akkor, ha saját NYÁK-ra teszel mindent, azaz csinálsz magadnak egy arduinót USB chip nélkül. Ekkor úgy is kell egy oszcillátor, akkor meg miért ne?

A gond a libeknél lehet ekkor is. Ha abban van milis(), delay, prescale, (vagy más) akkor máris át kell írni mindent benne.

A sim800L chip tudna i2c-t, de nincs kivezetése a modulokban. Na ez oldaná fel azt a elvi problémát amit te megtaláltál, ugyanis ott van SCL ami szinkronba hozza a kommunikációt. Ennek azonban más gondja lesz. Ezzel arra utalok, hogy bármit is választasz soha(!) nem lesz 100% üzembiztos. A mcu bekap a kozmikus háttérsugárzásból egy komolyabb részecskét és máris hibát generál. Kicsi a valószínűsége, de már ezzel sem lesz 100%.

Szerintem sokkal jobban jársz, ha a kommunikációban pl a cheksum-al ellenőrzöd a fogadott byte-okat és ha hibás lekéred megint. Ennél jobb megoldás nincs. Arra utalok, hogy a hibákra minden esetben fel kell készíteni a programokat. Ez a fejlesztés legnagyobb és egyben legunalmasabb része is sajnos.

Nem jártam utána a sim800l setén, hogy ezek a hibajavítások miként mennek, de pl a CD/DVD-n sem 8 bit egy adatcsomag, hanem 10 bit, vagy még több. Redundanciát visznek bele, hogy az eredeti adatot vissza lehessen állítani sérülés esetén. Szerintem a SIM800l is képes ilyesmire, mert a fejlesztők is tisztában vannak a korlátokkal.

A frekvencia állítássaal több gondot veszel a nyakadba szerintem. Amit küldtél frekvencia/baud táblázatot abban szerepel ugyan 0%, de az is csak annyit tesz, hogy az általuk vizsgált elképzelhető minimumnál kisebb. Az sem valódi 0.

Sziasztok!
Hogyan oldanátok meg egy olyan programot, aminek azt kellene tudnia, hogy kb 2 másodpercenként érkező 0VDC impulzusok idejére meghúz egy relét, amit az utolsó jeltől számított másfél másodperc múlva el is enged?
Köszi.

A 0VDC impulzus az mi? Digitális vagy analóg jel?

Analóg. Testre kapcsolgatás.

Aham. Megírtam digitre, valahogy így csinálnám ha digit lenne:


Nem tesztelt, és nem is biztos hogy hibátlan, de az elv kb. ez.
Analóggal az a szívás, hogy az ADC mintavétel időbe telik, és azt is célszerű átlagolgatni, aztán kell egy treshhold érték ami alatt 0-nak veszed, stb.
Én lehet tennék mellé egy 5V-ról hajtott komparátort, aminek a - lába lenne mondjuk a treshold érték (mondjuk 0,2 V vagy ilyesmi), a + lába a figyelt jel, aztán abból kijönne egy egészen használható digitális jel.

A PulseIn nem lehet megoldás?

Szerintem nem. Az egy low vagy high "impulzus" hosszát adja meg. Mire használnád ezt az értéket?

De amúgy amit írtam az is rossz
Meg a feladatleírás is kacifánt. Az alábbi kód digit jelre a következőt csinálja:

Az elejét nézve amikor jön a jel akkor behúzza a relét, ha elmegy akkor nem. (Szóval van egy minimális elvárt idő, amíg 0 a jel, nagyon rövid impulzusoknál a relé nem húz be!)
Aztán az utolsó ilyen 0 impulzus után (önkényesen megválasztva: ha 2,5 másodpercig nem jön ilyen impulzus) behúz 1x 1,5 másodpercre

A legfőbb "kacifánt" az, hogy még van 2 analogwrite is, amit meg kell szakítson egy külön-külön egy-egy 0VDC a bemeneten...



ezzel az a gond, hogyha hosszabb a 0VDC, mint 1500ms, akkor egy pillanatra elenged a relé...

Valószínűleg pontosan azt csinálja, amit kérsz tőle, valahol az 1500 millis lekapcsolásnál kellene még valami mást is vizsgálnod. De ezt a kódot max. te látod át, én tuti nem.

Szia!

Szerintem hasonló a gond mint a prell. Azt tenném, hogy az első if-ben ahol beolvasol analóg értéket, ott egy külső függvényt hívnék meg aminek a típusa boolean. A függvénybem egy loopban újra olvasgatok analóg értékeket pl. 10x. (delay10, vagy amit szeretnél a loopon belül) Ebben a loop-ban is (vagy for, még jobb) olvasnék adatot. Ha az érték kisebb mint 100mv akkor egy számláló++. A függvény végén egy feltétel, hogy ha ez a szám pl 6-nál nagyobb, akkor tutira behúzták földre. A függvény értéke meg true. (Profi szint: A függvény bemenő paraméterként megkaphatná, hogy a delay mennyi legyen, illetve megkaphatná, hogy mennyit mérjen és mennyitől fogadod el igaznak (10ből hat, vagy 10ből 8 stb. ), valamint mekkora a legnagyobb feszültség érték, amit még nullának veszel)

A fő programban, ahol elsőként olvastál be analóg értéket, abba beágyazva még egy feltétel. Ha ez a külső függvény true, akkor a megfelelő láb magas, majd hívjon meg egy másik függvényt ami vár addig amíg kell, a fő programban ezután a megfelelő láb alacsony. (várakozó függvény is saját, külső paraméterezhetően) Onnantól megy a program tovább, de ezt neked kell látnod.

Leírni több, mint leprogramozni, nem is értem miért nem csináltam meg...

És az analogwrite? Az miatt nem lehet várni.

Ok, benéztem! bocsánat!

Nem értem pontosan mit szeretnél, de szerintem az időmérés a hibás. A loop-ban ki kell szedni a current milis-eket, nem ott kell értéket adni nekik rögtön.


eltelt_ido+=millis()-eltelt_ido; //itt azt akarnám megoldani, hogy a valós eltelt idővel növelje, de a millis() túlcsordul!!!! Erre figyelni kell!

if (analogRead(A1) < 100)
{
analogWrite(led_pin6, 0);
digitalWrite(rele6, HIGH);
Serial.println("rele6: magas");
state6 = 1;
eltelt_ido=0; //Mert addig amíg nyomja nem kell, hogy elinduljon a számláló
}

//Elvileg ez ok, mert az eltelt idő ha nagyobb lesz mint 1500ms, akkor fog ez lefutni

if (( eltelt_ido >= period) && (state6 == 1)) {
digitalWrite(rele6, LOW);
state6 = 0;
Serial.println("rele6: alacsony");
}

A lényeg, hogy amikor megnyomja a gombot akkor kezd el számolni. Ha nem nyomja meg megint, akkor a számláló nő és mikor eléri a maximum értéket lefut ami alacsonyra húzza. Az eltelt idő számláló meg növekszik folyton, ezért az a második if ami lehúzza megint lefut.

Na ezzel az lesz a gond, hogy az eltelt_ido változó sem növekedhet örökké, túl fog csordulni. Ekkor a második if le fog futni, mert a változó 0 lesz, ha minden igaz. Szóval ez nem jó még.

A millis is túlcsordul, ezért az eltelt_ido+=millis-eltelt_ido sem jó teljesen. Ezt a hibát is le kell kezelni.

Igen, az időmérést piszkáltam meg, és úgy működik, ahogy szeretném.

Tehát a módosítással új értéket kap a startmillis, amíg 0VDC van a bemeneten.

A millis túlcsordulása miatt nem aggódok, mert pár óránként egy másik eszköz áramtalanítja a boardot

Ez lett volna a következő amit javasoltam volna, mert a kinullázás a lényeg, nem kell másik változó. Azt csak azért gondoltam bele, mert jobban átlátható a kód.

Király!

Ha így töltöm (fordítom) le - kép -, nem lehet elméltileg hiba. A kontollernek mindegy mekkora kvarc alapján jár, mindig ugyanaz a belső sebesség.
Érdekes amúgy az I2C hiba is, mivel ott a kontroller "adja" a SCL lábon a sebességet, a slave elemek ahhoz alkalmazodnak. Mindegy nekik, hogy az 100 kHz vagy 92.35 Khz-en mennek.
Szóval nem értem..

Ez nem teljesen igaz. Az ATMega328-ban csak néhány osztó van, szorozni nem tud. Tehát alapvetően a kvarc sebességével megy a CPU is, ha nincs osztás. Ha van osztás, akkor az lehet /2, /4, stb, tehát az osztás sem lehet tetszőlegesen részletes.

Egyébként az „arduino1.8.5”-ös ide híresen televan hibákkal!
Amikre itt is már sokan panaszkodtak.

Ezért nem is használjuk!

Sziasztok.

A kis kertészetembe szeretnék összereakni egy autómata öntöző rendszert.
Arra gondoltam, hogy egy uno-hoz kötött mérleg szenzort használnék a közeg nedvesség megállapítására mivel a növényeim egy rekeszben vannak (talaj nélküli termesztés) És az uno kapcsolná az öntöző szivattyút egy relén keresztül.
Több kérdés is felmerült bennem,
1, Megoldható lenne-e a rendszer wifi modulokkal (találtam wifi-s relét de szerintem azt csak telefonnal lehet vezérelni)
2, Két arduino tudna egymással kommunikálni mert akkor egyiken csak egy relé lenne és az kapcsolná a szivattyút.

Köszönöm szépen ha valaki segít kicsit elmélyednem ebben az érdekes világban

Szia!

Mindegyik megoldható, de miért gondolsz két Arduinót?

1. wifi: simán használhat esp8266/esp32 modulokat "wifi adapterként" az arduino-hoz, csak szintillesztő kell hozzá. De: ezek erősebb mikrokontrollerek, mint maga az arduino, szóval...
2. nyilván tud, nagyobb távolságokra soros porton (akár softserial) vagy rádión (433 mhz, rola, wifi, stb), rövidebb távon i2c/spi buszon keresztül is.

Azért gondoltam kettőt mert az egyik mérte volna közeg súlyát a másik pedig kapcsolta volna a szivattyút és a kettő között lett volna wifi kapcsolat. De mint tbarath-tól megtudtam azért a két eszköz közötti wifi-s kommunikációt nem egyszerű dolog megoldani. Így inkább oda kábelezek 10-15m-ről van csak szó

Köszönöm a választ, érdekes lesz számomra az építés és jó az a tudat, hogy ha elakadok van hova fordulnom.