With the program beneath, the PIC should light the LED when the input on RA0 is high and the LED should be shut off when the input on RA0 is low. But, in both case it seems RA0 is red as low (0).
#chip 18f1330,8
Dir PortA.0 in
Dir PortB.0 Out
do
if (PortA.0 = 1) Then
PortB.0 = 1
else
PortB.0 = 0
end if
loop
The problem comes from the "asm" code of this program. When the program is called, it tries to disable the comparators on RA0, RB2 and RB3:
;CMCON = 7
movlw 7
movwf CMCON,ACCESS
as described in the PIC18F1330 datasheet (Example 10.1 - p87).
BUT at p179 it is explained that the comparator is disabled when its bit is put to 0 (and not 1, as in the example).
So with:
;CMCON = 0
movlw 0
movwf CMCON,ACCESS
the problem is solved.
You don't need to modify the "asm" code as you can add:
CMCON = 0x00
et the beginning of your Great Cow Basic.
Note: RB2 and RB3 are not concerned by this problem. May be, because they always are digital inputs contrariwise of RA0 which could be an analog input.
Best regards,
Edorul
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
With the program beneath, the PIC should light the LED when the input on RA0 is high and the LED should be shut off when the input on RA0 is low. But, in both case it seems RA0 is red as low (0).
The problem comes from the "asm" code of this program. When the program is called, it tries to disable the comparators on RA0, RB2 and RB3:
as described in the PIC18F1330 datasheet (Example 10.1 - p87).
BUT at p179 it is explained that the comparator is disabled when its bit is put to 0 (and not 1, as in the example).
So with:
the problem is solved.
You don't need to modify the "asm" code as you can add:
et the beginning of your Great Cow Basic.
Note: RB2 and RB3 are not concerned by this problem. May be, because they always are digital inputs contrariwise of RA0 which could be an analog input.
Best regards,
Edorul
Interest difference. I was not aware of this difference.
Very good workaround. The root cause analysis allowed me to fix in a few seconds.
Please try the system.ini here. This should fix this issue within the core compiler and therefore you should not require the workaround.
Anobium
Thanks, your modifications work fine, directly without the workaround :-)
Best regards,
Edorul
Thank you. Nice to fix it so quickly.
This did impact a number of chips as follows:
This fix will be in all release after May 2016. For a fix for release prior to May 2106 please use the file found here