Nincs mit! De hát ere való a fórum, így vagy úgy, de kirángatni egymást a végtelen hurokból ))

Hogy ez a hétköznapi munkában is hányszor van így...
Belemerül az ember egy problémára és felkerül a szemellenzö...
Ilyenkor jól jön egy kolléga akinek semmi köze a projekthez.

Azt tudod, hogy a (7950/256) eredménye 31 és nem 31.054? Ezért aztan a végeredmény sem lesz pontos. Ebben az esetben kicsi a hiba, de a módszer maga pontatlan. Ha azt írod, hogy 7950 * t3_szamlalo / 256, akkor pontosabb eredményt kapsz.

A megszakítási rutinban levő hosszadalmasabb számítás még megbosszulhatja magát.
Miért nem késik egy mintával a PWM. Ekkor a megszakítás csak előveszi az előzőleg kiszámolt értéket és beírja a PWM regiszterébe csak eztán kezd szorozni és osztani.

Köszi, javítom!

Amúgy full tesztnek ment eddig, mivel a hibát sem ismertem pontsan. Ha megnézitek a hozzászólások időpontjait, akoor kiderül, hogy pár perc alatt sokkal jobb eredményt értem el, mint korábban, örültem neki, nem agyaltam túl eddig a dolgot. Az interruptban eddig más volt, csak gyors ellenőrzésként tettem ezt bele és már az is sokkal jobb volt.

De köszi a gondolatokat, átírom a javaslatok szerint, mert jók nagyon!

Jöhetnek még, akár tapasztalatok is!

Köszi!

Erre még nem gondoltam, beépítem az eddigi programba, sőt valójában igen könnyen meg is tudom tenni.

Még meglátom melyik megoldás illik a legjobban az eddigi progam töredékhez. Elvileg egy chirp jel lesz, de az eddigi szinuszos jellegű jeleim is igen jók, de 42KHz-nél már nem. 0-4Khz-ig igen jó eredményeim lettek úgy is, kicsit elmentem a PWM rejtelmei felé. Most Vco-val gondolkodom, van is itthon, jó négyszögjelet ad ami a fet H-hídhoz és a piezóhoz is illik.

Szóval ha bejön majd később a projektbe, hogy a triggerre induljon a jel, akor a timer_3-at indítom. Ekkor már be is tölthetem az első értéket (trigger előtt még a main()-ben), majd kiszámolom a másodikat is. Az interrupban meg betöltöm a másodikat, kiszámolom a következőt, stb.

Gondolom hasonlóra gondolsz, de ha blődség amit írok, akkor bocs, hamarabbírok, mint ahogy kipróbálom.

Még át kell írnom a kódot, hogy ne kelljen folyton számolgatnom, hanem csak pár paraméter megadásával minden jól működjön.

A Microchip a fejállományaiban struktúrákat húz rá a hardver regiszterek címeire. Ezzel nem mondtam semmi újat...
De hogyan tudja azt megcsinálni, hogy ezután a forráskódban xxx.yyy alakban lehet hivatkozni a struktúra elemeire?!
Én ilyet csak mutatón keresztül tudok csinálni, de akkor annak megfelelően xxx->yyy lesz a hivatkozási forma...

Ezt a C nyelv által támogatott Bit field adatstruktúrával érik el, amivel egy byte vagy word egyes bitjeit definiálhatod külön, és hasonlóan mint egy struktúra elemeit éred el xxx.yyy formában.

Másik hasznos dolog a uni-on (kötőjel nélkül, de a fórum motor megőrül, ha úgy írom be, a lenti példában is!). Ezzel a ugyanazt a adat típust többféleképpen is definiálhatod. Például két byte-os word-ot elérheted hi és lo byte-ként, vagy egyben. Példa az sdcc-ből, de a Microchip is biztosan hasonló:



A TRISA regiszter-r elérheted TRISA-ként, ami mind a 8 bitet jelenti, elérheted TRISAbits.TRISA-ként, ami a használt 7 bitet jelenti, és elérheted bitenként is TRISAbits.TRISA0-ként.

Fontos, hogy a 1 bites mezőket bitműveletekre fordítja, legalábbis ha optimalizál, de a több bites mezők ilyen forma elérése az költségesebb, több utasítás lesz belőle.

Úgy látom valami teljesen kiüti a fórum motorját a válaszomban Most írom negyedszer....

