google://arduino short long button example
Erre ad 4,5 milliót kb., sanszosan az elején találsz megfelelőt.

Yes. Meglesz az

Ó, köszi! Nem lapoztam vissza eléggé.
Kipróbáltam, de nem oldotta meg a hibát, aztán rájöttem, hogy rosszul deklaráltam az egyik változót, ami hasonló problémát okozott, úgyhogy végülis sikerült megoldani

Használt már valaki külső watchdog áramkört? Egy stabilan, a gyakorlatban működő rajzra lenne szükségem egy 5V-os Pro Mini alaplaphoz. Pl. az 555-ös IC-vel megvalósított áramkörökkel az a probléma, hogy túl nagy a maradék feszültsége a kimeneti fokozatnak, ezért nem reseteli a kontrollert. Váltó kapcsolón keresztül működik, de ha az IC kimenete vált, akkor már nem.
(az avr/wdt.h könyvtár sem úgy működik, ahogy szeretném, szóval az sem jó, 2 alaplappal is próbáltam)

TLC555 ?

Jó ötlet, csak olyanom nincs most itthon
Holnap tudnám kipróbálni.

Hello! Kiegészíted két tranyóval és már kész is vagy..

Sziasztok.
Nem tudom, hogy más is találkozott már-e ilyen problémával, de remélem:
Arduino nanot haszálok, ami egy mini pro-val kommunikál, ami ismét egy mini pro-val kommunikál, tehát egymás után megy az infó, először a nano, aztán mini pro, majd mini pro.
Leprogramoztam egy egyszerűbb, egyirányú kommunikációt, szinkronizációs ponttal. Azt vettem, észre, hogy az időzítések nagyon nem pontosak. 3db mini pro-t próbáltam ki, azonos programmal, azonos a késés (a hardware is azonos maradt, nem csak a program!).
Már beraktam cli es sei-t is a kritikus részekre, delayMicroseconds() függvényt használok. Néha pontos, néha nem... Interrupt az van, mert mind a 6 kimeneten PWM-mel van hajtva folyamatosan, de nem változtatom az értéket. Ennyit bekavarna a 6db PWM? Felrakok egy képet, Hantek 6022BE-vel készítettem, látható rajta, hogy a sárga forma lenne az adat (100uS-ig magas vagy 100uS-ig alacsony, ilyen egyszerü, a zöld pedig, hogy mikor mérem a jelet. Ennek ugye a sárga 100uS közepén kellene lennie, csak a sárga el van csúszva... A kép közepén látható, hogy az adat 2db "magas" lenne, 200uS-ig kellene hogy tartson, mégis 225uS-ig tart. A két db. bit elküldése között van olyan idő, amikor a megszakítás dolgozni tud, ezért gondolom, hogy az egy db. 100uS-os bit pontos, viszont a több azonos bit egymás után pontatlan. Az interruptot nem tilthatom le az egész adás alatt... Megpróbálom még, hogy nem fix 100uS-ot várok, hogy folyamatosan lekérem a micros() aktuális értékét, és ez alapján tartok szünetet, így az interrupt nyugodtan futhat a háttérben.
Kipróbáltam közben ezt a megoldást is, és így sem stimmel valami.

Pl. a második scope ábrán: a zöld lefutó éle után a sárga vár 50uS-ot, majd ismét vár 50uS-ot, és ekkor vesz mintát. A képen látszik, hogy ez az egyszerü feladat sem sikerült, sőt, a mintavételek között sem 100uS van.
Megnéztem a mini pro nyákját, nincs rajta kondi a kvarccal/rezonátorral párhuzamosan. Mindhárom mini pro nyák ugyanígy viselkedik. A tápfeszültség 4.95V. Ennyire pontatlan lenne a 16MHz-es rezonátor, vagy a PWM megszakítása zavar be folyamatosan? Mire tippeltek? Köszi.

A Timer0 használod? Mert erről megy a millis, micros is.

Kód nélkül nehéz kitalálni, hogy minek kellene történni. A mikroszekundum ugye 1 milliomod másodperc, ezalatt 16 órajel fut le, egy ASM utasítás 1-3 órajel átlagban. Tehát a 25 uS késés az utasításban mérve nem sok, kb 70 ASM utasítás. Ha az Arduino API-t használod és nem direkt port írást, akkor akár abból is adódhat ennyi eltérés, ha jól emlékszem olvasmányélményeimből 100 órajel nagyságrend egy port írás az Arduino API-ból.

Ha simán az interrupt tolná el az időzítést, akkor azt azért nehéz volna "elkapni" a szkópon. Persze a periódusidőkből ki kell számolni a valószínűségeket, van olyan is amikor sokszor előjön, hogy bezavar az interrupt.

"PWM megszakítása" - hogyan van felprogramozva a PWM? Ha jól emlékszem 3 timer van az AMTEGA328-on, 1 timer 2 hardveres PWM-et tud csinálni, de a Timer0 fixen az időszámlálásra van felprogramozva, és ezért ez "félszoft" PWM-et tud Arduino alatt, ami interruptból billegteti a kimenetet. Jól emlékszem?

A kommunikációval mit akarsz megvalósítani? Biztos, hogy szükség van ekkora jelsebességre, hogy ilyen rövid jeleket kell használni? Nem tudsz valami hardveres perifériát használni a kommunikációra?

Azt tippelném, hogy ha Arduino lib nélkül írnál meg egy ilyen programot, akkor az idő számlálás és PWM kimenet interruptja néhány 10 órajel alatt lefutna, az ebből adódó jitter 5uS-on belül maradna, talán 1-2uS-ig le lehetne szorítani.

Hogy ne adódjanak össze a hibák, érdemes nem a kicsi szakaszokat külön mérni, hanem egy 0-hoz képest beidőzíteni a lépéseket. Tehát pszeudó kóddal:


Helyett:

A harmadik mintavétel időzítése 1 jitternyivel fog eltérni az ideálistól és nem kettővel, tehát nem adódnak össze a hibák.

A saját kommunikációs protokollt pedig érdemes úgy megtervezni, hogy mennél gyakrabban legyenek élek benne, akkor az időmérések hibái szintén nem adódnak össze. Például minden bit egy 0->1 vagy 1->0 él, mindegy, hogy melyik irány, csak a jel hossza számít. És olyan jelhosszt kell választani, ami egyértelműen felismerhető az érintett programokból.

Az IT kiszolgálás idejét úgy szoktam mérni, hogy a főprogramba egy pint folyamatosan röcögtető kódot írok, és akkor a szkópon ameddig leáll a röcögés, annyi idő volt az interrupt futása. (Ha magad írod az interruptot, akkor az is kiadhatja a mérőjelet, de akkor a belépés és kilépés idejét nem méred bele.) Ezzel tudod becsülni, hogy mennyi lesz az IT futásából adódód jitter, ha éppen a legrosszabkor üt be egy interrupt.

Az Arduino saját pwm könyvtárát használom, és mindhárom timer használatban van.

Asch: 16MHz-nél 0.0625uS-ként van egy órajel, én meg 50-100uS-ként szerettem volna pontosan időzíteni. Az interrupt közbelépését azért lehet látni a szkópon, mert a delayMicroseconds(50) függvény 50uS-ig vár, ha közben az interrupt megszakítja, akkor annyival többet. Természetesen direkt port írást használtam mindehol.
A timer0 az tuti hogy szoftveres, egy periódus alatt többször is lefut (millis miatt, plusz a pwm).
A feladat az lett volna, hogy 17db LED szalag fényerejét külön-külön tudjam állítani. De ahogy látom, ez nem fog menni, kivéve, ha átállok hardware-es kommunikációra. Közben találtam egy 16 csatornás PWM IC-t (PCA9648), az i2C-n kommunikál, ezzel kiváltok 3db Arduino mini pro-t.
A tippeket köszönöm, a jövőben hasznos lesz.

Mekkora felbontású PWM kell? Mert led szalaghoz nem kell nagyon nagy pwm frekvencia, akár szoftveres pwm-el is megoldható - csak legyen elég I/O láb hozzá.

Nézz bele, hogy hogy működik belül a delayMicroseconds, szerintem nem kellene az interruptnak hozzáadni a várakozáshoz (lásd: "As of Arduino 0018, delayMicroseconds() no longer disables interrupts." innen: https://www.arduino.cc/reference/en/language/functions/time/delaymi...conds/ de nem néztem most meg a kódját). De áríthatod a micros() kérdezgetésére, az egy kicsit többet fog hibázni egy ponton, de nem adódik össze a hibája, ha úgy csinálod ahogy fentebb javasoltam.

Ahogy Skori írta, lámpához elegendő frekvenciájú és pontosságú PWM-et egyetlen szoftveres interruptból is előállíthatsz annyit, ahány szabad lábad van. Egyszer csináltam még olyat is, ami minden PWM-et szándékosan külön fázisban indított el, hogy ne legyen a pillanatnyi áramfelvétel túl nagy. A kommunikáció is simán elfér mellé, pláne ha UART vagy egyéb hardveres dolog.

Igazatok van, simán elég lenne 8bit is 17csatornával, egy db. mini pro le tudná kezelni az egészet. Ha leprogramoznám, akkor ugyanott lennék, mintha megvenném a fent említett 16csatornás PWM IC-t. Megpróbálom beszerezni, találtam "használtan", így hamarabb ideér.
Köszi!

Szerintem próbáld ki a BluePill-t. Az arduinokhoz képest baromi gyors, és nem vészes az ára sem. Annak idején kísérletképpen 1µs-os megszakítást is kipróbáltam, és még jónéhány művelet is könnyedén belefért a megszakításba. 72MHz -> 14nanosec órajel - és a legtöbb utasítás belefér egy órajelbe, 32 biten is... Ezzel egy sokcsatornás, szoftveres pwm is könnyedén megoldható lenne.

Ebből meg sok a hamis klón!

Arduino alapokon is lehet menni bőven felfelé!! Rengeteg féle és gyármányú µC beilleszthető Arduino környezet alá!
Ha kicsi és gyors kell pl: seeeduino xiao

Szerintem érdemes még megnézni a raspberry pico-t is. Itthon is elfogadható áron és gyorsan beszerezhető, két magos ARM-M0+, ha jól emlékszem 133MHz, arduino alatt is programozható. Beszerzésnél legalább 2 darabot érdemes venni belőle, így az egyikből lehet debuggert csinálni. Ekkor vscode alatt lehetőség van debug funkciókat is igénybe venni (ott is lehet a pico-ra arduino alapú kódot csinálni). Van 2db PIO nevű perifériája, amit kimondottan nagy sebességű egyedi perifériák megvalósítására találtak ki.

A "hamis klónok" is működnek.

...de nem mindig kielégítően!

Például? Mi nem megy jól a klónokon?

Néha már programozni sem lehet őket. De olyan is van, hogy jobban bírják az overclockot. Vagy 103 helyett 101 van benne, és vacakol az USB. Egy csomó ilyet sorolhatnék. És pont ez a baj, teljesen kiszámíthatatlan, mit küldenek.

Köszi, valóban az USB problémával én is találkoztam, de ST-Linkkel eddig még mindegyiket tudtam programozni. Amit még találtam, az a belső hőmérő hiánya - de ez nem tűnt jelentős problémának.

Az overclockot próbáltam, a kínai cuccot 72MHz-ről 104 MHz-ig tudtam húzni, felette lefagyott, a gyári 101-es (amin amúgy minden megy - az USB is) 128MHz-en is vígan ment, feljebb nem próbáltam, mert ahhoz már kvarcot is kellene cserélnem, de lehet, hogy majd kipróbálom

Amúgy tényleg érdekelne a többi is (amit még sorolhatnál) már csak azért is, hogy tudjam mire számítsak. A hibák ismerete könnyebbé teszi behatárolni, hogy mire jó, és mire nem célszerű használni, illetve mi az amire csak korlátozottan alkalmas.
A kínai cucc annyival olcsóbb, mint az eredeti, hogy sok esetben megfontolandó lehet, hogy mégiscsak megéri... Nyilván a feladat súlyától is függ a dolog, de pl. egy LED szalagokat vezérlő program nem tűnik különösebben kritikus feladatnak.

Szerintem az USB azért vacakol, mert valamiért a mai napig előfordulnak 10k-s felhúzó(D+) ellenállásokkal szerelt panelek, miközben oda inkább 1,5k körüli kellene...

Én elég sok darabot rendeltem már, különböző helyekről..., eddig mindig ST-s IC volt rajtuk(legalábbis felirat, ID szerint), ahogy rendeltem, és mindegyik teljesen jól tette a dolgát...

Én is felhasználtam már vagy 2 tucat Arduinot. Egyikkel sem volt különösebb gond.
Ezek is sok helyröl jöttek.

Ellenállást minidg ellenőrzöm, cserélem. Sajnos néha simán 101-essel küldik. Vagy átírják 103-ra.
Nekem néha nem is ST a felirat. És némelyik nem teszi a dolgát.

Ha kiszámítható lenne, akkor igen. De ki rendel valamiből rögtön 20-40 darabot? Ki tudja, hogy jó lesz-e. Azt próbáltam, hogy rendeltem kettőt, jó volt. Pár napon belül rendeltem ugyanonnan két tucattal. Na, azok már nem is ST IC-vel jöttek...

Annak idején futottam ezzel pár kört. A kínából rendelt BluePill modulok jelentős hányadán nem megy az USB, és nagy részüknél nem a felhúzó ellenállás a probléma (amelyiken jó, az többnyire a 10k-s felhúzóval is jó). Azt tapasztaltam, hogy egyszerűen azok I/O lábak rosszak amin az USB van, azaz sima portlábként sem működnek (amelyiken meg jó az USB az sima I/O lábként is jól működik).

Összedobtam egy egyszerű tesztert, amin minden elérhető I/O lábon van egy led bekötve, és egy egyszerű futófény programmal azonnal kiszúrható, hogy minden láb működik. Arra (is) használtam, hogy megnézzem sikerült-e a proci beforrasztása a saját paneljeimre. Illetve gyári panelre is (amin véletlenül kinyírtam a procit) került eredeti processzor - így könnyen össze lehet hasonlítani a klónnal.

Az USB hibába több esetben belefutottam, ezek mindegyikén a hőmérő is hiányzott (már azt hittem nem jó a programom - de eredeti procival persze jó ), és elvétve találkoztam olyannal is amin az A/D konverter rosszalkodott. Más hibába viszont még nem futottam bele a klónra épülő BluePill panelekkel.

Engem az érdekelne, hogy azokon a hibákon kívül amelyek fel lettek sorolva, mik azok amelyekkel nem csak elvétve találkoztál.
Az USB hiba gyakori, 101-es proci, programozási nehézségek... ok. és mi van még?

Én innentől nem mentem bele sokkal jobban. Egyszerűen nem éri meg nekem az idegeskedést.
A hobbimhoz teljesen jók a gyári Nucleok. A munkahelyemen is azokat használjuk. Ott pedig szóba sem jöhetnek a kínai klónok, az ST hivatalos disztribútorától vesszük a komponenseket.
Amivel még találkoztam: Retro számítógépekhez van rengeteg open hardware és software kiegészítő, amik már nehezen elérhető hardvereket váltanak ki. Ezek zöme Arduino, Bluepill és RPI alapra épül, mert ezek olcsóak, és sokan fejlesztenek rá a retro közösségekből. USB floppy adapter, SCSI HDD emulátor, ROM emulátor, órajel generátorok, stb. Na, ott futottam még bele, hogy az egyik Bluepillel működött az adott helyettesítő, például SCSI emuláció, a másikkal nem. Szemmel láthatóan csúnyábban néz ki a felirat a nem működő IC-n, mint a működőn. És sántítva hasonlít a gyári Nucleo IC-jén lévő feliratra. Az okokat nem tudom, nem álltam neki debuggolni. Atmel MCU-s kínai Arduinokkal ilyenbe még nem futottam bele. Ott csak hibás ellenállás érték, ellenállás helyett kondenzátor, illetve 180 fokkal elforgatva beültetett IC fordult elő.
Mindenesetre kerülöm a nem eredeti STM32 mikrokontrollereket, mert eddig csak bosszúságot, és időkiesést okoztak, amit egyáltalán nem tud pótolni az olcsó áruk. Különösen úgy nem, hogy mindig mást küldenek. Hiába ismerem ki az egyik problémáit, ha legközelebb már másképp nem jó a cucc.

Ezek ST-s feliratú IC-k? Vagy más gyártók ST-s analógjai? Mert ha ez utóbbi, akkor nem kell csodálkozni rajta! Ha előbbi..., főleg, ha ID alapján is egyezik a gyári azonosítóval, akkor az már érdekesebb....
Ahogy említettem, nekem eddig csak gyári ID-el megegyező IC-kel szerelt paneljeim voltak/vannak, melyeken értelemszerűen a felirat is ST-s(abba most nem mennék bele, mennyire fogyott el a "tintájuk" éppen, vagy találták meg a "zigazi" fontkészletüket)..., azoknál én még semmilyen hibába nem futottam eddig...., bár az is tény, hogy az USB perifériát korántsem mindegyiken használtam... De legközelebb, mindegyik kezembe kerülő példányon futtatok egy USB-s tesztet, kíváncsiságból...