by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 08 16:22
    DmytroLebed commented #50
  • Jul 08 09:51
    a3f commented #50
  • Jul 08 06:34
    DmytroLebed opened #50
  • Jul 05 21:38
    a3f labeled #11
  • Jul 05 21:38
    a3f labeled #11
  • Jul 05 05:41
    a3f commented #6
  • Jul 04 16:29
    Omar-Alzaabi commented #6
  • Jun 30 09:36
    a3f closed #15
  • Jun 29 18:25
    Tcm0 closed #11
  • Jun 29 18:25
    Tcm0 commented #11
  • Jun 29 18:11
    JakubVanek commented #11
  • Jun 29 12:00
    Tcm0 commented #11
  • Jun 29 11:56
    simonedegiacomi commented #15
  • Jun 29 11:53
    simonedegiacomi commented #48
  • Jun 29 11:35
    JakubVanek commented #11
  • Jun 29 11:34
    JakubVanek closed #9
  • Jun 29 11:34
    JakubVanek commented #9
  • Jun 29 07:26
    a3f closed #23
  • Jun 29 07:26
    a3f commented #23
  • Jun 29 07:25
    a3f commented #48
Ahmad Fatoum
@a3f
I have pushed a new branch https://github.com/c4ev3/C4EV3.Toolchain/tree/OSELAS.Toolchain-2018.12.0 which extends OSELAS.Toolchain-2018.12.0 with a configuration that bundle the EV3's kernel headers with the most recent uclibc release
As an extra benefit of using a proper build system, the toolchain can be built from scratch with a single ptxdist go -j -q that downloads all needed packages, patches them if needed and builds/install them. Downside is that it's not readly compilable on macOS, because of the outdated GNU tools there.
Pavel Malinnikov
@malinnikov
@a3f , that's cool. I'm on mac though, and use your toolchain actively. I use C++11 and static linking. Added a couple of sensors support, probably will prepare a pull request about it. BTW, we with my son won the Ukrainian Robo Sumo contest! My son took the 1st place and I'm on the 3rd :-) https://www.youtube.com/watch?v=Hh8oWSWoUIE&t
Ahmad Fatoum
@a3f
@malinnikov I'll see how much work it is to cross-compiler the cross-toolchain. Would be nice if you could test if I figure it out. Looking forward to your Pull Request!
Much thanks for the video! I absolutely love to see what people are doing with this and congrats to your son (and to you, although I didn't expect you were allowed to compete ^^')
I never been part of such competitions, is my understanding correct that they provide the EV3 and you're only allowed to plug in a SD-Card?
Pavel Malinnikov
@malinnikov
Usually Lego robosumo tournament participation here assumes the age under 17, but this time all ages were allowed so I used the chance to participate. You allowed to bring your own robot, it just has to be only from Lego parts and not more that 1 kg, 25x25x25 cm.
Ahmad Fatoum
@a3f
@malinnikov I see. So you could flash a new firmware (say ev3dev) on your EV3 as well?
Pavel Malinnikov
@malinnikov
From this year it's possible to use any software, including ev3dev, with Python, for example. Looks like Lego has officially adopted ev3dev and calls it MicroPython: https://education.lego.com/en-us/support/mindstorms-ev3/python-for-ev3
AnarCom
@AnarCom
I had problems with uploading program to ev3 ( Transfer failed.
last_reply=06 00 00 00 05 93
UNKNOWN_HANDLE: Path doesn't exist (CONTINUE_DOWNLOAD was denied.))
i checked that path is available
hase someone solved this problem later?
dnlmlr
@dnlmlr
How did you connect your EV3? Are you using the eclipse plugin or the ev3duder directly? And lastly did this work for you before? If you are using the ev3duder directly, do the other commands (for example ls) work?
AnarCom
@AnarCom
i use this command (my ev3 has sd card) "ev3duder.exe up C:\elfs\sensors.elf /media/card/a"
then dudder print: USB connection established.
Transfer failed.
last_reply=06 00 00 00 05 93
UNKNOWN_HANDLE: Path doesn't exist (CONTINUE_DOWNLOAD was denied.)
this is my .elf file (https://drive.google.com/drive/folders/1RELY91wdgSw_ARcqlaj_uma0RVt0W_hw?usp=sharing)
but it upload elf file in "ev3 file system"
AnarCom
@AnarCom
and it is strange)
AnarCom
@AnarCom
and then i try to upload file by eclipse plugin I have the same problem
Simone Degiacomi
@simonedegiacomi
excuse me for the off topic: @a3f I've sent my pull request. In the end it includes different changes, if it's needed I can split it in multiple pull requests.
Ahmad Fatoum
@a3f
@simonedegiacomi It's a quite a lot to review and there are some other pull requests as well. It will take a while, but it is on the radar. Thanks!
@AnarCom So you can upload file via the file system dialog in Eclipse, but not by directly running ev3duder from command line?
Simone Degiacomi
@simonedegiacomi
@a3f thank you!
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
I've recently compiled the toolchain on the new OSELAS.Toolchain-2018.12.0 branch, but I'm not sure it's fully working. I've built it on two separate machines running Ubuntu 18.04.2, so I'm very certain it built correctly.
The default Hello World EV3 C project compiles successfully, and I can upload the files to the EV3 without issues, but nothing seems to happen.
I know it's an issue with the toolchain, because when compiled with the CodeSourcery toolchain, it runs successfully.
Not sure what needs to change; just letting you know I've tested it.
dnlmlr
@dnlmlr
If you have a compatible wifi stick, you can log into the EV3 using telnet and run the program there from the shell. That gives the most information in my experience.
Simone Degiacomi
@simonedegiacomi
I also tried to compile the toolchain (using Ubuntu 19.04 with ptxdist v2019.07.0) and got the same result. When I start the program from the shell (using telnet) I get a segmentation fault
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
I was experimenting around with making my own toolchain for the EV3, and I think I've stumbled across a really simple solution.
I ended up downloading buildroot-2019.05.01 (https://buildroot.org/downloads/buildroot-2019.05.1.tar.bz2) and creating a simple defconfig (https://drive.google.com/file/d/1ijBXhfV_KiHDWhg3d5yVaX4H_jut63g8/view?usp=sharing).
Here's the steps I took to make a working toolchain:
1) Unpack the buildroot tarball
2) Copy c4ev3_defconfig into the buildroot-2019.05.1/configs directory
3) Open the buildroot-2019.05.1directory in the terminal
4) Enter make c4ev3_defconfig
5) Enter make toolchain
6) Sit back, relax.
You'll find your new toolchain in buildroot-2019.05.1/output/host/.
I built this toolchain inside an Ubuntu 18.04.2 VM, and it has worked for me so far. I've compiled and run the C and C++ Hello World programs without issue.
Hopefully this helps :D
Ahmad Fatoum
@a3f
@simonedegiacomi @OurLordAndSaviorStickles Thanks both for testing. Hmm a segfault.. I wonder why that happens..
Simone Degiacomi
@simonedegiacomi
@a3f thank you for your effort to provide a toolchain! Feel free to ask for tests if it's needed. Right now I'm building the toolchain as @OurLordAndSaviorStickles has suggested, I will report my results when the compilation finishes
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles Nice. I am not used to Buildroot, but I don't object to adopting it. The config needs some changes though. We need to use either an older glibc explicitly or uclibc. Otherwise we risk linking applications that don't work on the EV3. Could you amend your defconfig to use the newest uclibc? Also I see no where a config option about the ARMv5T. I think we need that to not risk the compiler generating instructions that aren't supported on the ARM9 at higher optimization levels.
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
@a3f Yeah, the config could probably be improved by explicitly setting more options. I was just trying to get it done quickly, and relied on a lot of the default settings.
Here's an updated version, with a few of the default settings explicitly defined (https://drive.google.com/file/d/1_O1iexITacZBHqDWwxGv1bwmhNDE9HWU/view?usp=sharing)
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles Great. The only question is how we will get a Windows Toolchain out of this.. Can you do a canadian cross compile (--build=x86-linux --host=windows-x86 --target=arm-linux) with buildroot?
Our Lord And Savior Stickles
@OurLordAndSaviorStickles
@a3f It doesn't look like Buildroot can do this. It's handy for Linux, but we'll need another method for a Windows toolchain. Unfortunately, I have very little experience in this matter, so I'm not sure what the best approach would be :/
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles The uclibc builds works fine for you? Could you run your toolchain's gcc -Q -v, so I can compare it with OSELAS' one?
OSELAS.Toolchain doesn't support canadian cross either, but I rather try to extend that one because the maintainer sits one office over at work and I am used to PTXdist.
dnlmlr
@dnlmlr
Maybe
*Maybe docker could be utilized to create a build environment to reliable build the toolchain. Cross compiling for windows should be also possible this way.
Our Lord And Savior Stickles
@OurLordAndSaviorStickles

