OK!
A laptopon nincs se soros se párhuzamos.

Eagle-ben már elkezdtem egy tervet, majd még meglátom!

Amúgy először még üzembe helyezem a régi asztali pc-m
és megprobálom azon is.

Kössz mindent.

Igen. Szerintem egy picit belekeveredtünk Röviden: RB7-hez gnd érint akkor minden ok (villog a led) ha nem akkor (led nem villog). Lebutitottam a progit egy led villogtatására mig keresem a hiba okát. De bármelyik RB lábnál ez a helyzet. (kivéve RB4 mert az felhuzva Vdd-re 10k).

Mutasd meg a kapcsolást és a kódot, anélkül nemnagyon tudunk mit mondani.

Milyen PIC ez? Nem lehet, hogy engedélyezve van a debug, és az is az ICSP lábakon kommunikál?

Elvileg le van tiltva: Link

Na megy a hőmérős dolog, persze invertálva a subwf baromsága miatt, de azt mindjárt lekezelem, és a tényleg fél fok jelet egyet, tehát Potyó ötlete is tökéletesen bejött, 60-at kell levonni, és az a 30
.
Persze 41 foknál kell bekapcsolnia, és 37-nél ki, de ezt is megoldom most már.
Mégegyszer köszi a helpért.
Ez itt szilvának:
Ez meg Potyónak:
És ezt meg magamnak:

Ez nem a subwf baromsága, ez egyszerűen ilyen! Lehet, hogy nekünk kifacsart, viszont a bináris logika szerint csakis így jó! Tanuld meg elfogadni a dolgokat és úgy használni(ha már nem érted miért van úgy), sokkal könnyebben haladsz.
A másik, hogy potyo nem egy ötletet adott elő, hanem tényt közölt, amit észre kellene neked is venni egy adatlapban, ha egy eszközt használsz. Kicsit kevesebb csapongással jobban megakadnál ilyen fontos részleteken. Azért egész ügyes voltál ha a végeredményt nézem! Alakul ez...

Sosem mélyedtem bele, hogy miért is alakul így a carry, egyszerűen elfogadtam.

Azért megjegyzendő, hogy nem minden processzor viselkedik így, én például Intel 8085-tel és Z80-nal kezdtem anno, ott a carry "a józan ész" szerint viselkedik. Akkor ért az első meglepetés ezügyben, amikor a Commodore-okban lévő 6502/6510 processzorokkal kerültem szorosabb kapcsolatba, ahol már az invertált carry-logika jelent meg a kivonásoknál.

Később sokat foglalkoztam az MCS51 család mikrovezérlőivel, ott megint csak az "inteles" felfogás érvényesült. Aztán a PIC-eknél ismét meg kellett tanulnom, hogy az "fordítva" van

Működik a hőmérős projekt. 41 fok felett bekapcsol, és 36 alatt pedig ki.
Estére megtervzem a nyákot, aztán ha lesz időm akkor le is világítom meg ki is marom. Aztán mehet a radiátor mellé.
Asszony is örülhet, mert végre egy hasznos projekt a sok kísérlet meg fényjátékok után.
Köszi mégegyszer a helpeket.

Nem pont fordítva? Vagy mit vezérel ez? Nem egy termosztát lesz a padlófűtésre?

üdv,

Ezzel a 16f887-el döcögök, de egy kis elmélet...
Ha egy változónak értéket szeretnék adni akkor a max érték az d'256' ? vagyis b'11111111' ?

A maximális érték az decimálisban 255! Ez azért van így, mert a 0-t vesszük a kezdőértéknek, nem az 1-et! Legalábbis a fordítók ezt támogatják...

Nem lehet 256, mert az a következő helyiérték értéke lenne. b'100000000'
Azért sem, mert a 256 páros. A kettes számrendszer egyetlen páratlan helyiértéke az 1 (0. bit, illetve 1. helyiértéken) Ha tehát az 1. helyiérték 1, akkor a szám páratlan.

aha, teheát 8bites PIC-nél csak 8bites lehet a legnagyobb szám vagyis 255. kösz

Több bájton nagyobb szám is kezelhető természetesen.

Kedves Fórumozók!

C30-as compilerrel az a bajom, hogy a printf függvény használata iszonyatos kódot generál, nagyon-nagyon sokat.
Helyettesítve saját függvénnyel, a program mértete alig pár száz utasítás, printf függvényt használva 4000 a 4096-ból!?

