Az ICR1 regiszter a periódus időt határozza meg. 65535-nél nagyobb nem lehet. Az kicsit több, mint 4 másodperces periódus időt tesz ki. Most 2 másodpercre van állítva. Az OCR1x regiszter a két kimenet PWM értékét tartalmazza. Maximum értéke az ICR1 lehet.
Max 4,19 másodperces periódus idő a maximum, amit tud a timer1 16 MHz-es órajel mellett fast PWM-ben, 1024-es előosztó mellett. Fázis korrekt PWM-ben a dupláját. Ha ennél is hosszabb periódus idő kell, akkor már az MCU órajel előosztóját is osztásra kell állítani, ami lassítja a műveletek elvégzését. De azzal cirka 2145 másodperces periódus időt lehet elérni. Ha ennél is nagyobb periódus idő kell, akkor már le kell cserélni lassabbra a kvarcot.

Igen olvastam most már. Azért forgott a motor elsőnek mert az agyonstruktúrált, objektumorientáltan programozni tudó nagy tudású valaki az SS pin-t elfelejtette outputra állítani, így semmi adatot nem fogadott el az IC, a bekapcsolás után a RUN engedélyezve van, így elég csak pwm jelet adni a motor forog. Van egy szép nem működő program hozzá a referencia:
Bővebben: Link

Az arduino fejlesztőkörnyezetet át lehet állítani valahogyan, hogy ne utf8-ban tárolja az ékezetes karaktereket, hanem mondjuk használjon iso8859-et vagy bármi olyat ahol nem foglalnak két bájtot
az ékezetes betűk?

Nem tudok róla, hogy lenne és valószínűleg nem is lesz, mert a fordító a kódban eleve utf-8-as kódolást használ és ennek a megváltoztatása kompatibilitási problémát okozhat (a wide karakterek példáján okulva, amit benne hagytak a fordítóban az utf-8 megjelenése után).
De létezik konverter hozzá, arra az esetre, ha a soros monitor nem támogatja az utf-8-at.
De miért van rá szükséged, hogy 1 byte-os legyen? Hátha van rá más megoldás.

Sziasztok.

Arduino nano (atmega328) tudom használni egyszerre a soros portot és az I2C port-ot egyszerre?
Soros port-ra egy Nextion kijelző menne, i2C- pedig egy mcp23017-es i/o port-bővítő.

Köszönöm.

Szia, szerintem nincs akadálya. (használtam már "egyszerre")

Tudod. Miért nem próbáltad ki?

Mivel jelenleg nincs itthon sem port bővítő sem Nextion kijelző.
(Mert, ha nem lehet, akkor felesleges lenne rendelnem)
Köszönöm.

Köszönöm.

Sziasztok!

Először szeretném megköszönni a sok segítséget a PWM jellel kapcsolatban!

Másodszor szeretnék ismét segítséget kérni. Javasolták a fórumon, hogy szerezzek be MAX31855 k típusú hőszenzor erősítőt mert ez tágabb tartományban tudja értelmezni a hőmérsékleteket. Azonban kipróbáltam az arduinoval példakódot használva a könyvtárból (Adafruit MAX31855) de teljesen értelmezhetetlen értékeket kaptam. Máshol olvastam, hogy zajszűrés céljából erősen javallott egy 10nF-os kerámia kondenzátor bekötése a bemenetre. Ugyan 10nF-os kondim nem volt, de bekötöttem egy 45nF körülit de semmi nem változott. Valaki találkozott már ilyen problémával, több külföldi fórumon utánanéztem de nem találtam semmi megoldást. A termoelemeket kipróbáltam MAX6675-el és úgy működtek.

A kód az alábbi:


És az alábbi értékeket kapom a soros porton:



Előre is köszönöm a segítséget!

Skori, amiatt kérdezed amit ITT írtam?

Én ASCII forrással dolgoztam, nem Arduino alatt, ha a forrás file csak UTF-8 lehet, akkor is meg lehet szerintem csinálni, csak akkor a mappelő függvényben ha 0xC2 vagy nagyobb byte jön, akkor azt csak eltárolni kell mint utf8 első byte, és a következő byte kiírásánál megcsinálni a mappelést.

Így a forrásban UTF-8 lesz, de az LCD-re kiküldve ASCII.

Igen amiatt is. Tudom is kezelni a problémát, de sok dolgot egyszerűsített volna.
A probléma összetettebb annál amint amit írsz, ugyanis az a megoldás, hogy a 0xc2 vagy nagyobb byte esetén tudom, hogy UTF8 karakterként kell feldolgozni, az bájt sorrend függő.
És már belefutottam olyanba, hogy amiatt kellett átírnom, mert az a processzor amire át akartam vinni a kódot, fordított bájt sorrenddel tárolta az adatokat (típust ne kérdezz, sok éve volt már).
Ha nem kellene az UTF8-at használni, akkor lehetne processzorfüggetlen kódot írni.

A jelenlegi megoldásom egyébként ilyesmi:
Itt a konverziós táblázat és a sok switch-case helyett két string konstanst, és ciklust használok a konverzióhoz (jól működik). Többféle karaktertábla esetén csak ezeket a string konstansokat kellene #define-ba kiraknom.

Értem. A táblázatos megoldásod jó, sokkal tömörebb.
Utf-re a switch-case elég terjengős lenne, de ASCII-ban megfelelt.

