Hát az adatlapban mindig talál meglepő dolgokat az ember! Én pl. mindig azt hittem, hogy a hosszabb konverziós idő a jobb, erre most kiderült az adatlapból (számomra is újdonságként), hogy épp ellenkezőleg, a lehetséges minimumra kell szorítkozni.

Ha a mérendő jel gnd-hez képest -300 és +300mV közt fog ingadozni, akkor kell egy MCP1525 referencia, amihez képest majd 2,2 és 2,8V közötti jelet kapok, igaz?

Szerintem egy műveleti erősítő is kell, ami a jelszint eltolását elvégzi. Az MCP1525 csak egy referencia jelet ad, mint egy normálelem, vagy mint egy precíziós feszültségstabilizátor.

Ja, különben nagyon szívesen!

Úgy látszik van aki azt hiszi, hogy ez a topic egy gép. Be kell dobni egy kérdést és kijön válasz. Ha kijött, lehet dobni a következőt. Lehet, hogy bennem van a hiba...

ejj-ejj

Meg tudom oldalni egyedül is, csak ilyen feladatot még nem csináltam és lehet, hogy a harmadik nekifutásra fog normálisan működni, meg tízszer annyi időm megy el segítség nélkül. Egyébként meg mi értelme egy fórumnak, ha minden benne van az adatlapokban, elektrokönyvekben, stb? Elolvasok 6000milliárd oldalt és mindent tudni fogok. (kivéve, ami nincs benne)

Amúgy kösz.

Érdekelne mintakapcsolás, hogyan célszerű megoldni ezt a -300 - +300mV közt ingadozó jel PIC AD-re vezetését, ha nem túl megterhelő.

Lásd: Műveleti erősítők (angol). Nekem az 5. számú neminvertáló összeadó tetszik. Két bemeneted lesz: v1 és v2. Ha nem számoltam el, akkor ha minden ellenállás egyforma értékű, egyszeres lesz az erősítés.

De ha pontos mérés kell, akkor ennél kifinomultabb megoldás kell: pl.a 0.3V-os jeledet erősíteni kellene...

Kár hogy nem érted mi a bajom
Amúgy meg old meg egyedül...


Lehet, hogy még is érted mi a baj? Már nem szívesen!

Az 5. számú megoldással az a baj, hogy ha a mérőbemenetet a levegőben lógva hagyod, a másik ágon pedig megkapja az összeadó a 2.5V referenciát, akkro nem 0 lesz a levegőben lógó bemenet potenciálja. Azaz a 0V-ra kötve a bemenetet is áram fog folyni a bemeneti ponton. Ez egy mérőműszernél nem szerencsés.

Jobb megoldásnak tartanám, ha egy dupla műveleti erősítő egyik fokozata lenne egy követőerősítő (3. verzió), netán valamekkora erősítéssel bíró, nem invertáló fokozat (2. verzió), majd ennek a kimenetét követné az 5. verzió szerinti összegzés a 2.5V-os referenciával. Ennek a dupla OPA-nak viszont kell dupla tápfeszültség, azaz olyan típust kellene kiszemelni, ami pl. +5V és -5V tápfeszültségekkel jól működik. A -5V-ot elő lehet állítani akár a PIC egyik PWM kimenetének segítségével is, de be is lehet építeni egy ICL7660-ast vagy hasonlót. Ha netán van az áramkörben RS232 kommunikáció miatt MAX232, akkor onnan is lehet "lopni" + és - tápfeszültséget is az OPA számára.

Megjegyzem, ilyen megoldásoknál a 2.5V-os referenciát is érdemes bevezetni egy másik A/D bemenetre, és minden mérésnél a referenciát is megmérni, majd abból visszaszámolni a valós feszültségértéket.

Arról még nem hallottunk eddig, hogy mi is lesz ebből... A kívánt (kissé perverz) méréshatár alapján nekem valami fixen bekötött ketyerének tűnt.

Valóban, jobb lenne egy bonyolultabb megoldás, csak pont a bonyodalmakat akartam elkerülni....

Hajszálra ugyanez jutott az eszembe, csak már nem érdekel...

hello!
Pic cikkben talált programokkal szórakoznék, JDMet megépítettem PIC16F876om van, kiolvastam, majd írtam egy hexet a chipbe. Minden ok azt mondta a IC-prog. Topi féle cikkben lévő asm programot átírtam mivel abban a D portra vannak kötve a ledek. Nekem meg csak C van átírtam a programot, hogy a C portra hívatkozzon, de semmi, azonban ezt kiírta a mplab:
Message[302] C:\PIC\INPUT\MAIN.ASM 16 : Register in operand not in bank 0. Ensure that bank bits are correct. Mellékletben ott a hex...
Mit a gond... Köszi
Krisz

Ebben igazatok van, én csak próbáltam rávilágítani, hogy merrefelé érdemes továbbgondolni, ha mégis valami "komolyabb" dolog lenne belőle.

