Hogyan johetett ki 4110 fok, amikor 2047 a maximum? Azon kivul a csatolt kepen az elso byte mindig 0, tehat 16 foknal nagyobb ertek nem is lehet. A 13 fok sokkal inkabb helyes eredmeny, mert a masodik byte felso 4 bitje pontosan a fokot tartalmazza, ha a felso byte 0. Ennek megfeleloen a csatolt kepen 8..14 fok koruli ertekek vannak. A belso homerorol nem derul ki semmi, mivel a harmadik byte helyett is a negyediket kuldted ki.
A programban data es th milyen tipusu valtozok? Ha data long, akkor nem kell a felesleges maszkolas es ujboli elojel eloallitas (15. sor), eleg csak siman: th = data >> 18;

Valóban.
Azt viszont már javítottam.
A sprintf-ben hogy kell átírni hogy két tizedes pontosan megjelenjen?
Illetve nem teljesen értem hogy miért kell elosztani 4-el a fogadott hőmérséklet adatot.

Első körben én kettéválasztanám az érkező 32bit adatot két 16 bitesre.

Ez csak pozitív egész számokat tud kezelni, de kezdésnek jó lesz:

Tökéletesen működik!

Hogy lehet megcsinálni, hogy ne csak egész számokat tudjon kezelni?

Azert kell neggyel osztani, mert az also ket bit nem a homerseklethez tartozik, a kovetkezo ket bit pedig a tizedes resz, azaz a 0.5 es 0.25 fokok bitjei. A sprintf-ben nem egyszeru a ket tizedes kiiras, mert ha azt kapod az IC-bol, hogy 3, akkor az 0.75 fok. Egy nem tul elegans megoldas, ha pl. megszorzod 25-tel a kapott eredmenyt, es azt iratod ki ket reszletben. Csak ott is szivas van a tort resz elojelevel:


Ha ugyanezt lebegopontosan oldod meg, akkor valamivel egyszerubb a kiiratas, de valojaban sokkal tobb kodba kerul a lebegopontos aritmetika hozzalinkelese miatt:

Köszönöm a gyors válaszokat neked is és Zolinak is! A legvégén nem lesz szükségem a tizedesek kiírására, de szeretném megérteni, ezért jól jött hogy leírtad.

Én nem terhelném le az AVR-t tört változókkal.
Külön kezelném a tört értékeket egész számként.
Persze ez függ a felhasználási területtől is.

Jogos, csak akkor a negativ szamok eseteben maskepp kell dolgozni. Ha csak siman eldobod az also ket bitet a szambol, amikor az egeszeket kepzed, akkor a negagiv ertekeknel kulon oda kell figyelni, mert a -1, -2 es -3 ertekek -0.25, -0.5, -0.75 foknak felel meg. Ha csak siman eldobod az also ket bitet, akkor az egesz resz -1 lenne, pedig annak nullanak kellene lennie. Ezen felul a tizedeseket sem kepezheted ugy, hogy az also ket bitet szorzod 25-tel, mert negativ homersekletnel az sem lesz jo. Ennel egyszerubb, ha negativ homerseklet eseten, kiirsz egy minusz jelet, es a szamot negalod, es utana pont ugy kezeled, mint a pozitiv homersekleteket.

Nem is jo a kodreszlet, amit irtam, mert -0.25 es -0.75 fok kozott hibas erteket ir, mivel ezekben az esetekben az egesz resz nulla, igy nem fogja kiirni a minusz jelet... A floatos megoldas jo, csak az irtozatos pazarlas.

Ez a része tényleg beugratós, észre se vettem.

Még egy olyan megoldást tudnék elképzelni, hogy a hőelem adatán az alsó két bitet lemaszkoljuk, és így használjuk fel előjeles egész számként. Csak minden számítási műveletnél figyelembe kell venni, hogy az aktuális hőmérséklet 16 szoros értékével dolgozunk.

Egyedül a megjelenítésnél kell egy pár művelet, ahol külön kezelnénk az előjelet, az egész értéket és a tizedest. Talán még mindig kevésbé lenne erőforrás igényes mint egy lebegőpontos szám.

Persze, terminálon átküldve nem lenne jó, de az szerintem nem is végtermék megoldás. Ha PC-n kell megjeleníteni, akkor oda is átmehet egészként és majd az ottani program konvertálja át magának tizedesre.

Maszkolas helyett inkabb elshiftelem ket bittel jobbra. Akkor is elojeles egesz szam marad, de minden bit hasznos lesz benne, nem kell kulon foglalkozni azzal, hogy az also ket bit mindig nulla. Tort szam marad igy is, hiszen az also ket bit 0.75 fokot "ér", de ettol meg szamolni konnyen lehet vele. Es ahogy mondod, a kiirasnal kell csak vacakolni a szetszedessel. A 25-os szorzast is csak a kiirasra javasoltam, egyeb muveletekre a 14 bites erteket jobbra igazitva a legcelszerubb hasznalni. Terminalra ASCII-t kuldesz, ez adja magat. De hat az a kiiratas, maga.

Tehát ha előjeles számot shift-elek az előjel marad a helyén?

Igen. 0x8000 >> 1 = 0xc000. Ha elojeles szamot shiftelsz jobbra, akkor a legfelso bit megmarad, es az eggyel alacsonyabb helyierteku bitre is a legfelso bit masolodik be. Assembly-ben ez altalaban az ASR, Arithmetic Shift Right. Balra shiftelesnel az also bitbe nulla megy mindig.

Sziasztok, a következő fuse bit-ek beírásával kizárhattam magam a mikrokontrollerből: 7F DF ? Amíg A1 D9 volt még ment, de most már a régit sem tudom visszaírni. Most külső oszcillátor kell neki hogy tudjam programozni?

