ANN: Soletta Project


Gustavo Sverzut Barbieri
 

On Tue, Jun 30, 2015 at 12:44 PM, Robert Schwebel
<r.schwebel@...> wrote:
On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:
Not yet. We're using an internal one, github issues for the public. Is there a
good free ML service you recommend?
I don't think so. Let's stay here for the moment :-)
https://lists.solettaproject.org/mailman/listinfo

people finally setup a mailman, we can still talk about it here or
start discussions about it there. I'm on both ml.


--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact


Gustavo Sverzut Barbieri
 

On Tue, Jun 30, 2015 at 1:39 PM, Robert Schwebel
<r.schwebel@...> wrote:
On Tue, Jun 30, 2015 at 01:30:04PM -0300, Gustavo Sverzut Barbieri wrote:
On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:
Not yet. We're using an internal one, github issues for the public. Is
there a good free ML service you recommend?
I don't think so. Let's stay here for the moment :-)

Our first impression when we saw soletta was: wow, they did it right.
That's nice to read. You mean just the build or the project itself? Share your
ideas and needs please :-)
The project itself. We are doing a lot of industrial automation
projects, and over the years, everyone invents the typical IO framework
stuff over and over again. Even worse, people with a different
background invent the same stuff in different ways:

- control people use Matlab/Simulink
- measurement guys use Labview
- factory automation does IEC61131 or IEC41499
- IoT folks use COAP etc.

Everyone reinvents wheels all over the place already, and now the IoT
people start working on the same things again.

There are many frameworks out there which have started with a university
background and have many deficiencies for professional use, and on the
other hand there are commercial frameworks which take things like safety
into account, but are not open source.

It's all a big mess.
yes, this is the case. And to make things worse, some assumptions from
Industrial or "old" embedded are making hard to get efficient user
consumer electronics. Take polling, for instance. Most software out
there is based on a fixed base tick, like Arduino or even some OS. If
you can't define timers, you can't reprogram your base tick and thus
cannot do a technique similar to Linux 'tickless' scheduler. That
means battery drain. Not an issue for industrial where you have
reliable power supply with backups/ups and where the lack of power
stops everything else. On homes, power outages are common, people want
to run on few duracell AAA batteries and so on... Network connectivity
is also similar, particularly if you take the wifi mess into account.
And upgrades, while before either you'd never upgrade or you'd do so
using experienced maintenance support, while with consumer electronics
you get get your inexperienced family member to do it and they have
nobody to call if things go wrong.

That's why we also plan to cover these bits with Soletta. We will
implement some sol_platform targets to reset to factory defaults,
emergency and upgrade for platforms we support, of course some rely on
having a hardware (i.e.: if we do have flash we can upgrade, if we
have EEPROM/NVRAM/... we can reset to factory defaults). Those would
be generic implementation, users can always provide their own and
still use the common API.

Did you take some time to try the linux-micro platform with posix
mainloop? We're using it for some demos with impressive footprint
(140kb userspace using bluetooth low-energy - bluez-peripheral +
muslc) And we can avoid using busybox or shell scripts :-) a single
binary does it all, including some services such as mounting from
/etc/fstab or setup ipv6.


IMHO what we need is a heterogeic hierarchical modeling framework, in
the spirit of Ptolemy II (but withaut Java), coupled with the practical
experience from GStreamer and v4l2 subdevices, but for process data.

soletta comes close :-)
great, let's work to do it :-)


--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact


Gustavo Sverzut Barbieri
 

On Tue, Jun 30, 2015 at 1:31 PM, Robert Schwebel
<r.schwebel@...> wrote:
On Tue, Jun 30, 2015 at 01:18:28PM -0300, Gustavo Sverzut Barbieri wrote:
ARGH!
We're fixing it, we found problems within Yocto as well.

The idea of moving to Kbuild is to make options interdependency easier
to track and do, as well as allowing it to be extremely configurable
for small os (for standard Linux we can compile everything as .so and
ship what we need)

Sorry about the inconvenience at this moment, but I believe as soon as
we get enough test it will be stable and a better option.
"
Use autotools
- Every custom config/makefile/build system is worse for everybody
than autotools is.
- We are all used to autotools, it works, nobody cares.
- It's only two simple files to edit and include in git, which are
well understood by many many people, not just you.

[...]

