I have been playing with my new PICKIT2 debug express and the demo board that comes with it. The demo has a PIC16F887.
gputils assembler has a file for the '887 but it don't assemble it. Complains about the name of the PIC. I temporarily tried using the '877a as a fake pic type and the i/o works but the A/D doesn't.
Then I read that there was a GCASM and i set that one up. Still did not work for the '887.
Then I drug the compiled.asm over to MPASM assembler and it worked fine for the '887.
Took two evening to figure out how to hook the MPASM to the compile.bat file and work. Ended up copying the compiled.asm file over to MPASM and assembling and then copying it back.
Remember to use double quotes "" around the long directory/file paths in the .bat file.
Like ie- copy "c:\Program Files\GCBASIC\compiled.asm" "c:\Program Files\Microchip\MPASM Suite\compiled.asm"
Mike
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did a reinstall of GCBasic not too long ago, and it now asks which assembler you want to install MPASM or GCASM I think. Have to recommend the MPASM for sure, as you have found out.
I really like my PicKit 2 programmer, I am sure you will too. Pretty much handles all the devices with GCBasic, plus you can also power your demo/proto board. One odd-ball Pic, a 18f4331, didn't work because of a weird register set(it can do a dual h-bridge in hardware). With some effort, got that to work too by changing system.h (reverted the file back tho, so other devices would work).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When 16F887 did not assemble using GPASM, one of the gputil tools, did you check to see if the 16F887.h file was present. If it was, I suggest you go to the gputil section of sourceforge.net and do a bug report. I expect from time to time we will find problems with gpasm.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I, also, tried to compile for the 16F887 and the assembler returned the same "unknown processor". The p16F887.inc" is present , therefore, the assembler must maintain an internal list. One of the reasons I tried GCBASIC was to compile to the 16F887 processor. I looked at gpasm and it appears that there is a newer version than that included in GCBASIC. Does anyone know whether the 16F887 bug in gpasm has been fixed in the new version. I am on dialup and I don't look forward to downloading the MPLAB that will solve this problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have been playing with my new PICKIT2 debug express and the demo board that comes with it. The demo has a PIC16F887.
gputils assembler has a file for the '887 but it don't assemble it. Complains about the name of the PIC. I temporarily tried using the '877a as a fake pic type and the i/o works but the A/D doesn't.
Then I read that there was a GCASM and i set that one up. Still did not work for the '887.
Then I drug the compiled.asm over to MPASM assembler and it worked fine for the '887.
Took two evening to figure out how to hook the MPASM to the compile.bat file and work. Ended up copying the compiled.asm file over to MPASM and assembling and then copying it back.
Remember to use double quotes "" around the long directory/file paths in the .bat file.
Like ie- copy "c:\Program Files\GCBASIC\compiled.asm" "c:\Program Files\Microchip\MPASM Suite\compiled.asm"
Mike
Did a reinstall of GCBasic not too long ago, and it now asks which assembler you want to install MPASM or GCASM I think. Have to recommend the MPASM for sure, as you have found out.
I really like my PicKit 2 programmer, I am sure you will too. Pretty much handles all the devices with GCBasic, plus you can also power your demo/proto board. One odd-ball Pic, a 18f4331, didn't work because of a weird register set(it can do a dual h-bridge in hardware). With some effort, got that to work too by changing system.h (reverted the file back tho, so other devices would work).
When 16F887 did not assemble using GPASM, one of the gputil tools, did you check to see if the 16F887.h file was present. If it was, I suggest you go to the gputil section of sourceforge.net and do a bug report. I expect from time to time we will find problems with gpasm.
I, also, tried to compile for the 16F887 and the assembler returned the same "unknown processor". The p16F887.inc" is present , therefore, the assembler must maintain an internal list. One of the reasons I tried GCBASIC was to compile to the 16F887 processor. I looked at gpasm and it appears that there is a newer version than that included in GCBASIC. Does anyone know whether the 16F887 bug in gpasm has been fixed in the new version. I am on dialup and I don't look forward to downloading the MPLAB that will solve this problem.