| T O P I C R E V I E W |
| jacklick |
Posted - 02/23/2019 : 07:06:28
Believe there is a the bug related to speed setting on chips. In devices.txt file, speed 1 (slowest) == speed 5 aka -2 (slowest) in program; vice-versa speed 5 in devices.txt (fastest) == Speed 1 aka +2 in program.
Most chips default to the fastest speed. Not sure if that is by design.
Apologize if this has been raised before...will try to search a bit better.
Edit>>Would also be good to document exactly what the speed setting does. Does it change the pulse width from 50ms,1ms, 100usec? If so, which speed corresponds to what pulse width?
H/W Re: GQ-4X Re-2.20(SW Re. 6.38)
USB Driver Re.2.0
Software Re. 6.38
|
| 15 L A T E S T R E P L I E S (Newest First) |
| anniel |
Posted - 04/03/2019 : 04:49:52
quote:
Originally posted by lance4glas
I also just recently noticed the discrepancy in the Speed settings on my GQ-4X, where Speed Setting -2 = 5, setting -1 = 4. setting 0 = 3, setting +1 = 2 and setting +2 = 1.
And was going to initiate a post regarding the discrepancy prior to discovering this thread.
It does seem to me that the settings should be reversed, as it would make more sense with the Speed Setting Initialized at / of 0 = 3.
Therefore, +1 should = 4, +2 should equal 5, and -1 should =2 while -2 should = 1.
But then again, that is simple 1st grade level basic Math and not the sophisticated, complex razzle dazzle double speak employed by some on this forum.
FWIW - I do believe that it was in the Police Academy that I attended after I changed careers from Data Processing ( NOW THAT definitely DATES me ) to Law Enforcement that I was taught - " If you can NOT offer a VALID response to a question posed by the Defense Attorney - then just ' Baffle them with your Bull-****' "
I will go NO further than the above ! 
Yes, it IS simple 1st grade level basic math to understand it is a speed reduction. |
| lance4glas |
Posted - 04/02/2019 : 16:30:45
I also just recently noticed the discrepancy in the Speed settings on my GQ-4X, where Speed Setting -2 = 5, setting -1 = 4. setting 0 = 3, setting +1 = 2 and setting +2 = 1.
And was going to initiate a post regarding the discrepancy prior to discovering this thread.
It does seem to me that the settings should be reversed, as it would make more sense with the Speed Setting Initialized at / of 0 = 3.
Therefore, +1 should = 4, +2 should equal 5, and -1 should =2 while -2 should = 1.
But then again, that is simple 1st grade level basic Math and not the sophisticated, complex razzle dazzle double speak employed by some on this forum.
FWIW - I do believe that it was in the Police Academy that I attended after I changed careers from Data Processing ( NOW THAT definitely DATES me ) to Law Enforcement that I was taught - " If you can NOT offer a VALID response to a question posed by the Defense Attorney - then just ' Baffle them with your Bull-****' "
I will go NO further than the above ! |
| anniel |
Posted - 03/19/2019 : 14:11:28
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
Algorithms are documented in datasheets.
Yes but some chips support multiple algorithms eg. Standard 50us or Fast 1ms based on WVCC setting. Some algorithms verify after each write and some verify after the all bytes are written.
Would be good to know what algorithm is used based on the chip class or even show the pulse width setting being used or how the speed setting interacts with the chip class/algorithm.
regardless, still have a discrepancy between speed setting in devices.txt and how that is translated to UI.
So 1ms is faster than 50us?
I meant standard 50ms vs Fast 1ms, but you knew that, and still offered nothing towards my question. Why? Very deflective and dismissive in your responses. I am just trying learn and understand but guess if you are the only one capable of responding, I came to the wrong place.
What is your question exactly?
I will rephrase quoted comment to clear questions.
Does the chip class control control the programming algorithm?
How do you know what algorithm (standard, fast, quick, other) is being used? Is it possible to see the pulse width setting per chip class or is it documented? Is the programmer doing something more unique or "smart" (like programming each byte, verifying, backing off pulse, verifying? How does the speed setting come into play?
So, basically, you want me to reverse-engineer the GQ-4X software for you?
quote:
What is the best way to report speed setting bug?
Call MCUMall? |
| jacklick |
Posted - 03/19/2019 : 09:03:54
quote:
Originally posted by anniel
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
Algorithms are documented in datasheets.
Yes but some chips support multiple algorithms eg. Standard 50us or Fast 1ms based on WVCC setting. Some algorithms verify after each write and some verify after the all bytes are written.
Would be good to know what algorithm is used based on the chip class or even show the pulse width setting being used or how the speed setting interacts with the chip class/algorithm.
regardless, still have a discrepancy between speed setting in devices.txt and how that is translated to UI.
So 1ms is faster than 50us?
I meant standard 50ms vs Fast 1ms, but you knew that, and still offered nothing towards my question. Why? Very deflective and dismissive in your responses. I am just trying learn and understand but guess if you are the only one capable of responding, I came to the wrong place.
What is your question exactly?
I will rephrase quoted comment to clear questions.
Does the chip class control control the programming algorithm?
How do you know what algorithm (standard, fast, quick, other) is being used? Is it possible to see the pulse width setting per chip class or is it documented? Is the programmer doing something more unique or "smart" (like programming each byte, verifying, backing off pulse, verifying? How does the speed setting come into play?
What is the best way to report speed setting bug?
|
| anniel |
Posted - 03/19/2019 : 07:09:49
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
Algorithms are documented in datasheets.
Yes but some chips support multiple algorithms eg. Standard 50us or Fast 1ms based on WVCC setting. Some algorithms verify after each write and some verify after the all bytes are written.
Would be good to know what algorithm is used based on the chip class or even show the pulse width setting being used or how the speed setting interacts with the chip class/algorithm.
regardless, still have a discrepancy between speed setting in devices.txt and how that is translated to UI.
So 1ms is faster than 50us?
I meant standard 50ms vs Fast 1ms, but you knew that, and still offered nothing towards my question. Why? Very deflective and dismissive in your responses. I am just trying learn and understand but guess if you are the only one capable of responding, I came to the wrong place.
What is your question exactly? |
| jacklick |
Posted - 03/19/2019 : 04:24:26
quote:
Originally posted by anniel
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
Algorithms are documented in datasheets.
Yes but some chips support multiple algorithms eg. Standard 50us or Fast 1ms based on WVCC setting. Some algorithms verify after each write and some verify after the all bytes are written.
Would be good to know what algorithm is used based on the chip class or even show the pulse width setting being used or how the speed setting interacts with the chip class/algorithm.
regardless, still have a discrepancy between speed setting in devices.txt and how that is translated to UI.
So 1ms is faster than 50us?
I meant standard 50ms vs Fast 1ms, but you knew that, and still offered nothing towards my question. Why? Very deflective and dismissive in your responses. I am just trying learn and understand but guess if you are the only one capable of responding, I came to the wrong place. |
| anniel |
Posted - 03/08/2019 : 15:17:24
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
Why would that be a bug? Did it ever cause a software failure?
So software bugs are only for software failures?
If it is functioning as desired, so be it. I guess I shouldn't have reported it.
Wikipedia:"A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways."
isn't that what this is. You configure the device.txt file one way and it is interpreted by software the exact opposite of what is expected. Pretty sure it is behaving in "unintended ways" and producing "unexpected results"
Do you work for mcumall?
I think it is pretty well intended and expected, probably for historical reasons?
Nope but I think it would be interesting. |
| jacklick |
Posted - 03/08/2019 : 09:54:43
quote:
Originally posted by anniel
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
Why would that be a bug? Did it ever cause a software failure?
So software bugs are only for software failures?
If it is functioning as desired, so be it. I guess I shouldn't have reported it.
Wikipedia:"A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways."
isn't that what this is. You configure the device.txt file one way and it is interpreted by software the exact opposite of what is expected. Pretty sure it is behaving in "unintended ways" and producing "unexpected results"
Do you work for mcumall? |
| anniel |
Posted - 03/08/2019 : 09:51:30
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
Why would that be a bug? Did it ever cause a software failure?
So software bugs are only for software failures?
If it is functioning as desired, so be it. I guess I shouldn't have reported it.
Wikipedia:"A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways." |
| anniel |
Posted - 03/08/2019 : 09:51:25
quote:
Originally posted by jacklick
quote:
Originally posted by anniel
Algorithms are documented in datasheets.
Yes but some chips support multiple algorithms eg. Standard 50us or Fast 1ms based on WVCC setting. Some algorithms verify after each write and some verify after the all bytes are written.
Would be good to know what algorithm is used based on the chip class or even show the pulse width setting being used or how the speed setting interacts with the chip class/algorithm.
regardless, still have a discrepancy between speed setting in devices.txt and how that is translated to UI.
So 1ms is faster than 50us? |
| jacklick |
Posted - 03/08/2019 : 08:38:01
quote:
Originally posted by anniel
Why would that be a bug? Did it ever cause a software failure?
So software bugs are only for software failures?
If it is functioning as desired, so be it. I guess I shouldn't have reported it. |
| jacklick |
Posted - 03/08/2019 : 08:29:10
quote:
Originally posted by anniel
Algorithms are documented in datasheets.
Yes but some chips support multiple algorithms eg. Standard 50us or Fast 1ms based on WVCC setting. Some algorithms verify after each write and some verify after the all bytes are written.
Would be good to know what algorithm is used based on the chip class or even show the pulse width setting being used or how the speed setting interacts with the chip class/algorithm.
regardless, still have a discrepancy between speed setting in devices.txt and how that is translated to UI. |
| anniel |
Posted - 03/08/2019 : 05:39:11
quote:
Originally posted by jacklick
Guess I will respond to my own thread. Based on other forum posts, it doesn't seem the "Speed" setting directly impacts the write algorithm and it is not clear what the setting does specifically but i am assuming it is a wait time for the write algorithm to fail or delay to dynamically back off pulse width. I still believe their is a bug between setting in Devices.txt and how the programming software interprets that. Plus the -2,1,0,+1,+2 is just confusing to reference a 1-5 setting.
It appears the write algorithm used is determined by the chip class but you don't know which algorithm is used so no way to verify if the Wvpp and Wvcc are accurate. For example, many 2764 chips can program at wvcc 5v at 50ms (Standard/Slow) but to enable (Fast/ 1ms) you need to be at Wvcc 6v. However, all 2764 have wvcc setting of 5.5 in gq-4x devices.txt.
Completely just a theory, would love to have a comment or if I get motivated, may try to prove, but I am assuming the algorithm is something dynamic where it might start at pulse width 100us, try to verify, back off to 200us, 400us,.. 1ms...50ms, until bit or byte is successfully programmed and verified. By adjusting the speed slower, you may be giving the algorithm more time to back off pulse width to allow successful programming. Again that is just a theory and if I have missed this being explained in documentation, apologies.
couple older forum posts I found related to the topic
http://www.mcumall.com/forum/topic.asp?TOPIC_ID=428
There are some info I know:
1. The new device can be added into the device search list by modifying the devices.txt.
2. The new device is based on the existing chip family, it's called "class" in the devices.txt file. They are sharing same read/write algorithm. Only different on size, speed, voltage, package. So that you can add the new devices based on the same class. The class is the predefined algorithm collection, user is unable to change the class for now.
3. You have to follow the syntax in the devices.txt file.
4. The new dip setting is by "DIP=", example: "DIP=100010110000". for total 12 bit DIP switch. 1 or 0 for one bit DIP switch ON or OFF.
http://www.mcumall.com/forum/topic.asp?TOPIC_ID=361
The current write algorithm used byte mode to write. The write algorithm has build in verification step after each byte write. If the write mode and verification mode switching speed is faster than chip's speed, the verification will fail. The speed seems not controlled the switching mode here.
Algorithms are documented in datasheets. |
| anniel |
Posted - 03/08/2019 : 05:34:35
quote:
Originally posted by jacklick
Believe there is a the bug related to speed setting on chips. In devices.txt file, speed 1 (slowest) == speed 5 aka -2 (slowest) in program; vice-versa speed 5 in devices.txt (fastest) == Speed 1 aka +2 in program.
Most chips default to the fastest speed. Not sure if that is by design.
Apologize if this has been raised before...will try to search a bit better.
Edit>>Would also be good to document exactly what the speed setting does. Does it change the pulse width from 50ms,1ms, 100usec? If so, which speed corresponds to what pulse width?
H/W Re: GQ-4X Re-2.20(SW Re. 6.38)
USB Driver Re.2.0
Software Re. 6.38
Why would that be a bug? Did it ever cause a software failure? |
| jacklick |
Posted - 03/06/2019 : 06:34:50
Guess I will respond to my own thread. Based on other forum posts, it doesn't seem the "Speed" setting directly impacts the write algorithm and it is not clear what the setting does specifically but i am assuming it is a wait time for the write algorithm to fail or delay to dynamically back off pulse width. I still believe their is a bug between setting in Devices.txt and how the programming software interprets that. Plus the -2,1,0,+1,+2 is just confusing to reference a 1-5 setting.
It appears the write algorithm used is determined by the chip class but you don't know which algorithm is used so no way to verify if the Wvpp and Wvcc are accurate. For example, many 2764 chips can program at wvcc 5v at 50ms (Standard/Slow) but to enable (Fast/ 1ms) you need to be at Wvcc 6v. However, all 2764 have wvcc setting of 5.5 in gq-4x devices.txt.
Completely just a theory, would love to have a comment or if I get motivated, may try to prove, but I am assuming the algorithm is something dynamic where it might start at pulse width 100us, try to verify, back off to 200us, 400us,.. 1ms...50ms, until bit or byte is successfully programmed and verified. By adjusting the speed slower, you may be giving the algorithm more time to back off pulse width to allow successful programming. Again that is just a theory and if I have missed this being explained in documentation, apologies.
couple older forum posts I found related to the topic
http://www.mcumall.com/forum/topic.asp?TOPIC_ID=428
There are some info I know:
1. The new device can be added into the device search list by modifying the devices.txt.
2. The new device is based on the existing chip family, it's called "class" in the devices.txt file. They are sharing same read/write algorithm. Only different on size, speed, voltage, package. So that you can add the new devices based on the same class. The class is the predefined algorithm collection, user is unable to change the class for now.
3. You have to follow the syntax in the devices.txt file.
4. The new dip setting is by "DIP=", example: "DIP=100010110000". for total 12 bit DIP switch. 1 or 0 for one bit DIP switch ON or OFF.
http://www.mcumall.com/forum/topic.asp?TOPIC_ID=361
The current write algorithm used byte mode to write. The write algorithm has build in verification step after each byte write. If the write mode and verification mode switching speed is faster than chip's speed, the verification will fail. The speed seems not controlled the switching mode here. |
|
|
