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
