Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 31 13:08
    Electrenator commented #26
  • Oct 27 10:47
    Courtbookinger edited #13
  • Oct 27 10:30
    Courtbookinger opened #13
  • Oct 17 13:33
    Electrenator commented #26
  • Oct 17 13:32
    Electrenator commented #26
  • Oct 11 23:05
    dnlmlr commented #26
  • Oct 11 23:05
    dnlmlr commented #26
  • Oct 11 23:04
    dnlmlr commented #26
  • Oct 11 22:39
    Electrenator commented #26
  • Oct 11 11:50
    dnlmlr commented #26
  • Oct 11 11:42
    Electrenator opened #26
  • Oct 04 11:57
    simonedegiacomi commented #25
  • Oct 04 11:39
    dnlmlr commented #25
  • Oct 01 12:28
    Jensonbruins commented #25
  • Oct 01 12:23
    dnlmlr commented #25
  • Oct 01 12:11
    Jensonbruins opened #25
  • Sep 27 17:06
    dnlmlr commented #24
  • Sep 27 15:40
    WilliamRagstad opened #24
  • Aug 22 14:47
    simonedegiacomi synchronize #22
  • Aug 20 16:50
    simonedegiacomi synchronize #22
Ahmad Fatoum
@a3f
The issue is because implementation-defined signedness of char. Some compilers choose char to be signed, other have it unsigned. Even worse the same compiler may do different things on different machines (On Intel, char is usually signed but on ARM it's unsigned)
I have enabled signedness warnings and fixed the problems that turned up as well as some more so it compiles cleanly as C++ now as well
Try to copy the same parts from the current EV3-API master
Simone Degiacomi
@simonedegiacomi
Hi @a3f , I've added the support for Bluetooth communication between robots and the HT compass sensor. During the implementation I changed the way of how the sensors are initialized and used (copying from Makecode) because I was having some trouble with different Gyro sensors.
Moreover, I also refactored the code for the sensors: I've split the code to handle each sensor protocol in a different file and I've done the same for each sensors.
Now that the code has been refactored, the API to use the sensors has changed, but if it's important to maintain back-compatibility I can restore that.
Ahmad Fatoum
@a3f
Hello @simonedegiacomi , that sounds nice! There has been a pull request for HiTechnic compass sensor today. Is it the same? Could you review the patch if that's the case: c4ev3/EV3-API#19
@simonedegiacomi Refactoring if useful, is welcome, but API needs to stay the same. There are courses using the API for teaching and I'd prefer not to break them
Simone Degiacomi
@simonedegiacomi
@a3f the pull request isn't mine. About the API, I can fix the back-compatibility next week
Ahmad Fatoum
@a3f
@simonedegiacomi Is it the same seonsr? If so, it would be nice if you can take a look at it
Simone Degiacomi
@simonedegiacomi
Yes, It Is the same sensor. I also had to multiply the value for 2, as explained at the end of this page
Ahmad Fatoum
@a3f
Ah I see. Makes sense as the value can then fit into a byte
@malinnikov_twitter I've thought some more about my cross-toolchain endeavors last year. We only really need compatiblity with the 2.6.33 kernel on the EV3, we could just ship our own libc, like C++ users are already doing for libstdc++.
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.)
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