Adatlapot olvastad?
Bővebben: Link

Szia,
Igen olvastam. Erre írtam, hogy van olyan doksi amiben 3.3V -ot ír (ezt találtad meg te is), de találtam máshol olyat amiben meg csak annyit hogy TTL szint. Plusz a példákban simán használják az 5V -os arduinoval. Ezért kérdeztem.
Üdv.

Nekem egyértelmű Ha valahol pongyolák és csak ttl-t írnak, az nem jelent semmit.
A tápra is írtak megkötést, láttad?

Igen láttam, 3,2 - 5,5 V-ig megy.
Elemről fog menni az eszköz 4-4,5V lesz a táp, ezért is érdekes, hogy kell -e szintilleszteni.

A processzorra az van írva Vdd+0.3V minden lábra. Gondolom a panelen lévő LDO 3.3V-os. A többi része meg mese. Ha a panelen direkt van kivezetve a TX/RX láb.
Valamelyik rádiós modulra is ráírták TTL szintű, de rendes adatlap szerint 2,8V a maximum. Már a 3,3V-is sok neki. ennyit a ráírásokról.
A szintillesztéssel nem kell sokat bajlódni (szerintem) , a modul tx kimenetére soros ellenállás, az RX re meg egy feszültségosztó ellenállásból.

Sziasztok!

Én is kérnék egy kis segítséget, nem találok megoldást egy problémára.
Bármit csinálok, bootoláskor mindig felhúzza magasra az egyik lábat az Arduino.

Arduino Nano 14-es A0 lábát használom digitális kimenetként. A lábról egy 5 V - 3,3 V szintillesztőn (Bővebben: Link) keresztül csatlakozok egy Orange Pi DI-ként felkonfigurlált GPIO lábára.

Tökéletesen működik minden, csak az a gond, hogy néha muszáj újraindítani az Arduino-t WD-vel és ilyenkor bootolás közben felhúzza aktívra az A0 lábat 1,4 s időre. És ilyenkor az Orange Pi olyan jelzést kap, amit nagyon nem kellene.

A programban rögtön a setup rész elején LOW-ra állítom a lábat, de hiába.
Google keresés lehúzó 5-10k ellenállást javasolt tuti megoldásként, de ez sem segít. Tettem 4,7 k-t a GND felé a szintillsztés elé és utána is, mégis megvan a 1,4 sec magas impulzus bootoláskor.

Multiméterrel mérve a 14-es lábon egész pontosan 2,05 V-ra ugrik fel boot közben a lehúzóellenállások ellenére.

Miért nem marad lent, mit lehetne még tenni, hogy ne menjen fel magas szintre?

Bootloader nélkül is csinálja?
Másik lábbal is csinálja? Ha nem, miért nem rakod át arra?

Rakj fel másik bootloadert. De szerintem nem kellene az A0-nak magasnak lennie, semmi értelme! Üres Arduinoval is csinálja? Ha igen, akkor a bootloader a ludas. Van másik, rakd rá azt. A 2.05V inkább egy pwm jelre enged következtetni...

Most nincs kéznél ilyen megoldásom, hogy bootloader nélkül próbáljam ki.
De mindenhol azt írják, hogy lehúzó ellenállás megoldja ezt a gondot, nem kellene ehhez törölni a bootloadert meg nem is szeretném.

A Dx lábak már mind foglaltak, azért kezdtem el használni az Ax lábakat is.
Jó lenne erre a konkrét lábra megoldást találni. Már le van gyártatva a NYÁK így ezzel a lábbal, épp úton van hozzám, azon már nem változtathatok.

Ez a probléma csak most merült fel, több órás tesztelgetés során, hogy időnként lefagy az Arduino és WD-vel újra kell indítani. Ami nem is lenne gond, ha boot közben nem váltogatná az A0 láb állapotát.

