gputils-devel Mailing List for gputils

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi, I use gputils-1.5.0 with sdcc-4.4.0 to support one 8-bit single-chip processor.

月明风清
445...@qq...

&nbsp;
> 
>> 
>> 2) Are there any foreseeable roadblocks?
> 
> Microchip has so far tolerated the inclusion of old headers in the gputils project. The MplabX v5.05 was the last one to have the old headers. I don't know what they would say about the conversion you describe. The source data is owned by the company. I don't want to deal with that because I might end up being threatened.
> 

Fair point but I was thinking along the lines of just getting the register names and hex values for same from the headers, I don't think they are copyrightable as individual 'works of art' nor as a collection, so we I should be good.

I already did that, I wrote a simple script that goes through my code, collects the register names I use and then searches the header file (for the processor I will be targeting next) for the addresses of those and creates a minimalistic header file for that processor to be used with my project.

>> 
>> 3) How about CONFIG, this is assembler directive so nothing I can do about 
>> that in the header/source file level, this would require patching gpasm?
>> 
> 
> You can make a modified copy for yourself. I have described how to do this at the beginning of one of the scripts I have created for this purpose: gputils/scripts/tools/device-manager.pl
> In that folder are the scripts I used to add the newer chips a long time ago. I cannot deal with this.

I had look at that and learning to do that with pearl is just too much hassle.

Also I don't want to create a dependency from my project to some customised gpasm that the users of my project would have to compile themselves. 

I prefer that my project  can be compiled with gpasm as it is.

> 
>> I can with live with something like:
>> 
>> 	ORG H'300000'
>> 	DW H'ffff' ; set CONFIG1
>> 
>> And that should work, right?

I tried this (answering my own question) and it looks like it should work, gpasm warns about 300000 being out side ROM address space but the .hex file still contains the correct bytes. The only thing is that gpasim insists on full 16 bit words and address 300004 does not exist so I hope my pk2cmd does not refuse to program the config words. But if that is the a case I guess I will have to write a script that will do a surgical change to the .hex file for the config words.

Thanks for the answers!

wbr Kusti

On Sat, 4 Mar 2023 19:37:21 +0200
"ea...@ea..." <ea...@ea...> wrote:

> Hi,
> 
> I have a largish PIC18F4550 project (written in gpasm) that could use
> more RAM, I'm currently thinking / playing with PIC18F27Q83.
> 
> I was half through a half hearted attempt to convert the code to pic-as 
> when I realised that actually what is keeping from keep using gpasm is 
> are missing headers and CONGIG stuff.
> 
> If I could get the header for the processors / processors I want to support
> I could use gpasm and more to the point gpsim.
> 
> I had a preliminary look at the header from pic-as from MP LAB X and it 
> looks to me that writing a Python to script convert the header to 
> a form that would be usable in gpasm would not be huge task.
> 
> I don't mean 100% conversion and 100% similar header as those that we 
> already have with gpasm but something that would be close enough so that 
> I could get my existing project to compile with little changes.
> 
> Now my questions are:
> 
> 1) Has anyone attempted this already?

Not that I know of.

> 
> 2) Are there any foreseeable roadblocks?

Microchip has so far tolerated the inclusion of old headers in the gputils project. The MplabX v5.05 was the last one to have the old headers. I don't know what they would say about the conversion you describe. The source data is owned by the company. I don't want to deal with that because I might end up being threatened.

> 
> 3) How about CONFIG, this is assembler directive so nothing I can do about 
> that in the header/source file level, this would require patching gpasm?
> 

You can make a modified copy for yourself. I have described how to do this at the beginning of one of the scripts I have created for this purpose: gputils/scripts/tools/device-manager.pl
In that folder are the scripts I used to add the newer chips a long time ago. I cannot deal with this.

> I can with live with something like:
> 
> 	ORG H'300000'
> 	DW H'ffff' ; set CONFIG1
> 
> And that should work, right?
> 
> wbr Kusti
> 
> 

Regards

Károly

Hi,

I have a largish PIC18F4550 project (written in gpasm) that could use
more RAM, I'm currently thinking / playing with PIC18F27Q83.

I was half through a half hearted attempt to convert the code to pic-as 
when I realised that actually what is keeping from keep using gpasm is 
are missing headers and CONGIG stuff.

If I could get the header for the processors / processors I want to support
I could use gpasm and more to the point gpsim.

I had a preliminary look at the header from pic-as from MP LAB X and it 
looks to me that writing a Python to script convert the header to 
a form that would be usable in gpasm would not be huge task.

