sigrok

On 09/12/2012 04:42 PM, Markus Engel wrote:
> Hello,
> 
> today we got hands on the Asix Sigma2. We especially ordered it because 
> of the support of sigrok.
> While I fully understand that open source software, supporting a wide 
> range of different hardware types, can be incomplete at some points, I'm 
> a bit disappointed that even the "Usage Example" in the wiki does not 
> work at all (and maybe did never).
> 
> Here is a list of what I've come across with and how I worked around 
> problems:
> 
> 1) after doing anything with sigrok-cli (e.g. scanning devices) I get a 
> double free.
> This is because of asix-sigma.c:427 where ftdi_free is called instead of 
> ftdi_deinit

Ok, I think that one is mine. I made some changes in that driver, but don't
have a sigma to test with. I'll see about getting this fixed/tested.

> 2) I always get a "sigrok-cli only supports one device for capturing." 
> even if I specify exactly one device using the "-d" option.
> This is because run_session tries to find all devices (which will return 
> the demo dummy device and the sigma in my case) and checks whether this 
> device list is greater than one, ignoring the "-d" option.
> My workaround here was to recompile libsigrok without the demo driver 
> leaving only one device in the list.

Sounds like a bug indeed, it should ignore demo unless specified directly.
However, be advised that you're using sigrok out of git, and the docs may
not always be up to date. In this case, you need to call sigrok-cli with
"--driver=asix-sigma". That's the new syntax, but hasn't made it into a
release yet.

> 3) The example uses the "--samples 5000000" option but the hwcaps of 
> your driver does not enlist SR_HWCAP_LIMIT_SAMPLES, so all you get is
> "Failed to configure sample limit.".

Hmm, indeed this is something every LA driver should have. As a workaround
for now, you could figure out the number of samples at your samplerate, and
specify it with --time. But you figured that out.

> 4) Finally I tried "sigrok-cli -d 0:samplerate=10m --time 1000 -O bits 
> -p 1-4"
> but the effect was more or less equivalent to "sleep 1". When I give an 
> "-o outfile" option I'm left with an empty file.
> Here is the output of loglevel 5:
> --BEGIN---
> sr: libsigrok loglevel set to 5.
> srd: libsigrokdecode loglevel set to 5.
> sr: Found ASIX SIGMA - Serial: A6021022
> sr: sigma: Uploading firmware asix-sigma-50.fw
> sr: sigma: Firmware uploaded
> sr: session: starting
> sr: bus: received SR_DF_HEADER
> cli: Received SR_DF_HEADER
> sr: bus: received SR_DF_META_LOGIC
> cli: Received SR_DF_META_LOGIC
> sr: session: running
> --END-----
> 
> I'm missing some log messages saying that samples are actually transferred.

It looks to me like it just didn't fire a trigger in that one second, and it
interrupted because time was up.

> All problems were observed using the current git head. I also tried the 
> newest tarballs of sourceforge, but the --samples thing was the same and 
> --time didn't exist.
> 
> So my questions are: Have I done anything wrong? Is there maybe ANY 
> revision I should check which at least captures some samples?

I'm curious, are you seeing that double free in the latest release as well?


-- 
Bert Vermeulen        bert@...          email/xmpp

Hi Markus,

Markus Engel wrote:
> today we got hands on the Asix Sigma2. We especially ordered it
> because of the support of sigrok.

Cool! It's a good piece of hardware and the vendor is very much worth
supporting!


> While I fully understand that open source software, supporting a wide 
> range of different hardware types, can be incomplete at some points,
> I'm a bit disappointed that even the "Usage Example" in the wiki does
> not work at all

I understand that.


> (and maybe did never).

I think it did, but sigrok is still a youngish project so there are
some violent changes here and there. I'm glad that you got in touch
with the community quickly though, so that you don't have to waste
time figuring out everything on your own.


> Here is a list of what I've come across with and how I worked around 
> problems:
> 
> 1) after doing anything with sigrok-cli (e.g. scanning devices) I get a 
> double free.
> This is because of asix-sigma.c:427 where ftdi_free is called instead of 
> ftdi_deinit

Are you comfortable with using git? If so, submitting a patch with
this fix should literally take only seconds. If not, please say so,
then I guess that someone else may produce the patch. In that case,
it would be helpful if you at least send the output of git diff for
your fixed file.


