Nem inkább ln()-t kellene használni? Bár lehet, hogy a log() is ln(), mindenesetre nem árt kipróbálni, hogy biztosan így van-e.

Igen, a MikroC fordítóban a log(); függvény a természetes alapú logaritmus.

Kovidivi: Ez könnyebbnek és pontosabbnak tűnt, így ezt a megoldást választottam. Igaz, könnyű már nem lett, de nem szeretném félbehagyni.
A tippet köszönöm, később jól jöhet.

Valami nem stimmel az α, β és γ paraméterekkel, mert ha ezeket beírom egy számológépbe, akkor megkapom a 130.524-et, mint te is.

Itt más paramétereket írnak, ezeket és a 8900-at behelyettesítve 300,83-at kapok, ami ugye 27,7 fok, az nagyjából stimmel.

Így lehet linearizálni az NTC-n mérhető feszültséget: Bővebben: Link Csak érdekességként.

Jelen esetben mindegy, hogy uint, vagy int, de igaz, hogy int.
Lehet, hogy felesleges a (float) prekonverzió kérés, de ártani nem árt, az eredmény helyes lesz, valószínű a fordító nem veszi figyelembe, mert úgy is megtenné, ha nem kérném. De aki kevésbé jártas a fordító típus konverzióival(mint én is), biztosra megy.
A zárójelben teljesen igazad van, azt nem láttam meg!

Van valami oka annak, hogy ennyi floatot használsz? 8bites PIC-ekben a float műveletek felzabálják a memóriát. Egyszer egy 16F627A-t teleírtam egy matematikai művelettel... A felvázolt feladatot fixpontos egész számokkal is meg lehet oldani.

Köszönöm mindenkinek a segítséget.

potyo:A paramétereket egy a gyártótól származó excel makró generálta a part number alapján, ezért gondoltam hogy azzal nem lehet gond. Ezek szerint valamit elnéztem. Ha a linkelt paramétereket használom, gondolom nem nagyon lövök mellé.

Kovidivi:Köszönöm, ezt elmentem későbbre, még jól jöhet.

Wezuv:Minden segítséget szívesen fogadok. Hogyan oldhatom meg fixpontos számokkal?

Az mindegy, hogy jelen esetben mindegy-e, az a lényeg, hogy ha valakinek magyarázod a programozást, akkor magyarázd jól, ne vezesd félre.
Az nem baj, ha biztosra mész, de attól még tudni kell, hogy mikor milyen konverzió történik, mert különben nem tudod, hogy mit csinál a programod. Ezért írtam le. Ha itt kiírod a (float)-ot, mert nem vagy benne biztos, hogy megcsinálja magától, akkor abban sem vagy biztos, hogy máshol milyen konverziókat csinál, és így elég nehéz előre kiszámítható viselkedésű programot írni.

Szerintem az a probléma a számításoddal, hogy a gyártó a négy paraméteres Steinhart-Hart képlethez adta meg az adatokat: 1/T= A + B*ln(R/Rt) + C*ln(R/Rt)² + D*ln(R/Rt)³
Az egyszerűsített képletben a C=0, de akkor tolódnak a paraméterek.
Itt lehet ellenőrizni: Bővebben: Link

Valóban ez volt a probléma, figyelmetlen voltam.
Közben találtam egy kalkulátort, ami 3 hőmérséklet és a hozzá tartozó ellenállás értéket megadva kiszámolja az együtthatókat. Ez alapján korrekt eredményeket kapok.

Kérdésem mi a hiba a fordításkor ezt írja ki az MPLAB IDE
Executing: "C:\Program Files\HI-TECH Software\PICC\9.81\bin\picc.exe" -C -E"LCDTERM6.cce" "LCDTERM6.c" -O"LCDTERM6.obj" -Zg9 -O -ASMLIST -Q -MPLAB -16F84A
(924) missing argument to "-O" option
Halting build on first failure as requested.

Egy program nem attól lesz jó, hogy pontosan ismered a fordító minden porcikáját. Ettől még igazad van természetesen a kérdéses ügyben elvileg. A gyakorlat árnyaltabb...

A második -O után nincs állománynév.

