Meg lehet csinálni, bár egyfelől nem értem, mire kell egyáltalán a float típus, másrészt úgy érted, hogy a több byte-os típusokat byte-okra bontani? Mert arra tökéletes a union. Pl.:

A Te verziód nem működik megfelelően. Az union-nak az a speciális tulajdonsága van, hogy a benne szereplő elemek azonos memóriaterületen vannak tárolva, így amikor Te az f0-nak adsz értéket, egyben az f1-nek is ugyanazt az értéket adod.

Igen úgy értem, mert eddig csak 2 byte-os számot tudtam kiküldeni bit tologatás révén, több byte-osnál nem jöttem rá, hogy lehetne a középső byte-okat is kinyerni könnyedén, de így már akkor egyszerűnek hangzik.

(#1264502) El_Pinyo:
De az f0 meg az f1 csak 1 bit méretű. Könyvben én úgy értelmeztem, hogy csak byte-nál ugyanaz, tehát 1 darab 1 byte-os változó deklarálásánál még működne, nem?
*

És, hogy válaszoljak egy jó kérdésedre, mert valószínű azt szeretnéd elérni, hogy egy lebegőpontos számot elküldjél a soros porton bájtonként:


(A PC-n összerakni nehezebb, de az más téma.)

Viszont átszaladtál azon a ponton, hogy miért is használsz float-ot...
Mert szerintem extrém ritka dolog az, amikor egy 8-bites mikrokontrollerben érdemes float típust használni (nekem még konkrétan nem volt ilyen esetem a pályafutásom alatt).
És mielőtt megkérdeznéd: fixpontos integert kell használni helyette.

Szia! Én műszerekhez szoktam lebegőpontosat használni akkor, ha polinom együtthatókkal kell számolni a kalibrációnál. Nem okoz gondot egy PIC-nek polinomsor kiszámítása. Sokkal bonyolultabb lenne konvertálgatni fixponotossá, főleg ha soros porton keresztül egyszerűen akarjuk feltölteni az együtthatókat. Legalább is nekem így tűnt egyszerűbbnek.
A kérdésed ugyanakkor jogos, mert nem tudjuk ő mit akar...

*
A jó kérdés az volt, amit El_Pinyo-nak tettem fel, ezt már _vl_ is megválaszolta, de köszi

Játszásiból.
Nem gondoltam volna, hogy ennyire érdekel.
Egyébként szabályozást tervezek.
Bevallom őszintén még nem volt dolgom fixpontossal, így utána kellene néznem hogy is van az. PC-re való programozáskor mindig float-tot használtam, így ezt találtam egyszerűbbnek itt is.
A program még csak kezdeti fázisban van, lehet nem is kell majd float. Csak most jó lenne kiküldeni az értékeket a számítógépre vagy lcd kijelzőre, hogy lássam hol a hiba (az előbbi már megy, az utóbbi még nem).
Meg pár tört számot jó lenne állítgatni a számítógépről vezérelve (pl. hurok erősítést ami lehet, hogy csak 1,86), hogy ne kelljen mindig újra programozni az eszközt. De ha igaz, hogy ha valamilyen terminálon keresztül beküldöm például a 1,86-ot és azt még át kellene konvertálni fixpontosra, akkor jelen esetben a float egyszerűbbnek tűnik.

Alapvetően az a gond a float és hasonlókkal, hogy a(z egyszerűbb) kontrollereken nincs rájuk hardveres támogatás, emiatt szoftverből kell megoldani velük minden műveletet, ami egyrészt lassú, másrészt sok kódmemóriát foglal. A kódmemória méret még mondjuk tűrhető, mert ha már valahol van pl. két float szám összeadása, akkor másik kettő összeadása már nem fog sok plusz memóriát igényelni, viszont ha valamit sokszor kell kiszámolni, akkor ott már nagyon problémás lehet a float miatti lassúság.

PC-n más a helyzet, a processzorok már jó ideje tartalmaznak matematikai segédprocesszort, ami ezekkel a számokkal történő műveleteket is hardverből megoldja, így nem jelentősen lassúbb a kód, bár azért ott is illik egész típusokat használni ahol lehet, mert azoknál nem jönnek elő a számábrázolási problémák, kerekítések, stb. De kontrollereknél, főleg ha valamit sokszor kell számolni, ott érdemes valamilyen egész típust használni.

Terminálon hogyan küldöd át az 1,86-ot? Küldesz egy egyest, vesszőt, nyolcast és hatost? Mert akkor küldhetnél 186-ot, és akkor a kontrolleren meg akár egész típusokkal elvégzed a műveleteket, majd a végén elosztod százzal az eredményt.

Tudom, hogy lassabb a művelet végzés vele, de még nem forrott ki teljesen a kód, szóval biztos fog még változni minden. A szorzás/osztáson én is gondolkodtam, de ma még nem volt időm tesztelgetni. Jó lenne még egy saját terminálos progit is írni, csak ezt a visual basic-et kellene áttanulmányozni...:-/

Szerintem kezdjed ezzel, aztán rájössz, hogy a világ legegyszerűbb dolga. Tényleg vannak esetek, amikor a float a helyes választás, de ritka, mint a fehér holló.
Alapvetően a PC-d kb. 1000x gyorsabb integer műveletekben, és kb. 100.000x gyorsabb float műveletekben, mint egy PIC. Ami számítást csak tehetsz, tolj át a PC-s oldalra (majd ott dolgozik a CPU).
Sajnos egy 8-bites mikrokontrollernél a lehető legritkább esetben teheted meg, hogy abszolút nem foglalkozol vele, mi mennyi idő alatt hajtódik végre. Ez túl nagy luxus, amit csak a GHz-es CPU-k programozói engedhetnek meg maguknak

Már elnézést, de senki nem válaszolta ezt meg eddig, ha azt hiszed igen, nem értesz még pár dolgot...

Megkérhetnélek, hogy csatolsz pár fixpont kezelő C rutint, hogy lássam hogy is kell ezt elképzelni?
Írtam egy 32 pontos FFT-t egy 16LF1638-ra és hát ráférne egy kis gyorsítás... Épp át akarok térni 24F-re, de megpróbálkoznék még a fixpontos számábrázolás használatával, hátha azzal nyernék egy kis plusz erőforrást, mert igazából a 24F-et nem használnám ki rendesen.
Előre is köszi bármilyen segítséget!

Diablo és watt! Könyörgöm, privibe! Privibe! Köszi!

Rosszul értelmezted. Próbáld ki szimulátorral, watch window segítségével. Ott láthatod, hogy a nem módosított union tag is módosul.

Mplab-bal nem tudom hogy kell megnézni de megnéztem más szimulátorral a regiszter tartalmát és tényleg ugyanaz az összes bit.
Természetesen struktúrával működik szépen a bit állítgatás is. Köszi a választ!

Őket neked kerestem: Bővebben: Link Bővebben: Link

Na volt egy kis időm az összes variációt kipróbálni köztük a tiedet és arra jutottam, hogy mind a 3 ugyanazt csinálja.

_vl_ ezt válaszolta meg, csak annyit változtattam rajta, hogy az unsigned char-t float-ra írtam és 8 bitesekre a byte-okat (ennyi még nekem is megy). Egy szóval ugyanaz, de ezt ránézésre is meg lehetett mondani. A változókat kicserélni meg bárki kitudja.

De mégis a legkézenfekvőbb megoldás a struktúra nélküli union amikor egy union-ban hozzuk létre a változót és mellette egy 4 elemű tömböt. A hivatkozás is sokkal egyszerűbb.

Köszi a linkeket! Feltétlen megnézegetem őket.

Miert jobb neked amugy a bitfield mint a karakter tomb?

Én nem mondtam hogy jobb, jelenleg is azt használom amit beszúrtál most kódot.
Kivéve 1db flag byte-hoz amihez struktúrát használok. Vagy azt is lehet unionnal? pl. bit[8] : 1 is érvényes kód lenne? 8 elemű 8 bites tömböt is lehet létrehozni? Még nem próbáltam.

A union arra való, hogy ugyanazt a memóriaterületet többféleképpen érhesd el (mondjuk bitenként is, meg byte-ként is). Azaz a unionban felsorolt mezők mind ugyanott (egymás hegyén-hátán) laknak a memóriában.
A struct mezői (bitek, byte-ok) egymás mellett laknak a memóriában. Tehát ha az a célod, hogy legyen 8 külön címezhető bited, akkor azt csak struct-tal tudod megcsinálni, mert ha unionba raksz 8 bitet, azok mind ugyanabban az egy szem memóriabitben fognak lakni.

Tombot bitekre nem lehet letre hozni. Arra jo a bitfield. Amit irtam kodot csak azert irtam, mert ugy veltem ez neked arra kell, hogy a float valtozod egyes byte-jaihoz hozza ferhess, hogy azt at tudd kuldeni a soros vonalon.

A bit fieldet akkor szoktam kerulni, ha erdekes melyik bitet hova pakolassza. Ugyanis a C szabvanyban nincs definialva hogyan kell azt csinani. Egyes forditok optimalizalnak -- pl. PIC-nel az also ill felso 4 bithez (nibble) egyszerubb a CPU-nak hozza fernie, emiatt nem tartom elkepzelhetonek, hogy a

eseteben a 'byte1' mezo nem kozepen lesz, hanem legalul vagy legfelul. Van olyan compiler ami nem csinal ilyet, masok meg csak azzal vacakolnak, hogy a byte0 az most a 0. biten vagy a 7. biten van-e -- kvazi mint az LSB/MSB tarolasi problemak tobb byte-os adat strukturak eseten.

Azt a struktúrásat csak watt kedvéért próbáltam ki.
Viszont a 2. bekezdésed nem teljesen világos, hogy mire akarsz kilyukadni, de most szerintem számomra az nem is olyan fontos.

Idézet:
„Viszont a 2. bekezdésed nem teljesen világos, hogy mire akarsz kilyukadni, de most szerintem számomra az nem is olyan fontos.”

Mindegy is, lenyeg, hogy ha csak lehet en kerulom a bitfield-et, mert mikor egyszerre fejlesztettem 10 kulonbozo platformra akkor nagyon meggyult vele a bajom. Ha csak egyetlen kornyezetre fejlesztesz es nem cserelgeted a forditokat sem akkor valoszinuleg nem is fogsz ezekkel a problemakkal talalkozni.

Helló,

PIC32-ben ez miért nem működik?



Valami miatt 0 értéket ad vissza a debugger tmp_float értékre.

Mi lehet a hiba?

Hát, mondjuk az integer osztása integerrel, ez minden C fordítónál integer osztásra fog lefordulni (ettől még nem 0-nak, hanem 5-nek kéne lennie az eredménynek)...

Másrészt a debuggerrel nekem voltak gondjaim, gyakorlatilag teljesen megbízhatatlan, amikor a változók értékét kéne megmutatni.

Szia,
Egy tipp:
A C fordítók a konstans kifejezéseket fordítási időben értékelik ki, eszerint a 100/1024 =0.
Igy a
tps_value = tps_ad_value * 0 lesz.
Nem ellenőriztem le, szerintem nézz utána az assembly listában hogy tényleg így van-e jelen esetben.

Hogyan tudom, akkor elvégezni a műveletet?
Castolni mikor kell?

Szia!

- Zárójelezéssel:
tps_value = (tps_ad_value * 100) / 1024;
- Két lépésben:
tps_value = tps_ad_value * 100;
tps_value /= 1024;