Írásjelek?

Még mi volt ráadva a feszen kívűl?

Egyébként akkor, ha csak a fesz volt ráadva, akkor világíthat. Dugd rá az LPT-re és indítsd el a programot, majd csekkold le a vonalakat. HA rendben ,akkor teheted rá a PIC-et. (korábban többször leírtuk, hogy hogyan kell csekkolni, kérlek keress rá itt a topicban!)

Hello mindenki. Az a "gondom" hogy nem tudom hogyan lehet a microchip C fordítóiban ASMben megírt függvényt hívni.Egy ideig gugliztam de nem találtam rá választ, keresővel itt sem találtam.

Előre is köszi a választ Üdv: Marcell

Hogy néz ki az asm-ban megírt függvény? Benne van a C18 forrásában? pl. így:


?

Addig is egy dokumentáció. A 43. oldaltól írnak a C és ASM keveréséről...
C18 kezelői kézikönyv

Köszi, a linkelt dokumentációban megtaláltam.Még most kezdek átállni Cre és eddig nem sikerült ilyen dokumentumokat összeszednem,végigbogarásznom.

További szép napot!

Szívesen! Azért kérdeztem, hogy hogyan akarod az ASM részt rutinban elhelyezni, mert a doksival ellentétben és más megoldást is jónak látok, és használok. Írok egy C rutint, és abban _asm ... _endasm közé az ASM betétet. Így végül is ASM rutint hívok meg. Kicsit sántít a dolog abban, hogy ekkor a függvény meghívásához szükséges tárolások miatt több időbe telik, mint ha direkt hívná meg a doksi szerinti módon. Bár ebben nem vagyok teljesen biztos, össze kéne hasonlítani a két megoldást.
Naszóval az én megoldásom:


trudnai biztosan tudja a feltett probléma mögötti dolgokat is, talán...

Tényleg ez így elég áttekinthetőnek tűnik, és valószínűleg annyira "nem bonyolítja el" a fordító sem

Lehet vele játszani ésa lefordított kódot disassemblálni. Érdekes megoldásokat vonultat fel a fordító sok esetben... Van mikor ez számít, van mikor meg nem.

Legotbb esetben ha valaki C nyelvet valaszt a leforditott kod hatekonysaga mellek szerepet jatszik es eloterbe kerul a gyorsabb fejlesztesi ido valamit a kod hordozhatosaga - persze ezeken is lehet vitatkozni, hogy valoban gyorsabb-e egy C-ben fejleszteni, mindenesetre nem kell eltoprengeni ket 32 bites szam osszeadasan, hogy hogy is megy az. Hozzatennem sajnalatos, hogy Microchipek nem ajanlanak egy nagy asm rutingyujtemenyt amivel a mindennapi munka megkonnyulne es ilyen alapveto dolgok mint matematikai vagy logikai muveletek, LCD kezeles, belso periferiak kezelese stb ezek siman mehetnenek ugyanugy konyvtarakbol mint a C eseteben.

(remelem nem inditok tuzparbajt itt, tavol alljon tolem)

Rádugtam a portra majd elindítottam az oshonsoft programot. A hardware/check -ben bepipálom a vdd-t akkor a vdd led világít ha a vpp-t akkor a vpp led. A többi vonalat hogy tudom ellenőrizni? Voltmérővel, leddel? Bocs a kérdésért de hiába használtam a keresőt nem kaptam meg a kérdésemre a választ, de lehet hogy én nem értek a keresőhöz.

Mivel igazad van, így nem indítasz párbajt. Én is vegyesen használom a C-t, mert vannak előnyös tulajdonságai, viszont sokszor nem hatékony. Ilyenkor jön az _asm.

Természetesen. A LED is megoldás, csak akkor a katódja menjen a kimenetre, és az anódja egy 1K-n keresztül az 5V-ra. (mivel OPC-s a kimenete a 7406-nak.) Akkor fog világítani a LED, amikor nincs becsekkolva a vonal!!!
Az is egy megoldás, hogy a LED katódját testre teszed, az anódján a kimenetre. Így már akkor fog világítani, amikor a pipa be van téve a checkboxba. Azt hiszem ez a verzió egyszerűbb is, ezért ezt ajánlom inkább...

