Nálam a 100nF minősége nem volt mindegy. SMD-vel ment, fóliával nem.

Sajnos elkiabáltam a dolgot egy kicsit. Minden müködik ahogy irtad a megszakitás gyorsitása stb. A baj az, hogy valamilyen konfliktusba kerültem a fordulatszámláloval ami a loopban van és egy egyszerü gray-code számlálo, fordulatonként 1 impulzussal. Ha a IRQ sebesség 2 ms alá megy ( a cél 1-0,5 ms lenne) a számlálo 8-12 fordulatonként megáll 1-2 másodpercre. (Kihagy 1-3 fordulatot). Nem tudom még pontosan mi az oka. Sajnos a fordulatszámlálot nem tudom megszakitásbol kezelni mert az a port foglalt.

A leírt módon felprogramozva 115200-al oda-vissza jól megy.
Úgy tűnik az órajellel nincs gond.

Köszönöm a tippet, kipróbálom.

Ha 16MHz a csip órajele, akkor 1ms alatt 16.000 ciklus fut le: jóval ez alatt kell tartani az ISR futásidejét, hogy "ne érjenek egymásra". Ez egyébként nem kevés órajel, nem hiszem hogy a tekercselő logika több volna, tippre 100 körül lehet. De ha például osztást is csinálsz periodikusan, az egyből nagyon sok órajel. De még azzal is nehéz kifogyasztani a 16.000-et.

Ha túl sok az ISR, akkor a főprogramnak nem marad idő futni, illetve az időzítőkből is kimarad pár. Ez lehet egy hibaok. Ezt lehet az ASM lista alapján számlálni, becsülni, vagy ha az ISR elején egy debug lábat magasba küldesz, a végén pedig alacsonyba, akkor meg tudod mérni a kiszolgálás idejét szkópon is.

A másik, amivel foglalkozni kell, hogy a főprogram mit csinál még a számoláson kívül? Például ha a főprogram, vagy az ISR kommunikál Serial-lal (debug trace üzenetek például), akkor az elég hosszú ideig blokkolhatja a futást, abból is gond lehet. A serial kommunikáció az egyik, amit másképp szoktam megvalósítani, mint ahogy az Arduino csinálja. Az Arduino print blokkoló módban működik, ami baj mert a HW puffer 1 bájt. Tehát ha 2 bájtot írsz egyszerre, akkor a második már várakozni fog! (Bejövő oldalon az Arduino lib is használ egy puffert.) Ehelyett egy-egy nagyobb puffert foglalok a ki és bemenetnek, a print hívás oda ír, és a bájtok küldését aszinkron módon valósítom meg ISR-ből. Így is figyelni kell arra, hogy hosszú idejű átlagban kevesebb üzenet legyen, mint ami átfér a baud rate-en, de legalább sosem blokkolja a futást a trace üzenet.

