Ports interacting?? 16F1826
OK, any ideas on this one? This is my code:
Code:
;----[16F1826 Hardware Configuration]-------------------------------------------
#IF __PROCESSOR__ = "16F1826"
#DEFINE MCU_FOUND 1
#CONFIG
cfg1 = _FOSC_HS ; HS Oscillator, High-speed crystal/resonator connected between OSC1 and OSC2 pins
cfg1&= _WDTE_OFF ; WDT disabled
cfg1&= _PWRTE_OFF ; PWRT disabled
cfg1&= _MCLRE_OFF ; MCLR/VPP pin function is digital input
cfg1&= _CP_OFF ; Program memory code protection is disabled
cfg1&= _CPD_OFF ; Data memory code protection is disabled
cfg1&= _BOREN_OFF ; Brown-out Reset disabled
cfg1&= _CLKOUTEN_OFF ; CLKOUT function is disabled. I/O or oscillator function on the CLKOUT pin
cfg1&= _IESO_OFF ; Internal/External Switchover mode is disabled
cfg1&= _FCMEN_OFF ; Fail-Safe Clock Monitor is disabled
__CONFIG _CONFIG1, cfg1
cfg2 = _WRT_OFF ; Write protection off
cfg2&= _PLLEN_OFF ; 4x PLL disabled
cfg2&= _STVREN_OFF ; Stack Overflow or Underflow will not cause a Reset
cfg2&= _BORV_HI ; Brown-out Reset Voltage (Vbor), high trip point selected.
cfg2&= _LVP_OFF ; High-voltage on MCLR/VPP must be used for programming
__CONFIG _CONFIG2, cfg2
#ENDCONFIG
#ENDIF
;----[Verify Configs have been specified for Selected Processor]----------------
; Note: Only include this routine once, after all #CONFIG blocks
#IFNDEF MCU_FOUND
#ERROR "No CONFIGs found for [" + __PROCESSOR__ +"]"
#ENDIF
DEFINE OSC 4
TRISA = %00000000
TRISB = %00000000
Low PORTA.1
Low PORTA.4
PORTA.1 = 1
pause 1000
PORTA.4 = 1
pause 1000
PORTA.4 = 0
PORTA.1 = 1
end
:
When I run the code, and LED attached to PORTA.1 goes ON as expected. However, when I code PORTA.4 = 1, then PORTA.1 goes low and the LED turns OFF!
After the second 'pause 100', then PORTA.1 = 1 does indeed turn the LED back ON.
Are these two ports interacting in some way that I am not aware of?
Help! :-)
Re: Ports interacting?? 16F1826
Disregard the above thread! :-)
BTW, how can I delete a thread??
Re: Ports interacting?? 16F1826
Hi,
I don't think you can delete a thread and I don't think you should, but that's my personal thoughts of course.
Instead post what the problem was, how you found it and how you solved it. That way others can read about it and perhaps learn something - which is what a forum like this is all about.
Was it perhaps a R-M-W issue?
/Henrik.
Re: Ports interacting?? 16F1826
Quote:
Originally Posted by
HenrikOlsson
Hi,
I don't think you can delete a thread and I don't think you should, but that's my personal thoughts of course.
Instead post what the problem was, how you found it and how you solved it. That way others can read about it and perhaps learn something - which is what a forum like this is all about.
Was it perhaps a R-M-W issue?
/Henrik.
Good point Henrik! I thought it was a bad circuit board, that is why I thought the thread should be forgotten. However, it ended up being a bad LED. :-)
Re: Ports interacting?? 16F1826
found this video on the microchip site about r-w-m issues , its a "c" demo but the physical cause of the r-w-m problem is explained in a easy to follow way and is worth looking at.
http://www.microchip.com/webinars.mi...cName=en556253
Re: Ports interacting?? 16F1826
> However, it ended up being a bad LED. :-)
Wow, you're out of luck with your LEDs aren't you? Or is this proplem the same as the other thread where you had busted LED - and the thread on MELABS forum?
Anyway, glad you've figured it out!
/Henrik.
Re: Ports interacting?? 16F1826
Keep in mind
All of the new "Enhanced 12FXXXX and 16FXXXX" parts use the LATx register for changing the output state. Portx register for reading the input state.
Re: Ports interacting?? 16F1826
Quote:
Originally Posted by
HenrikOlsson
> However, it ended up being a bad LED. :-)
Wow, you're out of luck with your LEDs aren't you? Or is this proplem the same as the other thread where you had busted LED - and the thread on MELABS forum?
Anyway, glad you've figured it out!
/Henrik.
Ha!! Nope, same issue on several sites looking for clues. At least I am not going too far mad!
Re: Ports interacting?? 16F1826
Quote:
Originally Posted by
mark_s
Keep in mind
All of the new "Enhanced 12FXXXX and 16FXXXX" parts use the LATx register for changing the output state. Portx register for reading the input state.
I would like to know more about "LATs". Know zero. Does PIC Basic Pro support these? Tell me more please! Sounds interesting!!
Re: Ports interacting?? 16F1826
Quote:
Originally Posted by
HenrikOlsson
Hi,
I don't think you can delete a thread and I don't think you should, but that's my personal thoughts of course.
Instead post what the problem was, how you found it and how you solved it. That way others can read about it and perhaps learn something - which is what a forum like this is all about.
Was it perhaps a R-M-W issue?
/Henrik.
I also see that I probably ran into a R-M-W issue as well...or got it to work in an unstable state. Good info!!!!!!! Thanks!!! Again, new to R-M-W. Cool.
Re: Ports interacting?? 16F1826
Quote:
Originally Posted by
SOTASOTA
I would like to know more about "LATs". Know zero. Does PIC Basic Pro support these? Tell me more please! Sounds interesting!!
Hi,
Lat is short for latch. I not a good communicator, so I can't explain it better than the data sheet. The main thing to understand is that on the older pic16's we used portx.x to read or write to a pin. This could lead to R-M-W problem that Henrik pointed out. On the new pic16fxxxx,pic12fxxxx, pic18, dspic, and pic32 we use Latx.x to change the output. Portx.x is used to read a port pin. So on the above code you provided.
Code:
Low PORTA.1
Low PORTA.4
PORTA.1 = 1
pause 1000
PORTA.4 = 1
pause 1000
PORTA.4 = 0
PORTA.1 = 1
This is how it should be, as someone pointed out in the other thread.
Code:
Low LATA.1
Low LATA.4
LATA.1 = 1
pause 1000
LATA.4 = 1
pause 1000
LATA.4 = 0
LATA.1 = 1
Here a similar thread
http://www.picbasic.co.uk/forum/showthread.php?t=15836
Re: Ports interacting?? 16F1826
Hi,
Just to clarify, writing to the PORT registers still works on ALL devices. The thing is that newer devices can run much faster (64MHz) compared to older (20MHz) so the risk of running into RMW issues are bigger.
Using the LAT register (when available) for outputs is a good idea. However, I'm not entirely sure that using HIGH/LOW (or any high level pin/port command) on LAT works, actually I don't think it does, but I'd be happy to stand corrected on that.
/Henrik.