> 2) I always get a "sigrok-cli only supports one device for capturing." 
> even if I specify exactly one device using the "-d" option.
> This is because run_session tries to find all devices (which will return 
> the demo dummy device and the sigma in my case) and checks whether this 
> device list is greater than one, ignoring the "-d" option.

Stupid bug. I think Bert may fix this one.


> 3) The example uses the "--samples 5000000" option but the hwcaps of 
> your driver does not enlist SR_HWCAP_LIMIT_SAMPLES, so all you get is
> "Failed to configure sample limit.".

Maybe Bert too? :)


> 4) Finally I tried "sigrok-cli -d 0:samplerate=10m --time 1000 -O bits 
> -p 1-4"
> but the effect was more or less equivalent to "sleep 1". When I give an 
> "-o outfile" option I'm left with an empty file.
..
> I'm missing some log messages saying that samples are actually
> transferred.

Bert mentioned triggers. I'm not sure what the situation is wrt.
triggers in the asix-sigma driver. Is there a trigger button on the
Sigma2? If not, perhaps try using a few different clock or trigger
methods.

Note that sigrok so far has been tested significantly more with
mind-numbingly stupid FX2 streaming data acquisition hardware,
and not as much with actual logic analyzers like the ASIX products.

This means that there are a few wrinkles, but the underpinnings are
very much in place in sigrok to make it work excellently with actual
LAs, and I think if you have a serious usecase for the Sigma2 then
investing a few days of development effort into sigrok will be
incredibly rewarding - more is not going to be needed to make it
work really great also with the Sigma2.


> So my questions are: Have I done anything wrong? Is there maybe ANY
> revision I should check which at least captures some samples?

You've done nothing wrong, I think the code is just slightly
bitrotten from lack of testing - but the core is quite solid
and fresh, so since you have hardware in hand you are in the
best position to fix the issues.

I understand that you actually just want to use sigrok, but this is a
small project in terms of developers and that's simply not how such
projects work. Sorry. :\ But even if small, this community is really
fantastic - you'll have lots of fun if you stay in touch. Also feel
free to come hang out on freenode #sigrok.


//Peter

Hi Peter,

Am 13.09.2012 08:06, schrieb Peter Stuge:
> Hi Markus,
>
> Markus Engel wrote:
>> today we got hands on the Asix Sigma2. We especially ordered it
>> because of the support of sigrok.
>
> Cool! It's a good piece of hardware and the vendor is very much worth
> supporting!

That's part of why we've ordered it ;)

>
>> While I fully understand that open source software, supporting a wide
>> range of different hardware types, can be incomplete at some points,
>> I'm a bit disappointed that even the "Usage Example" in the wiki does
>> not work at all
>
> I understand that.
>
>
>> (and maybe did never).
>
> I think it did, but sigrok is still a youngish project so there are
> some violent changes here and there. I'm glad that you got in touch
> with the community quickly though, so that you don't have to waste
> time figuring out everything on your own.

Well, the example used the "--samples" option, which is neither 
supported in the tarball release nor in the git head. So if at any point 
in time the option WAS supported I'm wondering why it ever got removed. 
Thus I concluded the option was never supported and thus the example 
could not have worked.
You see, I was more guessing on this, but my conclusion seems quite 
reasonable to me ;)

>
>
>> Here is a list of what I've come across with and how I worked around
>> problems:
>>
>> 1) after doing anything with sigrok-cli (e.g. scanning devices) I get a
>> double free.
>> This is because of asix-sigma.c:427 where ftdi_free is called instead of
>> ftdi_deinit
>
> Are you comfortable with using git? If so, submitting a patch with
> this fix should literally take only seconds. If not, please say so,
> then I guess that someone else may produce the patch. In that case,
> it would be helpful if you at least send the output of git diff for
> your fixed file.

I'm at war with git. There are way too many versioning systems out there 
and I've come to find that git is the least usable under the popular 
ones. Just my opinion, but therefore I just know how to clone and pull ;)
Anyway, I appended the patch to the mail, hoping that mailman does not 
prune it or does whatever with it (I'm also at war with mailman *g).

>
>
>> 2) I always get a "sigrok-cli only supports one device for capturing."
>> even if I specify exactly one device using the "-d" option.
>> This is because run_session tries to find all devices (which will return
>> the demo dummy device and the sigma in my case) and checks whether this
>> device list is greater than one, ignoring the "-d" option.
>
> Stupid bug. I think Bert may fix this one.
>
>
>> 3) The example uses the "--samples 5000000" option but the hwcaps of
>> your driver does not enlist SR_HWCAP_LIMIT_SAMPLES, so all you get is
>> "Failed to configure sample limit.".
>
> Maybe Bert too? :)
>
>
>> 4) Finally I tried "sigrok-cli -d 0:samplerate=10m --time 1000 -O bits
>> -p 1-4"
>> but the effect was more or less equivalent to "sleep 1". When I give an
>> "-o outfile" option I'm left with an empty file.
> ..
>> I'm missing some log messages saying that samples are actually
>> transferred.
>
> Bert mentioned triggers. I'm not sure what the situation is wrt.
> triggers in the asix-sigma driver. Is there a trigger button on the
> Sigma2? If not, perhaps try using a few different clock or trigger
> methods.