Harminchárom év gyakorlati tapasztala alapján ki merem jelenteni, hogy a gyakorlat annyiban árnyaltabb, hogy kisérletezéssel is lehet eredményt elérni, de ha tudod, hogy mi miért történik, akkor hamarabb készülsz el a munkával, és biztos lehetsz benne, hogy működik. A programozás elég egzakt tudomány, egy program a gyakorlatban is pont azt kell csinálja, amit az elméletben.

Sziasztok!

XC16 -ban írt programom optimalizáció nélkül rendben teszi a dolgát, optimalizálva nem. Addig rendben, hogy a megszakításokban is módosított globális változók volatile előtagot kapnak, de mi a helyzet a mutatókkal (a főprogramban)?
Ha van például egy globális változóm, amit a főprogramban (értsd: nem megszakításban) csak indirekt címzéssel használok (mutatókkal), akkor a fordító nem fogja kioptimalizálni, (pl. nem is foglal neki helyet a memóriában) mivel azt látja hogy csak deklarációkor kap értéket, és "a" néven nem is hivatkozok rá sehol?

Globális változót a C fordító semmiképpen nem optimalizálhat ki, mivel nem tudja, hogy másik file-ból hivatkozol-e rá. Ezért globális. Szóval a helyet mindenképpen le fogja neki foglalni.

Ez eddig ok, akkor helyet biztos hogy lefoglalja neki. De nem világos, hogy a főprogramban pl. a vizsgálatot már kioptimalizálhatja-e, ha látja, hogy sehol sem kap más értéket "a"? Nem fogja vizsgálat nélkül úgy tekinteni, hogy mindig teljesül?
Mert mondjuk "a" csak így kap más értéket a főprogramban:

Ha van a foprogramodban olyan fuggvenyhivas, ami nem az adott file-on beluli fuggvenyt hiv, akkor a fordito nem tudhatja, hogy a hivott kulso fuggveny megvaltoztatja-e a globalis valtozodat, ezert nem optimalizalhatja ki a hozzaferest sem. Olyat kioptimalizalhat, hogy pl:

Ebben az esetben megteheti, hogy "a"-t csak egyszer olvassa fel a memoriabol, mert tudja, hogy a ciklustorzs nem valtoztatja meg az erteket. A te pelddadban nem kell eszrevennie, hogy te ezzel az "a" valtozot valtoztatod, tehat igen, kioptimalizalhatja az olvasast, ha csak ilyen formaban kap erteket a valtozo és nincs kulso fuggvenyhivas.

Az ilyen esetekre valo a volatile, amivel garantalod, hogy nem fog semmit kioptimalizalni az adott valtozoval kapcsolatban.

Barmirol is legyen szo, elarulod, hogy miert kell neked egy int pont a 0x110e cimen?

Azt hiszem értem... tehát az én példámnál maradva, (ha nincs külső függvényhívás, (bár van, csak szeretném megérteni a dolog menetét) tehát tekintsük úgy, hogy nincs) simán kihagyhatja az "a" összehasonlítását 10-el.


Hát persze!
Egy régen asm-ben írt programomat ültetem át C -re. Asm korszakomban egyértelmű volt hogy PC -ről bele tudok nézni a PIC memóriájába úgy, hogy elküldöm a memóriacímet, és a PIC visszaküldi a tartalmat. Ezt C-ben gondolom nem így kéne csinálni, de az egész asm- ből jött, és igyekszem a legkevesebb ponton változtatni a logikán.
Ja és persze PC -ről írni is tudok a PIC memóriájába.

