Say goodbye to compatibility issues and hello to seamless integration! MicroEJ has revolutionized the game with its Virtual Execution Environment (VEE), now supporting Managed C. That’s right, C code can now run in its own container, alongside Java and Javascript applications through MicroEJ’s managed code framework.

MICROEJ VEE ensures your C code is kept safely in its own container, ensuring a smooth experience for your legacy code and new applications alike. And the best part? MICROEJ VEE virtual machine is ultra lightweight, with a footprint of only 50 kB – perfect for microcontrollers and microprocessors with limited memory.

Discover More with Fred Rivard, MicroEJ’s CEO, in an Exclusive Interview with William Wong from Electronic Design!

 


— TRANSCRIPT —

William Wong – Java is a major part of Android and it is used in a lot of applications in general. So, Fred, could you tell me a little bit about VEE because that’s a specialized virtual machine for Java, isn’t it?

Fred Rivard – It’s more of a container for managed code, and of course in managed code you can include the Java language. There is a large community of Java programmers, who now can benefit from microcontrollers. The container itself weights 50Kb, so it fits in most commercial and cost-effective MCU’s, covering low power microcontrollers below $1, to MPUs powered by Linux ranging from $10 to $15. We provide our container to any kind of microcontrollers, supporting Java, Javascript, Kotlin, and now Managed-C.

W.W. – So can you tell me a little bit more about Managed-C, because unlike the languages you were talking about, it doesn’t have garbage collection or anything like that. How does that work in terms of isolation, and how does it cooperate with the other things that are out there, like Java applications?

F.R. – I would say we provide the allocation, but it remains in the boundary of the container, so there’s no way for you to escape the boundary of the container. So, you can mess up yourself, but only yourself. You won’t crash the rest of the system. We also provide, inside the container, a sandboxing mechanism for apps. You may have a component written in Managed-C, another component written in Java, and they will be protected one from each other. This makes things extremely safe. You can also reuse such components in a totally secure and reliable way.

W.W. – Now, Java has the managed memory support, whereas C does not. How do you make the two talks together? Do they have a shared memory system? You know, how do the heaps actually work?

F.R. – Basically, it’s a shared heap and objects from C [i.e. allocated structures] are addressable directly from the Java space. The Managed-C and the Java do not point to each other. There is no overlap. You have this notion of C-structure in Java, so you can pass along such objects. The sharing is done with a zero-copy strategy within one heap (one piece of memory).

W.W. – Excellent. Now you also mentioned (actually, you hadn’t mentioned it but we talked earlier about) the fact that you utilize things like ahead of time compilation for the Java and you can also essentially have constants or predefined objects and structures both in C and in Java available to you and stored in Flash instead of RAM.

F.R. – Well, as you know, we try to save space, especially in the RAM, which is a costly part of a microcontroller or embedded system. There are objects that are constants, that really don’t need to be recreated at boot time because their values will not be modified by the application. We have tools that allow you to detect such objects. Of course, the programmer can also create its own set of static objects, and have them “created” within the flash just along with the code itself. When the system (the virtual execution environment) starts, these objects already exist, either from C, JavaScript or Java, which save a lot of CPU at the beginning, and also save some RAM memory. We have a third shared heap with the native C, which is the code that is running below the container (the virtual execution environment). This is the immortal heap where the managed code can share data with the unmanaged code using a shared memory. The typical use case are buffers of the drivers (for displays, or such kind of things).

W.W. – Because this is the containerized system, I’m assuming that you can mix and have various of numbers of containers and number of different kinds of applications. So, you could potentially have two isolated C applications and a couple of Java applications depending upon what you’re building.

F.R. – You are extremely right. That’s exactly it and you are also allowed to load and unload code. We have the capability to link at runtime those little apps or components, and we can do it without sending over all the [link] symbols. We have an ID mechanism, which allows the code to already be inside the device. The code that is getting loaded and linked to the boardis to be extremely compact based on IDs only, and not symbols, which saves bandwidth and also RAM, flash, etc.

W.W. – I can see a number of use cases for this. Would one of them being taking up a standard IoT driver written in C and incorporated into a managed code application?

F.R. – A driver is something hardware related, so probably not. What you are going to put into the managed code is something that is more independent from the hardware, something that you would capitalize across different hardware or hardware innovation, etc. When you take a full communication stack, the upper-part of it would make sense to be turned into managed code. The low-level will remain in assembly, close to the hardware, because in fact this is some kind of a hook to the hardware, like a handle. There is a boundary here, between what you want to capitalize across hardware evolution versus what is really taking advantage of the hardware itself and will be changed across hardware evolution.

W.W. – Oh, very good, it sounds like a very useful platform. Thanks for filling us in on VEE and Managed-C.

F.R. – Thank you very much.

.

— END OF TRANSCRIPT —