Nic Pablo

I found the culprit. GPUTILS uses two separate environment variables GPUTILS_HEADER_PATH & GPUTILS_LKR_PATH that need to be explicitly provided. Case closed :-) C:\Users\Nic\PIC14>sdcc --use-non-free --verbose -mpic14 -p16f887 TestPIC16.c Processor: 16f887 Using devices from c:\Users\Nic\sdcc\bin..\include\pic14\pic14devices.txt. sdcc: Calling preprocessor... sdcc: sdcpp -nostdinc -Wall -std=c11 -D__SDCC_PROCESSOR="16f887" -D__SDCC_PIC16F887 -D__SDCC_PIC14_STACK_SIZE=14 -obj-ext=.o -D__SDCC_CHAR_UNSIGNED...

Hi everyone. I am currently developing a Windows app that requires SDCC/GPUtils to be portable ( ie , no installation, just run directly using the path)The SDCC is OK and generates the necessary asm file . It calls gpasm successfully but gpasm seems lost and cannot find the include file ( ie p16f887.inc) . There are different errors in PIC16 & PIC18 .What seems to be missing? I have tested it using the cmd command line only interface. Kindly see below some info: ................. C:\Users\Nic\PIC14>path...

Hi everyone. I am currently developing a Windows app that requires SDCC/GPUtils to be portable ( ie , no installation, just run directly using the path)The SDCC is OK and generates the necessary asm file . It calls gpasm successfully but gpasm seems lost and cannot find the include file ( ie p16f887.inc) . What seems to be missing? I have tested it using the cmd command line only interface. Kindly see below some info: ................. C:\Users\Nic\PIC14>path PATH=c:\users\nic\gputils\bin;c:\users\nic\gputils\header;c:\users\nic\gputils\lkr;c:\users\nic\sdcc\bin...

Hi everyone. I am currently developing a Windows app that requires SDCC/GPUtils to be portable ( ie , no installation, just run directly using the path)The SDCC is OK and generates the necessary asm file . It calls gpasm successfully but gpasm seems lost and cannot find the include file ( ie p16f887.inc) . What seems to be missing? I have tested it using the cmd command line only interface. Below is the partial dump: ................. C:\Users\Nic\PIC14>sdcc --use-non-free --verbose -mpic14 -p16f887...

Well, stack is my last worry, because this project has a fat RAM and there's an option to use external stack. Anyways, I think this issue is closed(?) At lest I have my own record ot personal findings about SDCC. I agree on the calling convention and endianness . Cheers

You may be right to point out that I should have used %Lu instead But C89/C99 or C11 t would not emit 0 for a value of 98 which definitely fits in both int and long data sizes. If you don't consider it bug , so be it. However, the following code would not emit '0' in any other C compilers , CCS C & GCC included so the argument about %u is very weak. #include <stdio.h> int main (void){ long j = 68; printf ("This is %u\n",j); printf ("This is %Lu\n",j); printf ("This is %d\n",j); printf ("This is %i\n",j);...

You may be right to point out that I should have used %Lu instead But C89/C99 or C11 t would not emit 0 for a value of 98 which definitely fits in both int and long data sizes. If you don't consider it bug , so be it. However, the following code would not emit '0' in any other C compilers , CCS C & GCC included so the argument about %u is very weak. #include <stdio.h> int main (void){ long j = 68; printf ("This is %u\n",j); printf ("This is %Lu\n",j); printf ("This is %d\n",j); printf ("This is %i\n",j);...

You may be right to point out that I should have used %Lu instead But C89/C99 or C11 t would not emit 0 for a value of 98 which definitely fits in both int and long data sizes. However, if you don't consider it bug , so be it. However, the following code would not emit '0' in any other C compilers , CCS C & GCC included so the argument about %u is very weak. #include <stdio.h> int main (void){ long j = 68; printf ("This is %u\n",j); printf ("This is %Lu\n",j); printf ("This is %d\n",j); printf ("This...