I've already answered on that one, but accidently just replied to Bert 
instead to the whole list. And I wrote it at home last night, so I don't 
have access to that post at the moment. I'll repost it today evening.

>
> Note that sigrok so far has been tested significantly more with
> mind-numbingly stupid FX2 streaming data acquisition hardware,
> and not as much with actual logic analyzers like the ASIX products.
>
> This means that there are a few wrinkles, but the underpinnings are
> very much in place in sigrok to make it work excellently with actual
> LAs, and I think if you have a serious usecase for the Sigma2 then
> investing a few days of development effort into sigrok will be
> incredibly rewarding - more is not going to be needed to make it
> work really great also with the Sigma2.

I'm always open for supporting open source software and I'm investing a 
lot of effort into these. As you could see I tried to fix things on my 
own and scanned a bit over the code to understand what's going on there.
But right now I'm at the point where things should just work with little 
effort.
I need the measurements for my master thesis and I don't think I should 
spend too many time fixing things, what I need are pragmatic solutions ;)
So I don't know how much time I can effort writing or fixing code but if 
there is anything I can test for you, let me know it.

>
>
>> So my questions are: Have I done anything wrong? Is there maybe ANY
>> revision I should check which at least captures some samples?
>
> You've done nothing wrong, I think the code is just slightly
> bitrotten from lack of testing - but the core is quite solid
> and fresh, so since you have hardware in hand you are in the
> best position to fix the issues.
>
> I understand that you actually just want to use sigrok, but this is a
> small project in terms of developers and that's simply not how such
> projects work. Sorry. :\ But even if small, this community is really
> fantastic - you'll have lots of fun if you stay in touch. Also feel
> free to come hang out on freenode #sigrok.

See above ;)

>
>
> //Peter
>
> ------------------------------------------------------------------------------
> 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
> sigrok-devel@...
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>

Postet this before, but accidently only to Bert. So here is a repost to 
the list:

Am 12.09.2012 23:35, schrieb Bert Vermeulen:
> On 09/12/2012 04:42 PM, Markus Engel wrote:
>> Hello,
>>
>> today we got hands on the Asix Sigma2. We especially ordered it because
>> of the support of sigrok.
>> While I fully understand that open source software, supporting a wide
>> range of different hardware types, can be incomplete at some points, I'm
>> a bit disappointed that even the "Usage Example" in the wiki does not
>> work at all (and maybe did never).
>>
>> Here is a list of what I've come across with and how I worked around
>> problems:
>>
>> 1) after doing anything with sigrok-cli (e.g. scanning devices) I get a
>> double free.
>> This is because of asix-sigma.c:427 where ftdi_free is called instead of
>> ftdi_deinit
>
> Ok, I think that one is mine. I made some changes in that driver, but don't
> have a sigma to test with. I'll see about getting this fixed/tested.
>
>> 2) I always get a "sigrok-cli only supports one device for capturing."
>> even if I specify exactly one device using the "-d" option.
>> This is because run_session tries to find all devices (which will return
>> the demo dummy device and the sigma in my case) and checks whether this
>> device list is greater than one, ignoring the "-d" option.
>> My workaround here was to recompile libsigrok without the demo driver
>> leaving only one device in the list.
>
> Sounds like a bug indeed, it should ignore demo unless specified directly.
> However, be advised that you're using sigrok out of git, and the docs may
> not always be up to date. In this case, you need to call sigrok-cli with
> "--driver=asix-sigma". That's the new syntax, but hasn't made it into a
> release yet.

I think it should ignore everything else if I specify "-d N", shouldn't 
it? I had just a quick look over the code but it seems to me that 
run_session doesn't do its work if more than one device is found.
Even if I specify "--driver=asix-sigma", consider what happens if you 
have two Sigmas connected. So in my opinion "-d" should pick exactly one 
device -- what else is the primary use of this option?