I don't mean 100% conversion and 100% similar header as those that we 
already have with gpasm but something that would be close enough so that 
I could get my existing project to compile with little changes.

Now my questions are:

1) Has anyone attempted this already?

2) Are there any foreseeable roadblocks?

3) How about CONFIG, this is assembler directive so nothing I can do about 
that in the header/source file level, this would require patching gpasm?

I can with live with something like:

	ORG H'300000'
	DW H'ffff' ; set CONFIG1

And that should work, right?

wbr Kusti

On Tue, 15 Feb 2022 21:12:53 +0000
Rob Pearce <ro...@fl...> wrote:

> On 15/02/2022 19:14, Molnár Károly wrote:
> > I checked the datasheet here: DS40001723E-page 19
> >
> > BANK 0: 020h - 06Fh -- General Purpose Register 80 Bytes
> > BANK 1: 0A0h - 0BFh -- General Purpose Register 48 Bytes
> ^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^
> >
> > 80 + 48 = 128 Bytes
> >
> > This does not include the Common RAM. Or did I look at it wrong?
> 
> Yes, the datasheet is just plain wrong and inconsistent.
> 
> 0xA0 to 0xBF _*IS NOT 48 BYTES *_- it's 32
> 

You are absolutely right. Hell, I believed what I saw and didn't do the math.

> The datasheet also says the TOTAL RAM is 128, which includes 16 bytes 
> common.
> 
> That 48 is just a typo on the datasheet.
> 
> Cheers,
> 
> Rob

Regards,

Károly

On Tue, 15 Feb 2022 18:18:32 +0000
Rob Pearce <lis...@fl...> wrote:

> On 11/02/2022 19:29, Molnár Károly wrote:
> > Thanks in advance for your contribution.
> 
> Hi Karoly,
> 
> I notice you've made the change for bug #316. Did you verify against 
> real hardware?

For this reason, I will not buy an MCU. I haven't made a device in years. Nowadays you can only get SMD parts more and more often, which I don't think you can work with in amateur conditions. (For example, solder tin will run together between two IC legs.)

