nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
PhotoJim has quit [Remote host closed the connection]
PhotoJim has joined #beagle
PhotoJim has quit [Remote host closed the connection]
PhotoJim has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
m-atoms has joined #beagle
m-atoms has quit [Ping timeout: 248 seconds]
alan_o has quit [Ping timeout: 240 seconds]
Shadyman has quit [Quit: Leaving.]
alan_o has joined #beagle
jfsimon1981 has joined #beagle
starblue has joined #beagle
rob_w has joined #beagle
zjason`` has joined #beagle
zjason` has quit [Ping timeout: 248 seconds]
zjason has joined #beagle
zjason`` has quit [Ping timeout: 248 seconds]
otisolsen70 has joined #beagle
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has joined #beagle
mvaittin has joined #beagle
samnob has quit [Ping timeout: 256 seconds]
rob_w has quit [Remote host closed the connection]
_Posterdati_ has joined #beagle
Posterdati has quit [Ping timeout: 256 seconds]
_Posterdati_ has quit [Quit: KVIrc 5.0.0 Aria]
Posterdati has joined #beagle
<zmatt> jfsimon1981: fortunately Etcher is available for Windows, Mac, and Linux... so that part is all the same :)
<zmatt> set_: ?
<zmatt> you're gonna have to be a bit more specific than "that lib"
<jfsimon1981> Yes i forgot about this, i used it a while ago
<jfsimon1981> Thanks
samnob has joined #beagle
florian_kc is now known as florian
starblue has quit [Ping timeout: 248 seconds]
starblue has joined #beagle
jfsimon1981 has quit [Ping timeout: 276 seconds]
jfsimon1981 has joined #beagle
lucascastro has joined #beagle
otisolsen70 has quit [Read error: Connection reset by peer]
otisolsen70 has joined #beagle
ikarso has joined #beagle
Midjak has joined #beagle
<Midjak> Hi
<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
<Midjak> erience doing this(VM install or cross copilation from x86 arch) I will be glade to ear from you.
<zmatt> Midjak: how about this?
<zmatt> wasn't hard to find by googling rust and cross compilation (and ignoring any results that are about cross-compiling rust itself)
<Midjak> Did you try it ?
<zmatt> nope, like I said I just found it by googling just now
<Midjak> I try to cross copile on mac os and linux but linking fails
<zmatt> yeah, that's usually the biggest pain when cross-compiling
<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
<Midjak> yes I can try corss-rs but I have doubt about how it is able magically to install all toolchain.
<zmatt> not sure what you mean
<zmatt> the toolchain is the easy part
<zmatt> well, depending on the scope of what you mean by "toolchain"
<Midjak> apparently I need a linux host
<Midjak> I tried with rustup
<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)
<Midjak> but rustup only install rust related things
<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
<Midjak> Ok I see I didn't find information you provide.
<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 ...
<zmatt> ...compilation is delegated)
<Midjak> intersting
<Midjak> *interesting
<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
<Midjak> I wonder if it's possible with Rust
<Midjak> zmatt, if you have good quality documentation about "sysroot" and "multiarch" it's very welcome.
<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
<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
<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
<zmatt> unfortunately, sysroot is the option I know the least about
<zmatt> but the top google hit looks informative at first glance:
<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)
<Midjak> I saw this kind of articles each time I am looking for something
<zmatt> and a mirror of the contents of your beaglebone
<zmatt> (you don't strictly need everything, as long as you have the headers and libraries I think)
<zmatt> and then pass -sysroot /path/to/beaglebone/mirror to the cross-compiler
<zmatt> dunno how that works with rust
<Midjak> Just If I could find exhaustive information about how linking works in unix/linux would be great I think
<zmatt> exhaustive? are you very sure about that? lol
<zmatt> linking is quite a complicated topic.... but most of that arcane knowledge is not relevant for you
<Midjak> Yes I don't want recipe
<Midjak> Actually on mac os linking fails about an unkown option
<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
<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
<Midjak> ok
<Midjak> I am going to try this
<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
<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.
<Midjak> yeah I think you are right. I am going to try on Linux.
<zmatt> at a bare minimum you're still linking to libc
<Midjak> libc provides system primitives right ?
<Midjak> systemcall etc...
<zmatt> yeah, system calls, memory allocation, etc
<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)
<Midjak> just puzzled about rust use c code to speak with OS, but it's logical indeed
<zmatt> yeah, there's no language-independent library for system functionality, libc performs that job (for essentially historical reasons)
<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 ?
<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
<Midjak> yes I know that. Just forgot several things, and don't know other.
<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
<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
<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...
<zmatt> anyway, yeah cross-compilation can still be quite a headache....
<Midjak> How this is called exactly shared libraries, static libraries, headers, linker etc... ?
<zmatt> ?
<Midjak> apparently it's not the toolchain
<Midjak> ah ok build environment
<Midjak> need to put a name on this
<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" ;)
otisolsen70 has quit [Ping timeout: 260 seconds]
<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
<zmatt> including whatever libraries are included as part of the toolchain (yes, that's circular ;)
<Midjak> this --toolchain argurments in rustup
<zmatt> yeah not sure
<zmatt> I think it's talking about the rust toolchain
<Midjak> just above rustup target add arm-linux-androideabi is supposed to install the toolchain
<zmatt> btw, for using a sysroot with rust, apparently you can stick the "--sysroot=PATH" option into the RUSTFLAGS environment variable
<Midjak> Yes I think this what cross-rs do
<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
<zmatt> because it's just using the wrong linker :/
<Midjak> I need to think about how all of these wor
<Midjak> *work
<Midjak> did you try to install the linker ?
<Midjak> I am looking cross-rs
<Midjak> ah ok it uses docker
<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
otisolsen70 has joined #beagle
<zmatt> cargo actually has a config option for setting the linker:
otisolsen70 has quit [Remote host closed the connection]
<Midjak> ah ok worth to know
<zmatt> ah, and found the same option for rustc: rustc --target=armv7-unknown-linux-gnueabihf -C linker=arm-linux-gnueabihf-ld
<Midjak> you just need to do cargo init in the project dir
<Midjak> and it provides the hello world program
<Midjak> did it work ?
<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
<zmatt> which was a giant pain in the ass
<zmatt> I don't understand why it can't just figure this shit out itself
<zmatt> anyway, that's enough cross-build headaches for me... I've got other stuff to do :)
<zmatt> I wish you good luck!
<Midjak> You have to provides an option for lirairies too perhaps
<zmatt> rest assured, it *can* work
<Midjak> Thanks zmatt
<zmatt> if you get stuck again, try asking in a rust channel/forum
<zmatt> since this is really not beaglebone-specific at all
<Midjak> yes they say the same thing here
<Midjak> I am on #rust channel too .
<Midjak> they don't answer my question :-))
markand has quit [Read error: Connection reset by peer]
Guest61 has joined #beagle
buzzmarshall has joined #beagle
Guest61 has quit [Quit: Client closed]
jfsimon1981 has quit [Ping timeout: 248 seconds]
jfsimon1981 has joined #beagle
florian has quit [Quit: Ex-Chat]
jfsimon1981 has quit [Ping timeout: 276 seconds]
xet7 has quit [Read error: Connection reset by peer]
vagrantc has joined #beagle
lucascastro has quit [Ping timeout: 248 seconds]
jfsimon1981 has joined #beagle
lucascastro has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
xet7 has joined #beagle
mattb0ne has joined #beagle
<mattb0ne> how would one time how fast the pru is runnning through code.
<mattb0ne> ?
<mattb0ne> so the PID thing works but it is going through the signal too slowly
<mattb0ne> rather than going through the signal sequentially I think I need to have it decide if it needs to skip values
<mattb0ne> so I am trackign time with CT_ECAP.TSCTR
<mattb0ne> I could do a simple difference and convert to milliseconds to determine how many values to skip
jfsimon1981 has quit [Ping timeout: 256 seconds]
Shadyman has joined #beagle
thinkfat has joined #beagle
<zmatt> mattb0ne: ehh, you're probably just doing something weird
<zmatt> and/or misinterpreting observations
<zmatt> can I see your code?
<zmatt> what do you even mean "too slowly" ?
<zmatt> it will use one signal sample per loop iteration, i.e. one signal sample per load cell update
<zmatt> i.e. the signal samplerate equals the load cell sample rate
<zmatt> and it will take exactly that amount of time each iteration, since you're doing the same work each loop iteration
<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
<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
<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
vagrantc has quit [Quit: leaving]
<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
<zmatt> )
ikarso has joined #beagle
Midjak has quit [Quit: This computer has gone to sleep]
jfsimon1981 has joined #beagle
lucascastro has quit [Remote host closed the connection]
mattb0ne has quit [Ping timeout: 252 seconds]
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 260 seconds]
Midjak has joined #beagle
m-atoms has joined #beagle
jfsimon1981 has quit [Ping timeout: 276 seconds]
insurgent has quit [Read error: Connection reset by peer]
insurgent has joined #beagle
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 248 seconds]
demirok has joined #beagle
demirok has quit [Read error: Connection reset by peer]
m-atoms has quit [Ping timeout: 248 seconds]
m-atoms has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
demirok has joined #beagle
demirok has left #beagle [#beagle]
demirok has joined #beagle
nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
demirok has left #beagle [#beagle]