- And really, nothing but autotools is really an option. Just get
over it. Everything else is an experiment, and it will come back
to you sooner or later. Why? think cross compilation, installation/
uninstallation, build root integration, separate object trees,
standard adherence, tarball handling, make distcheck, testing,
portability between distros, ...
"

... from https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/plain/README
and it is very, very true.
well, this is Lennart and Kay, I know them and the history of libabc.
To put in context, the idea was to enlighten all the kernel developers
how to do stuff in userspace as most of them really invented something
new (not even kbuild, but their own Makefiles with shell scripts).


But I get your point. let's give people few more weeks to get it ready
for once and for all, it now we can go back.


(BTW, for cross compile we will need two builds of Soletta as we use some
built binaries to generate other files we use. One native and another for
target)
Yes, I've seen that you already started inventing stuff like TOOLCHAIN_PREFIX.
I'm not much into Kbuild so I'm not reviewing these patches. If you
know a Kbuild standard way let them know (Leandro Dorileo is the one
doing it).


--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact


Thomas Petazzoni
 

Hello all,

On Tue, 30 Jun 2015 17:44:54 +0200, Robert Schwebel wrote:

All experience from packaging > 600 tools for ptxdist shows, that any
package that tries to be smarter than autotools and invent their own
build system didn't take care of many important things.
Similar experience as a Buildroot core developer: autotools-based
packages are the ones that cause the least amount of trouble.

Best regards,

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


Robert Schwebel
 

On Tue, Jun 30, 2015 at 01:30:04PM -0300, Gustavo Sverzut Barbieri wrote:
On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:
Not yet. We're using an internal one, github issues for the public. Is
there a good free ML service you recommend?
I don't think so. Let's stay here for the moment :-)

Our first impression when we saw soletta was: wow, they did it right.
That's nice to read. You mean just the build or the project itself? Share your
ideas and needs please :-)
The project itself. We are doing a lot of industrial automation
projects, and over the years, everyone invents the typical IO framework
stuff over and over again. Even worse, people with a different
background invent the same stuff in different ways:

- control people use Matlab/Simulink
- measurement guys use Labview
- factory automation does IEC61131 or IEC41499
- IoT folks use COAP etc.

Everyone reinvents wheels all over the place already, and now the IoT
people start working on the same things again.

There are many frameworks out there which have started with a university
background and have many deficiencies for professional use, and on the
other hand there are commercial frameworks which take things like safety
into account, but are not open source.

It's all a big mess.

IMHO what we need is a heterogeic hierarchical modeling framework, in
the spirit of Ptolemy II (but withaut Java), coupled with the practical
experience from GStreamer and v4l2 subdevices, but for process data.

soletta comes close :-)

And now you are removing autotools and replace that by Kconfig. I
don't think that this is a good idea, especially when things make
further progress and there will be modules with external
dependencies.
Our hope is that it will make life easier as we already have modules
with external dependencies such as udev and systemd. Tracking that
with autotools was becoming more and more of a burden, like conflicts
and depends.
It looks easier in the first place, but usually it just shifts the
complexity somewhere else.

Got you. That's why I started it using autotools. :-) upon request
from many people we decided to try Kbuild. If it does not work we can
always go back to autotools.
However, let's see where your current activities lead to.

rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |


Robert Schwebel
 

On Tue, Jun 30, 2015 at 01:18:28PM -0300, Gustavo Sverzut Barbieri wrote:
ARGH!
We're fixing it, we found problems within Yocto as well. 

The idea of moving to Kbuild is to make options interdependency easier
to track and do, as well as allowing it to be extremely configurable
for small os (for standard Linux we can compile everything as .so and
ship what we need)

Sorry about the inconvenience at this moment, but I believe as soon as
we get enough test it will be stable and a better option. 
"
Use autotools
- Every custom config/makefile/build system is worse for everybody
than autotools is.
- We are all used to autotools, it works, nobody cares.
- It's only two simple files to edit and include in git, which are
well understood by many many people, not just you.

[...]

- And really, nothing but autotools is really an option. Just get
over it. Everything else is an experiment, and it will come back
to you sooner or later. Why? think cross compilation, installation/
uninstallation, build root integration, separate object trees,
standard adherence, tarball handling, make distcheck, testing,
portability between distros, ...
"

... from https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/plain/README
and it is very, very true.

(BTW, for cross compile we will need two builds of Soletta as we use some
built binaries to generate other files we use. One native and another for
target)
Yes, I've seen that you already started inventing stuff like TOOLCHAIN_PREFIX.

Sigh.

rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |


