Szép napot mindenkinek!
Létezik olyan megoldás egy Attiny44-nél,hogy lehessen serial monitorozni,vagy nem tudom itt mi a helyes kifejezés?
Valami olyasmit keresek ahol nem kell Arduino.

Nem tudom mit értesz monitorozás alatt, de a használt programnyelvnek megfelelően küldesz adatokat UART-on , ezt nézegetheted bármilyen terminál programmal pl. realterm Bővebben: Link

A nehézség annyi, hogy ennek nincs hw uartja. Kell hozzá egy szoftveres uart lib, és egy uart-USB illesztő amivel a PCre dugod. Szoktak olyat csinálni, hogy csak a kimenetet valósítja meg a szoftver UART, ha csak logokra vam szükség, parancsolásra nem.

Sziasztok, egy általános kérdésem lenne. Adott egy ATMEGA328P chip beforrasztva, felprogramozva, letesztelve. A program gond nélkül fut többszöri ki-bekapcsolás után is, majd egyszer csak nem indul el. A programot újra feltöltve ismét szépen működik. Mi lehet az oka?
Ha tennék be egy a RESET lábat GND-re húzó nyomógombot, az segíthet egy ilyen hiba esetén?
Köszönöm a választ!

Egy tipp: Ha mindig kb. ugyanannyi ki-bekapcsolás után történik (értsd: mindig 10-12. után, és nem olyan, hogy van amikor 5. után máskor meg a 20. után), akkor valami adat feltorlódás / túlpörgetés lehet.
Mivel a ki-bekapcsolás számít, így nem RAM, hanem a flash / eeprom területen. Vagyis lehet egy változó, ami az éppen írandó területre mutat, ami minden bekapcsoláskor növekszik eggyel, majd valamikor eléri a "túl sok" értéket. Újraprogramozáskor pedig ez a változó megkapja ismét a kezdeti értéket. Jó lenne tudni, hogy a program csinál-e ilyen jellegű műveletet. Szerintem nagy eséllyel a RESET sem segítene rajta...
Ha nagyon változó, hogy hány ki-bekapcsolást visel el, akkor más hiba lesz... (pl. tápfesz megjelenés / eltűnés sebessége, valamely periféria válaszára vár, ami nem történik meg, stb...)

Illetve, ha a ki-bekapcsolás valójában csak szoftveres készenlétbe helyezés és nem valódi tápfeszültség megszüntetés, akkor lehet a RAM használatának problémája is.

Ha valami konkrétabbat írsz a céljáról, működéséről, környezetéről, több segítséget kapsz...

(Egyébként pedig: Gratulálok, sikerült beleprogramoznod a tervezett elavulást! Már csak a darabszámot kell optimalizálnod a várható használati mód és a garanciaidő figyelembevételével. )

Sziasztok!
Bocsi előre is a képért, de így tudom a legjobban szemléltetni.
Csak egy gyorsan összedobott kapcsolás, ne nézzétek az esztétikát

A lényege:

- Bal oldal a bemeneti ág. A BETAP csatlakozón esik be a tápláló feszültség, aminek a pozitív ága egyrészt egy LDO-n keresztül megtáplálja az Arduino Mega 2560-at, illetve direktbe át van vezetve a jobb oldalon található lámpa kimenetre.
Hogy a lámpa ne világítson mindig, és a fényereje szabályozható legyen így egy IRLZ44-es Mosfettel szakítom a GND ágát a lámpa kimenetnek. A FET-et a 45-ös digitális lábról vezérlem. Ez idáig tökéletesen működik, a lámpa ki-be kapcsolható és a fényerő is szépen állítható.

- Szintén bal oldalt található egy feszültségmérő bemenet. Gyakorlatilag feszültség osztón átengedett feszültséget vizsgálok az egyik analóg bemeneten. Amit tudni kell, hogy a BETAP és a feszültség osztó ugyan azt a tápforrást használja, így a közös GND megvan. Próbálkoztam bolondbiztossá tenni, remélem ez a dióda elég lehet.

- Található rajta egy BlueTooh modul, amivel adatot küldök ki a mért feszültségről. Bluetooth modul nélkül a feszültségmérő rész viszonylag pontos volt, állandó értéket mért. Viszont ahogy bekerült a kapcsolásba a modul, a mért feszültség nagyon ugrálni kezdett. Ezért betettem a 1000µF kondit, így a jelenség megszűnt.

