Az hogy lehet, hogy az eredmény 171798608 ?

A 32 bites float-ban 1bit előjel, 23 bit mantissa, 8 bit exponens található. Simán lehet, hogy a 23 bites mantissa részbe nem fér bele ennél nagyobb pontosság.

Az nem megoldás, hogy a vezérlőt ráhekkeled a távirányítóra? Mintha te húzgálnád a karokat.

Az a baj, hogy ha double típus, akkor is ezt csinálja...
Nekem is olyan érzésem van, mintha mindenáron csak float típusig "látna", és emiatt van a jelenség.

Hali!
Én kerülöm a float változókat nagy ívben. Ha belefér a számábrázolásba akkor valami egész tipusban tárolom a 10, 100-szorosát (a pontosságtól függően), azzal számolok, megjelenitéskor meg figyelek hogy "hol legyen" tizedespont.

Ezt szoktam én is alkalmazni..., főleg kiírásnál könnyű így szöveggé alakítani! )
De itt ezt nem lehet, mert a teljes 32 bites értéktartományra szükség van.

Már így is szét kellett faragnom két részbe az egész és tizedes számokat, mert a nyomi arduino String osztály függvényei megállnak a float hossznál. Pedig ott vannak a double függvények is benne, de pont az a probléma kb, mint a példámban!

Így is van: arduino.cc/reference/en/language/variables/data-types/double/

Van olyan, hogy long long ebbe sem férsz bele?
Sajna nem minden támogatja, pl ami régebben nekem nem ment a serial.print-ből

innen meríthetsz ötletet az adattípusokról https://github.com/esp8266/Arduino/blob/master/tools/sdk/include/c_types.h

Igen, van olyan 64 bites típus..., de az arduino honlap alapján azt még csak meg sem említik! Ki nem próbáltam, hogy implementálva van e, mert ahogy említettem, már kapásból szét kellett szednem a számot egész és tört részre. Ettől kezdve, amint kiderült, hogy az Arduino csak a megánál ismeri a double(64 bites) típust, darabokból raktam össze a számot 32 bites egésszé. Így működik jól...

úgy látom használatban van a long long pl itt a define: \hardware\tools\avr\avr\include\stdint.h -ban, de használhatod direktben az int64_t

typedef signed long long int int64_t;

/** \ingroup avr_stdint
64-bit unsigned type.
\note This type is not available when the compiler
option -mint8 is in effect. */

Valójában önmagában egy 64 bites változó nem segít azon, hogy szöveges formában érkezik egy szám. Ezt nem tudod már a String osztály függvényein keresztül kezelni, csak float méretig! Innentől kezdve meg vagy lőve..., csak darabokból lehet összerakni float-nál nagyobb felbontást... Itt nem az abszolúte érték ami számít, hanem az ábrázolható pontosság, ami kell ahhoz, hogy legalább 32 bites szám minden számjegye ábrázolható legyen.
Viszont, nem kizárt, hogy később 40, vagy 48 bites számra szeretném kiterjeszteni..., akkor jól jön még a 64 bites változó használhatósága...

Hali.

A long-ba beleférne, csak az egész típus. Te meg nem azt adtál neki.

A floatba nem férne bele?

"float (32 bit) - signed number from -3.4028235E38 to 3.4028235E38. Floating point on the Arduino is not native; the compiler has to jump through hoops to make it work. If you can avoid it, you should. We'll touch on this later."

Simán, de felesleges ekkora szám. Főleg arduino-ban.

Áh, fáradt vagyok.

Inkább alszom egyet!

Ezt benéztem...

Azon gondolkodom, hogy nem létezhet valami szoftveres megoldás erre? Mint pl maga a String osztály sem az arduinó sajátja, hanem egy beépült könyvtár. Lehet nem vagyok egyértelmű. Szóval nem létezik olyan függvénytár ami saját adattípussal megoldja az extra nagy számok kezelését? Mindjárt utána nézek..

Esetleg ez? Bővebben: Link

Biztatónak tűnik! Majd ránézek jobban, ha lesz időm....

A Visuino próba félre téve. Pedig jó ötletnek tűnt!

Üdv!

Lenne egy kérdésem, hátha már találkozott valaki ilyesmivel.
A mikrokontroller egy ATmega328PB, az IDE 1.8.13, a kontrollert a MiniCore könyvtárral (próbálom) használom.
PCinterruptot használnék. A probléma ott van, hogy beállítom a regisztereket (PCICR, PCMSK2). Ha beérkezik a megszakítás, akkor a megszakítás, az ISR(PCINT2_vect) nem hajtódik végre, hanem befagy a program.
Hol hibázhatok? A kód amúgy sima 328P-vel MiniCore könytár nélkül működik.

Vizsgálgatva a kapcsolatos dolgokat, a /usr/lib/avr/include/avr könyvtárban nincsen iom328pb.h nevű fájl. Ez okozhatja a hibát?

Ez biztosan nem, mert ha nem tudná összelinkelni a fordító, akkor le se tudná fordítani. Tehát minden rendelkezésére áll..., max valami érték(pl cím) nem jó...

A működő rendszerben, ha bekapcsolom a megszakítást, de nem csinálom meg hozzá az ISR-t, akkor ugyanígy befagy a program a megszakításkor.
Fel van adva a lecke.

Ebben van valami....! De akkor nem lehet, hogy ez a megoldás is?! Hogy hiányzik a megszakítási vektor, vagy nem jó címre van definiálva?! Az LGT-nél láttam ilyet...

Az ISR-t megírtam. De nem hajtódik végre. Most neki kell futnom annak, hogy miként kell egy ilyent címezni, stb. Ilyennel még nem szenvedtem. Az LGT-nél is 1-2 hónap volt, mire a timer3-at beüzemeltem...

Az még nem biztos, hogy elég hozzá! Címet kb így rendelhetsz hozzá:

Amit nem tudok egyenlőre, az az, amit az 1. sorban írtál.

Az egy általános forma, 2,3 sor meg egy konkrét példa rá.
A nevet te adod meg neki, a megszakítási címet viszont valahonnan ki kell derítened! Atmeganál ez nem lehet probléma, jól dokumentált...

Sajnos, mint éjszaka kiderült, a hiba egészen más és cifrább. A készüléken van egy I2C-s karakteres LCD. Ha leforrasztom, akkor végrehajtja a megszakítást. Ha visszateszem, akkor belefagy.

Ha az I2C-s LCD kezelések előtt letiltom a PCinterruptot, akkor működik, nincsen fagyás. Valahogyan összeakad a PCinterrupt és az I2C LCD?

Valószínűleg az IIC is interruptot használ. Mit csinász a megszakítás rutinban? Definíció szerint csak egy rövid ideig futó, interruptot nem használó kódot szabad futtatni. Ezt a szabályt is át lehet hágni, de ahhoz fel kell készülni alaposan.