De ha open collectoros a kimenet akkor nem biztos, hogy a volt mero igy onmagaban jo otlet. Ahhoz akkor kellene egy felhuzo ellenallas minimum a kimenetre.

Van felhúzó ellenállás(nézz rá az oshon kapcsolására). A Vdd-t be kell kapcsolni mikor a kimeneteket mérjük, hogy a felhúzók feszt kapjanak. A sima LED-es mérés is csak Vdd bekapcsolása után mehet..

Üdv!

Az elmúlt napokban összeütöttem egy IEEE754 kompatibilis lebegőpontos számolást a 4 alapművelettel 12F683-ra (tulajdonképpen bármelyik midrange-re jó). Ez ahhoz kell, mert építettem egy hőmérsékletfüggő ventiszabályozást, amiben a hőérzékelő egy LM335Z, azaz a hőmérsékletértékek A/D-zve jönnek.

A munkapadon a mintapéldány nagyon szépen viselkedett, de egy PC-s tápba beépítve azt tapasztaltam, hogy időnként felugrik, időnként le a vent fordulatszáma - valahonnan zajt szed össze. Ennek a zajnak a kiszűrésére egy digitális szűrőt programoznék bele, ehhez is kell a floating point aritmetika.

Viszont jó lenne ezt az egészet tesztelni, akár csak MPLAB szimulátorban. Kellene előállítani valami zajjal terhelt bemenetet, amit a szimulátor megkapna, aztán a kiszámolt kimeneti értékeket jó lenne lelogolni, hogy utólag ki lehessen elemeztni a szűrő működését.

Erre tud-e valaki útmutatást, hogy hogy lehetne ezt a szimulációt megoldani?

Nem tudok róla, hogy zajt lehet szimulálni, de ha tévednék, az nagyon meg fog lepni, és örülni is fogok, mert sokszor jól jött volna ilyesmi...

Nekem még az sem teljesen világos, hogy analóg bemenetet hogy tudnék szimulálni. Tegnap olvasgattam az MPLAB pdf diksiját, de ilyenre nem láttam utalást, ma meg annyira ki vagyok pukkadva, hogy még el sem indítottam az MPLAB-ot

Amúgy lehet, hogy valami külső megoldást kellene találni, mondjuk excelben legyártani az analóg értékeket egy oszlopba, meg a zajt egy másikba, és a kettő összegéből csinálni valahogy kimenetet, amit be lehetne adagolni az MPLAB-nak - de ez mind csak elmélkedés, nem tudom, hogyan álljak neki, azért is kérdeztem, hogy hátha valaki már legalább hasonlót csinált, és van rá ötlete.

Mondjuk én nem a jel zajmodellezésére gondoltam, hanem a tápon beszűrődőre. Nem is biztos, hogy a jelen jön be neked a zavar...

En ugy tudom az SCL-bol lehet regisztre injekciot csinalni. Ha van ilyen tablad abbol csak generalni kell egy SCL filet es kesz is van a trukk. Digitalis jellel ezt csinaltam, WAV-ot alakitottam at SCL-e, es persze a WAV a szgep audio bemenete volt mint scope Az a bajom meg mindig szivok a virtualis gep belovesen, ha tul vagyok ezeken akkor lesz MPLAB meg minden es akkor tudok ilyenekkel foglalkozni. Addig ha a Microchip foruman rakeresel biztosan megtalalod az SCL-rol szolo anyagokat, VHDL meg SCL kulcsszavakra rakeresve.

Végülis mindegy, hogy hol jön be, azt a jelre is áttranszformálhatjuk.

