Customers sometimes ask us if it is possible to use our modules without integrating our programming library. Indeed, at first sight, the library can seem unnecessarily complex when you only want to switch a relay or read a temperature. So the answer is yes... but no. There are ways to reduce the memory footprint of our library, but not to the point of reducing everything to a few manually forged USB packets. Let's look at it in detail.
Standard use of the library
As described in our tutorial describing the use of Yoctopuce modules, the programming library is not structured to offer a specific class per Yoctopuce product, but one class per feature. At first sight, this may seem more complicated, but it has the great advantage of enabling an application to work without any modification with different similar modules.
In the different examples provided with our programming libraries, we include most of the time the whole library, for simplicity. It thus includes the classes that drive all the Yoctopuce modules, even if the example does not use them. This allows you if necessary to start from an existing example for a sensor, and to add code to drive a relay for example.
If you want to reduce unnecessary dependencies, you can delete all the files concerning the function types that you don't use. For most languages, they are very easy to recognize: the file name is yocto_ followed by the function type. The only other mandatory file is called yocto_api. So if your application only uses the LightSensor and Relay features, you only need to keep the yocto_api, yocto_lightsensor and yocto_relay files. This should considerably reduce the number of files in your project.
Use without high-level interface
If you can't or don't want to use our object interface which allows you to easily interact with all the features of the Yoctopuce modules, it is possible to go down one level of abstraction by working directly with our C library. This is what we have described in a previous post. You can also find useful information about this in the devices user's guides, in the chapter entitled Using with unsupported languages.
The direct use of this"yapi" interface in C requires very good knowledge of C programming. To use this interface in C, you can either reference our precompiled library in your project, or directly integrate the .c and .h source files which you can find in the yapi subdirectory of the C++ library.
Can you shrink the "yapi" library?
If you want something even smaller, you may wonder why we needed fifteen or so .c files to code some USB package exchanges. Isn't there an even shorter version?
The answer is no: we don't have one. Our library was designed to be compiled on many platforms, so we had to make some abstractions to support the differences between operating systems. You may say that threads are not necessary for your application, but our experience is that they are necessary for robust USB operation when working without drivers, especially to handle plug-and-play properly. Furthermore, this C library can communicate with Yoctopuce modules both over the network and via USB. Even if you don't need this feature, it won't be easy to remove it because it is finely integrated to be fully transparent to the user.
Can you forge USB packages directly?
We have even been asked about the format of our USB packages to make a simpler driver than ours. So, yes or no?
We have nothing to hide: the format of the packages can be found in the ydef.h files and most of the code that makes up the packages can be found in ystream.c. But before you start, be aware that the low-level protocol between the modules and the library is not guaranteed to stay the same. It has already evolved several times over the last ten years to add new features. We maintain firmware and library compatibility to make these changes completely transparent to our users, but if you do your own implementation of the USB layer, you do so at your own risk.
Don't expect to find the equivalent of a serial port where you could send commands and receive measurements. Such an architecture would not have allowed for clean management of asynchronous events in the midst of synchronous communications. This is why we opted for a more sophisticated HID protocol. Moreover, since the use of HID packets limits us to a frame of 64 bytes per millisecond, we can neither separate each different piece of information in a different frame, which would be inefficient, nor limit the messages to one frame, which would be too restrictive when there is a lot of information to transfer. The information is therefore encoded in streams that are multiplexed in the USB frames, and which are therefore not so trivial to find without implementing the full stream logic. Therefore, do not expect to find the information at fixed locations in the USB packets.
Conclusion
We have not yet encountered a scenario that really justifies another implementation of the low-level interface than the one provided in our C library. This being said, if you really think you have a good reason to ask us, you can always contact Yoctopuce support to see if we can do something for you...