Jól működik azt nem kétlem, de furcsálom a CRC szerinti előjelváltást.
A Makeint a leírás szerint egy 16 bites értéket csinál két byte -ból (256 * MSB + LSB). A leírás nem terjed ki arra, hogy előjeles-e a számábrázolás (nincs fordítóm), de tegyük fel, hogy előjeles. Így a negatív szám elő is áll, hiszen a DS1820 adatlapja szerint a számot kettes komplemens kódban szolgáltatja és a Makeint is ebben várja.
Azért működik jól, mert a CRC eddig még sohasem volt 0. Ha a fenti feltételezés igaz (azaz a Makeint(255,255) megfelel a -1 -nek), ezt a három sort ki kellene törölni...

Azt nem vehetem ki, mert

és ha kiveszem akkor írhatom át az egészet hogy megkapjam.
Így az a jó hogy van egy függvény, meg szenzoronként 3 sor amivel meghívom a függvényt és meg vannak az értékek.

Nem azt a márom sort kellene kivenni, hanem ezt:

Ezáltal felesleges lenne az első paraméter (CRC) átadása is.

De hogy az Sc(9) elvileg sosem nulla, akkor csak az ifet kellene kivenni max, ami közte van az mehet fixen.
Nem? Nem tudok most próbálkozni én sem még mert otthon van a panel és még melóban vagyok, de délután megnézem.

A CRC a hőmérséklettel együtt továbbított 8 byte adatból készül. Elvileg van olyan adatsorozat, amivel számolt CRC kiadja a 0-t. Így a legjobb, ha az említett 3 sort elsőre csak kikommentezed. Mind a hármat.

tesztelem ezt a kütyüt...és azt vettem észre, hogy néha teljesen véletlenszerűen valamelyik hőm. értéket negatív előjellel jeleníti meg....rendszertelen a dolog mind a megjelenés mind a pozíció tekintetében....és csak egy frissítés erejéig tart.....

Kiszedtem, működik, de negatíval még nem tudom tesztelni csak holnap a hűtővel max.
De jó lenne ha lehetne bootloaderrel weben keresztül programozni...:S

A tizedes mérés..akkor hogyan is néz ki? Had tanuljak valamit!

Ahány program annyiféleképp lehet visszaszámolni a kapott két byte-ből. A lényeg hogy 3 féle eset lehet ha mindkettő 0 akkor 0 celsiusban is. Ha binárisan nézve az első négy helyi értéken 0 van akkor a maradék 12 helyi értékkel, meg lehet szorozni a 0.0625 fokcelsiust. Ha az első négy 1-es negatív előjelet kap a 1111 1111 1111 1111 -ből kivont kapott érték és ezt szorozzuk 0,0625 a kapott eredménynek lesz tizedes pont utáni része, ha megfelelő változók voltak használva. Azért van sokféle megoldás, mert a felső byte-t szorozva 256-al ehhez hozzáadva az alsó byte-ot decimálisan megkapjuk, amit szorozni kell 0,0625-el. De ha a felső byte-ot elosztjuk 16-al, az alsót megszorozzuk 16-al egyből celsiusban kapjuk. (1/16=0,0625)

köszönöm estére megnézem...

Amit küldtem mintát az tizedessel mér, csak mint mondtam a kijelzőre kerülő érték integerbe tölti vagyis egész számba, így levágja a tizedest.
A kérdés az volt hogy miért nem működik erre próbáltunk rájönni nem személyre szabott kódot adni... sültgalamb efektus..
Annyi a lényeg hogy ne integerbe kerüljön az érték a decigrades függvény végén.
pl:

és az ert értékét írod ki lcd re ami már a fusing eljárás által eleve meg is van formázva.
és itt az asd as single az ert pedig string*5.
Ja és azt hiszem a ki is kommentelheted ez esetben.

Ha működik, akkor a következő két sor is kivehető:
Decigrades = Decigrades * 10
..
Decigrades = Decigrades / 10
Így az egész rész ennyire zsugorodik:

Na hoztam fel fagyott zöldborsót tesztelni és a negatív irány működik szerencsére.
Azt nem vehetem ki viszont mert utána van egy 16 al való osztás is és a matek miatt ott dől a dolog.
Így pontos,

de ha kiveszem:

Mivel a decigrades nem single hanem integer és nem is tudom átpakolni így muszáj osztás előtt felszorozni hogy a tizedeseket ne vágja le.

helyett írj
Decigrades = Makeint(sc(1) , Sc(2)) / 16.0
sort

Nem jó, a Bascom 3 műveletet nem tud megcsinálni egy sorban.

azt hiszem..a bascommal lesz valami probléma...mert nem igazán akarja fordítani a dolgokat..pedig hibát sem jelez. az égető pedig a khazama.

Az mit jelent hogy nem akar fordítani de hibát sem jelez? Ha nem fordítja le akkor kiírja hogy mi baja van vele, ha nem írja ki akkor pedig lefordítja. Az nem tudom milyen égető, én Cseh Robi féle (Bővebben)STK500-at használok 10éve. De ha gondolod írd meg ahogy neked jó, tedd fel, és lefordítom neked.

Használj légy szíves nagybetűket a mondat elején.

Ha meg az égetés nem megy elugrasz hozzám és feltöltöm neked!

lefordítja..de nem akar elindulni..pedig a khazama beletölti...a programozó USBASP. Az extreme Burner pedig az írja, hogy nem jó hex file...ha vele próbálkozom. Az általad megadott hexeket viszont vígan betölti a khazama...és el is indulnak.

Láthatnánk az a bizonyos hex állományt? Nincs benne (a végén) egy-két nem ":" -tal kezdődő sor?

tessék...ezt én fordítottam..erre mondja az extreme burne , hogy invalid hex.

Sajnos a 4sensorspróba.hex csak egy vége rekordot tartalmaz.

Hülye kérdés: ékezet nélkül próbáltad?

próbáltam...lefordítja az általad küldött 4sensor.bas...betölti a khazama...de a program megáll ott, hogy nincs szenzor. A hexet amit szintén akkor küldtél...betölti simán és fut. Ezek azok.

Ugyan az a tartalma, mint amit Tetye töltött fel. Inkább mégis fuse bit beállítási hiba vagy a programozó hibája lehet.

A 4sensors.hex az a Tetye féle...it van az amit én fordítottam...:
A módosítás minimális lenne..csak annyi,hogy az első mérőhelyet a-val lesz jelölve.

$PROG &HFF,&HE1,&HD9,&H00' generated. Take care that the chip supports all fuse bytes.
ezt olvastattam ki...

Már csak a fordító verziójában lehet eltérés.

Mire gondolsz? Az extreme fel sem ismeri ezeket a hexeket...a Khazama felismeri bár berzenkedik mert mindig azt mondja, hogy nem jó az órajel...de azért betölti

Mivel égeted? Bootloader-es arduino? Vagy sima ic ISP-n keresztül? Szerintem törölj le mindent. Aztán töltsd le az atmel studiót a honlapjukról regisztrálni kell hozzá, aztán a legfrissebb bascom- demót, tedd fel ezeket és úgy próbáld meg.
Bascom-al lefordítod, avr studioval meg felégeted.