Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 22 14:47
    simonedegiacomi synchronize #22
  • Aug 20 16:50
    simonedegiacomi synchronize #22
  • Aug 20 11:58
    simonedegiacomi synchronize #22
  • Aug 19 14:18
    l-yc opened #23
  • Aug 19 13:05
    simonedegiacomi synchronize #22
  • Aug 19 12:25
    simonedegiacomi synchronize #22
  • Aug 19 12:24
    simonedegiacomi synchronize #22
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)
peehrlich2
@peehrlich2

I want to use the GyroSensor in both Modes (Angle & Rate) at every time. What is the proper way to do this in c4ev3?

It works with constant shifting:

    setAllSensorMode(NO_SEN, NO_SEN,GYRO_ANG,NO_SEN);
    angle = readSensor(IN_2);
    setAllSensorMode(NO_SEN, NO_SEN,GYRO_RATE,NO_SEN);
    rate = readSensor(IN_2);

But that´s not so good for the performance :-(

Mason Wood
@raul32_gitlab
Hello, I seem to be unable to sucesfully "Upload and run" the hello world example file. I get stuck at the "Assembling starter" step
Any ideas on what might be wrong?