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.

"Az egyik kimeneten egy led van, aminek a világítási módja jelzi, hogy melyik irányba tart a motor ..."

Első körben megfordítanám a működését. Amikor nem történik semmi akkor világítson, ha kétszínű akkor meg egyik irányt jelezze a kikapcsolt állapottal. A program első sorai kapcsolja be a LED-et.

Így tudod elindult-e a program, illetve azt is, hogy kikapcsolás után mikor áll le. Ha túl kevés idő telik el a ki-be kapcsolás között, akkor a LED még világít.

Ha bekapcsolás után is sötét marad, akkor el sem indult. Ekkor meg lehet nézni, hogy reset-re elindul-e.

Illetve ha nem újra programozod, csak kiolvasod, akkor is reset-eli az AVR és ha csak ennyitől megjavul, akkor ezen a részen lehet probléma.

A világítási módot úgy kell érteni, hogy folyamatosan világít, vagy villog, tehát mindenképpen látszik, hogy elindult-e a program. Nincs olyan programrész, amiben a led egyáltalán nem világít.
"Sajnos" azóta nem jött elő a hiba, így továbbra sem tudom, hogy mi váltotta ki.

Használtatok már ilyen klónt: LGT8F328P?
Van esetleg topikja?

Kipróbáltam BASCOMAVR alatt, amit ír a pdf-je az működik, kár, hogy nem lábkompatibilis a M328-al

Én arduino mini helyett venném. Ha jól láttam úgy, mint panel úgy lábkompatibilis.
Inkább az Arduino IDE mókolása gyanús nekem.

Az igen, de van hozzá config file. Végül is 99%-ban u.a., csak van benne 1-2 dologgal több. Ardu alól nem próbáltam, de ha modult vettél, akkor jó a bootloadere, max old loadert kell választani.

Sziasztok,
Úgy tűnik kiestem az AVR-ezésből, mert egy egyszerűnek tűnő problémán nem igazán tudok túljutni.
Adott egy javításra szoruló panel amin van két Atmega128.
Atmel JTAG ICE3-al próbálok csatlakozni hozzá avrdude-al de nem sikerül sehogy sem.
Úgy került hozzám, hogy a procikat cserélték már rajta előttem.

Amit néztem:
Táp stabil 5V.
ISP órajelet levettem 20 kHz-re.
Adtam neki órajelt egy oszcillátorról (14,7456 MHz), mert a gyári kvartz nem rezgett (lehet nem jó fuse van benne)
A programozó vonalak (MOSI, MISO, RST, SCK jó helyre (PE0, PE1, RESET, PB1)) jól vannak bekötve (van rajta gyárilag ISP csati) logikai analizátorral nézve minden bejut a prociba. A PDO lábon semmi mozgás.
Bontottam egy panelről (amit előtte megpróbáltam kiolvasni és működött) egy procit felraktam és ezt sem lehet progamozni.
Van még valami amit elfelejtettem és akadályozhatja az ISP programozást?

Szia!

A külső órajel (14,7456 MHz) abban az esetben nem lesz jó, ha ATmega128L-8 -ről van szó.
Ha netán ATmega128L-16 vagy ATmega128-16, akkor ez nem lehet a probléma forrása.

+5V megvan a VCC és AVCC lábakon is?
Van valami még a PE1-en? (esetleg zárlat)
A bontott procid milyen órajellel ment az eredeti helyén?
Az SPIEN fuse-val ki lehet kapcsolni a SPI programozást, de lehet próbálkozni JTAG-en, vagy ha minden kötél szalad a parallel mindig működik.

Köszönöm a tanácsokat, az alábbi okozta a programozhatatlanságot:
Az a helyzet, hogy kretén egy panel: az egyik Atmega egy sima kvartzról megy, majd az XTAL2 be van húzva egy bufferbe és át van húzva a másik proci XTAL2-jébe. Első körben levertem a kvartzot (ugye ha nem jók a fuse bitek akkor nem fogja hajtani) bekötöttem helyére az oszcillátort, mondván, hogy mi baj lehet. Hát egészen konkrétan csak annyi, hogy a buffer fogta a vonalat.
Szerencsére volt előtte, utána egy-egy 330 Ohmos, amiket leszedve már lehetett programozni.
Tanulság: mindig ellenőrizni kell az órajelet akkor is ha oszcillátort tettem fel.

Egy nem általad tervezett panelnél, igen ellenőrizni kell.

Kedves Fórumtársak!

Életem fő műve a melléklet szerinti enkoder, melyet a szokásos A-B csatornás, inkrementális, 3600 pulzus/fordulatú, opto-elektronikus jeladóval elfordulásiszög mérésére kívánunk használni 0-tól +-60 fokig.

"Asztalon" elfogadhatóan működik, de kikapcsoláskor, áramszünetkor meg kellene őriznie az utolsó "pulse" értéket, mert így a fenti célra nem használható.

Hogyan tároljam el a végeredményt úgy, hogy bekapcsoláskor az legyen a kezdőérték?

Köszönöm szépen!

Az EEPROM-ban