Gustavo Sverzut Barbieri
 

On Tuesday, June 30, 2015, Robert Schwebel <r.schwebel@...> wrote:
On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:
> Not yet. We're using an internal one, github issues for the public. Is there a
> good free ML service you recommend?

I don't think so. Let's stay here for the moment :-)

Our first impression when we saw soletta was: wow, they did it right.

That's nice to read. You mean just the build or the project itself? Share your ideas and needs please :-)

 
And now you are removing autotools and replace that by Kconfig. I don't
think that this is a good idea, especially when things make further
progress and there will be modules with external dependencies.

Our hope is that it will make life easier as we already have modules with external dependencies such as udev and systemd. Tracking that with autotools was becoming more and more of a burden, like conflicts and depends.

 

Are you sure you took care of things like out-of-tree builds and cross
compilation in a clean environment?

As you saw in your second email, things are broken and people are looking into fixing them. Unfortunately it broke, fortunately doesn't seem a huge thing to fix  
 

All experience from packaging > 600 tools for ptxdist shows, that any
package that tries to be smarter than autotools and invent their own
build system didn't take care of many important things.

Got you. That's why I started it using autotools. :-) upon request from many people we decided to try Kbuild. If it does not work we can always go back to autotools.



 
rsc
--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact


Gustavo Sverzut Barbieri
 



On Tuesday, June 30, 2015, Robert Schwebel <r.schwebel@...> wrote:
On Tue, Jun 30, 2015 at 05:44:54PM +0200, Robert Schwebel wrote:
> Our first impression when we saw soletta was: wow, they did it right.
> And now you are removing autotools and replace that by Kconfig. I don't
> think that this is a good idea, especially when things make further
> progress and there will be modules with external dependencies.
>
> Are you sure you took care of things like out-of-tree builds and cross
> compilation in a clean environment?
>
> All experience from packaging > 600 tools for ptxdist shows, that any
> package that tries to be smarter than autotools and invent their own
> build system didn't take care of many important things.

rsc@callisto:soletta$ make -j 4 ARCH=arm CROSS_COMPILE=/opt/OSELAS.Toolchain-2014.12.0/arm-cortexa8-linux-gnueabihf/gcc-4.9.2-glibc-2.20-binutils-2.24-kernel-3.16-sanitized/bin/arm-cortexa8-linux-gnueabihf-

...

rsc@callisto:soletta$ file build/soletta_sysroot/usr/bin/sol-fbp-runner
build/soletta_sysroot/usr/bin/sol-fbp-runner: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ab8c0ae81e21690d44fe635fc817f906caca899b, not stripped

ARGH!

We're fixing it, we found problems within Yocto as well. 

The idea of moving to Kbuild is to make options interdependency easier to track and do, as well as allowing it to be extremely configurable for small os (for standard Linux we can compile everything as .so and ship what we need)

Sorry about the inconvenience at this moment, but I believe as soon as we get enough test it will be stable and a better option. 


(BTW, for cross compile we will need two builds of Soletta as we use some built binaries to generate other files we use. One native and another for target)

 

rsc
--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
_______________________________________________
Celinux-dev mailing list
Celinux-dev@...
https://lists.celinuxforum.org/mailman/listinfo/celinux-dev


--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact


Robert Schwebel
 

On Tue, Jun 30, 2015 at 05:44:54PM +0200, Robert Schwebel wrote:
Our first impression when we saw soletta was: wow, they did it right.
And now you are removing autotools and replace that by Kconfig. I don't
think that this is a good idea, especially when things make further
progress and there will be modules with external dependencies.

Are you sure you took care of things like out-of-tree builds and cross
compilation in a clean environment?

All experience from packaging > 600 tools for ptxdist shows, that any
package that tries to be smarter than autotools and invent their own
build system didn't take care of many important things.
rsc@callisto:soletta$ make -j 4 ARCH=arm CROSS_COMPILE=/opt/OSELAS.Toolchain-2014.12.0/arm-cortexa8-linux-gnueabihf/gcc-4.9.2-glibc-2.20-binutils-2.24-kernel-3.16-sanitized/bin/arm-cortexa8-linux-gnueabihf-

...

rsc@callisto:soletta$ file build/soletta_sysroot/usr/bin/sol-fbp-runner
build/soletta_sysroot/usr/bin/sol-fbp-runner: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=ab8c0ae81e21690d44fe635fc817f906caca899b, not stripped

ARGH!

rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |


