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

Nálam XC16-ba került, nem néztem meg mit optimalizál belőle az ingyenes verió , de kipróbáltam az eddigi funkciók működnek volatile nélkül is. Persze vele raktam a volatile-t mivel később valószínűleg megszakításban s lez használva.

Sziasztok!
Tápfesz megszűnése esetén szeretném menteni egy port aktuális állapotát beépített EEPROM-ba, megszakítással.
Az EEPROM-ba írást tehetem megszakításba közvetlenül, vagy nem célszerű?

Én oda tenném.

Szia.
Arra nem árt figyelni, hogy lehetőleg 5V legyen a tápfesz, és lehetőleg ne menjen gyorsan 0-ra le, mert nem fogja tudni végrehajtani az EE írást.
Sajnos már jártam így.

Nem az a lényeg, hogy hány V a táp, hanem az, hogy az előállítása(nyers tápfesz, regulátor, kondenzátor kapacitások, esetleg a PIC felé külön leválasztott tápág) megfelelően legyenek méretezve.

Igaz. De ha mégsincs elég puffer, akkor gyorsan esik a fesz...

Köszönöm a válaszokat, akkor ott marad.
7805 stabilizátorral van előállítva a táp, jelenleg egy 680µF-os pufferral kísérletezek.
A HLVD feszültségfigyelő regiszter segítségével generálok megszítást. (PIC18F87k22)

Sziasztok. Egy valós számot kell kijeleznem hétszegmenses kijelzőkön normálalakban. A szám legyen pl: 0.0005412345 . A kijelzőn ennyit szeretnék látni: "5.4 -4". A kitevőt megtudom határozni, de hogyan lehet a számot külön számjegyekre alakítani? Létezik erre függvény?, vagy egyéb módszer? Köszönöm.

C: printf("%e",float_var); // Ha ismeri a C.
Na nem ismeri:
A számot megvizsgálod, hogy kisebb-e mint 10.
Ha kisebb, elkezded szorozni 10 -zel, addig , míg 1 és 10 közé nem esik, számolod a szorszások számát.
Ha nagyobb, elkezded osztani 10 -zel, addig , míg 1 és 10 közé nem esik, számolod a osztások számát.
kiírod az egész részt egészként.
Pont kiírása.
A törtrészt megszorzod 10 annyiadik hatványával, ahány tizedes jegyet szeretnél, az eredményt kiírod egészként.
Ha szorozni kellett akkor "E-" kiiratása, ha osztani kellett, akkor "E+" kiíratása.
A számolt szorzások / osztások számának kiíratása.

Hát.. A C ismeri A kérdésben nem szerepelt C fordító megnevezés. Vagy azt mondod, hogy egyik PIC C konyvtar sem ismeri a %e-t?

Talán csak néhányan lennénk, akik assemby -ben számolnánk lebegőpontos számokkal. Így feltételeztem, hogy magas(abb) szintű nyelvet használ... Mivel a topik címében a Microchip szerepel, ezekre a fordítókra koncentráltam... Hiába ismeri az AVR ill. a ARM fordító, ha PIC -re kell a megoldás.

A

Idézet:
„Létezik erre függvény?”

nekem is a C-t sugallja !

Köszönöm, megpróbálom.

Felreertesz. En csak annyit kerdeztem, hogy egyetlen PIC-es C konyvtar sem tamogatja a %e-t. Mert ez nem C fordító, hanem könyvtár kérdése. Kiprobaltad vagy megnezted, hogy pl. a pic32-hoz jaro library-ben mukodik-e a %e? Szoval igazabol arra lennek kivancsi, hogy mibol vontad le azt a kovetkeztetest, hogy a (PIC) C nem ismeri a %e-t. De ez puszta kivancsisag, nem kotekedni akarok.

Ezekből a leírásokból:
XC8 V1.33: (DS50002053D) szerepel benne a %f és a %e -is.
C18 V3.47: (hlpC18Lib.chm) nem szerepel benne az egyik sem.

Akkor mégiscsak ismeri. Legalább is az XC8. A masik meg semmilyen lebegopontos kiirast nem tamogat. Ezt mondjuk meg is ertem. Nekem van olyan konyvtaram ARM-hez is, amiben egy direkt csokkentett tudasu printf is van, pont azert, mert felesleges a kodot novelni olyannal, amit egyebkent nem hasznal az ember. Marpedig a lebegopontos aritmetika az eleg huzos cucc. Egyszer 25 eve en is hasznaltam 68HC11 mikrokontrolleren (assembly-ben irtam meg az egesz float aritmetikat), de ma mar egesz biztos, hogy 32 bites fixpontos aritmetikaval oldanam meg az adott feladatot. Es minden kezdot is arra biztatok, hogy mikrokontrolleren ne hasznaljon lebegopontos szamitast, mert lassu, nagy, es a legtobbszor teljesen felesleges.