Kösz az ötleteket.
Gyakorlatilag csak egy primitiv ISR van, ami léptetei a fömötort, 200 lépés/sec ami 60 RPM. Ebböl van elvonatkoztatva a másik motor mozgása ( osztással minden 5-40 lépésre lép egyet a másik motor. Abban van még egy iránykapcsolo ami bizonyos lépés után megváltoztatja a motor forgását. A fordulatszámlálo meg a loopbol van lehivva, amikor az elsös szenzor állása változik (másodpercenként egyszer 60 RPM-nél) eggyel csökkenti a menetszámot. Ez addig meg hibátlanul amig a ISR idöalapja 2 ms felett van. ( 2000 a timer). Az aktuális fordulatszámot is az irányt a I2C 1602 displayen jelzem ki ( ott nem tudom, hogy van-e még valamilyen ISR.). A display szintén a loobbol van frissitve.
A föprogramban 3 switch ...case van, de amikor tekercsel, akkor abban az üzemmodben gyakorlatilag csak megengedem a motorok forgását ( átkapcsolok egy flaget), és elinditom a számlálot aminek az eredményét kiirom a displayre - más nincs a progamban, valamint figyel egy nyomogombot, amivel meg lehet állitani a forgást.
Lehet, hogy az ISR-böl kiveszem teljesen a kis motor vezérlését és átteszem a föprogramba.
Majd este megprobálok még vele elszorakozni.

Sajnos nem sikerült összehangolnom a független számolot a hajtással. Számomra érthetetlen okok miatt oeriodikus megakad, ha a motos gyorsabban lép mint 2 ms. Igy mos átalakitottam a kodot és egyenesen a motor fordulatszámát számolom igy mos a számolás tökéletes, a korábbi számolo szerkezet meg felesleges..

Elnézést a sok hibáért, már késö volt.

A léptető motort vezérlő lábakat digitalWrite() függvénnyel állítgatod?

Igen, de egy-egy meghajton keresztül, azaz csak STEP és DIR kimenete van mindkét motornak.
Az UNO-ra egy 4 csatornás CNC shield van dugva de csak 2 meghajtoval.

Régebben csinálgattam egy léptetőmotoros dolgot. Ott ütköztem abba a problémába, hogy a digitalWrite függvénnyel nem tudtam egy bizonyos sebesség fölé menni, mert viszonylag lassú a függvény. Úgy olvastam, hogy hatvan-valahány órajel ciklus. Regiszteres port piszkálással viszont már nem volt ilyen gondom.

Nem tudom pontosan mennyi idő, de ha gyors kimenet kell én is kerülöm.
Részlet a wire_digital.c fájlból:

Miért kell ilyen bonyolultnak lennie?

Kompatibilitás miatt.

Nekem azzal nem volt gondom - nem volt szükség tul nagy sebességre ( 400 lépés/sec elég). De a fordulatszámot ettöl függetlenül számoltam ami nem müködött jol nagyobb sebességnél.

Sajnos SMD kerámiával sem működik.
A reset impulzus hatástalan, nem látja a soros portot.
Talán azt valamilyen paraméter megváltoztatásával, vagy biztosíték beállítással kellene elérni.

Azt is teszi, hogy ha a timer kimenetét használod és a működése közben állítanád a kimenet szintjét, akkor lekapcsolja a kimenetről a timert.

Én mikor ilyet csináltam, összekötöttem a géppel programozón keresztül (mosi miso sck...) az arduinó keretprogramban kiválasztottam a programozót, utána mondtam neki, bootloader égetése.
Megcsinált mindent, nem kellett semmit utólag állítgatni.A felprogramozott chipben induláskor megnézi, hogy a soros porton kap e érvényes adatot, ha kap, annak megfelelően azt beégeti, ha nem akkor egy bizonyos idő múlva tovább lép a felhasználó által készített programra. Ha a DTR lábra nem reagál, akkor a megfelelő pillanatban ( kb mikor kiírja feltöltés) felengedett reset gombbal is ki lehet váltani a programozó módot.- és feltöltést.

Az esetek 1%-a miatt kellett lassítani az egészet?

Ez a gombnyomás meg a régi bootloaderes lapoknál megoldható volt, az új bootloader szerintem 0.5mp-et se vár.

Gondolom az volt a szempont, hogy bolondbiztos legyen. Volt eset, amikor én sem értettem, hogy miért melegszik az MCU. A timer nyomta a PWM jelet a kimenetre, ami nullán volt. Kissé bele voltam keveredve.
Ilyesmi hibák miatt csinálták bolondbiztosra.
Az Arduino megalkotásánál volt sok Rejtő Jenő féle kompromisszum:
"Végre is, ha Rezedát ártatlanul agyonverjük, kisebb hiba, mint ha életben marad, és ő a bűnös."

Lehet rájöttek, hogy már inkább programozóval töltöm fel a programot, mert néha kivárhatatlan a bekapcsolási késleltetés. Ha az új gyorsabb, csak üdvözölni tudom. ( bár a programozó akkor is gyorsabb.)

Nagyon szuper az új bootloader. Mintha nem is lenne késleltetése. A program is gyorsabban fent van, mert nagyobb sebességen megy a kommunikáció. A bootloader is kisebb, mint a régi, csak elfelejtették a megfelelő fuse bit-eket kiválasztani, ezért ugyanakkora helyet foglal el, mint a régi, pedig a fele is elég lenne (ha azóta nem változtattak rajta).
Megtaláltam: "Der bisherige Bootloader ATmegaBOOT wurde gegen Optiboot ausgetauscht und damit einhergehend auch die Datenübertragungsrate von 57.600 Bd auf 115.200 Bd verdoppelt.

Optiboot ist vor allem deutlich kleiner als der alte Bootloader (1,35 KB anstatt 5,4 KB beim Vergleich der Hex-Files) und erlaubt eine schnellere Übertragung der Daten, was sich angenehm bemerkbar macht, wenn man größere Programme flashen will. Vom eingesparten Speicherplatz hat man als Anwender aber nichts, denn der reservierte Speicherbereich für den Bootloader beträgt durch die unveränderten Fuse-Bits weiterhin 1.024 words (2 KByte)." - röviden: Optiboot-ra lett a bootloader lecserélve, dupla gyors programfeltöltés, a bootloader .hex fájlja 1.35kb-ot foglal a régi 5.4kb helyett, viszont a fuse bite-ek változatlansága miatt 2kb hely ígyis-úgyis le van foglalva, tehát nem nyertünk plusz helyet.

Sziasztok ,kezdő arduinos vagyok ,és az alábbi témában szeretnék némi segítséget kérni:
Bringa sebességmérőt készítenék 2 db 7 szegmenses leddel.(2 különálló szegmensem van,
közös anódos,nem egybeépített ezért összesen 20 csatlakozóm van.A 2 tizedespont nem kell
meg az anódra is elég 1-1 ,így 16 marad)Ardu nanó-m van de kevés a digitális pin)
Az elv: A0 -ra hall senzor ,ez megvan és jelet is ad ,kipróbáltam.Kerékre van jó erős neo mágnesem.
Addig eljutottam,hogy 1 szegmensre ki tudok írni egyjegyű számot.
Viszont a "millis" segítségével kellene 2 jeladás közt mérni az eltelt időt ms -ban,egy változóba betenni
pl "kulonbseg" néven,és ezután egy feltételt beállítani:
ha "kulonbseg " >= 200 ,akkor digit 1 legyen "2" és digit 2 legyen "4" (24 km/óra)
ha " kulonbseg" >= 150 ,akkor digit 1 legyen "2" és digit 2 legyen "8" (28 km/óra)
ezek a számok csak becslések ,ki tudom majd számolni a pontos értéket.
Azt kérdezném ,az analóg pineket fel tudom használni ehhez,mert úgy megvan a szükséges 16?
Nos ,ehhez kellen valami kód ,mint írtam saját magam nem tudom megírni...
Az is jó lenne ha 40 x van benne az "if" ,(40 km/óráig elég)majd szép lassan beírogatom a kiszámolt értékeket.Hagy dolgozzon az Arduino...
Tudom ,hogy ez nem igazán szép kód lesz,de legalább értem ,aztán majd egyszer megtanulom
lerövidíteni.Egyelőre elég lesz a Ctrl+C - Ctrl+ V verzió.
Bocs ,hogy hosszú volt és köszi a tanácsot,üdv.