>
>> 3) The example uses the "--samples 5000000" option but the hwcaps of
>> your driver does not enlist SR_HWCAP_LIMIT_SAMPLES, so all you get is
>> "Failed to configure sample limit.".
>
> Hmm, indeed this is something every LA driver should have. As a workaround
> for now, you could figure out the number of samples at your samplerate, and
> specify it with --time. But you figured that out.
>
>> 4) Finally I tried "sigrok-cli -d 0:samplerate=10m --time 1000 -O bits
>> -p 1-4"
>> but the effect was more or less equivalent to "sleep 1". When I give an
>> "-o outfile" option I'm left with an empty file.
>> Here is the output of loglevel 5:
>> --BEGIN---
>> sr: libsigrok loglevel set to 5.
>> srd: libsigrokdecode loglevel set to 5.
>> sr: Found ASIX SIGMA - Serial: A6021022
>> sr: sigma: Uploading firmware asix-sigma-50.fw
>> sr: sigma: Firmware uploaded
>> sr: session: starting
>> sr: bus: received SR_DF_HEADER
>> cli: Received SR_DF_HEADER
>> sr: bus: received SR_DF_META_LOGIC
>> cli: Received SR_DF_META_LOGIC
>> sr: session: running
>> --END-----
>>
>> I'm missing some log messages saying that samples are actually transferred.
>
> It looks to me like it just didn't fire a trigger in that one second, and it
> interrupted because time was up.

Well, I didn't specify a trigger condition, so I thought sigrok would 
record all the specified probes for the given duration.

I also tried "--trigger 1=1" and triggered some edges on probe 1 but it 
didn't change anything, except that
* without the option the LED was yellow
* with the option the LED was red. It didn't change after I triggered 
the edge but it changed after pressing the button. But in either case, 
no data were transferred.
I cannot rule out I could have made a mistake here. After all these 
failed tests it was more some random testing. I will repeat this in a 
more controlled way.

>
>> All problems were observed using the current git head. I also tried the
>> newest tarballs of sourceforge, but the --samples thing was the same and
>> --time didn't exist.
>>
>> So my questions are: Have I done anything wrong? Is there maybe ANY
>> revision I should check which at least captures some samples?
>
> I'm curious, are you seeing that double free in the latest release as well?
No, I'm just saying that the "--time" option didn't exist in the release 
and the "--samples" option didn't work either. Thus a friend encouraged 
me to use the git version and THEN there was the double free issue.

Regards,
markus

On 09/13/2012 12:25 AM, Markus Engel wrote:
> On 12.09.2012 23:35, Bert Vermeulen wrote:
>> On 09/12/2012 04:42 PM, Markus Engel wrote:

>>> 2) I always get a "sigrok-cli only supports one device for
>>> capturing." even if I specify exactly one device using the "-d"
>>> option. This is because run_session tries to find all devices (which
>>> will return the demo dummy device and the sigma in my case) and
>>> checks whether this device list is greater than one, ignoring the
>>> "-d" option. My workaround here was to recompile libsigrok without
>>> the demo driver leaving only one device in the list.
>> 
>> Sounds like a bug indeed, it should ignore demo unless specified
>> directly. However, be advised that you're using sigrok out of git, and
>> the docs may not always be up to date. In this case, you need to call
>> sigrok-cli with "--driver=asix-sigma". That's the new syntax, but
>> hasn't made it into a release yet.
> 
> I think it should ignore everything else if I specify "-d N", shouldn't
> it? I had just a quick look over the code but it seems to me that
> run_session doesn't do its work if more than one device is found. Even if
> I specify "--driver=asix-sigma", consider what happens if you have two
> Sigmas connected. So in my opinion "-d" should pick exactly one device --
> what else is the primary use of this option?

The last released version of sigrok-cli did that, but it didn't do it very
well at all. For example there was no way to specify different options for
each device found, or different probes, or any number of problems. We just
bit the bullet on this one, and declared sigrok-cli unfit for multiple
device capturing -- hence the message "sigrok-cli only supports one device
for capturing."

Multiple device support just needs a better frontend.

The --driver option is used to specifically select a driver, and pass along
any options that driver needs to find the device (e.g. the serial port it's on).

The --device (-d) option is only for options that are applied to a device
once it's been found.


-- 
Bert Vermeulen        bert@...          email/xmpp