On Tue, Aug 11, 2015 at 10:23 PM, Zac Harvey <zhar...@pobox.com> wrote: > Thanks Kaspar and Joakim, > > I'm not trying to be difficult here (I promise!) I'm just trying to see the > forest through the trees. > > When you say that "The OpenJDK would probably require many megabytes of both > ROM and RAM, this means it will not run on the sam3x8e...", why? Is it > because it would require "many megabytes", or because it requires ROM, which > I'm guessing isn't supported by RIOT-OS?
ROM is the flash memory inside your MCU, that is where you store the actual program code. RAM is volatile and is used for storing runtime variables and buffers. Both kinds of memory are used by all RIOT applications (OT: it is possible to run an application without touching the ROM by loading the binary to RAM via the debugger. It is not very useful in a real world application, though.) The SAM3X8E has 512 kB of ROM and 96 kB of RAM. It will not run OpenJDK because the binary will not fit, and if you manage to load it (for example via external flash memory) it will definitely run out of RAM before even finishing its initialization procedure. > > And yes, I will definitely dive into Darjeeling/LLVM, but am trying to see > if I can't brute force an easier solution first. :-) Darjeeling is probably the easy solution here :) > > Thanks again! > BR, Joakim > > On 8/11/15 4:05 PM, Joakim Gebart wrote: >> >> On Tue, Aug 11, 2015 at 9:48 PM, Zac Harvey <zhar...@pobox.com> wrote: >>> >>> A quick mid-day follow up here: From everything I’ve collected so far, >>> the >>> RIOT-OS has no problem handling 32-bit (ARM-based) architectures, and so >>> there’d be nothing stopping me from getting it to run on, say, the ARM >>> SAM3X8E Cortex M3 MCU, yes? (Please correct me if I’m wrong!) >> >> Yes, the SAM3X8E is already supported in RIOT [1]. It is used by the >> udoo and arduino-due boards. >> >>> There is a 32-bit (i386) version of OpenJDK 7 available on lots of Linux >>> repos (check them out here: http://openjdk.java.net/install/). So, I >>> can’t >>> imagine it would be too difficult to get a 32-bit, Open JDK 7 compiled >>> and >>> running on an ARM chip where RIOT-OS is its underlying OS. Again, >>> *please* >>> correct me if I’m wrong, or if I’m overlooking some obvious hurdles here! >> >> The OpenJDK would probably require many megabytes of both ROM and RAM, >> this means it will not run on the sam3x8e, even if you add all the >> support functions that are required by the program to get it to run >> inside RIOT. A more realistic approach would be to take a serious look >> at the embedded JVMs that were suggested earlier in this thread >> (Darjeeling, and the LLVM based one). >> >> BR, >> Joakim >> >> [1]: https://github.com/RIOT-OS/RIOT/tree/master/cpu/sam3 >> >>> Best, >>> Zac >>> >>> >>> On 8/11/15 9:54 AM, Zac Harvey wrote: >>>> >>>> Thanks for the thorough response Joakim. >>>> >>>> I actually think 32-bit is perfectly fine, at least for my needs. >>>> Specifically I'm looking to target the ARM SAM3X8E family (Cortex M3) >>>> which >>>> is 32-bit (most Java apps can - and arguably should run inside of 4GB). >>>> >>>> Your point about Java not being able to *truly* deliver real-time >>>> guarantees is spot-on. However, there are all sorts of tricks you can >>>> do so >>>> that major collections run very infrequently. And the Shenandoah/G1 >>>> "pauseless" GC coming in Java 9 or 10 promises to reduce actual >>>> pausetime >>>> down to <1ms. That's probably not impressive for you hardcore RTOS >>>> peoples, >>>> but in Java-land that is like...the best thing...of all time...ever. >>>> >>>> A lot of IoT-type devices do not need *hard* real-time guarantees, but >>>> could greatly benefit from running existing platforms, libraries and >>>> frameworks running in JVM/Python/Ruby/etc. lanaguages. How cool would >>>> it be >>>> to run Akka on a smart device? This is likely how Skynet will come to be >>>> self-aware and enslave us all. I guess my motivation would be to accept >>>> the >>>> current real-time shortcomings of the JVM, use those tricks to minimize >>>> GC, >>>> and hold out for a few years until improvements to the core JVM (such as >>>> Shenandoah) are released into the wild. >>>> >>>> I also think such an endeavor would spark a large community of non-C >>>> devs >>>> to get heavily interested in RIOT-OS, which from what I can tell, is >>>> best-in-show in the modern RTOS landscape. >>>> >>>> Thanks again for the solid input here - stay tuned! >>>> >>>> On 8/11/15 8:48 AM, Joakim Gebart wrote: >>>>> >>>>> See my response inline below. >>>>> >>>>> On Tue, Aug 11, 2015 at 11:58 AM, Zac Harvey <zhar...@pobox.com> 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 >>>>> devel@riot-os.org >>>>> https://lists.riot-os.org/mailman/listinfo/devel >>>> >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> devel@riot-os.org >>>> https://lists.riot-os.org/mailman/listinfo/devel >>> >>> >>> _______________________________________________ >>> devel mailing list >>> devel@riot-os.org >>> https://lists.riot-os.org/mailman/listinfo/devel >> >> _______________________________________________ >> devel mailing list >> devel@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/devel > > > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
