to my understanding, uPython on Nuttx will be very similar to Python on
Linux. The POSIX concept of both is (near) identical. On the other side,
uPython on bare metal will be very different from both POSIX systems
Nuttx and Linux. The example of the BMP180 sensor will most likely work
on Nuttx and Linux uPython, but not on bare metal.
I would prefer a compatibility to Linux/Python then to any bare metal.
Both architectures are very close.
Not using the existing POSIX infrastructure for uPython, and instead try
to emulate any bare metal uPython, looks wired to me.
I guess, you understand, that an operating system like Nuttx, shield and
prevent hardware specific parts from user applications. The user land
application uPython, on Nuttx, have to use the POSIX interface to use
the hardware interface. You should also understand, that resources like
the SPI bus, will be used by several applications, not only uPython. As
such, only Nuttx can handle concurrent access to these.
On bare metal, all resources are yours. But not so in Linux, and not in
Nuttx.
Am 2022-06-20 18:38, schrieb Tomek CEDRO:
On Mon, Jun 20, 2022 at 6:26 PM Tomek CEDRO wrote:
On Mon, Jun 20, 2022 at 5:30 PM wrote:
> I dont think there is much to do with the drivers:
> Nuttx have already many drivers written in C, and from uPython, you just
> can open(), read(), write(), close() the character drivers. For example,
> if you like to read a pressure sensor what is already supported (BMP180
> for example, a pressure sensor connected by I2C), all the hardware stuff
> is done already in C. uPython only needs to open the BMP180, and ready.
>
> This is the big different of (u)Python on Nuttx compared with uPython on
> bare metal. The uPython on bare metal implementation must implement
> every hardware/sensor by itself. uPython on Nuttx can reuse all existing
> sensors, actors, and so on.
(..)
Using existing NuttX drivers should be possible in ported MP (i.e.
filesystem device read/write). But also what worked on bare MP should
work on MP+NuttX. I would not take the path of using existing NuttX
drivers to implement underlying drivers for MicroPython because that
would not be the generic way.
Sorry, local distraction and it that part sounds contrary what I wrote
before.
What I mean is I want any code work on generic set of drivers. So code
would be fully portable between bare-metal MicroPython and MicroPython
on NuttX both ways.
That would be probably implemented using NuttX as build target for
MicroPython just as current Unix build target. Generic drivers will be
"glue" and will use underlying character/block devices implemented by
NuttX so we are independent from underlying hardware.
Using existing target drivers of MicroPython on NuttX would imply
problems with NuttX drivers and vice-versa. Thus "the glue drivers and
build target concept".
Sure existing BMP180 driver of NuttX could be used on MP on NuttX. But
that would not work the other way - you would not run that code on
bare metal MicroPython. If no portability is required this is fine and
may be even more efficient. However, I would like to have a solution
that would work both ways in the first place and that would be my
ultimate goal :-)
