[LAU] Building an Open Source keyboard rig

[Patrick Shirkey]

On Mon, March 7, 2016 1:30 am, Gianfranco Ceccolini wrote:
>> Another contributor to the difficulty of making a successful
>> keyboard/DAW
>> hardware solution is the amount of effort/time required to build and run
>> the system. It's a good couple of man years of effort to wrap it all up
>> into a simple UI. Add the cost of manufacturing hardware and it quickly
>> become very difficult to compete on price with the established players.
>>
>> It's a minefield to build a simple system that just works. Realistically
>> it requires building out a complete stand alone distribution.
>
> My 2cents here:
>
> On the hardware part, I might be wrong but a powerful ARM platform is more
> interesting than any of the Intel NUCs.
>
> If we are talking multiple cores we have the Cubie8, the Optimus and
> others based on the AllWinner A80 which is an 8 core, 2MHz, ARM v7 + ARM
> v15 (BIG.little) CPU
>
> If we’re talking performance per core, the Pine64, the DragonBoard 410
> and even the Raspberry 3 (though I would not recommend the later) are a
> great option for the new 64bit ARM cpus.
>
> And of course, there are at least a handful of companies offering these
> SBCs already with a Board Support Package for the Industry: Toradex,
> Eurotech and Variscite are some.
>
>
> On the software part, I’d divide it into the OS + BSP and your actual
> software (the actual application)
>
> If you're making a business, then outsource all the OS + BSP and focus on
> your application.
>

All good points but on this one I tend to disagree. My experience is that
outsourcing this stage often ends up blowing out costs and creating a
dependency on the third party supplier. If you have access to experienced
hardware developers and can bring them in house then you will pay less in
the long run. If you draw talent from your trusted colleagues then you may
be able to get a very good results at very reasonable prices. Most
companies  that provide this kind of service have a small team of experts.
It's not that hard to replicate that structure inhouse.

>From a business perspective it's about finding the balance between getting
someone else to do the work for you and managing it in house. Very few
third party providers will give you a cheap deal. They might say they are
swallowing the design costs but they will make it back on unit price and
when other opportunities present themselves. If not they might not be very
good at estimating the true costs of delivery (time/effort) and that will
cause problems. A lot of companies will say they can do everything even if
they have no idea how to do it so they can win a contract.

Another issue to contend with is that there's a lot of risk involved and
they are used to their customers taking advantage of them so third party
suppliers tend to over estimate and then add double to keep their
financial risk low. If they don't do that then they may find it hard to
justify prioritizing your development tasks over their other projects and
cause delays in delivery.

Bringing the Firmware development phase in house allow you to manage more
closely the actual costs and development timeline. Then you can more
effectively make "agile" decisions if/when things start to go off track or
major roadblocks occur.


> The specification of OS + BSP are defined by the application, so I would
> do it at least in two rounds, doing a first round of prototypes using as
> much readily available elements as possible (and caring very little to
> aesthetics, ergonomy and actual performance), build a preliminary/pilot
> application over this prototype and then, if you decide you’re game on,
> you can then precisely specify the outsource job to be done.   I can
> assure you it will pay off in the long run :-)
>

The tricky part is precise. It's hard to find third party suppliers that
can do both precise and cheap. If you manage that part yourself then you
have more control of the Quality Assurance process.


> if you are using AllWinner CPUs, companies like Free Electrons can do all
> OS and necessary drivers. Even better, they do it in mainline vanilla
> kernel, which not only keeps your Open Source assumption but also gives
> you a much longer life cycle.
>

That is very important. You need to get access to ALL the firmware code
because after the supplier has finished the initial build there is no
guarantee that they will be around in the future to provide ongoing
services/support.


> If you’re doing for fun, try to find the board that offers the smallest
> effort on the OS + BSP.  Magic word here for the tool is Buildroot ;-)
>
> hope I have helped
>
>
> Gianfranco Ceccolini
> MOD Devices
> +49 160 646 9313
> gianfranco at moddevices.com <mailto:gianfranco at moddevices.com>
>
>


--
Patrick Shirkey
Boost Hardware Ltd