When compiling V-USB for attiny85 clocked at 16MHz using PLL (internal oscillator), the device was not recognized with “Device not accepting address” error messages in the kernel log.
The problem was that setting clocks in V-USB to 16000 (16MHz) only works with a crystal oscillator. When using internal oscillator, this setting does not work, and you need to set 16.5Mhz frequency by using the following in usbconfig.h
#define USB_CFG_CLOCK_KHZ 16500
After recompilation the device recognized properly, and worked correctly.
Hopefully this would save you a few hours of investigation.
A few minutes ago a new version of Karaoke Lyrics Editor – a free, open-source (GPLv3) software to create and edit Karaoke lyrics in many formats, with optional export to CDG and Video formats.
This version introduces several long-requested features, which will help you to make the editing faster.
I have purchased ASUS Zenbook UX305. It is a good Ultrabook which good Linux support and hiDPI screen. Unfortunately the support of hiDPI screens in modern Linux distributions is still lacking. Thus I decided to write down this post to help others struggling with similar problems when installing OpenSuSE on laptops with high definition resolution screens. After applying the suggested fixes you will get a functional Linux Ultrabook.
This is the last article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
You have made your core technology available for licensing. Because you followed the recommendations, your first SDK has been very successful on market. Licensees praised it for its easiness of use and quick integration, its features and robustness. However your product contains more than just the core technology – you have your support libraries, the rendering engine, a driver. And unexpectedly, your licensees start asking you to make available those other technologies as well. You may wonder, why? After all, creating a driver, or a rendering engine should be an easy task comparing to creating your core technology. And if someone doesn’t want to do this, it is available from other companies – there are even free, open-source versions! So why do the licensees ask for that?
This is a eights article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
No matter how good your SDK is, and how easy to integrate you made it, some licensees will still encounter issues during the integration. Those issues, ranked by the occurrence rate, would fall in one of the following categories:
- Invalid SDK usage (for example incorrectly installed or configured SDK, invalid API usage, incorrect license used);
- Environment issues (for example, lack of permissions to open the requested file);
- Lack of required system resource issues (lack of memory, disk space);
- Bugs in the SDK triggered by otherwise valid usage;
- Baseline issues (such as hardware issues, corrupted or infected operating system, etc).
There is little you can do for the last two categories. But the rest of the issues the SDK should handle as gracefully as possible. This means the licensee should know not only that the SDK cannot perform the requested operations, but also why the SDK cannot do that.
This is a seventh article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
We already discussed in the previous article, SDK Design Goal #5: Design for Extra Functionality, that when you initially develop your technology to be used internally, usually only the API necessary for the internal use is exposed. Thus you know extra work is needed when the technology is prepared for licensing, and now you are trying to decide which functionality should be available from your SDK.
Here you got a dilemma: Continue reading
A part of this article covers the issues related to C/C++/Java programming languages, and mentions relevant APIs. Feel free to skip those if you’re not familiar with the languages.
This is a sixth article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
When you developed your product, it only needed to work with files. After all, the users only needed to open the image file – or a set of files – and recognizes characters on it. Or to scan them for malware. Or to encode them into a video. Thus your technology operates on files. When you decide to make it available for licensing, this was the only option available to you.
Now you face a dilemma. Shall you take the technology as-is and make it available with its limited functionality? Or shall you spend time and effort, adding more functionality – and potentially more bugs – and delay the time to market? You speak with engineering, and they believe using only the files is good enough. You ask, what if someone wants to handle the data stored in memory? Or in the database blob? They say, this is not likely to happen, but even in this case it shouldn’t be difficult to dump this file into disk for processing. Just four lines of code or so. No big deal, right?
A part of this article covers the issues arising from designing C/C++ interfaces, and assumes basic knowledge of those languages.
This is a fifth article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
The technology you have developed works fine on a 32-bit Microsoft Windows. This is where it has been developed, this is where it has been used internally, and this is the platform it supports. Your marketing team sees no needs to support anything else, because your product already runs on both 32-bit and 64-bit Windows. Developing a separate 64-bit product would require significantly more effort, duplicate QA, and the expected performance gain for a 64-bit version is less than 1%.
Considering this, you decide to limit your SDK to a 32-bit Windows, and the API you created for it cements that. You happily using wchar_t Unicode strings all over the API, and you expect your SetIntValue function to accept pointers as well, because they’re the same size as the integer type on this platform. Your first licensees are also using 32-bit only, and don’t care about it. Everything goes well.
Suddenly Continue reading
This is a fourth article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
This goal works together with the prior one, Design for Extensibility. Let’s assume your SDK has passed the evaluation, the partner has integrated your product and is shipping. They are happy with the SDK quality, and everything goes well.
Then the other team in your organization asks you to extend the SDK just a bit. For example, they want the AV scanning function to return more information about the file. Or the OCR function to notify you about the progress. A pretty simple modification, which requires very slight modification of the API. Of course this would require a slight modification of the code using the SDK, but the internal team is ok with that. After all, they requested them, and they are ready and willing to modify their corresponding code using this SDK. And the modification is very small, so it is not a big real, right?
This is a third article in the SDK Design Goal series. Please see the introduction article “How to present the licensed technology the right way?”.
So if you followed the Design Goal #1 article, your design is good and you assume you got everything needed for quick integration. Your SDK provides all the functionality you think the customers might ever need, it has every options you think the customer needs, and retrieves all the data you think the customers might ever need.
This is true, and will stay true until you get your first real customer, who’d be using your technology. And what happens next?