bp_delay_us is not accurate

[agatti]

A more precise way to perform delays should be implemented as this might mess with timing-sensitive protocols such as 1-Wire. Unfortunately I bricked my v4 and I'm away for a week so I can't really work on this at the moment, but before the bricking I made 1-Wire work more reliably by changing the amount of time being waited, and my logic analyser all of a sudden would detect the protocol state changes.

Something that on paper should be more accurate would be this (assuming the number of milliseconds is in W0 and that it's running on a v4 board, which means it can execute 16 instructions each microsecond):

  sub #1, w0    /*  1 / 16 */ /* Compensate for first batch of NOPs */
  nop           /*  2 / 16 */
  nop           /*  3 / 16 */
  nop           /*  4 / 16 */
  nop           /*  5 / 16 */
  nop           /*  6 / 16 */
  nop           /*  7 / 16 */
  nop           /*  8 / 16 */
  nop           /*  9 / 16 */
  nop           /* 10 / 16 */
  nop           /* 11 / 16 */
  nop           /* 12 / 16 */
  nop           /* 13 / 16 */
  nop           /* 14 / 16 */
  nop           /* 15 / 16 */
  nop           /* 16 / 16 */

.loop: 

  nop           /*  1 / 16 */
  nop           /*  2 / 16 */
  nop           /*  3 / 16 */
  nop           /*  4 / 16 */
  nop           /*  5 / 16 */
  nop           /*  6 / 16 */
  nop           /*  7 / 16 */
  nop           /*  8 / 16 */
  nop           /*  9 / 16 */
  nop           /* 10 / 16 */
  nop           /* 11 / 16 */
  nop           /* 12 / 16 */
  nop           /* 13 / 16 */

  sub #1, w0    /* 14 / 16 */
  bra z, .end   /* 15 / 16 */
  bra .loop     /* 16 / 16 */

.end:

  nop           /* 16 / 16 */ /* Align to 16 cycles for when W0 is 0 */

However I can't really try this out at the moment, if somebody with a logic analyser or a PIC simulator or a PicKit and a spare board wants to get wild with this, that'd be awesome!

[agatti]

Oh, forgot to mention that for this to work interrupts need to be disabled beforehand and restored once finished (which is not much of an issue as the board is stuck in a busy loop when this code is ran).

[agatti]

Fixed with 4685d15.

[USBEprom]

Sorry to bother.
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.
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.
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.
I just built a new firmware for the BP revision 3 starting from the current repository and I noticed this.
Is there is a way to ensure that is the correct behavior?
Thanks.
I know this is already been closed, so I apologize for the hijacking, but in my opinion something is weird there.
Thank you.

News December 9, 2016:

I have digged further and by applying the fix #23 then I2CEEPROMWIN (source code here: http://web.archive.org/web/20150927140926/http://the-bus-pirate.googlecode.com/svn/trunk/scripts/I2CEEPROMWIN.c) does not work any more, it read wrong (all values are 0x01 does not matter what).

[agatti]

The changes applied for #23 were supposed to fix 1-Wire, where the delays are grossly miscalculated and causing the protocol to simply operate out of spec. I wonder why I2C stops working since the two calls to bp_delay_us in i2c.c are commented out...

Would it be possible to get some logic analyser dumps / screenshots / etc. for before and after 4685d15 got applied? The problem may be somewhere else, but I'll see if there was something obvious I missed that triggered this.

Thanks for reporting!

[USBEprom]

@agatti

Sorry for the late reply.
Sadly I know nothing about why I2C stops working while the patch #23 is applied.
However the usual friend of mine did some shots that I have not any analyzer or oscilloscope.
Based 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.
By 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.
New speeds are lower than before, this is for sure.
For 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.
The logs of the two readings are here as attachment.
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.
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.

PATCH #23 read.txt

NO PATCH #23 read.txt

[agatti]

@USBEprom Can you please to try changing the value of FCY in base.h to see if things improve? I'm not sure if v3 runs at the same frequency as v4.

Is v3 supposed to run at 16MHz too?

[USBEprom]

@agatti

Unfortunately inside of base.h I can not find the word FCY, where it should be?
I know I am pretty babo, so sorry please.
However based on this:

http://dangerousprototypes.com/docs/index.php?title=BPv3_FTDI_UART_demo&oldid=16133

It is stated that "The Bus Pirate uses an 8 MHz internal clock multiplied by a 4x PLL to produce a 32 MHz CPU clock" and when I have calculated the prescalers for the new speeds into the menu of SPI I have used the 16MHz value.
It is likely that FCY is 16MHz also for the Bus Pirate revision 3.
Here:

http://dangerousprototypes.com/forum/viewtopic.php?f=40&t=3864&start=15#p41505

it is said "The 16MHz SPI speed mode is not valid, the max SPI peripheral speed is 8MHz (10MHz slave)", ignoring the context (SPI) seems that also for the Bus Pirate v3 FCY is really 16MHz.
Here:

http://dangerousprototypes.com/forum/viewtopic.php?f=4&t=2262&p=22362#p22362

it is said "the bus pirate is running at Fosc 32MHz so Fcy becomes 16Mhz".
At this point I guess that 16MHz is exact as FCY also for the Bus Pirate revision 3.
Soon when I will understand where is the parameter FCY I will try to do some changes on it and then I will post the results.
See you later and thanks for your reply sir!

[agatti]

@USBEprom FCY is here: https://github.com/BusPirate/Bus_Pirate/blob/master/Firmware/base.h#L24

Now, the only difference I can see that might impact delays would be linking libpic30 together with the project. I'll see if I can just extract the delay function alone and see if that helps.

[USBEprom]

@agatti

OK, still you won while I lose being a total babo.
Of course you are right the parameter FCY is inside base.h as you have written, in the current repository though!
Yesterday I was looking for it inside the previous release of the Bus_Pirate-master, not the last one, so it is quite normal that I did not find it!
However today using the current repository I have built a test firmware for my Bus Pirate revision 3 where line 24 has been changed as "#define FCY 8000000UL".
It works exactly like the same firmware made leaving unaltered the content of the line number 24 inside the base.h (#define FCY 16000000UL).
The test firmware behaves just the same as the current released one, no difference.
The usual friend of mine took a couple of shots, here you go:

As it is possible to see the clock speed is still low compared the expected.
Is there nothing else I can do to help out?
Thank you sir.

[agatti]

@USBEprom can you please try to build this version and see if things change? The only difference is that libpic30 is not linked in anymore, but its delay function has been merged in anyway - as it allows for 1-Wire to function reliably.

fw_no_libpic30.zip

[USBEprom]

@agatti

Unfortunately nothing happens.
I have just built a new test firmware starting from your fw_no_libpic30.zip but the speed of the clock for the I2C protocol is still wrong, too low compared to what is expected.
As your reference here you go a couple of shots:

Thank you very much for your support sir.

[agatti]

@USBEprom I think I found the problem... Can you please give this version a try? It theoretically should fix the extra delay issue on I2C, but I cannot really test things at the moment.

firmware-delay-fix.zip

[USBEprom]

@agatti

Before all merry Christmas to you and thanks a lot for your hard work.
Unfortunately nothing happened.
I have just built a new test firmware starting from your firmware-delay-fix.zip but the speed of the clock for the I2C protocol is still wrong, too low compared to what is expected.
As your reference here you go a couple of shots:

I am really sorry that you alone have to take all this trouble also spending your holidays by working, as I understand that fixing the problem is really very, very hard.
Basically you alone are doing the work of hundreds of thousands of people.
Thank you sir.

[agatti]

@USBEprom thanks for trying that out. I'll do some more test on my end with some sample circuits (I only have SPI devices to test with at the moment) and hopefully see what can be done.
However we've been delaying v7.1 for quite some time now, so there might be chances that we will release said version with that I2C issue in. Still, we'll look into this and try our best to fix this issue, hopefully we'll be able to sort it out in time.

[USBEprom]

@agatti

I agree with you.
In the end the firmware v7.0 was conceived basically for the Bus Pirate revision 4, good for its possible compatibility with previous revision 3.
I deal either with SPI and I2C so until the issue will not fixed I will still use the firmware that I built myself based on the previous repository which it has not the patch #23:

dangerousprototypes.com/forum/download/file.php?id=12196

Thank you very much sir.

[agatti]

@USBEprom which mode did you use for I2C? Hardware or software?

For software I2C I do get ~700Hz on SCL:

For hardware I2C I get ~500kHz on SCL:

Both of those using the maximum speed available.

[agatti]

@USBEprom I tried with the very latest version, just rebuilt and installed and I get ~100kHz in software mode:

I have the feeling that I hit a v3-only issue I don't have a board to test with...

[agatti]

@USBEprom Can you please try this firmware, just to be sure? This is the last version that does not have the bug #23 fix. On a v4, in software mode I have around 111kHz on SCL, which is slower than what I get after I applied the fix.

Please try this one in software and hardware modes if possible, thank you!

fw_before_patch23.zip

[agatti]

Oh ok, I thought you were relying on TIMER1 asynchronously, my bad.

For 1-Wire, a quick and dirty way to test things up is to hook up a logic analyser with the software of your choice - as long as it can decode 1-Wire - and use https://gitea.youb.fr/youen/OneWireArduinoSlave on any Arduino board you have laying around. That's how I debugged things back then before I stumbled upon a proper 1-Wire device.

[ChristopherSamSoon]

@agatti
Thank you for the proposal of using Arduino, I will see what I can do to test 1-wire

Best

Christopher

[USBEprom]

@ChristopherSamSoon

Thank you very much sir for having spent time on fixing this!
I will built a test firmware for the Bus Pirate v3 starting from your repository https://github.com/ChristopherSamSoon/Bus_Pirate and I let you know the result as soon as possible.
About #111 and #112 me too I hope are gone together this #23, however I will test them all and I let you know as soon as possible.

@agatti

As for you suggestion I will surely test 1-WIRE protocol too.
About that kind of protocol I have doubt it is working though, because I have a DS1990A iButtons and I did not able to use it with firmware v7.x.
Maybe it is me, maybe it is something wrong I did, though I have not tried yet using old firmware as comparison.
However thank you a lot sir for having provided a new different way to test it if functioning or not, that is great useful.
I will test the whole thing and I let you know as soon as possible.

[USBEprom]

@ChristopherSamSoon

thank you very much sir for your invaluable code!

@ALL
Really sorry for the delay.
Finally I was able to build a test firmware starting from the latest repository dated 04 November, 2018 released by Christopher Sam Soon (https://github.com/ChristopherSamSoon/Bus_Pirate).
For testing I built both SAFE (only I2C software) that UNSAFE (freed I2C hardware) firmwares and as promised here in attachment are the results.
For me all it works fine, however I will continue the tests in order to assure there are not any sort of problem somewhere and then I will let you know.

About #111 and #112 I must write that I am not 100% sure it totally works now because I tested them in an unorthodox manner.
Surely the things ar better with the new code and for 2-WIRE ~5kHz, ~50kHz, ~100kHz and ~400kHz are the same as for the I2C software protocol, though for 3-WIRE too it is for ~5kHz and ~50kHz as for I2C, but ~100kHz and ~400kHz are respectively ~80kHz and ~170kHz.
I tested the 2-WIRE and 3-WIRE behaviour simply entering in the protocol and sending 1hex while connected to the same Arduino on which was running the I2C sketch provided by agatti and then acquiring the traffic with the logic analyzer setted for I2C decoding.
Maybe that did the result, maybe did not, but I do not know other way to test the matter.
However I would dare to say that even #111 and #112 have now gone.

Please pay attention to the fact that orange color for the caption about ~400kHz SOFTWARE mode does not mean it is working bad, simply that does not match the value into the menu.
Christopher Sam Soon has already explained there is a speed limit there so it may even be useful to change the value in the menu from ~400kHz to ~220kHz hence it would be full green as color.

[USBEprom]

For 1-Wire, a quick and dirty way to test things up is to hook up a logic analyser with the software of your choice - as long as it can decode 1-Wire - and use https://gitea.youb.fr/youen/OneWireArduinoSlave on any Arduino board you have laying around. That's how I debugged things back then before I stumbled upon a proper 1-Wire device.

@agatti
Sorry to keep bothering you.
Seems to me that library does not work with MEGA 2560 because some incompatibility with the utility LowLevel.h I guess due of these:

\libraries\OneWireSlave\src/utility/LowLevel.h: In member function 'void Pin::attachInterrupt(void (*)(), int)':

\libraries\OneWireSlave\src/utility/LowLevel.h:157:3: error: 'CLEARINTERRUPT' was not declared in this scope

CLEARINTERRUPT; // clear any pending interrupt (we want to call the handler only for interrupts happening after it is attached)

^

I wonder if it possible to fix the issue or otherwise use something else to check 1-WIRE protocol.
Library and sketch are compiled without problems for Arduino/Genuino UNO but by changing target as for Arduino MEGA 2560 them fail with the erros I wrote and sadly I own only the latter.
The only change I made to the original sketch was to change the interrupt pin from 2 to 20 due to the fact that the pin numbering on the MEGA 2560 is different from that of the UNO.

And another thing if possible.
What on how connect together Bus Pirate and Arduino?
I am scared to damage Arduino and/or Bus Pirate due wrong connections because each of them provides its own +5V.
I guess it is need to connect the ground on the Bus Pirate to the one on the Arduino, then MOSI on the Bus Pirate which is the pins responsible for 1-WIRE protocol on it to an interrupt pin on the Arduino (I chose pin 20 of the Arduino MEGA 2560 which is labeled as interrupt 1 [INT1] so that I have really used it on the sketch).
I do not sure for the VPU and pull-up resistor, though.
Should I jumpering + 5V with VPU and activate power supply and pull-up resistors (command W and P on the Bus Pirate side) or is it enough to activate the pull-up resistors by issuing the P command without turning on the power supply with the command W due the fact the +5V is already provided by the Arduino for the simulation?
Thanks.

[agatti]

@USBEprom I used an Arduino Nano for this, even if I had the time to look into this I do not have neither a Uno nor a Mega 2560 I'm afraid. For connections, if you connect the two GND pins together and MOSI and 1-Wire together as well, that should be it - if both devices are using 5v logic levels (that's important!) for data transmission it shouldn't damage anything. At most it won't detect any data coming in or out - it's the same principle that applies for UART to USB adapters, for example...

[USBEprom]

@agatti

Please do not worry sir.
So for now I will try with iButton I own, although I already did without result.
First I will test the thing with old firmwares in order to try to understand where is the problem.
Thanks a lot sir!

[agatti]

I added @ChristopherSamSoon's delay code to the main branch - it is currently enabled by default, but can be switched off by undefining BP_USE_HARDWARE_DELAY_TIMER in configuration.h.

[USBEprom]

I just built new firmwares SAFE and UNSAFE starting from this repository (https://github.com/BusPirate/Bus_Pirate/archive/master.zip) where you have merged the code provided by Christopher Sam Soon (https://github.com/ChristopherSamSoon/Bus_Pirate) and for me it works with Bus Pirate v3.
Thank you sir and thanks to Christopher Sam Soon too!:

http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=120

[ChristopherSamSoon]

I just built new firmwares SAFE and UNSAFE starting from this repository (https://github.com/BusPirate/Bus_Pirate/archive/master.zip) where you have merged the code provided by Christopher Sam Soon (https://github.com/ChristopherSamSoon/Bus_Pirate) and for me it works with Bus Pirate v3.
Thank you sir and thanks to Christopher Sam Soon too!:

http://dangerousprototypes.com/forum/viewtopic.php?f=28&t=8498&start=120

No problem, I am glad to contribute to the community.

Lest us know of your results for 1-WIRE together with the iButton. I tried to lookout for my Arduino but could not get hold on it yet.

[USBEprom]

@ChristopherSamSoon

Surely, I am already at work on that.
Thanks again sir.

[USBEprom]

Ok, in the end I managed to test the functioning of the 1-WIRE protocol on the Pirate v3 Bus using the firmwares that I got from the current repository and therefore updated, concluding that everything works as expected.
For the tests I have followed the suggestion of agatti and I used an Arduino MEGA 2560 card borrowed from the usual friend of mine where was running a 1-WIRE SLAVE library.
Very sadly I have not in any way been able to test the 1-WIRE protocol with a real device, because despite all the attempts I made I could not read the iButton DS1990A-F5 I own.
I tried hard, I also purchased a real iButton socket probe reader provided with suppressor but no joy.
Maybe my DS1990A-F5 has something bad, even if it is weird because it is fully working using other than Bus Pirate, I do not know why it does not work with my Bus Pirate v3 which has the 2000ohm R20 pull-up resistor.
I would have liked to verify the 1-WIRE protocol with a real and not simulated device but in the end I had to resign myself to perform tests on devices emulated with Arduino.
The library that I used is here:

https://github.com/orgua/OneWireHub

It is the only one I could find that works with the Arduino MEGA 2560 board.
Among the other supported devices, the above library also manages the families DS1990, DS1990A and DS2401, so in the end, although only in emulation mode, I could virtually test the 1-WIRE protocol with the iButton DS1990A, because with the real one I own I have not succeeded.

For what I could see everything works correctly, even if I noticed a weirdness and could in my opinion be introduced some improvements.

The weirdness I noticed is that while performing MACRO (1-50) which show the 8-byte ROM identifier of the device placed on the specific address chose, then the resulting final message does not match to the device on which the query was made.

So for instance while querying for device 3 on the 1-WIRE bus by performing MACRO (3):

1-WIRE>(3)

Then the response show the device numbered as n+1, or 4 rather than 3 as actually it should be in this case:

ADDRESS MACRO 4: 0x81 0x00 0xA0 0x90 0x19 0xDA 0x00 0x03

I guess this behavior could be related to the fact that the numbering does not start from 0 because that is the purpose of MACRO (0) that on the Bus Pirate show the list of available macros, do not the 8-byte ROM of the device number 0 on the 1-WIRE bus, though I can very well be wrong.

The possible improvement that I thought is tied with the item Overdrive (~160kps) into the menu as available choice.
I would have liked to check this too but sadly I could not because if I have not misunderstood to enable Overdrive (~160kps) on the 1-WIRE devices that allow for it, not all 1-WIRE slaves support Overdrive (~160kps), it is need to send 0x69 (Overdrive Match ROM command) in normal speed followed by the 8-byte ROM identifier in overdrive speed or by sending 0x3c (Overdrive Skip ROM command) in normal speed.
This one immediately puts all overdrive capable slaves on the bus into overdrive mode.
Once a slave is in overdrive mode, all subsequent communication must take place at overdrive speed.
(http://forum.arduino.cc/index.php?topic=201776.msg1486950#msg1486950)
The Bus Pirate provide Overdrive (~160kps) support (07c8be9) but actually it can not use it because in order to do so would need to go from Standard (~16.3kbps) to Overdrive (~160kps) and the other way around, keeping active pull-ups and power supply, which is not currently allowed.
In fact, once one of the two items has been set, Standard (~16.3kbps) or Overdrive (~160kps), to change it it is need to return to the menu with the "m" command, thus immediately making the power supply and the pull-up resistors are deactivated, therefore there is in no way possible to initialize the slave devices that support it in the Overdrive mode (~160kps).
Even using externally powered external pull-up resistors it does not improve the thing, especially when working with emulated 1-WIRE slave devices, as this could result in the risk of damaging the Arduino board and or the Bus Pirate itself, although I believe that this last should have more chance to survive than the Arduino board, however I would like to avoid experiments in that direction.
In my opinion the correct and most elegant solution would be to be able to switch from Standard (~16.3kbps) to Overdrive (~160kps) and the other way around without contextually deactivating power supply and pull-up resistors on the Bus Pirate side.
I do not know if this is possible or not, even if it can be recommended, it is only a thought of mine that I want to share.

[USBEprom]

Ok, in the end I managed to test Overdrive (~160kps) on 1-WIRE protocol with the Bus Pirate v3 despite as it is now Bus Pirate v3 can not natively switch from standard to overdrive speed without turning off power supply and pull-up resistors so that the 1-WIRE slave device is indesirably deselected (#117 and 07c8be9).
In order to reach the goal I had to manually operate 3 switches and add 2 diodes type 1N4148 and one 2,2kohm resistor as in the attached picture.

Since the above diagram is used to execute the I2C_ARDUINO_TEST procedure provided by agatti
I have also kept it for the OneWireHub-2.2.1 library by simply setting to 20 the 1-WIRE pin (pin_onewire {20};) that is among the valid interrupt pins for the Arduino MEGA 2560 board.
In this way I can do testing on both I2C and 1-WIRE protocols with no need to change connections and by only switch from an Arduino sketch to another.
This is why there are the SCL and the SDA names on the diagram although I am talking about 1-WIRE protocol.

The target 1-WIRE slave was a DS2506 64Kb Add-Only Memory simulated by an Arduino MEGA 2560 running the OneWireHub-2.2.1 library (https://github.com/orgua/OneWireHub) where in "OneWireHub_config.h" the overdrive support for the slaves was enabled #define OVERDRIVE_ENABLE 1 // support overdrive for the slaves.
In order to operate safety for Bus Pirate v3 and Arduino MEGA 2560 I did as follow.
First.
With the connections shown above I have set up:

a) SWITCH 3 = OPEN

b) SWITCH 2 = CLOSE

c) SWITCH 1 = CLOSE

Once did so I started the Bus Pirate v3 for 1-WIRE protocol and Standard (~16.3kbps) speed, ending turning on the power supplies with command "W" and pull-up resistors with command "P".
After this I queried the Arduino MEGA 2560 with macro (51) and (240) in order to be sure all was right.
Having verified this, I gave the command {0x3c r: 8 from the Bus Pirate v3.
As explained here in http://forum.arduino.cc/index.php?topic=201776.msg1486950#msg1486950, 0x3c (Overdrive Skip ROM command) immediately puts all overdrive capable slaves on the bus into overdrive mode.
Once a slave is in overdrive mode, all subsequent communication must take place at overdrive speed, so I did this:

a) SWITCH 2 = OPEN

b) SWITCH 3 = CLOSE

c) SWITCH 1 = OPEN

Then I reset the Bus Pirate v3 with command "#" and restarted it for 1-WIRE protocol this time choosing the Overdrive (~160kps) speed and ending turning on the power supplies with command "W" and pull-up resistors with command "P".
At this point I moved switches as follow:

a) SWITCH 1 = CLOSE

b) SWITCH 3 = OPEN

