Ok. Rosszul másoltam ki a PIC típusát. Valóban van 16 bit módja, de....
Ez egy 8 bites PIC, nincs 16 bites írható timer regisztere. A TMR0-t mint olyat nem tudod írni. Van TMR0H és TMR0L regisztere. Olvasd el mit ír. Íráskor először a TMR0H-t kell megadni majd a TMR0L-t. A 16 bit a TMR0 felső bájtjába a TMR0H regiszter a TMR0L regiszter beírásakor kerül be. Most telepítettem a gépem nemrég és XC8 még nincs fenn, szóval nem tudok belenézni,hogy erre miért nem dob hibát a fordító, hacsak nincs valami beépített makroja erre, de akkor meg minek dob warningot.

mod: Na úgy néz ki van TMR0 makrója, de ki tudja hogy működik. Nem kéne használnod, ha warningot dob.
Viszont van más beépített makrója is a 16 bit timerre. :READTIMERx, WRITETIMERx

Nem a fordítóra gondoltam, hanem az IDE-re azért volt ott az eclipse mert szerintem katasztrófa. Most a fordítóra a megoldásokat ne részletezzük... de én inkább fordítatokk kevésbé effektív kódót mint, hogy az IDE-től a világból is ki fussak az X-nek is vannak gondjai, de az Atollic studio, simplicity ide én megzavarodok tőlük

Jó reggelt!

Szeretném kérni segítségeteket abban, hogy mi a helyes szintaktikai megadás módja C kódban:

Az option_reg egy bit tartalmát (WPUEN) szeretném 0-ra állítani.
option_reg.WPUEN=0;--> erre hibát dob a fordító, nem jó

Valamint a configuration word1 és word2 beállítását is szeretném C kóddal megadni.
config_1=0x2E04;--> erre is hibát dob a fordító

Köszönöm!
Peti

fordító függő.
Include fájlban megtalálod.
pl. p18f14k50.h
de valószínű nem option_reg, hanem OPTION_REG

Sajnos nem jó, nem nagybetűvel kell írni
option_reg=0b00001001; ez jó, de itt 1 byte-n adom meg.
Én csak 1 bitet szeretnék átírni.

Az include fájlban nem találom, hogy a config word-öt hogy adja meg.

A fordító ez:
Code Generator: BoostC Compiler - http://www.sourceboost.com
;// Version : 7.03

Melyik fordító?
XC8:

Előző hozzászólásomban megírtam, hogy melyik fordító.
Nem jót adtam meg?
Lepróbáltam, nem ismeri fel.

Szia!
Max csatold ide fel a headert,mert nem sokan tolják ezzel a fordítóval.

XC-nél még jó a :

_WPUEN=0;

C ... de melyik?
Vagy csak én nem látom?

Hülye vagyok hozzá....
Nem tudok programozni, azt használom ami van.
Flowcode-ban programozok (bár megírtam ott is a kérdésemet, eddig nem kaptam választ), annak van egy beépített fordítója.
A lefordított fájlból másoltam ki azt, amit korábban megírtam.

Amit eddig C kódban használtam, és jól működött, az ezek:

//baud átállítása UART2 115200 bps
clear_bit(txsta2,SYNC);
set_bit(txsta2,BRGH);
set_bit(baudcon2,BRG16);
spbrgh2=0;
spbrg2=34;

//SPI2 port beállítások
trisb.TRISB3=0; //RB3 kimenet, SDO2 PIN24
trisb.TRISB2=1; //RB2 bemenet, SDI2 PIN23
trisb.TRISB1=0; //RB1 kimenet, SCK2 PIN22

//SPI2 regiszter beállítások
ssp2stat=0b01000000;
ssp2con1=0b00100010; //Fosc/64

Ebben is pl. az ssp2stat regisztert csak byte-osan tudtam megadni.
Amiből próbáltam kiindulni, az ez volt:
trisb.TRISB3=0; ennek mintájára írtam be, hogy : option_reg.WPUEN=0; de így nem működik.

Másik gonddom az az volt, hogy a configuration word1 és word2 regiszterek értékét szeretném megadni a program elején C kódban.

Ezért bátorkodtam feltenni a kérdést itt.

clear_bit(option_reg , 7)
Esetleg: clear_bit(option_reg , WPUEN)

Köszönöm! Szuper!
clear_bit(option_reg , 7) ezt elfogadta, de a végére kéri a pontos vesszőt

Esetleg a configuration word1 és word2 regiszterek beállítására nincs javaslatod?

A pontosvessző alap a C-ben. Én csak azért nem írtam oda, mert nem kódsornak szántam, csak iránymutatónak.
Én nem értek a flowcode-hoz, de azt tudom, hogy a configot egy ablakban be lehet állítani az IDE-ben. Atz, hogy kódban megadható formulája van-e nem tudom. Valamint ezeket a kérdéseket a flowcode-os témában kellene feltenned.