Hello!

Egy kis magyarázatot kérnék, mert már nem tudok gondolkodni a pipától.
Ha egy unsigned long változtót belepréselek egy unsigned int-be akkor miért 32768-nál száll el és miért nem 65535-nél? (XC16)
Egy órát szívattam magam mire rájöttem mi baja, de ha 65535-nél szállt volna el akkor rögtön tudom. Tudtam , hogy a típuskonverziókkal van baj, csak azt hittem valhol számításoknál szállt el.

Szia!
Nem szabad elszállnia, a tipuskonverziónak jónak kell lennie.
Esetleg Használj uniont, ekkor nem kell tipuskonverzió .
(GenericTypedefs.h )

Egesz pontosan mi a problema?

Egész pontosan a következőt követtem el.


T3 megszakításban ez van:


A 6. lépésig azaz amikor a "b" 30000 lesz úgy működik ahogy kell.
A 7.-nél nem egyet ugrik hanem rögtön felszalad a 10. lépésig, vagyis csakis 32768-nál szállhat el.
Igaz elfér 16 bitben a "b" max értéke, de korábban 200000 volt azért maradt long.
Azt nem értettem miért 32768-nál van gond miért nem 65535-nél.

Oszinten szolva nem egeszen ertem, hogy mit jelent a 6. es 7. lepes. De mondjuk feltetelezem, hogy (v * 500 ) az 5000 akart lenni, csak valamiert hianyoznak a nullak.

A (v * 5000) kifejezes meger par sort: A 'v' unsigned char, tehat eleve 'int'-kent kezeli a fordito. Az 5000 szinten 'int'. Ezert a szorzas eredmenye is int lesz, tehat -32768 es 32767 kozotti erteket vehet fel. A 7 * 5000 az mar negativ ertek lesz, ahogy te is kitalaltad.

Szerintem az lesz a megoldas, ha az 5000 helyett 5000u-t irsz. Ekkor az 5000 'unsigned int' lesz, es ezert a 'v'-t is unsignedre fogja alakitani, es a szorzas eredmenye is unsigned lesz.

Igen az 5000 volt, csak azóta módosítottam egy kicsit és azt sikerült beírnom.
Ami a "v"-t illeti igazad van, rá is jöttem később csak nem javítottam már tegnap, viszont amit csináltam az, hogy ha v-t úgy hagyom uchar-nak és a "b"-t unsigned int-nek deklaráltam így is jól működött, ez nem fért már a fejembe miért. Közben már táblát is vettem fel, úgyhogy mindenképpen át kell néznem hol, mi minek van deklarálva. Ami az 5000-et illeti szerintem úgy hagyom, a "v"-t uint-nek deklarálva jó így is, és különben is lehet, hogy 500 marad a végén, vagy csak 50, a táblától függ majd. Mindenesetre kösz a magyarázatot.

Még egy dolog. Emlékeim szerint az XC16-ban ellentétben a 8 bites foordítókkal az unsigned az alap és a signedet szokták jelölni, persze lehet, hogy keverem már valamivel. Tehát ez volt a másik ok amiért értetlenkedtem.

Azert, mert ha 'b' unsigned int, akkor a (v * 5000) eredmenye int-ről unsigned int-re lesz konvertálva, ami valojában semmi, mert marad 16 bit. Ha viszont 'b' unsigned long, akkor a (v * 5000) szorzas eredmenye is át lesz alakitva unsigned long-ga. Ha v = 7, akkor az eredmeny 35000, azaz 0x88b8, ami long-ra konvertalva 0xffff88b8.

Ha v-t nem unsigned char-nak, hanem unsigned int-nek deklaralod, akkor szinten jol fog mukodini, mert akkor a szorzas eleve unsigned lesz, mivel 'v'-bol nem csinal int-et a fordito.

Ez is világos.
Közben utána néztem utolsó kérdésemnek és mint kiderült valamivel kevertem.
XC16 manual:

Pedig tuti, hogy valamelyik fordítóban ez fordítva működik, csak már nem emlékszem hol.

A C nyelv definicioja (C11) szerint a sima short, int, long es long long az mindig signed. A char eseten a C fordito szabadsaga, hogy signed vagy unsigned lesz. Az explicit modon kiirt signed char es unsigned char megint egyertelmu. Egyes forditoknal parancssori opcioval lehet kivalasztani, hogy a sima char elojeles legyen vagy nem.

Igen, így kéne, hogy legyen. Mondom már nem emlékszem honnan rémlik, még az is lehet, hogy nem C, bár szerintem a basic-ben is így van. Mindegy is. Frissítettem a memóriámat ezzel az infoval is.

CCS fordítóban alap az unsigned

Tudtam, hogy valamelyikben az az alap. Köszi a megerősítést.

Mire alap az unsigned? Mindere vagy csak a char-ra?