[Arm-netbook] CC3000 Wi-Fi for MCU

[Gordan Bobic]

lkcl luke wrote:

>> what would be the advantage
>> of having the firmware blob in the hardware vs. having it in software
>> updatable?
> 
>  if you do not respect software freedom at its absolute extreme, there
> is absolutely no advantage whatsoever, and, in fact, there is a
> significant financial penalty for respecting software freedom.
> 
>  ... however given that there is, quite literally, absolutely zero
> persons providing _any_ WIFI modules that are FSF
> Hardware-Endorseable, the first people to do so will walk away with
> the entire market.

To the best of my knowledge, that argument has never lead to a 
manufacturer completely opening their drivers, despite the obvious 
benefits they would reap.

>>>  why is this something that i would like to cover?  it is because i
>>> would like _everyone_ in free software to be involved in the EOMA
>>> initiative.
>> As somebody pointed it out already, since there is currently no such
>> thing as WiFi module that doesn't handle firmware in the side-load way I
>> don't think it'll make any difference one way or the other.
> 
>  you don't understand: i *have* to find a solution.

Fair enough, if that is the view you insist on taking. But it may well 
mean that you end up with no product due to that inflexibility.

>> Nothing
>> changes and the EOMA card product isn't in any way disadvantaged. So
>> from the purely pragmatic PoV, I don't see a problem.
> 
>  please get such notions of considering "pragmatism" out of your head.
>  i *have* to find a solution, in order to serve these loyal customers.

Good luck.

>>>>>  thus, it is necessary to consider solutions such as having a separate
>>>>> CPU which has, for example 2x USB-2 (one of which is client USB and
>>>>> the other is USB host), and that CPU having on-board NAND flash which
>>>>> can be made read-only, and that CPU having an application which is
>>>>> also read-only, and that CPU's application acting as a proxy of USB
>>>>> data once the firmware has been uploaded, and that CPU having the WIFI
>>>>> module connected to the USB host and the *main* CPU being connected to
>>>>> that separate CPU.
>>>>>
>>>>>  this is the kind of thing that would be recommended for purchase via
>>>>> the FSF's web site.
>>>>>
>>>>>  the only problem is that i can't find a CPU that's fast enough, small
>>>>> enough, has fast enough interfaces and also isn't an insane cost.
>>>> What is the gain, though? What is the underlying cause for the objection
>>>> to firmware blobs?
>>>  it's that they are non-free.  if they're non-free, then the source
>>> code must be available.  if the source code is not available, then it
>>> must be inviolate (hardware-only).
>>>
>>>  that's the rule.  there is no arguing with this rule: it is not up
>>> for negotiation.
>> See above under "rhetoric and posturing".
> 
>  see above under "serving the customer".

The problem is that in order to serve one customer you may end up having 
no product at all, to serve _any_ customers.

I guess my argument so far paints a clear enough picture of which side I 
am on when it comes to a choice between pragmatism and politics as far 
as engineering and product design are concerned.

IMO, a product is better than no product, a product that works is better 
than a product that doesn't, and a product that is more open is better 
than a product that is less open. Sacrificing the existance of a product 
just because it wouldn't be as open as you like sounds like cutting off 
your nose to spite your face.

Gordan