Hi, I found one example device not supporting the 'network layer' is DS1821, so it makes sense to split the PD into the link and network layer. I will duplicate the related overdrive code, and use the overdrive decoder option to disable overdrive detection by the protocol. This way all devices should be somehow covered.
Regards, Iztok Jeras On Wed, Jul 4, 2012 at 10:16 PM, Iztok Jeras <[email protected]> wrote: > Hi Uwe, > > Comments are inline. > > Regards, Iztok Jeras > > On Wed, Jul 4, 2012 at 2:20 AM, Uwe Hermann <[email protected]> wrote: >> Hi, >> >> On Tue, Jul 03, 2012 at 12:33:17AM +0200, Iztok Jeras wrote: >>> The 1-Wire protocol decoder should be almost ready now, this week I >>> will add some more dumps and test the decoder with them. The code is >>> ready for a first review, next issues remain: >> >> Thanks, merged for now with a few minor changes and quite a bunch of >> rebasing and git fixups, though. >> > I will have a look at what you did with GIT and follow your recommendations. >> >>> 1. Annotations: >>> Currently there are 3 annotation options, for three protocol layers >>> (link, network, transport), but this separation does not work well >>> with sigrok, since the display of annotations should overlap. I will >>> probably update this after running through some more example dumps. >> >> This should change anyway, as there is a clear layer system in this >> protocol(stack), we certainly want one protocol decoder per layer >> (at least) and then stack them. >> > I would make sense to separate the link and network layer of the > protocol. This might also improve the decoder performance, since the > network layer code would be called less frequently. But there is a big > issue, the overdrive mode is decoded in the Network layer and it > affects the link layer. You can think of it as two UART devices > negotiating a baudrate change. >> In this case, something like this would probably make sense (example): >> >> onewire_link -> onewire_network -> ds18s20 >> >> As you mention below the transport layer (and possibly others) can be >> device-specific. In those cases a generic decoder should only do generic >> decoding, all device-specific knowledge and decoding should happen in >> a respective decoder for that device. >> >> Example: We certainly want a 'ds18s20' decoder, which takes (I guess) >> onewire_network as input, which in turn takes onewire_link as input, >> which in turn has raw signal values as input. >> >> Whether or not a 'onewire_transport' PD makes sense, depends on how much >> non-device-specific stuff would be in there, need to look into the spec >> and some datasheets to check. >> > Separating the device specific transport layer from the network layer > is not such an obvious choice. The main reason is that 1-Wire supports > multiple slaves on the same bus and each slave can be identified by > its ID and SERIAL NUMBER (known from the Network layer, except if SKIP > ROM command is issued). So if there are separate decoders on the > transport layer, this means that only one decoder can be used and only > one device can be decoded at the same time. > My idea was to create a Python class containing all the shared > transport layer code, and then create sub-classes for each device ID. > The decoder is already able to create a list of all devices on the > bus, so for each ID+SERIAL an instance of the appropriate device class > could be made, holding the device state. > Writing this classes would be a much larger effort than the code for > the link and network layers, and I expect it would require recoding it > a few times before the architecture would make sense. >> >>> 2. Overdrive support: >>> Overdrive support was not tested yet, although all the needed code >>> should be present. >> >> Sounds good, haven't tested anything though. >> >> I think I might have some 1-Wire devices here, will try to make a few >> additional dumps for the repo, so you have some more files to test >> against. >> > I received a Saleae Logic device, but for now I run it using the > original software. So I should have less trouble generating new dumps. > Overdrive might be a problem. I have to ask OWFS developers how to > persuade the tool to use the overdrive mode. Otherwise I have another > onewire implementation on an FPGA, but it will take me some time to > recompile the code and to get all the tools and hardware ready. >> >>> 3. Transport layer: >>> The transport layer is very device specific although there are some >>> common aspects. For now I decided not to decode this protocol layer >>> and to only display transported data bytes. I think this is good >>> enough for the first release. >> >> Yup. But see above for plans for later versions. >> > I checked today what the 1-Wire decoder from the Saleae Logic software > does and it seems they cover the same amount of protocol as I do. >> >>> 4. White space: >>> I have my own preferences regarding white space, I prefer long lines >>> with vertically aligned keywords. Could you please apply the preferred >>> formatting to the source while merging it? >> >> I'll have a run over the code and fix various issues, both functional >> and coding-style/whitespace, just let me know when I should >> do it -- before or after we split the PD into multiple ones? >> >> Also, do you want to do the splitting, or should I give it a go? >> > Since there is no obvious way to split the protocol, I think this > needs some more discussing. > I also think there are some third party 1-Wire devices that only > support the link layer, so this would be another reason to have a > separate link layer. It might make sense to have the code related to > overdrive in both the link and network decoder. This would be a small > duplication, and it would enable separation of layers into separate > decoders. What do you think? >> >>> sigrok-dump GIT is here (master branch): >>> https://github.com/jeras/sigrok-dump >>> The Verilog dump generators, and Tektronix text dumps with the >>> converter were deleted from GIT, but remain in the history. >> >> Thanks, I picked and merged the files themselves for now (without >> history). If you really want the scripts etc. to be in sigrok-dumps >> (not sure if that is really relevant there, though), feel free to post >> another patch which adds them to a onewire/owfs/scripts subdir or so. >> Otherwise, I suggest you put them in an extra 'my_vhdl_stuff' or such >> repo on your github account, as it's technically not really >> sigrok-related. >> > There is no real need to have the scripts in the release, I will keep > them on GitHub. >> >> Thanks for your continued work on this PD! >> >> Cheers, Uwe. >> -- >> http://hermann-uwe.de | http://sigrok.org >> http://randomprojects.org | http://unmaintained-free-software.org ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