Ez csak egy figyelmeztetés, ami arra vonatkozik, hogy a fordító nem biztos benne, hogy az adott helyen jól állnak-e a bankválasztó bitek, ugyanis nem a bank0-n van a megcímzett regiszter. Ha a progidban helyesek a bankváltások, akkor az ilyen figyelmeztetéssel nem kell foglalkozni, ettől még lefordul a progi. Hiba esetén nem is fordul le.

Sziasztok! Olyan kérdésem lenne, hogy valaki nem alakította e még át hőmérő funkciósra ezt az órát? és ha nem, akkor válalná e valaki azt? előe is köszi a válaszokat!!!

Szeva!

Mplab sim szimulátorban futattva jónak tűnik a kód, lehet hogy a panelon van a gond?
A hiba üzenet szerintem csak egy figyelmeztetés hogy bank váltásra van szükség amit meg is teszel , csak az mplab nem figyel elég jól

Ha zavar írd be a config utáni sorba:
ERRORLEVEL 0, -302

16F887 & 44pin demo board -al kellene egy asm programot írnom ami egy potméter állásától függően változtatja egy led fényerejét.
Eszközöm nincsen, ezért marad az mplab és a próbálgatás. (Bár ez így elég kétséges)
Ahogy olvasgattam a 16f887 sheetjét szerintem ezt ADC-vel és PWM -el kellene megoldani.
A mellékelt file egy példa file az A/D-ről, ezt kellene kiegészítenem, a meghatározás alapján a pwm-el ha minden igaz.
Az igazat megvallva nem szeretnék nagyon belemélyedni a programozásába

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

Innen nekem is sikerült.

Mestereim! Miért jó nekünk az, hogy a PIC18 családban már szoftver verem is van? Mire jó az? Mondjatok egy érthető példát! Köszönöm! goo

Melyikben van?

Nem arra gondol, hogy egy írható/olvasható verem-státuszregiszterben vannak a jelzőbitek ? Vagyis a programból lehetséges a verem kezelése, de attól ez még hardveres.

( Kónya könyvből ez derült ki nekem legalábbis. )

Kónya írja a weblapján: "megjelent a szoftver verem, és az azt kezelő utasítások..."

Nem szofveres csak bele tudsz "turkálni".Lehet a verem tartalmát és mutatóját manipulálni. Nem haszontalan az ilyen lehetőség. Pl.: egy meghívott szubrutin visszatérési címét meg tudod változtatni, így máshol is folytatódhat a programod. Vagy így is tudsz paramétert átadni a hívott szubrutinnak: előbb beteszed a paramétert, meghívod a rutint. Ott kiveszed a visszatérési címet, majd a paramétert, majd a visszatérési címet visszateszed - vagy előbb a rutin eredményét...

Köszönöm Uraim!

A szoftver verem arra lenne jó, hogy adatokat lehet(ne) menteni benne push utasítással és visszahozni belőle pop utasítással. Rövidebb szubrutinoknál hasznáják gyakran, vagy magas szintű nyelvek függvények argumentumait ezen keresztül adják át. A PIC18 -ban nincs ilyen, 16 és 32 bites családokban van sw verem.

Csepel CNC-n úgy oldották meg a késkopás mérőt, hogy egy mikrofonnal figyelték, mikor ér a kés a megmunkáladó anyaghoz. Ez egy teljesen más, de hasonló elven működő gép, 2 mikrofon van, ez bemegy egy erősítőbe aminek van egy stereo kimenete. Ha erre rádugok egy fejhallgatót, akkor bal oldalon hallom, amit az egyik mikrofon vesz, jobb oldalon amit a másik. Ezt a jelet figyeli egy "hangelemző", aminek relés kimenetei vannak és a relés kimeneteket egy IO kártya figyeli, ami a kimenetek állapota alapján már elvégzi a vezérlést.

Az IO kártya működését már kiváltottam egy PIC-es szerkezettel, eleinte voltak gondok, de már több, mint egy fél éve működik stabilan működik non-stop. Most kellene belőle még egy, de jó volna a hangelemzőt is megcsinálni. Az eredetileg használt ketyere egy svéd gyártmányú számítógépre köthető, programozható profi cucc, de a tudásának a 10%-a sincs kihasználva. Egyszer felprogramozzák és soha többé nem nyúlnak hozzá. Szerintem és a megbízó szerint is ez kiváltható lenne.

Szkóppal már figyeltem a jeleket, határozott, jól látható váltások vannak az események függvényében. 2 probléma van, az egyik, hogy analóg technikához kevésbé értek, a másik pedig az, hogy szinte csak késő éjszaka tudok 1-2 órát foglalkozni a témával. De türelmesek, az IO kártya is hónapokig készült. Ezt úgy igértem, hogy január végére elkészül.

Egy a baj, hogy ez itt a PIC-es topic. Analog illesztésért más topicot kéne keressél. Annyit segítek, hogy olyan illesztés kell, ami a 0-5V tartományba alakítja át a mérendő feszt. Ezt már illesztheted a PIC-hez. Innentől nem PIC-es a téma...

