First off, thanks for an awesome project. Its been a real lifesaver for me in lab, allowing me to resurrect some old ICs (binary to BCD ???) and avoid wiring ugly things (like this 4 1-bit summer). I was able to get this code to compile just fine for an 18F877A, but I can't seem to get it to compile for an 18F1220.
I know that it could be something silly like the chip line I'm using, #chip 18F1220, 4, but I'm not sure. When I use compile.bat, GCBasic creates some assembly that fails the assembly stage, specifically at the config line. I explicitly made sure that I was only using pins that exist on the 18F1220 as well.
Once again, thanks for an awesome project. It's really been useful here in lab.
This problem is most likely being caused by an incompatibility between the format of the config setting generated by GCBASIC, and that expected by the assembler. On 18F chips, GCBASIC uses the newer format for specifying the chip config, which the version of gputils included with GCBASIC cannot handle.
There are 3 solutions to this problem:
1. Install the newest version of gputils from http://gputils.sourceforge.net/
2. Install MPLAB, and set GCBASIC up to use it
3. Use the assembler that is now built in to GCBASIC
When I do finally get around to releasing the next version of GCBASIC it will include the new version of gputils and/or use its internal assembler. I'll release the next version once I've implemented subroutine overloading, hopefully this won't take too much longer. I need a bit more pressure to get the next version out, so if I've not got a release candidate labeled version 0.9.3.9 out by May, I'd like everyone reading this to email me and nag me about it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First off, thanks for an awesome project. Its been a real lifesaver for me in lab, allowing me to resurrect some old ICs (binary to BCD ???) and avoid wiring ugly things (like this 4 1-bit summer). I was able to get this code to compile just fine for an 18F877A, but I can't seem to get it to compile for an 18F1220.
I know that it could be something silly like the chip line I'm using, #chip 18F1220, 4, but I'm not sure. When I use compile.bat, GCBasic creates some assembly that fails the assembly stage, specifically at the config line. I explicitly made sure that I was only using pins that exist on the 18F1220 as well.
Once again, thanks for an awesome project. It's really been useful here in lab.
------------------------
'muxControl
'4 bit summer
'1:44 AM 4/10/2008
'-------------------------------
#define in0 PORTB.7
#define in1 PORTB.6
#define in2 PORTB.5
#define in3 PORTB.4
#define f0 PORTB.3
#define f1 PORTB.2
#define z0 PORTB.1
'-------------------------------
'-------------------------------
'Set pin direction
dir in0 IN
dir in1 IN
dir in2 IN
dir in3 IN
dir f0 OUT
dir f1 OUT
dir z0 OUT
'-------------------------------
' What we have in lab, not assembling right
'#chip 18F1220, 4
' Have some, and it works
#chip 16F877A, 4
dim numA as byte
dim numB as byte
dim numC as byte
dim numD as byte
dim sum as byte
DO
'wait 500 ns
numA.0 = in0
numB.0 = in1
numC.0 = in2
numD.0 = in3
sum = numA + numB + numC + numD
'f sum=0 then set z0 on
if sum>0 then set z0 off
f0 = sum.0
f1 = sum.1
'wait 500 ns
LOOP
This problem is most likely being caused by an incompatibility between the format of the config setting generated by GCBASIC, and that expected by the assembler. On 18F chips, GCBASIC uses the newer format for specifying the chip config, which the version of gputils included with GCBASIC cannot handle.
There are 3 solutions to this problem:
1. Install the newest version of gputils from http://gputils.sourceforge.net/
2. Install MPLAB, and set GCBASIC up to use it
3. Use the assembler that is now built in to GCBASIC
The first solution is pretty self explanatory, the other two are detailed here: https://sourceforge.net/forum/message.php?msg_id=4286525
When I do finally get around to releasing the next version of GCBASIC it will include the new version of gputils and/or use its internal assembler. I'll release the next version once I've implemented subroutine overloading, hopefully this won't take too much longer. I need a bit more pressure to get the next version out, so if I've not got a release candidate labeled version 0.9.3.9 out by May, I'd like everyone reading this to email me and nag me about it.