Öröm látni, hogy kezdőnek nézel, aki sosem látott/használt még bitmezőt, struktúrát, vagy uni(o)nt ))))))

A kérdésem alapvetően arra vonatkozott, hogy hogyan kap konkrét, adott címet a struktúra, amire az általad beidézett kódrészletben van is utalás, amiért köszi!

Érdekes, hogy az aktuális projekt p33EV32GM002.h állományában erre semmi utalás nincs..., fölötte csak az xc.h-van, alatta csak egy stdint.h, amiben nincs semmi ezt érintő dolog....

Talán mert úgy tetted fel a kérdést:



Ebben sehol nincs benne, hogy azt nem érted, hogy hogyan van az adott változó az adott memória címre definiálva. Ennek viszont semmi köze a bitfield-hez.

Én nem is említettem bitmezőt! Struktúra szerepelt a kérdésemben, melyet azzal kezdtem, hogy a periféria regiszter (amik ugye fixek)címeire hogyan....??!! Nem az volt a kérdés, alapban hogyan tudok fix címre definiálni ilyen olyan változót(bitmezőt/struktúrát/uni(o)nt)

A struktura elemei? Ez nem hagyományos struktúra, hanem bitmező, ha nem is említetted nevén. De mindegy, ezt te úgyis jobban tudod.

Egyébként a linker script-ben vannak megadva, hogy melyik melyik címre kerül.

Bingó! Tudtam, hogy valahol már láttam őket.... Ennél a projectnél, mivel nem módosítom a linker script-et, nincs is becsatolva a project fájlok közé, ezért nem jutott eszembe ott megnézni...
De ez csak egy mellék kérdés volt az eredeti problémához, mert a címek azok ismertek voltak eddig is. Csak azt nem láttam, hol rendelődnek hozzá?!
Közben talán megoldódni látszik..., elvileg gcc a fordító(VisualGDB alól), de valamiért nagyon nem akar menni bizonyos definiálási mód. Kínkeservesen találtam egyet, amit megeszik, legalábbis hiba nélkül lefordul..., de hogy jó e, azt majd csak akkor tudom meg, ha fel is töltöttem a mikrovezérlőbe.

Sziasztok!

Segítséget szeretnék kérni:
Adott egy szériában gyártott termék, (nem írhatom le hogy ez mi) amiben a controller szerepét egy PIC18F26K22 tölti be.
Mikor ebből egy hibás darab visszaérkezik garanciában, össze kellene hasonlítanom a rossz példányon található adatot, egy jó darab adatával.
A kérdés, hogyan tudnám letölteni a PIC-ről a rajt lévő adatot? (lehetőleg az áramkör megbontása nélkül)
Mi az ami kell ehhez? Egy PICKit3 programozó elvileg elérhető, de még nem használtam.
El tudná valaki magyarázni a pontos módszert?

És végezetül: PIC-ek terém teljesen "kopasz" vagyok.... Atmegát, és STM-et már programozgattam, készítettem néhány áramkört, de PIC-el még nem, így nem ártana a szájbarágás...

Az áramkörtől függ, hogy ki lehet-e egyáltalán olvasni belőle az adatot úgy, hogy nem forrasztod ki a helyéről, anélkül csak annyit lehet mondani, talán megoldható. A második kérdés az, hogy a kódvédelem be van-e kapcsolva arra a területre, amelyikre kíváncsi vagy. Ha igen, akkor kár is kiforrasztani, nem lehet kiolvasni belőle az adatokat.

Szia!

Mindenképpen kipróbálnám... A fent említett PICKit3 alkalmas lehet a feladatra? A kódvédelem biztosan nincs bekapcsolva, a gyártási folyamatban közvetlen a felhasználás előtt is kell beleírni az epromba...

Elsődlegesen nem a PIC-en futó program érdekelne, hanem az eprom tartalom....

A kódvédelem a kiolvasást gátolja meg, ettől függetlenül írni lehet a PIC-be.
Mellékletben a bekötés. PICKit 3-mat az MPLAB nevű program kezeli.

Köszi! én is pont most nézegetek egy régebbi leírást, ebben még PICkit2-t használ...
Valami ilyesmire lenne szükségem:
MPLAB
61. oldal.
Ha erre képes, az nekem elég lesz. Holnap elkérem a programozót, aztán meglátjuk....

