Force overdrive from the start.

[USBEprom]

Sorry to bothering. No sure this is the right place, anyway I try to ask while apologizing for the maybe crazy question. In order to do some tests on a hardware device called Bus Pirate (http://dangerousprototypes.com/docs/Bus_Pirate) I am using this great and useful library with an Arduino MEGA 2560. I came across the need to verify the operation of the 1-WIRE protocol in overdrive mode (https://github.com/BusPirate/Bus_Pirate/issues/23) so here it is the point, it would be possible to set up library and skecth to force overdrive operation? I mean modify things so that Arduino work out of the box as slave 1-WIRE device initialized and ready for overdrive communications, so that it is possible to query it at overdrive speed with no need to before switch parameters from standard to overdrive speed. A native, ready to use 1-WIRE environment would be a great help in debugging. By changing in OneWireHub_config.h

define OVERDRIVE_ENABLE 0

to

define OVERDRIVE_ENABLE 1

it is possible to enable overdrive, but how to force it as native? (of course if it is possible). Thanks.

Be seeing you.

U.Sb

[mpeg71]

If you are ready with your tool I am very much interested

Von meinem iPhone gesendet

Am 10.11.2018 um 22:24 schrieb USBEprom notifications@github.com:

Sorry to bothering. No sure this is the right place, anyway I try to ask while apologizing for the maybe crazy question. In order to do some tests on a hardware device called Bus Pirate (http://dangerousprototypes.com/docs/Bus_Pirate) I am using this great and useful library with an Arduino MEGA 2560. I came across the need to verify the operation of the 1-WIRE protocol in overdrive mode (BusPirate/Bus_Pirate#23) so here it is the point, it would be possible to set up library and skecth to force overdrive operation? I mean modify things so that Arduino work out of the box as slave 1-WIRE device initialized and ready for overdrive communications, so that it is possible to query it at overdrive speed with no need to before switch parameters from standard to overdrive speed. A native, ready to use 1-WIRE environment would be a great help in debugging. By changing in OneWireHub_config.h

define OVERDRIVE_ENABLE 0

to

define OVERDRIVE_ENABLE 1

it is possible to enable overdrive, but how to force it as native? (of course if it is possible). Thanks.

Be seeing you.

U.Sb

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[USBEprom]

Ready I am ready, but how should I proceed to reach the goal? Thanks.

[mpeg71]

Which chip do you emulate with arduino? DS2505?

Von meinem iPhone gesendet

Am 11.11.2018 um 11:37 schrieb USBEprom notifications@github.com:

Ready I am ready, but how should I proceed to reach the goal? Thanks.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[USBEprom]

As the emulation of all the devices listed as supported in the library work with Arduino MEGA 2560, for me it makes no difference which chip to use. The DS2505 / DS2506 suits me, just like any other else that supports overdrive. The main purpose of all this is to verify communication and timing. Many thanks.

[kutukvpavel]

IIRC, master selects operation mode by issuing different commands for overdrive and non-overdrive requests (that's why both overdrive-capable devices and ordinary devices can operate on the same bus). So that's not OneWireHub's responsibility to enforce overdrive (it just supports it), that's your master's responsibility to do so.

[USBEprom]

@kutukvpavel

Ok, I agree. That is for sure. I need the thing in order to test a device on which right now it is not easy to switch from normal to overdrive speed. Because we are talking about to emulate 1-WIRE devices with Arduino I thought would be some way possible emulate one of them like it was waiting in idle state already switched ready for overdrive speed. That is. I said if this were possible and worth it, otherwise I will live with that by using real physical components for the tests, although at the moment with the device still there are problems in handling the thing, because the master device that I am debugging does not allow easily to switch from standard to overdrive speed and the other way around.

[kutukvpavel]

Well, in terms of normal 1-wire communication, without "temporary debug hacks", what you want is to send overdrive command 0x3C (overdrive skip ROM) prior to any other ROM-unrelated command for all overdrive-capable devices to transmit next command response using overdrive speed. If you are unable to configure your master, or create a custom master for testing (which only requires 1 extra generic arduino board and 5 minutes of time), you can either manually inject 0x3C into the bus using some device (Bus Pirate probably?); or you can change some OneWireHub code so that your emulated device always (or not, if you modify library code you can create pretty much anything you want) responds using overdrive. Such changes by no means comply 1-wire standard and thus can be only called "dirty temporary debug hack". Just in case: your master will not be able to receive responses because it won't know that overdrive has been enabled, because it did not issue 0x3C, of course. Most likely master will see just garbage. But if you don't care about your master, this is probably OK (are you actually trying to debug Bus Pirate? I would definitely create a custom master-duino [that will only send pre-programmed command sequence] for such purposes, it's a much better approach by all means).

P.S. A quick look at OneWireHub.cpp suggests that you want to set od_mode = true upon receiving commands you are interested in. Then the hub should respond using overdrive to them anyway. Probably just add od_mode = true; to all the cases you are interested in (inside switch that is inside recvAndProcessCmd())) and see what happens. PPS.: Not-so-quick look at the code revealed the following. As for slave's responses, od_mode takes effect only inside sendBit() routine: therefore it only affects timings used for sending bits. You can just hard-code od_mode to be 1 inside that function and enjoy your overdrive responses to a non-overdrive master (which is what you wanted I suppose).

[USBEprom]

Well, in terms of normal 1-wire communication, without "temporary debug hacks", what you want is to send overdrive command 0x3C (overdrive skip ROM) prior to any other ROM-unrelated command for all overdrive-capable devices to transmit next command response using overdrive speed.

I know that.

If you are unable to configure your master, or create a custom master for testing

Yes, it is just so.

(which only requires 1 extra generic arduino board and 5 minutes of time),

I do not own any Arduino boards, the MEGA 2560 I have available has been loaned to me by a friend of mine.

you can either manually inject 0x3C into the bus using some device (Bus Pirate probably?);

Yes I have a Bus Pirate on which I want to check timing in 1-WIRE protocol, but I can not do in that way you wrote because for what it is now the firmware of the Bus Pirate it is not possible to switch from standard to overdrive speed and the other way around.

or you can change some OneWireHub code so that your emulated device always (or not, if you modify library code you can create pretty much anything you want) responds using overdrive.

I do not have Arduino for myself, hence of course I have no skill on that matter.

Such changes by no means comply 1-wire standard and thus can be only called "dirty temporary debug hack". Just in case: your master will not be able to receive responses because it won't know that overdrive has been enabled, because it did not issue 0x3C, of course. Most likely master will see just garbage. But if you don't care about your master, this is probably OK (are you actually trying to debug Bus Pirate? I would definitely create a custom master-duino [that will only send pre-programmed command sequence] for such purposes, it's a much better approach by all means).

Yes, I am actually trying to debug Bus Pirate, so I do not need more than one Arduino that acts as slave.

P.S. A quick look at OneWireHub.cpp suggests that you want to set od_mode = true upon receiving commands you are interested in. Then the hub should respond using overdrive to them anyway. Probably just add od_mode = true; to all the cases you are interested in (inside switch that is inside recvAndProcessCmd())) and see what happens.

I tried so and it does not work for me.

PPS.: Not-so-quick look at the code revealed the following. As for slave's responses, od_mode takes effect only inside sendBit() routine: therefore it only affects timings used for sending bits. You can just hard-code od_mode to be 1 inside that function and enjoy your overdrive responses to a non-overdrive master (which is what you wanted I suppose).

Too complex for me. At this point I will buy real chips. The fact is that until now I was able to retrieve a 2560 board by borrowing it from a friend of mine, I do not have any other, nor electroinc components such as resistors for additional pull-ups or other, so I wanted try to see if in some way it was possible to reach the goal I wrote in the beginning. Really sorry to have stolen time from you and others, for me the request can be considered closed. Thank you sirs.

[USBEprom]

Hi guys. For information 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 (https://github.com/BusPirate/Bus_Pirate/issues/117 and https://github.com/BusPirate/Bus_Pirate/commit/07c8be981fac9cfc633195c55959ca4c968ba4e1). 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 (pinonewire {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 where in "_OneWireHubconfig.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! (https://github.com/BusPirate/Bus_Pirate/issues/23) So I could send commands and capture and decode the data traffic on the bus with the logic analyzer. Your awesome library works like a charm and it was really useful to reach the set goal. It is really priceless. One last thing, if I can. Actually it seems that even as it is now the library it is natively able to do what I asked in the beginning with no need to change anything. The only thing necessary to do is to write the right chip.cpp and chip.h. Infact some device already work natively for the overdrive speed, for instance DS28E15 (https://www.earth.li/~noodles/blog/2017/01/1wire.html), so in the end it is enough just write something like DS28E15.cpp and DS28E15.h. Doing so fulfill my request I did by starting this issue. Still really sorry to have stolen time from all you. I repeat it, for me the request can be considered closed. Thanks a lot sirs.