08:53 <zmatt> jfsimon1981: fortunately Etcher is available for Windows, Mac, and Linux... so that part is all the same :)

08:53 <zmatt> set_: ?

08:55 <zmatt> you're gonna have to be a bit more specific than "that lib"

09:02 <jfsimon1981> Yes i forgot about this, i used it a while ago

09:02 <jfsimon1981> Thanks

11:44 <Midjak> Hi

11:51 <Midjak> 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

11:51 <Midjak> erience doing this(VM install or cross copilation from x86 arch) I will be glade to ear from you.

12:03 <zmatt> Midjak: how about this? https://github.com/cross-rs/cross

12:04 <zmatt> wasn't hard to find by googling rust and cross compilation (and ignoring any results that are about cross-compiling rust itself)

12:05 <Midjak> Did you try it ?

12:05 <zmatt> nope, like I said I just found it by googling just now

12:06 <Midjak> I try to cross copile on mac os and linux but linking fails

12:07 <zmatt> yeah, that's usually the biggest pain when cross-compiling

12:09 <zmatt> 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

12:09 <Midjak> yes I can try corss-rs but I have doubt about how it is able magically to install all toolchain.

12:10 <zmatt> not sure what you mean

12:10 <zmatt> the toolchain is the easy part

12:11 <zmatt> well, depending on the scope of what you mean by "toolchain"

12:11 <Midjak> apparently I need a linux host

12:12 <Midjak> https://rust-lang.github.io/rustup/cross-compilation.html

12:12 <Midjak> I tried with rustup

12:13 <zmatt> 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)

12:13 <Midjak> but rustup only install rust related things

12:14 <zmatt> 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

12:18 <Midjak> Ok I see I didn't find information you provide.

12:18 <zmatt> 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 ...

12:18 <zmatt> ...compilation is delegated)

12:19 <Midjak> intersting

12:19 <Midjak> *interesting

12:19 <zmatt> 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

12:19 <Midjak> I wonder if it's possible with Rust

12:21 <Midjak> zmatt, if you have good quality documentation about "sysroot" and "multiarch" it's very welcome.

12:21 <zmatt> 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

12:23 <Midjak> 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

12:23 <zmatt> 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

12:23 <zmatt> unfortunately, sysroot is the option I know the least about

12:24 <zmatt> but the top google hit looks informative at first glance: https://www.baeldung.com/linux/sysroot

12:26 <zmatt> 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)

12:26 <Midjak> I saw this kind of articles each time I am looking for something

12:27 <zmatt> and a mirror of the contents of your beaglebone

12:27 <zmatt> (you don't strictly need everything, as long as you have the headers and libraries I think)

12:28 <zmatt> and then pass -sysroot /path/to/beaglebone/mirror to the cross-compiler

12:28 <zmatt> dunno how that works with rust

12:28 <Midjak> Just If I could find exhaustive information about how linking works in unix/linux would be great I think

12:29 <zmatt> exhaustive? are you very sure about that? lol

12:29 <zmatt> linking is quite a complicated topic.... but most of that arcane knowledge is not relevant for you

12:29 <Midjak> Yes I don't want recipe

12:30 <Midjak> Actually on mac os linking fails about an unkown option

12:30 <zmatt> 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

12:31 <zmatt> 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

12:32 <Midjak> ok

12:32 <Midjak> I am going to try this

12:34 <zmatt> 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

12:35 <Midjak> 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.

12:35 <Midjak> yeah I think you are right. I am going to try on Linux.

12:36 <zmatt> at a bare minimum you're still linking to libc

12:37 <Midjak> libc provides system primitives right ?

12:37 <Midjak> systemcall etc...

12:37 <zmatt> yeah, system calls, memory allocation, etc

12:38 <zmatt> 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)

12:38 <Midjak> just puzzled about rust use c code to speak with OS, but it's logical indeed

12:39 <zmatt> yeah, there's no language-independent library for system functionality, libc performs that job (for essentially historical reasons)

12:40 <Midjak> 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 ?

12:41 <zmatt> 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

12:42 <Midjak> yes I know that. Just forgot several things, and don't know other.