Buildroot:

$ arm-c4ev3-linux-uclibcgnueabi-gcc -Q -v
Using built-in specs.
COLLECT_GCC=/home/stickles/buildroot-2019.05.1/output/host/bin/arm-c4ev3-linux-uclibcgnueabi-gcc.br_real
COLLECT_LTO_WRAPPER=/home/stickles/buildroot-2019.05.1/output/host/libexec/gcc/arm-c4ev3-linux-uclibcgnueabi/8.3.0/lto-wrapper
Target: arm-c4ev3-linux-uclibcgnueabi
Configured with: ./configure --prefix=/home/stickles/buildroot-2019.05.1/output/host --sysconfdir=/home/stickles/buildroot-2019.05.1/output/host/etc --enable-static --target=arm-c4ev3-linux-uclibcgnueabi --with-sysroot=/home/stickles/buildroot-2019.05.1/output/host/arm-c4ev3-linux-uclibcgnueabi/sysroot --enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib --disable-decimal-float --with-gmp=/home/stickles/buildroot-2019.05.1/output/host --with-mpc=/home/stickles/buildroot-2019.05.1/output/host --with-mpfr=/home/stickles/buildroot-2019.05.1/output/host --with-pkgversion='Buildroot 2019.05.1' --with-bugurl=http://bugs.buildroot.net/ --disable-libquadmath --disable-libsanitizer --enable-tls --disable-libmudflap --enable-threads --without-isl --without-cloog --with-float=soft --with-abi=aapcs-linux --with-cpu=arm926ej-s --with-float=soft --with-mode=arm --enable-languages=c,c++ --with-build-time-tools=/home/stickles/buildroot-2019.05.1/output/host/arm-c4ev3-linux-uclibcgnueabi/bin --enable-shared --disable-libgomp
Thread model: posix
gcc version 8.3.0 (Buildroot 2019.05.1)

