Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Úgy mondanám, hogy egyenszilárdságú a pic -beli uart egységgel...
Szerintem inkabb orulj, hogy egy programozoval lehet ilyeneket csinalni! Szerintem nagyon jo, hogy Microship ezt egyaltalan megcsinalta
Na a MCHP kirukkolt egy uj Free C forditoval. A MPLAB XC egyenlore 8 es 32 bites valtozatban toltheto le, de hamarosan kijon a 16 bites valtozat is.
Szia! Úgy látom ugyanannyira free, mint a korábbi, azaz az optimalizációs szint gyengébb a free-ben. Remélem mindent módosítottak, hogy könnyű legyen átállni!
Mesterek! Valami baj van az MPLAB szimulacioval. (MPLAB 8.84) MPSIM alatt nem tudom billegtetni a PCON, ULPWUE bitet. Mindig "0" marad. Mar vagy 3 programot probaltam (CCS C), az ASM listaban benne van a BSF utasitas, es nem tudom "1" szintre billenteni. A Watch ablakban sem csinalja.
Reszlet az ASM listabol.
Szia!
Nincs itt gond semmi. Dokumentáltan nem szimulálható. Debugger / Settings / Limitation fülön a Detail gomb előhozza a határokat leíró help oldalt, arról nyíló General Limitations fejezet alulról 3. mondata: Idézet: „Ultra Low Power Wake Up Enable (ULPWUE) is not supported by the simulator”
Kosz, de legalabb a bitet billegtetne. Na mindegy, ez felejtos.
Stimulus / register injection vagy SCL stimulus lehet a megoldás.
Na ez vajon miféle alkotás ? A felvásárolt Hi-Tech tudása van benne ? Nagyon úgy tűnik nekem, olvasva a doksiját. Nem is baj mindig is szimpatikusabb volt a Hi-Tech féle fordító nekem. Valahogy sejtettem hogy ez lesz, dobják a sajátjukat mikor meglátják hogy mennyivel jobb amit megvettek.
Helló mindenki!
Analog mérőket eddig simán úgy átlagoltam hogy mértem és folyamatosan összeadtam az utolsó mérésnél osztottam a mérések számával! Itt a fórumon kaptam régebben a tippet, hogy az igazi az lenne ha pl: 50 mérek abból 10 legkisebb ill 10 legnagyobb kuka és a maradék harmincat átlagolnám! Ezért a méréseket egy tömbe szeretem volna gyűjteni aztán rendezni átlagolni. A probléma következő int meres1[50]; int meres2[50]; eddig még ok innentől már a többit nem veszibe a fordító Pedig memória az bőven van 1536 ból 522 foglalt a két tömbbel értelem szerűen 722 gondolom a 3 lenne 822 és így tovább mivel az int 2 bájtos én meg 50 szeretnénk! Azt hiszem memória bankolás gondom van! Ez a szöveg Error - section '.udata_nap.o' can not fit the section. Section '.udata_nap.o' length=0x0000014e Errors : 1 A fordítót próbáltam állítgatni de valami nem ok Ja C ben írom a progit asm ül nem tudok de ha ezen múlik bele kaparok egy betét
Csinált valaki tesztet erről a mintaeldobásról ? Én nem vettem észre semmilyen különbséget az eldobásos és sima átlagolós módszer között. Az utóbbihoz ráadásul sokkal kevesebb memória is kell, hiszen csak gyűjteni kell az összeget egy nagyobb változóba, és a végén elosztani. Én úgy csinálom hogy a kijelezni kívánt értéknél 1 digittel nagyobb pontosságot érek el sok érték átlagolásával, és utána csak akkor változtatom meg a kijelezni kívánt értéket, ha van egy bizonyos eltérés az előzőhöz képest. Így nem ugrál. 25V os méréshatárnál századvolt pontosságú, ugrálásmentes kijelzést csináltam így 12 bites adc vel.
Amúgy milyen fordítót használsz ? Milyen pic, stb ?
Az eldobásos akkor jó, ha beesik egy abszolút fals mérés, valamilyen külső zavar miatt.
Na jó, beleesik egy + impulzus, de zavar jön a - irányba is nem ? Ha meg nagyon sűrűn beleesik, és nem szimetrikus, akkor meg bele kéne mégis csak számítani nem ? Mert különben hamis lesz a mérés a feszültség valós értékét tekintve.
A múltkor éppen ezt tárgyaltuk, és akkor is azt pedzegettem, hogy ha nem tudjuk mitől van az eltérés, akkor milyen alapon hagyjuk azt ki?
Szépen mutató műszert, vagy "jó" műszert szeretnénk? Ahogy lidi is mondja, az egyszerű átlagolás is tökéletes, a várható érték torzítatlan becslése. Egyébként ennyi erővel a vett minta mediánját is vehetnénk. Tessék, gyors, egyszerű, osztani sem kell. Kit érdekel a lehetséges aszimmetriából adódó probléma, az elhagyásos módszernél is felmerül, mégsem izgatjuk magunkat?!
Az átlagolás a normál eloszlást követő mérési eredmények "legvalószínűbb" értékének meghatározására szolgál.
Az eldobós módszernél feltételezzük, hogy az adatok között olyan is előfordul, ami nem statisztikus ingadozás, hanem valami zavaró effektus következtében tér el az átlagtól. Például fel- vagy lekapcsoltak mérés közben egy villanykapcsolót a közelben. Ennek is lehet értelme, de túl sok adatot nem érdemes elhagyni, mert az már torzíthatja az eloszlást, s így az eredményt is. Ha az eloszlás nem a normál eloszlást követi, akkor egyik módszer sem jó a fentiek közül. Ha vannak fizikai ismereteink a vizsgált jelenségről, ismerjük az eloszlás alakját, akkor jobb módszer az eloszlás paraméterinek meghatározása (fittelés) és ezekből a meghatározott paraméterekből fizikai mennyiségek meghatározása.
Sziasztok Istenek!
Tudom lustának tűnhetek, de lenne pár kérdésem (kérésem) hozzátok. Van 1 kv-főzőm GE panelen egy pic 18f452 kontrolerrel bekapcsolt védelemmel. Azt szeretném megtudni, hogy hozzá lehetne-e jutni ehhez forráskódhoz esetleg asm-ben, mivel csak egy LCD-t szeretnék rárittyenteni+ pár helyen módosítani. Ha nem kénytelen leszek az egészet megírni, és nescafén élni egy darabig. Minden segítséget előre is köszönök: picimi
a) verzió: megkéred azt, akinek megvan a program (pl. az írója), hogy adja oda
b) verzió, belenézel: http://break-ic.com/topics/break-ic.asp
Sziasztok!
a, ha közöttetek van az írója lécci adja oda léccí lécci  .b, Ez igen durva.  c, asszem írok.  Köszönöm a segítséget,ha látott valaki már ilyen progit minden tippet szívesen fogadok. Köszi köszi köszi: hűséges alattvalótok.
Sziasztok! Kis segítség kellene PIC ASM -ben. Manchester dekódolással van problémám....valaki tudna segíteni,hogy hogyan kell dekódolni a manchester kódot?
ATMEL doksi
Csak átfutottam de amint láttam van benne elméleti s gyakorlati rész is(csak C-ben). Megtudhatjuk miért olyan fontos az assembly?
Amikor elkezdtem a pic-ekkel foglalkozni akkor ccs-ben kezdtem...a kezdeti sikerek után megállt a tudomány nálam....először könnyűnek tűnt (semmit nem tudtam a c-programozásró), de a "komolyabb" programoknál sajnos zsákutcába futottam! Azután tértem át az ASM-re ami nekem jobban tetszik! Szóval egy szónak is száz a vége: Nekem az ASM a szimpatikusabb
Köszönöm válaszod!
Fűtés ill. HMV vezérlés mp enként mérek egy nagy eltérés csak mérési hiba lehet / ha nem kilyukad a tartály, akkor a vezérlés a legkisebb gond / ezért gondoltam, hogy az eldobós a jobb. / De a te módszered is jól hangzik mindenképp átgondolom hogy inkább negyed fokba tároljak és átlagoljak aztán egész fokra alakítás/ DE ETTŐL függetlenül szeretném tudni akár máshoz is jó lehet, hogy miért nem használhatom a teljes memóriát PIC 18F4520 1536 bájt memória melyből csak 722 ig megy a dolog MPLAB szerint / 8.10 / a fordító C18 3.10
Köszönöm válaszod!
lifi nek írtam hogy a módszertől függetlenül szeretném tudni akár máshoz is jó lehet, hogy miért nem használhatom a teljes memóriát. Ill. hogy használhatnám? PIC 18F4520 1536 bájt memória melyből csak 722 ig megy a dolog MPLAB szerint / 8.10 / a fordító C18 3.10
Használj linker script-et (*.lkr). Ez mondja meg a linkernek hogy melyik memóriaterületet lehet használni. Azt most nem tudom alapértelmezésben ha nem állítasz be semmit melyiket használja, de a fordító bin\LKR könyvtárában vannak ezek. Érdemes a 4520-ra vonatkozót átmásolni az aktuális project könyvtárába, a projecthez hozzáadni és ha szükséges kissé át is lehet írni.
Idézet: Ha int változót használsz, az két bájtot foglal. Nem ebből van a félreértés? „PIC 18F4520 1536 bájt memória melyből csak 722 ig megy a dolog MPLAB szerint”
Tehát MPLAB szerint
alapállapot 522 foglalt int meres1[50]; int meres2[50]; a két tömb után 722 foglalt ami stimmel 50 * 2 bájt kétszer azaz + 200 bájt tehát egy újabb 50 elemű int tömb 100 bájt azaz 822 kéne lenni de le se forditja benjami l.lkr átírás lehet hogy jó lesz mert most néem ebből 4 van végigpróbálom
Kösz a tippet
*.lkr minden képen ki kell választani a fordításhoz De nekem 4 van 18F4520.lkr 18F4520_e.lkr 18F4520i.lkr 18F4520i_e.lkr Egyikkel se megy! A számlán 4520 I/P van. Ide linkelem a 18F4520.lkr mit kéne átírni Idézet: „// $Id: 18f4520.lkr,v 1.2 2004/04/28 01:49:46 curtiss Exp $ // File: 18f4520.lkr // Sample linker script for the PIC18F4520 processor LIBPATH . FILES c018i.o FILES clib.lib FILES p18f4520.lib CODEPAGE NAME=vectors START=0x0 END=0x29 PROTECTED CODEPAGE NAME=page START=0x2A END=0x7FFF CODEPAGE NAME=idlocs START=0x200000 END=0x200007 PROTECTED CODEPAGE NAME=config START=0x300000 END=0x30000D PROTECTED CODEPAGE NAME=devid START=0x3FFFFE END=0x3FFFFF PROTECTED CODEPAGE NAME=eedata START=0xF00000 END=0xF000FF PROTECTED ACCESSBANK NAME=accessram START=0x0 END=0x7F DATABANK NAME=gpr0 START=0x80 END=0xFF DATABANK NAME=gpr1 START=0x100 END=0x1FF DATABANK NAME=gpr2 START=0x200 END=0x2FF DATABANK NAME=gpr3 START=0x300 END=0x3FF DATABANK NAME=gpr4 START=0x400 END=0x4FF DATABANK NAME=gpr5 START=0x500 END=0x5FF ACCESSBANK NAME=accesssfr START=0xF80 END=0xFFF PROTECTED SECTION NAME=CONFIG ROM=config STACK SIZE=0x100 RAM=gpr5 ”
Ez így lefordul:
Nálam a linker állomány vége így néz ki:
Ez azért érdekes, mert a #pragma udata (vagy idata) után egy szekciónevet kell megadni. |
Bejelentkezés
Hirdetés |
