Does kotlin native support embedded arm targets? I’m guessing the size of stdlib in kotlin would be ...

# kotlin-native

[andrew]

Does kotlin native support embedded arm targets? I’m guessing the size of stdlib in kotlin would be hefty

[hfhbd]

What do you mean? There is linuxArm64 for example, and other arm targets too. But the stdlib isn’t the problem, other Liberiers are, for example missing coroutines support. https://github.com/Kotlin/kotlinx.coroutines/pull/2841#issuecomment-1298377277

[andrew]

for non linux devices, say one with a custom os on it, or an embedded iot device

[andrew]

My use case was I was thinking about writing bindings for https://play.date/ but realized there’s probably a not a nostd option like rust has

[napperley]

Are you referring to uC's?

[napperley]

All K/N Linux ARM targets are aimed at ARM devices running some form of Embedded Linux (eg Raspberry Pi running Raspberry Pi OS).

[Arkadii Ivanov]

Depends on the use case, but I guess not only the size of stdlib may be problematic. Also the lack of structs and so excessive use of heap.

[andrew]

@napperley afaik, this isn’t linux

[andrew]

@Arkadii Ivanov yeah, that’s what I figured…. I was thinking for a split second that I’d write bindings, but that split second turned to “hold on a minute”

[ephemient]

https://blog.jetbrains.com/kotlin/2018/02/kotlinnative-v0-6-is-here/

Also, we finally provide an ability to create Kotlin/Native programs aimed for embedded targets, such as STM32-based microcontrollers (using Zephyr Project kernel). Note that support is still experimental so your mileage may vary, and there are some shortcomings around C interoperability, which will be fixed in upcoming releases.

that's the most "embedded" target for K/N for now. I haven't heard much about it since then nor have I used it, so I don't know what state it's in though

[napperley]

That Zephyr target will likely be dropped in a future Kotlin release if it hasn't been dropped already.

[andrew]

This uses STM32 afaik

[andrew]

With an ESP32 as a coprocessor I think, for Wifi and BT

[andrew]

If it is being dropped then it probably isn't worth it

[napperley]

Zephyr ( https://www.zephyrproject.org/ ) BTW is an RTOS. Many STM32 based uC's are supported by the RTOS.

[andrew]

There's the STM32 that powers it

[napperley]

Definitely doesn't look like a development uC. Which ARM architecture does it use?

[napperley]

Considering the uC development situation with Kotlin, unfortunately you will need to use a different programming language like C for example 😦 . Next years Kotlin conf might see the situation improve, if the Kotlin team make an announcement about Kotlin officially supporting uC development 🔮.

[napperley]

Hypothetically if Kotlin did officially support uC development then the bare metal approach would be taken to minimise the performance footprint of Kotlin uC applications, and to keep the build process as simple/quick as possible. Also a decent amount of high quality documentation would be provided on doing uC development with Kotlin (via Kotlin Native), which would cover best practices and optimising performance. A new bare metal target would be added to Kotlin Native called armv6-m, which would cover the following ARM based uC's (including the Raspberry Pi Pico, and any uC's that use the RP2040 uC chip) using one of the following CPUs:
• Cortex-M0
• Cortex-M0+
• Cortex-M1

[Landry Norris]

The command line compiler has an option to disable the standard library, but the compiler requires some stdlib classes and methods to be present. You'd have to create a kotlin package and implement those yourself (ended up being almost the whole stdlib last I tried back with 1.5.31). From there, you can set the target as linux* for your architecture, then link against a binary of libunwind, libpthread, and a few other binaries that it expects to get from linux. I almost got a basic hello world program running on bare metal x86 once, but switched to some 'more practical' projects after a while.