The community boards have two main problems: the hardware reliability-availability coming from the mindset of the community board maker and the deep native structure of its own O.S., like Debian or Raspbian, developed to work in normal laboratory conditions.

Without getting into the argument of why a SW engineer will load the OS with useless gigabytes of data, libraries, and runtime engines for an embedded application making it slow to bootstrap, we would like to focus on the real problems that we can solve.

Working with the microSD as the repository (not having a flash memory you must use a microSD or, worse, a microSD USB stick), you have the famous and well-known problem of the microSD corruption, along with potential thermal problems, and surely availability problems, because you cannot place a volume order with scheduled shipments. They are community board makers for hobbyists and laboratory projects, so it’s not their organization’s capability or mindset.

But what can we do to help our customers who have already started their application with one of those toy-board objects?

We offer a Raspmood HW design, that gives you the same IO pin strip pinout and logical level, so any external peripheral can be connected without a problem, almost the same mechanical form factor and IO connector… (”almost” because we would not like to directly copy a community board with all its problems and limitations).

We offer a Raspmood SW design, supporting the same OS (same OS means nothing to modify from a SW point of view, just reinstall) hosted in a flash memory with our clean shut down manager (insert link to the other news). And closing the argument with a simple library that will reroute the GPIO numbers, necessarily different, so your reinstalled software will run, the same as on the original, almost without any trouble. And in case of trouble, we’re here to support you.