A Probléma: Önmagában a feszültségmérés, majd az érték kiküldése BlueTooth-on tökéletesen működött. Ahogy belekerült a PWM-es lámpavezérlés minden elromlott. A mért feszültségérték kb. 3-ára esett vissza, és a BlueTooth modul sem működik mindig, van hogy nem küld egyáltalán jelet, van hogy reset után küld, teljesen változó.

MI lehet a gond szerintetek?
Én arra gyanakszom, hogy a FET ellenállással GND-re húzásval lehet valami gebasz... Mert bár a képen nem látszik, de a Bluetooth modul RX lába előtt egy 1K/2K feszültségosztóval csökkentem az Arduino 5V-os logikai szintjét 3,3-ra. Ez önmagában működik is, csak akkor nem ha FET-et is használom. Lehet elcsúszik valahogy a GND szintje, és nem lesz meg a 3,3V a modul logikai bemenetén?

Teljesen hobbi szinten űzöm, az elektronikát csak önszorgalomból tanulom, így tuti hemzseg hibáktól a kapcsolás, de nagyon szívesen meghallgatok minden építő jellegű kritikát!

Szia, köszönöm a választ! Nem néztem, hogy hány ki-bekapcsolás idézi elő a hibát, de jó ötlet, megfigyelem.
A programban mindössze egy változó adat van, ez a bekapcsolás óta eltelt idő (micros()), ezen kívül semmi változó nincs, de amennyire tudom, ez minden bekapcsoláskor 0-ról indul.
A program annyit tesz, hogy egy léptetőmotort piszkál két irányban, mindkét véghelyzetnél van egy végállás szenzor. Tehát semmi komoly adatfeldolgozás nincs benne.

Én a VIN-GND közé is tennék némi szűrést, főleg hogy arról a tápról PWM-es vezérlésű lámpa is működik. A feszültség mérő bemenet negatív ága közösítve van valahol a mega gnd-jével? Csak mert így elég nehéz elképzelni azt, hogy valami értelmes értéket mér.

Így van. Írtam is hogy a két bemenet ugyan arról a tápról megy.
Szűrés alatt mekkora kondira gondolsz? Ugyebár az LDO után, Mega előtt van egy kis 100nF zavarszűrő fóliakondi. Pontosan hova gondolod: egyből a bemenet után, vagy a lámpa kimenet elé?

Mekkora áramok folynak, amikor be van kapcsolva a lámpa? Mekkora frekvenciával megy a PWM? Mekkora a bemenő tápfeszültség? Mennyire van elkülönítve a nagyáramú föld a digitális földtől?
Lehet, hogy a vezetékezés kialakítása (hosszú / vékony vezeték) okozza a problémát.

El tudod különíteni, hogy a BT modul vagy már az ARDUINO nem küld adatot?
Pl. a modul helyett egy soros-USB átalakítót teszel átmenetileg, azon működik a kommunikáció? Ha így tökéletes - hiba a BT modul körül van.
Vagy fordítva: a BT modul Rx-Tx lábait leválasztod, a modulnál összekötöd őket, és az ARDUINO-ra csak azt kötöd be, amelyik a parancsot küldi. Így tudsz parancsot küldeni (gondolom arra szükség lesz, hogy a lámpát vezéreld), de válaszként pontosan ugyanazt kell kapnod. Ha mindig minden jól jön vissza -> az ARDUINO-val / programjával van a gond.

Megkapja a tápfeszültséget, és adott idő múlva mozgatja a léptetőmotort egyik, majd másik végállásba és leáll? Vagy van valamilyen külső infó, amire reagál (gombnyomás / soros vonalon parancs / egyéb)?
Amikor "nem indul el", akkor semmit sem csinál, vagy valahol elakad?

Nézz meg egy LDO adatlapot. A bemenetet és a kimenetet is szokták szűrni. A szűrőtag kerámia tagját pedig minél közelebb kell tenni az LDO-hoz. Nálad csak a kimenet van szűrve, a bemeneten semmi nincs.

Én azzal kezdeném, hogy újraprogramozás helyett kiolvasnám a programot. Ugye ha nincsen lezárva - és miért lenne ha magadnak csinálod - akkor ennek semmi akadálya. És összehasonlítanám az eredeti programmal. Az avrdude-nak van ilyen verify opciója azt hiszem, csak ki kell keresgetni. Nagyon ritka, hogy elromlik a program a vezérlőben, de végülis nem kizárt úgyhogy csak azért, hogy kizárjuk meg kellene csinálni ezt az ellenőrzést.

