See my response inline below.
On Tue, Aug 11, 2015 at 11:58 AM, Zac Harvey <[email protected]> wrote:
Thanks for that Lejos link, Kaspar, I will definitely dig into it later
today.
You mentioned that RIOT *targets* devices that require a small
footprint,
but you didn't state that RIOT only supports devices with small RAM.
What's the max size/RAM that RIOT can support, or that RIOT is
addressable
for? What would be entailed with refactoring it to handle larger apps?
So far, RIOT does not support 64 bit systems (native included, it is
compiled as a 32 bit binary even on amd64 afaik), and it will take
some effort to add that support, because there may be hidden
assumptions in the code that some data type is 32 bit long.
The biggest problem, however, with porting to a larger system than a
microcontroller is that these larger systems have MMU (memory
management unit)-hardware which performs address space translations
between virtual addresses and physical addresses, and ensures that
each process has its own address space to run inside. This MMU must be
configured when booting in order to access all of the memory. My area
of expertise is constrained systems, such as the current RIOT
platforms, so I may have some factual errors in the above explanation,
please correct me if I am wrong about anything above.
I ask this because to me, and for many others I'm sure, the main value
in an
RTOS (as opposed to Linux) is its deadline guarantees. When I run Java
on
Linux, the whole JVM process might come to a hault for a few seconds
while
Linux flushes some stream. Or perhaps some system-level utility runs for
a
few minutes and bogs down everything on the server (including my Java
app).
So to me, the real appeal of RIOT is:
1. Its a legitimate real-time OS when hard deadlines, task execution
guarantees, etc.; and
Can you really get any real-time guarantees on a Java VM? There are
background processes happening inside the Java VM which may cause
delays, for example memory garbage collection (this applies to Python
too and probably others, but I don't know any other interpreted
languages well enough to comment on them)
2. It's an OS where I can just deploy my app and I know that *nothing
else*
besides the OS is running
So to me, if RIOT-OS can technically handle JVM apps (2GB - 4GB in
size),
then why not try to get a JVM like HotSpot to run on it? And if for some
reason it can't handle apps that size (e.g. perhaps the largest integer
it
can handle is only 65,536, etc.), then I'm wondering what level of
refactoring would be required to enable it to handle beefier/server-like
apps.
Traditionally, the counter-argument here is: "Well then just write your
apps
in C." However, in 2015, all hobbyists, commercial and open source
organizations have an enormous amount of time & effort ($$$) invested in
existing software systems, which may be Java-based, Python-based,
Ruby-based, Node-based, etc.
I can't speak for anyone else, but I would argue that the ability to run
a
JVM app on a real-time OS is going to be of *enormous* utility,
especially
in this modern "Internet of Things" era we're careening towards. It
might
also spawn up a whole subculture of getting other systems (again,
Python,
Ruby, etc.) running in an embedded context. I'm just sayin'...!
Thoughts? Criticisms? Hate mail?
By all means, go for it! Even if it may not give the same real-time
guarantees as running a process hand-coded in C on the bare metal
platform it is still a useful experiment and concept.
For anyone attempting this: I don't believe this is an easy task. You
will probably have to implement quite a large part of POSIX ioctl,
some improvements to the supervisor call handler (at leas if running
on ARM, to handle more than just task scheduling). You may also need
to write an adaptation layer between gnrc (the network stack) and
whatever network API is expected by the JVM. Filesystem storage may
not be strictly necessary, but probably mandatory for almost any apps
you want to run on this system.
Best regards,
Joakim
_______________________________________________
devel mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/devel
