**** BEGIN LOGGING AT Wed May 04 02:59:56 2022 May 04 09:53:25 jfsimon1981: fortunately Etcher is available for Windows, Mac, and Linux... so that part is all the same :) May 04 09:53:38 set_: ? May 04 09:55:08 you're gonna have to be a bit more specific than "that lib" May 04 10:02:08 Yes i forgot about this, i used it a while ago May 04 10:02:14 Thanks May 04 12:44:54 Hi May 04 12:51:03 I recently bought a beagle board black I am exploring poossibilities. I have seen we can run script in js and python, that's cool. I am a Rust developper too so I would like to program beagleboard in Rust. As memory is pretty limited on the board I consider to cross compiling my program from my OS (I have linux and mac os) but in order to avoid installing a specific toolchain on my systems, I consider to run linux in a Qemu arm instance. If you have any exp May 04 12:51:03 erience doing this(VM install or cross copilation from x86 arch) I will be glade to ear from you. May 04 13:03:23 Midjak: how about this? https://github.com/cross-rs/cross May 04 13:04:46 wasn't hard to find by googling rust and cross compilation (and ignoring any results that are about cross-compiling rust itself) May 04 13:05:20 Did you try it ? May 04 13:05:45 nope, like I said I just found it by googling just now May 04 13:06:08 I try to cross copile on mac os and linux but linking fails May 04 13:07:45 yeah, that's usually the biggest pain when cross-compiling May 04 13:09:08 one way is to use a debian host system, same debian release as what's on the beaglebone, and then install relevant -dev packages for the armhf architecture May 04 13:09:15 yes I can try corss-rs but I have doubt about how it is able magically to install all toolchain. May 04 13:10:13 not sure what you mean May 04 13:10:54 the toolchain is the easy part May 04 13:11:28 well, depending on the scope of what you mean by "toolchain" May 04 13:11:38 apparently I need a linux host May 04 13:12:06 https://rust-lang.github.io/rustup/cross-compilation.html May 04 13:12:59 I tried with rustup May 04 13:13:06 so, to be able to link executables for the beaglebone, the linker will need access to the libraries that will be available on the beaglebone. like I mentioned above, if you're running debian then you can just literally install those libraries (thanks to multi-arch support, which allows e.g. installing armhf libraries on an x86 system, for use with cross-compilation) May 04 13:13:12 but rustup only install rust related things May 04 13:14:51 another way is by using a "sysroot", i.e. having a local copy of the system that's on the beaglebone and tell the compiler/linker to look in there for includes and libraries May 04 13:18:14 Ok I see I didn't find information you provide. May 04 13:18:28 for C/C++ there's a completely different solution, which is to build on the beaglebone but use distcc to delegate the actual compilation to a fast machine on the network ... that machine only needs a basic cross compiler (i.e. apt-get install g++-arm-linux-gnueabihf ) but it doesn't need any headers or libraries for the target, since preprocessing and linking is still done on the beaglebone (only ... May 04 13:18:35 ...compilation is delegated) May 04 13:19:06 intersting May 04 13:19:12 *interesting May 04 13:19:18 this is what I use personally... it's not quite as fast or efficient as having a proper cross-build environment, but it has the advantage of being very little headache May 04 13:19:51 I wonder if it's possible with Rust May 04 13:21:27 zmatt, if you have good quality documentation about "sysroot" and "multiarch" it's very welcome. May 04 13:21:43 it uses the headers and libraries that are actually on the beaglebone, so the cross-toolchain doesn't need to have those, and it appears like you're just compiling on the beaglebone (once setup it works transparently) hence you can compile any third-party project without worrying about whether their Makefile / build system supports cross-compilation May 04 13:23:09 So as compilation step work on mac os and fails on linking May be there is a way to start compilation on mac and link under beagerbone May 04 13:23:13 and the fourth and final option I can think of is using qemu-arm-user to spawn a shell in a beaglebone image and do "native" compilation there May 04 13:23:31 unfortunately, sysroot is the option I know the least about May 04 13:24:46 but the top google hit looks informative at first glance: https://www.baeldung.com/linux/sysroot May 04 13:26:09 you'd need a suitable cross-compiler (using the exact same gcc version as what's on the beaglebone is highly recommended to avoid incompatibility problems) May 04 13:26:09 I saw this kind of articles each time I am looking for something May 04 13:27:17 and a mirror of the contents of your beaglebone May 04 13:27:37 (you don't strictly need everything, as long as you have the headers and libraries I think) May 04 13:28:08 and then pass -sysroot /path/to/beaglebone/mirror to the cross-compiler May 04 13:28:15 dunno how that works with rust May 04 13:28:45 Just If I could find exhaustive information about how linking works in unix/linux would be great I think May 04 13:29:11 exhaustive? are you very sure about that? lol May 04 13:29:40 linking is quite a complicated topic.... but most of that arcane knowledge is not relevant for you May 04 13:29:45 Yes I don't want recipe May 04 13:30:49 Actually on mac os linking fails about an unkown option May 04 13:30:55 what just matters for cross-compilation is that you have 1. a linker that supports the target architecture 2. the libraries for your target system May 04 13:31:54 e.g. on debian if you install a cross-toolchain (e.g. gcc-arm-linux-gnueabihf) it will automatically install the appropriate binutils (binutils-arm-linux-gnueabihf) which includes the linker May 04 13:32:09 ok May 04 13:32:20 I am going to try this May 04 13:34:20 and like I said earlier, on debian (since multi-arch was implemented a while back) you can just install armhf libraries, and then the cross-toolchain will find those May 04 13:35:07 by libraries what do you mean exactly. I don't expect my program use libraries. It is standalone, built with Rust librairies in the future. But just now it's a real standalone program. May 04 13:35:55 yeah I think you are right. I am going to try on Linux. May 04 13:36:06 at a bare minimum you're still linking to libc May 04 13:37:06 libc provides system primitives right ? May 04 13:37:23 systemcall etc... May 04 13:37:31 yeah, system calls, memory allocation, etc May 04 13:38:35 you can check what shared libraries a program is linked to using ldd, i.e. "ldd ./my-program" (only works for native executables, for cross-compiled ones you'd need to run it on the target) May 04 13:38:35 just puzzled about rust use c code to speak with OS, but it's logical indeed May 04 13:39:56 yeah, there's no language-independent library for system functionality, libc performs that job (for essentially historical reasons) May 04 13:40:57 ok thanks for your help. I would love to find this in a book or something. No one wrote about this ? Is there any reference book about this ? May 04 13:41:22 anyway. there are two types of libraries: static and shared. whenever you link against a static library (.a), whatever parts of that library that are used by your program simply get embedded into your executable May 04 13:42:13 yes I know that. Just forgot several things, and don't know other. May 04 13:42:41 while shared libraries get loaded at runtime, but of course the linker also still needs access to them while linking since it needs to know e.g. what symbols are provided by the library May 04 13:43:11 so when cross-compiling, shared libraries are needed both on the build machine and on the target machine, while includes and static libraries are only needed on the build machine May 04 13:43:34 On internet we find only bad an short article. Well not always bad but it's just giving a fish when trying to leanr fishing... May 04 13:44:35 anyway, yeah cross-compilation can still be quite a headache.... May 04 13:46:19 How this is called exactly shared libraries, static libraries, headers, linker etc... ? May 04 13:46:38 ? May 04 13:46:42 apparently it's not the toolchain May 04 13:47:45 ah ok build environment May 04 13:48:08 need to put a name on this May 04 13:48:25 so, toolchain generally refers to compiler and associated tools (assembler, linker, etc) and whatever else is needed to be able to compile at least "hello world" ;) May 04 13:49:39 in rustup book toolchain is ambigous. I didn't understand if it was the name of the rust tool chain or the rest of the tools chain linker included May 04 13:49:45 including whatever libraries are included as part of the toolchain (yes, that's circular ;) May 04 13:50:48 this --toolchain argurments in rustup May 04 13:51:07 yeah not sure May 04 13:51:20 I think it's talking about the rust toolchain May 04 13:51:28 just above rustup target add arm-linux-androideabi is supposed to install the toolchain May 04 13:51:30 https://rust-lang.github.io/rustup/concepts/toolchains.html May 04 13:54:04 btw, for using a sysroot with rust, apparently you can stick the "--sysroot=PATH" option into the RUSTFLAGS environment variable May 04 13:55:43 Yes I think this what cross-rs do May 04 13:57:20 ok, I just tried "rustup target add armv7-unknown-linux-gnueabihf" and compiling a program with --target=armv7-unknown-linux-gnueabihf ... and that indeed results in a linker error May 04 13:57:26 because it's just using the wrong linker :/ May 04 13:57:43 I need to think about how all of these wor May 04 13:57:48 *work May 04 13:58:11 did you try to install the linker ? May 04 13:59:11 I am looking cross-rs May 04 14:00:13 ah ok it uses docker May 04 14:02:18 I have a suitable linker on my system, it just didn't use it... but I should probably use cargo rather than invoking rustc directly, but I haven't used any of this stuff for a very long time so I don't really remember how any of it works May 04 14:02:52 cargo actually has a config option for setting the linker: https://doc.rust-lang.org/cargo/reference/config.html#target May 04 14:04:23 ah ok worth to know May 04 14:04:41 ah, and found the same option for rustc: rustc --target=armv7-unknown-linux-gnueabihf -C linker=arm-linux-gnueabihf-ld hello.rs May 04 14:04:56 you just need to do cargo init in the project dir May 04 14:05:11 and it provides the hello world program May 04 14:05:35 did it work ? May 04 14:06:20 so now it indeed invokes the right linker, but it can't find any library .... this is kinda the same shit I've had when trying to cross-compile things with clang, which is also llvm-based just like rust, and the only way I ever got that working was by figuring out what search paths were used by gcc and then manually explicitly telling all of that to clang May 04 14:06:36 which was a giant pain in the ass May 04 14:06:52 I don't understand why it can't just figure this shit out itself May 04 14:07:52 anyway, that's enough cross-build headaches for me... I've got other stuff to do :) May 04 14:07:57 I wish you good luck! May 04 14:08:02 You have to provides an option for lirairies too perhaps May 04 14:08:07 rest assured, it *can* work May 04 14:08:12 Thanks zmatt May 04 14:08:37 if you get stuck again, try asking in a rust channel/forum May 04 14:08:44 since this is really not beaglebone-specific at all May 04 14:08:46 yes they say the same thing here https://github.com/rust-lang/rust/issues/34282 May 04 14:09:04 I am on #rust channel too . May 04 14:09:30 they don't answer my question :-)) May 04 19:30:40 how would one time how fast the pru is runnning through code. May 04 19:30:44 ? May 04 19:31:04 so the PID thing works but it is going through the signal too slowly May 04 19:31:59 rather than going through the signal sequentially I think I need to have it decide if it needs to skip values May 04 19:33:03 so I am trackign time with CT_ECAP.TSCTR May 04 19:34:44 I could do a simple difference and convert to milliseconds to determine how many values to skip May 04 20:27:35 mattb0ne: ehh, you're probably just doing something weird May 04 20:27:43 and/or misinterpreting observations May 04 20:27:46 can I see your code? May 04 20:28:19 what do you even mean "too slowly" ? May 04 20:29:07 it will use one signal sample per loop iteration, i.e. one signal sample per load cell update May 04 20:29:16 i.e. the signal samplerate equals the load cell sample rate May 04 20:29:50 and it will take exactly that amount of time each iteration, since you're doing the same work each loop iteration May 04 20:31:52 I'm getting a strong deja vu here, I feel like I've been explaining the core structure of your program to your again and again every few weeks or so :P May 04 20:35:16 I'm probably exaggerating, but I did explain this exact thing very recently when you were trying to meddle with the timing of your loop May 04 20:38:14 of course it is possible to decouple the pwm sample rate (i.e. the rate at which the PID loop runs) from the load cell sample rate, but that will add a fair bit of complexity to the program May 04 20:41:09 (and as far as I remember the original plan was to use the load cell measurement as input to the control loop, which further motivated the simple "loop forever { receive load cell measurement; get encoder position; do math; update PWM output; report to python; }' structure May 04 20:41:16 ) **** ENDING LOGGING AT Thu May 05 02:59:57 2022