Ha a program nem romlik el, akkor az újraprogramozás azért segít, mert tisztességes reszetet kapa csip a programozótól.

Ha a program elromlását kizártuk, akkor marad, hogy valami más állapot ragad be. Lazsi írta, hogy talán az EEprom használat rossz a programban, de ha nincs benne egyáltalán ilyen, akkor nem ez lesz a baj. Én arra tippelnék, hogy beragadós állapotba fut a program, és valójában nincsen áramtalanítva a csip és ebben benne tud ragadni. Például ha van egy jó nagy szűrőkondi a rendszerben, akkor arról egy csomó ideig még stabilan tarthatja a RAM-ot a csip és nem történik RESET amikor te azt gondolod, hogy történik.

Konkrétan nem láttam még ilyet, de elvileg olyan jelenség is lehetséges, hogy ha lassan megy el a táp, akkor egy feszültség alatt instabillá válik az MCU működése és hülyeségeket is csinálhat a csip. Itt bármi megtörténhet, akár emiatt is beragadós hibaállapotba állhat. Ez ellen úgy kell védekezni, hogy van a csipnek egy Brown-out detector nevű alrendszere, amit be kell konfigurálni (FUSE bitekkel ha jól emlékszem), hogy egy küszöbfeszültség alatt reset-elje magát.

Tehát ezeket csinálnám meg: program kiolvasás, csip VCC feszültség mérése kikapcsolt állapotban, brown-out detector bekapcsolása

Esetleg megoszthatod a programot, hátha attól okosabbak leszünk.

Ha rájöttél, hogy mi okozza írd meg, mert nagyon kísérteties, biztos mi is okulnánk belőle!

Bekapcsolás (tápfesz ráadás) után elindul az egyik végállásba, majd onnan a másikba. A két irány sebessége eltérő, de precíznek kell lennie, erre használtam a micros()-t. Külső jel a két végállás szenzor, egy nyomógomb, amivel menet közben megállítható a mozgás, valamint egy poti, amivel picit lehet korrigálni az egyik sebességet.
Az egyik kimeneten egy led van, aminek a világítási módja jelzi, hogy melyik irányba tart a motor, valamint van egy csipogó, ami a végállást, nyomógombot jelzi, de bekapcsoláskor is csippan egyet.
Amikor a hiba előjött, akkor semmi sem történt. Se csipogó, se led, se mozgás. Mintha nem is lenne szoftver a mikrovezérlőn.

Én is úgy látom, hogy egy rakás szűrőkondenzátor hiányzik az áramkörből. Ahogy fentebb is írták, a szűrőnek mennél közelebb kell lenni ahhoz, amit szűr. Talán ezt még nem írták mások, ezért mondom, hogy az IRLZ44-hez is tennék egyet, ami a lámpa kapcsoláskor nem engedné rángatni a tápfeszültséget. És persze a regulátornak kell a bemenetére és a kimenetére is kondi az adatlap ajánlása szerint.

Az Arduino TX->BluetoothRX között a feszültség osztó az ismereteim szerint rendben van, elfogadható megoldás a 3,3V konverzióra. Ha óriási volna a jelsebesség, akkor lehetne hogy jobb megoldás kell, de remélhetőleg nem használsz ilyet.

Ha teheted, szerezz be egy oszcilloszkópot, tanulságos ilyenkor ránézni, hogy hogyan ugrálnak a feszültségek! Az ember jobban elhiszi, ha látja is.

Szia!

Saját tapasztalatom írom le. Kínai Arduinoval (valószínűleg hamis ATMEGA328P) oldottam meg egy háromjáratú csap vezérlését. Rendszertelen időközönként lefagyott a program. Sok időt töltöttem szoftveres hibakereséssel mire végül rájöttem hogy a hiba forrása nem belül keresendő hanem kívül. A csap 230V-os motorja indukált zavarjeleket a kábelekben (nem csak a jelvezetéken hanem a 230V-on is) amelyek összezavarták szerencsétlen AVR-t. A megoldás érdekében bevettem mindent: árnyékolt árnyékolt kábelek, optó relék, hálózati zavarszűrők. Azóta jól működik.

Ahogy látom a fet-et vezérlő fóliasáv a bluetooh modul alatt megy el. Lehet hogy túl közel van az antennához ami miatt hibás adatok kerülnek be 1-2bittel több/kevesebb.
Ha van módod nézd meg logikai analaizátorral az adatokat, pl. ezzel a programmal Pulseview elég sok eszközt támogat többek közt ARDUINO-t is.