De választhatsz 3,072V-ot, akkor pont 3mV lesz egy osztás az 1024-es skálán.

Már ezen dolgozom...

Sziasztok!

Próbálgattam tovább az FT232RL-es RS485-ös kommunikációt, de még mindig nem jöttem rá mi a baj.

Ilyen kóddal próbálkozgattam, szinte nem is lehet elrontani rajta semmit, mégsem jó.
A putcUSART('A') hatására megjelenő adat: 7D 00

#include

TRISCbits.TRISC6 = 0; //(a teszt kedvéért mindkettő kimenet)
TRISCbits.TRISC7 = 0;

OpenUSART (USART_TX_INT_OFF & USART_RX_INT_OFF & USART_ASYNCH_MODE & USART_EIGHT_BIT & USART_CONT_RX & USART_BRGH_HIGH, 129);
// 9600baud: 129

while(BusyUSART());
putcUSART ( 'A' );

Mi lehet a baj? Az FT232 miatt nem kell valamit másképp kezelni szoftveresen, mint mondjuk egy max232-nél?

Köszönettel:
Zoli

Szia!

A könyv: Dr. Kónya László: PIC mikrovezérlők alkalmazástechnikája, 158.o. ( www.chipcad.hu címen megrendelhető). Ebben le van írva a másik módszer, amely alapján a kimeneti jel átlagértéke a PWM-nek megfelelő.
Az én megoldásomnak az a lényege, hogy van egy változód, amit időegységenként megnövelsz és vizsgálsz, hogy 0 =< változó < PWM érték ilyenkor a kimenet '1', ha a PWM=< változó =<255, akkor a kimenet '0' !
Ebben az esetben PWM érték változtatásával változna a kimenet impulzuszélessége!

Steve>>>>

unsigned char PWM_duty=100;
unsigned char curr_=0;

void interrupt() {
curr_++;
TMR0 = 96;
INTCON = 0x20;
}