Amúgy a tápot egy lokális 78L05 állítja elő a 12V-ból, persze megfelelő szűrőkondikkal, szóval azt nem hinném, hogy a tápon jelentkezik a zaj. Az érzékelő amikor közel került a hűtőbordához, akkor keletkezett a zavar - ezen a bordán vannak a nagyfeszültségű rész kapcsolótranzisztorai.

A program úgy működik, hogy vesz egy A/D értéket, az alapján kiszámolja a kitöltési tényezőt a PWM kimenetre, aztán várakozik jópár tized másodpercet, majd kezdi elölről. A jelenség pedig úgy néz ki, hogy hogy időnként a hőmérséklettől hallhatóan eltérő fordulatszám áll be. Mivel a ciklus jópár tizedmásodpercenként kezdődik újra, ez a fordulatszámváltozás jól hallható. Ezt akarom "kisimítani" a szűrővel.

Vedd néhány előző kiszámolt érték átlagát, és akkor egy ilyen kiugrás nem fog bezavarni.
Ferritgyűrű a mérővezetéken?

Ahogy eddig láttam, az ilyenre a legjobb módszer a Proteus és az MPLAB házassága, csak az alkalmazott kontroller nem biztos, hogy megvan a Proteus-ban...
Egyébként csak a regiszter-betöltés marad, triggerként pl. egy PC-értékkel (mielőtt beolvasná a konverzió eredményét), és készíteni kell hozzá egy zavarjellel ellátott adatfile-t, erre talán leggyorsabb egy Excel makró, véletlenszám-generálással két határérték között.

Igen, ez egyfajta digitális szűrő, de én szeretnék egy korrektet és hangolhatót építeni - lehet, hogy itt most nincs túl nagy értelme, de talán a megszerzett tudás és tapasztalat felhasználható majd később máshol is.

Aki meg nem hallott volna rola, a Microchip hivatalosan bejelentette, hogy elkeszult a PicKit2 parancssori valtozata Linuxra es MacOS X -re...

Letoltheto innen.

Igen, most olvasgattam még kicsit a dolgokat, tegyük fel, hogy valami táblázatkezelőből vagy akár vbscript-ből elkészítek egy olyan stimulust, amit be tudok adagolni a programomnak. Ez lehet regiszter injekció is, de nem feltétlenül az ADRES-be, mert azt a normál futás mellett állandóan felülcsapja az A/D használata.

A programot a szimuláció idejére simán átírhatom annyira, hogy ne az ADRES-ből, hanem egy másik regiszterből dolgozzon, amit a stimulus feltölt bizonyos időpillanatokban.

Tehát tételezzük fel, hogy a bemenet megoldódik.

Ám jön a másik kérdés, hogy kimenetet hogyan tudnék logolni MPLAB-ban? Akár csak annyi, hogy egy erre a célra bevezetett regiszter értékét bizonyos szimulált időpillanatokban vagy a program bizonyos pontjára lépve a szimulációban letegye egy log-ba, Ilyet, vagy ehhez hasonlót tud egyáltalán az MPLAB sim?

Még nem próbáltam, de a Register Trace elvileg erre való, file-ba menti (adott esemény hatására) a kívánt regiszter tartalmát.

Hát, roppant fapados, de a register trace-t sikerült életre keltenem egy minimál tesztprogival. Úgyhogy még lehet, hogy lesz is ebből a szimulációból valami

Lecsekkoltam a vonalakat. Már csak egy valamit nem értek. A Vpp-t a MCLR lábra, a Vss-t a gnd, a Vdd-t a pic Vdd lábára kell kötni. Az Lvp, Data és a Clock kimenetet a pic melyik lábára kell kötni? 16F84A-t akarok programozni. Az adatlapját hiába nézem nem leszek tőle okosabb.

Az RB6 az órajel (Clock), az RB7 az adat (Data), ezeket pedig leírták az adatlapban. Az Lvp akkor kellene, ha alacsony feszültségű programozást csinálsz, vagyis ha a 13 V-os Vpp helyett az 5 V-os, normál táppal akarnád felprogramozni, de ezt a 84A nem is támogatja, vagyis nem kell bekötni.

Köszi.