A régi MpLab 8.xx és a PICkit2 is támogatja a PIC18F26K22 -t.

A titoktartás indokolt ilyen esetben, mert elég rosszul veszi ki magát, hogy szériában gyárt egy cég termékeket és nincsen ott senki aki értene hozzá.

Néhány támpont:
- a szoftver az utolsó ami magától megsérül a PIC-ben (leszámítva a hibásan megírt bootloader esetét)
- a szoftvert nem kiolvasással szoktuk ellenőrizni, hanem valamilyen ellenörzőösszeggel, pl. CRC használatával.
- Ha már azt sem lehet tudni, hogy milyen szoftver van a processzorban, akkor a következő verzió küldjön ki egy verziószámot kijelzőre/uartra amikor indul a SW.

amúgy meg ilyen helyeken jobb nem vállalni munkát még pályakezdőként sem, mert nincsen meg a fejlődés lehetősége...

Én úgy gondolom, hogy ha egy cég szériában gyárt valamit, akkor vagy saját maga fejlesztette vagy licenc alapján gyártja.
Mindkét esetben ismert a fejlesztő. Én is fejlesztéssel foglalkozom, bár nem elektronikával. De furának tűnik, hogy létrehozok egy terméket és a garanciális belső vizsgálatra semmi támpontot nem adok a saját kollégámnak a termékről.
Szerintem a fejlesztővel kéne felvennie a kapcsolatot pajesz66 -nak.

EEPROM tartalomról volt szó. Lehet, hogy ott tárolódik pl. az üzemóra, bekapcsolások száma stb. Talán garanciálisan akarnak javíttatni valamit amit messze a tervezett/engedélyezett mód felett terheltek.

Egyébként egyetértek, Eelktro.on kollágával is. Milyen hülyeség az már, hogy a gyártó a hivatalos (?) szervíznek nem ad infót...

Ja, látom. Egy későbbi hozzászólásban elhangzott ez is.
Akkor itt valami olyasmiről van szó, hogy a szakszerviz reverse engeneering módszerekkel próbálja a készülék hibáját felderíteni...

Sziasztok!

Huh... most látom mennyi hozzászólás érkezett...
Az, hogy a fejlesztéstől mennyi információt kapok a készülék debugjához, az egy vicc kategória. A fejlesztés külföld, csak a legszükségesebb infókat osztják meg. Aki dolgozott már multinál, az szerintem tudja miről beszélek.

A problémámon egyébként pontosítanék: Nem a szoftvert, hanem az eprom tartalmat kellene ellenőriznem, mivel a gyártás során is kerül az epromba ilyen-olyan információ, illetve a vevőnél is tovább programozódik a cucc különféle kalibrációs adatokkal, és egyéb beállításokkal.

A PICKIT már itt van az asztalomon, most telepítem az MPLAB-ot.
Kérdés: az eprom kiolvasásához kell-e bármi egyéb külső alkatrész (pl kristály az órajelnek?), vagy a fentebb vázolt "egyszerűen rákötöm" a programozóra az elég?

Szia!

Csak a programozóra rá kell kötni a chip-et magában vagy akár megfelelő áramköri környezetben ( ICSP) és működik a programozás vagy a kiolvasás ( ha nincs a kódvédelem bekapcsolva!)!

Nem kell hozzá kristály. Tápfesz az MCU-nak viszont kell.
akkor tudod kiolvasni az eepromot, ha nincsen rá bekapcsolva a kódvédelem.
Először a konfig biteket próbáld kiolvasni.

Szia!
Megtörtént... Ez most még egy teljesen nyers IC (QFN28 tokban ) pickiten a status led sárga, az epromviewer végig tele van FF-el...
Pickiten status led sárga.
Honnan tudom, hogy rendben csatlakozva vagyok-e az IC-hez? Ha a configurations bits-nél látom a csatolt képet akkor ok?

Még nem OK... lehúzott kábelekkel is tudja ezt

Window menü -> Target Memory Views -> EE Data Memory

Az ablak bal oldalán találsz egy ikont (ha minden igaz, az első): Read Device Memory

PK2 nél miket kellene kicserélnem hogy Vcc amperben erősebb legyen?
1 x már 1-ik alkatrésznél megerősítettem. De már megint gyenge a Vcc m.
esetleg 1 képen, ha valaki tudná mutatni. Kössz