A dolog vegtelenul egyszeru. Csak azt optimalizalhatja ki, ami nem valtozhat a program futasa soran. Azt tudni kell, hogy egy valtozo cime csak az & operatorral eloallitva tekintendo a valtozo cimenek, tehat "az en tudom, hogy a 0x1234 cimen van, ezert oda irok" jellegu atirasokkal a C fordito nem szamol, ahogy a megszakitasban torteno atirasokkal es a DMA, vagy egyeb hardware okozta memoria valtozasokkal sem. Ezeknel a valtozoknal kell a volatile, ahogy a PIC osszes regisztere annak van deklaralva. De ha te atadod egy valtozo cimet egy fuggvenynek, akkor a fordito feltetelezi, hogy a hivott fuggveny megvaltoztathatja a valtozot, kiveve, ha a hivott fuggveny const pointert var. Ilyenkor lehet tudni, hogy a hivott fuggveny a kapott pointert csak olvasasra fogja hasznalni, irasra nem.
Nos, a valtozok ilyen formaban torteno atirasa PC-rol valoban nem szokvanyos dolog C-ben, de szerintem assemblyben sem, mivel a valtozok cimet a linker tudja egyedul, senki mas. Ezert sokkal biztosabb dolog valami mas modon azonositani oket kulso kapcsolat eseten. Persze ha a program 4 sor es ket valtozoja van, akkor tok mindegy, de komolyabb programoknal ez eleg veszelyes modszer.

Értem amit mondasz, és érzem is hogy C-ben ez nem szép így, de azért csak számíthatok arra, hogy ha azt mondom a linker/fordítónak "__attribute__((address(0x110E)))" akkor az ott is lesz.
Köszönöm a segítséget.

Szia!

Idézet:
„Nos, a valtozok ilyen formaban torteno atirasa PC-rol valoban nem szokvanyos dolog C-ben, de szerintem assemblyben sem, mivel a valtozok cimet a linker tudja egyedul, senki mas.”

Kivéve, ha abszolút módban írod az asm-et és nem relokálhatóba, mert akkor te osztol ki mindent és ez sem "ördögtől" való !

Biztos. En mar 1982-ben is ugy irtam az assemblyt, hogy voltak a valtozok, es az assembler szamolta ki a cimeket. Azt en mondtam meg, hogy hol kezdodnek a valtozok, de, hogy melyiknek pontosan mi a cime, azt nem en szamoltam ki:

1. org 800h
2. buffer: ds  10
3. text:    db 'Szoveg$'
4. var1: dw 1234h
5. var2: dw 0

Úgy is lehet, meg általában jó is !

Szép napot mindenkinek!

A kérdésem/problémám nem kimondottan a PIC-ek C nyelven való programozásáról szól, inkább csak szárazon magához a C nyelvhez kapcsolódik, így ha az alábbi problémát rossz helyre írtam, úgy előre is elnézést kérek!

A hibám egy bitstruktúrával kapcsolatos, amit egy fejlécállományban definiáltam, és ezt a struktúrát szeretném több forrásállományban használni (egyikben változtatom az adott elemek értékét, egy másikban pedig csak vizsgálom, hogy milyen értékű), de ezt nem engedi. Fordításkor azzal a hibával dobja ki, hogy az adott struktúra többszörösen van definiálva, amit azért nem értek, mert maga a definíció csak a fejlécállományban van, a forrásfájlokban természetesen nincs.

Segítségeteket előre is köszönöm!

Szia!
a header állomámyt szúrd be a következő sorok közé:
#ifndef _blabla_
#define _blabla_

definíció
definíció
definíció

endif

ekkor már nem fog kiabálni, hiszen bárhová csatolod a headert nem definiálódik újra.
Ha viszont egy adott változót szeretnél "látni" másik forrásban akkor az adott forrásban dekraláld újra de tedd elé az extern szót ez jelzi a fordítónak, hogy máshol van .

üdv.:Foxi

Link és a kettővel előtte levő hozzászólást is olvasd el

Szia!

Köszi a válaszodat, eddig úgy használtam, ahogy Te is leírtad, vagyis az egyik forrásállományban definiáltam, majd a másikban, ahol szintén használtam az adott struktúrát, ott is deklaráltam, így természetesen működik is.

Én csak azért gondoltam, hogy egy fejlécállományba deklarálom és definiálom, hogy ne kelljen ezeket a sorokat is beírni abba a forrásállományba ahol egyébként nem változtatom a struktúra elemeinek értékét csak figyelem őket.

Nagyon szépen köszönöm, erre gondoltam!

Az mindegy, hogy csak figyeled (olvasod) vagy írod is egy változó értékét, a változót attól még deklarálni kell. Azt szokták még ilyenkor csinálni, hogy a header-be beleteszik a struktúra definiciót és az extern deklaraciót is. És valamelyik forrás.c-ben pedig van a változó tényleges deklarációja.