Activity for gputils
-
Ben Sagal created ticket #324
gpdasm: sumtimes wrong reg with access bank
-
tech66 posted a comment on ticket #323
Forgot to log in, I just posted. I am running gpasm-1.5.2 #1331 (Mar 21 2023)
-
Anonymous posted a comment on ticket #323
I noticed the same error, even a single space after the ';' and it works ok. I have hit this error a few times and I upvote it.
-
alain gibaud posted a comment on discussion General Discussion
Hi everybody Many thanks to all the developers of GPUTILS. This a great tool, and I wish it support more recent devices. I discovered that the DEBUG bit of CONFIG2H register is missing for PIC18F24Q10 (and other devices of the same family). Symptoms : The CONFIG directive fails when you mention this bit (ie: CONFIG DEBUG=OFF (or ON) is rejected). Everything seems to work fine when you don't mention this bit. In the latter case, the default value is assumed. Fix: The problem comes from the gputils/libgputils/gpcfg-table.c...
-
Molnár Károly posted a comment on ticket #81
Thank you for the patch. I have created newer version: [r1333] gputils-src-20231125-1333.tar.bz2 gputils-20231125-1333-setup.exe
-
Issue an error if you #define the same symbol as defined by equ.
-
gputils released /snapshot_builds/i686-mingw32msvc/gputils-20231125-1333-setup.exe
-
-
Issue an error if you #define the same symbol as defined by equ.
-
* gputils/gpasm/coff.c, gputils/gpasm/directive.c, gputils/gpasm/gpasm.c,
-
Petr Mikše created ticket #81
Issue an error if you #define the same symbol as defined by equ.
-
COFF object file creation in absolute mode
-
Anonymous posted a comment on ticket #80
Thank you, I've been able to use it properly. These are the newer versions [r1332]: gputils-src-20231022-1332.tar.bz2 gputils-20231022-1332-setup.exe
-
gpasm expand macros partly
-
This patch is I treated together with patch https://sourceforge.net/p/gputils/patches/80.
-
-
-
* gpasm/cod.c, gpasm/coff.c, gpasm/directive.c, gpasm/evaluate.c,
-
Gordon Scott created ticket #323
Macro complains apparently wrongly.
-
Here are all the patches in one file. The original patches must be applied gradually. I'm sorry for the inconvenience. gpasmCorr4 and gpasmCorr5 are needed for the successful execution of asm tests also on the i386 architecture. Regards, Petr
-
COFF object file creation in absolute mode
-
I believe you intended the gpasmCoffcorr3.patch file to be the main patch. I have found that it cannot be applied. I get a lot of error messages. This is not going to work. Please download the latest svn version. Make your changes in this code tree. Then create a single patch and upload it to the ticket.
-
gpasm expand macros partly
-
Gpasm uses significantly less memory with this patch. All the absolute sections share the same memory image.
-
Just a bugfix.
-
Hi Károly, thank you very much for your response. Yesterday I tried to simplify the gpasm message generator. All messages are generated with a single function now. No need to format the message in the caller. I am sorry, I am not the right one to take over your project. I don't really understand the parser/lexer part of this software. I don't plan on making any more changes now. Petr
-
My comment on the https://sourceforge.net/p/gputils/patches/80 also applies here.
-
I have not worked on the project for a long time. But I don't want your work to go to waste. So I'll try to find the time and energy to go over the improvements at some point. In the meantime, please be patient. (It would be nice if someone could take over the maintenance of the project from me.) Károly
-
This correction enables 8bit per word idlocs, idlocs and config addresses are excluded from BADROM. It adds an error indicating where overwritten address contents was defined and an error indicating where redefined label was originally defined. Some bugfixes.
-
This correction adds constants to the coff file. They holds variable names in absolute mode. If not in mpasm compatibility mode, constants beginning with a underscore are excluded, coff file created have a .cof suffix and an executable bit set, so no linker step is needed. I tested debugging using both the simulator and Pickit3 (MPLABX4.15) successfully. A macro dereference (-X option) have also effect to the generated coff file now. A linker listing looks better with it.
-
COFF object file creation in absolute mode
-
gpasm expand macros partly
-
I had this problem too. I got around this by putting the macro definitions in a second .inc file that was all conditionally included.
-
Anonymous posted a comment on ticket #317
I see two solutions: 1) In most jurisdictions, the files are free, as they are not copyrightable (see discussion on debian-legl: https://debian-legal.debian.narkive.com/gGuSWDyP/are-register-names-and-locations-under-copyright) 2) By now, Microchip provides the XC8 package, which includes header files (in a different format, but containing the same information) under the free 3-clause BSD license.
-
Nic Pablo posted a comment on discussion General Discussion
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...
-
MACRO name cannot include "_" underscore.
-
check for flex and yacc before compiling?
-
support for PIC16F152XX family
-
Having verified the tool for my favorite PIC16F1534x processors, I am adopting it. But I am hopeful there will be support for some simpler p16 devices like PIC16F152xx. The dead end for Microchip MPASM is the reason for this toolkit so we need to keep going with PICs not supported in MPASM. It seems like a great little assembler and I am glad to adopt it. To get more processors supported I would offer help but it would be best if you coordinated things and let us know what you need. I read through...
-
Anobium posted a comment on ticket #12
was the 18F27Q43 class of chips ever added?
-
Anders Andersson created ticket #321
Macros expanded or parsed inside if(0)/endif block, breaking some include-guards
-
Regression in 1.5.2 relative to 1.5.0
-
Thanks for the patvh. These are the newer versions [r1331]: gputils-src-20230103-1331.tar.bz2 gputils-20230103-1331-setup.exe
-
-
-
Regression in 1.5.2 relative to 1.5.0
-
* gputils/gpasm/directive.c:
-
Roy Rankin posted a comment on ticket #78
Here is the patch
-
Regression in 1.5.2 relative to 1.5.0
-
Robert Pearce created ticket #320
Inappropriate macro expansion in linker list file
-
GPLINK broken with unused extern
-
This bug is still present in v1.5.2 and is actually worse than I thought. The apparently harmless change (with a linker-defined address) causes all five bytes of .idata to be initialised wrongly. I've attached an updated zip with the build results I get (and the makefile tweaked to not need my complex build environment)
-
gpasm allows RETURN for 10F202
-
This bug is fixed in [r1330] svn version.
-
* gpasm/directive.c, gpasm/gpmsg.c, gpasm/gpmsg.h,
-
Now that the linker defaults to ignoring these symbols (and gives an option to warn about them) I think this is probably fine as it is. In fact, having thought about it, the current behaviour is probably about optimal. You can close the bug. Thanks.
-
PIC16F69 TRIS does not assemble correctly
-
This bug fixed in svn version [r1329]. Thanks for the bug report and the patch.
-
* libgputils/gpopcode.h,
-
The data sheet is indeed incorrect. There is a controversy in the description of the TRIS command: Operands: f = 5, 6, 7, 8 or 9 . . . Description: TRIS register ‘f’ (f = 5, 6 or 7) is loaded with the contents of the W register.
-
Incorrect duplicate symbol error
-
I think it's fine now because of another fix. Károly
-
Is it worth going into this in more depth, or should it stay that way? Károly
-
ELIF is not ELSE IF, bug or unusual name?
-
Fixed in svn version [r1328]. Thanks for the bug report and the patch. Károly
-
* gpasm/directive.c, gpasm/testsuite/regression/source/elif.asm:
-
I agree that looks like a bug - your interpretation of "elif" matches everyone else's, even if the gputils documentation is rather vague on the subject. I believe the fix is fairly simple, it just needs applying in several places. The attached patch should do it.
-
<deleted post=""> sorry, was finger trouble.</deleted>
-
Well this is weird. I've just tried this again and the problem's back - the --strict option makes no difference.
-
As far as I can tell, that is in line with MPASM (although that gives a message about the substitution but compiles the same otherwise). There are a few 12-bit processors for which gpasm throws an error on RETURN but even for those, MPASM compiles it as RETLW 0 with a warning.
-
I believe the attached simple patch is all that's actually needed. I tried tweaking one of the test files to check it out and it seems OK but I'm not sure I get the full process for the tests.
-
This appears to have been fixed in release v1.5.2
-
The relevant page of the datasheet contains misleading information.
-
incorrect linear_ram_addrs
-
* lkr/12f1571_g.lkr, lkr/12lf1571_g.lkr, libgputils/gpprocessor.c:
-
I'm sorry to say this but this "fix" needs reverting as the bug report is in error.
-
incorrect linear_ram_addrs
-
Thanks for the bug report. Version [r1326] is now free of this bug.
-
* lkr/12f1571_g.lkr, lkr/12lf1571_g.lkr, libgputils/gpprocessor.c:
-
It appears that the pic12f1571 has an incorrect ending address for linear_ram_addrs in static struct px pics[] in gpprocessor.c. The end address is 0x206F, indicating 112 general purpose registers, but per the datasheet, this processor has 128 general purpose registers. I think the end address should be 0x207F. The linear memory size is indeed incorrect. This is because the lkr file used as the source also contains incorrect data: // File: 12f1571_g.lkr // Generic linker script for the PIC12F1571...
-
incorrect linear_ram_addrs
-
OK, I've finally got round to checking this against V1.5.2 The core problem (that an unused "extern" creates a need for an unused symbol) is actually still there, but the new "-S" / "--strict" option defaults to ignoring undefined symbols. That's probably an acceptable fix, as it still generates an error if the code attempts to actually use the symbol
-
The datasheet is inconsistent and GPUtils is correct, I believe. If you look closely at your third attachment, the one that shows "48 bytes" of RAM in page 1, you'll see that the address range is A0 to BF - which is only 32 bytes and matches the 1822. Since the datasheet also specifies that the 1571 has 128 bytes RAM in total, including the 16 bytes shared RAM, the 112 byte linear region is correct.
-
Foad S. Farimani created ticket #319
gcc: error: scan.c: No such file or directory
-
-
-
-
-
* man/gplink.1.in:
-
* doc/gputils.lyx:
-
Add PIC16F184XX devices
-
Add PIC16F184XX devices
-
Thank you for the patch kit. I have merged it into the source. [r1323] Molnár Károly
-
* header/Makefile.am, header/Makefile.in, header/p16f184...inc,
-
Parser doesn't allow more than one unary operator
-
This is the newer version: [r1322] Molnár Károly
-
* gpasm/parse.y:
1 >