Közben eszembe jutott egy áthidaló megoldás.
Egyszerűen invertáltam a jelet. Eddig úgy volt, hogy magas jelszintű impulzus leküldte suspend módba az Orange Pi-t. Átirtam mindkét oldalon a programot, hogy alapból mindig magas legyen a pin és alacsony szintű impulzus küldje el aludni a linuxot.

Gyors teszt után úgy néz ki így megfelelő lesz. Nyomkodom a reset gombot vadul az Arduino-n, de nem kap alacsony szintet az OPi ezen a lábon. Viszont minden más működni látszik rendben.

Erre mondjuk hamarabb is gondolhattam volna, végülis a hibát nem oldja meg, de megkerüli.

Amúgy szerencsétlen Arduino-t muszáj indőnként újraindítani. Egyszerre kezel I2C buszt slave-ként a hardveres lábakon, egy második I2C buszt masterként szoftveres I2C könyvtárral és még soros RS-232 vonalon is beszélget az OPi-s linux-al. Nagyon szépen működik minden, csak 3-4 óra futás után egyszer csak megfagy és nem kommunikál tovább.

Lehet, hogy valami buffer betelik, vagy valami túlcsordul, nem tudom hogy lehetne kinyomozni, nem lenne könnyű biztosan. De pofon egyszerű megoldásnak kínálkozik a watchdog bekapcsolása. Ha pár óránként újraindul, az nem okoz semmi gondot a működésben.

Köszönöm.

"Amúgy szerencsétlen Arduino-t muszáj indőnként újraindítani." - ha hibás a program, akkor ez természetes. Ha minden előfordulható hiba le van kezelve, akkor elmegy az Arduino hónapokig, évekig...

Igen, ezzel tisztában vagyok. Csak nem egy egyszerű dolog az ilyen hibakeresés és ha van igénytelenebb, de tökéletesen működő megoldás, lehet, hogy azt választom majd.
Már maga a tesztelgetés is brutálisan hosszú lehet, hiszen mindig csak több óra működés után jön elő a hiba.

Amúgy a WD nem segített. Annyira rájöttem a segítségével, hogy nem is fagy le az Arduino. Tettem rá egy heartbeat LED-et, amit a főciklusból villogtatok másodpercenként és az szépen működik tovább. Látszólag csak a szoftveres I2C kommunikáció hal meg. És mivel az innen származó adatok függvényében küld tovább egyéb adatokat a másik I2C illetve az RS232 buszokon, így kifelé sem küld már semmit, ha olvasni sem tud.

Innentől kezdve pedig lehet akár bug is a szoftveres I2C könyvtárban. Pedig ez már a második, amit használok, az első az nagyon bugos volt, használhatatlan volt.
Ez a második egész eddig tette a dolgát, csak tegnap jöttem csak rá, hogy többórás működés után bedobja a törölközőt. Amúgy nem csinál bonyolult dolgot, egy nyomógomb mátrixot kérdezgetek le folyamatosan egy PCF8574 IC-n keresztül. Ez fagy be mindig pár óra elteltével. Reset után ismét működik pár óra erejéig.

Le kellene kezelni azt a helyzetet, amikor hibás adat jön vissza, vagy nem válaszol a megszólított hardware (ezt is le lehet gyorsan tesztelni, hogy melyikre, hogyan reagál a progi). Nem annyira bonyolult rátalálni a hibára, hiszen te már rájöttél, hol kell keresni!

Sziasztok!
Egy kinetikus energiától felhúzódó karóra óraforgatója került hozzám elektronika hiba miatt. Nem túl bonyolult áramkör mert egy egy 16 lábú - felirat nélküli - IC hajt meg egy H hidat. Egy négy állású - egy áramkörös - kapcsolóval vannak kiválasztva a forgatási módok (jobbra, balra, jobb-bal szakaszos meg még valami hasonló, az ikonok alapján)
Arduino programozásban nagyon kezdő vagyok ezért a kapcsoló helyzetének lekérdezésére kérnék Tőletek javaslatokat. Én arra gondoltam, hogy négy digit lábra kötni a kapcsolót és a program időnként megnézi, hogy melyik láb van lehúzva földre. És bőven elég akár percenkénti vizsgálat is.
De bármilyen más - egyszerűbb - ötletet javaslatok örömmel fogadok. (akár más, nem Arduinos megvalósítás is jöhet)
Előre is köszi !

