In the end into the firmware which has the patch #23 despite the various settings for the speed, ~5kHz, ~50kHz, ~100kHz and ~400kHz, the actual speed provided by the Bus Pirate is between ~635Hz and ~1kHz does not matter what (~635Hz by setting for ~5kHz into the menu of the Bus Pirate, for the remaining values, ~50kHz, ~100kHz and ~400kHz, it is ~1kHz for them all) rather far from specifications, lower than projected. It is possible to see that using the new firmware incorporating the patch #23 into 1 second of acquiring only 111 data bytes are logged, while using the previous release in the same conditions all the 2048 data bytes are collected within 1 second which is largely enough to complete the job. The logs of the two readings are here as attachment. #USB OVERDRIVE KNOWN PIRATE FULL#New speeds are lower than before, this is for sure.įor instance has been read the full contents of a memory IC over a I2C bus using the ~50kHz speed and the entire reading was acquired with a logic analyzer set for 4MHz sampling and 1 second lasting. However the usual friend of mine did some shots that I have not any analyzer or oscilloscope.īased on what is possible to see the new firmware built starting from the current repository where patch #23 is applied it works with a reduced speed clock.īy setting I2C for ~50kHz into the menu of the Bus Pirate the actual speed used is about ~730Hz, max ~1kHz, depending it if in setup or read/write over the I2C protocol, while with the previous release which has not the patch #23 applied the clock speed for the same ~50kHz setting is actually ~31kHz, max ~35kHz, still it depending if in setup or read/write over the I2C protocol. Sadly I know nothing about why I2C stops working while the patch #23 is applied. I have digged further and by applying the fix #23 then I2CEEPROMWIN (source code here: ) does not work any more, it read wrong (all values are 0x01 does not matter for the late reply. I know this is already been closed, so I apologize for the hijacking, but in my opinion something is weird there. Is there is a way to ensure that is the correct behavior? I just built a new firmware for the BP revision 3 starting from the current repository and I noticed this. With the previous versions of the firmware by choosing for different speed even the refresh of the characters on the terminal are different, instead now with the #23 fixed it is not so any more. No matter the speed that is chosen (~5kHz, ~50kHz, ~100kHz, ~400kHz), then the responses that are shown in the terminal seems to be slow, much slower than setting for ~5kHz using previous versions of the firmware where the issue #23 had not been fixed yet. I know I am babo as hell and more serious this issue is closed, I wonder how it works though, because it seems to me that now I2C does not honor the target speed choosed into the menu.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |