Hi Alberto,
I am happy to have found OP and happy to be testing/using it.
I only have need for few different low capacity PICs (12F, 16F), and OP is doing what I expected.
Having the CLI, GUI and Firmware full open source is really something very interesting, and be able to use its full features with a GNU/Linux box is a really nice feature...
I am starting to take a look at the code, to understand it better for my own needs and to be able to have a good user relationship with it for long term.
The more I learn, the more I am getting interested in OP...
Other than the few PICs that I am interested now, I do have some more different devices and will be trying/testing then so that the "tested list" can growth and help attract more users...
I was thinking about the size of the .hex if I remove/delete the code for ParseCommands(), so I did and WOW, the USB portion is only about 1800K Words (exclusing EEPROM)!!!
Then I did an experiment, to see if the code can compile for the 18F14K50 as target, since the 18F2450 also has only 8K Words (the same for the 14K50), I became interested in having it tested...
Well, it does compile and link OK...
After connecting to a GNU/Linux box the negociation with the PC goes OK...
Of course, IT CAN DO NOTHING, since there is no ParseCommands()...
I don't know if the USB code will be functional on the 14K50 but at least I know that the size is OK, compilation is OK, establishment of connection with PC is OK... maybe it also works (the USB portion) on this target as well...
Making a "Slim Version of OP" works on the 14K50 is something that I became interested...
I am not going to try it now, but it is something I want to think and try later...
There are 2 things that I am thinking right now (will be trying it later):
1) make the USB stack works on the 14K50
2) make a Slim Version of OP for the 14K50 (only 20 pins, can it be?)
Attached is the linker script that I forge for the 18F14K50... not sure if is correct or enough... Compiler is C18 v3.46
Below is the dmesg output on GNU/Linux when connecting the 14K50...
{ [29555.950541] usb 1-4.3: USB disconnect, device number 6 [29568.460486] usb 1-4.3: new full-speed USB device number 13 using ehci-pci [29568.572340] usb 1-4.3: New USB device found, idVendor=1209, idProduct=5432 [29568.572345] usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [29568.572347] usb 1-4.3: Product: Open Programmer USB HID class [29568.572349] usb 1-4.3: Manufacturer: Open Programmer [29568.575785] hid-generic 0003:1209:5432.0004: hiddev0,hidraw0: \
USB HID v1.01 Device [Open Programmer Open Programmer USB HID class] on usb-0000:00:02.1-4.3/input0
}
Of course, OP was used to burn the 14K50 with the test hex...
So, OP is, in reality, doing much more than I was expecting!!!
For now, I like to say congratulations for the good and long work on OP, nice job!
Based on my count it is supporting 802 MCUs (eight hundred devices)!
This number alone speaks a LOT...
Porting to the 18F14K50 seems possible.
I did not check all the configurations in detail, but the fact that USB works is a good sign.
I expect some changes in the way pheriperals are controlled.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-02-18
Hi.
Thanks for the reply about the 14K50...
To be honest, the 14K50 is a nice device but the flash size and numbers of I/O is probably a huge obstacle if we consider OP and portability issues...
To start, you "loose" RA5 and RA4 to the oscillator, plus the RA0 and RA1 to USB, RA3 is reset, subtracting Vdd, Vss, Vusb... then, you only have 12 I/O, and this is the START...
The reason I am interested in trying this device goes beyond the device ITSELF...
It is somehow connected with the subject of portability and modularity...
I have some ideas that I am trying to put on a presentation file, maybe you will find something useful to the future of OP...
Nothing practical yet, just some general directions/ideas...
This is not a project, just a set of notes/ideas surrounding the wide theme of small discrete MCUs (like PIC 8bits) and WHY the associated MCU programmer is an important TOPIC (still and will continue to be) and HOW should we look at it...
Some kind of "personal point of view" made into a presentation, so that, I myself, can have more clarity about the subject...
Learning OP project and using/learning it is also helping me to shape the whole idea into the doc...
The JPEG picture illustrate one of the main points...
The draft document (pdf, odg) is attached, as soon as I put some more slides I will share the final doc here...
From the perspective of the presentation, the 18F14K50 becomes a more interesting device to think about (trying/testing) the portability issue...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-02-20
Hi Alberto,
here is the presentation with the other slides included.
These slides shows in general lines what is in my mind now surrounding the subject of Microcontrollers Programmers.
I am sharing here because I think some ideas there may be useful for the future of OP...
Keep in mind that I am not asking for features, the current state of OP does all the things that I need now (1XF18xx, 1XF183xx, 1XF15xx), and I am happy because I am getting more than I was looking for...
I am starting to take a look at code level now, firmware, PC CLI and also PC GUI, because some of my future needs may benefit from knowing how to change things, so that we don't need to ask things from you, instead, we may be able to help the project directly by improving/changing the code...
Right now, I am specially intrigued by the possibility to create the Flash Programming Description Language Database, because if we achieve it, then things will become very interesting...
Not for necessity now, but, I am excited with the possibility to "detach" the USB module and make it work on other 18F w/ USB...
Also, I am very interested in trying to "detach" the software and the hardware of the Voltage Booster from the main MCU to a separated 8p/14p MCU, thus creating a Voltage Booster Module (universal), so that we can use it w/ Duinos, PIs, ESPs, etc...
Well, as said before, there is no project, just desire to hack around these ideas and, I am seeing in OP ALL the elements to start...
In other words, I am seeing in OP a Platform to exercise these ideas...
Of course, things can go beyond just exercises, but this is no my thinking now...
Well, one thing you have to consider is that modularization usually goes against efficiency.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-02-21
Hi, YES, you are absolutelly right.
The reason we all love MCUs is that they are PRECISE, down to microseconds control...
I also like assembly and its control over bits and precise timming...
I think we should no walk away from it... and what is more important is that it is working well..
I am thinking about having, ALSO, other options that possible can greatly complement the good things that ALREADY is working well...
But they are aall ideas to consider, for the time to come... right now I am very happy with OP...
Valter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-02-24
Hi, just want to report another little test for OP running inside the 18F14K50...
Firmware
Taking "ParseCommands()" back to OPcontrol.c and removing lots of functions like JTAG, SPI, etc, as well as eliminating pin conflits/problems...
PC CLI App
Implement new switchs to Vdd On and Vdd Off, "-J" and "-j"...
I am able to connect the 14K50 and switch a LED (and 1k Resistor) ON and OFF using the op CLI command...
(Without the PNP transistor, the switch is working "inverted" for the direct LED on RC1... switch OFF turn the LED on, switch ON turn the LED off)
So, this is the 2nd good sign that the USB Software Module can work on the 18F14K50... just a simple test but shows a good sign...
The CCP2 connected stuff was completely removed so, NO Voltage Booster at all for this test...
I was basically interested in knowing if the USB module can receive/send messages from/back to PC...
Following is the result of "./op -i" command:
Programmer detected on /dev/usb/hiddev0
Programmer detected
Firmware version 0.11.0
Hardware ID: 0.0.255 (?)
vid 0x1209 pid 0x5432 version 0x0001
bus: 1 devnum: 8 ifnum: 0
The device on /dev/usb/hiddev0 says its name is Open Programmer Open Programmer USB HID class
So Far So Good... the more I learn, the more I am insterested/motivated...
I am attach-ing here the linker script and the file usb.c (two lines are different from the original), so that if anybody wants to try...
Hi Alberto,
I am happy to have found OP and happy to be testing/using it.
I only have need for few different low capacity PICs (12F, 16F), and OP is doing what I expected.
Having the CLI, GUI and Firmware full open source is really something very interesting, and be able to use its full features with a GNU/Linux box is a really nice feature...
I am starting to take a look at the code, to understand it better for my own needs and to be able to have a good user relationship with it for long term.
The more I learn, the more I am getting interested in OP...
Other than the few PICs that I am interested now, I do have some more different devices and will be trying/testing then so that the "tested list" can growth and help attract more users...
I was thinking about the size of the .hex if I remove/delete the code for ParseCommands(), so I did and WOW, the USB portion is only about 1800K Words (exclusing EEPROM)!!!
Then I did an experiment, to see if the code can compile for the 18F14K50 as target, since the 18F2450 also has only 8K Words (the same for the 14K50), I became interested in having it tested...
Well, it does compile and link OK...
After connecting to a GNU/Linux box the negociation with the PC goes OK...
Of course, IT CAN DO NOTHING, since there is no ParseCommands()...
I don't know if the USB code will be functional on the 14K50 but at least I know that the size is OK, compilation is OK, establishment of connection with PC is OK... maybe it also works (the USB portion) on this target as well...
Making a "Slim Version of OP" works on the 14K50 is something that I became interested...
I am not going to try it now, but it is something I want to think and try later...
There are 2 things that I am thinking right now (will be trying it later):
1) make the USB stack works on the 14K50
2) make a Slim Version of OP for the 14K50 (only 20 pins, can it be?)
Attached is the linker script that I forge for the 18F14K50... not sure if is correct or enough...
Compiler is C18 v3.46
Below is the dmesg output on GNU/Linux when connecting the 14K50...
{
[29555.950541] usb 1-4.3: USB disconnect, device number 6
[29568.460486] usb 1-4.3: new full-speed USB device number 13 using ehci-pci
[29568.572340] usb 1-4.3: New USB device found, idVendor=1209, idProduct=5432
[29568.572345] usb 1-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[29568.572347] usb 1-4.3: Product: Open Programmer USB HID class
[29568.572349] usb 1-4.3: Manufacturer: Open Programmer
[29568.575785] hid-generic 0003:1209:5432.0004: hiddev0,hidraw0: \
USB HID v1.01 Device [Open Programmer Open Programmer USB HID class] on usb-0000:00:02.1-4.3/input0
}
Of course, OP was used to burn the 14K50 with the test hex...
So, OP is, in reality, doing much more than I was expecting!!!
For now, I like to say congratulations for the good and long work on OP, nice job!
Based on my count it is supporting 802 MCUs (eight hundred devices)!
This number alone speaks a LOT...
Regards,
Valter
Correction: hex without ParseCommands() is 1800 Words, not Kilo...lol...
Porting to the 18F14K50 seems possible.
I did not check all the configurations in detail, but the fact that USB works is a good sign.
I expect some changes in the way pheriperals are controlled.
Hi.
Thanks for the reply about the 14K50...
To be honest, the 14K50 is a nice device but the flash size and numbers of I/O is probably a huge obstacle if we consider OP and portability issues...
To start, you "loose" RA5 and RA4 to the oscillator, plus the RA0 and RA1 to USB, RA3 is reset, subtracting Vdd, Vss, Vusb... then, you only have 12 I/O, and this is the START...
The reason I am interested in trying this device goes beyond the device ITSELF...
It is somehow connected with the subject of portability and modularity...
I have some ideas that I am trying to put on a presentation file, maybe you will find something useful to the future of OP...
Nothing practical yet, just some general directions/ideas...
This is not a project, just a set of notes/ideas surrounding the wide theme of small discrete MCUs (like PIC 8bits) and WHY the associated MCU programmer is an important TOPIC (still and will continue to be) and HOW should we look at it...
Some kind of "personal point of view" made into a presentation, so that, I myself, can have more clarity about the subject...
Learning OP project and using/learning it is also helping me to shape the whole idea into the doc...
The JPEG picture illustrate one of the main points...
The draft document (pdf, odg) is attached, as soon as I put some more slides I will share the final doc here...
From the perspective of the presentation, the 18F14K50 becomes a more interesting device to think about (trying/testing) the portability issue...
For now, regards,
Valter
Hi Alberto,
here is the presentation with the other slides included.
These slides shows in general lines what is in my mind now surrounding the subject of Microcontrollers Programmers.
I am sharing here because I think some ideas there may be useful for the future of OP...
Keep in mind that I am not asking for features, the current state of OP does all the things that I need now (1XF18xx, 1XF183xx, 1XF15xx), and I am happy because I am getting more than I was looking for...
I am starting to take a look at code level now, firmware, PC CLI and also PC GUI, because some of my future needs may benefit from knowing how to change things, so that we don't need to ask things from you, instead, we may be able to help the project directly by improving/changing the code...
Right now, I am specially intrigued by the possibility to create the Flash Programming Description Language Database, because if we achieve it, then things will become very interesting...
Not for necessity now, but, I am excited with the possibility to "detach" the USB module and make it work on other 18F w/ USB...
Also, I am very interested in trying to "detach" the software and the hardware of the Voltage Booster from the main MCU to a separated 8p/14p MCU, thus creating a Voltage Booster Module (universal), so that we can use it w/ Duinos, PIs, ESPs, etc...
Well, as said before, there is no project, just desire to hack around these ideas and, I am seeing in OP ALL the elements to start...
In other words, I am seeing in OP a Platform to exercise these ideas...
Of course, things can go beyond just exercises, but this is no my thinking now...
Regards,
Valter
Well, one thing you have to consider is that modularization usually goes against efficiency.
Hi, YES, you are absolutelly right.
The reason we all love MCUs is that they are PRECISE, down to microseconds control...
I also like assembly and its control over bits and precise timming...
I think we should no walk away from it... and what is more important is that it is working well..
I am thinking about having, ALSO, other options that possible can greatly complement the good things that ALREADY is working well...
But they are aall ideas to consider, for the time to come... right now I am very happy with OP...
Valter
Hi, just want to report another little test for OP running inside the 18F14K50...
Firmware
Taking "ParseCommands()" back to OPcontrol.c and removing lots of functions like JTAG, SPI, etc, as well as eliminating pin conflits/problems...
PC CLI App
Implement new switchs to Vdd On and Vdd Off, "-J" and "-j"...
I am able to connect the 14K50 and switch a LED (and 1k Resistor) ON and OFF using the op CLI command...
(Without the PNP transistor, the switch is working "inverted" for the direct LED on RC1... switch OFF turn the LED on, switch ON turn the LED off)
So, this is the 2nd good sign that the USB Software Module can work on the 18F14K50... just a simple test but shows a good sign...
The CCP2 connected stuff was completely removed so, NO Voltage Booster at all for this test...
I was basically interested in knowing if the USB module can receive/send messages from/back to PC...
Following is the result of "./op -i" command:
So Far So Good... the more I learn, the more I am insterested/motivated...
I am attach-ing here the linker script and the file usb.c (two lines are different from the original), so that if anybody wants to try...
Regards,
Valter