I have this develoment board: <STM32F429I-DISCO>, ...
# kotlin-native
p
I have this develoment board: STM32F429I-DISCO, and I want to try Kotlin on it. My first idea is to skip the JVM stuff (in theory possible since you can have linux there) and try Kotlin/Native. I see here that @BradW you tried it - any luck? This ticket from 3 years ago and this thread don't give much hope, however these release notes mentioning "Experimental support for Zephyr RTOS" do give hope 🙂 Anyone could share their experience?
đź‘€ 1
Or maybe just install lightweight Linux with JVM there? Any experience from this side? My goal is to program simple robots and GUIs with my kid, nothing fancy. Basically a cheap replacement to Mindstorms NXT, with touchscreen.
n
Linux can't be installed on uC's, however Linux can be installed on many ARM based SBC's like the Beaglebone Black and the Raspberry Pi for example. Kotlin works reasonably well (via Kotlin Native) on some ARM based SBC's running some form of Embedded Linux.
p
what's SBC?
n
SBC stands for Single Board Computer.
đź‘Ť 2
Kotlin's porting system is constantly in flux. Adding support for a new target is a very painful experience where official documentation is non-existent, the porting system is a constant moving target, and bare metal targets can't be added without doing some ugly hacking (spaghetti codebase).
đź‘Ť 2
If you are looking at heading down the SBC route then I would recommend using a Raspberry Pi 2 or later with Kotlin Native via the linuxArm32Hfp target.
p
Before I invest in Raspberry, I'm trying the economic approach first - I already have this development board which in some sense is a SBC. People install Linux there, not sure how hard it is, though. The uC is STM32F429ZIT6 which is ARM-based. Do I connect the dots correctly that the linuxArm32Hfp target should work there as well?
n
Kotlin Native doesn't support uCLinux, and the device is a uC that uses an ARM M series CPU. All ARM based SBC's use an ARM A series CPU. With the Linux targets the CPU instruction set (eg ARMv7) is important since that determines whether the device is compatible or not. Kotlin doesn't support any ARM M series CPUs, only the ARM A series ones based on the supported targets. Currently the Linux targets support the following CPU instruction sets: • ARMv7 • ARMv8 • X64 • MIPS 32 • MIPS 64 In the future Kotlin might have some new Linux targets that support the RISC-V CPU instruction sets, although that would require dropping the MIPS targets in order to free up the needed resources to make it happen.
The JVM doesn't work on uC's, however there are some custom variants that do but they come with the following large disadvantages: • High CPU, memory, ROM usage • Requires using a compatible RTOS (Real Time Operating system - https://en.wikipedia.org/wiki/Real-time_operating_system ) which will use many hardware resources • Very limited hardware support • Access to a tiny ecosystem (can't access the C ecosystem) • Large hardware costs with using a JVM with each uC • The majority of the custom JVMs for uC's aren't free and come with high licensing costs
It appears that uCLinux is no longer actively maintained.
@Artyom Degtyarev [JB] - As I understand it the Kotlin team don't consider uC development to be a high priority for Kotlin. The team have other priorities that are much higher like server side (via JVM) and mobile development for example. While it would be very nice to have Kotlin working on uC's there are other platforms that are much more important for Kotlin like Embedded Linux for example, which I presume the Kotlin team would address long before looking at running Kotlin on uCs bare metal (without needing to use an RTOS).
Kotlin needs to work well, and be in a mature state on Embedded Linux devices before efforts are made to get Kotlin working on uC's bare metal. Think of Embedded Linux as being the extremely important starting point for having Kotlin run on Embedded devices. Currently Kotlin already runs on many Embedded Linux devices like the Raspberry Pi (consumer SBC - https://www.raspberrypi.com/products/raspberry-pi-4-model-b/ ), Beaglebone Black (consumer SBC - https://beagleboard.org/black ), and the TS-7970 (industrial SBC - https://www.embeddedarm.com/products/TS-7970 ) for example.
p
Thank you for the clarification!
FTR, I'm trying another path: MicroPython + Kotlin/Python backend. Looks promising so far
n
Sensible choice to make. Hopefully the Kotlin team takes a look at getting Kotlin running on uC's in the future, considering that a dynamic language can be used it should be easier to get a modern static language working on uC's.
j
i haven't hit this wall yet, but if it doesn't exist to date i propose that a docker gentoo ebuild platform is the sanest way to encompass a massive scale of build switches reaching all the way back to bootstrap and arriving at a point where individual dynamic and static libs can be specified and built with an easily learned set of configs not unlike a docker file, but completely C/make/bash/autoconf level configs. @Piotr Krzemiński it might be a touch advanced for a youngster but if you haven't looked at gentoo (specifically for the ebuilds) you can't go wrong. i use ubuntu for kde but i keep a gentoo bootstrap in docker current for systems level development when i want production bins.