You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(1) |
Sep
(2) |
Oct
(4) |
Nov
(2) |
Dec
(8) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(6) |
Feb
|
Mar
|
Apr
(5) |
May
(5) |
Jun
(16) |
Jul
(9) |
Aug
(10) |
Sep
(10) |
Oct
(4) |
Nov
(4) |
Dec
(11) |
2004 |
Jan
(27) |
Feb
(29) |
Mar
(94) |
Apr
(34) |
May
(27) |
Jun
(69) |
Jul
(48) |
Aug
(27) |
Sep
(46) |
Oct
(25) |
Nov
(21) |
Dec
(19) |
2005 |
Jan
(26) |
Feb
(18) |
Mar
(9) |
Apr
(8) |
May
(23) |
Jun
(58) |
Jul
(5) |
Aug
(8) |
Sep
(59) |
Oct
(38) |
Nov
(27) |
Dec
(19) |
2006 |
Jan
(2) |
Feb
(3) |
Mar
(54) |
Apr
(53) |
May
(72) |
Jun
(15) |
Jul
(16) |
Aug
(2) |
Sep
(32) |
Oct
(47) |
Nov
(99) |
Dec
(16) |
2007 |
Jan
(28) |
Feb
(29) |
Mar
(18) |
Apr
(3) |
May
(6) |
Jun
(4) |
Jul
(1) |
Aug
(3) |
Sep
(7) |
Oct
(31) |
Nov
(16) |
Dec
(8) |
2008 |
Jan
(12) |
Feb
(1) |
Mar
|
Apr
(13) |
May
(9) |
Jun
(25) |
Jul
(9) |
Aug
(7) |
Sep
(9) |
Oct
(1) |
Nov
(18) |
Dec
(5) |
2009 |
Jan
(6) |
Feb
(41) |
Mar
(12) |
Apr
(13) |
May
(10) |
Jun
(13) |
Jul
(19) |
Aug
(7) |
Sep
(10) |
Oct
(10) |
Nov
(13) |
Dec
(17) |
2010 |
Jan
(6) |
Feb
(7) |
Mar
(36) |
Apr
(23) |
May
(49) |
Jun
(61) |
Jul
(11) |
Aug
(7) |
Sep
(2) |
Oct
(24) |
Nov
(3) |
Dec
(6) |
2011 |
Jan
(32) |
Feb
(43) |
Mar
(19) |
Apr
(15) |
May
(51) |
Jun
(34) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
(8) |
Nov
(7) |
Dec
|
2012 |
Jan
(8) |
Feb
(5) |
Mar
(8) |
Apr
(8) |
May
(6) |
Jun
(2) |
Jul
|
Aug
(7) |
Sep
(7) |
Oct
|
Nov
(1) |
Dec
(2) |
2013 |
Jan
(5) |
Feb
(1) |
Mar
(31) |
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
(18) |
Sep
(10) |
Oct
|
Nov
|
Dec
(2) |
2014 |
Jan
(5) |
Feb
|
Mar
|
Apr
(23) |
May
(6) |
Jun
(4) |
Jul
(13) |
Aug
(2) |
Sep
(10) |
Oct
(2) |
Nov
(10) |
Dec
(5) |
2015 |
Jan
(16) |
Feb
(1) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
(6) |
Nov
|
Dec
|
2016 |
Jan
(26) |
Feb
(27) |
Mar
|
Apr
(2) |
May
(6) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2017 |
Jan
(6) |
Feb
|
Mar
(6) |
Apr
(5) |
May
(1) |
Jun
(7) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
2021 |
Jan
(1) |
Feb
|
Mar
(57) |
Apr
(2) |
May
(3) |
Jun
(11) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2022 |
Jan
(15) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(6) |
Dec
(18) |
2023 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(3) |
Dec
|
2024 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Roy R. <rr...@ih...> - 2024-09-26 04:52:11
|
I have been working for some time in getting a version of gpsim using GTK3 > 3.20 working. I had two motivations for doing this. Firstly someone reported that gpsim was too small on a high resolution display. GTK3 does support scaling which GTK2 does not. Secondly I suspect that support for GTK2 may soon be going away as they are already up to GTK4. I have uploaded my current work to the sourceforge repository under branches/gpsim-gtk3. I consider it to alpha level code at best and there are still some known issues, but other people using and reporting issues or patches with the code would now be very helpful. Several issues I am aware of are 1> register view window slows down execution times 2> There is an intermittent issue with single stepping. 3> Sometimes the Source Browser window will scroll horizontally. To get code using svn use "svn checkout https://svn.code.sf.net/p/gpsim/code/brances/gpsim-gtk3 gpsim-code" or use the "Download Snapshot" feature in the branches/gpsim-gtk3 page on sourceforge Roy Rankin |
From: Michele A. <mic...@gm...> - 2024-07-09 18:48:42
|
Hi Roy, anyway... if you don't think this is an useful addition, just tell me with no problems. I was thinking that maybe the same task (adding source code references) could be done by commands, but I can't find a suitable one, only "symbol" to define a symbol. Maybe if a command existed to add a source line, like for example: source <address> <file> <linenum> the same goal (enabling source debugging and not only disassembled code) could be achieved independently from the compiler used. Bye Michele Il 09/07/24 12:07, Roy Rankin ha scritto: > Michele, > > I have loaded your patch into my local copy of gpsim and see no issues > with it how you use it on the program command line. However, there were > issues when I tried to load a hex and cmf via an stc file. I think I > have resolved these issues and will be committing the patch after > further testing and updating the documentation. > > Roy Rankin > > > On 2/7/24 20:39, Michele Alessandrini wrote: >> Hi, >> as I mentioned to one of the authors, I developed a patch to get full >> source debug for programs developed with MPLAB X (official Microchip >> IDE). >> MPLAB produces ELF object files (not COD as supported by gpsim) and >> the normal HEX. Elf is quite difficult to use, but it also generates a >> CMF file, a text file with source-binary matching and symbols. >> So my idea is loading CMF file in place of COD (after all "-s" is for >> symbol file, so it seemed the right place to me). It still needs HEX >> file and processor specification, example: >> gpsim -s myprog.cmf -p p16f887 myprog.hex >> >> So attached is my proposed patch. I hope it can be useful, it allows >> full source debug using MPLAB. I tried to integrate it well in the >> structure and style of the program. >> >> Let me know! >> Bye >> Michele Alessandrini >> >> >> _______________________________________________ >> gpsim-devel mailing list >> gps...@li... >> https://lists.sourceforge.net/lists/listinfo/gpsim-devel > > > _______________________________________________ > gpsim-devel mailing list > gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsim-devel |
From: Michele A. <mic...@gm...> - 2024-07-09 10:49:05
|
Thank you very much. I'm afraid I'm not getting the full picture for a program that complex. Il 09/07/24 12:07, Roy Rankin ha scritto: > Michele, > > I have loaded your patch into my local copy of gpsim and see no issues > with it how you use it on the program command line. However, there were > issues when I tried to load a hex and cmf via an stc file. I think I > have resolved these issues and will be committing the patch after > further testing and updating the documentation. > > Roy Rankin > > > On 2/7/24 20:39, Michele Alessandrini wrote: >> Hi, >> as I mentioned to one of the authors, I developed a patch to get full >> source debug for programs developed with MPLAB X (official Microchip >> IDE). >> MPLAB produces ELF object files (not COD as supported by gpsim) and >> the normal HEX. Elf is quite difficult to use, but it also generates a >> CMF file, a text file with source-binary matching and symbols. >> So my idea is loading CMF file in place of COD (after all "-s" is for >> symbol file, so it seemed the right place to me). It still needs HEX >> file and processor specification, example: >> gpsim -s myprog.cmf -p p16f887 myprog.hex >> >> So attached is my proposed patch. I hope it can be useful, it allows >> full source debug using MPLAB. I tried to integrate it well in the >> structure and style of the program. >> >> Let me know! >> Bye >> Michele Alessandrini >> >> >> _______________________________________________ >> gpsim-devel mailing list >> gps...@li... >> https://lists.sourceforge.net/lists/listinfo/gpsim-devel > > > _______________________________________________ > gpsim-devel mailing list > gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsim-devel |
From: Roy R. <rr...@ih...> - 2024-07-09 10:38:14
|
Michele, I have loaded your patch into my local copy of gpsim and see no issues with it how you use it on the program command line. However, there were issues when I tried to load a hex and cmf via an stc file. I think I have resolved these issues and will be committing the patch after further testing and updating the documentation. Roy Rankin On 2/7/24 20:39, Michele Alessandrini wrote: > Hi, > as I mentioned to one of the authors, I developed a patch to get full > source debug for programs developed with MPLAB X (official Microchip > IDE). > MPLAB produces ELF object files (not COD as supported by gpsim) and > the normal HEX. Elf is quite difficult to use, but it also generates a > CMF file, a text file with source-binary matching and symbols. > So my idea is loading CMF file in place of COD (after all "-s" is for > symbol file, so it seemed the right place to me). It still needs HEX > file and processor specification, example: > gpsim -s myprog.cmf -p p16f887 myprog.hex > > So attached is my proposed patch. I hope it can be useful, it allows > full source debug using MPLAB. I tried to integrate it well in the > structure and style of the program. > > Let me know! > Bye > Michele Alessandrini > > > _______________________________________________ > gpsim-devel mailing list > gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsim-devel |
From: Michele A. <mic...@gm...> - 2024-07-02 10:40:03
|
Hi, as I mentioned to one of the authors, I developed a patch to get full source debug for programs developed with MPLAB X (official Microchip IDE). MPLAB produces ELF object files (not COD as supported by gpsim) and the normal HEX. Elf is quite difficult to use, but it also generates a CMF file, a text file with source-binary matching and symbols. So my idea is loading CMF file in place of COD (after all "-s" is for symbol file, so it seemed the right place to me). It still needs HEX file and processor specification, example: gpsim -s myprog.cmf -p p16f887 myprog.hex So attached is my proposed patch. I hope it can be useful, it allows full source debug using MPLAB. I tried to integrate it well in the structure and style of the program. Let me know! Bye Michele Alessandrini |
From: <rr...@ih...> - 2024-03-21 06:28:20
|
I seek a wider opinion on bug 292 which I closed and have reopened for more input . Some processors such as the 12F675 are shipped with the last program instruction (0x3ff on 12F675) with 0x34XX (retlw 0xXX) where XX is the factory RC calibration correction. The data sheet provides an example of "call 0x3ff; movwf OSCCAL" to set the RC oscillator calibration to the factory value.Currently in gpsim the last instruction is the default blank value of 0x3fff. When the above call is executed gpsim steps the PC to 0x400 which causes a memory violation which resets the PC to 0 causing an infinite loop. I originally closed the bug on the basis that doing a bulk erase prior to loading the program will clear the factory value. The programing spec indicates you should read the value prior to erase and reload it with the program. Thus I provided a way to do this in the test code. The creator of the bug countered that this should be the responsibility of the programing tools rather than the program developer. So the question is should gpsim put a valid instruction, probably 0x3480, as default into this program address? |
From: <rr...@ih...> - 2023-11-14 03:13:36
|
I am declaring 0.32.1 as the new release. I discovered that my windows build was not working on my windows partition and have just downloaded a windows build that works for me. The source tarball has been up a week and is the official release. Roy Rankin |
From: Schelte B. <pic...@ot...> - 2023-11-02 11:44:27
|
I have sometimes contemplated if it wouldn't be a nice idea to embed Tcl/Tk in gpsim. First of all, that would provide a full-fledged scripting language to gpsim instead of the rather limited cli that is currently provided. This is exactly the kind of use-case Tcl was originally created for. And with Tk, it would be able to take care of the GUI part as well. Tcl and Tk work on linux, windows, and mac. However, the mere mention of Tcl usually evokes a knee-jerk reaction from ill-informed people that just regurgitate 25 year old objections, several of which were false even back then. And development of Tcl has continued in the last 25 years. But because I don't like fighting windmills, I haven't brought it up so far. I'd be willing to explore the possibility if there is serious interest in going this route. But that would also not be feasible for the coming release. Schelte. On 02/11/2023 04:33, rr...@ih... wrote: > Zbigniew, > > I have spent the last week investigating what it would take to add this > capability to gpsim. It looks to me that the best way to do this is move > the GUI from gdk2 to gdk3. I have gotten a trial build to actually build > under linux, however it needs some issues with the display to be fixed. > Note that I am not a GUI expert. The biggest issue with getting it done > is that I do not see a gdk3 build for mingw and other mingw libraries > may be required to build. Without this the windows build cannot be done > which I see as a core requirement for a release. > > The change from gtk2 to gtk3 is too major a change for a last minute > change immediately before a release. I thus plan not to do this before > this coming release, but make it a priority for the next release which > will go out as soon as possible. > > Any help with either the GUI transition or the windows build would be a > big help. Let me know if you can help and I will share to you what > knowledge and code I have. > > Roy |
From: <rr...@ih...> - 2023-11-02 03:33:45
|
Zbigniew, I have spent the last week investigating what it would take to add this capability to gpsim. It looks to me that the best way to do this is move the GUI from gdk2 to gdk3. I have gotten a trial build to actually build under linux, however it needs some issues with the display to be fixed. Note that I am not a GUI expert. The biggest issue with getting it done is that I do not see a gdk3 build for mingw and other mingw libraries may be required to build. Without this the windows build cannot be done which I see as a core requirement for a release. The change from gtk2 to gtk3 is too major a change for a last minute change immediately before a release. I thus plan not to do this before this coming release, but make it a priority for the next release which will go out as soon as possible. Any help with either the GUI transition or the windows build would be a big help. Let me know if you can help and I will share to you what knowledge and code I have. Roy ----- Original Message ----- From: "Zbigniew" To: Cc: Sent:Fri, 27 Oct 2023 11:37:38 +0200 Subject:Re: [gpsim-devel] Gpsim release candidate > I have changed the release number of gpsim to 0.32.0 and I am calling > the SVN code a release candid. > A new release is well overdue. Unless anyone has any commits I > will declare the SVN a new release in about a weeks time. If > anyone does have changes they want in the new release please > commit them now or let it be known on this list. Before new release please either add an option allowing to make its GUI bigger, or at least make Gpsim respecting GDK_DPI_SCALE environment variable! For today's standards — I mean the screen resolutions used today — the windows of Gpsim are way too small. And it's not possible to „fix” that at least by simple: export GDK_DPI_SCALE=2 ; gpsim Why? -- regards, Zbigniew _______________________________________________ gpsim-devel mailing list gps...@li... https://lists.sourceforge.net/lists/listinfo/gpsim-devel |
From: Schelte B. <pic...@ot...> - 2023-10-29 13:42:15
|
On 27/10/2023 14:28, rr...@ih... wrote: > I would be happy for you to merge your p16f1847 branch. > Done. I had some trouble figuring out the correct merge command syntax as the svn version on the server seems to predate v1.5 and most online documentation is for later versions. But I think I managed in the end. Schelte. |
From: Schelte B. <pic...@ot...> - 2023-10-27 10:07:22
|
On 27/10/2023 05:43, rr...@ih... wrote: > I have changed the release number of gpsim to 0.32.0 and I am calling > the SVN code a release candid. > > A new release is well overdue. Unless anyone has any commits I will > declare the SVN a new release in about a weeks time. If anyone does > have changes they want in the new release please commit them now or > let it be known on this list. > Excellent suggestion. I would like to merge the p16f1847 branch. I have been using it for the past year and in my opinion it is ready to be included. Any objections? Schelte. |
From: Zbigniew <zbi...@gm...> - 2023-10-27 09:37:49
|
> I have changed the release number of gpsim to 0.32.0 and I am calling > the SVN code a release candid. > A new release is well overdue. Unless anyone has any commits I > will declare the SVN a new release in about a weeks time. If > anyone does have changes they want in the new release please > commit them now or let it be known on this list. Before new release please either add an option allowing to make its GUI bigger, or at least make Gpsim respecting GDK_DPI_SCALE environment variable! For today's standards — I mean the screen resolutions used today — the windows of Gpsim are way too small. And it's not possible to „fix” that at least by simple: export GDK_DPI_SCALE=2 ; gpsim Why? -- regards, Zbigniew |
From: <rr...@ih...> - 2023-10-27 04:05:34
|
I have changed the release number of gpsim to 0.32.0 and I am calling the SVN code a release candid. A new release is well overdue. Unless anyone has any commits I will declare the SVN a new release in about a weeks time. If anyone does have changes they want in the new release please commit them now or let it be known on this list. Roy Rankin |
From: Schelte B. <pic...@ot...> - 2023-01-31 22:53:14
|
All, In CCPCON::capture_start(), on line 1394 of 14bit-tmrs.cc, there is a call to: config_output(0, true, true); The first "true" argument indicates that the I/O pin is to be used as an output. The second "true" argument specifies that it should be used as an input. That doesn't make sense. The pin is either input or output, not both. For the capture function, it should be an input. Assuming this isn't a typo, also specifying "true" for output may have been done to update the GUIname of the pin to ccpX. The problem is that configuring the pin as output overwrites any other output function that was set up on this pin before. In my case the pin is already configured as comparator output and I want to capture comparator changes. The data sheet is a little vague on whether that should work ("If the CCPx pin is configured as an output, a write to the port can cause a capture condition"). But in practice it works just fine (on a PIC16F1847). However, in the simulator the comparator even stops functioning as soon as the CCP is configured. My code starts behaving like the real chip when I change the line mentioned above to: config_output(0, false, true); This change has no effect on the results of the test suite. If the change of the GUI name is considered important, then I think it should be accomplished differently than by making the output argument double as a way to achieve the name change. Or am I missing something? Schelte. |
From: <kus...@sp...> - 2022-12-26 12:37:53
|
> On 26. Dec 2022, at 12.32, Rob Pearce <lis...@fl...> wrote: > > On 26/12/2022 12:06, kus...@sp... wrote: >> Maybe improve the ".cod range error" with something like: >> >> "cod range error. Too many code sections?" >> >> or something, lest some lonely future user fails to find the >> answer from the lis archives? > > Yes, but if I'm clarifying error messages then I'd want to produce the correct reason, not a potentially misleading one. The current test traps several possible illegal entries as well as the valid-but-unsupported one. It will need more careful error checking (and consultation of the COD format definition) to do that. That is the prudent approach and if you are up to it, then that is great. My approach was just to add the '?' at the end to indicate that the error message might not be accurate and still hint a possible cause. cheers Kusti |
From: Rob P. <lis...@fl...> - 2022-12-26 12:32:39
|
On 26/12/2022 12:06, kus...@sp... wrote: > Maybe improve the ".cod range error" with something like: > > "cod range error. Too many code sections?" > > or something, lest some lonely future user fails to find the > answer from the lis archives? Yes, but if I'm clarifying error messages then I'd want to produce the correct reason, not a potentially misleading one. The current test traps several possible illegal entries as well as the valid-but-unsupported one. It will need more careful error checking (and consultation of the COD format definition) to do that. |
From: <kus...@sp...> - 2022-12-26 12:06:56
|
> On 26. Dec 2022, at 12.00, Rob Pearce <lis...@fl...> wrote: > > On 26/12/2022 07:04, kus...@sp... wrote: >> The error message in the title still seems buggy > > I've just committed a fix for that message bug > > Cheers, > > Rob > Brilliant, thanks! Maybe improve the ".cod range error" with something like: "cod range error. Too many code sections?" or something, lest some lonely future user fails to find the answer from the lis archives? cheers Kusti |
From: Rob P. <lis...@fl...> - 2022-12-26 12:00:32
|
On 26/12/2022 07:04, kus...@sp... wrote: > The error message in the title still seems buggy I've just committed a fix for that message bug Cheers, Rob |
From: <kus...@sp...> - 2022-12-26 09:04:01
|
> On 26. Dec 2022, at 8.21, Rob Pearce <lis...@fl...> wrote: > > On 26/12/2022 07:04, kus...@sp... wrote: >> the actual execution may work (and thus avoid the error message completely) >> once I get the code load properly to gpsim. > > Quite likely your code will work better if it's actually loaded... at all! The .cod error you're seeing at line 181 of cod.cc prevents any of the binary image being loaded, so your simulated flash is all blank. :) Hard for gpsim to work as if the code fails to load ;) should have paid more attention to that error message in the first place. Couple of hours of editing and some helpful macros cut down the +260 absolute sections to somewhere around 100 and now the code loads and runs, much as expected. > > I'm not sure whether the problem is an absolute limitation of the COD file format or a limit of GPSim's parser. It throws that error if two adjacent page references aren't the same, but I don't know the format well enough to say what that means. It's not inconceivable that the format actually defines those fields as a first-and-last pair for block allocations, and when you hit 128 separate blocks the linker needs to allocate more than one page to the alloc block. Yeah, COD is made of 512 byte blocks so yeah that would do it. > If that's the case, I think this is a bug in GPSim, just one that very few people ever trigger, and quite possibly one that was done deliberately because the author didn't expect anyone ever could trigger it. It would be pretty hard on a device with as little flash as the early PICs. Right. Call it not a bug but a limitation, and I've already worked around it. Took me three years ;) but no matter. This is a fun project anyway to keep me entertained on holidays. I originally used this computed GOTO approach and hit this speed bump (cod range error) three years ago, but back then I changed my approach to use an intermediary jump table which allowed me to get rid of all of those abs sections and replace them with 256 labels and GOTOs. Turns out I cannot afford those 2 clock cycles at that point in execution so I had to come back to this original approach. > > Cheers, > > Rob thanks and cheers Kusti |
From: Rob P. <lis...@fl...> - 2022-12-26 08:21:48
|
On 26/12/2022 07:04, kus...@sp... wrote: > the actual execution may work (and thus avoid the error message > completely) > once I get the code load properly to gpsim. Quite likely your code will work better if it's actually loaded... at all! The .cod error you're seeing at line 181 of cod.cc prevents any of the binary image being loaded, so your simulated flash is all blank. I'm not sure whether the problem is an absolute limitation of the COD file format or a limit of GPSim's parser. It throws that error if two adjacent page references aren't the same, but I don't know the format well enough to say what that means. It's not inconceivable that the format actually defines those fields as a first-and-last pair for block allocations, and when you hit 128 separate blocks the linker needs to allocate more than one page to the alloc block. If that's the case, I think this is a bug in GPSim, just one that very few people ever trigger, and quite possibly one that was done deliberately because the author didn't expect anyone ever could trigger it. It would be pretty hard on a device with as little flash as the early PICs. Cheers, Rob |
From: <kus...@sp...> - 2022-12-26 07:04:30
|
> On 25. Dec 2022, at 18.03, kus...@sp... wrote: > > A trivial self contained test case did not fail. > > So I started to think about what is unique in my project. > > The answer is 'a lot of ORG' statements. > > I started to bisect and strip down my code and after some elbow grease my guess is > that around 128 non discontinuous sections we get this error. > > I will try to create simple test case to prove this and also to find out if this is per file limitation > or per executable limitation. > > wbr Kusti I confirmed my suspicions. gpsim gives me .cod range error if there are a more than 128 discontinuous sections in a .cod file. Not sure I can all it a bug, maybe it s a limitation of the format . IDK. I tested this by programmatically generating a test file with various number of sections like this: LIST p=18f4550 RADIX DEC INCLUDE p18f4550.inc ORG 0x4000 NOP ORG 0x4020 NOP <SNIP> ORG 0x4FC0 NOP ORG 0x4FE0 NOP END and compiling, linking and loading with: gpasm -DSTACK_MODEL_SMALL -D__STACK_MODEL_SMALL -o test.o -c test.asm gplink -s 18f4550.lkr -m -o test.hex test.o gpsim test.cod and as soon as the number of sections hit 128 I get the error. Now this is a bit a bummer cause in my code I use a computed GOTO to N x 64 so I need to place my code sections with ORGs, This needs some thinking as the obvious solution of making those sections continuous by adding NOPs by hand is not appealing. Anyway, back where I started. I think that once I solve above issues the original issue I reported may disappear, The error message in the title still seems buggy but the actual execution may work (and thus avoid the error message completely) once I get the code load properly to gpsim. wbr Kusti |
From: Rob P. <lis...@fl...> - 2022-12-25 18:29:44
|
On 25/12/2022 14:48, kus...@sp... wrote: > > So my test hack was just wrong. > > But I'm now thinking if there is (also) a problem witht .cod file > generated by gpasm. > Reading through cod.cc <http://cod.cc> I I find: > > * Memory map table - describes the ranges of memory used in the > processor. > > If this refers to the actuall processor type and not just what is > compiled for that particular piece of code then if might be that the > processor spec for gpasm is faulty in someway. > > This rabbit hole gets deeper all the time. > I'm not really sure it does. The message you are seeing is generated at line 125 of pic-registers.cc and indicates only that the program execution has reached the top of memory and is wrapping round to the start. This is actually normal for some 12-bit CPUs where the reset address is the last word of flash and contains a calibration value for the internal oscillator. The only problem, and what is causing you to think it's all wrong, is that the code that produces the message was written for a 12-bit CPU and reports the values simply as internal indices. That matches proper addresses for 12-bit and 14-bit cores but needs to be doubled for the 16-bit. Oh, and the other problem is that your code under test is escaping out into empty memory... |
From: <kus...@sp...> - 2022-12-25 18:04:04
|
A trivial self contained test case did not fail. So I started to think about what is unique in my project. The answer is 'a lot of ORG' statements. I started to bisect and strip down my code and after some elbow grease my guess is that around 128 non discontinuous sections we get this error. I will try to create simple test case to prove this and also to find out if this is per file limitation or per executable limitation. wbr Kusti > On 25. Dec 2022, at 14.48, kus...@sp... wrote: > > > >> On 25. Dec 2022, at 14.28, Rob Pearce <lis...@fl... <mailto:lis...@fl...>> wrote: >> >> On 25/12/2022 13:00, kus...@sp... <mailto:kus...@sp...> wrote: >>> Hi Roy, >>> >>> thanks. Where did you get your source? I got mine like this: >>> >>> svn checkout svn://svn.code.sf.net/p/gpsim/code/trunk <svn://svn.code.sf.net/p/gpsim/code/trunk> >>> >>> >>> I just managed to compile it on macOS: >>> >>> gpsim-0.31.1 #2607 (Dec 25 2022) >>> >>> and I see the issue there. >>> >>> After hacking p18x.h:671 to >>> >>> unsigned int program_memory_size() const override { return 0x8000; } >>> >>> My error now is >>> >>> increment PC=0x8000 == memory size 0x8000 >>> >> Looking through the ChangeLog, I see this entry: >> >> 2008-08-26 Rob Pearce <ro...@bd...> <mailto:ro...@bd...> >> * src/processor.cc <http://processor.cc/> src/processor.h src/sim_context.cc <http://sim_context.cc/> src/cod.cc <http://cod.cc/> >> src/16bit-processors.h gui/gui_profile.cc <http://gui_profile.cc/> : >> Corrections to use of Processor::program_memory_size() so that all >> of them expect it to be instruction words, not byte addresses. >> That being the case, the correct return value should be 0x4000 (it's written as 16384 in the svn HEAD) but that should map to 0x8000 as a PC value. However, given that the interpretation had to be "corrected" back in 2008 it wouldn't surprise me if there are places where it's misinterpreted still (or again). >> >> Regards, >> >> Rob >> >> _______________________________________________ >> gpsim-devel mailing list >> gps...@li... <mailto:gps...@li...> >> https://lists.sourceforge.net/lists/listinfo/gpsim-devel > > Thank, I see. > > So my test hack was just wrong. > > But I'm now thinking if there is (also) a problem witht .cod file generated by gpasm. > Reading through cod.cc <http://cod.cc/> I I find: > > * Memory map table - describes the ranges of memory used in the processor. > > If this refers to the actuall processor type and not just what is compiled for that particular piece of code then if might be that the processor spec for gpasm is faulty in someway. > > This rabbit hole gets deeper all the time. > > wbr Kusti > > > > _______________________________________________ > gpsim-devel mailing list > gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsim-devel |
From: <kus...@sp...> - 2022-12-25 14:48:38
|
> On 25. Dec 2022, at 14.28, Rob Pearce <lis...@fl...> wrote: > > On 25/12/2022 13:00, kus...@sp... <mailto:kus...@sp...> wrote: >> Hi Roy, >> >> thanks. Where did you get your source? I got mine like this: >> >> svn checkout svn://svn.code.sf.net/p/gpsim/code/trunk <svn://svn.code.sf.net/p/gpsim/code/trunk> >> >> >> I just managed to compile it on macOS: >> >> gpsim-0.31.1 #2607 (Dec 25 2022) >> >> and I see the issue there. >> >> After hacking p18x.h:671 to >> >> unsigned int program_memory_size() const override { return 0x8000; } >> >> My error now is >> >> increment PC=0x8000 == memory size 0x8000 >> > Looking through the ChangeLog, I see this entry: > > 2008-08-26 Rob Pearce <ro...@bd...> <mailto:ro...@bd...> > * src/processor.cc src/processor.h src/sim_context.cc src/cod.cc > src/16bit-processors.h gui/gui_profile.cc : > Corrections to use of Processor::program_memory_size() so that all > of them expect it to be instruction words, not byte addresses. > That being the case, the correct return value should be 0x4000 (it's written as 16384 in the svn HEAD) but that should map to 0x8000 as a PC value. However, given that the interpretation had to be "corrected" back in 2008 it wouldn't surprise me if there are places where it's misinterpreted still (or again). > > Regards, > > Rob > > _______________________________________________ > gpsim-devel mailing list > gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsim-devel Thank, I see. So my test hack was just wrong. But I'm now thinking if there is (also) a problem witht .cod file generated by gpasm. Reading through cod.cc I I find: * Memory map table - describes the ranges of memory used in the processor. If this refers to the actuall processor type and not just what is compiled for that particular piece of code then if might be that the processor spec for gpasm is faulty in someway. This rabbit hole gets deeper all the time. wbr Kusti |
From: Rob P. <lis...@fl...> - 2022-12-25 14:27:51
|
On 25/12/2022 13:00, kus...@sp... wrote: > Hi Roy, > > thanks. Where did you get your source? I got mine like this: > > svn checkoutsvn://svn.code.sf.net/p/gpsim/code/trunk > > > I just managed to compile it on macOS: > > gpsim-0.31.1 #2607 (Dec 25 2022) > > and I see the issue there. > > After hacking p18x.h:671 to > > unsigned int program_memory_size() const override { return 0x8000; } > My error now is > > increment PC=0x8000 == memory size 0x8000 > Looking through the ChangeLog, I see this entry: 2008-08-26 Rob Pearce <ro...@bd...> * src/processor.cc src/processor.h src/sim_context.cc src/cod.cc src/16bit-processors.h gui/gui_profile.cc : Corrections to use of Processor::program_memory_size() so that all of them expect it to be instruction words, not byte addresses. That being the case, the correct return value should be 0x4000 (it's written as 16384 in the svn HEAD) but that should map to 0x8000 as a PC value. However, given that the interpretation had to be "corrected" back in 2008 it wouldn't surprise me if there are places where it's misinterpreted still (or again). Regards, Rob |