Sajnos csak most van időm elolvasni és már megkaptad a választ is.
C fordítót írtad, de a PIC -ekhez egy halommal van (CCS, Mikor C, Hitech C, Microchip XC8, Small Device C - SCC, CC5X, CC8e, Boost C, LPIC, stb - nem is említve a FlowCode belső fordítóját), mind egy kicsit másképp fogadja el.

Igazad van.
Viszont abból adódik a problémám, hogy ott az ablakban megadott értékek közül kettő adat az a konfig 2-ben szerepel. Az LVP és a PLL beállítások. Sajnos fordítás után, mikor betöltőm a hex fájlt, akkor ott a konfig2 beállítást a fordító mindig átírja. Így manuálisan kell visszaállítanom az LVP beállítását. Erre keresek választ, hogy miért írja át.

Arra gondoltam, hogy C kóddal megadom mindkettő konfig értéket. Így megláttam, hogy akkor mi történik.

Ennyi a kérdéseim háttere.

Köszönöm.

Na többek között ezért maradok én az assemblynél.

Minden nyelvnek van egy szintaktikája, amit meg kell tanulnod, ha használni akarod! Ebből a szempontból nem érdekes a nyelv...

Segítsség kérésnél pedig úgy tűnik, hogy igen.
Eddig, ha assemblyben segítséget kértem, még sosem kérdeztek vissza, hogy milyen assemblyt használok.
Ráadásul a feltett kérdés megoldása assemblyben nem is kérdés.
Lévén ott direktben kezelhetsz biteket.
BCF OPTION_REG,7

Az assembly-ben sem azonos mindig ugyanazon funkciójú regiszterek elnevezése (pl. GPIO, PORTA), a BRA-t, BTG-t sem tudod mindig használni, stb. és más processzorra ( pl. AVR ) más az assembly szintaktikája, azaz egy kérdés megválaszolásához ott is tudnod kell dolgokat...
Nem kötözködöm, én is szeretem az assembly-t, használom is, de nem kizárólagosan: a C-t is lehet "univerzálisnak" tekinteni pl. egy "if"-el, míg ez az assembly-nél nem mondható el különböző processzoroknál (PIC, AVR,stb.)..

Azok a régi szép idők....
Egy macro assembly -vel (MpAsm ilyen) olyan kontrollerekre is lehet fordítani kódot, amilyet még nem is gyártottak le, de szimuláció, a nyomkövetés ilyen esetben nem fog működni.
Nem kell mást tenni, mint létrehozni egy include állományt, amiben a kontroller regisztereit definiálod (címek) és megadod az utasításokat macro -kként.
- Réges-régen, egy messzi-messzi galaxisban, az MpLab x.y nem ismerte (még) a 18F242 - 18F252 típusokat, csak a 18C242 - 18C252 -t. A C-s verziókban nem volt LFSR utasítás... Egy macro megoldotta. Az MpLab ASM pl. előre definiált btg macro -val rendelkezik a PIC16 -ok esetében.
- Azokon a kontrollereken, amelyek el tudják érni a stack -et adatmemóriaként (16 és 32 bites PIC) létrehozhatsz egy "virtuális gépet". A "virtuális gép" utasításait egy szubrutin hívás után letett utasításkóddal lehet működtetni. A meghívott szubrutin felveszi a visszatérési címet, onnan olvassa az utasítás kódot, végrehajtja őket egészen a "térj vissza" utasításig. Ekkor egy return -t hajt végre a módosított visszatérési címre. (Ld. Sinclair Spectrum Float rutinok).

- Vannak olyan assembly -ben könnyen megoldható feladatok, amik magasabb szinten (C és a többiek) megoldani nem egyszerű, a nyelvi korlátozások miatt nem is lehetségesek. Használt már valaki ugrótáblás elágazást C -ben?

Több éve feltettem ide a problémát:
C18 + 18F2550: Az adat EEProm -ban egy táblázat van. A táblázat egy parancskódot (infra távirányító megváltoztatható kódját) kódolja belső funkciókódra. Egy header állományban lehetne megadni a konkrét parancskódokat. A parancskódhoz tartozó EEProm címre kellene elhelyezni a hozzá tartozó funkciókódot.
Assembly absolute kódban parancsonként két sor (ORG, DE). C18 -ban nem találtam megoldást. XC8 még változó címét sem hajlandó az EEProm területre lerakni.
Hogy melyik a rugalmasabb, döntse el ki-ki maga.

Ezeket a hordozhatóságot is feltételekkel kell kezelni. Egy PIC -re írt C programot (nagy matematikai számítások kivételével) egyszerűen nem fogsz tudni (módosítás nélkül) áttenni más architektúrára, hiszen a kezelt perifériák eltérőek. Kipróbáltam a AVR tranzisztor tesztert (AtMega328) programját áttenni PIC16F1786 -ra, a mai napig nem működik rendesen, pedig C -ben van a forrás.