Szerintem nem jól fogalmazott a szerző. Szoftveresen módosítható veremmutató jelent meg.

Bocsanat, hogy kozbe kotyogok, de szerintem azon az oldalon nincs jol leirva, hogy mi az a szoftveres verem! A hardveres verem az hardverrel torteno tamogatast jelent, azaz a verem tartalmanak kezelese "termeszetes modon" tortenik. Pl a CALL-RETURN mechanizmussal vagy a PUSH-POP adat eleressel. Ha ez meg meg van spekelve STACK FRAME tamogatassal is illetve offset cimzes frame eleressel akkor teljes a kep, tulajdonkepp akkor elmondhatjuk, hogy a hardver C nyelvi tamogatassal bir. Ugye a C (de sok mas magas szintu nyelv is) a parameterektol kezdve a visszateresi cimeken keresztul a lokalis valtozokig mindent stacken tarolnak.

Mivel sok MCU-ban ilyenek nincsenek (mert kisporoltak, vagy mert nem gondoltak ra) ezert masfajta verem kezelesra van szukseg - a szoftveres veremre. Szoftveres verem nincs utasitasokkal es regiszterekkel megtamogatva, hanem indirekt memoria cimzessel es index regiszterekkel leemulaljak a stack mukodeset. Mit jelent ez? Hogy egy vagy tobb index regiszter a stack pointer szerepet vallalja fel igy lehetove valik a memoriaban kialakitani egy LIFO buffert ami ugye a STACK megfeleloje.

PIC-en a visszateresi cimek hardveres stack tamogatassal birnak, igy azokkal nem kell torodni, azonban a valtozokhoz es parameterekhez kenytelenek vagyunk szoftveres stackeket letre hozni. Ami miatt a PUSH-POP mechanizmus fontos, hogy a PIC az nem Neumann, hanem egy modositott Harvard architektura, igy ez a hardveres stack (amit call-stack-nek is hivnak ugye mert a fuggvenyhivasok visszateresi cimeit tarolja) szoval ez a stack nem olvashato ki memoria hozzaferesekkel. Normalis eseben a stack manipulalasara nincs szukseg, hiszen teszia dolgat, azonban ha egy RTOS operacios rendszert szeretnenk megvalositani, akkor a taszk valtasokhoz szukseges, hogy ezt a stacket is elmentsuk ill vissza toltsuk mikor bekovetkezik a taszk csere. Nyilvan, ha az egyik taszk hivja B fuggvenyt eppen, megtortenik a valtas es a masik meg eppen terne vissza C fuggvenybol, akkor nem lenne szerencses, ha az elso taszk visszateresi cimet toltene be a Program Counterbe (PC)...

Nagy gond azonban, hogy nincs lehetoseg offset cimzesre igy stack framekre sem. Ez azert fontos, mert igy a lokalis valtozok cimzese meglehetosen nehezkes - tulajdonkepp minden lokalis valtozo elereshez elobb ki kell szamolni az offset es a stack frame-bol a memoria cimet es utana ezt betolteni az index regiszterbe, hogy a valtozo elerhetove valjon. MC18-ban meg is lehet nezni milyen borzalmas kod alakul ki ebbol fakadoan.

Epp ezert van egy harmadik fogalom is, amit gyakran pseudo-stack-nek neveznek, mig az MC18 overlay-nek. Ilyenkor a parameterek es valozok nem stacken, azaz nem dinamikus memoria kiosztassal kezelodnek le, hanem forditasi idoben a fordito felterkepezi melyik valtozot hol erdemes eltarolni, mikor melyikre lesz szukseg, es, hogy melyik memoria rekeszt lehet ujra hasznositani. Pl A fuggveny hivja B-t, majd B C-t, majd C visszater es B hivja D-t. Ilyenkor A es B lokalis valtozoi a memoriaban egymas utan kerulnek letarolasra, ezt koveti a C lokalis valtozoinak terulete. Igen am, de D hivasakor mar a C altal lefoglalt teruletre ninc szukseg, ezert D valtozoi is ugyanezen a teruleten lesznek elhelyezve. Amit pedig ezzel a trukkel nyernek, hogy gyakorlatilag nincs szukseg stackre, stack frame letrehozasara stb, egyszeruen direkt ram eleressel megoldjak a problemat, mig a programozonak nem is kell tudnia mi zajlik a hatterben. Egyetlen gond, hogy ilyen esetben nem lehet rekurziv ill altalanossagban beszelve reentrans fuggvenyeket letrehozni. MC18-ban epp ezert lehet manualisan kapcsolgatni a fuggvenyek elott, hogy az adott fuggveny lokalis valtozoi overlayek-e vagy statikusak avagy stack-esek. Mas fejleszto rendszerekben ezek a dolgok teljesen automatikusan allitodnak, ha a fuggveny reentrans, akkor annak megfeleloen csinalja, amugy pseudo-stack-esen.