void main() {
OPTION_REG = 0x88;
TRISC = 0;
PORTC = 0;

TMR0 = 96;
INTCON = 0xA0;

for(;
{
if (curr_ <= PWM_duty)
{
PORTC=0xFF;
}
else
if (curr_ >= PWM_duty)
{
PORTC=0x00;
}
}
}

Erre a kódra jutottam, működik is tökéletesen, csak az a baj, hogy az oszcilloszkóp szerint egy impulzus szélessége 40mSec, ami elég messze van a hardveres PWM néhany uSec-étől.

Feltetelezem 4MHz-es belso orval dolgozol, mert csak akkor johet ki amert eredmeny, szoval; szamoljunk egy kicsit:

TMR0=96, azaz a timer 160-at tud elorefele szamolni mire 255-rol 0-ra atcsordul, tehat at mar kapasbol 160us. Namost ha jol latom a periodul ido a curr_ atcsordulasa, tehat 160*256 = 40960us = 40.96ms = 24.4Hz.

Nyilvan a timeren kellene kicsit csiszolni, nem tudom mekkora a kivant frekvencia?

Mértél linearitást és ismételhetőséget?

Hát, ez nem valami meggyőző kód. Az egész ott kezdődik, hogy c-ben van írva, pedig pont ez az az alkalmazás, ahol aztán tényleg borotvaélen táncol az ember az időkkel.

Fogjuk meg a másik oldaláról a dolgot: tételezzük fel, hogy van egy periódikus megszakításunk, amiben a curr segédváltozót növelgetjük, majd a duty-hoz hasonlítva eldöntjük, hogy az adott kimenetnek 0-nak vagy 1-nek kell-e lennie. Ez a PWM generátor egy elemi lépése, és ha ez az egész az interruptban van, akkor már csak azt kellene tudni, hogy egy ilyen lépéssorozat mennyi idejébe kerül a processzornak. Én egy durva feltételezéssel azt mondom, hogy 256 lépés - ebbe biztos belefér az interrupt elején és végén történő regisztermentegetés- és visszaállítás, meg sok egyéb sallang, ami szükséges, valószínűleg akár több független PWM kimenetet is lehetne kezelni ez alatt az idő alatt, sőt, még akár az is beleférhet, hogy c-ben van megírva a kód.

Szóval a 256-os feltételezéssel élve azt jelenti, hogy 256 utasításonként jöhet az interrupt, azaz 4MHz-es órajelnél 1MHz/256=3906Hz-es ütemben. A PWM kimeneteken a periódusidő abból fog adódni, hogy hány elemi PWM lépésből áll egy periódus, azaz milyen finom a PWM felbontásunk. Ha elég a 0% és a 100% között 16 lépés, akkor 3906/16=244Hz lesz a kimeneti frekvencia. Ez nem valami sok.

Hasonló okfejtésből következően én egy 122Hz-en működő, 32 állapotú (5 bites felbontású) szoftveres PWM-et ütöttem össze LED-vezérléshez egy 16F628-ból. Azt kell mondjam, hogy határeset, a 122Hz világításhoz jó, de a 32 állapot igencsak lehetne több (főleg kis fényerőknél nagy a lépésköz).

A szomorú hír, hogy ha sűrűbbre veszi az ember az interruptot, átütő sikert azzal sem tud elérni, mert ha a negyedére beszűkítenénk az időt, akkor nyernénk 2 bitet a PWM felbontásában, lenne egy 7 bites PWM-ünk, de a proci mással (pl. a PWM-et vezérlő billentyűk lekezelése) már szinte egyáltalán nem tudna foglalkozni, ha egyáltalán nem "harapna a saját farkába" az interrupt. Az egyedüli megoldás az órajel megemelése lenne, de ott is a kb. 4-szeres emelés a reális. Mondjuk 4x-es órajelemeléssel, és az interruptok sűrűségének duplájára növelésével (128 utasításonként) 122Hz-es periódusidejű, 8 bites PWM-et lehet építeni. De kb. ez a maximum, amit szoftverrel ki lehet hozni egy 16F-ből.

Úgy érted Vref=2.048V-on? Nos, a program úgy néz ki hogy sok sok mintavétel bset AD1CON1, #2 utasítás van egymás után. +- 1-2 digit a hiba de ezt betudom annak hogy egy 12V/5W izzó áramát mérem amit egy MOSFET kapcsol. Nem egy stabil referencia fogyasztó

A lienaritást nem tudtam még lemérni mert hát már eléggé este van.
Aztán gondolkoztam egy olyanon hogy lehet nem 1/2, 1/4 és hasonlókkal próbálkozom, mert hát pl megjátszhatom azt hogy:

Pl: 4096/16 =256; 256*7= 1792. Ha ez lenne a referencia akkor az ADCON eredmény*7, majd /16.

Igazából jól le kellene nyomnom a referenciát mert még az 55W-os izzok mellett sem akarom hogy 0,3-0,4Vnál több essen, a mérő ellenálláson...
Nagyon furcsa hogy összesen 2.7-3.6 között választhatok referenciát... Nem tűnik célszerűnek...

Most nézem a táblázatot a referencia feszültséggel kapcsolatban... Azt írja rá hogy nem tesztelik a gyárban... Ahogy esik úgy puffan... Na frankó...

Szia! Igen ASM-ben kéne és meg is mondom miért nem titok szeretnék látni egy példaprogramot egy olyan áramkörre ami egy A/D átalakítást végez (poti feszültsége) majd ugyanez az áramkör (pic) PWM-ben szabályoz egy fetet. Ez lehet egy DC motor vezérléséhez is használni nekem személy szerint egy dimmerhez kellene (a feltöltött "motor.c" fájl is ezt csinálta csak C nyelven ezért kéne ASM-ben) ha tud valaki segíteni nekem azt nagyon megköszönöm. tényleg

Tessék, bogarázd...

Én felteszem ide egy korábbi szoftveres PWM progimat. A PICkit2 44pin demo board-on volt fejlesztve, de a végső verzió egy 12F629-en fut, az MPLAB-ban ki kell választani a procitípust, a feltételes részeket aszerint fordítja.

Ez a progi annyit csinál, hogy egyetlen gombbal lehet változtatni a fényerőt és ki/be kapcsolni a "lámpát". Azaz a gombot nyomva tartva elindul valamelyik irányba a fényerő, következő nyomva tartáskor meg a másik irányba. Rövid nyomásokkal pedig a nulla és a legutóbb használt fényerő között lehet kapcsolgatni (ki/be funkció).

Nagyon szépen köszönöm mindkettőtöknek. Tényleg. Kössz.

Az általuk megadott tartományban biztos jó. Azon kívül csak a próbák adnak kielégítő választ.
Az adatokat nem célszerűségből adják meg, hanem kényszerből. Ennyit lehet biztonságosan kihozni a hardverből. Ha ettől pontosabb kell, külső AD-t lehet használni. Nem látom, hogy ez akkor a gondot okozna.
Az sem okozott nekem még soha gondot, ha nem kettő hatványa volt a ref fesz, sőt, én még ilyet nem is készítettem. Legtöbbször 2,5V a ref feszem, ezt még a 2,7V helyett is megeszi a legtöbb példány.

De lenne hozzád kérdésem.
A MPASM ban simán lehet ilyen állandót(gyakorlatilag stringet) deklarálni a fordítónak:

Az ASM30-ban a .equ lenne a DEFINE helyett, de nem eszi mega fordító ezt:


Próbáltam .macro-val is:

Ezt megeszi a fordító, de amikor használni akarom azt már nem:


Megszoktam már, hogy ilyen jellegű deklarálásokat készítek, de ebben a fordítóban nem sikerül rájönnöm a mikéntjére, már jó ideje.
Neked sikerült már ilyen összetételt létrehoznod?

A másik kérdésem, hogy mit szólsz a W15 Stack kezeléséhez? Milyen dolog a memóriából ellopni területet, mikor amúgy is alig van!? (256 szó az x területen nálam. Persze ez egy nagyobb SRAM-os példánynál nem akkora gond.) Igazán tehettek volna bele néhány 10 Stack memót!
Az már csak hab a tortán, hogy a fordító nem képes ellenőrizni a Stack pointert, hogy hová mutat, és a deklarált változót a 0x800-as címre teszi, ezzel kitéve a felülírásnak, amikor egy megszakítás, vagy szubrutinhívás történik. Még szerencse, hogy van egy SPLIM regiszter, amivel a Stack túllépést detektálni lehet, bár a szimuláció szerint elég furán viselkedik, mert a hiba megszakításának is helyet kell hagyni a Stack memóterületen, hogy a lekezeléskor nem írja felül az első változóinkat. Naszóval vannak érdekes dolgai ezeknek a 16bites PIC-eknek, már alig várom a következőt...

Következő mit?
Stack kezelés: Ez a jövő. Ugyanis a hardver stack korlátozza az ugrások mélységét. A mezei memóriában tárolt meg nem. A deklarálásoknál mindig a cimkével kell kezdeni, utánna kettőspont. Ez minden cimkére igaz amit asm-ben nyomsz. Berakok egy képernyő mentés azon kultúráltabban látszanak a dolgok. EZ az aktuális Autó project-em ma reggeli állása.

11. sorba beraktam a "Gomb" nevű cuccodat. Gomb mögé kell a kettőspont.

Nekem ez a software Stack gondot okozott az ICD2-vel Ő is a 0800 területet akarta használni. 4. sorban látod azt a ".space" nevű részt. Na az az összes kezdő változót felpakolja nekem pl 0A00-ra. Így már nem lesz gondod.

Ezek után 5-10-ig változók deklarálása. A kezdéskor nem értettem hogy a Watch window változó listájában mé nem jelennek meg a saját változóim. 4. sor és az 5-10.-ig mutatott példával megjelennek. Anno kellettek, jelenleg nem használom őket de hogy a forma szem előtt legyen benne tartom. Lásd most neked jól jön.

Ha mindennel megvagy jön egy .text fordító-direktíva. EZ mutatja hogy mot már a kód jön.

Én utánna raktam be a megszakítás kezelőt, de teheted akárhová a helye nem lényeges csak az hogy az egyes megszakítások cimkéi a megadottak legyenek. Tehát bárhová teheted "__ADC1Interrupt:" cimkét csak legyen definiálva előre. Erre van nekem az 1. sor interruptvariables.inc nevű sora. Ez egy txt file amiben az van pl hogy:
.global __ADC1Interrupt

57-70-ig pedig az említett InitStack, utánna az Init_Wregs (ezek kellenek mindenképpen), és mivel én használok DMA-t ezért én a ClearingDMA résszel törlöm a 0x4000- kezdődő részt ami DMARAM is egyben.

Hát röviden ennyi. Ha ez megvan akkor el lehet kezdeni a konkrét inicializációt. Ez a láb kimenet, az meg bemenet, AD konverter, stb stb... Remélem segítettem.

És még valami. Ha makrót definiálsz akkor ott nincs utasítás.

.Macro Gomb Data0, RegNr
mov &Data0&, W&RegNr&
.endm

Ezzel a makróval azt szeretném neked mutatni hogy paraméterezheted is. Igy futtatod:
Gomb #0x0123, 2
Ez így a #0x0123 értéket beleteszi a W2, be mert RegNr paraméterként ez lett megadva.

Mellékelem két képet. A 001 amin van az amiről beszéltem, a 002 meg az ECAN buszom egyik kommunikációs makrója.

Szóval azt hiszem nekem már elég sok minden sikerült benne...

Üdv!
Javasolnám, hogy a képernyőképeket ne jpg-be, hanem png-be mentsd el, így többet látnánk belőle. Kösz!

Ezt megértem, ha van bőven memória, de ebben a PIC-ben nincs(dsP30F2020). Aztán hová kellhet 32 mélységnél több? 18F-nél az életben nem kellett több. De amúgy nem zavar a dolog nagyon, csak fura.


Köszi, sokat segítettél! Tudod mennyi doksit és programot néztem át e miatt? Ebben a formában nem használták, ill. nem adtak példát róla, csak a fenti szintakszisban.


Ezt nem értem. Nem azt akartad írni, hogy utasítás nélkül nem lehet makrót készíteni? Én csak azért próbáltam, mert más ötletem nem volt.
Vagy azt akartad mondani, hogy a makró meghívásakor nincs utasítás a macro Symbol előtt?

Köszi a többi segítséget is, de igazándiból ez az egy gondom volt.

Sziasztok! Kis segítséget szeretnék kérni. Programoznom kellene egy ATmega8 -as AVR-t. Tud valaki valami egszerűen utánépíthető programozót? Bevallom néhány PIC-et már programoztam, de nincs túl nagy gyakorlatom.... előre is kösz mindenkinek! üdv Tibi

:eek2: Elnézted a topikot! -> AVR - Miértek , hogyanok... ez oda való kérdés.

Ezt inkább az AVR-es topicba kellett volna...

Épp tegnap illesztettem bele az "Első AVR programozóm" cikkembe a kiegsézítést, hogy hogyan lehet összeépítés után önmagával felprogramozni, jelenleg még a modik kezében van a módosított cikk, így nem látható (kapcsolások között lesz majd). Abban leírtam a PonyProg használatát, azzal szerintem meg tudod oldani, ha van soros portod.

Először is újra a képeket. Én sosem használtam dSPIC-et. Nem kell szerénykedni. PIC24HJ256GP610. Ez ma a legizmosabb 16 bites. Fölösleges valami kiherélttel ismerkedni mert abba a zsákuccába jutsz a tanulás során hogy ez nincs benne, az nincs benne, és kapufa... Nekem pl tök jól jön hogy két ECAN modul van benne. Az egyikből kijön a másikba bemegy, és eccerre egy laptopon egy ICD2-vel két PIC programját fejlesztem. Az adóét és a vevőét. A végén csak annyi a dolgom hogy a kész programot "kettéfűrészelem" és az egyiket ebbe a másikat abba töltöm bele...

Másodszor. A makró az szó szerint az amit jelent. Te beírod és a linker meg "bután" beírja amit az adott makróban leírtál. Persze ahogy mutattam paramétereket behelyettesítve ahogy mutattam. Innentől kezdve ha neked az van a makróban hogy

.Macro Teszt
easyrideröcsém
.endm

akkor az adott sorba a linker szolgai módon beírja hogy easyrideröcsém, ezek után a fordító meg azt írja hogy easyrideröcsém utasítás nincs.
Ha tehát valahol makrót használsz az egyszerűen csak utasítások halmaza amit te határozol meg.

Tehát pontosan. Makró hívásakor nincs utasítás. CSak a makró neve és mögé a paraméterek a meghatározott sorrendben és formában.

Még valami. Látod a változó definiálásokat a .space -nél. Te adod meg a méretet. Tehát a 160 az 160 byte, de mivel a memória word szervezésű, célszerű hogy kettővel osztható legyen a fentartott érték.
Tehát ami ott 2 az igazából 2 byte, azaz egy word, tehát egy memória rekesz. Ha a view/File registers-t választod és ott alul átkapcsolsz symbolic-ra akkor látod hogy a változó neveket hogy pakolgatja egymás után.

Szia watt,

A #define az egy C preprocesszorbol eredo dolog, ezt az MPASM-be beintegraltak, ezert mukodik csak. Az tulajdonkepp egy behelyettesites, azaz teljesen mindegy mi van ott azt forditas elott a preprocesszor a megfelelo helyre beteszi.

A .equ az mindenkepp szamot var, ezert nem mukodik a PORTB,RB0. A .macro meg hasonloan a #define-hoz makro behelyettesiteses modszer, de azt program reszletekre lehet hasznalni.

A fo kulonbseg a #define es a .equ.macro-k kozott, hogy a #define-t a fordito nem latja mivel a preprocesszor kiszedi azt es a behelyettesitest elvegzi, mig a .equ.macro dolgokat a fordito csinalja meg es resze a nyelv szintaktikajanak is.

Igen, hat epp ezert kedveltem meg a PIC modositott harward architekturajat, mivel a stack teljesen elkulonul a memoriatol. Ugyanis ha ez nem tortenik meg akkor konnyen kaphatunk egy olyan megoldast mint amit pl az AVR is folytat, ahol is a stack alul ill felul csordulasana nincs kellokeppen levedve. Az pedig rejtett hbakhoz vezethet amit csak nagyon korulmenyes megtalalni. Pl a stack felul ir egy fontos adat teruletet, ami csak evente 1x tortenik meg amikor a firmware valamit csinal amit maskor nem szokott. A hibara pedig a felulirast kovetoen fel evre derul csak feny mikor azt a memoria teruletet kiolvassa a firmware egy masik resze...

Van ezekben a 24H/dsp PIC-ekben valami boundary vagy stack frame checking?

A CPU statusz regiszterei között vannak olyan megszakítást jelző bitek hogy Oscillator Fail trap, Address Error trap, Stack Error trap, Math Error Trap, DMA Conflict Error trap.

Most így hirtelen belenézve ennyi. Én személy szerint úgy gondolom hogy asm-ben (lassabban és alaposabban programozva) ilyen hiba nem nagyon fordulhat elő, mert úgyis lépésről lépésre tesztel az ember.

Szóval jelez bizonyos nem tolerálható hibákat. Mindezek mellett úgy gondolom hogy az a program ami mondjuk erősen kihasználja a PIC16 nem tudom talán 15 elemű vermét az rossz program. Nemhiába nem használom a PIC24-ben a "Nested Interrupt" nevű csodát aminek az a lényege hogy megszakítás végrehajtása közben ha adódik valami a jelenleginél is fontosabb akkor kilép az adott megszakításkezelőből, és átlép a másikba... Fölösleges hibaforrás.

Nem akarok szerénytelennek látszani, de nem értem mit nem értesz azon, hogy:
Írtam:

?

Rosszul fogalmaztál és ezért kijavítottalak, erre elmondod ugyanazt mégegyszer.
Ezt írtad először:

Erre írtam, hogy ezt nem értem, és hogy valószínű nem ezt akartad írni és valóban, most ezt írod:

Erről beszéltem. (Írtam: )
Kérlek ne felületesen olvasd amit írtam, mert nagyon furcsán jön ki, hogy olyasmire is válaszolsz, amit nem is kérdeztem, valamint kényelmetlenül érint, hogy ilyesmit kell tisztázgatni, ami szerintem egyértelmű volt.


Ez is egy kicsit furán jön ki, mivel nem tudod miért a dsPIC. Van 24HJ-m(bár ez nem érdekes), de a 30F2020 jobb a célra(kitalálod miben?)

Köszönöm a segítő szándékod, de kicsit elárasztottál a válaszokkal.

Igen van, írtam, hogy a SPLIM regiszterben beállított cím elérése esetén megszakítás generálódik. Ha lefoglal az ember a memó elején területet, és figyel a verem mélységére, akkor talán elkerülhető a felesleges megszakítás.
De egyetértek a véleményeddel, én sem szeretem a közös használatú Stack memót!

Szia trudnai!

Igen, ezt tudtam és írtam is:

Végül is a fordító szintje felett marad, tehát nem fordítódik(abban a sorban ahol deklarálva lett), csak behelyettesítődik a fordítás előtt.


Biztos vagy benne?
zsimon példáját ugyan még nem tudtam kipróbálni, majd otthon, de nekem úgy tűnik hogy nála működik ez:



Szerintem a .macro is csak egy egyszerű szöveg behelyettesítés, elég ha csak megnézed a dissasemblált ablakot... De igazából mindegy, ezen ne rágódjunk...

Én igazából csak a formátumát javítottam ki a Gomb-os dolognak. És amint a képernyőmentésen talán látszik, a fordítás sikerült. Az hogy utána úgy működik e ahogy kell azt bevallom nem próbáltam.