A switch-case megoldásodban az tetszett meg, hogy könnyen áttekinthető. De ahogyan írod is, utf8-al kompatibilissé kellene tenni, ha arduinoval is használni akarnám. Ma már talán ügyesebben, ill. áttekinthetőbbre meg tudnám írni a táblázatos megoldást is, de jó lett volna az utf8-tól megszabadulni. A forrasztóállomásom programjában is használom ezt a függvényt, de néha elgondolkozom rajta, hogy valamilyen ügyesebb megoldást kellene csinálni.

Nem. Illetve a régi 1.0.x illetve -0023ig bezárólag tárolta nem UTF-8ban.
A spec beállítások a preferences.txt-ben vannak - de abban nincs ilyen lehetőség.

Akkor marad a jelenlegi megoldás. Azért köszönöm mindenkinek aki utánanézett vagy próbált segíteni.

Egy gyakorlati kérdésem lenne:
Milyen módszerrel, logikával alakítjátok át a bool logikai típusokat a praktikusabb tárolás céljából bájt-á?
(Tehát ha van 8 független bool változód, és nem szeretél 8 bájtot kidobni rájuk, akkor milyen praktikához folyamodtok, hogy bájt-á alakítsátok őket át?)

Össze tudod bindzsizni bitműveletekkel (Bővebben: Link), de lehet, hogy több memóriát buksz el a műveletekkel, mint amit megnyersz az adaton.

Nem biztos, hogy jól értem a kérdésedet, de a klasszikus mikrokontrolleres megoldás a flagek használata bit művelettel. kb. így:
Hogy programozástechnikailag ez manapság mennyire indokolt, az megint más kérdés.
Én szeretem ezt a megoldást, jól olvasható kódot ad.

Pl. Bit Field használatával is megoldható.

Köszönöm a segítséget. Konkrét leszek: van egy 32*8-as boolean tömböm, ami a Nano program memóriájának kb 10%-át megeszi. Gyanús lett, hogy ez túl sok. (Ezek egy szekvenszer dobhangjait tárolják) Átalakítottam byte-os tárolásra, és 77%-ról sikerült 68%-ra lemennem. (aminek örülök egyébként) Viszont ilyen bitReader-es megoldást kellett alkalmaznom a tömb címzéshez, valahogy így:

Tehát kénytelen voltam a 8-as maradékok alapján címezgetni a tömböt, ami egyébként úgy néz ki működik, csak nem vagyok biztos benne, hogy ez a legkézenfekvőbb, és leggyorsabb megoldás...
Mindenesetre most átrágom a programot, és minden logikai változót átszervezek byte-ba. Csak megfordult a fejemben, hogy ezért felesleges volt létrehozniuk ezt a típust, mert így kb többet árt, mintha eredetileg is byte-os szemlélettel építeném fel a programot... Tehát mondjuk, ha lenne erre egy fordító opció, az megmagyarázná a dolgot...

Az Arduino kódok kapcsán szerintem ez egy igen jellemző probléma. Nem tudod ki írta meg, nem tudod hogyan. Nem tudod milyen erőforrást használ és mennyit. Ahol számít, ott jobban jársz a saját kóddal, mint egy alapvető feladatra felhasználni egy akárhogyan megírt könyvtárat.

Bár fogalmam sincs, hogy miről van szó, de a 8-as maradékot szerintem a 7-tel való ÉS kapcsolattal is megkaphatod.

Sziasztok.

Ezt átnézni valaki, hogy lát -e benne hibát?

7 nyomógomb
6 Kimenet
MCP2307 I2C port-bővítő
Ezek 3.3V-ról mennek.
Egy Nextion kijelző (5-3.3v szintillesztéssel)

A másik oldalon egy arduino nano 33 IOT lesz (ez 3.3V-os) ezzel kommunikál a port-bővítő.


A linken ott van pdf-ben is, mert lehet az oldal lerontja a kép minőségét.

https://www.dropbox.com/s/0tmjs0pozfj83bo/ext.pdf?dl=0



Köszönöm.

Az U$1 és az U$8 milyen IC-k? Ha 78xx típusú stabilizátorok, akkor a kimenetükön ne legyen csak 4.7 - 10 µF-os kondenzátor, kivéve ha az adalap (más típusú IC esetén) másként nem nyilatkozik.

Szia.

Az egyik L7805 a másik LD33, (dpak mind a kettő) adatlap alapján teszek oda akkor kondit.

Abban az elrendezésben ahogyan te használod, LD33 esetén 10 µF van az adatlapban, 7805 esetén pedig 100 nF. Utóbbinál, ha nagy kapacitású terhelés van a kimeneten, kell egy védődióda is, különben a nagy kondenzátor tönkreteszi az IC-t.

Rendben, a többi része szerinted megfelelő?

Ha a portbővítő nem használt lábait (A7, B0 és B1) kimenetnek állítod be, akkor feleslegesek a felhúzó ellenállások. Ha a Q1 - Q6 FET-eket nem akarod gyorsan kapcsolgatni (másodpercenként többször), akkor jó de a 10 kΩ-os felhúzókat inkább cseréld le 1 kΩ-os ellenállásokra, gyorsabban fognak lezárni a FET-ek.

A 10k-s felhúzók a bemeneten szerintem hatástalanok, mert a LED és az ellenállása kisöntöli.
L03-mal sorban 10k van, gondolom, 120R-t akartál.
A kimeneteken elég erős FET-ek vannak. Érdemes kiszámolnod, hogy kikapcsoláskor mekkora disszipáció keletkezik, azaz a 10k elég gyorsan süti-e ki a gate kapacitást.
Az UART szintillesztőhöz szerintem nem kellenek FET-ek, de konkrét adatlapot kellene nézni. Az első kijelző, amit a gugli kidobott, megérti a 3V-ot magasnak. A másik irányhoz meg elég egy feszosztó.