Hello Everyone, I recently bought a arduino, and I would like to use crystal to program for it, I known that is not officially supported but, I still want to give it a shot for learning purposes, so I write the following blink program for arduino mega2560 using C bindings for arduino.h :
@[Link("Arduino.h")]
lib Arduino
fun pinMode(pin : UInt8, mode : UInt8)
fun digitalWrite(pin : UInt8, val : UInt8)
fun delay(ms : UInt32)
fun setup()
fun loop()
end
def setup
Arduino.pinMode(22, 0x1)
end
def loop
Arduino.digitalWrite(22, 0x1)
Arduino.delay(1000)
Arduino.digitalWrite(22, 0x0)
Arduino.delay(1000)
end
setup()
while true
loop()
end
using this to compile and returning a .o object and a linker command:
The Arduino library is something else entirely, and they didnât make it easy to integrate: thereâs no libarduino.a or similar () and itâs a mix of C and C++ (). I have a minimal experimental integration⌠somewhere.
I think the Arduino IDE builds each required source file as needed for the exact CPU as it builds and links the project.
Hello again thank you for the good references and sorry for the late reply but I didnât have the time to test and reply.
I achieved to generate some .hex files but without the binds for Arduino will be terrible write anything a little more complex, maybe I should try to write some libs in my free time.
Thank you all again for your help, and I really look forward for the crystal evolution in the micro-controllers world
Digging into the arduino sdk is indeed gnarly! Nothing is documented, dozens of boards have arbitrary pinouts and pin-abilities. The IDE performs hijinks to manipulate source code pre-compilation, and scripting avr-dude itself is rather brutal.
But I think this is one of the ways that Crystal could really shine. Itâs low level enough to run on a dedicated processor (ruby canât do that), and itâs high level enough to be used and built-on by humans (where C struggles). There have been attempts at embedded python, etc, but that requires new hardware.
Embedded programming is a terribly managed ecosystem of software. Part of what Arduino managed to do so many years ago was hide most of that brutalist approach to software behind something beginner friendly macros and functions, and a toolchain that supported development.
About 15 years ago I had the good fortune to teach middle schoolers (and even much younger) to program Arduino boards and it was amazing to see them adapt and execute within the clumsy Arduino IDE all because the SDK (and broader ecosystem) provided a meaningful set of tools they could understand.
What was really disappointing to see was when a student wanted to do more but that required jumping into âreal codeâ â deep C crap thatâs difficult to read even for a seasoned software professional. The student had a vision for what they wanted to accomplish, but when shown what was required to make it happen they would just surrender: âcan you do it for me?â or worse they would give up entirely.
Raspberry Pi comes along and offers python as a native tool, and itâs fine but still suffers from a complete lack of developer ergonomics â partly because itâs âpythonâ and partly because itâs a thin layer on top of the brutalist C code which powers it. And now, instead of running a dedicated processor, itâs running a whole operating system, with all the pitfalls and pain that accompanies it.
This is a mere dump of my local shard, thatâs working with the deb packages on Ubuntu 20.04. I canât vouch that it actually works, especially the manual C++ bindings
And there are zero support for interrupts or PROGMEN (to put things in address space 1), and the bindings only care about atmega328p (the classic Arduino Uno). Youâll have to fix or add support for other boards & tweaks.
The libarduino-core.a must be built for each and every CPU. The Makefile in the shard can be used to do that. It would be great to have some more generic.
Zephyr is an OS. One that targets microcontrollers, but with enough memory and CPU power such as the RP2040 or ATMEL SAM (both ARM based) which includes the SAM based Arduino boards, but not the ones based on ATMEL AVR (The Uno R2 is 16Mhz, 32KB flash and 2KB RAM).
Iâm surprised that it supports some ESP32 though, but they seem to have more CPU power, flash and ram than the usual AVR.
That doesnât mean it wouldnât be nice (quite the opposite), but it wonât cover all the embedded spectrum âbut still cover quite a lot!