12:42 <zmatt> 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

12:43 <zmatt> 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

12:43 <Midjak> 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...

12:44 <zmatt> anyway, yeah cross-compilation can still be quite a headache....

12:46 <Midjak> How this is called exactly shared libraries, static libraries, headers, linker etc... ?

12:46 <zmatt> ?

12:46 <Midjak> apparently it's not the toolchain

12:47 <Midjak> ah ok build environment

12:48 <Midjak> need to put a name on this

12:48 <zmatt> 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" ;)

12:49 <Midjak> 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

12:49 <zmatt> including whatever libraries are included as part of the toolchain (yes, that's circular ;)

12:50 <Midjak> this --toolchain argurments in rustup

12:51 <zmatt> yeah not sure

12:51 <zmatt> I think it's talking about the rust toolchain

12:51 <Midjak> just above rustup target add arm-linux-androideabi is supposed to install the toolchain

12:51 <zmatt> https://rust-lang.github.io/rustup/concepts/toolchains.html

12:54 <zmatt> btw, for using a sysroot with rust, apparently you can stick the "--sysroot=PATH" option into the RUSTFLAGS environment variable

12:55 <Midjak> Yes I think this what cross-rs do

12:57 <zmatt> 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

12:57 <zmatt> because it's just using the wrong linker :/

12:57 <Midjak> I need to think about how all of these wor

12:57 <Midjak> *work

12:58 <Midjak> did you try to install the linker ?

12:59 <Midjak> I am looking cross-rs

13:00 <Midjak> ah ok it uses docker

13:02 <zmatt> 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

13:02 <zmatt> cargo actually has a config option for setting the linker: https://doc.rust-lang.org/cargo/reference/config.html#target

13:04 <Midjak> ah ok worth to know

13:04 <zmatt> ah, and found the same option for rustc: rustc --target=armv7-unknown-linux-gnueabihf -C linker=arm-linux-gnueabihf-ld hello.rs

13:04 <Midjak> you just need to do cargo init in the project dir

13:05 <Midjak> and it provides the hello world program

13:05 <Midjak> did it work ?

13:06 <zmatt> 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

13:06 <zmatt> which was a giant pain in the ass

13:06 <zmatt> I don't understand why it can't just figure this shit out itself

13:07 <zmatt> anyway, that's enough cross-build headaches for me... I've got other stuff to do :)

13:07 <zmatt> I wish you good luck!

13:08 <Midjak> You have to provides an option for lirairies too perhaps

13:08 <zmatt> rest assured, it *can* work

13:08 <Midjak> Thanks zmatt

13:08 <zmatt> if you get stuck again, try asking in a rust channel/forum

13:08 <zmatt> since this is really not beaglebone-specific at all

13:08 <Midjak> yes they say the same thing here https://github.com/rust-lang/rust/issues/34282

13:09 <Midjak> I am on #rust channel too .

13:09 <Midjak> they don't answer my question :-))

18:30 <mattb0ne> how would one time how fast the pru is runnning through code.

18:30 <mattb0ne> ?

18:31 <mattb0ne> so the PID thing works but it is going through the signal too slowly

18:32 <mattb0ne> rather than going through the signal sequentially I think I need to have it decide if it needs to skip values

18:33 <mattb0ne> so I am trackign time with CT_ECAP.TSCTR

18:34 <mattb0ne> I could do a simple difference and convert to milliseconds to determine how many values to skip

19:27 <zmatt> mattb0ne: ehh, you're probably just doing something weird

19:27 <zmatt> and/or misinterpreting observations

19:27 <zmatt> can I see your code?

19:28 <zmatt> what do you even mean "too slowly" ?

19:29 <zmatt> it will use one signal sample per loop iteration, i.e. one signal sample per load cell update

19:29 <zmatt> i.e. the signal samplerate equals the load cell sample rate

19:29 <zmatt> and it will take exactly that amount of time each iteration, since you're doing the same work each loop iteration

19:31 <zmatt> 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

19:35 <zmatt> 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

19:38 <zmatt> 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

19:41 <zmatt> (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

19:41 <zmatt> )