From: Iztok J. <izt...@gm...> - 2012-05-22 21:09:24
|
Hi, Let me introduce myself first. I am an ASIC developer (Verilog coder) from Ljubljana (Slovenia). A prof of my 1-Wire experience here is my 1-Wire master written in Verilog, with a port of the original Dallas Semiconductors software (everything was tested on a FPGA): https://github.com/jeras/sockit_owm Dumps: I have access to a logic analyzer at work, and I have a USB/UART based 1-Wire master, and the FPGA based master mentioned above. I also have several 1-Wire devices (thermometers, ADC, GPIO, memory). I can create some dumps, but I need some help with the conversion to *.sr files, since I do not have access to a sigrok compatible device. Currently I have created some binary files (using Verilog simulation), I can probably also export from the logic analyzer into binary (I have not tried yet). Currently I use the next command line: $ sigrok-cli -i onewire.bin -I binary -p 1=OWR -o onewire.sr The problem with the output file is that it is missing a sample rate. How could I specify it? https://github.com/jeras/sigrok-dump/tree/master/onewire/verilog Protocol decoder: I started writing the protocol decoder. https://github.com/jeras/sigrok/tree/master/libsigrokdecode/decoders/onewire But I have issues debugging it. Currently I run configure, "make" and "sudo make install". I was able to run the decoder, but the given error did not help much. How do you debug this decoders (while developing them)? I would like to see the Python error trace, if possible, and avoid installing. Regards, Iztok Jeras |
From: Uwe H. <uw...@he...> - 2012-05-22 23:35:37
|
Hi, and welcome :) On Tue, May 22, 2012 at 11:09:18PM +0200, Iztok Jeras wrote: > Dumps: > > I have access to a logic analyzer at work, and I have a USB/UART based > 1-Wire master, and the FPGA based master mentioned above. I also have > several 1-Wire devices (thermometers, ADC, GPIO, memory). I can create Yes, various dumps for all those devices would be great, each in an extra subdir in onewire/ in the sigrok-dumps repo, and each with a detailed README of which device it is, what traffic is going over the wire, which LA/samplerate/probes were used etc. etc. I've not merged your current sigrok-dumps stuff though, that also contains VHDL stuff and shell scripts etc. which are not relevant for the sigrok-dumps repo (should only contain .sr files and README). Feel free to make another branch/clone with just those *.sr/README files, we'll pull that in then. And/or I can manually commit your current .sr file, but then your name won't be in the git log. > some dumps, but I need some help with the conversion to *.sr files, > since I do not have access to a sigrok compatible device. Currently I > have created some binary files (using Verilog simulation), I can > probably also export from the logic analyzer into binary (I have not > tried yet). Currently I use the next command line: > $ sigrok-cli -i onewire.bin -I binary -p 1=OWR -o onewire.sr > The problem with the output file is that it is missing a sample rate. > How could I specify it? That's not possible at the moment, sorry. The 'binary' input module hardcodes 8 probes (and various other stuff) and has no samplerate. We'll need to add options for the input format so you can specify samplerate and other values, but that's not implemented, yet. > https://github.com/jeras/sigrok-dump/tree/master/onewire/verilog > > Protocol decoder: > > I started writing the protocol decoder. > https://github.com/jeras/sigrok/tree/master/libsigrokdecode/decoders/onewire Great, thanks! I've pulled in the decoder (after a "git rebase origin/master"). Please always try to keep your changed on top of the current master, if possible (not a big deal, though). If you continue working in your branch you probably need to "force-push" once now due to my rebase. And/or it's probably easier if you don't work in the "master" branch, but rather keep that at the current "upstream" state always. Instead, make another "onewire" (or whatever name) branch with your changed, probably makes things a bit easier. > But I have issues debugging it. Currently I run configure, "make" and > "sudo make install". I was able to run the decoder, but the given > error did not help much. How do you debug this decoders (while I've fixed a few smaller issues, but the main problem was that you used in some places %d instead of %s. The error is more useful now: srd: Calling decode() on all instances with starting sample number 0, 3480 bytes at 0x0x16d7f80 srd: Calling decode() on instance onewire with 3480 bytes starting at sample 0. srd: Protocol decoder instance onewire: Exception: Invalid lnk_state: WAIT FOR NEGEDGE You can use "-l 5" as option for sigrok-cli for maximum debug output. > developing them)? I would like to see the Python error trace, if > possible, and avoid installing. I usually just do 'make install' in libsigrokdecode, that doesn't take much time at all if you only change .py files. I have libsigrok installed in $HOME/sr (or some other temp. dir) and libsigrokdecode and sigrok-cli, too, and run it from there: ~/sr/bin/sigrok-cli -i onewire.sr -a onewire:owr=0 -l 5 (do "./configure --prefix=$HOME/sr ..." when installing the first time) Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
From: Bert V. <be...@bi...> - 2012-05-22 23:50:55
|
On 05/22/2012 11:09 PM, Iztok Jeras wrote: > $ sigrok-cli -i onewire.bin -I binary -p 1=OWR -o onewire.sr > The problem with the output file is that it is missing a sample rate. > How could I specify it? > https://github.com/jeras/sigrok-dump/tree/master/onewire/verilog As Uwe said, the binary input module needs to get some options for that, so imports can be a bit more flexible. As a temporary workaround, just edit the "metadata" file inside the .sr file (it's actually just a zip file). It's text, take a look at what's in some of the .sr files to see how you can specify samplerate. It all works fine without a specified samplerate as well, of course. > > Protocol decoder: > > I started writing the protocol decoder. > https://github.com/jeras/sigrok/tree/master/libsigrokdecode/decoders/onewire > But I have issues debugging it. Currently I run configure, "make" and > "sudo make install". I was able to run the decoder, but the given > error did not help much. How do you debug this decoders (while > developing them)? I would like to see the Python error trace, if > possible, and avoid installing. Note you can set the environment variable SIGROKDECODE_DIR to e.g. your development directory -- it will take precedence over any other module path. That way you can avoid doing "make install" all the time. Currently we're not doing a full traceback when an exception is raised in a python PD. The file/linenumber that it does show is *cough* not necessarily right, either. Definitely something that needs fixing :-) There is no debug path for PDs back into libsigrokdecode and from there to the frontend. I'm not so sure that it's worth doing... I just use print() and watch stdout. -- Bert Vermeulen be...@bi... email/xmpp |
From: Iztok J. <izt...@gm...> - 2012-06-23 11:37:21
|
Hi, I now have a few 1-Wire dumps ready, but the whole protocol (lower layers) is not yet covered, overdrive mode is missing. It will be hard to cover all the higher level protocol elements, I should be able to add some more dumps, once I understand the higher protocol layers better. I should be able to add more dumps in the next month, but if for some reason I postpone it too far, please just pick them from: https://github.com/jeras/sigrok-dump/tree/master/onewire/owfs I should finally have 3 days of time for implementing the decoder. There is is something that is not clear to me, how should I write the command line to get the output from a decoder to the console or into a file. Currently I use the highest verbosity. Also it would help if README in the dump directories would also explain (example command line) hot to use the decoder (if available) on each dump. Regards, Iztok Jeras On Wed, May 23, 2012 at 1:50 AM, Bert Vermeulen <be...@bi...> wrote: > On 05/22/2012 11:09 PM, Iztok Jeras wrote: > >> $ sigrok-cli -i onewire.bin -I binary -p 1=OWR -o onewire.sr >> The problem with the output file is that it is missing a sample rate. >> How could I specify it? >> https://github.com/jeras/sigrok-dump/tree/master/onewire/verilog > > As Uwe said, the binary input module needs to get some options for that, so > imports can be a bit more flexible. As a temporary workaround, just edit the > "metadata" file inside the .sr file (it's actually just a zip file). It's > text, take a look at what's in some of the .sr files to see how you can > specify samplerate. > > It all works fine without a specified samplerate as well, of course. > >> >> Protocol decoder: >> >> I started writing the protocol decoder. >> https://github.com/jeras/sigrok/tree/master/libsigrokdecode/decoders/onewire >> But I have issues debugging it. Currently I run configure, "make" and >> "sudo make install". I was able to run the decoder, but the given >> error did not help much. How do you debug this decoders (while >> developing them)? I would like to see the Python error trace, if >> possible, and avoid installing. > > Note you can set the environment variable SIGROKDECODE_DIR to e.g. your > development directory -- it will take precedence over any other module path. > That way you can avoid doing "make install" all the time. > > Currently we're not doing a full traceback when an exception is raised in a > python PD. The file/linenumber that it does show is *cough* not necessarily > right, either. Definitely something that needs fixing :-) > > There is no debug path for PDs back into libsigrokdecode and from there to > the frontend. I'm not so sure that it's worth doing... I just use print() > and watch stdout. > > > -- > Bert Vermeulen be...@bi... email/xmpp > > ------------------------------------------------------------------------------ > 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 > sig...@li... > https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Iztok J. <izt...@gm...> - 2012-06-24 12:19:39
|
Hi, I found the issue with missing annotations in my decoder. I should be able to remove the debug code now. Regards, Iztok Jeras On Sat, Jun 23, 2012 at 1:37 PM, Iztok Jeras <izt...@gm...> wrote: > Hi, > > I now have a few 1-Wire dumps ready, but the whole protocol (lower > layers) is not yet covered, overdrive mode is missing. It will be hard > to cover all the higher level protocol elements, I should be able to > add some more dumps, once I understand the higher protocol layers > better. I should be able to add more dumps in the next month, but if > for some reason I postpone it too far, please just pick them from: > https://github.com/jeras/sigrok-dump/tree/master/onewire/owfs > > I should finally have 3 days of time for implementing the decoder. > There is is something that is not clear to me, how should I write the > command line to get the output from a decoder to the console or into a > file. Currently I use the highest verbosity. > > Also it would help if README in the dump directories would also > explain (example command line) hot to use the decoder (if available) > on each dump. > > Regards, > Iztok Jeras > > On Wed, May 23, 2012 at 1:50 AM, Bert Vermeulen <be...@bi...> wrote: >> On 05/22/2012 11:09 PM, Iztok Jeras wrote: >> >>> $ sigrok-cli -i onewire.bin -I binary -p 1=OWR -o onewire.sr >>> The problem with the output file is that it is missing a sample rate. >>> How could I specify it? >>> https://github.com/jeras/sigrok-dump/tree/master/onewire/verilog >> >> As Uwe said, the binary input module needs to get some options for that, so >> imports can be a bit more flexible. As a temporary workaround, just edit the >> "metadata" file inside the .sr file (it's actually just a zip file). It's >> text, take a look at what's in some of the .sr files to see how you can >> specify samplerate. >> >> It all works fine without a specified samplerate as well, of course. >> >>> >>> Protocol decoder: >>> >>> I started writing the protocol decoder. >>> https://github.com/jeras/sigrok/tree/master/libsigrokdecode/decoders/onewire >>> But I have issues debugging it. Currently I run configure, "make" and >>> "sudo make install". I was able to run the decoder, but the given >>> error did not help much. How do you debug this decoders (while >>> developing them)? I would like to see the Python error trace, if >>> possible, and avoid installing. >> >> Note you can set the environment variable SIGROKDECODE_DIR to e.g. your >> development directory -- it will take precedence over any other module path. >> That way you can avoid doing "make install" all the time. >> >> Currently we're not doing a full traceback when an exception is raised in a >> python PD. The file/linenumber that it does show is *cough* not necessarily >> right, either. Definitely something that needs fixing :-) >> >> There is no debug path for PDs back into libsigrokdecode and from there to >> the frontend. I'm not so sure that it's worth doing... I just use print() >> and watch stdout. >> >> >> -- >> Bert Vermeulen be...@bi... email/xmpp >> >> ------------------------------------------------------------------------------ >> 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 >> sig...@li... >> https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Iztok J. <izt...@gm...> - 2012-07-02 22:33:24
|
Hi, 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: 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. 2. Overdrive support: Overdrive support was not tested yet, although all the needed code should be present. 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. 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? sigrok GIT is here (master branch): https://github.com/jeras/sigrok 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. Regards, Iztok Jeras On Sun, Jun 24, 2012 at 2:19 PM, Iztok Jeras <izt...@gm...> wrote: > Hi, > > I found the issue with missing annotations in my decoder. I should be > able to remove the debug code now. > > Regards, > Iztok Jeras > > On Sat, Jun 23, 2012 at 1:37 PM, Iztok Jeras <izt...@gm...> wrote: >> Hi, >> >> I now have a few 1-Wire dumps ready, but the whole protocol (lower >> layers) is not yet covered, overdrive mode is missing. It will be hard >> to cover all the higher level protocol elements, I should be able to >> add some more dumps, once I understand the higher protocol layers >> better. I should be able to add more dumps in the next month, but if >> for some reason I postpone it too far, please just pick them from: >> https://github.com/jeras/sigrok-dump/tree/master/onewire/owfs >> >> I should finally have 3 days of time for implementing the decoder. >> There is is something that is not clear to me, how should I write the >> command line to get the output from a decoder to the console or into a >> file. Currently I use the highest verbosity. >> >> Also it would help if README in the dump directories would also >> explain (example command line) hot to use the decoder (if available) >> on each dump. >> >> Regards, >> Iztok Jeras >> >> On Wed, May 23, 2012 at 1:50 AM, Bert Vermeulen <be...@bi...> wrote: >>> On 05/22/2012 11:09 PM, Iztok Jeras wrote: >>> >>>> $ sigrok-cli -i onewire.bin -I binary -p 1=OWR -o onewire.sr >>>> The problem with the output file is that it is missing a sample rate. >>>> How could I specify it? >>>> https://github.com/jeras/sigrok-dump/tree/master/onewire/verilog >>> >>> As Uwe said, the binary input module needs to get some options for that, so >>> imports can be a bit more flexible. As a temporary workaround, just edit the >>> "metadata" file inside the .sr file (it's actually just a zip file). It's >>> text, take a look at what's in some of the .sr files to see how you can >>> specify samplerate. >>> >>> It all works fine without a specified samplerate as well, of course. >>> >>>> >>>> Protocol decoder: >>>> >>>> I started writing the protocol decoder. >>>> https://github.com/jeras/sigrok/tree/master/libsigrokdecode/decoders/onewire >>>> But I have issues debugging it. Currently I run configure, "make" and >>>> "sudo make install". I was able to run the decoder, but the given >>>> error did not help much. How do you debug this decoders (while >>>> developing them)? I would like to see the Python error trace, if >>>> possible, and avoid installing. >>> >>> Note you can set the environment variable SIGROKDECODE_DIR to e.g. your >>> development directory -- it will take precedence over any other module path. >>> That way you can avoid doing "make install" all the time. >>> >>> Currently we're not doing a full traceback when an exception is raised in a >>> python PD. The file/linenumber that it does show is *cough* not necessarily >>> right, either. Definitely something that needs fixing :-) >>> >>> There is no debug path for PDs back into libsigrokdecode and from there to >>> the frontend. I'm not so sure that it's worth doing... I just use print() >>> and watch stdout. >>> >>> >>> -- >>> Bert Vermeulen be...@bi... email/xmpp >>> >>> ------------------------------------------------------------------------------ >>> 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 >>> sig...@li... >>> https://lists.sourceforge.net/lists/listinfo/sigrok-devel |
From: Uwe H. <uw...@he...> - 2012-07-04 00:22:55
|
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. > 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. 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. > 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. > 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. > 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? > 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. 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 |
From: Iztok J. <izt...@gm...> - 2012-07-04 20:17:03
|
Hi Uwe, Comments are inline. Regards, Iztok Jeras On Wed, Jul 4, 2012 at 2:20 AM, Uwe Hermann <uw...@he...> 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 |
From: Iztok J. <izt...@gm...> - 2012-07-06 15:58:24
|
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 <izt...@gm...> wrote: > Hi Uwe, > > Comments are inline. > > Regards, Iztok Jeras > > On Wed, Jul 4, 2012 at 2:20 AM, Uwe Hermann <uw...@he...> 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 |
From: Iztok J. <izt...@gm...> - 2012-07-17 20:15:48
|
Hi, First, I followed suggestions regarding rebase of git commits and using the 'onewire' branch instead of 'master'. Could you check if I did it correctly. https://github.com/jeras/sigrok I now separated the link/network/transport layers into separate protocols, overdrive mode detection is now duplicated but not tested yet. Each protocol is now placed inside its own directory, I would prefer to place all *.py files into a single directory "onewire", but it does not seem to be possible with the current build infrastructure. The transport layer code is very primitive for now. I also updated the reported timing, it is now start/end time, before this was start/duration. This was due to an error in the documentation: http://sigrok.org/wiki/Protocol_decoder_API Functions put() and decode() list the time/duration pair instead of ss/es (start/end sample). For the network and transport layer I would need to perform 8 and 16 bit CRC. I would like to use the 'crcmod' Python library (http://pypi.python.org/pypi/crcmod/1.7), but it is not yet in Debian repositories. What would be your suggestions here. Another issue I see is with the extra long CLI needed for decoding: sigrok-cli -i ../../../onewire.sr -a onewire_link:owr=0,onewire_network,onewire_transport -s onewire_link,onewire_network,onewire_transport -A onewire_transport Is it possible to shorten this, or is the idea that for ease of use the GUI will be used instead of the CLI? Regards, Iztok Jeras On Fri, Jul 6, 2012 at 5:58 PM, Iztok Jeras <izt...@gm...> wrote: > 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 <izt...@gm...> wrote: >> Hi Uwe, >> >> Comments are inline. >> >> Regards, Iztok Jeras >> >> On Wed, Jul 4, 2012 at 2:20 AM, Uwe Hermann <uw...@he...> 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 |
From: Uwe H. <uw...@he...> - 2012-07-22 01:08:15
|
Hi, On Tue, Jul 17, 2012 at 10:15:41PM +0200, Iztok Jeras wrote: > First, I followed suggestions regarding rebase of git commits and > using the 'onewire' branch instead of 'master'. Could you check if I > did it correctly. > https://github.com/jeras/sigrok Yep, looks good, thanks! I merged the changes and fixed up the contents a bit wrt. some coding style / cosmetics and also some functional changes, see below. > I now separated the link/network/transport layers into separate > protocols, overdrive mode detection is now duplicated but not tested > yet. Each protocol is now placed inside its own directory, I would That's great. > prefer to place all *.py files into a single directory "onewire", but Nah, that doesn't make sense. The files belonging to one PD must be in that PD's directory, of course. > The transport layer code is very primitive for now. I renamed that PD to maxim_ds28ea00, as it doesn't really make sense to try to have a "generic" transport layer PD, I'm pretty sure about that now. This layer is inherently device-specific, so the respective devices will have their own PDs on top of onewire_link and onewire_network. I added some more explanations in the respective commit message. The PD looked like it's mostly intended for the DS28EA00 so I renamed and reworked it for that one. Please add other PDs for other devices as needed. Note: It _might_ make sense to have one PD support multiple devices, if those devices are _very_ similar. We did this for (e.g.) the lm75 decoder, which can easily support the original National LM75 temperature sensor, but also various compatible devices from other vendors, which are usually almost identical, with only minor differences like 9-12 bits resolution as opposed to fixed 9bits for the LM75. It might make sense here to have a PD which handles the DS18B20 and various very similar sensors (similar features, commands, protocol, etc). Be careful though not to merge in too many devices. If there are too many differences between them, the code gets really ugly and convoluted and it would be better to have multiple PDs instead. Only support _very_ similar devices within one PD. > I also updated the reported timing, it is now start/end time, before > this was start/duration. This was due to an error in the > documentation: > http://sigrok.org/wiki/Protocol_decoder_API > Functions put() and decode() list the time/duration pair instead of > ss/es (start/end sample). Yeah, that page is a bit outdated, thanks! Will fix it soonish. > For the network and transport layer I would need to perform 8 and 16 > bit CRC. I would like to use the 'crcmod' Python library > (http://pypi.python.org/pypi/crcmod/1.7), but it is not yet in Debian > repositories. What would be your suggestions here. Generally it would be best to only use common modules that are part of the Python 3.x distribution, as anything else may or may not be available on all systems (at all, or without extra work for the user). Think Windows, FreeBSD, OpenBSD, Solaris, embedded stuff with only a minimal set of installed packages (OpenWRT and similar, for example), and of course the 100+ Linux distros which may or may not carry non-standard Python modules. In this specific case, the CRCs don't look that hard to calculate, it should be doable with a small helper function in the PD's .py file, no need for an extra module, IMHO. > Another issue I see is with the extra long CLI needed for decoding: > sigrok-cli -i ../../../onewire.sr -a > onewire_link:owr=0,onewire_network,onewire_transport -s > onewire_link,onewire_network,onewire_transport -A onewire_transport > Is it possible to shorten this, or is the idea that for ease of use > the GUI will be used instead of the CLI? Well, yeah, this kind of stuff will always be a bit longer on the CLI, but that's not a big issue. The more convenient usage for users will be in the GUIs later, sure. FYI, I added a few additional dumps of a DS1985 iButton to the sigrok-dumps repo, so we have a few more files to test the PDs on. I'll write a specific PD for that device soonish, but _link and _network seem to work OK on it already. I may have a few more upcoming changes for the _link/_network PDs, haven't looked at all details yet. HTH, Uwe. -- http://hermann-uwe.de | http://sigrok.org http://randomprojects.org | http://unmaintained-free-software.org |
From: Iztok J. <izt...@gm...> - 2012-07-22 09:29:47
|
Hi, My replays are inline. Regards, Iztok Jeras On Sun, Jul 22, 2012 at 3:08 AM, Uwe Hermann <uw...@he...> wrote: > Hi, > > On Tue, Jul 17, 2012 at 10:15:41PM +0200, Iztok Jeras wrote: >> First, I followed suggestions regarding rebase of git commits and >> using the 'onewire' branch instead of 'master'. Could you check if I >> did it correctly. >> https://github.com/jeras/sigrok > > Yep, looks good, thanks! I merged the changes and fixed up the contents > a bit wrt. some coding style / cosmetics and also some functional changes, > see below. > > >> I now separated the link/network/transport layers into separate >> protocols, overdrive mode detection is now duplicated but not tested >> yet. Each protocol is now placed inside its own directory, I would > > That's great. > > >> prefer to place all *.py files into a single directory "onewire", but > > Nah, that doesn't make sense. The files belonging to one PD must be in > that PD's directory, of course. > The main reason I would like to have more protocols in a single directory is o more obviously share code, expecially for the transport layer. > >> The transport layer code is very primitive for now. > > I renamed that PD to maxim_ds28ea00, as it doesn't really make sense to > try to have a "generic" transport layer PD, I'm pretty sure about that now. > This layer is inherently device-specific, so the respective devices will > have their own PDs on top of onewire_link and onewire_network. > I added some more explanations in the respective commit message. > > The PD looked like it's mostly intended for the DS28EA00 so I renamed > and reworked it for that one. Please add other PDs for other devices as > needed. > > Note: It _might_ make sense to have one PD support multiple devices, if > those devices are _very_ similar. We did this for (e.g.) the lm75 > decoder, which can easily support the original National LM75 temperature > sensor, but also various compatible devices from other vendors, which > are usually almost identical, with only minor differences like 9-12 bits > resolution as opposed to fixed 9bits for the LM75. > > It might make sense here to have a PD which handles the DS18B20 and > various very similar sensors (similar features, commands, protocol, etc). > Be careful though not to merge in too many devices. If there are too > many differences between them, the code gets really ugly and convoluted > and it would be better to have multiple PDs instead. Only support _very_ > similar devices within one PD. > It might make sense to have a single PD for all thermometers. One of the reasons I created a single transport layer PD is that many different 1-wire devices can be connected to the bus at the same time, but it is not possible to connect multiple decoders to the network layer PD. Another issue is that the user might not know what devices exactly are connected to the wire, and a common PD could do it automatically. If the issue is having the code organized, I would split the code into various files in the same directory, and import them all in __init__.py. I am still arguing for my position, since I am not sure we already reached a good solution. > >> I also updated the reported timing, it is now start/end time, before >> this was start/duration. This was due to an error in the >> documentation: >> http://sigrok.org/wiki/Protocol_decoder_API >> Functions put() and decode() list the time/duration pair instead of >> ss/es (start/end sample). > > Yeah, that page is a bit outdated, thanks! Will fix it soonish. > > >> For the network and transport layer I would need to perform 8 and 16 >> bit CRC. I would like to use the 'crcmod' Python library >> (http://pypi.python.org/pypi/crcmod/1.7), but it is not yet in Debian >> repositories. What would be your suggestions here. > > Generally it would be best to only use common modules that are part of > the Python 3.x distribution, as anything else may or may not be > available on all systems (at all, or without extra work for the user). > > Think Windows, FreeBSD, OpenBSD, Solaris, embedded stuff with only a > minimal set of installed packages (OpenWRT and similar, for example), > and of course the 100+ Linux distros which may or may not carry > non-standard Python modules. > > In this specific case, the CRCs don't look that hard to calculate, > it should be doable with a small helper function in the PD's .py file, > no need for an extra module, IMHO. > OK, the CRC function is very specific and it should not take more than a few lines of code. > >> Another issue I see is with the extra long CLI needed for decoding: >> sigrok-cli -i ../../../onewire.sr -a >> onewire_link:owr=0,onewire_network,onewire_transport -s >> onewire_link,onewire_network,onewire_transport -A onewire_transport >> Is it possible to shorten this, or is the idea that for ease of use >> the GUI will be used instead of the CLI? > > Well, yeah, this kind of stuff will always be a bit longer on the CLI, > but that's not a big issue. The more convenient usage for users will be > in the GUIs later, sure. > > > FYI, I added a few additional dumps of a DS1985 iButton to the > sigrok-dumps repo, so we have a few more files to test the PDs on. I'll > write a specific PD for that device soonish, but _link and _network > seem to work OK on it already. > > I may have a few more upcoming changes for the _link/_network PDs, > haven't looked at all details yet. > I was able to create some overdrive waveforms this week, they are on my GitHub sigrok-dump repo, but not yet on an appropriate branch (master for now), and the README file needs some more details. Instead of checking if overdrive is working properly I found big issues with the link layer, I am working on a rewrite now. The separation of layers, sounds as a very good idea now. > > HTH, Uwe. > -- > http://hermann-uwe.de | http://sigrok.org > http://randomprojects.org | http://unmaintained-free-software.org |
From: Iztok J. <izt...@gm...> - 2012-08-02 22:01:49
|
Hi, The recoded link layer PD is now working. But I still have to clean up the list of options (I added all protocol timing, although only some are used). Overdrive support is now tested and works. There is no need to merge the code now, unless you would like to make a release soon, than I would say the code is unfinished but usable. Two annotation modes are now available, one with only the same data as provided to the next protocol, one with extra timing information. The decoder now checks if the master timing is according to the standard and issues warnings if not. I attempted to remove the optional power signal, since the link layer can not use it. Now I send power changes to the next decoder. It seems the decoder does not work properly if only one signal is decoded, incoming data samples were corrupted. I have questions regarding how is the GUI supposed to show decoder annotations: Should the annotations be short, not to waste space when waveforms are zoomed out? The annotation content is given to the put function as a list, what would happen if multiple elements are present in the list? I would also like to know, if there are any plans for the next features, before I start bothering you with all my ideas (I am really excited about being part of this project): - continuous sampling mode - decoders written in C/C++ (speed would be needed for continuous mode) - attaching multiple decoders to a single continuous stream (separate decoders for UART Rx/Tx, ...) Regards, Iztok Jeras |
From: Iztok J. <izt...@gm...> - 2012-08-05 23:07:51
|
Hi, I updated the link and network layer code this weekend. Regarding all the timing options I decided not to document them, this should be acceptable, since the defaults are god for most cases (99%). You will probably have to do some white-space cleanup (not much), but otherwise the code should be OK for release. I also committed the dumps created with the sockit_owm Verilog master (FPGA + RTL + some C software). The file was used to test the overdrive mode code. GitHub, onewire branch (created from latest origin head): https://github.com/jeras/sigrok-dump In this version there are mostly documentation updates, but also announcements have been changed to shout less (using lower case letters). There was a bug fix for overdrive mode, and CRC checking was added to the network layer. I did not do any changes to the transport layer code. I added some code for the power signal, but it seems not to work properly, if the signal is not used (I do not have any waveforms with a separate power signal yet). I would like the value not to change from a default. So right now power signal changes are just propagated through the link and network layer to the transport layer, which should interpret them. Regards, Iztok Jeras On Fri, Aug 3, 2012 at 12:01 AM, Iztok Jeras <izt...@gm...> wrote: > Hi, > > The recoded link layer PD is now working. But I still have to clean up > the list of options (I added all protocol timing, although only some > are used). Overdrive support is now tested and works. There is no need > to merge the code now, unless you would like to make a release soon, > than I would say the code is unfinished but usable. > > Two annotation modes are now available, one with only the same data as > provided to the next protocol, one with extra timing information. The > decoder now checks if the master timing is according to the standard > and issues warnings if not. > > I attempted to remove the optional power signal, since the link layer > can not use it. Now I send power changes to the next decoder. It seems > the decoder does not work properly if only one signal is decoded, > incoming data samples were corrupted. > > I have questions regarding how is the GUI supposed to show decoder annotations: > Should the annotations be short, not to waste space when waveforms are > zoomed out? > The annotation content is given to the put function as a list, what > would happen if multiple elements are present in the list? > > I would also like to know, if there are any plans for the next > features, before I start bothering you with all my ideas (I am really > excited about being part of this project): > - continuous sampling mode > - decoders written in C/C++ (speed would be needed for continuous mode) > - attaching multiple decoders to a single continuous stream (separate > decoders for UART Rx/Tx, ...) > > Regards, > Iztok Jeras |
From: Bert V. <be...@bi...> - 2012-08-05 23:32:34
|
On 08/03/2012 12:01 AM, Iztok Jeras wrote: > I would also like to know, if there are any plans for the next > features, before I start bothering you with all my ideas (I am really > excited about being part of this project): > - continuous sampling mode Yes, this is already supported. The FX2-based LAs do this: the hardware always streams, triggering is done in libsigrok. With sigrok-cli, you would use --continuous. > - decoders written in C/C++ (speed would be needed for continuous mode) Not really something we want to do... we really want to build up a large and useful python PD library, since it's so much easier for people to contribute. > - attaching multiple decoders to a single continuous stream (separate > decoders for UART Rx/Tx, ...) Now you can laugh, but the fact of the matter is: 1) This was always in scope -- the idea that you split a signal into different PDs stacks. 2) The code is all there for this to be supported and working. 3) Nobody's ever tried it :-) The general idea is that your decoder instance is by default named the same as the PD (e.g. 'i2c', 'uart' and so on), but by assigning them different IDs yourself you should be able to set up a different stacking order for them. Let us know how that goes :-) -- Bert Vermeulen be...@bi... email/xmpp |