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
(2) |
Nov
|
Dec
|
From: <ea...@ea...> - 2022-01-27 09:55:44
|
> On 27. Jan 2022, at 10.33, Rob Pearce <lis...@fl...> wrote: > > Give me SF/SVN any day. Each to their own poison. ;) I have no stake in this and I have no desire to to try convince anyone otherwise so I won't promote the case for git even though I could say a thing a two re your points. cheers Kusti |
From: Rob P. <lis...@fl...> - 2022-01-27 08:33:52
|
On 27/01/2022 03:59, kus...@sp... wrote: >> On 27. Jan 2022, at 0.01, Rob Pearce <lis...@fl...> wrote: >> >> It's certainly very much the sort of scenario for which branches are >> used in all the SVN documentation ;) > It must be +20 years since I used SVN branches and the resulting > merges in anger but I remember that it was (for me) a painful experience. > > SInce then I've only participated in projects the are in github or > bitbucket which really support collaboration and are mostly pleasant > to use. > Well, not for the first time this week, I'm going to have to say "my experience differs from yours". I'll grant that SVN's branching syntax is rather obscure but I find that it just works, and generally very well. Git, on the other hand, seems determined to throw obstacles in my way at every opportunity. The github model works well for a project that genuinely has dozens of second-tier contributors who regularly submit patches (pull requests) to a single core developer who has always been and will always be the project's very keen and active maintainer. It falls over horribly when Scott gets too busy and wants to hand off to Roy, or when four of us are pretty much equally "the maintainer", and it gives no real benefit when we get two patches submitted per year. I'm currently trying to resurrect a dead project elsewhere. If it were a Sourceforge/SVN project like GPSim, the old maintainer could simply add me to the list then (if he wanted) remove himself. As it's on github, the master repository is in a personal account that cannot be shared or transferred, AFAICT. Give me SF/SVN any day. Cheers, Rob |
From: <kus...@sp...> - 2022-01-27 03:59:54
|
> On 27. Jan 2022, at 0.01, Rob Pearce <lis...@fl...> wrote: > > It's certainly very much the sort of scenario for which branches are used in all the SVN documentation ;) It must be +20 years since I used SVN branches and the resulting merges in anger but I remember that it was (for me) a painful experience. SInce then I've only participated in projects the are in github or bitbucket which really support collaboration and are mostly pleasant to use. wbr Kusti |
From: Rob P. <lis...@fl...> - 2022-01-26 22:02:01
|
On 26/01/2022 20:42, Schelte Bron wrote: > > Have you considered using an SVN branch for doing development on a new > PIC family? Although I don't have much experience with using branches > in SVN, it is my understanding that this kind of thing is exactly what > that feature is intended for. That should make it easier to > collaborate, while keeping the trunk clean. And you have an off-site > backup of your work. It's certainly very much the sort of scenario for which branches are used in all the SVN documentation ;) Yes, it would make sense to do, and maybe Roy and I should do so for our respective works in progress. It doesn't look like anybody's used a branch on GPSim since Scott's GUI experiments in the old CVS days some 18 years back! Cheers, Rob P.S. It looks like it wasn't only the "from" that Thunderbird slipped past me - I'd intended my earlier reply to go to the list. |
From: Schelte B. <pic...@ot...> - 2022-01-26 20:42:51
|
Rob, Roy, Thank you both for your very helpful insights. I'm glad work is already underway for the SMT peripheral. That seemed a bit daunting to me. I started with the WWDT, hoping it would be easier. But I have trouble matching the information in the data sheet with the behaviour I see on a real PIC. And unfortunately the watchdog timer is not something you can investigate with an in-circuit debugger. Have you considered using an SVN branch for doing development on a new PIC family? Although I don't have much experience with using branches in SVN, it is my understanding that this kind of thing is exactly what that feature is intended for. That should make it easier to collaborate, while keeping the trunk clean. And you have an off-site backup of your work. Thank you for the vote of confidence concerning my developer skills. I have to admit that for some of the bug reports I created, I had no clue of how to fix the issue. So I was very curious to see how it would be resolved. But I understand I can always ask here when necessary. So I see no harm in adding me as a developer to this project. As long as you don't mind that I will probably only work on the PICs I'm interested in for my own projects. By the way, Rob, I did get your earlier mail as well. Thanks, Schelte On 26/01/2022 19:14, Rob Pearce wrote: > I wrote my reply below some while back but got caught out by > Thunderbird's habit of using the wrong "From" address... and I see Roy > has also answered in the mean time. > > On 24/01/2022 15:08, Schelte Bron wrote: > >> So, are there any best practices or tools for starting a new family of >> PICs? Or is it just a matter of finding a vaguely similar device and >> copy/pasting the similar parts and adding new functionality? Any >> suggestions will be highly appreciated. > > It's mostly a case of find something similar and either copy or derive > from. > > As the one you're wanting to add is quite new and significantly > different, I'd suggest you should start a new file for it. > > Where a peripheral is not quite identical to an existing one, you need > to make a judgement as to whether the existing class can be tweaked or a > new (derived or with common base) class is better. And make sure you > check the differences carefully - I've just checked in some fixes for > bugs caused by not spotting a change between the existing device and the > new one. > > In all cases, when you add or fix something, we like to have a > regression test, too. For a new processor it should test a few basics, > but if there are new peripherals you should write regression tests that > thoroughly exercise them (again, it's easy to only test a limited case > and thus miss bugs in your implementation). > > Check everything you do against real hardware. I'm sure you don't need > to be told that! Most of the regression tests are not written this way, > but it would be good to be able to run it on the real chip and confirm a > full pass. Doing so won't ensure it's a good test - it won't check > whether it misses any bugs! - but it will confirm it's not a Very Bad > Test that expects something wrong. > > Doing it right is not trivial and it's probably going to feel like a lot > of work. That's why I've STILL not committed my 12F1572 implementation > (it's missing the PWM16 module, which is quite complex). Sometimes, if > you get stuck like that, it's better to offer up a partial version - > there's at least one device in the current release that gives a "this > peripheral is not implemented yet" warning. > > HTH > > Rob > > |
From: <rr...@ih...> - 2022-01-26 07:44:52
|
Schelte, Of coarse the first thing is to ask questions on this list. But I find an existing processor which is as similar as possible and work from there. I am currently working on the p16f1614 family, and have been working on it for some time. This family has some of the features it looks like your processor family uses including a new T2 module and the (SMT) Signal measurement timer which I have just started and am currently working on. I have not committed most of these as it is a work in progress and we strive to always have the SVN in a useable state. However, what I have does work but is missing some functionality and registers. I thus may clean up the debugging (which may take a day or two) and commit it to the SVN. There are two areas, that come to mine where things are done the old way and the new way. The first involves the PIRx register. In the old way, new PIRx registers were create with associated bit set functions. As more and more processors were added, this was becoming a mess. The new way uses the InterruptSource class which is created in the module setting the interrupt flag, and possible causes an interrupt if the appropriate bits are set in PIEx and the generic interrupt flags. When the class is invoked, the PIR register and IF bit are defined. The IF flag is set by calling the Trigger() function. The second involves inter module communication. Older PICs had very limited communication between modules, but the modules on newer PICs may talk to a number of other modules. In the old way a receiving module would send it's address to the sending module which could then send the state to a prearranged function. If a new module wanted to communicate both modules had to be modify. In the new way, the sending module invokes a class DATA_SERVER. The receiving module, knowing the sending modules address, can attach a DATA_RECEIVER class to the DATA_SERVER class.This scheme allows the sending module to easily send data to multiple receivers and the receivers to get data from multiple sending modules. Do you want to become a developer with SVN write permission. Through your patches and bug reports you have shown you have the skills to be a developer. Regards,Roy Rankin ----- Original Message ----- From: "Schelte Bron" To:"gpsim devel" Cc: Sent:Mon, 24 Jan 2022 16:08:03 +0100 Subject:[gpsim-devel] Guidance on adding a new PIC family to gpsim Hi all, I have moved a project (http://otgw.tclcode.com/ in case anyone is curious) from mplab x to gputils/gpsim. You may have seen some patches and bug reports related to that from me lately. Thanks to Roy's excellent responsiveness that project is now fully converted, including the test suite. What is very impressive is how much faster the test suite runs. Using mplab's mdb, it used to take over 7 minutes to run completely. Now that I have reimplemented the same tests using gpsim, a full run finishes in 15 seconds! Clearly you guys have done an excellent job with gpsim. I want to express my gratitude for that. Now I am about to start a new project, based on a PIC16F18426. This chip isn't even supported in the latest gputils release, but I have provided a patch for that (https://sourceforge.net/p/gputils/patches/77/). With that taken care of, I also want to add the device (and other similar devices) to gpsim. So I am looking for guidance on how to go about doing that. I already had a look around and noticed that these devices are quite different from the 14-bit PICs that are currently supported. Even basic things like write protection and the watchdog timer would need modifications. The devices contain new peripherals, like the reference clock output module and the signal measurement timer. And finally there are differences with existing peripherals, such as doze mode, an ADC computation module and capacitive voltage divider and timer 0 16-bit mode and operation during sleep. So, are there any best practices or tools for starting a new family of PICs? Or is it just a matter of finding a vaguely similar device and copy/pasting the similar parts and adding new functionality? Any suggestions will be highly appreciated. Thanks, Schelte Bron. _______________________________________________ gpsim-devel mailing list gps...@li... https://lists.sourceforge.net/lists/listinfo/gpsim-devel |
From: Schelte B. <pic...@ot...> - 2022-01-24 15:08:16
|
Hi all, I have moved a project (http://otgw.tclcode.com/ in case anyone is curious) from mplab x to gputils/gpsim. You may have seen some patches and bug reports related to that from me lately. Thanks to Roy's excellent responsiveness that project is now fully converted, including the test suite. What is very impressive is how much faster the test suite runs. Using mplab's mdb, it used to take over 7 minutes to run completely. Now that I have reimplemented the same tests using gpsim, a full run finishes in 15 seconds! Clearly you guys have done an excellent job with gpsim. I want to express my gratitude for that. Now I am about to start a new project, based on a PIC16F18426. This chip isn't even supported in the latest gputils release, but I have provided a patch for that (https://sourceforge.net/p/gputils/patches/77/). With that taken care of, I also want to add the device (and other similar devices) to gpsim. So I am looking for guidance on how to go about doing that. I already had a look around and noticed that these devices are quite different from the 14-bit PICs that are currently supported. Even basic things like write protection and the watchdog timer would need modifications. The devices contain new peripherals, like the reference clock output module and the signal measurement timer. And finally there are differences with existing peripherals, such as doze mode, an ADC computation module and capacitive voltage divider and timer 0 16-bit mode and operation during sleep. So, are there any best practices or tools for starting a new family of PICs? Or is it just a matter of finding a vaguely similar device and copy/pasting the similar parts and adding new functionality? Any suggestions will be highly appreciated. Thanks, Schelte Bron. |
From: Rob P. <lis...@fl...> - 2022-01-14 22:31:26
|
Hi guys, Spurred on by recent discussions, and some trouble with simulating a project, and getting distracted in my code digging... I've returned to finishing my 12F1571 implementation. The bits that are missing at the moment are the PWM and CWG blocks. I noticed that the 16F1503 has a very similar CWG to the 12F1571 so that looked a good place to start. Anyway, on looking into this, and checking for differences, I came across the definitions at line 152 of src/cwg.h: //CWG1CON2 GxASDFLT = 1 << 0, GxASDCLC1 = 1 << 1, GxARSEN = 1 << 6, GxASE = 1 << 7 Those first two bit allocations don't match the datasheet for either processor. I think it matches the 10F320 but needs correcting for other devices. Any comments? Cheers, Rob |
From: Rob P. <lis...@fl...> - 2022-01-14 11:06:12
|
On 14/01/2022 10:11, Santiago González wrote: > Another clue is in block diagrams in I/O Port sections: A clue, yes, but, as has been discussed several times previously, the Microchip data sheets are not always accurate and those diagrams are "simplified" at best. > It shows that perifericals force the pin as output regardless of TRIS state. No, not quite. It shows that the peripheral *is capable* of forcing the pin to be an output. It gives no clue as to whether or when it does. > But... I'm watching 16F627/628/648 right now and it's showing the same > thing for RX and TX pins, so forcing the RX pin to be an output????. Yes, that's correct. The USART can be configured in "synchronous" mode, where it behaves more like an I2C device, and the pins are CK and DT, both of which are bidirectional. The USART will switch their direction on the fly. The block diagrams in the data sheet show an AND gate, which means the USART can only force the pin to be an output. For it to work in synchronous mode, then, it is necessary for both TRIS bits to be set to "input" (1). For UART mode, though, the TRIS bits can (and probably should) be set RX-in, TX-out, although it's probably only the RX that matters. Regards, Rob |
From: Santiago G. <san...@gm...> - 2022-01-14 10:36:54
|
Another clue about why setting TRIS bits matters, but not because it will make perifericals work/not work: PIC16F87x datasheet, page 33, 3.3 PORTC and the TRISC Register: "When enabling peripheral functions, care should be taken in defining TRIS bits for each PORTC pin. Some peripherals override the TRIS bit to make a pin an out- put, while other peripherals override the TRIS bit to make a pin an input. Since the TRIS bit override is in effect while the peripheral is enabled, read-modify- write instructions (BSF, BCF, XORWF) with TRISC as destination, should be avoided. The user should refer to the corresponding peripheral section for the correct TRIS bit settings." El vie, 14 ene 2022 a las 10:11, Santiago González (<san...@gm...>) escribió: > Just my 2 cents... > Another clue is in block diagrams in I/O Port sections: > It shows that perifericals force the pin as output regardless of TRIS > state. > But... I'm watching 16F627/628/648 right now and it's showing the same > thing for RX and TX pins, so forcing the RX pin to be an output????. > > > El jue, 13 ene 2022 a las 18:14, Rob Pearce (<lis...@fl...>) > escribió: > >> On 13/01/2022 11:07, Schelte Bron wrote: >> > Unfortunately the above story doesn't seem to hold true for all >> > devices. There appear to be some exceptions. For example the >> > PIC18F2220/2320/4220/4320 data sheet says the TRISC<6> bit must be >> > cleared (= 0) when using the USART. I don't have one of those devices >> > to be able to check if it will also work when the TRIS bit for the TX >> > pin is configured as an input. >> >> I have a couple of old boards using the 18F2321 and the 18F1220 but not >> those exact devices, unfortunately. I've always set the TX pin TRIS bit >> to 0, although the note on the 2321 code attributes that to GPSim rather >> than the actual device. >> >> Regards, >> >> Rob >> >> >> >> _______________________________________________ >> gpsim-devel mailing list >> gps...@li... >> https://lists.sourceforge.net/lists/listinfo/gpsim-devel >> > |
From: Santiago G. <san...@gm...> - 2022-01-14 10:11:20
|
Just my 2 cents... Another clue is in block diagrams in I/O Port sections: It shows that perifericals force the pin as output regardless of TRIS state. But... I'm watching 16F627/628/648 right now and it's showing the same thing for RX and TX pins, so forcing the RX pin to be an output????. El jue, 13 ene 2022 a las 18:14, Rob Pearce (<lis...@fl...>) escribió: > On 13/01/2022 11:07, Schelte Bron wrote: > > Unfortunately the above story doesn't seem to hold true for all > > devices. There appear to be some exceptions. For example the > > PIC18F2220/2320/4220/4320 data sheet says the TRISC<6> bit must be > > cleared (= 0) when using the USART. I don't have one of those devices > > to be able to check if it will also work when the TRIS bit for the TX > > pin is configured as an input. > > I have a couple of old boards using the 18F2321 and the 18F1220 but not > those exact devices, unfortunately. I've always set the TX pin TRIS bit > to 0, although the note on the 2321 code attributes that to GPSim rather > than the actual device. > > Regards, > > Rob > > > > _______________________________________________ > gpsim-devel mailing list > gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsim-devel > |
From: Rob P. <lis...@fl...> - 2022-01-13 18:13:55
|
On 13/01/2022 11:07, Schelte Bron wrote: > Unfortunately the above story doesn't seem to hold true for all > devices. There appear to be some exceptions. For example the > PIC18F2220/2320/4220/4320 data sheet says the TRISC<6> bit must be > cleared (= 0) when using the USART. I don't have one of those devices > to be able to check if it will also work when the TRIS bit for the TX > pin is configured as an input. I have a couple of old boards using the 18F2321 and the 18F1220 but not those exact devices, unfortunately. I've always set the TX pin TRIS bit to 0, although the note on the 2321 code attributes that to GPSim rather than the actual device. Regards, Rob |
From: Rob P. <lis...@fl...> - 2022-01-13 18:07:30
|
On 13/01/2022 01:42, rr...@ih... wrote: > Hi all, > > All the data sheets I have looked at which uses the USART (not EUSART) > says the TRIS bits for TX and RX should be set. This is ambiguous as > to whether the bits should be set to 1 or direction dependent. > However, I have bug reports that the on the 16f628 silicon TRIS for TX > must be set to 1. Also 16f874a silicon can work regardless to the TRIS > bit for the TX pin. > > I have a patch ready which allows the USART TX to only work if it's > TRIS bit is set to 1. > > Is there any reason to not submit this change. Particularly experience > on the actual chips. It needs checking against some real hardware. I've dug out an old project using a 16F628 and in that I had the TX TRIS bit set to 0, which was a working configuration. I did the same on a 16F871 project, which also worked. Regards, Rob |
From: Schelte B. <pic...@ot...> - 2022-01-13 11:29:23
|
The data sheets could indeed be clearer in this respect. One additional clue it provides to what "the TRIS bits have to be set" actually means comes from the description of the TXEN bit: "Clearing the TXEN enable bit during a transmission will cause the transmission to be aborted and will reset the transmitter. As a result the TX/CK pin will revert to hi-impedance." That last part can only happen when the TX pin has been configured as an input. The idea behind setting the TX pin as input seems to be that it easily facilitates half-duplex operation. If the TX and RX pins are tied together, the TXEN bit is the single place that would control whether the device is receiving or transmitting. I can confirm that configuring both pins as inputs works on a PIC16F628 (USART), PIC16F88 (AUSART), and PIC16F18426 (EUSART). However, I have also verified on the PIC16F88 that configuring the TX pin as an output works as well. So it seems that the TRIS bit is completely irrelevant on the actual hardware. I would therefor prefer that gpsim replicates that. That would also not suddenly make code with TX configured as an output (which was necessary before) stop working in gpsim. Unfortunately the above story doesn't seem to hold true for all devices. There appear to be some exceptions. For example the PIC18F2220/2320/4220/4320 data sheet says the TRISC<6> bit must be cleared (= 0) when using the USART. I don't have one of those devices to be able to check if it will also work when the TRIS bit for the TX pin is configured as an input. Regards, Schelte Bron On 13/01/2022 02:42, rr...@ih... wrote: > Hi all, > > All the data sheets I have looked at which uses the USART (not EUSART) > says the TRIS bits for TX and RX should be set. This is ambiguous as to > whether the bits should be set to 1 or direction dependent. However, I > have bug reports that the on the 16f628 silicon TRIS for TX must be set > to 1. Also 16f874a silicon can work regardless to the TRIS bit for the > TX pin. > > I have a patch ready which allows the USART TX to only work if it's > TRIS bit is set to 1. > > Is there any reason to not submit this change. Particularly experience > on the actual chips. > > Regards, > Roy Rankin |
From: <rr...@ih...> - 2022-01-13 02:04:50
|
Hi all, All the data sheets I have looked at which uses the USART (not EUSART) says the TRIS bits for TX and RX should be set. This is ambiguous as to whether the bits should be set to 1 or direction dependent. However, I have bug reports that the on the 16f628 silicon TRIS for TX must be set to 1. Also 16f874a silicon can work regardless to the TRIS bit for the TX pin. I have a patch ready which allows the USART TX to only work if it's TRIS bit is set to 1. Is there any reason to not submit this change. Particularly experience on the actual chips. Regards,Roy Rankin |
From: Franc G. <tis...@gm...> - 2021-12-01 23:52:37
|
Ah, already found it out myself: apparently the relevant i2c slave code is in i2c-ee.cc <http://i2c-ee.cc/> and setting verbose helped a lot. Sorry for bothering! Franc > On 1 Dec 2021, at 23:54, Franc Grootjen <tis...@gm...> wrote: > > Hi > To find out why my pic i2c code is not working I downloaded the latest version of gpsim and adapted i2c.cc and i2c2par.cc (uncommented the #define DEBUG lines). > Unfortunately after recompiling/installing I do not receive any debugging messages. > Did I made a mistake or overlooked something? > > Franc > > PS: Running on Ubuntu 20 |
From: Franc G. <tis...@gm...> - 2021-12-01 22:54:13
|
Hi To find out why my pic i2c code is not working I downloaded the latest version of gpsim and adapted i2c.cc <http://i2c.cc/> and i2c2par.cc <http://i2c2par.cc/> (uncommented the #define DEBUG lines). Unfortunately after recompiling/installing I do not receive any debugging messages. Did I made a mistake or overlooked something? Franc PS: Running on Ubuntu 20 |
From: Kustaa N. <kus...@sp...> - 2021-06-29 05:47:52
|
Sorry, mac mail seems to defeat my attempts to post to the correct list! Argh. > On 29. Jun 2021, at 8.44, Kustaa Nyholm <kus...@sp...> wrote: > > Sorry for "cross posting" I posted this to wrong list yesterday > > 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 |
From: Kustaa N. <kus...@sp...> - 2021-06-29 05:45:16
|
Sorry for "cross posting" I posted this to wrong list yesterday 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 |
From: Kustaa N. <kus...@sp...> - 2021-06-29 05:40:15
|
Apologies, wrong list. |
From: Kustaa N. <kus...@sp...> - 2021-06-29 05:38:57
|
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 |
From: Kustaa N. <kus...@sp...> - 2021-06-28 05:27:43
|
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/ /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 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/ /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 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) Here is the actual error message: 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 |
From: Kustaa N. <ea...@ea...> - 2021-06-12 04:16:38
|
> On 12. Jun 2021, at 1.13, Rob Pearce <lis...@fl...> wrote: > > > Pretty much. There is a quirk of the step trace that it happens after doing the step and attempts to show the thing that's just happened, which means it needs to back-track from where it is. If the instruction just stepped was a branch, goto or call, then it needs to take special action to account for that. It appears that, in the case of a movwf PCL, it doesn't take the necessary special action. > > If you have the GUI available, the source browser should display the PC pointer correctly. > > Cheers, > Rob > Ok, so all is good. I actually do not use the stepping (or GUI) for anythings, I call gpsim from an other program and just check the results. I only step if I need to debug something. Now that I know this issue it is no problem. cheers Kusti |
From: Rob P. <lis...@fl...> - 2021-06-11 21:14:15
|
On 11/06/2021 20:12, Kustaa Nyholm wrote: > so if I interpret this correctly, the simulator appears to work > correctly but the step trace is wrong ? > > it shows > > 0x000000000000002C p18f4550 0x017E 0x3FFF INVALID > > instead of whatever it should show when it executes this: > > MOVWF PCL, a > > but the next instruction after that is correctly executed at 0x180. > > Is this interpretation correct? > Pretty much. There is a quirk of the step trace that it happens after doing the step and attempts to show the thing that's just happened, which means it needs to back-track from where it is. If the instruction just stepped was a branch, goto or call, then it needs to take special action to account for that. It appears that, in the case of a movwf PCL, it doesn't take the necessary special action. If you have the GUI available, the source browser should display the PC pointer correctly. Cheers, Rob |
From: Kustaa N. <kus...@sp...> - 2021-06-11 19:13:07
|
> On 11. Jun 2021, at 21.55, Rob Pearce <lis...@fl...> wrote: > > On 11/06/2021 17:18, Kustaa Nyholm wrote: >> Hi, >> >> I changed my computed goto code a little and came across this: >> >> MOVLW 0x80 >> MOVWF PCL, a >> >> This seems to jump to 0xnn7E and not 0xnn80, >> is this how the PIC works or is this gpsim bug? >> > What instruction do you have at 0x7E? Actually nothing at that address. This is what I see: **gpsim> s 0x000000000000002A p18f4550 0x00E2 0x0E80 movlw 0x80 167: Wrote: 0x0080 to W(0x0FE8) was 0x00F0 **gpsim> s 0x000000000000002C p18f4550 0x017E 0x3FFF INVALID (BTW PCLATH= 0x01) I ORG code at 16 bytes intervals to which this computed goto is supposed to land. So there is always a word or more before the address to which I try to jump. The actual code is as follows (what I showed was a simple test snippet I did when I stumbled on the problem): MOVLW HIGH(decode) MOVWF PCLATH, a ; MOVF OPCODE, w, a ; high nibble defines where to jump ANDLW 0xF0 ; ; MOVLW 0x80 ; this is was for the test I made MOVWF PCL, a and then org 0x100 decode: some code org 0x110 some code org 0x120 some code ... org 0x01F0 some code Hope this clarifies what I mean. wbr Kusti > > I initially started to say I'd confirmed this behaviour and found some other weirdness but then realised my test code had: > > org 0x7E > > goto bad > > > This is a problem, because "goto" is a two-word instruction, so the next instruction is not at 0x80. In my case, GPSim was, actually, behaving exactly right and jumping to 0x80... but that was the middle of the "goto bad" instruction at 0x7E, so it (correctly) showed the PC pointer on that line, but executed it as a NOP. The transcript on the console looks wrong in that it shows the whole goto before the nop and doesn't show the movwf PCL - but that's a weirdness of the reporting of the step operation. > > Cheers, > > Rob > > > > > _______________________________________________ > gpsim-devel mailing list > gps...@li... > https://lists.sourceforge.net/lists/listinfo/gpsim-devel |