I ran into this on my older version of the compiler/studio. Did the obvious things: palm-slapped my forehead, bored into the datasheet for the 18044 and family, searched the net, tried turning off various internal peripherals, remapping pins, etc., and still got the warning. I also downloaded the latest version of the compiler/studio, thinking that there was a bug that got fixed. Still get the warning.
I also fell back on simplifying my program down to isolate causes and effects. A test compile of just the chip and clock frequency and "dir RA5 Out" causes the same warning.
I have spent some hours poring over the datasheet for the 16F18044 and cannot find any info that would suggest that RA5 can't be an output; on the contrary, a lot of info in the control registers that it CAN.
So (1) is this a bug in my head where I missed something? (2) is this a bug in the datasheet? (3) is this a bug in the compiler? (4) a bug in the .DAT file for the part? or a bug/errata for the chip?
I've been using PICs for a couple of decades now, haven't run into anything like this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, this must be fustrating. The issue ( I have just looked into the root cause ) is an error in the chip specific .DAT file.
Please replace yours with the one attached here. Put in your \gcstudio\gcbasic\chipdata folder over writing the \GCstudio\gcbasic\chipdata\16F18044.dat file.
Let me know this works and I will regen the chips impacted.
Thought maybe I was caught by the ANSELA register set to all inputs at reset. Compiler docs on analog says the compiler inserts code to turn off the analog inputs unless there is an active A2D going on.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great to hear. The root cause was the chip description file. That error was cause by an error in the database we maintain the describes every chip. All sorted.
I ran into this on my older version of the compiler/studio. Did the obvious things: palm-slapped my forehead, bored into the datasheet for the 18044 and family, searched the net, tried turning off various internal peripherals, remapping pins, etc., and still got the warning. I also downloaded the latest version of the compiler/studio, thinking that there was a bug that got fixed. Still get the warning.
I also fell back on simplifying my program down to isolate causes and effects. A test compile of just the chip and clock frequency and "dir RA5 Out" causes the same warning.
I have spent some hours poring over the datasheet for the 16F18044 and cannot find any info that would suggest that RA5 can't be an output; on the contrary, a lot of info in the control registers that it CAN.
So (1) is this a bug in my head where I missed something? (2) is this a bug in the datasheet? (3) is this a bug in the compiler? (4) a bug in the .DAT file for the part? or a bug/errata for the chip?
I've been using PICs for a couple of decades now, haven't run into anything like this.
More info: I tried disablling FEXTOSC and CLKIN. No help. SOSC is also on RA5, but I believe it's disabled at reset. Guess I may as well try it.
Hello,
Sorry, this must be fustrating. The issue ( I have just looked into the root cause ) is an error in the chip specific .DAT file.
Please replace yours with the one attached here. Put in your \gcstudio\gcbasic\chipdata folder over writing the \GCstudio\gcbasic\chipdata\16F18044.dat file.
Let me know this works and I will regen the chips impacted.
Thought maybe I was caught by the ANSELA register set to all inputs at reset. Compiler docs on analog says the compiler inserts code to turn off the analog inputs unless there is an active A2D going on.
Not the issue, so all is good.
The root cause was the chipdata had these chips as 18pin ( old pinout ) not 20pins.... So, the descriptors were set incorrectly.
All should be good now with the new dat. This and other dat files update will be included in the next release.
I'll go check it out!! Thank you for the help!
That does seem to have fixed the issue. Thank you very much.
Great to hear. The root cause was the chip description file. That error was cause by an error in the database we maintain the describes every chip. All sorted.
Donate Here
Please donate to support the operational costs of the GCBASIC Project.
Thank you! Donate here. Select this URL, then select
Send, enter your donation value and then selectNext. Follow the process to complete the payment.This year, we are reaching out to anyone and everyone who uses the GCSTUDIO/GCBASIC toolchain to contribute.
Please contribute as much as you can afford.