Sziasztok!

Nemrégiben jelentkeztem a MAX31855 problémával kapcsolatban.
A szabályzáshoz szeretnék egy PIC szabályzót illeszteni. Egyenlőre egy másik projekt szabályzójával próbálkozom, több kevesebb sikerrel.
Amíg a beállított értéket nem éri el teljesen a szenzor, kb. 20 fok különbség lehet, addig tökéletesen működik a kijelzés, amint eléri és a szabályzás beavatkozna, elkezd ugrálni a kijelzés, pl beállítom 200 fokra akkor 211, 202, 193, de még 170-re is képes lemenni. Ha "beállt" és csak finoman kellene pár fokot szabályoznia képes ugrálni a kijelzés 198 és 188 között, csak ez az érték, pont 10es különbséggel. Ha csak a proporcionális tag értéke van beállítva, az integráló és a deriváló 0, akkor tökéletesen működik. Amint az integrálót 0-ról elállítom, újra előjön a hiba.



pid.c:


pid.h:


Amennyit ugrál a beállított hőmérséklet annyit fizikailag képtelen, mert egy fűtőtesten van a hőelem, tehát azt nem értem, hogy hol és mit rontottam el hogy csak akkor ugrál amikor finoman kellene szabályozni. Vagy pont azért csinálja ezt mert még nincs bekalibrálva a PID szabályozó?

Kapcsolási rajz?

Ez messze nem AVR kerdes, sokkal inkabb PID. Ha nem jok a konstansok, a szabalyzod gerjedni fog. Nem egyszeru temakor. A PID szabalyzok integralis tagja csuf dolgokra kepes. Pl. itt soha senki nem nullazza azt es tulcsordulasra sem figyeli a program. Ez semmikeppen nem jo. Ha KD-t nullara allitod es KI-t valami kis ertekre, akkor is ugral?

Lehet félreértettem a problémát...
A kijelzett hőmérséklet ugrál össze-vissza vagy a hőmérséklet ingadozik és emiatt a kijelzés is?

ui.: Hol és mire vannak megadva a pid konstans értékei?

Akkor nem ugrál. Ezzel a beállítással: pid_s.KP = 15; pid_s.KI = 2; pid_s.KD = 0; pid_s.KT = 30; 160 fokra beállítva 164 és 151 között mászkál, 151 alá nem megy. Kezdhetek arra gyanakodni, hogy csak azért csinálja mert gerjed a szabályozó?

Zoli: Biztos vagyok benne hogy a kijelzett hőmérséklet ugrál. Fizikailag lehetetlen hogy a fűtőtesben 1sec alatt 10 fokot változzon a hőmérséklet, még ha teljes gőzzel fűt, akkor sem változik 1sec alatt 10 fokot, és itt ráadásul negatív irányban változik, ezért nem értem.

Ha így ugrál az mérési hiba, mégis csak kéne a kapcsolási rajz.

Ez volna az. Én is arra tippeltem először, de furcsa hogy csak bizonyos PID értékek mellett csinálja, közben kísérletezések közben ha a KT-t levettem 1-re akkor nem csinálta. És fura hogy csak akkor ugrál ha a PID be akar avatkozni.
A csatolmány kérésre törölve.

Elsőnek a hőelem jelét szűrni kéne, mert elég hosszú a vezeték és rárakódik a kapcsolási zaj.
Másodiknak átlagolni kéne. Másodpercenként elég egyszer pid értéket számolni normál pákáknál, viszont ezalatt mérni kéne "folyamatosan" és átlagolni.

Milyen pákához lesz?

Sold iron/n pákához. Szűréshez elég csak egy 100nfos kondi a hőelem bemenetre?
Átlagolásnál mennyi időnként mérjek és hány értéket érdemes átlagolni?

100n nem elég, kéne egy aluláteresztő szűrő.
Olyan gyakran mérj, amilyen gyakran csak lehet (nem túl sok lesz .

Üdv!

Megszerettem volna építeni a vonalkövető robotot, de szereintem valami nem jó a programban!
a kapcsolás maga működik, de ha elindítom a Serial Monitort, akkor semmit nem ír ki, miközben kellene neki a határértkeket!


Előre is köszönöm!

Szia.
Rakj egy Serial.print-et a setupba, hogy tudd, egyáltalán van-e kommunikáció (ha nem azonosak a sebességek, lehet nem jön át semmi karakter). Ezután rakd fel még az if-ek elé a Serial.print-et, mert lehet, hogy az egyik if-be beragad a program. A másik ötlet: a motorok elindításakor resetel az AVR. Szét kellene választani a két tápot, minimum egy diódával, az AVR-nek meg legyen saját 1000µF kondija. Nézd meg a tápellátást is, hogy elég-e!
szerk: ez mondjuk Arduino, annak van külön témája, oda írj ezután.

Köszönöm!
Rendben oda fogom.

Sziasztok!
Van valami módja az I2C kommunikációt optocsatolóval izolálni?
Találtam kapcsolást, ami majdnem jó, csak nálam nincs különválasztva az SDAin és SDAout.Bővebben: Link
Az SCL-t leválasztani nem okoz gondot, azt úgyis csak a master adja, viszont két irányú lenne a kommunikáció, az SDA leválasztására nem találok megoldást, ahol nem kell valami spéci IC-t venni.
Esetleg ez jó lenne SDA-hoz? Bővebben: Link
Köszönöm a segítséget!

250ms-onként lehet adatot kiolvasni, szóval másodpercenként 4x.
Az aluláteresztő szűrőhöz megfelel a 47uf-os és 470 ohmos ellenállás?
A pwm kapcsolófrekit érdemes lentebbvinni? Láttam olyan megoldást ahol csak 15hz.

Goooogle "I2C opto isolator": Bővebben: Link