@simonedegiacomi Great. Looking forward to it! :)
@a3f alright thanks, I'll try that!
I opened an issue for the make error, hopefully the error message is useful enough (sorry, it's my first time trying out stuff like this so i'm not sure what exactly is needed)
By the way, did the sound API work for anyone out of the box? It threw a casting error for me, which I managed to fix by adding the missing cast in the API
Source prj_sound/sound.cpp, Project Folder prj_sound
prj_sound/sound.cpp: In function 'void PlayToneEx(short unsigned int, short unsigned int, unsigned char)':
prj_sound/sound.cpp:49: error: invalid conversion from 'unsigned char*' to 'char*'
prj_sound/sound.cpp:49: error: initializing argument 1 of 'int WriteToSoundDevice(char*, int)'
As for your sound issue, we got no sound.cpp, did you copy paste code into your project?
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
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.
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.
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
Yes, It Is the same sensor. I also had to multiply the value for 2, as explained at the end of this page
@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++.
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.
@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
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?
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
i checked that path is available
hase someone solved this problem later?
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.)
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 So you can upload file via the file system dialog in Eclipse, but not by directly running ev3duder from command line?
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.
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.
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
3) Open the
4) Enter
5) Enter
6) Sit back, relax.
You'll find your new toolchain in
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
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 directory3) Open the
buildroot-2019.05.1directory in the terminal4) Enter
make c4ev3_defconfig5) Enter
make toolchain6) 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
@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.
@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)
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)