> As I commented on the bug (but you probably didn't see) 
> the datasheet is self-contradictory and mostly supports the original 
> version, as did the Microchip LKR file, not Ben Tesch's "correction".
> 
> In particular, please note in section 3.6.2 of the datasheet, that "The 
> 16 bytes of common memory are not included in the linear data memory 
> region." This is standard across all 14-bit enhanced devices, and means 
> that a device with 128 bytes total RAM (like the 1571) will only have 
> 112 bytes of linear address space.
> 

I checked the datasheet here: DS40001723E-page 19

BANK 0: 020h - 06Fh -- General Purpose Register 80 Bytes
BANK 1: 0A0h - 0BFh -- General Purpose Register 48 Bytes

80 + 48 = 128 Bytes

This does not include the Common RAM. Or did I look at it wrong?

> I think this is a case where the bug should have been rejected.
> 
> Regards,
> 
> Rob
> 
> 

Regards,

Károly

On Fri, 11 Feb 2022 16:48:55 +0000
Rob Pearce <lis...@fl...> wrote:

> On 11/02/2022 13:48, Molnár Károly wrote:
> >
> > Please subscribe to the mailing list. This way I don't have to go to the administration interface to decide whether to allow or delete the mail.
> Sorry! I was already subscribed but I don't know which alias was used 
> (and these days it gets erased by the POP server). Back in the day I had 
> a mail client that could be told to do the right thing but Thunderbird 
> lacks that feature.
> >
> >> I'd volunteer to join the team but compilers are not my area of expertise
> >> (and I've just resurrected/forked another OSS project that needs some TLC)
> > In this case, what would you like to help with? As you wrote, it is indeed the compiler that needs to be improved and developed. This is often quite time-consuming. When I started working on it, I was slow to understand the context and how the code worked. I wanted to improve it, not break it.
> 
> I know what you mean!
> 
> I could probably help with validating and tidying any submitted patches. 
> I could (and probably should!) also have a go at trying to trace down 
> some of the outstanding bugs, especially those that I raised. I don't 
> want to promise too much - I'm an embedded guy really, have two jobs, 
> three OSS projects and am a developer on GPSim, so even without "too 
> many hobbies" I'd be keeping quite busy.
> 
> Regards,
> 
> Rob
> 
> 

I'll have little time to do this (since it was one of the reasons I stopped), but if I get help I'll try to do it occasionally. Thanks in advance for your contribution.

Regards,

Károly

On 11/02/2022 13:48, Molnár Károly wrote:
>
> Please subscribe to the mailing list. This way I don't have to go to the administration interface to decide whether to allow or delete the mail.
Sorry! I was already subscribed but I don't know which alias was used 
(and these days it gets erased by the POP server). Back in the day I had 
a mail client that could be told to do the right thing but Thunderbird 
lacks that feature.
>
>> I'd volunteer to join the team but compilers are not my area of expertise
>> (and I've just resurrected/forked another OSS project that needs some TLC)
> In this case, what would you like to help with? As you wrote, it is indeed the compiler that needs to be improved and developed. This is often quite time-consuming. When I started working on it, I was slow to understand the context and how the code worked. I wanted to improve it, not break it.

I know what you mean!

I could probably help with validating and tidying any submitted patches. 
I could (and probably should!) also have a go at trying to trace down 
some of the outstanding bugs, especially those that I raised. I don't 
want to promise too much - I'm an embedded guy really, have two jobs, 
three OSS projects and am a developer on GPSim, so even without "too 
many hobbies" I'd be keeping quite busy.

Regards,

Rob

On Thu, 10 Feb 2022 21:19:05 +0000
Rob Pearce via Gputils-devel <gpu...@li...> wrote:

> On 10/02/2022 11:44, Molnár Károly wrote:
> > I'm tired of the whole thing anyway. This is the reason why I haven't 
> > done anything with the project for years. Your patch made me want to 
> > spend some time on it. But only because I didn't want to waste your work.  
> 

Please subscribe to the mailing list. This way I don't have to go to the administration interface to decide whether to allow or delete the mail.

> Are you the only active maintainer now?

In fact, it is barely active. But I didn't want to unsubscribe from lists because then the project would be dead.

> The SF page lists six people, 
> though I recognise a couple of them as most likely retired.

I'm not young anymore either.

> I'd volunteer to join the team but compilers are not my area of expertise 
> (and I've just resurrected/forked another OSS project that needs some TLC)

In this case, what would you like to help with? As you wrote, it is indeed the compiler that needs to be improved and developed. This is often quite time-consuming. When I started working on it, I was slow to understand the context and how the code worked. I wanted to improve it, not break it.

> 
> Regards,
> 
> Rob
> 

Regards,
Molnár Károly

-- 

On 10/02/2022 11:44, Molnár Károly wrote:
> I'm tired of the whole thing anyway. This is the reason why I haven't 
> done anything with the project for years. Your patch made me want to 
> spend some time on it. But only because I didn't want to waste your work.

Are you the only active maintainer now? The SF page lists six people, 
though I recognise a couple of them as most likely retired. I'd 
volunteer to join the team but compilers are not my area of expertise 
(and I've just resurrected/forked another OSS project that needs some TLC)

Regards,

Rob

On 10/02/2022 12:44, Molnár Károly wrote:
> I apologise. I didn't copy into the text what I wanted.

No worries. Google translate came up with a pretty reasonable translation.

Thanks,
Schelte Bron.

On Thu, 10 Feb 2022 11:40:51 +0100
Schelte Bron <pic...@ot...> wrote:

> On 10/02/2022 10:06, Molnár Károly wrote:
> > Egyébként is belefáradtam az egészbe. Ez az oka annak hogy évek óta nem csináltam semmit sem a projecttel.
> 
> Translation: Anyway, I'm tired of it all. That’s why I haven’t done 
> anything with the project in years.

I apologise. I didn't copy into the text what I wanted. That would have been the full answer:

"At first sight, this seems to be the best solution. In my opinion, there will be no problem if there is an unofficial COD version. Otherwise, I think that the ELF format should have been used in the gputils project a long time ago. But that would have been a lot of work and I couldn't have managed it. I'm tired of the whole thing anyway. This is the reason why I haven't done anything with the project for years. Your patch made me want to spend some time on it. But only because I didn't want to waste your work. If you have the time and inclination to solve the problem, you could make another patch. I'll hopefully have enough time - if not immediately - to use it in a new svn version."

> I'm sad to learn you feel that way. But thanks for taking the time 
> anyway to apply my patch and respond to my question. I will discuss the 
> situation in the gpsim project, which relies on the cod file produced by 
> gpasm/gplink. If any conclusion comes from that, I will do my best to 
> create a patch.
> 
> 
> Thanks again,
> Schelte Bron.

Regards,
Molnár Károly

On 10/02/2022 10:06, Molnár Károly wrote:
> Egyébként is belefáradtam az egészbe. Ez az oka annak hogy évek óta nem csináltam semmit sem a projecttel.

Translation: Anyway, I'm tired of it all. That’s why I haven’t done 
anything with the project in years.

I'm sad to learn you feel that way. But thanks for taking the time 
anyway to apply my patch and respond to my question. I will discuss the 
situation in the gpsim project, which relies on the cod file produced by 
gpasm/gplink. If any conclusion comes from that, I will do my best to 
create a patch.

Thanks again,
Schelte Bron.

On Wed, 9 Feb 2022 15:58:11 +0100
Schelte Bron <pic...@ot...> wrote:

> All,
> 
> A few weeks ago I posted a patch [#77] to add the PIC16F184XX devices. I 
> now noticed that there is a problem for the LF version of these chips. 
> When trying to compile a program for the 16LF18426 for example, the 
> assembler reports a warning:
> 
> warning: This processor name ("16lf18426") too long to .COD file, it 
> will be truncated to 8 bytes length.
> 
> I checked the COD file format and found that it indeed only has space 
> reserved for a processor name of up to 8 characters. I'm unsure how to 
> fix this.
> 
> The Byte Craft web site seems to have disappeared at some point in 2020. 
> So getting an official update of the format that allows longer processor 
> names will probably not be possible.
> 
> Should the name perhaps be shortened to 16l18426? There appear to be 42 
> bytes left at the end of the main directory block. Can we simply decide 
> to take 16 bytes from there to store the real name, while leaving the 
> truncated or shortened name in the normal place for some feeble attempt 
> at backward compatibility?
> 

At first sight, this seems to be the best solution. Véleményem szerint nem lesz baj azzal ha létezni fog egy nem hivatalos COD verzió is. Egyébként pedig szerintem már jó ideje át kellett volna térni az ELF formátum használatára a gputils projectben. De az rengeteg munka lenne és nem tudtam volna megoldani. Egyébként is belefáradtam az egészbe. Ez az oka annak hogy évek óta nem csináltam semmit sem a projecttel. Az ön patch-je miatt késztett arra hogy egy kevés időt szánjak rá. De csak azért mert nem akartam hogy kárba vesszen a munkája. Ha van kedve és ideje megoldani a problémát akkor készíthetne egy újabb patch-et. Annyi időm remélhetőleg lesz - ha nem is azonnal - hogy felhasználjam egy újabb svn verzióban.

> Another option may be to store the remainder of the name in a subsequent 
> directory block. The PIC16F184XX devices will normally have such a block 
> anyway, because the config words have an address above 0xffff. Currently 
> the processor field in a subsequent directory block is empty.
> 
> Any other ideas?
> 
> 
> Regards,
> Schelte Bron

Regards,
Molnár Károly

All,

A few weeks ago I posted a patch [#77] to add the PIC16F184XX devices. I 
now noticed that there is a problem for the LF version of these chips. 
When trying to compile a program for the 16LF18426 for example, the 
assembler reports a warning:

warning: This processor name ("16lf18426") too long to .COD file, it 
will be truncated to 8 bytes length.

I checked the COD file format and found that it indeed only has space 
reserved for a processor name of up to 8 characters. I'm unsure how to 
fix this.

The Byte Craft web site seems to have disappeared at some point in 2020. 
So getting an official update of the format that allows longer processor 
names will probably not be possible.

Should the name perhaps be shortened to 16l18426? There appear to be 42 
bytes left at the end of the main directory block. Can we simply decide 
to take 16 bytes from there to store the real name, while leaving the 
truncated or shortened name in the normal place for some feeble attempt 
at backward compatibility?

Another option may be to store the remainder of the name in a subsequent 
directory block. The PIC16F184XX devices will normally have such a block 
anyway, because the config words have an address above 0xffff. Currently 
the processor field in a subsequent directory block is empty.

Any other ideas?

Regards,
Schelte Bron

Forget it, problem was missing space between CLI switches and arguments. 

Sorry about the noise.

wbr Kusti

I'm trying to use gpasm/gplink on a project that used to compile with mpasmx/mplink.

The compile stage goes fine:

gpasm boot.asm -o boot.o --mpasm-compatible -p18F45K50 -c -DBOOTLOADER_VID=0x1D50 -DBOOTLOADER_PID=0x6020 -DXTEA_KEY=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
gpasm boot_asm.asm -o boot_asm.o --mpasm-compatible -p18F45K50 -c -DBOOTLOADER_VID=0x1D50 -DBOOTLOADER_PID=0x6020 -DXTEA_KEY=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
gpasm usb.asm -o usb.o --mpasm-compatible -p18F45K50 -c -DBOOTLOADER_VID=0x1D50 -DBOOTLOADER_PID=0x6020 -DXTEA_KEY=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
usb.asm:321:Message[305] Using default destination of 1 (file).
gpasm usb_desc.asm -o usb_desc.o --mpasm-compatible -p18F45K50 -c -DBOOTLOADER_VID=0x1D50 -DBOOTLOADER_PID=0x6020 -DXTEA_KEY=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
usb_desc.asm:160:Warning[212] Expected (ENDIF)
gpasm vectors.asm -o vectors.o --mpasm-compatible -p18F45K50 -c -DBOOTLOADER_VID=0x1D50 -DBOOTLOADER_PID=0x6020 -DXTEA_KEY=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
gpasm xtea.asm -o xtea.o --mpasm-compatible -p18F45K50 -c -DBOOTLOADER_VID=0x1D50 -DBOOTLOADER_PID=0x6020 -DXTEA_KEY=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

but link fails:

nyholku@Kustaas-MacBook-Pro fw % gplink -s bootloader.lkr -p18F45K50  boot.o   boot_asm.o   usb.o   usb_desc.o   vectors.o   xtea.o  -mbootloader.map -obootloader.cof

error: Invalid character 0x46 in number constant.
error: Invalid character 0x6f in number constant.

If I leave out my linker script it fails also with the default linker script

nyholku@Kustaas-MacBook-Pro fw % gplink boot.o   boot_asm.o   usb.o   usb_desc.o   vectors.o   xtea.o  -mbootloader.map -obootloader.cof                              

error: Invalid character 0x6f in number constant.
message: Using default linker script "/usr/local/share/gputils/lkr/18f45k50_g.lkr".

any ideas?

cheers Kusti

I did some further tests.

I managed to compile SDCC 3.4.0 on Bug Sur with following configure

./configure --prefix ~/sdcc340 CFLAGS='-g -O2 -w' CXXFLAGS='-g -O2 -w'

where the  '-w' switch  ignored warnings.

This compiles my project but gplink fails.

So I thought this points to gputils as the problem.

I then rebooted to High Sierra and checked the gplink/gpasm versions (which work):

On High Sierra I have:

gplink-1.5.0 #1284 (May 12 2019)

On Big Sur I have:

gplink-1.5.0 #1285 (Nov 15 2020)

The SDCC compiler is now same version (though not same build as I built from source
with more resent macOS tools) and gplink is same version (but apparently that
tool is different buld) I'm a bit confused how to proceed...

cheers Kusti

> On 29. Jun 2021, at 8.50, Kustaa Nyholm <ea...@ea...> wrote:
> 
> I don't know if this is SDCC or gputils problem, probably later, but reporting this here too ( seen end of post for the full error message):
> 
> 
> This is on macOS Big Sur 11.3.1
> 
> brew info gputils
> gputils: stable 1.5.0-1 (bottled)
> GNU PIC Utilities
> https://gputils.sourceforge.io/ <https://gputils.sourceforge.io/>
> /usr/local/Cellar/gputils/1.5.0-1 (5,332 files, 122MB) *
>   Poured from bottle on 2021-05-19 at 12:16:58
> From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gputils.rb <https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gputils.rb>
> License: GPL-2.0
> ==> Analytics
> install: 63 (30 days), 268 (90 days), 1,183 (365 days)
> install-on-request: 10 (30 days), 41 (90 days), 160 (365 days)
> build-error: 0 (30 days)
> 
> nyholku@Kustaas-MBP src % brew info sdcc   
> sdcc: stable 4.1.0 (bottled), HEAD
> ANSI C compiler for Intel 8051, Maxim 80DS390, and Zilog Z80
> https://sdcc.sourceforge.io/ <https://sdcc.sourceforge.io/>
> /usr/local/Cellar/sdcc/4.1.0 (10,940 files, 293.4MB) *
>   Poured from bottle on 2021-05-19 at 12:22:49
> From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/sdcc.rb <https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/sdcc.rb>
> License: GPL-2.0-only and GPL-3.0-only and Public Domain and Zlib
> ==> Dependencies
> Build: autoconf ✘, automake ✘
> Required: boost ✘, gputils ✔, readline ✔
> ==> Options
> --HEAD
> 	Install HEAD version
> ==> Analytics
> install: 146 (30 days), 713 (90 days), 2,087 (365 days)
> install-on-request: 145 (30 days), 707 (90 days), 2,055 (365 days)
> build-error: 0 (30 days)
> 
> 
> 
> Asdcc: Calling linker...
> + /usr/local/bin/gplink -I/Volumes/Partition2/Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -I/usr/local/bin/../share/sdcc/lib/pic16 -I/usr/local/Cellar/sdcc/4.1.0/share/sdcc/lib/pic16 -I/usr/local/bin/../share/sdcc/non-free/lib/pic16 -I/usr/local/Cellar/sdcc/4.1.0/share/sdcc/non-free/lib/pic16  -f 0xffff  -m -s18f45k50.lkr  -w -r -o ../obj/toad4.hex  ../obj/main.o ../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o ../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o ../obj/swuart.o ../obj/hi_speed_irq.o   libc18f.lib libio18f45k50.lib libm18f.lib libsdcc.lib libdev18f45k50.lib libsdcc.lib 
> warning: "/usr/local/bin/../share/sdcc/lib/pic16/libio18f45k50.lib" is missing symbol index.
> Assertion failed: (gp_archive_have_index(Archive)), function gp_archive_read_index, file gparchive.c, line 598.
> + /usr/local/bin/gplink -I/Volumes/Partition2/Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -I/usr/local/bin/../share/sdcc/lib/pic16 -I/usr/local/Cellar/sdcc/4.1.0/share/sdcc/lib/pic16 -I/usr/local/bin/../share/sdcc/non-free/lib/pic16 -I/usr/local/Cellar/sdcc/4.1.0/share/sdcc/non-free/lib/pic16  -f 0xffff  -m -s18f45k50.lkr  -w -r -o ../obj/toad4.hex  ../obj/main.o ../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o ../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o ../obj/swuart.o ../obj/hi_speed_irq.o   libc18f.lib libio18f45k50.lib libm18f.lib libsdcc.lib libdev18f45k50.lib libsdcc.lib  returned errorcode 6
> m
> _______________________________________________
> Gputils-devel mailing list
> Gpu...@li...
> https://lists.sourceforge.net/lists/listinfo/gputils-devel

I don't know if this is SDCC or gputils problem, probably later, but reporting this here too ( seen end of post for the full error message):

This is on macOS Big Sur 11.3.1

brew info gputils
gputils: stable 1.5.0-1 (bottled)
GNU PIC Utilities
https://gputils.sourceforge.io/ <https://gputils.sourceforge.io/>
/usr/local/Cellar/gputils/1.5.0-1 (5,332 files, 122MB) *
  Poured from bottle on 2021-05-19 at 12:16:58
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gputils.rb <https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/gputils.rb>
License: GPL-2.0
==> Analytics
install: 63 (30 days), 268 (90 days), 1,183 (365 days)
install-on-request: 10 (30 days), 41 (90 days), 160 (365 days)
build-error: 0 (30 days)

nyholku@Kustaas-MBP src % brew info sdcc   
sdcc: stable 4.1.0 (bottled), HEAD
ANSI C compiler for Intel 8051, Maxim 80DS390, and Zilog Z80
https://sdcc.sourceforge.io/ <https://sdcc.sourceforge.io/>
/usr/local/Cellar/sdcc/4.1.0 (10,940 files, 293.4MB) *
  Poured from bottle on 2021-05-19 at 12:22:49
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/sdcc.rb <https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/sdcc.rb>
License: GPL-2.0-only and GPL-3.0-only and Public Domain and Zlib
==> Dependencies
Build: autoconf ✘, automake ✘
Required: boost ✘, gputils ✔, readline ✔
==> Options
--HEAD
	Install HEAD version
==> Analytics
install: 146 (30 days), 713 (90 days), 2,087 (365 days)
install-on-request: 145 (30 days), 707 (90 days), 2,055 (365 days)
build-error: 0 (30 days)

Asdcc: Calling linker...
+ /usr/local/bin/gplink -I/Volumes/Partition2/Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -I/usr/local/bin/../share/sdcc/lib/pic16 -I/usr/local/Cellar/sdcc/4.1.0/share/sdcc/lib/pic16 -I/usr/local/bin/../share/sdcc/non-free/lib/pic16 -I/usr/local/Cellar/sdcc/4.1.0/share/sdcc/non-free/lib/pic16  -f 0xffff  -m -s18f45k50.lkr  -w -r -o ../obj/toad4.hex  ../obj/main.o ../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o ../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o ../obj/swuart.o ../obj/hi_speed_irq.o   libc18f.lib libio18f45k50.lib libm18f.lib libsdcc.lib libdev18f45k50.lib libsdcc.lib 
warning: "/usr/local/bin/../share/sdcc/lib/pic16/libio18f45k50.lib" is missing symbol index.
Assertion failed: (gp_archive_have_index(Archive)), function gp_archive_read_index, file gparchive.c, line 598.
+ /usr/local/bin/gplink -I/Volumes/Partition2/Users/nyholku/sdcc-3.4.0/share/sdcc/non-free/lib/pic16 -I/usr/local/bin/../share/sdcc/lib/pic16 -I/usr/local/Cellar/sdcc/4.1.0/share/sdcc/lib/pic16 -I/usr/local/bin/../share/sdcc/non-free/lib/pic16 -I/usr/local/Cellar/sdcc/4.1.0/share/sdcc/non-free/lib/pic16  -f 0xffff  -m -s18f45k50.lkr  -w -r -o ../obj/toad4.hex  ../obj/main.o ../obj/toad4.o ../obj/usb_hid.o ../obj/usb_core.o ../obj/usb_pic_defs.o ../obj/usb_user_config.o ../obj/command_queue.o ../obj/crt0iz_toad4.o ../obj/swuart.o ../obj/hi_speed_irq.o   libc18f.lib libio18f45k50.lib libm18f.lib libsdcc.lib libdev18f45k50.lib libsdcc.lib  returned errorcode 6
m
Ok,

found the problem.

I had earlier in the code
	udata
ram	rmb	0x600
	org 	0x400

and it seems that 'org' implies code section and thus the conflict.

So for posterity, this works:

	udata	0x600
ram	rmb 	0x400	
	code
	org xxx
	org yyy
	...
	etc

wbr Kusti

> On 28 Dec 2020, at 18.48, Kustaa Nyholm <kus...@sp...> wrote:
> 
> I get these two mysterious errors:
> 
> 
> Error[154]   Each object file section must be contiguous: ".org_000400"
> Error[1101]   _update_reloc_ptr() -- Unknown relocation symbol number: 157
> 
> The code is below is the code. Brief explanatio:
> 
> I have three computed gotos that branch to addresses 16 bytes apart.
> 
> The first one at 0x300 compiles fine.
> 
> 
> But adding the exact same pattern again at 0x400 produces the error 154
> and apparently also error 1101.
> 
> Is this a bug or limitation in gpasm?
> 
> How many 'org's are allowed?
> 
> Why the first instance of this pattern is ok, but not the next one?
> 
> If I remove the last two computed gotos and associated orgs then it compiles fine.
> 
> wbr Kusti
> 
> 
> 
> ;
>       org         0x300
> ;
>       MOVF        OPCODE, w, a 
>       MULLW       16
> ;
>       ADDWF       _PCL, f, a
> ;
>       org         0x306
> <snip>
>       org         0x316
> <snip>
>       org         0x326
> 
> etcetc
> 
>        org         0x3F6
> ;
> ;
>        org         0x400 <==== Each object file section must be contiguous: ".org_000400"
> ;
>        MOVF        OPCODE, w, a 
>        MULLW       16
> ;
>        ADDWF       _PCL, f, a
> ;
> 
> <snip>
>        org         0x406
> <snip>
>       org         0x416
> <snip>
>        org         0x426
> <snip>
> ;
> 
> etcetch
> 
>        org         0x500
> ;
>        MOVF        OPCODE, w, a 
>        MULLW       16
> ;
>        ADDWF       _PCL, f, a
> 
> ;
>        org         0x5F6 <==== _update_reloc_ptr() -- Unknown relocation symbol number: 157	
> ;
> ;--------------------------------------------------------
> 
>        end
> 
> 
> 
> _______________________________________________
> Gputils-devel mailing list
> Gpu...@li...
> https://lists.sourceforge.net/lists/listinfo/gputils-devel

I get these two mysterious errors:

Error[154]   Each object file section must be contiguous: ".org_000400"
Error[1101]   _update_reloc_ptr() -- Unknown relocation symbol number: 157

The code is below is the code. Brief explanatio:

I have three computed gotos that branch to addresses 16 bytes apart.

The first one at 0x300 compiles fine.

But adding the exact same pattern again at 0x400 produces the error 154
and apparently also error 1101.

Is this a bug or limitation in gpasm?

How many 'org's are allowed?

Why the first instance of this pattern is ok, but not the next one?

If I remove the last two computed gotos and associated orgs then it compiles fine.

wbr Kusti

;
       org         0x300
;
       MOVF        OPCODE, w, a 
       MULLW       16
;
       ADDWF       _PCL, f, a
;
       org         0x306
<snip>
       org         0x316
<snip>
       org         0x326

etcetc

        org         0x3F6
;
;
        org         0x400 <==== Each object file section must be contiguous: ".org_000400"
;
        MOVF        OPCODE, w, a 
        MULLW       16
;
        ADDWF       _PCL, f, a
;

<snip>
        org         0x406
<snip>
       org         0x416
<snip>
        org         0x426
<snip>
;

etcetch

        org         0x500
;
        MOVF        OPCODE, w, a 
        MULLW       16
;
        ADDWF       _PCL, f, a

;
        org         0x5F6 <==== _update_reloc_ptr() -- Unknown relocation symbol number: 157	
;
;--------------------------------------------------------

        end

I tired load software compiled on gpasm 1.5.2 today on a PIC18F2550 
and that is broken as well.
So I've had to go back to 0.13.7 again.
I seeing failures after compile of port reads and port writes port writes, and it looks like the
maths routines are affected as well.
the same asm file compiles without error and runs when compiled with gpasm 0.13.7 and
the current version on mpasm on MPLABX
The hex files from gpasm 1.5.2 and 0.13.7 are different , running diff shows this

Really not good enough from the gputils team , this was reported two years ago and absolutely
ignored.
The .asm file is used to control a AD9912 DDS and hardware on a transceiver.The .asm is large .
I can upload the .asm file should anyone feel like bothering about it.
I feel VERY aggrieved that this situation seem to be , we dont care and we are going to ignore it.
Strange that others have reported bugs on the wiki, I wonder if they got ignored when sending bug
reports as well.

-- 
-- 
Best wishes /73 
Richard Bown

Email : ri...@g8...
HTTP  :  http://www.g8jvm.com
nil carborundum a illegitemis
##################################################################################
Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W & 3cms 5W
Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
OS: Linux Mint 18.1  x86_64 on a Dell Inspiron N5030 laptop
################################################################################## 

Hi
I've joined the list as I like GPutils, and I find MplabX very bloated
But I have a problem and I'm stuck on a very early version, gpasm-0.13.7 beta
the reason is the later versions dont compile code I have for a 18F2550
Piklab says it has 7800 lines
What the later versions compile just doesn't run, yet it build fine on 0.13.3 and mplab with
windows.
Is this a known problem , or and I in such a low minority its tough luck ?

thanks
-- 
-- 
Best wishes /73 
Richard Bown

Email : ri...@g8...
HTTP  :  http://www.g8jvm.com
nil carborundum a illegitemis
##################################################################################
Ham Call: G8JVM . QRV: 50-432 MHz + Microwave 23 cms 140W, 13 cms 100W & 3cms 5W
Maidenhead QRA: IO82SP38, LAT. 52 39.720' N LONG. 2 28.171 W
QRV VHF 6mtrs 200W, 4 mtrs 150W, 2mtrs 400W, 70cms 200W
OS: Linux Mint 18.1  x86_64 on a Dell Inspiron N5030 laptop
################################################################################## 

Thanks, Károly.  I can certainly relate to that.  No rush from my point
of view, I was just wondering whether I'd have a non-MPASMX toolchain
if I picked that particular PIC.

Regards,

Pete Restall

-----Original Message-----
From: Molnár Károly <pr...@hd...>
To: Pete Restall <pe...@re...>
Subject: Re: [Gputils-devel] PIC16F15385 ?
Date: Mon, 8 May 2017 21:35:44 +0200

On Mon, 08 May 2017 13:52:54 +0100
Pete Restall <pe...@re...> wrote:

> Hello,
> 
> I'm currently looking at using a PIC16F15385 in an upcoming project. 
> It seems brand-spanking new though, so I'm wondering if there are any
> plans for incorporation (relatively soon) into the gputils toolchain
> ?
> 
> Cheers,
> 
> Pete Restall
> 

I should have been long ago to update the list of supported processors.
Before that, I wanted to develop even a new thing, but I'm slow to move
on with him. Few of my time. I'm trying to update the supported
devices. Maybe ready next week. I'm trying to update the supported
devices.

Molnár Károly

Hello,

I'm currently looking at using a PIC16F15385 in an upcoming project. 
It seems brand-spanking new though, so I'm wondering if there are any
plans for incorporation (relatively soon) into the gputils toolchain ?

Cheers,

Pete Restall

2017	Jan	Feb (2)	Mar	Apr (2)	May (2)	Jun (2)	Jul	Aug	Sep	Oct	Nov	Dec
2020	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (2)
2021	Jan	Feb	Mar	Apr	May	Jun (2)	Jul (2)	Aug	Sep	Oct	Nov	Dec
2022	Jan	Feb (11)	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2023	Jan	Feb	Mar (3)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2024	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec

gputils-devel Mailing List for gputils

gputils-devel — Development chatter about gputils