Hey, I just uploaded a new version in there, I added an import feature, which right now imports files from Jawi's client. I needed that in order to load your samples.
I have some bad news and some good news. The good news is that I made a microwire parser and it's working properly I think. The bad news is that it's not telling you what kind of operation it is, because I noticed that different devices have different opcodes.
Edit: On the other hand, I don't think it's going to be an issue to remember the bit codes for the few opcodes this chips are supporting (most of them only having 2 bit opcodes).
I might add an option in the future that displays data related to common protocols on top of microwire.http://dumb.ro/lafront/microwire.png
this is your sample data.
Edit2: If you really want it to tell you what the opcodes mean, you can edit the parser yourself:
Tools -> Protocol Manager. Select the uWire protocol, hit Develop and then in the new dialog hit Edit (it will ask you to pick an editor).
The parsers are written in JS so it shouldn't be too hard to modify them (sorry there are no docs yet on the API, but you'll probably figure out fast what it all means). Also sorry if it's missing comments or if it's not as clear as it should be, I kinda rushed it.
Edit3: Let me know if, while looking into microwire, you stumbled upon some documents that properly explain the protocol and the way it's normally used. For one, it wasn't very clear to me what the start condition is. It appears that microwire devices have a trigger on the rising edge of the clock line and that's when they check CS and DI, if they're both high, it gets activated, so basically the trigger would be when all 3 lines are high (CS, DI and SK). Let me know if you think this is not the standard behavior or if you found some documents that might clarify the start condition.
What intrigues me is that in your examples, before any transfer begins, CS seems to be pulled low for a bit, just before releasing it back to a high state. However, that might be to ensure that the device gets reset to idle state, before starting a new transfer. Just to clarify, I'm not referring to the stop condition (which is low CS), but to the fact that it looks like the master is actually pulling CS low before pulling it high for the first time
, which doesn't seem to be necesary. My best guess is that it's doing it just in case, but it could also be part of the protocol and I'm not aware of it.