Also: MPASM, MPLAB Bugs, FAQ, Port Pin Gotchas, Electronic Gotchas
http://www.microchip.com/10/lit/suppdoc/errata/index.htm is the current Microchip errata page.
ent1 dt "123"assembles to
retlw 0x31 retlw 0x32 retlw 0x33which uses more memory than necessary on processors that can directly access the memory
string db A'1',A'2',A'3',0x00assembles to
0x31,0x32,0x33,0x00bytes in ascending memory. No useless retlw opcode bytes shoved between them as with dt. (see memory )
buffer = 31 ; String buffer at end of memory. ASC_0 = '0' ; ASCII numbers: 30h thru 39h.
Does the above assign the value to hex 31 to a variable called "buffer" and
assign the value to hex 30 to a variable called "ASC_0" or does it set up
a register called "buffer" at hex address 31 and set a register called "ASC_0"
at hex address 30 ('0").
A: Dr. Imre Bartfai [root at PROF.PMMF.HU] says:
Neither. It says purely the compiler: if you find the word 'buffer', replace it with '31'. It is completely irrelevant what do you intend thereafter. It may be as well a register naming act as well as naming a constant. I guess the 1st assignment would a register, and the 2nd one is a named constant. Note, that the difference is purely the question of the context. E. g. you can writemovlw buffer movwf bufferThe 1st statement loads the constant 31 to W, the 2nd one moves W into the register #31.
Almost. Theoretically, equated variables (they are in fact compiler variables, or - if you prefer - symbols) can not be changed afterwards, but assigned ["="] can.
movf ADRESH,w movwf PORTC end
A: Robert A. LaBudde says:
You're rolling off the end of memory and then restarting at x'0000'. If you want it to quit at the 'end', you need to tell the processor to stop. The 'end' just tells MPASM it's the end of your source file. The PIC just goes on to the next instruction. A reasonable choice would be a SLEEP instruction, or an endless loop:label: goto label
Also check the following items:
IMHO, there is a source code line missing in AN526 (DS00526E page 22). Between line 121 and 122 there should be the instructionincf ACCbLO
I spent some time in figuring out, that the description for constants in the MPASM User's Guide is not correct. In DS33014G-page 91 it read's:NOTE: Intermediate values in constant expressions are treatet as 32-bit unsigned integers.This is definitely wrong. Intermediate values are 32-bit SIGNED integers.
Immediately before this note, you can read, that "Constants can be optionally preceded by a plus or minus sign." This would not be possible, if intermediate values would be treated as unsigned.
After disabling interrupts i.e.bcf intcon,giecomplete safety is not assured unless you check the global enable bit to see that it *really* is as expected (clear, that is).
My trouble with this magically vanished when I started to use macros for int. enable/disable:
int_off MACRO ;disables all interrupts bcf intcon,gie btfsc intcon,gie ;make sure bit cleared (int could ;have occurred 1/2way thru instruction) goto $-2 ENDM int_on MACRO ;re-enable interrupts bsf intcon,gie ENDM
Michael Rigby-Jones [mrjones at NORTELNETWORKS.COM] says:
...this was a known problem with the 16C6X and 16C7X devices. The datasheet says:"If an interrupt occurs while the Global Interrupt Enable (GIE) bit isbeing cleared, the GIE bit may unintentionaly be re-enabled by the users Interrupt Service Routine (the RETFIE instruction)." It then goes on to describe the work around which is as per the macro's above.
Roman Black points out that as per the 16C84 datasheet, this is fixed in
the 16F84 and presumably any later chips.
The only problem I have run into with the ICE and 16F87x parts is when trying to access the program memory as data. You can't step thru a program memory read, or the whole system will lock up and complain about stack overflow. You can run thru program memory reads, but they take *much* longer than the real thing. One of my projects reads some audio data in program memory and chugs it out via PWM in the interrupt routine. This appeared not to work at all. Eventually I realized that the ICE was running so slowly that it looked broken, and that the PWM also got interrupted somehow during a program memory read. I programmed a real chip with the same code and everything worked fine.
See also:
PICList post "Please help!, retfie fast does not restore w."
Comments:
http://www.microchip.com/download/lit/pline/picmicro/families/16f7x/devices/16f77/30325a.pdf
these pages:
Section 10.2, USART Asynchronous Mode, p. 78, p. 80,
Section 10.3, USART Synchronous Master Mode, p. 82, p. 84, p. 86
all say the same thing:
``If using interrupts, ensure that GIE and PIE in the INTCON register are
set.''.
Since there is no ``PIE'' bit, I'm pretty sure they all meant to say:
``If using interrupts, ensure that GIE and PEIE in the INTCON register are
set.''.
See:
Questions:
Hello, i call a subroutine in page 1 from page0 with pagesel subr and call subr. the PC go in page1 it's OK, but when I return with return instruction the PCLATH don't reset in 00 (page0) but remain in 01 (page1 so when i call next sub in page0 the PCLATH is wrong. the only solution is write pagesel every call and goto? please help me
thank you Marco Frigerio
James Newton replies: You are correct. If the page of the destination of a call changes, you must preface the call with a pagesel. Try to keep related subroutines in the same page. If you will be calling subroutines quite a lot, you can setup, in one page, a list of long jumps (pagesel and jump) to each of the subroutines, then you can call the "subroutine" (actually the long jump to the subroutine) in that one page. This only saves code space if you call many different subroutines many times.+
Can anyone give me help about interrupts? I added an ISR (ORG 0x004) with some code but when I compile it, it gives me an error 118 with the message - overwriting previous contents at 004. It doesn't give me the same problem when I take the code out while leaving the ORG 0x004. Anyone know why?+
file: /Techref/microchip/gotchas.htm, 14KB, , updated: 2013/7/23 09:21, local time: 2024/11/4 23:24,
18.226.200.240:LOG IN ©2024 PLEASE DON'T RIP! THIS SITE CLOSES OCT 28, 2024 SO LONG AND THANKS FOR ALL THE FISH!
|
©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions? <A HREF="http://techref.massmind.org/techref/microchip/gotchas.htm"> Microchip PIC Gotchas</A> |
Did you find what you needed? |
Welcome to massmind.org! |
Welcome to techref.massmind.org! |
.