Még pár adalék a nem is olyen régi (LVP -t tudó) kontrollerek kezeléséhez.
- Ha LVP engedélyezett, a MCLR lábat nem lehet I/O-ként alkalmazni.
- Bizonyos konfigurációk esetében a Vpp First Programming Entry módszer volt (csak) használható a programozási módba való belépéshez (PGC és/vagy PGD kimenetnek állítva rögtön a program elején, oszcillátornak beállítva). A Vpp First Programming Entry módszer nem használható a Snap -pal.
- PIC12F629/675/PIC16F630/676 programozási leírásában kizárólag a First Programming Entry módszer van leírva.

Köszi a segítséget!
Végül Timer1-el oldom meg a dolgot úgy döntöttem.
A fordításban pedig azért volt warning mert a C99 így fogadja el a megszakítást (xc8 2.05):
void __interrupt() my_isr(void)

Még egy olyan kérdésem lenne, hogy beállítom a TMR1-et, mert 1ms-ként szeretnék egy megszakításra számolni. A TMR1 alsó és felső 8bit-jét beállítom.
Ha ezek után engedélyezem a timer-t, akkor az első megszakítás után újra meg kell adnom a TMR1L és H értékeit? Mert ugye nem 0xFFFF-től szeretném a számlálást kezdeni.

A Timer1 a beállított értéktől (ha nem állítjuk be, akkor 0 -tól) számol felfelé és (valahanyadik) átforduláskor kér megszakítást. Továbbá amíg eljut a megszakítás kiszolgálására, a timer1 értéke már megnövekedhetett, így direkt beírás helyett a hozzáadás lenne jó. A Time1 írása gondot okozhat, keresd a Timer1 Errata -t.

Nem lenne agyszerűbb Timer2 -vel megoldani az 1ms -es megszakítást. Nem kellene módosítani a Timer2 regiszterét.

Ezt kifejtenéd bővebben?
Igazából több Timerre lesz szükségem.
Timer2-t a PWM-hez szeretném használni.

Most itt tartok, akkor gyakorlatilag ez nem lesz megfelelő?

Szia!
A timer2 amellett,hogy ellátja a pwm periódus idejét, az utóosztója felhasználható másodperc alapú megszakításra.Ez nem szól bele a pwm-be. Mivel az utóosztója 1:1 -1:16-ig állítható ki tudod kalkulálni a megszakítást, és nem kell állandóan újra írni.

A beállításaid szerint 4 FOsc periódusonként lép a timer3, azaz utasításonként. A megszakítás elfogadása legalább egy - két utasításnyi időbe beletelik (PC mentése, a rutinra való ugrás) (ld. adatlap: Interrupt latency). A programban ott a feltétel vizsgálat (egy ugrás helyett nop(ok)), a TMR3IF törlése, a count növelése (hány bites is). Eddig a TMR3 belső regisztere már legalább 4 - 5 utasításnyi idő eltelt. De a megszakítás sem juthat érvényre azonnal, mert tiltva lehet (szemaforok kezelése alatt a megszakítás tiltva van -- ki tudja hány utasítás), illetve több ciklusos utasítás végét meg kell várnia (goto, call, movff, movffl). Újabb típusoknál ezen kívül működhet a DMA (Direkt Memória Elérés) is. Azaz a TMR3H írásakor a belső TMR3 regiszter már nem 0.

A TMR3 -ba 0xFC87 -et, decimálisan 64647 töltesz, azaz 889 utasítás után átfordul. Ez 4MHz órajel mellett csak 889 us.

Köszi szépen mindenkinek a segítséget, inkább próbálkozok a Timer2-vel A TMR3 regisztert meg szépen elnéztem.

Ami még érdekes lehet, hogyan lehetne prell mentesíteni IOC megszakítással? Ez sem jó megközelítés? Lefutóél IOC van beállítva.
Az IOC fogja nekem felébreszteni is a PIC-et.

pl most ezt gondoltam ki:

Sziasztok!
Van egy pic18f46k80 amit mikro c-ben programozok . Az RE0 portot használom bemenetként, analóg és digitális jelek fogadására. A bemeneten, attól függően, hogy digitális, vagy analóg jel kerül a bemenetre, az ANCON0.F5 regiszteren keresztül választom ki az RE0 port jelfogadását. 2 analóg és 6 digitális jelet mérek. A digitális jelek DS18S20 hőmérők jele. Az RE0 portra a jelek egy CD4051 ic-n keresztül kerülnek. A csatornák kiválasztása a pic-ből történik, a CD4051 ic, A, B, C, valamint az inhibit lábaira adott vezérlő jelekkel.
A probléma az hogy, az analóg jelek jönnek szépen, de a hőmérők jele nem jön. A hőmérők jelét a mikroc beépített OW függvényeivel fogadom. Ha megkerülöm a CD4051-et és közvetlenül adom a pic lábára az szépen jön.
A LATC vezérlésével csak azt figyelem egy leden keresztül,hogy van e belépés.
A jelzobitek regiszter 6. bitjét a megszakítás állítja 1-be, hogy legyen elég idő, hogy a konverzió létrejöjjön.

Mekkora a felhúzó ellenállás a 1W vezetéken?

Szia!
4.7K.