Ezt nem igy kell kezelni. A 7 szegmentes displayek azonos szegmenseit össze kell kötni, igy már csak 7 bemeneted lesz plusz 2 anod. Az anodokat egy-egy tranzisztorral kell kapcsolni, azaz egyszerre csak 1 display világit. Ha ezt gyorsan kapcsolgatod, akkor ez nem látszik és a szemeddel mindkét displayt fogod látni.
A kodra meg meglehetösen sok forrás van keresgélj a neten meg a youtubon, ahol kész megoldást is találsz ( akár 4 displayre is - pl az orákon van ilyesmi).
Amugy az A kivezetéseket is használhatod kimenetnek, ha megfelelöen állitod be a void setupban, de ne válaszd ezt az utat a fenti jobb. Ahhoz elég egyszer megirni a számok kodjat ( melyik számhoz melyik szegmensek tartoznak) és azt arra 7 kimenetre juttatni, ahova kötve vannak, utánna már csak az kell eldönteni melyik displayen világitsanak.
Sok sikert!

Nem szerencsés választás a LED a bringára. Ha rásüt a nap, nehéz lesz leolvasni. Inkább egy kétsoros karakteres LCD, aminek fekete a karaktere és zöld a háttér világítása. Ezt bármilyen erős nappali fénynél tökéletesen látni, este meg világíthat. Az olvashatóság miatt pedig használhatsz nagy karaktereket.

Nekem motorkerékpárra a Nextion kijelző vált be.

Köszi a válaszokat,jelenleg abból "főzök"amim itthon vav éppen.A Nextion biztos szuper,
mert még az Alin is 6000 -nél kezdődik.Sokat keresgélltem a neten,de leginkább mindenki
MAX7219-re építi a ledeket ,az meg épp nincs itthon.

A reset gomb felengedése a megfelelő időpontban már megvolt, 100 próbából egyszer sem volt eredményes, ami valami alapvető problémára utal.
Programozóval persze semmi gond. De ha már van bootloader, egyszerűbb lenne azt használni.
Talán gond lehet, hogy előtte frissítettem a legújabb verzióra.

Küldj adatokat az arduinóról 115200 bauddal, ellenőrizd jól megkapod-e. Ezután az arduinóra tegyél fel egy olyan programot, ami a kapott adatot visszaküldi 115200 bauddal. Ezeket a beépített terminállal tesztelheted. Ha ezek nem mennek, esélyes a chipp melletti kvarc értéke nem jó, ezért a baudrate beállítás nem megfelelő. (8/16Mhz) Esetleg a kommunikációt érintő zavar van, amiről a bootloader nem tehet. Mindenesetre egy könnyebben kereshető hiba. Ha ezek mennek, következő kérdés, maga a reset gomb hatásos?