Hali! Tekintve hogy a float és int számábrázolás teljesen más formátumú, így a tartalmazó bájtok egyesével mind a két esetben tök mást jelentenek, vagyis nincs értelme az u n i onnak.Tárolhatod vagy így vagy úg, és ha a másik kell akkor kényszerkonverzió. De vigyázz, floatban nem minden érték adható meg pontosan, így például összehasonlitáskor adhat fals értéket....
Közelítés : A float számok rögzített számú bitet használnak (előjel, kitevő, mantissza), így a valós számokat közelítésként, nem pedig pontos értékként ábrázolják.Pontosságvesztés : Emiatt néhány egyszerű tizedesjegy (például a 0,1) nem ábrázolható tökéletesen, ami apró hibákhoz vezet (pl.\(0.9999999999999999\)). A float műveletek egyébként sokkal erőforrás igényesebbek, több flash-t használnak a műveletvégzéshez, lassúbbak... Szóval jótanács, én ha tudom messze kerülöm a használatát. Ha tizedes kell, akkor használom az érték 10-100szorosát, ezzel végzem a műveleteket, kijelzéskor meg figyelek, hogy hová teszek tizedespontot.

Köszönöm,
nem, hálistennek ezek már megvannak, a prinf fromázások is, csak ez most nem áltl össze a szemem előtt így

bemásolom ide a kódom, hátha valaki észreveszi a hibát.
A beírt float-ot szeretném kiléptetni egy led-re, egyelőre.

Köszönöm, ezek megvannak, már csak azt nem értem ha a memóriájának valahol 4 bájtjában tárolja a float-ot, akkor annak a 4 bájtnak miért nem tudom kiolvasni a 0-1-0... értékeit...

