This project looks really great - I especially like the use of HID to avoid nasty driver problems. The one big thing which would be awesome, is to be able to program the chip using MPLAB Snap instead of the PICKit. MPLAB Snap is much cheaper (especially compared to PICKit 4) but only supports low-voltage programming, so it cannot program the PIC18F2550. The PIC18F25K50 looks very similar, but quite a bit cheaper and can be programmed by the MPLAB Snap.
Once I downloaded the code, I realised that it would also be a very good idea to move to a supported toolset (C18 -> XC8, MPASM -> pic-as), to make sure it keeps working in future IDE versions.
So, after a LOT of changes to move to the new toolchain, I have successfully built the code in MPLAB X and uploaded it to my PIC18F25K50 using my MPLAB Snap. Of course, I have no idea if it works yet - I am waiting for my batch of PCBs to arrive.
What I'm wondering, is whether the openprog developer would be happy to answer questions, give advice on how to get this working, and review my code changes. It may take quite a bit of effort, but I think it will be worth it in the long run.
Regards
Stephen
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sure I can answer; what I may be unable to do is dedicating a lot of time to changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-03-13
Of course! Thanks in advance for your help. I just received my boards so I am going to build one and do some testing to see how much is working in my initial build.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, well I can successfully program my 18F25K50 in-circuit with my MPLAB Snap. I found that the oscillator config will need to change... FOSC setting for 12MHz crystal is 0011 but table 3-1 shows that this disables the PLL. Luckily we can just use 16MHz internal oscillator and 3x PLL instead to get the same clock speed. So the xtal & caps can just be left off when building the circuit for 18F25K50.
After uploading my updated firmware and applying power via the extension board port, the LED started flashing at 4Hz as expected (good), and I did some basic voltage & continuity checks on the USB port (don't want to fry my laptop). It looked OK so I went ahead and plugged it in, however the device enumeration failed. So I started looking for Microchip official USB sample code. I successfully made a separate project where I took the "custom HID" example from MLA (Microchip Libraries for Applications), adjusted the OSC config. After compiling and uploading, it shows up as a valid USB device when attached to my PC. (Hooray!) I will need to compare the descriptors to figure out why the enumeration is failing.
Unfortunately the MLA sample Windows app that talks to the device hangs when I try to use it :( It could be just talking to the wrong USB device, I didn't look at all yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Compiled op & opgui. printf() working to send debug statements over UART. Can receive data from PC over USB using MLA driver, but TX not working yet. Once that is fixed, will try to get openprog firmware working.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, can successfully communicate both ways using Microchip drivers. Time to see if I can figure out why the driver used by your project isn't working.
BTW the Microchip driver is using the Apache 2.0 license, which seems to be open-source compatible, so it might be an option to use their USB driver which supports a wide variety of USB-capable PICs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I enabled the debug statements and I can see that the device gets to POWERED state, but then receives a series of Bus Reset events. So I suspect that Windows fails to process the device information and refuses to talk to it.
There are certainly some differences between the working descriptor that I have, and the one used in your project, but it's not obvious what is going wrong.
I propose to utilise the Microchip USB driver in PIC18F25K50 firmware. It appears to me to be compatible with open-source principles, and additionally it fully supports XC8 compiler (the problems I'm having could have been introduced by some difference in compiler behaviour).
If you are happy that using this library does not violate the open-source principles of the project, then I will start working on replacing the USB code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have the impression that you are not implementin an HID class device.
If you do so there is no need for drivers, it is a peripheral like a mouse, joystick etc.
The Microchip USF firmware is not open source, that's why I changed long ago for an open alternative.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for confusion, by "USB driver" I am referring to the part of the firmware on the PIC that manages the USB peripheral (usb.c and usb.h in your project). I am certainly implementing a HID class device, since it requires no Windows driver installation, which is one of the great features of this project.
Regarding the concern about the Microchip USB firmware - the short version is that the GPL was invented to encourage free software, and the Microchip USB firmware is definitely free software now (although perhaps it wasn't in the past). The rest of this post is the justification for that statement. But if you mean something else by "not open source" then you will need to explain.
"Free software" is defined by the FSF (https://www.gnu.org/philosophy/free-sw.html).
MLA used to be licensed under Microchip's Licensing Agreement (I checked the 2012 version, and it was still under this one), which probably means it was not free software back then - although, the license does allow you to modify the code, so I'm not 100% sure. Anyway, at some point, they decided to release it under Apache 2.0 license instead.
FSF has a list of licenses here: https://www.gnu.org/licenses/license-list.html. According to their view, software released under Apache 2.0 license qualifies as free. The Apache 2.0 license is not compatible with the GPLv2 license, however it is compatible with the GPLv3 license. In fact, one key goal for FSF in creating GPLv3 was to enable inclusion of Apache 2.0-licensed code in GPL-licensed software (see "New Compatible Licenses" under https://www.gnu.org/licenses/quick-guide-gplv3.html - the diagram here is very good).
Now, looking back at openprog - the openprog webpage says the code is released under GPLv2, however all of the headers in your source code say "either version 2 of the License, or (at your option) any later version.". I'm assuming you just took the standard GPLv2 wording.
My point is that FSF, who created the GPL, are very happy for GPL-licensed projects to make use of Apache 2.0-licensed code - they actively removed the barrier preventing inclusion of Apache 2.0-licensed code in GPL-licensed projects. We would just need to be careful to keep Microchip source files unmodified (which is not difficult).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, if it is an HID device with the right descriptor it has to work with the same exact software (on PC side). In fact the first firmware versions did use that framework.
MLA is definitely not free software in the classical sense, and not compatible with any GPL.
In the end, changing USB framework and C compiler is a lot of work, some in the coding itself but much more in verification: keep in mind that there are also assembly sections that are strongly timing critical.
So a first question is: what exactly is the advantage in making any change?
Is there an alternative path to obtain the same objectives?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The biggest motivation for me, is to provide an open-source programmer that is capable of high-voltage programming, and does not require a high-voltage programmer to construct! If you have any suggestion about an easier way to do that, then I am open to it, but my idea was to utilise a similar PIC that supports low-voltage programming, as that (hopefully) allows re-use of all of the code you worked so hard on.
Additionally, a long-term issue for this project that one day it will be impossible to build. The C18 and MPASM environment is going to break one day, and we will lose the best open-source programmer unless somebody converts it.
Since converting to a different PIC requires all the verification work anyway, if we upgrade the compiler at the same time we kill two birds with one stone. I would like to learn the techniques used to verify that timing requirements are still met, so if you can teach me how (or point me to some learning resources), I am happy to do the bulk of the work.
The reason I want to use MLA code is simply because it appears to be easier than making the existing USB code work on a different PIC (in fact I've already finished the conversion). Obviously, if MLA is incompatible with GPLv3, then it's not feasible to use this, so we need to clarify that point.
On that topic, I need to disagree with your statement that MLA is not compatible with any GPL. The code is released under Apache 2.0 license which everybody agrees is free and open source, and FSF themselves say is compatible with GPLv3. What makes you think MLA isn't compatible with GPLv3? As I mentioned before, the MLA licensing has changed since you initially developed this project.
If you are still not comfortable that the licensing is OK, would it help if we ask FSF for verification? They have an email address for these kind of licensing questions. If you like, I can draft an email for your review, and once you're happy with it, I can send it.
Last edit: Stephen Gordon 2022-03-21
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All PIC18 devices support low voltage programming.
The current firmware, however, is not compatible with LVP because RB5 would be reserved for program mode entry (as PGM), while it works as Data IO in normal operation.
This "feature" is present in the 18F2550 while I don't see the limitation in the 18F25K50; so that would be an advantage.
I was thinking about a workaround through the use of self-programming, so after a first low voltage write the device would self-disable LVP; I would need to try to confirm it can work.
Sure you can ask about license compatibility, maybe it used to be different 10 years ago.
Still, I am reluctant to invest so much time in a firmware that is compiled every 3 years on average; it would be easier to recompile using the same tool chain.
Regarding verification of changes, no problem in sharing the procedure, but notice how many different devices have been verified: do you have access to all of them? Or how many?
Because if most of the activity lands on me I need a very compelling reason, not simply a change of compiler or USB framework...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the licensing query - I will send you a message sharing my personal email address. We can then work via email to draft an email asking about the licensing question.
I believe you have to use high-voltage programming to disable LVP (a good feature!).
I would definitely verify all devices in my possession. Let me see what additional devices I could purchase for a reasonable cost.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just in case anyone reads this thread - Alberto and I have been collaborating and have made a lot of progress. A new firmware already exists supporting PIC18F25K50, but it has not been fully tested. Alberto is still working on a couple of other features for the next version.
I have also successfully compiled the existing firmware in MPLAB X/XC8 - without using the Microchip USB framework (avoiding all the licensing questions). This also needs more testing. I will certainly post a link here once it works, and I'm hoping Alberto will add it to the main webpage. I plan to run this as a downstream project and adopt all changes that Alberto makes into this version.
opgui has been ported to GTK3 which has much better Windows runtime availability, and I am also developing an SMD PCB as an alternative construction option (with 1206-size components and 1.27mm IC pin pitch so it's nice and easy to solder).
So, plenty of exciting developments.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2022-05-25
If it's any help we already did an SMD version, Alberto has one.
Just in case anyone reads this thread - Alberto and I have been collaborating and have made a lot of progress. A new firmware already exists supporting PIC18F25K50, but it has not been fully tested. Alberto is still working on a couple of other features for the next version.
I have also successfully compiled the existing firmware in MPLAB X/XC8 - without using the Microchip USB framework (avoiding all the licensing questions). This also needs more testing. I will certainly post a link here once it works, and I'm hoping Alberto will add it to the main webpage. I plan to run this as a downstream project and adopt all changes that Alberto makes into this version.
opgui has been ported to GTK3 which has much better Windows runtime availability, and I am also developing an SMD PCB as an alternative construction option (with 1206-size components and 1.27mm IC pin pitch so it's nice and easy to solder).
So, plenty of exciting developments.
Cool! I will release the designs for mine once I get around to ordering and testing it. It is 55x52.5mm, as I totally removed the device sockets. It is fully compatible with the existing daughter boards, but I also designed a new "all-in-one" daughter board (200x120mm) with a 10F20x socket.
I am targeting two types of people... firstly thoes who (like me) have an MPLAB Snap but need to program a chip that doesn't support low-voltage programming and don't want to buy a PICkit just for that. Secondly, those who can't/won't manufacture their own PCBs (again, like me - I have small children and don't want to store the chemicals around home). If you are paying shipping for the programmer board, the low additional manufacturing cost of the daughter boards means it is sensible to just get all of them in case you need them one day. But getting 6 small boards is a lot more expensive than 1 big one.
Hopefully someone else will also find it useful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Any news on an SMT version of the programming board? Do you have any Kicad files for this version of the board? I'd like to build a smaller footprint version for use in our embedded system lab at the UK university where I work. Thanks.
Last edit: David Briscoe 2023-02-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please provide an email address and I will send you my version. It consists of a small programmer board and a large board for plugging in devices to be programmed. This large board replaces all of the various openprog add-on boards, as it's much cheaper to fabricate two boards than 6. I have done some testing with common devices and it works fine so far.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is a picture. The programmer board is 57mm x 52.5mm. Target board is 200mm x 120mm.
I added a pad for the SOT-23 version of 10F20x, which were very difficult to program before. I allowed space and made bigger holes so that ZIF sockets can be used if desired for most devices.
The programmer board's ICSP also matches the SNAP programmer pinout, making it easier to program openprog firmware.
I also added a switch on RA7 pin which is free because there is no oscillator any more. This could be used to do batch programming (e.g. press the button when you are ready to program the next chip). Alberto already added some code in opgui for this but he didn't have any spare pins on the 18F2550 so I don't think there is any firmware support - but it wouldn't be hard to add.
Hi there,
This project looks really great - I especially like the use of HID to avoid nasty driver problems. The one big thing which would be awesome, is to be able to program the chip using MPLAB Snap instead of the PICKit. MPLAB Snap is much cheaper (especially compared to PICKit 4) but only supports low-voltage programming, so it cannot program the PIC18F2550. The PIC18F25K50 looks very similar, but quite a bit cheaper and can be programmed by the MPLAB Snap.
Once I downloaded the code, I realised that it would also be a very good idea to move to a supported toolset (C18 -> XC8, MPASM -> pic-as), to make sure it keeps working in future IDE versions.
So, after a LOT of changes to move to the new toolchain, I have successfully built the code in MPLAB X and uploaded it to my PIC18F25K50 using my MPLAB Snap. Of course, I have no idea if it works yet - I am waiting for my batch of PCBs to arrive.
What I'm wondering, is whether the openprog developer would be happy to answer questions, give advice on how to get this working, and review my code changes. It may take quite a bit of effort, but I think it will be worth it in the long run.
Regards
Stephen
Sure I can answer; what I may be unable to do is dedicating a lot of time to changes.
Of course! Thanks in advance for your help. I just received my boards so I am going to build one and do some testing to see how much is working in my initial build.
BTW I just realised I am not logged in! I am the anonymous poster.
OK, well I can successfully program my 18F25K50 in-circuit with my MPLAB Snap. I found that the oscillator config will need to change... FOSC setting for 12MHz crystal is 0011 but table 3-1 shows that this disables the PLL. Luckily we can just use 16MHz internal oscillator and 3x PLL instead to get the same clock speed. So the xtal & caps can just be left off when building the circuit for 18F25K50.
After uploading my updated firmware and applying power via the extension board port, the LED started flashing at 4Hz as expected (good), and I did some basic voltage & continuity checks on the USB port (don't want to fry my laptop). It looked OK so I went ahead and plugged it in, however the device enumeration failed. So I started looking for Microchip official USB sample code. I successfully made a separate project where I took the "custom HID" example from MLA (Microchip Libraries for Applications), adjusted the OSC config. After compiling and uploading, it shows up as a valid USB device when attached to my PC. (Hooray!) I will need to compare the descriptors to figure out why the enumeration is failing.
Unfortunately the MLA sample Windows app that talks to the device hangs when I try to use it :( It could be just talking to the wrong USB device, I didn't look at all yet.
Compiled op & opgui. printf() working to send debug statements over UART. Can receive data from PC over USB using MLA driver, but TX not working yet. Once that is fixed, will try to get openprog firmware working.
OK, can successfully communicate both ways using Microchip drivers. Time to see if I can figure out why the driver used by your project isn't working.
BTW the Microchip driver is using the Apache 2.0 license, which seems to be open-source compatible, so it might be an option to use their USB driver which supports a wide variety of USB-capable PICs.
I enabled the debug statements and I can see that the device gets to POWERED state, but then receives a series of Bus Reset events. So I suspect that Windows fails to process the device information and refuses to talk to it.
There are certainly some differences between the working descriptor that I have, and the one used in your project, but it's not obvious what is going wrong.
I propose to utilise the Microchip USB driver in PIC18F25K50 firmware. It appears to me to be compatible with open-source principles, and additionally it fully supports XC8 compiler (the problems I'm having could have been introduced by some difference in compiler behaviour).
The MLA homepage is here - it appears to indicate that PIC18 is not supported, but if you download the release notes, you will see that it is.
https://www.microchip.com/en-us/tools-resources/develop/libraries/microchip-libraries-for-applications
A copy of the USB library is also provided at https://github.com/MicrochipTech/mla_usb and this also indicates PIC18 support.
I did investigate using MPLAB Code Configurator to generate a USB driver, however it doesn't seem to be able to generate a HID class device driver.
If you are happy that using this library does not violate the open-source principles of the project, then I will start working on replacing the USB code.
I have the impression that you are not implementin an HID class device.
If you do so there is no need for drivers, it is a peripheral like a mouse, joystick etc.
The Microchip USF firmware is not open source, that's why I changed long ago for an open alternative.
Sorry for confusion, by "USB driver" I am referring to the part of the firmware on the PIC that manages the USB peripheral (usb.c and usb.h in your project). I am certainly implementing a HID class device, since it requires no Windows driver installation, which is one of the great features of this project.
Regarding the concern about the Microchip USB firmware - the short version is that the GPL was invented to encourage free software, and the Microchip USB firmware is definitely free software now (although perhaps it wasn't in the past). The rest of this post is the justification for that statement. But if you mean something else by "not open source" then you will need to explain.
"Free software" is defined by the FSF (https://www.gnu.org/philosophy/free-sw.html).
MLA used to be licensed under Microchip's Licensing Agreement (I checked the 2012 version, and it was still under this one), which probably means it was not free software back then - although, the license does allow you to modify the code, so I'm not 100% sure. Anyway, at some point, they decided to release it under Apache 2.0 license instead.
FSF has a list of licenses here: https://www.gnu.org/licenses/license-list.html. According to their view, software released under Apache 2.0 license qualifies as free. The Apache 2.0 license is not compatible with the GPLv2 license, however it is compatible with the GPLv3 license. In fact, one key goal for FSF in creating GPLv3 was to enable inclusion of Apache 2.0-licensed code in GPL-licensed software (see "New Compatible Licenses" under https://www.gnu.org/licenses/quick-guide-gplv3.html - the diagram here is very good).
Now, looking back at openprog - the openprog webpage says the code is released under GPLv2, however all of the headers in your source code say "either version 2 of the License, or (at your option) any later version.". I'm assuming you just took the standard GPLv2 wording.
My point is that FSF, who created the GPL, are very happy for GPL-licensed projects to make use of Apache 2.0-licensed code - they actively removed the barrier preventing inclusion of Apache 2.0-licensed code in GPL-licensed projects. We would just need to be careful to keep Microchip source files unmodified (which is not difficult).
Well, if it is an HID device with the right descriptor it has to work with the same exact software (on PC side). In fact the first firmware versions did use that framework.
MLA is definitely not free software in the classical sense, and not compatible with any GPL.
In the end, changing USB framework and C compiler is a lot of work, some in the coding itself but much more in verification: keep in mind that there are also assembly sections that are strongly timing critical.
So a first question is: what exactly is the advantage in making any change?
Is there an alternative path to obtain the same objectives?
Good questions.
The biggest motivation for me, is to provide an open-source programmer that is capable of high-voltage programming, and does not require a high-voltage programmer to construct! If you have any suggestion about an easier way to do that, then I am open to it, but my idea was to utilise a similar PIC that supports low-voltage programming, as that (hopefully) allows re-use of all of the code you worked so hard on.
Additionally, a long-term issue for this project that one day it will be impossible to build. The C18 and MPASM environment is going to break one day, and we will lose the best open-source programmer unless somebody converts it.
Since converting to a different PIC requires all the verification work anyway, if we upgrade the compiler at the same time we kill two birds with one stone. I would like to learn the techniques used to verify that timing requirements are still met, so if you can teach me how (or point me to some learning resources), I am happy to do the bulk of the work.
The reason I want to use MLA code is simply because it appears to be easier than making the existing USB code work on a different PIC (in fact I've already finished the conversion). Obviously, if MLA is incompatible with GPLv3, then it's not feasible to use this, so we need to clarify that point.
On that topic, I need to disagree with your statement that MLA is not compatible with any GPL. The code is released under Apache 2.0 license which everybody agrees is free and open source, and FSF themselves say is compatible with GPLv3. What makes you think MLA isn't compatible with GPLv3? As I mentioned before, the MLA licensing has changed since you initially developed this project.
If you are still not comfortable that the licensing is OK, would it help if we ask FSF for verification? They have an email address for these kind of licensing questions. If you like, I can draft an email for your review, and once you're happy with it, I can send it.
Last edit: Stephen Gordon 2022-03-21
All PIC18 devices support low voltage programming.
The current firmware, however, is not compatible with LVP because RB5 would be reserved for program mode entry (as PGM), while it works as Data IO in normal operation.
This "feature" is present in the 18F2550 while I don't see the limitation in the 18F25K50; so that would be an advantage.
I was thinking about a workaround through the use of self-programming, so after a first low voltage write the device would self-disable LVP; I would need to try to confirm it can work.
Sure you can ask about license compatibility, maybe it used to be different 10 years ago.
Still, I am reluctant to invest so much time in a firmware that is compiled every 3 years on average; it would be easier to recompile using the same tool chain.
Regarding verification of changes, no problem in sharing the procedure, but notice how many different devices have been verified: do you have access to all of them? Or how many?
Because if most of the activity lands on me I need a very compelling reason, not simply a change of compiler or USB framework...
Regarding the licensing query - I will send you a message sharing my personal email address. We can then work via email to draft an email asking about the licensing question.
I believe you have to use high-voltage programming to disable LVP (a good feature!).
I would definitely verify all devices in my possession. Let me see what additional devices I could purchase for a reasonable cost.
Just in case anyone reads this thread - Alberto and I have been collaborating and have made a lot of progress. A new firmware already exists supporting PIC18F25K50, but it has not been fully tested. Alberto is still working on a couple of other features for the next version.
I have also successfully compiled the existing firmware in MPLAB X/XC8 - without using the Microchip USB framework (avoiding all the licensing questions). This also needs more testing. I will certainly post a link here once it works, and I'm hoping Alberto will add it to the main webpage. I plan to run this as a downstream project and adopt all changes that Alberto makes into this version.
opgui has been ported to GTK3 which has much better Windows runtime availability, and I am also developing an SMD PCB as an alternative construction option (with 1206-size components and 1.27mm IC pin pitch so it's nice and easy to solder).
So, plenty of exciting developments.
If it's any help we already did an SMD version, Alberto has one.
Best wishes
Tim
On Wed, 25 May 2022 at 06:05, Stephen Gordon
stephengordon@users.sourceforge.net wrote:
Cool! I will release the designs for mine once I get around to ordering and testing it. It is 55x52.5mm, as I totally removed the device sockets. It is fully compatible with the existing daughter boards, but I also designed a new "all-in-one" daughter board (200x120mm) with a 10F20x socket.
I am targeting two types of people... firstly thoes who (like me) have an MPLAB Snap but need to program a chip that doesn't support low-voltage programming and don't want to buy a PICkit just for that. Secondly, those who can't/won't manufacture their own PCBs (again, like me - I have small children and don't want to store the chemicals around home). If you are paying shipping for the programmer board, the low additional manufacturing cost of the daughter boards means it is sensible to just get all of them in case you need them one day. But getting 6 small boards is a lot more expensive than 1 big one.
Hopefully someone else will also find it useful.
BTW the firmware that compiles with XC8 is at https://github.com/gordoste/openprog
Hi,
Any news on an SMT version of the programming board? Do you have any Kicad files for this version of the board? I'd like to build a smaller footprint version for use in our embedded system lab at the UK university where I work. Thanks.
Last edit: David Briscoe 2023-02-16
Please provide an email address and I will send you my version. It consists of a small programmer board and a large board for plugging in devices to be programmed. This large board replaces all of the various openprog add-on boards, as it's much cheaper to fabricate two boards than 6. I have done some testing with common devices and it works fine so far.
Here is a picture. The programmer board is 57mm x 52.5mm. Target board is 200mm x 120mm.
I added a pad for the SOT-23 version of 10F20x, which were very difficult to program before. I allowed space and made bigger holes so that ZIF sockets can be used if desired for most devices.
The programmer board's ICSP also matches the SNAP programmer pinout, making it easier to program openprog firmware.
I also added a switch on RA7 pin which is free because there is no oscillator any more. This could be used to do batch programming (e.g. press the button when you are ready to program the next chip). Alberto already added some code in opgui for this but he didn't have any spare pins on the 18F2550 so I don't think there is any firmware support - but it wouldn't be hard to add.
Last edit: Stephen Gordon 2023-02-21