Nem értem pontosan mit akarsz, de erre valók lennének a könyvtárak. Azt meg letöltesz, egyet kizippeled abban van minta, a lényeg a .cpp meg a .h file. Az ino meg ezeket fogja össze.

Rossz helyre linkeltem, egyel alá kellett volna, de mindegy is.
A keretrendszer adta lehetőséggel élve .ino fájlokat kapok, nem .c, .cpp vagy .h-t és a miértekre keresném a választ, de hagyjuk! Értem én, hogy könyvtárak, de ezt az életben nem fogom máshol használni, úgy gondoltam, hogy ha nem szabályos (a félresikerült válaszom előtt lévő hozzászólásban hangzott el (kapu48#'2264684')), hogy .ino-nak hívják, akkor van valami egyéb út, de akkor majd hagyom a fájl alján ami már tutira megy és nem darabolok!

Ha jól értem amit szeretnél, ámde lehet, hogy butaságot írok, de nekem a múltkor úgy volt, hogy nem volt komplett lib fájlom a kódhoz, hanem csak .c vagy .h. A könytárak menünél van olyan, hogy fájl hozzáadása (talán), ekkor az aktiv ino mellé egy másik fülre odatette a .c/.h fájt, egy ablakon belül.
Ezután, ha kiüríted a .c fájlt és beleteszed a tiéd, akkor szerintem menni fog.

Nem egészen erre gondoltam.

Nem értem mért vagy fen akadva a szabályok feszegetésén?

Nem szabályok vannak, hanem ésszerű és hasznos elhatározások, bevett szokások.
Amit magadnak kel kitalálnod, eldöntened.

Pl.: Van egy készüléked, amit többször is használni akarsz, akkor annak a programját külön állományba rakod. Így könnyebben tudod majd átvinni másik alkalmazásba.
Vagy ha már túl nagyra nőt a programod, és nehezen találod meg az éppen érdeklő részletet?
Akkor is részekre bonthatod, általában valami nagyobb témát pl.: grafikus alkalmazás,
vagy bármit, ami egybe tartozik. Külön rakhatod, és jól megadod állomány név esetén, tudni fogod, hogy mit hól keressél.

Arról pedig, hogy mikor legyen C vagy Cpp a kiterjesztés könyveket lehet írni, és ezt már nagyon sokan megírták. Neked csak elkellene olvasni valamelyiket!
Már ha tényleg érdekel a téma?

És ha már szétbontod több részre, akkor kel a: *.h, abba teszed az olyan változókat deklarációkat,
Amiket több helyen is használni akarsz. És az adott állományba be includolhatod.

És mindennek úgy tudod hasznát venni, hogy szerkesztéskór több ablakot megnyitsz.
Nálam pl. 2 monitor van, és arduinot többet is megnyitok egymás mellé, külön lapokkal.
A fő képernyőn van a szerkeszthető rész a többit külső szerkesztőre állítom, így azok követik a változásokat, és csak keresésre használom őket.

Még szerkesztéskór nagyon hasznos alkalmazás a Programers Notepad!

Itt ez volt a lényeg, hogy ezt kb. soha az életben nem használnám máshol (háttérkép generálás, specifikusan ehez az egyhez), de c-ként nem tudom kezelni (illetve lehetne ha az include-okat is abba írnám gondolom, de sehol nem láttam ilyen példát még), míg ino-ként ment. Amit máshol is használnék, már kiraktam lib-be, volt bajom, de megvan, értem is (hellyel-közzel), hogy mit hová és miért. Azt nem értettem, hogy miért kell egyetlen ino-nak lennie és a keret miért generál mégis automatán ino kiterjesztést neki (megértettem amikor írtad, hogy egy későbbi verzió talán le sem fogja fordítani úgy, ezért kerestem egy szabványosabb utat), de írtam is, hogy hagyom a fájl végén inkább, hogy ne legyen ezer+1 ino egy projektben. Nincs ezzel gondom, csak néha következetlennek gondolom, mivel az ino fájlokat besorolja automatán és nem kell kétszer includolni semmit. (a háttérkép generálásnál is használ lcd-re írást és a főprogramom is ír az lcd-re). Itt megint az van, hogy nagyra nőtt és az alja/teteje között tekergetve néha fonalat vesztettem, hogy hol járok. Most azt tettem, hogy amit leteszteltem és működik, a fájl végére tolom és így csak 1db ino kiterjesztéssel dolgozom.
Attól, hogy fenn vagyok akadva a szabályokon, nem azt jelenti, hogy nem akarom alkalmazni őket, hanem érteni is szeretném! Van 3 gyerekem, egynek se adtam a kezébe egy könyvet, hogy olvasd végig, ott a megoldás benne, hanem igyekeztem egy közelítő támpontot adni, hogy a 3.fejezet első felében leírja! Qt-n is programozok ezt-azt, ott nem kérdéses a fájlkiterjesztés és működnek is amit írok! Az ino-val vagyok csak bajban, mert ez csak egy kitalált kiterjesztés egy c/cpp-nek. De amint írtam, nem gáz, a fájl végén hagyom, mert ezt a programrészt sosem fogom máshol használni! Amit igen azt már kiraktam belőle.

Erről küldhetnél egy képernyőképet (esetleg privátban ha nem ide való)! Sosem programoztam hivatásszerűen, csak mókából, de mostanában egyre többet Könnyíteném az életem ahol lehet!

Baloldalon a szerkeszthető változat, középen csak keresésre van valamelyik választható állomány, ha éppen több is van.
Jobb oldalon a harmadik ablak a második monitoron, Notepad amiben általában valamelyik éppen használt külső lib állományai vannak, akár több is egymás alatt.

Most, ha valahol szerkeszted valamelyik állományt, és azt elmented.

Akkor a középső külső szerkesztésre állított arduinoban minden javítás frissítésre kerül.
És végezhetsz próbafordítást. Siker esetén akár fel is töltheted a programod, ellenőrzés képen.

Viszont a baloldali arduino nem követi, ha például a notepadban szerkesztesz és mentesz valamit.
Ezért erre odakel figyelni!

Sziasztok!

Próba panelen összeállítottam Ezt a kapcsolást, de nem tudom mit csinálok rosszul, mert nekem nem úgy jelennek meg a karakterek mint a videón.
Csináltam képet hogy mire gondolok:

az óránál az idő és a kettőspont mintha el lenne csúszva jobbra.

Helló!

Az 1098. sortól kezdődően nézd ezt meg:



A sor az ok, de a column-t nem értem miért 7. Az változtatná a villogó pontok helyét. Elvileg ha az egész LED modul 1 egységként van kezelve akkor csak azt a 7-t kell átírnod. Azonban szerintem a mátrix több elemből áll, ezért kell bele az address (adr változó). Ha igaz, akkor hibás címet kap, azaz nem a megfelelő alegység címét kapja meg. Soha nem dolgoztam ilyennel, próbálgass. Elsőként írd át 1-re, majd kettőre, háromra, stb. ezt a hetest. Így vándorolni fog. Ha végigment a kis egységen, akkor a címet is lehet változtatni.

Ez a függvény megkapja az add változót. Itt az if ben add==2 van. Esetleg ezt is átírhatnád próbaképpen pl 3-ra. Ha nem ez a gond, akkor ami ezt hívja meg, az rossz címet ad át.

Köszönöm a segítséget, holnap el játszadozom vele, ma már káprázik a szemem.

Valaki tud valuta váltó megoldást ami megbízható is?
Bővebben: Link
Minta példa sem működik pedig van net az átjárón ahová csatlakozik !
ezel panaszkodik

Jó reggelt, sikerült beállítani a segítségeddel.
A nullák voltak a nyerők.
Köszönöm még egyszer.

Szerintem nem a 7-essel van a gond, inkább az adr kiválasztással!

4 db 8x8-as LED mátrix van felfűzve, s ezek sorszáma 0, 1, 2, 3
a sorok és az oszlopok sorszáma pedig 0..7 lehet.

A programban az lc.setLed() függvényhívásnál az oszlop sorszáma azért 7, mert a második számjegy 7-es sorszámú (valójában nyolcadik) oszlopában kell megjeleníteni a kettőspontot.

Most úgy néz ki, hogy a mátrix sorszámozása nem jó, tehát én az

sort próbálnám megváltoztatni, hogy 2 helyett 1 legyen.

Az 1109. sorban is van egy hasonlós sor, ott is módosítani kell.

Már csak az a kérdés, hogy ha a kettőspont rossz helyre kerül, akkor a számok nem fordított sorrendben jelennek meg?

Sziasztok!
Egy kis segítségre lenne szükségem, már hetek óta próbálok egy használható programot írni egy mikrokontroller vezérelt elektronikus gyújtáshoz, ami egy egyhengeres kétütemű motoron működne.
Dióhéjban a program működése: Egy hall érzékelő figyeli a főtengely állását. Amint az érzékelő jelet ad (attachInterrupt) elindítja a Timer1 számlálót majd a következő jelre a számláló alapján tárolt microseconds értéket eltárolja a periodTime tárolóban ami tulajdonképpen az egy fordulat alatt eltelt időt jelenti us mértékegységben, nullázza a microseconds tárolót és minden fordulatnál újra méri az egy fordulatnyi időt. Ez adja az alapját a loop()-ban lévő függvényeknek és a mikrokontroller kiszámolja, hogy mikor kell indítani a trafó töltését majd az áramkör megszakítását, a szikra adást. A trafó áramkörének zárását és nyitását egy ISR megszakításban lévő függvények végzik a microseconds és a lopp()-ban kiszámolt gyújtási idők alapján.
A probléma az, hogy az egy fordulatnyi időt úgy gondolom, jól méri (soros portot nem tudok használni), de mégsem ad minden fordulatnál gyújtást és nagyon lassan dolgozik a 16MHz órajel ellenére. Több utat is kipróbáltam, akkor is ez van, ha a trafó áramkör zárás és nyitás a loop()-ban van és egy megszakításban a micros() függvény segítségével mérem az egy fordulatnyi idő.
Esetleg valakinek van valami ötlete, hogy mit ronthatok el mindegy módszernél?
Előre is köszönöm a segítséget!

Én a hall érzékelő jelét a maximum előgyújtásra állítanám. Jön a megszakításkérés, majd a megszakításban történik a várakozás. Minél alacsonyabb a fordulat, annál többet. Max fordulaton rögtön csattan a szikra. A megszakításon kívül pedig számíthatod a fordulatszámot.

Igen én is írtam, hogy ha nem megy akkor azt is meg kell nézni. Utolsó sorban erre gondoltam, de tanulok, elfáradok délutánra/estére, olykor nekem sem világos mit írok le!

Illetve sosem kódoltam ilyet, csak belenéztem a kódba.

Most jelenleg úgy próbálom meg összehozni, hogy amikor a dugattyú átfordul a felső holtponton, a hall érzékelő akkor ad jelet és a mikrokontroller számolja az összes többit. A te megoldásod esetén is számolnia kell ugyanezeket, csak éppen van egy 2000-es fordulatszám tartomány, ahol a a hall ic jelére adja a szikrát és a mikrokontrollernek semmi dolga. Ebben az esetben nem állna elő a korábban vázolt probléma?
Nekem inkább az az érzésem van, mintha a kontroller nem tudná megfelelően használni a periodTime tárolóba rögzített fordulat időt.

Én lehet, hogy nem vonnám bele a timert a késleltetésbe. Mint fentebb írtam, a legnagyobb előgyújtásra tenném a hall érzékelő megszakítás jelét és a megszakításban lenne egy for ciklus, ami néhány NOP-ot futtatna. Ahogy lassulna a fordulat, úgy futna egyre többször a for ciklus.
Amire ránéznék, az az lenne, hogy a CTC módban hajtott timer nálam sokszor véletlenszerűen indul. Gondolok itt arra, hogy nem mindig felfutó éllel indul, hanem sokszor lefutóval. (328-nál). Ilyen gondom nem szokott lenni sem fast pwm módban, sem fáziskorrekt pwm módban. A CTC szokott szivatni.

Azzal szokott probléma lenni, amikor a váltás előtt változtatod a komparálási értéket, így pont amikor a kimenetnek váltania kellene, nem vált, az új érték miatt pedig kb. dupla olyan hosszú lesz a kimenet állapota, mint lennie kellene. Magától nem csinál butaságot a timer, vagyis én még nem tapasztaltam.

Ha egyszerre indítok mondjuk 4 timert, 3 darabot fast pwm módban, 1-et ctc-ben, akkor a fast pwm-ek ugyanúgy szinkronban indulnak, a ctc pedig véletlen szerűen fel, vagy lefutó éllel. Hiába nullázom a létező összes regisztert.
Csináltam egy programot, ami figyeli a ctc-s timer kimenetét. Ha nem ugyanúgy felfutó éllel indul, akkor leállítja és újra indítja. Ritkán elsőre is indul jól. Általában másodszor-harmadszor a jó, de van, hogy kilencszer is nullázni és indítani kell, hogy felfutó éllel induljon.

Ilyenről még nem hallottam, de simán lehetséges. Ha a timernek adsz kezdőértéket, akkor is ezt csinálja? A kimenetet váltod (output change), vagy pedig fix állapotot rendelsz hozzá? Arra gondolok, hogy az output change okozhat gondot, nem tudom, hol van eltárolva az előző állapot (ami bekapcsoláskor nem is létezik). De megoldottad a problémát, ez a lényeg!

CTC módba, mindkét kimenetet felhasználva ugyanazon frekit kaphatod mindkét kimeneten, de állítható fázisban. Ilyenkor sok esetben még egymáshoz képest is változóan indulnak.
A timernek miként adhatok kezdő értéket? Ezt nem tudom.

TCNTx regiszter tárolja az aktuális értéket. Lehet le kell nulláznod mindet, mert indítás után azonnal elkezd számolni, és ha egymás után konfigurálod a timer-eket, az első már máshol tart, mint kellene. Lehet ez a gond?

Akkor ez kilőve, mert ezek nullázva vannak.

Ami észrevételem, a lebegőpontos számítások nagyon lassúak, bár nem tudom mennyire összemérhető az időkkel, de ha mikrosecekről van szó, akkor már számottevőek lehetnek. Ha lehet inkább eltolás összeadás közelítést alkalmaznék. A másik, mi van ha néha téves mérés történik, lehet a mért értékek valamiféle átlagolása, és a nagyon eltérőek szelektálása sem volna hátrányos.

Ha nem haragszotok meg, feltölteném ide az eddigi programot, a vs1053-as illetve Arduino Nano kombinációban készített samplerrel, ilyen mentés funkcióból, hogy ne kelljen elölről kezdenem. Nagyjából kommenteztem az elejét, de a program közben nem, mert rohadt zavaró volt... Elvileg 50 program választható, mindegyikhez külön beállítások, illetve mintakönyvtár beállítás, hogy az sd kártyáról honnan töltse be. Programonként állíthatóak a minták eleje, illetve végei, hangszín értéke, a minta sebessége, az "earspeaker" értéke. 50 beállítás menthető a romba. Programváltáskor előhívható. Több különböző logikájú billentyűmód... Beállítható, hogy csak midi kontroller legyen. Akkor csak Midi üzeneteket küld, olyankor gyorsabb a készülék. Még egy két animációszerűség is van benne. Kb 73% memóriát használ. Sajnos vannak gyermekbetegségei, de játéknak jó... A folytatásban valahogy meg kell oldanom, hogy adatokat tudjak olvasni, illetve azokat feldolgozni, visszaírni a vs1053 bufferébe...

Szia, a 134. sorban van egy hiba. Tizedes jelnek (,) vesszőt használsz.