A heap size-ot 200 bájtra tettem, a projekt beállításainál.
Valaki találkozott már e jelenséggel?

Helló Mindenkinek.

Kezdő PIC-kes kérdésem lenne.
16F887-essel tanulgatok. A minta prg. alapján beprogramoztam az a2d átalakítót.
Konvertásás után az eredmény az AdresH és az AdresL
tárolóban lesz. A prg.-ban az eredmény balra igazitott tehát az alsó 8 bit az AdresH-ban van és 255-ig számol.
Eddig redben is lennénk, be ez az érték a poti maximumánál keletkezik. Pedig ha ez az a2d 10 bites, akkor az 1024-nek kellene a poti maximumának lenni (ha olvasnám a felső két bitet is), tehát a 255 szám a poti negyedénél kellene hogy legyen.
Most szeretném felhasználni a felső kettö bitet is de nem értem, hogy most miért a poti vége a 255 és miért nem a negyedénél van?

Köszönettel

Ez nem egészen igaz. Az igaz, hogy az AdresH-ba van balra igazítva az érték, de az nem, hogy ez az érték 0-255 lenne. Inkább 0-1020-ig terjed, méghozzá 4-esével számolgatva, ugyanis az 1-es és a 2-es helyiérték az AdresL 6. és 7. bitjén van!

Így valahogy:
bH'11111111', bL'11xxxxxx'
Ha jobbra igazítod, akkor meg így néz ki:
bH'xxxxxx11', bL'11111111'

Adatlap 9-3-as "figura"...

Én egyszerűbbnek tartanám jobbra igazítani, és úgy kezelni.

Ha balra igazított, akkor az ADRESH, ADRESL regiszterpár bal oldalára kerül a legfelső bit, azaz az ADRESH teljes mértékben ki lesz töltve az eredmény 9-2. bitjeivel, és az ADRESL felső két bitjébe kerül a 1-0. bit.

Amiről Te írtál, az a jobbra igazításkor történik: ADRESH-ban a 9-8. bit, ADRESL-ben a 7-0. bit.

Helló Watt.
Köszi a gyorsaságot.
A minta prg.-ben van így.
Most írom első saját ügyetlenkedésemet, és szeretném mind a 10 bitet kihasználni, kijelezni.
Közben újra átolvastam az adatlapját és most látom, hogy nem a felső két bitet "vágta" le hanem az alsót.
Jól értelmezem?
Persze most probálom megfordítani az igazítást, csak az utánna jövö dinary to BCD konverter összezavarodott. (meg én is)

KÖszönettel.

Helló Watt és szilva.

Fantasztikus gyorsak vagytok, most nekiállok, és he netán elekadok, újra jelentkezem.

Ezer köszönet.

Igen, ha a többi programrész a jobbra igazításhoz van írva, akkor ne fordítsd meg!

(gondolom a dinary, binary akart lenni, az a2d, az meg AD.)

Egyébként most nem értem mit szeretnél, mert sokmindent meg kell változtani, vagy egyszerűen kihagyni, ha a részleteket szeretnéd végig követni.

Helló Watt.

Igazad van binary. (érdekes, gyerek korom óta keverem a b és a d betűket). Most 54 vagyok.
Több helyen láttam, hogy az analog digital átalakítókat így rövidítik, hogy analog 2 (to) digital.
A lényeg: találtam 16 bites binarist BCD kódra átalakító programot. Az átalakítót leteszteltem számokkal, és müködik. (még nekem is) most elé szeretnék tenni egy potit, melyet átalakítok 10 bites binarissá és azt kijelezni 7 szegmensen.
(nem ide tartozik, de ötven felett vagyok elbocsájtottak, és lenne egy kis munka és ahhoz kellene.)
A következő az lesz, hgy a mért értéket össze kellene hasonlítani egy "tűréssel", és nincs compare utasítás.
De ez majd a következő lépés.

Köszönöm a segítségedet.

Helló Watt.

Egyszerűen nem értem , ha a balraigazitott ADRESH teszem be a converter binL változójába,
a kijelző 1-255 ig kiír.
Ha jobbra igazítok, az mplab szerint tökéletes az ADRESL, és ADRESH értékei.
Ha most az ADRESL értékét teszem be a binL változóba, a kijelzés 1-3 ig megy.
De hogy miért?

