Why would they charge for an SDK?

[soFPG]

I mean, I don't get it: Why would a chip manufacturer charge for an SDK to enable customers developing their own software for these chips?

Maybe I want to do a bluetooth hobby project in the future (btw I am a pure hobbyist, I don't want to sell anything so that's another reason to not buy an SDK) so I looked around what kind of ICs there are. I knew about Nordic Semi before, they have some nice controllers with Bluetooth and they have the SDK to download for free on their website. Nice!

I searched google for a little bit more and came across a Qualcomm chip series which have Bluetooth 4.1 LE: https://developer.qualcomm.com/hardware/csr101x/csr1010-1011-dev-kits
So I registered on their website and I was able to find some documents about the CSR1010, which is a 16-bit uC (but they don't tell you which kind, it's 16-bit you know) with some ROM (that's how they describe it) and RAM. You can boot from internal ROM and from external I²C and SPI memory as well (that's nice I think). Programming also happens via SPI so you need some kind of SPI <-> USB adapter (which is on the Dev Board which I'll talk about in a bit).
It seems like Qualcomm aquired the company which originally developed these chips (called CSR) in 2015.
As I said it is possible to download some documents, to download the SDK however you need a product code. And you don't get any information on their website about how to get that product code! You have to look into the User-forum (which is not very active by the way) so that people tell you that you NEED to buy a 99$ dev board with bunch of buttons and LEDs and stuff on it which no body needs just to get a CD (in 2019) with the SDK on it (and probably a product key as well).

But why?   

And they are even using a toolchain based on GCC 4.x (don't remember exactly which version it is) which should be Open Source (because you remember GPL and so on)!

Qualcomm has some other Bluetooth / WiFi enabled chips but of course they are completely closed and there is no documentation about them, neither on their website (if you log in as a user) nor anywhere else on the internet - so that's not an option too.

I guess I have to stick with Nordic Semi then?

[Ian.M]

Usually because the beancounters have determined software support is a cost center, and the minimum 'pay to play' fee offsets the support costs and discourages clueless 'makers' but is too low for any commercial user to even bat an eyelid.

Also by forcing you to buy their dev board, if you need too much hand-holding, they can require you to build your buggy code for the dev board before they'll accept a support case.

See the GPL licence FAQ: https://www.gnu.org/licenses/gpl-faq.en.html
Its entirely legal for a company to charge for GPL licenced software, and they don't have to make the sourcecode available online for free, as long as they provide a copy to their customers (e.g. bundle it on the install CD) and to any third party on demand at no more than the cost they charge for the software.

Of course that's odious to FOSS advocates, but they may well not want the more rabid end of the FOSS community as customers due to the probability (in their opinion) of an increased workload for the support team.

[T3sl4co1l]

Qualcomm does huge, mass market products.  A, say $10k software license, is a minuscule fraction of total project or production cost, chump change.  If you aren't making mass-market products, don't look at them.

Tim

[soFPG]

If you aren't making mass-market products, don't look at them.

That's probably what I will / have to do even though it hurts to be unable to use their products (they have some pretty nice BT/WiFI SoCs which I haven't seen anywhere else). 

What I was able to find out about the CSR1010 is that it is not possible to program the interfaces directly, just through functions supplied by the SDK (much like the ESP8266 / ESP32) which is another thing I don't understand (but that's the same with Nordic Semi products I guess - no one wants to share how they implemented Bluetooth).

[SiliconWizard]

Qualcomm does huge, mass market products.  A, say $10k software license, is a minuscule fraction of total project or production cost, chump change.  If you aren't making mass-market products, don't look at them.

Yep. Given their typical market, the real question here would be: why would they NOT charge? What would they possibly gain from that? Thing is, mostly problems.

[m98]

Nordic nrf52 is pretty much the way to go if you want the most flexible Bluetooth/multiprotocol solution for a product. There are even 3rd-party open-source Bluetooth and other radio stacks for it. One tip: Use PlatformIO instead of segger embedded studio.

Dialog also has a nice product range, and also provide extensive documentation and free dev tools. But there doesn't seem to be a huge community around their products.

Just for completeness, they all don't support any Bluetooth audio profiles, so if you want that, you could take a look at the products from Microchip.

[coppice]

I mean, I don't get it: Why would a chip manufacturer charge for an SDK to enable customers developing their own software for these chips?