c) SWITCH 2 = CLOSE

And I started to query the simulated DS2506 from the Bus Pirate v3.
Bingo!, that did the trick and everything worked as expected!
So I could send commands and capture and decode the data traffic on the bus with the logic analyzer.
In this way I was able to measure about ~90kHz for the clock speed of the data traffic.

The whole thing was 100% functioning even because I had to set the decoder of the logic analyzer to "Overdrive" because otherwise I could not decode anything.
For what I can see all is good and nothing is wrong with 1-WIRE protocol on Bus Pirate v3 with firmware v7.x.
Very, very well!
All this shows that the recently added and remodeled code works well without introducing any problems whatsoever.

@ChristopherSamSoon

Many, many thanks sir!

[ChristopherSamSoon]

@USBEprom

Thank you for providing the detailed test results for 1Wire mode.

Let us aim to close this issue by end 2018!

Best

Christopher

[USBEprom]

@ChristopherSamSoon

That would be really great, sir!

[USBEprom]

@ ALL

Maybe I am wrong, but it seems to me that also 1-WIRE protocol uses the "blocking" way described here #18, especially when the clock speed is high as in the case of Overdrive (~160kps), or rather the whole thing is more evident with high speeds.
This time the usual friend of mine took a few screenshots while running ols-0.9.8 from jawi (J.W. Janssen) with the Open Bench Logic Sniffer.

Open Bench Logic Sniffer has confirmed the results obtained with the previous logic analyzer.
The client software provided by jawi is much more powerful, eclectic and versatile than that for the other logic analyzer and allows you to go into details otherwise difficult to guess

[ChristopherSamSoon]

@ ALL

Maybe I am wrong, but it seems to me that also 1-WIRE protocol uses the "blocking" way described here #18, especially when the clock speed is high as in the case of Overdrive (~160kps), or rather the whole thing is more evident with high speeds.
This time the usual friend of mine took a few screenshots while running ols-0.9.8 from jawi (J.W. Janssen) with the Open Bench Logic Sniffer.

Open Bench Logic Sniffer has confirmed the results obtained with the previous logic analyzer.
The client software provided by jawi is much more powerful, eclectic and versatile than that for the other logic analyzer and allows you to go into details otherwise difficult to guess

You may be correct. I would not be surprised if the root-cause of this behaviour is the same as #18. Anyways, this problem is not because of bp_delay_us() (This issue here), but because of "blocking" printout to UART during 1WIRE transmission (possibly other protocols as well)

[AreYouLoco]

Is there anything that can be done with this issue?
I am trying to use flashrom with 7.1 community firmware and I bumped on this bug.