is there anyone from JetBrains in this channel. Anyone who is doing active development on language support from embedded with Kotlin? Just wondering as the questions here go unanswered.

The dream for Embedded Kotlin would be to see JetBrains marry the Kotlin compiler with their recent Plugin love for the excellent PlatformIO Embedded Toolchain on Clion - entailing that Kotlin/Native code could be mixed in just as fluently as C/C++ for Microcontrollers of all sizes.

The last reports we had (you don't have to scroll up far...) were that binary sizes were still unexpectedly large for minimal programs coming from Kotlin/Native. Maybe the new compiler offers some hope...

📢 If there's anyone out there, in the black inky void, holding a flame of hope for Embedded Kotlin (especially within

[JB]

) then take a look at the potential here: https://www.espressif.com/en/news/ESP32_C3 The massively popular Espressif ESP8266 chip is getting a spiritual successor in the form of their new C3 chip. The interesting thing for Kotlin is that, whereas before the ESP8266 had a proprietary Tensilica core, the new one is RISC-V based. This implied a shift surely opens up easier pathways for a Kotlin / PlatformIO / C3 three-way cuddle puddle - a traction-gainer for sure 👍 At this point the response might be 'Kotlin isn't suitable for a platform of this small size' to which I'd say '_why shouldn't it be?_' - Kotlin/Native should theoretically be able to compile simple enough programs to MCU sizes; just as C++ scales both large and small. Maintaining Embedded as a goal, especially for the new IR compiler and linker, could bring both direct and side-benefits, on Kotlin's epic journey to platforms far and wide.

K ❤️ Please upvote: https://youtrack.jetbrains.com/issue/KT-44498 ❤️ K

what is Kotlin able to do on embedded systems? Like is it able to replace c++ for the arduino and python for the raspberry pi?

That thing in the background looks like a sort of embedded system… blob thinking upside down

hi folks, FYI: together with @SerVB we work on transpiling Kotlin to Python (technically, a new Kotlin backend). Using Kotlin on embedded systems is a great use case for this project - I realized it myself, when I started playing with my STM32-based board 🙂 if you want to learn more and/or support us, please head to: • the repo: https://github.com/krzema12/kotlin-python • related forum thread: https://discuss.kotlinlang.org/t/idea-python-backend/19852 • related YouTrack issue: https://youtrack.jetbrains.com/issue/KT-34074 • related Slack channels: #python and #python-contributors To sum up the status: it's not usable yet, but we got some nice momentum and with our current pace and about a year, it might become a real thing!

