Open tudorp opened 8 years ago
If you take a look at the SUMP protocol, esp. command 0x81h, you get 16-bits for the read count (= the number of samples times 4 returned to the PC). So: 65536 * 4 = 256k.
Thank you for pointing out the specific issue.
At the heart of my mistake is the fact that in my device I do not implement at all support for 0x81, fact that made me not to notice its implications on one hand and on the other hand to realize now that the protocol is quite limited given the syntax of 0x81.
Referring strictly to the existing implementation, I still do not think that trimming the expected sample count value by anding with a mask is the best choice here; maybe comparing the value with the specific limit and saturating it when needed would be better given the fact that command 0x81 still needs to be carried out properly?
On Thu, Sep 22, 2016 at 8:49 PM, Jan Willem Janssen < notifications@github.com> wrote:
If you take a look at the SUMP protocol http://www.sump.org/projects/analyzer/protocol/, esp. command 0x81h, you get 16-bits for the read count (= the number of samples times 4 returned to the PC). So: 65536 * 4 = 256k.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jawi/ols/issues/236#issuecomment-248976929, or mute the thread https://github.com/notifications/unsubscribe-auth/ACyxVAXEBLuHXiXVoxlS2doauVRTzPKTks5qsr-hgaJpZM4KAQes .
SUMP devices able to provide over 512kB of samples can't be used at full potential due to an internal software limit set in device.logicsniffer/src/main/java/org/sump/device/logicsniffer/LogicSnifferConfig.java that states "the number of samples to take, must be between 4 and 256*1024". The limit seems artificial and limits the possible functionality of other SUMP devices.