(Alapvetően azt szerettem volna elérni, hogy anélkül, hogy egyik és másik eszköz tudja mit kellene csináljon, ki tudja jelezni az A PIC által küldött számot a B PIC-hez kapcsolt 7 szegmenses (mondjuk). Ehhez csak egy float kellene neki, meg egy ,,felbontás" jelzés, de azt el is tudom küldeni. Tudom, hogy vannak erre kommunikációs interfészek stb, de most már baromira csiklandozza az ingerközpontomat, miért nem tudom a fizikai biteket kiolvasni.)

Hali!
Értsd meg, a float ban tárolt bájtoknak semmi köze a tárolt szám bináris bitenkénti tartalmához, nincs értleme az u n i onnak float és int között !!!!
float

MEgpróbálok még egyszer írni, hátha most megitn nem futok ugyanabba a szóhazsnálatba

Tehát a CCS a saját kódjaiban is használ IEE és PIC float közötti átalakításra bájtonkénti (bitenkénti műveletet).

ennek egy részlete:

Engedd el az u n i ont! használj külön float, és külön int változót, ha az érték mégis a másik formában kell akkor tedd át egyik váltózóból a másikba. Nézd már meg a float fizikai számábrázolását a 4 bájt melyikében mit tárol, és megérted. Ez azt jelenti ha van négy bájtod és belenézel int-ként akkor tök más értéket látsz, mintha float-ként tekintesz rá.

Itt mindenhol uint van nem sima int. A sima intnél bezavar a kettes komplemens.

Köszönöm a konstruktív segítséget!

Igen, alapvetően ezt meg lehet oldani másképpen is. Az ötlet csak onnan jött, hogy univerzális legyen, hogy a ,,dekódoló,, oldalnak tényleg ne kelljen tudnia hogy mennyivel kell visszaossza a számot stb stb.

Igen, egyre inkább az az érzésem, hogy azzal, ha beírom binárisan a float-ot, azzal nem a bitjeit állítom be, hanem az értékét. Szerintem itt a hiba, ma ezzel haladok tovább, és megpróbálom az általad használt verziót.

Köszönöm!

PIC18F14K22 open-drain kimenet

PIC18F14K22 RA4 open-drain kimenettel rendelkezik?

ChatGTP szerint:
RA4 (RA4/T0CKI)
Az RA4 láb hardveresen open-drain (open-collector jellegű).
Nem tud aktívan „1”-et hajtani, csak lehúzni a vonalat.
Külső felhúzó ellenállás szükséges.

Adatlapból nem jött le.

Egy busz vonalat kellene GND-re húzogatni ahol van egy felhúzó ellenállás és még két tranzisztor is használja.

Az újabbaknál már nem open drain az RA4.
Régebben az I/O Ports fejezetben ezt külön feltüntették, és külön block diagram volt az RA4-nek, ennél már nincs ilyen.

Tudsz váltani a bemenet és a kimenet GND-re húzva között, azzal megoldható.

Úgy van ahogy majkimester írja.
Pl. a 18F1320-nál open-drain az RA4 kimenet, vagyis kell felhúzó ellenállás, lásd adatlap 8. oldal.
A 18F14K22-nél az RA4 "rendes" kimenet mint a többi, lásd adatlap 10. oldal.
Érdemes ezeket mindig megnézni az adatlapban.
Én anno amikor elkezdtem ezzel foglalkozni, a 18F1320-nál szaladtam be ebbe, és nem értettem hirtelen mit rontottam el.

Ezt úgy érted, hogy ha le akarom húzni akkor kimenetre állítom, ha nem akkor bemenet?

Gondolom az nem működik hogy kimeneten magas szintet ad és a vonalon lévő külső tranzisztor meg lehúzza.

Igen,

PORTA,RA4 = 0 és TRISA.RA4-et váltod.

TRISA.RA4 = 0 -> kimenet, tehát GND-re húz
TRISA.RA4 = I -> bemenet, azaz nagy impedanciás

Az nem megy, hogy normál kimenetnél te magasba a külső tranzisztor meg alacsonyba akarja húzni. A gyengébb (ami Murphy szerint a kontrolleren belüli) tönkre is megy.

Szuper, Köszi az infót. Így már jó lesz.

Progi fordítása HEX re

Üdv mindenkinek
Sajnos nagyon kezdő vagyok a programok világában de szeretnék építeni egy áramkört pic16f887 ic vel.
Az AI vel írattam egy programot amit szeretnék kipróbálni de sajnos nem HEX fájlt küldött így nem tudom beégetni az ic be.Esetleg valaki letudná nekem fordítani.
Erről lenne szó:

Előre is köszönöm a segítségeteket

Pancsolj, lásd melléklet. A konfigurációt kiegészítettem, mert hiányos volt, erre:



A programot nem ellenőriztem semmilyen formában, csak fordítottam (ingyenes verzójú XC8).

Mármint parancsolj és ne csak pancsolj.

Hálás köszönet a pic et megrendeltem ha megérkezik már próbálom is ki.

PIC16F684 SMD fűt

Sziasztok!
Meglepve tapasztaltam egy kütyümnél, hogy a PIC felforrósodik, miközben minden dolgot hibátlanul csinál, pedig a program elég bonyi, szinte minden lábat és perifériát megdolgoztat. Leválasztottam róla az összes be/kimenetet, de a hiba megmaradt, folyamatosan felvett 260 mA-t. Procicsere után a kütyü hibátlanul működik.
Tapasztaltatok már hasonló jelenséget, vagy van erre szerintetek magyarázat?

Teszteld le a kimeneteket hogy nem zárlatos-e valamelyik.

Mint írtam, akkor is csinálta, ha minden ki/bemenetet leválasztottam...

Attól hogy megszüntetted az esetleges zárlatot a már tönkrement (belsőleg bezárlatosodott) mikrovezérlő nem fog megjavulni. Amint azt tapasztalhattad is, csak a csere segített. Bár jellemzően nem szokott túl érzékeny lenni, de azért tönkre lehet tenni egy mikrovezérlőt. Ha esély van arra, hogy "szkanderozni" fog a mikrovezérlő valamelyik perifériával, akkor célszerű áramkorlátozó ellenállásokat beépíteni a mikorvezérlő láb(ak) és a perifériá(k) közé.

A kontroller beforrasztása előtt célszerű a bemérés 2. és 3. lépését elvégezni. A forrasztás után érdemes a lábak közötti zárlatokat megkesesni.

Kösz, ez mind triviális, de akkor az új PIC miért nem halt bele? Az áramkörön semmi változtatás nem történt.
Ja, és csere előtt persze végigmértem, szkópoltam az összes láb jelét, mind hibátlan volt. Szkanderezésnek, szinthibának semmi nyoma nem volt.

Bocs, de nem igazán értem, hogy ez hogy jön ide... mármint a PICKit2 klón?

Az hogy végigmérted és szkópoltad a lábakra menő jeleket, csak azt jelenti, hogy a mérések alatt nem találkoztál rendellenes dolgokkal. Attól még más alkalommal előfordulhatott közeli villámcsapás, földeletlen asztali PC-vel történő összecsatlakoztaskori túlfeszültség, tápegységen keresztüljutó hálózati zavar, meg még ezernyi más dolog.

Ha elovasod a bemérés rész 2. 3. pontjait, rá fogsz jönni...

Ha a "Bemérés" 2. és 3. _bekezdéseiről_ van szó, akkor sem találom relevánsnak az én esetemre nézve. Én ott csak egy 7. pontot látok, de az egész anyagot persze nem olvastam végig.

Már leírták hogy zárlatba mehetett valamelyik kimenet vezérlője.Én is erről beszéltem. Ezért írtam hogy teszteld le. Írj rá egy programot, ami kapcsolgatja a lábakat és nézd meg logikai analizátorral vagy egy LED-el hogy kiadja-e a feszültséget a lábakra. Alapból én azzal kezdek feléleszteni egy elkészült modulomat, hogy írok rá egy láb tesztelő programot.

Kösz a választ, meg mindenkinek, aki foglalkozott vele. Úgy látom, bővebben le kell írnom a történetet, hogy minden aspektusa érthető legyen.
Szóval ez egy általam, egy megrendelőmnek fejlesztett kütyü, amit ő sorozatban gyárt (valahol 400 darabnál jár). Teszteléskor futott bele ebbe az egy forrósodósba, elhozta hozzám. A procikat tőlem viszi beégetve. Villám nem érheti őket, legfeljebb statikus csapás, ezt nem zárnám ki teljesen. PIC-ekkel 28 éve dolgozom, ilyen esetem sem volt még. Beméréskor sem valószínű a meghibásodás.

Amikor nekiláttam, először a funkcionális működést ellenőriztem: mindent hibátlanul csinált. Ezután szkóppal végignéztem a proci összes lábát, ott is minden abszolút rendben volt. Ezután újraégettem (a panelen ki van alakítva az ICSP csatlakozás), és továbbra is hibátlan volt minden, csak a proci forrósodott.
Ezután döntöttem a csere mellett. Az új proci a sorozatban égetettek közül került ki, azaz teljesen azonos FW volt benne. A kütyü hibátlanul elindult, az áramfelvétel normális lett, a proci hideg maradt.
A procit (SMD) lábak nélkül vágtam ki a panel kímélése érdekében, de még nem dobtam ki. Lehet, hogy megpróbálom behuzalozni egy teszt erejéig, pl. megpróbálok ránézni Pickit2-vel, mérve az áramfelvételét is.