OSELAS:

arm-c4ev3-linux-uclibceabi-gcc -Q -v
Using built-in specs.
COLLECT_GCC=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized/bin/arm-c4ev3-linux-uclibceabi-gcc
COLLECT_LTO_WRAPPER=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized/libexec/gcc/arm-c4ev3-linux-uclibceabi/8.2.1/lto-wrapper
Target: arm-c4ev3-linux-uclibceabi
Configured with: ../gcc-8-20181130/configure --build=x86_64-host-linux-gnu --host=x86_64-host-linux-gnu --target=arm-c4ev3-linux-uclibceabi --with-build-sysroot=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized/sysroot-arm-c4ev3-linux-uclibceabi --with-sysroot=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized/sysroot-arm-c4ev3-linux-uclibceabi --disable-multilib --with-float=soft --with-fpu=vfp --with-cpu=arm926ej-s --enable-linker-build-id --disable-libsanitizer --enable-c17 --enable-c++17 --with-bugurl=https://github.com/c4ev3/C4EV3.Toolchain --enable-__cxa_atexit --disable-sjlj-exceptions --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion='C4EV3.Toolchain-2019.08.0 8-20181130' --enable-threads=single --with-system-zlib --with-gmp --with-mpfr --with-mpc --with-isl --with-debug-prefix-map='= WORKSPACE/platform-=C4EV3.Toolchain-2019.08.0/platform-' --enable-libstdcxx-debug-flags='-gdwarf-4 -O0 -g3 -gno-record-gcc-switches' --prefix=/src/opt/C4EV3.Toolchain-2019.08.0/arm-c4ev3-linux-uclibceabi/gcc-8.2.1-uclibc-ng-1.0.31-binutils-2.31.1-kernel-2.6.33-rc4-sanitized --enable-languages=c,c++ --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --disable-shared --disable-libssp --enable-checking=release
Thread model: single
gcc version 8.2.1 20181130 (C4EV3.Toolchain-2019.08.0 8-20181130)
Ahmad Fatoum
@a3f
@dnlmlr You mean a docker containter for compiling or using the toolchain? The latter indeed sounds like a good idea. Would save the hassle and we could just ship the Linux compiler
Ahmad Fatoum
@a3f
@OurLordAndSaviorStickles Just to be sure, even a hello world (int main(void) { puts("Hello World"); }) crashes? How about an empty int main(void) {}?
Simone Degiacomi
@simonedegiacomi

I will report my results when the compilation finishes

I built the compiler using the second config file suggested by @OurLordAndSaviorStickles and it works also for me, although I need to compile with the -static flag, otherwise I get a "file not found error"

@OurLordAndSaviorStickles Just to be sure, even a hello world (int main(void) { puts("Hello World"); }) crashes? How about an empty int main(void) {}?

@a3f If it's the same problem that I have, also int main(void) {} crashes

Ahmad Fatoum
@a3f
@simonedegiacomi I think --disable-shared should make -static the default.
Simone Degiacomi
@simonedegiacomi
that flag needs to be specified when building gcc, right?
Ahmad Fatoum
@a3f
@simonedegiacomi yes. I already pass that in the OSELAS config. I think I might need to pass --with-abi=aapcs-linux to the OSELAS gcc configure. Would you be willing to run an ELF file I compile for you on the EV3, so we can try this out?
Simone Degiacomi
@simonedegiacomi
yes, no problem
Ahmad Fatoum
@a3f
@in
@simonedegiacomi https://send.firefox.com/download/d85ed5c97a693699/#ybTAX95CUQ9cr1YQJYGMlg
This one's compiler has --with-abi=aapcs-linux added and --fpu=vfp removed.
Simone Degiacomi
@simonedegiacomi
image.png