És akkor mit ír ki, ha balra igazítod és az AdresL-t teszed bele?
Egyébként inkább az AdresH-nál tudom elképzelni, hogy 1..3-ig van benne érték, ami jó is lenne. Nem véletlenül azt töltötted bele?

Esetleg a kódot, vagy annak részletét betehetnéd...

1/2-off.
Én még soha nem láttam az AD-t a2d-nek írni, de ahogy magyaráztad elfogadható, mondjuk. De hamár három betűt akarsz írni, írd inkább úgy, hogy ADC, így írja az adatlap is! De valóban nem sok jelentősége van...

Balra igazításnál az ADRESH legfelső bitjétől kezdi el a kitöltést a 10 bites eredménnyel az AD, a legalsó 2 bit "átcsorog" az ADRESL-be. Jobbra igazításnál ADRESL legalsó bitjétől kezdi a feltöltést az eredmény alsó bitjével, így a két legfelső bit "csorog át" az ADRESH alsó 2 bitjébe.

Ezáltal amit írtál, az jogos lehet (azzal a kiegészítéssel, hogy nem 1-től, hanem 0-tól kezdődő értékeket látsz). A 16 bites átalakító bemenetén az l és a h regisztereket is fel kellene töltened (binL-t írtál, gondolom, a párja a binH): az ADRESH-t a binH-ba, az ADRESL-t a binL-be kell másolni a konverzió előtt. Ha így teszed, akkor jobbra igazítás esetén 0-1023 értékeket kell kapnod, amik egyesével növekszenek.

szilva!
Írod:


Ezt írta Sendi:

Tehát akkor mégsem jó itt valami, mert pont az AdresH az amibe az átcsúszó két bit 0-3ig adna vissza értéket. Nem?

Szerintem össze lett keverve a két AdresX.

Helló mindenkinek.

A 887-es AD konvertere ha balra van igazitva akkor megteszi az alábbi parancsokat, ha jobbra akkor nem.
Miért nem? Nem tölti be az adatokat a binL és a binH-ba.

clrf binL ;az átszámítandó adat alsó 8 bitje
clrf binH ;az átszámítandó adat felső 8 bitje
movf ADRESL,w ;AD konverter eredménye
movwf binL
movf ADRESH,w
movwf binH

call _bin2bcd ; konverzió indítása

Ez egy szilárdtest relét fog meghúzni, mert a kandalónk olyan, hogy 2 radiátort kötötünk rá (3 a max), mivel begyújtás után a vizet elkezdi melegíteni, ezért vagy egyből benyomjuk a keringetőt, viszont akkor a rendszerben a hideg vizet keringeti, ami pazarlás, vagy megvárjuk, amíg a víz felmelegszik benne, azt beletekerjük a radiátorokba, és egyből melegedhet is, és amikor jön a hideg víz a radiátorok felé, akkor meg kihúzzuk.
Ez a folyamat 30-60 percen keresztül 10 percenként 1 perc bekapcsolás, meg csőfogdosás, ezt kell kiváltani.
A hőmérő a csőre kerül, és ez az elektronika, a relét meghúzza, ha a cső 41 fok vagy melegebb, a 36 foknál meg elenged a relé, kikapcsol a keringetés. (ezt lehet hogy majd lejebb veszem, ez még kísérlet tárgyát képezi)

Szerintem nem figyeltél a bankokra. Az ADRESL és ADRESH más-más bankban érhető el, és a binL-binH is lehet akár máshol is. Használj BANKSEL makrókat a regiszterek elérése előtt, pl. így:

BANKSEL binL
clrf binL ;az átszámítandó adat alsó 8 bitje
BANKSEL binH
clrf binH ;az átszámítandó adat felső 8 bitje
BANKSEL ADRESL
movf ADRESL,w ;AD konverter eredménye
BANKSEL binL
movwf binL
BANKSEL ADRESH
movf ADRESH,w
BANKSEL binH
movwf binH

Ha binL és binH ugyanabban a bankban van, akkor egyszerűsödik a dolog, ha esetleg ezek a 0. bankban vannak, akkor mivel az ADRESH is ott található, még egyszerűbb lehet.