kotlin-native on arduino

[ghost]

based on this

• iOS applications (reusing code with Android)
• Embedded systems/IoT (e.g., Arduino and beyond)

I wondered if there is progress?

Just read that avr-llvm was merged into the main tree some months ago and Kotlin-Native on iOS is already working.

thanks

[StefMa]

Hi,

I started a very basic "mobile sample" here:
https://github.com/StefMa/kotlin-native/compare/master...StefMa:mobile_sample

There is a "shared library" with pure kotlin code. The iOS project will
create a framework on building of that shared lib and include it.
The android project will create a jar on bulking of that shared lib and
include it.

Its far from perfect. But I shows you how to start with both platforms and
a shared lib written in kotlin...

On Jan 14, 2018 9:38 AM, "monouser7dig" [e-mail] wrote:

based on this
https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/

• iOS applications (reusing code with Android)
• Embedded systems/IoT (e.g., Arduino and beyond)

I wondered if there is progress?

Just read that avr-llvm https://github.com/avr-llvm/llvm was merged
into the main tree some months ago and Kotlin-Native on iOS
https://blog.jetbrains.com/kotlin/2017/11/kotlinnative-v0-4-released-objective-c-interop-webassembly-and-more/
is already working.

thanks

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/JetBrains/kotlin-native/issues/1229, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AJwYezlqYBvmLxGKpz7_-A_qdd8CQQJQks5tKbzogaJpZM4RdhQn
.

[msink]

Currently Kotlin/Native application require at least 200-300 kilobytes of memory - will not fit in arduino, needs something like stm32f4.

[olonho]

Yes, embedded targets are being worked on, however AVR-based Arduino are too low end from both CPU and memory standpoints.

[MRezaNasirloo]

Golang is already on 34 different platform including arduino uno with 2KB of SRAM. I hope you guys figured out soon 👍

[ghost]

golang is not on Arduino, gobot only talks to Arduino but does not run on Arduino, otherwise that would be nice as well but does not seem to be feasible.

[Arkuda]

So, if use esp8266/esp32 you can try join https://github.com/olonho/carkot/tree/master/translator and https://www.esp32.com/viewtopic.php?t=9226
(for short: first its a kotlin to llvm translator, second its a llvm for esp8266/esp32)
But, its very hard.

[thawkins]

Go on ardunio uno using llvm

https://github.com/tinygo-org/tinygo

[msink]

It supports ARM based microcontrollers and WASM, same as Kotlin/Native already did year ago.

Hm, for AVR it uses avr-gcc for linking.

[carlos4242]

FYI, Go (https://github.com/tinygo-org/tinygo), Swift (https://www.swiftforarduino.com) and Rust work on Arduino UNO and other AVR 8 bit microcontroller based boards, although they are of course much more limited in resource usage than on larger platforms. I wrote Swift for Arduino, I know Ayke who wrote TinyGo and the AVR rust/AVR llvm team (Dylan and others) plus I helped write a little of the AVR back end, so I'm fairly familiar with the issues. I am not experienced with Kotlin. My guess is, like those three existing languages for Arduino UNO, the challenge would be fitting standard libraries into the constrained resources of the device. With S4A I had to do a lot of careful work to get standard features to fit. It's definitely possible to get the language principles to work though, Kotlin is a compiled language in this paradigm and from what I know, is quite similar to Swift in many ways so it should be possible to make efficient code.

[sbogolepov]

Hello everyone!
It's unlikely that Kotlin team will work on Arduino support in the foreseeable future. The reason is simple: we have only so many resources :)
However, we have some ideas about refactoring compiler and surrounding tooling to make it extensible, so users could experiment with their own targets without much hassle. But this refactoring is big and touches many parts of Kotlin project (compiler, Gradle plugin, cinterop, kotlinx.libraries, etc.).
So before starting to work on such tremendous task we need to understand do our users really need such feature and how flexible it should be. That's why we created KT-43974.

According to https://github.com/JetBrains/kotlin-native/issues/4079 I'm closing this issue. Feel free to create a new issue on YouTrack or add your use-case to KT-43974.