Dinghy with ARMv7M (Ledger Nano S)
vhnatyk opened this issue · comments
Targeting Raspberry Pi is definitely cool, but what about going further to ARMv7M ?!) Investigating it right now - but if you see any obvious immediate blockers that I'm missing, would be very thankful to get notified in advance before investing too much 😃
Hey !
One thing to know is, dinghy sweet spot is CPU-class devices, where you will expect a full-fledge operating system (so ios and android things, or single board computers like the pis, or imx7 and imx8 and many others). Dinghy works by copying the executable to test on the device filesystem, whether is is some apple proprietary protocol, android adb or plain ssh/scp, then run it and capture the outcome somehow.
I am not a specialist, but my understanding is the ledger nano S do not belong to this category of devices, but rather the MCU with no operating system, just a single applicative flash. There are other tools around (like xargo) that are better suited for this task.
My optimism was based on this ("You don't need Xargo...") - and I planed to disable using std with [no_std] . But the the thing I'm trying to compile uses 300+ crates - some of them are using extern crate std; I thought I can leverage using Dinghy for crosscompilation and abstract deployment and results capturing steps(by running debug session or, well, at least just run the produced binary) Seems like Ledger doing the same with their C SDK and sort of OS called BOLOS
Well, you would need to extend dinghy greatly, in a direction where I am not sure we want to push. The main idea behind dinghy was "please run your crate tests on your smartphone once in a while". Ssh support was easy to add for single boards cpus, so we added it.
Dinghy actually plays two main functions, and we are actually thinking about splitting it in two now that cargo gets better scripting friendly interfaces.
First main function is toolchain setup for cross-compilation. dinghy role is limited to discover toolchains in places where they usually are (or from a configuration file), then setup the right environment variables before handing the work over to cargo. Something that you could typically solve with the right TARGET_CC and CARGO_ARM_***_LINKER variables before calling cargo with the right target.
Second function is deployment and running for ios, adb and ssh devices. All of them rely on the device running an actual operating system, putting the application somewhere on the filesystem and launching it. Once again, we try to discover whatever can be discovered (if adb is in the path, if an ios device is connected, ...), but ultimately, dinghy just hand the job over to something else. iOS excepted, this would be way easier if cargo had a clean way to specify an arbitrary wrapper to run tests, programs and benches (basically a wrapper script, plus some info about path and project structure to known what need to be copied to the device).
So I'm not too sure about how to fit no_std boards in that picture. What do you think ?
Yes, I understand that you needed a tool for what you need it) And basically it's not feature request - I've had an amazing experience with Dinghy, regardless of little quirks here and there:) And now I see ARMv6M and ARMv7M. And I just want the same experience on just another platform (oh well just a little M 😄) I have over 300 crates as dependencies - who cares! It's a bit of sarcasm of course - but in general, I just want to be able to add M to a target 😈 . Basically, Xargo seemed to be(part of) such a tool at first - just set a toolchain path var and go. A tool to magically turn the code into something (at least theoretically) runnable on Cortex-M - like a Dinghy for mobile, but seems it's redundant now and besides that, it doesn't work anyway for what I'm trying to do 😶 Seems like I will have to do everything manually at first and then will see if I can fit that into Dinghy to simplify embedded development on Rust for anybody, including myself 👍 ) Anyway thank you very much!