Muszály ennek Arduino? Astabil multivibrátor meg egy flip-flop a H híd elé akkor ide oda forog tőle a fix jobb/bal meg egy egy dióda a hídra a váltó kapcsolóra.
Ha meg elég a sima polling akkor 50 - 200 ms időnként nézzél rá a nyomógombokra.
De ha külön power gomb van akkor elég egyszer beolvasni a több állású kapcsoló állapotát.
De akár megszakítással is kezelheted.
Ha elég az egész felhúzására max 20 - 90 perc akkor egy időzítőt is rakhatsz a művelet leállításához.Mindegy melyik gombot nyomták meg , akkor is meg áll magától.

Semmi nem muszáj... Csak arra gondoltam, hogy egyszerűbb a hardvert megcsinálni egy pro minivel, meg négy tranyóval, mint multivibrátor(okat) építgetni... (de lehet, hogy rosszul gondolom) És bocs, lehet hogy rosszul fogalmaztam: nincs nyomógomb, csak egy négyállású kapcsoló van.
Igen valóban csak 1-2 órányi forgás elég utána elmehet pihenni.

Lehet Attiny-vel is egyszerűbb.
Igaz csak 8 lába van abból 2 a táp meg 2 a H híd vezérlése.
(belső órás időalap bőven elég ide)
Így is marad 2 abból az egyik 1 AD-s láb amin a fokozat kapcsoló osztja a feszt. vagy egy diódás mátrixot kapcsol a 2 bemeneten ami az üzemmódokat állítja be.

Ok, ez az ötlet már sokkal jobban tetszik - köszi !!!

Rábeszéltél, pár dolgot azért még megpróbálok.
Most majd úgy fogom tesztelni, hogy ha nem jön adat a slave-től, nem tud olvasni, akkor inicializálja újra a szoftveres buszt. És ilyekor meg is növeli a heartbeat LED villogási frekvenciáját, hogy lássam majd órák elteltével, hogy elvileg volt gond.

Kíváncsi leszek mit produkál így.

Olvasgatom, köszönöm. Közben annyi történt hogy az 5 órási relé időpontjait kicseréltem egy másik relé időpontjaival, azóta probléma nélkül működik. Nem értem mi lehetett a gond.

Bővebben: Link

Az miért lehet, hogy Arduino UNO -n és Nano-n működik az SPI móddal kapcsolt LCD, Ardunio Mega 2560-on pedig nem? Az I2C Scanner nevezetű betöltött program sem ismeri fel az LCD címét. Pedig a Wire.h -ban alapon megadott A4 és A5 csatlakozó lábakat használom. Kínai Arduino Mega-ról lenne szó. Esetleg kellene valamit állítani?
Köszönöm a segítséget!

SPI vagy I2C? Keresd meg a mega-don az I2C lábakat, mert nem a 4-es és az 5-ös lesz az!

A Megán I2C a 20-21 pin-en van.

Érdekes. De valóban így van.
Hol van ez a Wire.h - ban definiálva? Nem értem én ezt a fáljt.

SPI pinek az : 50,51,52,53
Bővebben: Mega pins

Köszi!
Én azt hittem , hogy a beépített LED-hez hasonlóan mindegyik láb azonos, de ezek szerint nem az.

Köszi !

Hello emberek!
Lenne egy projektem amin belül 5 db léptetőmotort kellene irányítanom (ilyen fajtáról lenne szó: 28BYJ-48 5V). Az lenne a kérdésem, hogy ezt egy darab arduino segítségével meg lehet-e oldani és ha igen hogyan?