[Mizar32-riot] Riot-avr32 Temporary github location

[George Orais]

 Hi Sergio,
Thank you for sharing these info, very interesting and all noted.
Btw want to confirm if my understanding is correct, first goal is port Riot to Mizar32.After this we will port existing interpreters (Lua, C, PicoLisp, TinyScheme) from Alcor6L to run on top Riot, correct?After this, add Javascript, Python and Haskell interpreters on top Riot, correct?


Hi Marcus,
Thanks for all these details about Riot port for AVR32, all noted.
Let me dig into this and prepare my environment based on these details, will get back as soon as I got questions or if its in ready state.
For the naming, I agree with the points on Riot- first or Mizar32- first, but if you and Sergio votes for Mizar32-riot, I'm fine that ;)


BR,Geo
    On Tuesday, 17 November 2020, 04:20:40 am GMT+9, Sergio Sorrenti <sergio at simplemachines.it> wrote:  
 
 Hi Marcus and All,

regarding Riot OS i planned to make a fork when

we start to have an RTOS + Interpreters.

As Zephir is RTOS tied with Micropython

where 1 thread in Micropython become 1 thread in RTOS

This is a special thing and a fork with another name for the thing

is due. So "Alcor" .

Simplemachines research was tied to interpeters on microcontrollers

we worked with eLua in past, then we was the first with Lisp on MCU

I want to give better the idea of the following in time:

1) 1980-1995 MCU was exclusively programmed in ASM

2) 1995-2012 MCU was programmed in C (bare metal)

(all passed to C even thew inital unbelievers)

3) 2010 - 2015 RTOS are started to be used widely

Many vendors use FreeRTOS as base. But is a pletora

of RTOS happening: Contiki, the failed ARM RTOS(EMBED),

Chibi OS, NuttX, VxWorks, Riot OS and many others

4) 2019 to Now

Peoples are starting to use solution as Zephyr

now a linux foundation project, that mate intimately

RTOS wit Python Interpreter. While many popular

Interpreters bare metal are run in all interpreted languages.

--

So Dates may be a little wrong but what i want to make evident

is that is progressive and a kind of evolution in programming MCUs.

I have nothing to object to who program still now in ASM or C without

an RTOS as is done from long time.

But i see something in the future, that is our additional effort in SAM

something is never appeared till now: ---> Distributed automation

implemented in MCUs to be simple but flexible,

and all in Free Specifications.

While at the other side all are encucumbering with Cloud and AI

(google, Alexa, Siri, the same nodered of IBM).

--

So i dream the same simple methods to create a node,

with cooperating pieces of code, to re-use that code, make libraries

a network so a machine or a machine made of SPI nodes or 485 nodes

or home automation, industrial, and distributed over the gateways

as i said turn a PWM rotor in a lamp ion Tokyo and Close

the valve of the Niagara falls. I do not see this as impossible.

And is a target in 4 years (intuitively).

With andrea we are looking at the early Distributed automation

to make it viable on today MCUs. Is not simple to make decision

on every tiny part, that at the right time, all of us will discuss.

So for example Remote Procedure call, Inter-process Communication

Define Types and methods, make things local as they are distributed

to have no difference between local and not local,

inner the node or outside all new things for me, that i am trying

to make simple a thing that is not simple at all. And for all.

so what is the purpose of Simplemachines? ---> do things for all.

Simple and Elegant. We do not forget our Social purpose to code.

--

So Riot will be Alcor for us. As soon as the first interpreter

is fully functional as in Zephir ...

I do not know when is OK to pulkl it out the mainline tree

or in again, but about in have not much sense,

since we have to focus to run interpreters first

and not only one at a time, 6 at a time.

A limit there is 6 interperters. To fix a point of arrival.

Of course we start with Python then Lisp then other

seeking for support external support.

So just mind our Riot is a Fork, the name is Alcor

and it runs interpreters... Is a thing where Riot coders

are not interested or not still interested,

in future maybe they will keep our code, as we

can align the important things in Alcor.

I did not named the list "Alcor" directly

since is not the time, first a complete port of Riot

i think that is important to go further.

So above there is the motivation,

a side motivation is that we can not

invite more developers if riot do not work properly.

So this is the arrow or direction i am trying to keep up.

PS: @ Marcus, if you want fork Riot, pls go also now...

Sergio

Il 16/11/20 17:17, Marcus ha scritto:
> Hi George and all,
>
> This is a bit messy, due to great enthusiasm and poor planning when I
> started.
>
> As there is a problem with C99/C11 my bet is that we will not be able
> to do the avr32 port in the Riot github tree, but will have to keep
> out-of-tree on our own. So keeping up to date with Riot might be
> tricky. When we get something semi-stable for the avr32 port, it might
> be possible to get it in-tree with Riot again. Any ideas about this?

_______________________________________________
Mizar32-Riot mailing list
Mizar32-Riot at lists.simplemachines.it
https://lists.simplemachines.it/listinfo/mizar32-riot
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.simplemachines.it/pipermail/mizar32-riot/attachments/20201119/bc1962b6/attachment.html>