https://kotlinlang.org logo
Join Slack
Powered by
Is Kotlin/Native capable of compiling for and runn...
# kotlin-native
l
Is Kotlin/Native capable of compiling for and running in constrained embedded systems such as microcontrollers? If it's currently not, is this capability planned in the future?
☝️ 1
@msink What do you call "heap memory"? I mean, any microcontroller that has RAM can have "heap memory", right? Also, how can I know which chips have or don't have clang compiler support?
m
Well, I mean - most microcontrollers not use heap - all data is statically allicated in compile time or some at boot time. It's common n realtime systems.
l
@msink But this can be done in Kotlin/Native too with mutable properties, right?
m
Well, maybe, but Kotlin too heavy depends on heap for hard realtime applications. IMHO.
e
Who said hard realtime? Most of the embedded market is not hard realtime at all. I’d say a small minority is.
Anyway, any kind of hard realtime heap-less code is going to be vebose, messy and hard to support. You can write such code in Kotlin, too. Kotlin is great in that it allows you to write beatiful code (you have to sacrifice some performance, though), but it does not prevent you from writing ugly code.
l
Could you give two meaningful examples or define more accurately the difference between "hard relatime heap-less" and "not hard realtime" applications please? I'd like to know which usages could benefit from beautifully readable Kotlin code and which ones I'd be forced to use something like C/C++ or worse, Assembly
e
hard-realtime usually has to do with direct control of some critical hardware. Automotive controllers, industrial, etc
Your “regular” embedded is something like home automation / IoT. It has to be reasonably fast like any other software, but no hard-realtime guarantees are usually needed. That is where you don’t have to use C/C++.
ARM Cortex is a good target for those. Cheap, lots of RAM, supported by clang. Take a look at Arduino Zero (at its clones) specs, for example.
➕ 1
For embedding into projects Arduino Zero Mini is small (and cheap) enough.
But there are lots of other ARM Cortex M0 boards out there, too.
l
For hard realtime usages such as automotive controllers, isn't there any alternatives to C/C++ that allow for more readable code (which means less error-prone, therefore safer)? Kotlin is the cleanest language I know yet, hence my interest in using it for embedded systems in place of C/C++ (I have yet to master those languages also, I only know a bit of C right now, and I already have a hard time with all those potential undefined behaviors that I see as pending potential malfunctions in my application
e
Rust is trying to become that language. With mixed success. It is non-goal for Kotlin/Native to get into hard-realtime space
👍 2
l
Why is it non goal for Kotlin/Native?
e
See, it is inherently complex. You have to write smart code to make sure all your memory is pre-allocated, etc, etc. In particular it means you have a lot of mutable state, you abolish functional paradigms for performance. Kotlin goes in completely opposite direction.
☝️ 1
👎 1
If you just convert a random piece of C/C++ code to Kotlin it will get littered with 
?
, and 
!!
, and 
var
. This is a clear sign that the code is not idiomatic Kotlin. You have to embrace immutability to become idiomatic. You have learn to program in a different way, starting from how you design it. This, necessarily, leads to extra memory allocations, which is a no-go in many hard-realtime apps since it is hard to predict how long allocating/deallocating memory is going to take. Not that it is slow or takes a lot of memory. Not at all. It is just not so predictable. It is Ok for vast majority of apps, though, so you can concentrate on the logic of your app, instead of worrying about memory.
l
But it may allow code sharing with multiplatform support which makes sharing simple things like constants much simpler. Also, code for a single responsibility µcontroller could be so short in Kotlin, even with mutability that it could still benefit readability over C/C++ although less idiomatic, am I right?
e
If you program in C/C++-style it will not be either readable nor safe. It has to be idiomatic Kotlin code to accrue Kotlin benefits. And it will work perfectly fine for most reasonable uC embedded applications.
Look at that ARM Cortex M0 with a typical budget of 32Kb RAM and countless Flash memory for program code. It is way more than enough for most of applications it is used in. Whether you are writing code that controls your coffee-machine or automating your garage door, I bet you will not run out of resources even if you just program in idiomatic Kotlin and don’t worry about your memory.
Of course, if you designing cheap blinker that is embedded into snickers for kids, then it is a completely different story. Those uC typically do not even have support for standard C and so constrained (can have just 32 bytes of RAM), that you’d be most likely programming them in assembly. It does not really matter, since the code is so small.
m
Don't know chips with 32 bytes, i8051 have 128... :)
e
This is quite large, though, for a blinker. Chinese blinkers use even smaller (and much cheaper) uCs
m
We still use 8051 in production. Well, now just in one very legacy device, but still...
l
I don't intend to program for 32bytes of memory uC, at least not in Kotlin, but I want to program for power efficient uC for application close to automotive requirements, but with a stricter power constraint: the systems need to run on an e-bike like battery, withtout draining it because the power is needed for pedal assist. What I want to do is smooth pedal assist for a velomobile (this is basically a 3-4 wheeled bicycle, with aerodynamic fairing that allows 60mph+ speeds solely on pedal power thanks to reduced air drag), a BMS (battery management system), and add a few sensors (force sensors, accelerometers...) to adjust the pedal assist based on hilliness and pedal power input. For the pedal assist to be as smooth as possible, it needs to be as realtime as possible, hence my request. I also have more complex usages for the same project in mind such as electronic rear-view mirrors adjustment, safety features, but overall in this project, the cost of the uC is not a problem as it's very unlikely to be the most expensive thing in a 4wheel velomobile
I'd really like to make this electric assisted velomobile thing, and I see a clear path on building one either from scratch, or on an existing one such as the Quattrovelo, except for the embedded systems part. I have a comfortable experience in Kotlin (1y+) and Android (3y+), but I'm struggling to find the appropriate tech for this project with embedded systems. I know I will use Kotlin for the driver/rider UI either with Kotlin/Native without OS and some ARM based system, or with a Linux with Kotlin/Native still, or with Android Things and Kotlin/JVM, but I know some parts mentioned earlier are likely to require "hard realtime" features, and I'd like to know what to use, and I'd prefer Kotlin if possible so I can reuse code, setup testing environment that can run on desktop or even Android device, and avoid programming errors as much as possible
m
Then maybe Raspberry Pi? It's already supported by Kotlin/Native.
e
RPi is quite power hungry. That is good application for ARM Cortex Mx, but Kotlin/Native is not currently supported on them
l
@elizarov Do you mean support for it is planned?
e
We’d love to support it, but we don’t have resources to support it in short term. Would love community to step up here.
l
@msink I already have a Raspberry Pi 3 Model B I got at an Android Things workshop at Android Makers Paris 2017, but I know it's power hungry, so I don't consider using it. RPI is meant to run with the provided power supply, which is rated at 3A max, which means up to 15W (about 1W avg, so still 5W just to keep lights on). I plan to put a small solar panel to keep the battery from draining. The system should keep running for months off solar light (remember the power is meant for pedal assist), so the power consumption needs to be as low as possible, below 1W for sure. (The batteries will total between 100W and a few kW for long range trips, but again, this power is not to be wasted)
@msink Why do you talk about toolchain support and som .def files? I didn't get your point and the link with the subject of this thread, maybe because I lack knowledge/experience in native development, sorry
m
Currently if you want to add new target to K/N - you have to patch compiler sources. But if it were in some .def file - you just create single text file, and point compiler to it. I really like how it works in meson-build.
👍 3
u
But meson-build is a build tool. It still uses different compilers / compilers with support for different targets that someone coded
m
K/N too uses different versions of llvm, linker and so on. But how to use them - hardcoded in K/N sources.
l
@msink I see. Please, could you add an issue here on GitHub with all the details you know to get this fixed? https://github.com/JetBrains/kotlin-native/issues
m
Ok, will do tomorrow
👍🏽 1
I suggest to start from Zephyr RTOS https://www.zephyrproject.org Maybe I even try it myself, but no promise.
6 Views
Open in Slack
PreviousNext
Powered by