Ports interacting?? 16F1826

[SOTASOTA]

OK, any ideas on this one? This is my 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! :-)

[SOTASOTA]

Disregard the above thread! :-)

BTW, how can I delete a thread??

[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.

[SOTASOTA]

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. :-)

[richard]

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.microchip.com/WebinarDetails.aspx?dDocName=en556253

[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.

[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.

[SOTASOTA]

> 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!

[SOTASOTA]

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!!

[SOTASOTA]

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.

[mark_s]

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.


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.


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

[HenrikOlsson]

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.