Any chance of obtaining documentation on the communication protocol of the PicoScope 2202? I'm considering trying to use it through an existing automated energy consumption measurement framework under Linux.
Any documentation format you happen to have handy would be helpful and much appreciated.
Regards,
Johan Lindqvist
Embedded Systems Laboratory
Ã…bo Akademi University
Sorry for the delay in the response I have not been on the forum for a short while.
The linux support was for a few of our older legacy products. We are aware of the growing use of linux, so your points are duly noted, in future our new products will have linux support. However it would require to much resources to make modifications for our current scopes.
We are aware of that project, however, it would not overcome the concerns that Ziko previously mentioned about releasing our code.
Regards
John
Could you please be so kind as to explain why you think so? Under the Linux Driver Project, companies don't release anything to the public, neither code nor specifications. It's just an agreement with a single developer (or a small group) who gets access to the specifications under a non-disclosure agreement. The code developed by this person will be public, but not the specifications. If the driver contains firmware which must be uploaded to the device before it can be used, this can perfectly be kept in binary form even under the GPL since the firmware is executed on the device and in no way can be considered "derivative work" based on other GPL code.
We would very much like to fully support Linux for our products; however, we do not wish to do so in half measures.
The drivers for our products are complex as they provide a number of special functions. Therefore, short of releasing our sensitive code, it would take us longer to provide specifications for the Linux developers than to write the drivers ourselves, and herein is the issue. Moreover, providing support to the Linux Driver Product and, by implication, to customers who use those drivers, would not facilitate the level of support that we like to provide for our customers.
In summary, we believe that to provide effective customer support, it will be necessary to produce our own Linux drivers and, we are continually reviewing if and how best to do that.
picojohn wrote:
The drivers for our products are complex as they provide a number of special functions. Therefore, short of releasing our sensitive code, it would take us longer to provide specifications for the Linux developers than to write the drivers ourselves, and herein is the issue. Moreover, providing support to the Linux Driver Product and, by implication, to customers who use those drivers, would not facilitate the level of support that we like to provide for our customers.
It's not that hard really ..
you need 2 things ..
1. kernel module
2. client library
kernel module has to be "compiled on site" so it should be "open source" but kernel module does not need to have any IP data in it .. it is just a mapper from USB to /dev/picoscope or /proc/picoscope/xyzw so the client library can communicate with the device. Your current windows driver does pretty much the same afaic.
client library is a different story and it does contain IP code that I'm sure you would not like to share. I actually do not see why you do not want to share it as it is actually quite easy to debug both your app and driver for win32 and reverse engineer the solution .. just, why do it .. afaik it will only work with your hardware, and your software is free anyhow...
back on topic .. you do not need to give away the source code for the client library that actually controls the device, just build 32bit and 64bit library and ship the binary ..
to cover "all" linux distro's and to make it professionally acceptable you need to only make 4 binary packages
- x32 dynamically linked with (current glibc at the time of linking)
- x64 dynamically linked with (current glibc at the time of linking)
- x32 statically linked with "whatever glibc you like"
- x64 statically linked with "whatever glibc you like"
so, the same source, you just need to compile 4 binaries, just few different flag's, provide libraries in .tar.bz2 and you are "the best supported pc scope for linux"
This is pretty much how all proprietary code is done, you do not need to go and make "installer", "rpm", "deb", "pkg" .. just make tar.gz or tar.bz2 .. 4 of them, x32 and x64 statically and dynamically linked .. that will be enough .. not much effort and probably huge gain... not to mention that you will get bunch of opensource scope applications with features "to die for" after that ..
one addition to my previous post, if you need any help in setting the envinronment for building all four packages, I would be ready to help (for free) .. I have much experience in building proprietary software for linux