The thinking in many hardware vendors is that paying for software is a signal the customer is serious. This means its worth putting serious support effort into ensuring their designs succeed, and reach high volume production. I have mixed feelings about every approach you can take, but having to assist a lot of people tinkering with your parts, with no hope they will ever buy a shed load of them, can really drag your business down.

[soFPG]

What would they possibly gain from that? Thing is, mostly problems.

More people trying their products (possibly students who later become entrepreneurs building products with their devices...). I don't expect support for something I didn't pay for. So I am fine with that (they have a forum where people can ask questions so that is also some kind of support)

Dialog also has a nice product range

Thanks! Never heard about Dialog before.

Just for completeness, they all don't support any Bluetooth audio profiles, so if you want that, you could take a look at the products from Microchip.

I don't know very much about Bluetooth, I thought that Bluetooth profiles are what devices tell to other devices what kind of data they are transmitting? Because, basically its always Bluetooth @ 2.4GHz - right?
I actually wanted to do some audio related stuff (that's why it is a true bummer because Qualcomm actually has some Bluetooth SoCs with DSPs in it)

I have mixed feelings about every approach you can take, but having to assist a lot of people tinkering with your parts, with no hope they will ever buy a shed load of them, can really drag your business down.

I understand that point of view but - why not only support paying customers who are buying in large volumes? I don't expect Microchip to help me with their IDE either, but I am happy they are providing it for free.
The same with STM / Espressif / ...

[coppice]

I have mixed feelings about every approach you can take, but having to assist a lot of people tinkering with your parts, with no hope they will ever buy a shed load of them, can really drag your business down.

I understand that point of view but - why not only support paying customers who are buying in large volumes?

If you put stuff on the web, people have problems using it, and you don't address them, you quickly build a bad reputation. There is a really big downside to "just putting stuff out there".

[coppice]

Just for completeness, they all don't support any Bluetooth audio profiles, so if you want that, you could take a look at the products from Microchip.

Note that most devices designed for ultra low power BTLE applications are incapable of doing classic Bluetooth things, like audio. They only support the low energy modes.

[james_s]

This has been my thought too, I refuse to even consider a product for which the documentation and SDK are not free. I'm perfectly ok with having to pay to get any kind of support but I will not pay just to find out if the part is worth messing with.

[mark03]

The majority of posters in this thread are wrong   (except for the advice to stay away from Qualcomm!)

People who have worked in a profession for a long time find ways of justifying "the way things are" and eventually, those explanations become conventional wisdom, dogma which isn't seriously examined.  I speculate that it serves the purpose of smoothing over cognitive dissonances which would otherwise distract us from getting real work done.  Or, it makes us feel better to justify the things that we cannot change, instead of chafing under them indefinitely.

The fairly obvious truth is that there is no good reason why Qualcomm does not release their SDK for free.  It might well help them if they did, and it certainly wouldn't hurt them.  They are free to release it into the wild, without having to lift a finger to support anyone they don't want to support.

[coppice]

This has been my thought too, I refuse to even consider a product for which the documentation and SDK are not free. I'm perfectly ok with having to pay to get any kind of support but I will not pay just to find out if the part is worth messing with.

If you are a serious potential customer for a decent volume of parts, you will normally find the sales people will get you everything you need at no cost. This is a normal part of volume price negotiations.

[james_s]

If you are a serious potential customer for a decent volume of parts, you will normally find the sales people will get you everything you need at no cost. This is a normal part of volume price negotiations.

I'm typically not, but that doesn't mean I'm never going to be. I also tend to hang around other engineers, some of whom do tend to do larger volume products and I speak highly of companies that have treated me well and grumble about those who have not, word gets around.

I simply see no downside to providing the software as-is with no support at no cost. Maybe I just tinker with it and build a one-off for myself and that's it, maybe something more comes of it, doesn't really matter. Unlike physical parts, giving away software costs essentially nothing, it can only benefit them to have it in as many hands as possible.

[m98]

I don't know very much about Bluetooth, I thought that Bluetooth profiles are what devices tell to other devices what kind of data they are transmitting? Because, basically its always Bluetooth @ 2.4GHz - right?
I actually wanted to do some audio related stuff (that's why it is a true bummer because Qualcomm actually has some Bluetooth SoCs with DSPs in it)

In case of the nrf52, that only supports Bluetooth LE (natively via the "soft devices"). Bluetooth classic has fixed profiles that need to be implemented by the Bluetooth stack, while Bluetooth LE effectively only supports the "GATT"-profile, which is then implemented in the application layer. With the 2PHY of Bluetooth 5, you still have a data rate of up to 2 Mbps, so you could hypothetically implement a custom profile for audio streaming if you use an external DSP/codec or only want something rudimentary. Of course, that would only be compatible with, for example, your own smartphone app that also implements that profile.
So if you want a Bluetooth classic / Dual Mode SoC with DSP and codecs, Microchip has a pretty good lineup.

[ebclr]

Typical Qualcomm customers, are Samsung, Apple, Sony even Huawei, they don't care to pay 10 K on a 100 million project

[SiliconWizard]

What would they possibly gain from that? Thing is, mostly problems.

More people trying their products (possibly students who later become entrepreneurs building products with their devices...).

They obviously don't care. Qualcomm is not Microchip, and engineers using Qualcomm products are not going to do it because they got to fiddle with them while they were students or hobbyists. The typical companies using Qualcomm products will not do it either based on some random engineer's opinion. This is the kind of big decision that is not taken this way in most cases, but goes through a long process of approval.

[soFPG]

If I were to decide that my R&D department now develops a Bluetooth enabled product (whatever), one of the first steps would probably be thinking about what the product should do and then selecting the IC which best fits the purpose.
But I certainly would not be calling Qualcomm that I now need 5 Million of their BT-chips. I don't think that's how it works right? Even mass produced products had a research phase beforehand where a prototype was developed in small quantity.
So Qualcomm must be giving away sample ICs (for free) for development. Because no company is signing a contract with the requirement to buy a large quantity of ICs. Maybe the R&D team discovers that for whatever reason the Qualcomm IC doesn't fit and now you have to switch to a Nordic Semi part and cancel the 5 million order?

How does this process works then?

[coppice]

If I were to decide that my R&D department now develops a Bluetooth enabled product (whatever), one of the first steps would probably be thinking about what the product should do and then selecting the IC which best fits the purpose.
But I certainly would not be calling Qualcomm that I now need 5 Million of their BT-chips. I don't think that's how it works right? Even mass produced products had a research phase beforehand where a prototype was developed in small quantity.
So Qualcomm must be giving away sample ICs (for free) for development. Because no company is signing a contract with the requirement to buy a large quantity of ICs. Maybe the R&D team discovers that for whatever reason the Qualcomm IC doesn't fit and now you have to switch to a Nordic Semi part and cancel the 5 million order?

How does this process works then?

How are you going to choose the best option for your 5 million unit production run without first negotiating the 5 million off price for the key components? This is the very first step in a high volume development project. You talk to vendors. They bid prices for the volume you need. You choose. You develop, often with considerable assistance from the vendor. If things go badly wrong with the development you start negotiations again for the remaining options. If things go well you start production. The snag comes if product sales don't go well, and your component pricing was contingent on accepting a large number of parts. You are going to have some serious negotiations with the vendor at that point.

[amyk]

Qualcomm is about the same as Broadcom, i.e. stay far away from them.

[SiliconWizard]

Qualcomm is about the same as Broadcom, i.e. stay far away from them.

Well, as a hobbyist/small company, obviously yes.

But interestingly, The RPi has been using Broadcom SOCs. (This causes a number of issues such as poor documentation for the end-user, but that's still interesting.)

[coppice]

But interestingly, The RPi has been using Broadcom SOCs. (This causes a number of issues such as poor documentation for the end-user, but that's still interesting.)

This appears to have happened only due to personal connections, and historic quirks. Some of the developers of the RPi came from Broadcom, and the original RPi seems to have used an SoC designed for set top boxes, which was a commercial failure. The first run of the RPi was able to soak up the stock of parts they had. After that, they just continued with derivatives of the original part.

[T3sl4co1l]

Also hard to argue with the price of the parts in such quantities; but as we've seen, it doesn't do much for openness of the platform.  They have no incentive to release documentation, indeed it would probably hurt them more by making that info available to their competitors (at least, that's something they'd tell you; I doubt their competitors have all that much trouble finding it regardless).

Tim

[station240]

TI used to charge for the SDK for their micros, but changed it to free.
Still a good idea to get a devboard with onboard programmer, as it's often cheaper than buying a dedicated programmer (as the later have more features).

I wouldn't quibble about $99 for a devboard that comes with a CD of the software, I doubt they make much money out of that.