Just finished a 2000 (two thousands) write/read operation on OP v0.11.0 running on a Raspberry PI 3!
After checking the log files and md5sum the hexes, EVERYTHING 100% SUCCESS!
Zero Errors!
The first time I did tried OP on RPI3, there was a trouble around the USB communication between the PI and the Host OP MCU (2550), then I introduce some changes at the op.c file, to delay (slow down) the USB communication...
With the changes, the tests went OK!
1000 writes, followed by a 1000 reads, logs saved, checked: ALL OK!
In reality, I did 500 writes/reads before the 2000, so, the total number of success is 2500 operations.
Below is a description about the changes that I did...
File: "op.c" version v0.11.0
[1. lines 648 to 651, commented]
if(v==0){
PrintMessage(strings[S_lowUsbV]); //"Tensione USB troppo bassa (VUSB<4.5V)\r\n"
return 0;
}
changed to
//if(v==0){
// PrintMessage(strings[S_lowUsbV]); //"Tensione USB troppo bassa (VUSB<4.5V)\r\n"
// return 0;
//}
[2. line 657, changed the 1500 to 3000]
for(;(v<(vreg/10.0-1)G||v>(vreg/10.0+1)G)&&t<t0+1500;t=GetTickCount()){
changed to
for(;(v<(vreg/10.0-1)G||v>(vreg/10.0+1)G)&&t<t0+3000;t=GetTickCount()){
[3. line 928, commented, added 1 line after]
usleep(x>MinDly?x:MinDly);
changed to
//usleep(x>MinDly?x:MinDly);
usleep(15000); //add this line after the 928, 15000 = 15 miliseconds
Change 3 add a 15 miliseconds between a write to USB and a read USB.
Control Device ("PC"): Raspberry PI 3
OP Version: v0.11.0
Firmware: v0.11.0
External Powered USB Hub: 2500 mA
Target MCU: PIC 12F1822 I/P
Need to look further to understand exactly what is different for the RPI to work and how to deal correctly with the timming regarding the USB communication, but for now, these changes above allows the little PI to work with OP without problems...
Regards all,
Valter
PS. I will run the same batch of test on a single core Raspberry PI Zero and report later the result... preliminar tests show that the PI Zero can also run OP, read, write...
I was hoping to have OP on a dedicated RPI3 or some other similar SBC, but instead, if it can run a single core PI Zero, better!!!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-03-31
Just add:
The post is related to the OP CLI (command line) version.
1 Write is a full hex write operation.
1 Read is a full flash read operation.
Valter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Adding 15ms to every USB transfer will make everything terribly slow.
I would consider it a temporary solution.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2019-04-03
I think that the desktop PC will always be the choice for maximum speed...
When trying to go beyond the (desktop) PC in the direction of diverse types of devices, specialy if ones try to think about portable code, then the high speed achieved by OP on the desktop will be difficult to keep...
There are kinds of users and kinds of needs where maximum speed is desirable, but not essential nor priority... just consider, for example, a current Duino user, there is already a mcu that can be used as "host mcu for OP" with available GPIO to drive the needed functions... in this case, I think that loosing speed will not be detrimental, instead it can unleash potential by joining the existing code with existing hardware, both ready to provide benefits...
Looking at the RPI for example, because it have GPIOs, we can think about the creation of "native routines" that works as "VIRTUAL FIRMWARE", directly driving GPIO pins nativaly inside the PI itself...
Then, if ones create these "virtual firmware" routines with portability in mind, the code should be easy to "copy/paste" to Arduino IDE, which in turn should make it easy to run on Duinos and ESPs amoung many other devices...
So, trying to keep the maximum speed will add extra complexity to achieve...
I believe that going slow is a "good price" if we achieve a situation where a huge real potential is unleashed (joining the already existing code with the already existing hardware)...
Well, when there is need for maximum speed, the user can always count on the desktop PC for that, because this feature already exist...
Just finished a 2000 (two thousands) write/read operation on OP v0.11.0 running on a Raspberry PI 3!
After checking the log files and md5sum the hexes, EVERYTHING 100% SUCCESS!
Zero Errors!
The first time I did tried OP on RPI3, there was a trouble around the USB communication between the PI and the Host OP MCU (2550), then I introduce some changes at the op.c file, to delay (slow down) the USB communication...
With the changes, the tests went OK!
1000 writes, followed by a 1000 reads, logs saved, checked: ALL OK!
In reality, I did 500 writes/reads before the 2000, so, the total number of success is 2500 operations.
Below is a description about the changes that I did...
File: "op.c" version v0.11.0
[1. lines 648 to 651, commented]
if(v==0){
PrintMessage(strings[S_lowUsbV]); //"Tensione USB troppo bassa (VUSB<4.5V)\r\n"
return 0;
}
changed to
//if(v==0){
// PrintMessage(strings[S_lowUsbV]); //"Tensione USB troppo bassa (VUSB<4.5V)\r\n"
// return 0;
//}
[2. line 657, changed the 1500 to 3000]
for(;(v<(vreg/10.0-1)G||v>(vreg/10.0+1)G)&&t<t0+1500;t=GetTickCount()){
changed to
for(;(v<(vreg/10.0-1)G||v>(vreg/10.0+1)G)&&t<t0+3000;t=GetTickCount()){
[3. line 928, commented, added 1 line after]
usleep(x>MinDly?x:MinDly);
changed to
//usleep(x>MinDly?x:MinDly);
usleep(15000); //add this line after the 928, 15000 = 15 miliseconds
Change 3 add a 15 miliseconds between a write to USB and a read USB.
Control Device ("PC"): Raspberry PI 3
OP Version: v0.11.0
Firmware: v0.11.0
External Powered USB Hub: 2500 mA
Target MCU: PIC 12F1822 I/P
Need to look further to understand exactly what is different for the RPI to work and how to deal correctly with the timming regarding the USB communication, but for now, these changes above allows the little PI to work with OP without problems...
Regards all,
Valter
PS. I will run the same batch of test on a single core Raspberry PI Zero and report later the result... preliminar tests show that the PI Zero can also run OP, read, write...
I was hoping to have OP on a dedicated RPI3 or some other similar SBC, but instead, if it can run a single core PI Zero, better!!!
Just add:
The post is related to the OP CLI (command line) version.
1 Write is a full hex write operation.
1 Read is a full flash read operation.
Valter
Adding 15ms to every USB transfer will make everything terribly slow.
I would consider it a temporary solution.
I think that the desktop PC will always be the choice for maximum speed...
When trying to go beyond the (desktop) PC in the direction of diverse types of devices, specialy if ones try to think about portable code, then the high speed achieved by OP on the desktop will be difficult to keep...
There are kinds of users and kinds of needs where maximum speed is desirable, but not essential nor priority... just consider, for example, a current Duino user, there is already a mcu that can be used as "host mcu for OP" with available GPIO to drive the needed functions... in this case, I think that loosing speed will not be detrimental, instead it can unleash potential by joining the existing code with existing hardware, both ready to provide benefits...
Looking at the RPI for example, because it have GPIOs, we can think about the creation of "native routines" that works as "VIRTUAL FIRMWARE", directly driving GPIO pins nativaly inside the PI itself...
Then, if ones create these "virtual firmware" routines with portability in mind, the code should be easy to "copy/paste" to Arduino IDE, which in turn should make it easy to run on Duinos and ESPs amoung many other devices...
So, trying to keep the maximum speed will add extra complexity to achieve...
I believe that going slow is a "good price" if we achieve a situation where a huge real potential is unleashed (joining the already existing code with the already existing hardware)...
Well, when there is need for maximum speed, the user can always count on the desktop PC for that, because this feature already exist...
Regards,
Valter