c4ev3/Lobby

Ahmad Fatoum

@a3f

@simonedegiacomi https://send.firefox.com/download/9b5b4070c3bed4b1/#R-sEKK-4iDhdQX6BTHzhBw

Simone Degiacomi

@simonedegiacomi

meh.. @simonedegiacomi you got gdb or something to get some more info why it crashes?

I can't run gdb on the EV3, but I tried to run it on a raspberry (I know it's not the same architecture, but it semes to work). When running the program I get:

(gdb) run
Starting program: /tmp/hellow.elf 

Program received signal SIGSEGV, Segmentation fault.
x00011c68 in strchr ()

@simonedegiacomi https://send.firefox.com/download/9b5b4070c3bed4b1/#R-sEKK-4iDhdQX6BTHzhBw

this works!

Ahmad Fatoum

@a3f

Great. Ok, I'll do hopefully the last toolchain build now and look into packaging that one as docker containers

Simone Degiacomi

@simonedegiacomi

which flags did you use for the build of hellow2?

Ahmad Fatoum

@a3f

@simonedegiacomi I tried the buildroot uclibc config, I am changing it a bit to always statically link now.

That way we shouldn't need -static

Simone Degiacomi

@simonedegiacomi

so you're going to use buildroot instead of ptxdist?

Ahmad Fatoum

@a3f

@simonedegiacomi The OSELAS problem was with the uclibc config, which I had based on a uClinuc config that wasn't compatible it seems. With this fixed, both work now.

I'd go with OSELAS/PTXdist. Less learning curve for me ^^'

Ahmad Fatoum

@a3f

@OurLordAndSaviorStickles Thanks by the way for the buildroot config. Very helpful to see what I was doing wrongly before : )

Simone Degiacomi

@simonedegiacomi

ok understood. thank you for trying the different configurations, I didn't know where to start. When you'll commit the new configuration I will run the build for the raspberry pi (I need the compiler for that), if it may be useful also for others I can share it

Ahmad Fatoum

@a3f

@simonedegiacomi https://send.firefox.com/download/e12171ae70629f37/#5VrBuzmAbYnuAFCsuE7YOA

One is C and the other C++.

There isn't a shortage on cross-compilers for the raspberry pi, why do you want to build your own?

Simone Degiacomi

@simonedegiacomi

I don't need the crosscompiler for raspberry pi, I need the compiler that runs on raspberry pi to compile programs for EV3 😄

One is C and the other C++.

they both work :thumbsup:

Ahmad Fatoum

@a3f

@simonedegiacomi great :) they print to stdout correctly as well?

Simone Degiacomi

@simonedegiacomi

@a3f yes

Ahmad Fatoum

@a3f

You dont't need a cross compiler for that btw. Just use your normal gcc with -ffree-standing and link manually against uclibc

But ye if it works out of the boz+

X*, that's a tad nicer

Simone Degiacomi

@simonedegiacomi

I compiled gcc for rpi with buildroot and it works, I also tried to run a program built for ev3 on rpi and it works (this is why I tried with gdb before), but I didn't try to run a program compiled with gcc of rpi on ev3. Wouldn't there be problems with the old headers? That's why my idea now was to compile gcc with ptxdist on rpi. Am I missing something?

Simone Degiacomi

@simonedegiacomi

I just tried, but when compiling with -freestanding and against static uclibc the linker reports a lot of errors about missing VFP register. I think I will just build the toolchain with ptxdist, so it's the same version used on x86

Ahmad Fatoum

@a3f

The trick is to not use your headers, but those of the uclibc you buiild yourself. To have the compiler not use vfp, ty -mfloat-abi=softfp, but ye, a cross compiler that just works is better

Our Lord And Savior Stickles

@OurLordAndSaviorStickles

@a3f No problem! I don't know a whole lot about this stuff (yet), so I'm glad I could help!

Ahmad Fatoum

@a3f

@simonedegiacomi I've pushed my ptxdist setup to c4ev3/C4EV3.Toolchain. A binary release for Linux is also uploaded. I'll see what to do about other host systems.

Simone Degiacomi

@simonedegiacomi

Great, thank you!
I noticed that your configuration doesn't support pthread, am I right? I built the toolchain myself (on the rpi) and it works, I just changed these two lines in the configuration to also support pthread:

- PTXCONF_CROSS_GCC_THREADS_SINGLE=y
- PTXCONF_CROSS_GCC_THREADS="single"
---
+ PTXCONF_CROSS_GCC_THREADS_POSIX=y
+ PTXCONF_CROSS_GCC_THREADS="posix"

Last question: do you have any idea why the binaries built with this compiler weight more that the ones built with the buildroot compiler?
For the same program:
ptxbuild compiler: 1.2MB
builtroot compiler: 334KB

(same compiler flags: g++ main.cpp static-libstdc++ -std=c++11 -pthread -Os -fdata-sections -ffunction-sections, -Wl,--gc-sections)

Ahmad Fatoum

@a3f

@simonedegiacomi Try running arm-c4ev3-linux-uclibceabi-strip on both

Simone Degiacomi

@simonedegiacomi

@a3f after running that program:
ptxbuild compiler: 219KB
builtroot compiler: 183KB

now the difference is much smaller, which I think is acceptable, thank you!

Ahmad Fatoum

@a3f

@simonedegiacomi And does the pthread support work correctly? You probably want to add --enable-tls to the gcc configuration options as well, so you can have efficient thread local variables

I can add both if you can write a small program that does some thready and thready-local stuff and they work

@simonedegiacomi re executable size, could you also try by appending -s to the compiler command line and see the difference?

Simone Degiacomi

@simonedegiacomi

@a3f it seems to work, but my program is very simple: I have all the code that controls the robot in one thread and the second thread only continuously checks if the back button is pressed to exit the program

@a3f adding -s the size is 211KB, so even smaller

Simone Degiacomi

@simonedegiacomi

@a3f I can try with --enable-tls and then search/try to write a program that does some concurrency. I'll reply when the build finished and I have some results

Ahmad Fatoum

@a3f

@simonedegiacomi If you only care about the back button, I think signals may be better

We could even integrate this easily with the EV3-API

In the API init code we register a signal handler for SIGALRM that checks which polls for the back button and calls _Exit() if it was pressed.

and then we arrange for SIGALRM to trigger every second. Having pthreads, just to poll and exit, feels overkill.

Ahmad Fatoum

@a3f

seems we are using SIGALRM already for the timer API. hmm, ok pthread it is then

The back button handler thread can still exist within EV3-API though, if you'd like to submit it. I hope to find time to start reviewing the pending Pull requests on sunday. If I don't, then next week

Simone Degiacomi

@simonedegiacomi

@a3f you're right, I didn't think about the timer API. I will look into it, maybe we can avoid the thread, because I see that there are different arrays for callbacks.
For the pull request no problem, even if it is next week (I'm currently adding the support for the PixyCam sensor)

dnlmlr

@dnlmlr

I personally find the timer API to be questionable. I even had to disable it once because it kills blocking tcp sockets with its Signals

Ahmad Fatoum

@a3f

@dnlmlr That's ok for the back button though. But ye, maybe normal users of the timer API should have their callbacks be called in a separate thread

Ahmad Fatoum

@a3f

Or the EV3 init canset SA_RESTART, so most operations automatically resume after the signal handler returns

Simone Degiacomi

@simonedegiacomi

🤦‍♂️ I didn't know about SA_RESTART when I implemented the bluetooth, so I handled all the function call as async ... (I think I was having the same problems as @dnlmlr , specifically I was receiving EINT)

Where communities thrive

People

Repo info

Activity