21–27 of 27 posts
Just goes to show how important it can be to read code in completely different fields than the one you're working in. Some problems are common for others so they've already been solved. Knowing that a solution exists is half the battle.
Earlier quoted context omitted.
I didn't know about FreeRTOS, interesting! I don't think CBinding.jl is an option, since the whole point of the arduino is that the julia runtime can't run there (and doesn't fit in the first place - there's not enough RAM and swapping to the SD seems bad). Linking with C created .o files should work though? I don't own any ESP32, but if that happens, yes I'd very much like to try!
Would you accept an ESP32 for your edification? No strings attached. Email me I think CBinding.jl could be helpful if one wanted to write a target-specific shim library in C and link against it. I would expect that some of the glue is going to be easier to write in C than in Julia, and you can play some tricks with macros to create bare modules [1] within some kind of `@arduino_setup`/`@arduino_loop`-style blocks. Ed…
Off topic but related: I played around with getting Nim running on an Arduino. 1. I found a critical bug almost immediately, but Andreas fixed it within 24 hours, and was super helpful. 2. Once the issue was resolved, it was surprisingly straight forward to get it running. I started by wrapping the arduino libs, and quickly shifted to wrapping the AVR libraries directly. One take away was: Nim (and Julia) are likely…
Cool! How big were the emitted nim binaries?
I use Julia as my main programming language and I learned so much from reading this. I never knew Julia had Base.llvmcall, good to know! Just goes to show how important it can be to read code in completely different fields than the one you're working in. Some problems are common for others so they've already been solved. Knowing that a solution exists is half the battle.
Conveniently, it's also pretty easy to check how any LLVM IR you've added manually with `llvmcall` is fitting in with the Julia-generated IR around it using `@code_llvm`.
This is very promising for embedded control applications. Bootstrapping this with a simple allocator and even something as basic as FreeRTOS [1] combined with CBinding.jl [2] for portability would be game-changing for many applications, and directly compete with e.g. MathWorks' Arduino Simulink target [3]. ESP8266/32 next, once LLVM support [4] lands? [1]: https://microcontrollerslab.com/use-freertos-arduino/ [2]: ht…
I didn't know about FreeRTOS, interesting! I don't think CBinding.jl is an option, since the whole point of the arduino is that the julia runtime can't run there (and doesn't fit in the first place - there's not enough RAM and swapping to the SD seems bad). Linking with C created .o files should work though? I don't own any ESP32, but if that happens, yes I'd very much like to try!
The default arduino toolchain, which is a g++ wrapper, supports C++, even though the whole system only has only 1 kilobyte of RAM. The C++ 'new' operator does seem to be supported, so I assume it has some kind of heap allocator - although I imagine that when you've only got 1 kilobyte to play with it gets quickly eaten by the allocators datastructures and C++ vtable pointers, not to mention the impact of fragmentatio…
Off topic but related: I played around with getting Nim running on an Arduino. 1. I found a critical bug almost immediately, but Andreas fixed it within 24 hours, and was super helpful. 2. Once the issue was resolved, it was surprisingly straight forward to get it running. I started by wrapping the arduino libs, and quickly shifted to wrapping the AVR libraries directly. One take away was: Nim (and Julia) are likely…
> And the Arduino codebase could use a healthy refactoring. So could Nim's stdlib and compiler backend, but the leaders have no intention of doing that, and never have, which is why there is a hard fork.