There is an article called Multilingual blink for Raspberry Pi Pico ( https://www.raspberrypi.com/news/multilingual-blink-for-raspberry-pi-pico/ ). Note that the Rust version is the most verbose by far 😱. In case anyone is wondering Kotlin isn't available for uC's (Microcontrollers), therefore the Kotlin version is absent (missing in action). All questions about that, and other stuff relating to Embedded development with Kotlin should be directed to the Kotlin team the next time they have a Kotlin AMA (Ask Me Anything) session on Reddit. Who knows, there might be a Kotlin team member busy working on a side project to port Kotlin to a uC 🙃 . JavaScript already works on the Raspberry Pi Pico, no pressure 😅. Slack Conversation

Hello everyone. Anyone here work with kotlin + raspberry pi???

Discussion on Kotlin for uC development: https://kotlinlang.slack.com/archives/C3SGXARS6/p1660527632546669?thread_ts=1660236386.407379&cid=C3SGXARS6

Some interesting findings have come out of the Eclipse IoT survey, which would affect how IoT is approached with Kotlin. One key finding is that ARMv8 devices are gaining ground, and have for the first time overtaken ARMv6 devices. An important implication of this is the need to have a Kotlin Native compiler for Linux ARMv8. Having this compiler would make it significantly easier to do development with the Linux ARM targets (linuxArm64 and linuxArm32Hfp), especially when combined with an IDE like Fleet ( https://www.jetbrains.com/help/fleet/install-on-a-remote-machine.html#628d8f04 ). Sure, one can do cross compilation to cover the Linux ARM targets, however that is often a painful experience.

Could Google's commitment to Android on RISC-V influence Kotlin/Native team's priorities around more flexible targeting of different (and embedded) architectures? https://arstechnica.com/gadgets/2023/01/google-announces-official-android-support-for-risc-v/

Some Kotlin Native targets are set to be deprecated. One of the deprecated targets is linuxArm32Hfp. If you want to prevent the linuxArm32Hfp target from being deprecated then leave a comment in this Kotlin blog post: https://blog.jetbrains.com/kotlin/2023/02/update-regarding-kotlin-native-targets/ Do note that the list of supported targets is not set in stone (is subject to change), and there is a chance to prevent the linuxArm32Hfp target from being deprecated. If no objections are raised then the Kotlin team will do this unopposed.

With K/N having been merged into the Kotlin code base a while back where are the K/N parts located? I am making an attempt to port Kotlin to the RP2040 uC (will be an unofficial Kotlin target called rp2040, IF the porting is successful). Unofficially there was a uC type target (relied on a real time OS; can't remember what it is called) that was part of the Kotlin code base, does it still exist and if so where is it located in the Kotlin code base?

After wrestling with a fork of the Kotlin code base it now successfully builds (took around 16 min) a custom version of the K/N compiler that has unofficial support for the rp2040 target 💪. Next stage is to test if the K/N compiler can generate a static library file via the rp2040 target.

Wow Nick - I don't know how much more work is implied to have something - anything - running on the RP2040, but looks like you're really digging into it now 👏 !

If you need an RP2040-toting Kotlin Enthusiast who's more-or-less in your time zone, to run/double check anything at any point, please feel free to DM me.

There is a major roadblock with getting the Kotlin Standard library generated for the rp2040 target. A related issue can be found here: https://youtrack.jetbrains.com/issue/KT-57278/Missing-Option-To-Build-Kotlin-Standard-Library-In-Kotlin-Native-Form

Some assistance is needed (someone with good C++ experience) in resolving a issue with building the K/N runtime for the rp2040 target: https://github.com/napperley/kotlin/issues/2

@napperley @darkmoon_uk Any of you is at #kotlinconf?

Sadly not this year... Next time 🤞

Hope you have a blast though @louiscad 👌🚀

Do you have any experience with running Kotlin on a LEGO Mindstorms EV3 set? Either JVM, Javascript or native when it comes to runtime

Hello. I would like to develop a application to write/dump a SPI flash memory. I have a FTDI here and I want use it to communicate with SPI flash. Is it possible use Kotlin to accomplish that??

not kotlin but kotlin colored

A screenshot of a Kotlin Native program running on a Debix Infinity SBC 🎉 .

Blinking LED using a Kotlin Native program running on the Debix Infinity SBC 🎉. Took ages to figure out which GPIO pin number to use, which isn't obvious ( GPIO documentation: https://www.debix.io/Document/manual_info/id/5/q/gpio.html#b117 ; key hidden info in blog post: https://www.debix.io/Software/blog_info/id/60.html ; subtle info is in the Use of GPIO section ).

Microcontrollers are known as the graveyard of high level languages 🪦 . Some languages have tried to target microcontrollers, but have eventually died/faded away. Some of the reasons high level languages have failed include the following: • Using a GC that isn't suitable for uCs (Microcontrollers) • Relying too heavily on the Heap for storing data • Bad quality toolchain (toolchain size is too large to download, can't statically link everything into a single binary etc) • Using a standard library that is too heavy weight (e.g. code size is too large) • Generation of binaries that are too large in size • Reliance on a VM (large code size, high RAM usage etc)

Could this 2 year old development still carry potential Kotlin on Xtensa (ESP32 et al)? Looks like the LLVM fork itself, is here