Robert Schwebel
 

On Fri, Jun 26, 2015 at 11:47:45AM -0300, Gustavo Sverzut Barbieri wrote:
Not yet. We're using an internal one, github issues for the public. Is there a
good free ML service you recommend?
I don't think so. Let's stay here for the moment :-)

Our first impression when we saw soletta was: wow, they did it right.
And now you are removing autotools and replace that by Kconfig. I don't
think that this is a good idea, especially when things make further
progress and there will be modules with external dependencies.

Are you sure you took care of things like out-of-tree builds and cross
compilation in a clean environment?

All experience from packaging > 600 tools for ptxdist shows, that any
package that tries to be smarter than autotools and invent their own
build system didn't take care of many important things.

rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |


Gustavo Sverzut Barbieri
 

Not yet. We're using an internal one, github issues for the public. Is there a good free ML service you recommend?

Most projects I know use either sourceforge, kernel's or their privately hosted. No idea what would be a best fit for this kind of project.



On Friday, June 26, 2015, Robert Schwebel <r.schwebel@...> wrote:
Hi Gustavo,

On Wed, Jun 17, 2015 at 02:15:23PM -0300, Gustavo Sverzut Barbieri wrote:
> I'm very glad to announce our project is now published as open source!
>
>     https://github.com/solettaproject/soletta

Is there already a mailing list for soletta?

rsc
--
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |


--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact


Robert Schwebel
 

Hi Gustavo,

On Wed, Jun 17, 2015 at 02:15:23PM -0300, Gustavo Sverzut Barbieri wrote:
I'm very glad to announce our project is now published as open source!

https://github.com/solettaproject/soletta
Is there already a mailing list for soletta?

rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |


Gustavo Sverzut Barbieri
 

Hi all,

I'm very glad to announce our project is now published as open source!

https://github.com/solettaproject/soletta

You're the perfect audience for this project and we hope you get some
time to check it out and test it. We hope it will be useful for people
creating embedded products, not only Linux products but also those in
the micro-controllers as it helps transitioning the knowledge (if not
the code) among different platforms. The main goal of this project is
to aid the developer to create "the device application" for his
product.

It is a first public release and it's far from a stable "1.0" release.
We're sharing the code and want to receive as much feedback as
possible so future development can help more and more developers out
there. So report any problems and ideas, even if you want to bash it,
please share your ideas on how it should be so we can stop being
bashed in the future ;-)

The README is pretty extensive and covers a lot, but what I'd like to
highlight that we make developers lives easier by providing some
uniform way to access basic resources and delivering events. As you
may expect the new wave of developers coming to embedded to implement
IoT are not that experienced and handling multiple OS-specific bits
are error prone and cumbersome, things like getting GPIO events from
interruptions (ISR) or file descriptors (Linux)... This often hurts
portability and we're stuck with a single SoC, board or OS because
porting the software is so painful. Right now we support Linux, RIOT
and there is an ongoing work to support Contiki.

It also helps those that have to support other developers, be a
manufacturer that needs to publish a SDK, be a services company that
helps a customer to create their product or a company that have
independent teams that need to create software components that will be
later joined to create the final product.

The basic programming is done in C and there is a high-level domain
specific language (DSL) to express business logic. The idea behind
this is to be as flexible and efficient as possible while avoiding
errors due asynchronous event programming in C, with all those nasty
callbacks and data passing. The FBP is translated to efficient C
blocks so it can run on very constrained systems. For larger systems
we benefit from FBP by using it as a script language, so one can avoid
build cycles to create the business logic.

This is even more powerful when combined with the "platform conffiles"
so you give your components a name based on purpose and define at
compile or runtime what's the actual implementation, with that one can
use standard keyboard and console to create something on your desktop
(fast), then move it to your real board/OS with minimum effort, just
change the conffile to map the boolean keyboard inputs to your GPIO,
some gtk/slider to your Analog I/O reader and from console to your
servo-motor and you're good to go! All that matters is if the
components have the same ports (names and types).

Last but not least, the license is permissive BSD so it can be
compiled as a static binary or together with the OS for those
micro-controllers.

NOTE: as you may see this from the contributors list the project was
created inside Intel. But it is meant to be a true open source project
without a controlling company. We will be very glad if more
manufacturers join us to help the embedded and IoT ecosystem. Whenever
you want to have your devkit supported, let us know and we will help.

--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 99225-2202
Contact: http://www.gustavobarbieri.com.br/contact