Thanks to a 2-man programming marathon over the holiday break, it’s now possible to program Vex robots using SDCC.
In case you didn’t already know, SDCC is a free, open source compiler for microcontrollers, which runs on virtually any operating system and hardware, including PowerPC Macs.
We have developed a new version of LibVexBot that builds under both MCC18 v3.x and SDCC v2.7.0 or later. Most of the development was done using SDCC 2.8.0, but I also built and uploaded the code from an iBook G3 running SDCC 2.7.0, and didn’t see any problems.
Optimization is actually the one advantage MCC18 still has as far as I can see. Even the feature-limited MCC18 student edition produces much smaller and faster hex files than SDCC at this point. Note that the student MCC18 only disables some of the optimizations, not all. The SDCC PIC port is still considered “unfinished”. Optimization is minimal, and the machine code generated is rather fluffy and inefficient.
On the bright side, so far I haven’t run into any errors caused by the compiler. I’ve been running my Vex on SDCC for about a month now, and so far not a single hiccup.
I also doubt that optimization is going to be much of an issue for most people. Unless you write some amazingly sloppy code, the 10 MIPS user processor should have no problem keeping up with the demands of Vex hardware. As an example, the SPI data stream from the master processor is by far the most demanding real-time requirement, sending a new character about every 18 microseconds. The SPI interrupt service routine, written in C and compiled with SDCC handles this with plenty of CPU cycles to spare. Processing standard sensor input is no where near this challenging, and most of the CPU cycles in a typical VEX program just go to waste on loops waiting for the next input event.
If anyone is doing something that tests the limits of the Vex controller, I’d be very interested in hearing about it.
Optimizations come in handy when doing complex manipulations… I used to try some delta-change-trigger function for reducing remote jitter and smoothing functions to help out the IR sensors, pid to control motor-movement and such… perhaps it wasn’t the most optimized C code but at such complexity I’d find it better to code in ASM or really have optimizations.
Well, the SDCC code is in the form of LibVexBot, which I created to provide an incremental step up from EasyC. EasyC and the Default code are truly on opposite extremes of ability level, and missed most of the bell curve in my view. You don’t have to be a genius with C to get started with LibVexBot. Much like EasyC, you can just call API functions to read sensors, turn on motors, etc. Unlike EasyC, you have the source code for those functions, so you’re not limited to abstract programming.
I think the ability to write the C code would be the easiest part of this whole process. A much more talented friend and i spent the night trying to get this installed. All of the things on this page are built on top of a series of other programs that had us off on tangents all night. We think the problem comes from the fact the the authors here had a prior programming background on their machine. My new MacBook has none of the most basic things like code compilers that the authors took for granted. It would be so nice if these programs came with all of their required parts. Downloading the developer pack from Mac we found to be good start for anyone else trying to do this. Although its still a virtual nightmare just trying to get the terminal emulator to work because the vexctl requires it. Who knows what other hurdles this will throw at us when we get to the compiling stage. This seems to be decent if you can get it to work and is probably worth the hassle not to use the vex software. I’ll post more once we get past the puzzle of installing this.
Thanks for posting the feedback. At version 0.2.3, there’s still much to be done. I don’t have a lot of free time at the moment, so it might be a while before the setup is simplified. But for starters I just added the following text to readme.txt in LibVexBot-0.2.3.tar.gz, so at least people won’t be left to guess how to go about it.
============
Installation
To use LibVexBot, you will need the following:
SDCC (Small Device C Compiler) or MCC18
A progamming tool
Windows:
IFI Loader
Unix/Mac:
vexctl (part of the roboctl project)
A terminal emulator
Windows: IFI Loader include a terminal app, or you can use PuTTY.
Unix/Mac: I recommend cutecom, but you can also use PuTTY or
any other terminal emulator with serial port support.
we ended up simplifying some of the code and running it on Ubuntu. Still no luck on Mac tho. But it does work on Ubuntu. Thanks for posting the stuff though. Free is always best to me.
I added a couple of scripts to the LibVexBot distribution to help beginners set up a Mac or Cygwin environment with SDCC. They’re not 100% automated, but where they don’t do something for you, they will tell you what you need to do. (e.g. Installing the right version of Xcode is not a decision that a script is qualified to make.)
I may add more scripts for other platforms as time permits.
I am having trouble installing OpenVex. I ran the robotize-debian script as root but it exits with the an error. Here is the the last bit from the script:
-- Configuring done
-- Generating done
-- Build files have been written to: /home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0
[100%] Built target cutecom
Install the project...
-- Install configuration: ""
-- Up-to-date: /usr/local/bin/cutecom
-- Up-to-date: /usr/local/man/man1/cutecom.1
Reading package lists... Done
Building dependency tree
Reading state information... Done
sdcc is already the newest version.
The following packages were automatically installed and are no longer required:
libplasma-geolocation-interface4 libplasmaclock4 libweather-ion4
kdebase-workspace-bin mysql-server-core-5.1 libprocessui4 libprocesscore4
akonadi-server libksgrd4 libtaskmanager4 libqimageblitz4
mysql-client-core-5.1 kdebase-workspace-data libplasmagenericshell4
kdebase-workspace-kgreet-plugins libkephal4 plasma-dataengines-workspace
ksysguardd libkscreensaver5 libkfontinst4 libplasma-applet-system-monitor4
kdepim-runtime plasma-widgets-workspace
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 316 not upgraded.
Commands gentoo-install LICENSE Makefile ROADMAP TODO
debian-install Libs Mac_bt_test README Scripts
Reading package lists... Done
Building dependency tree
Reading state information... Done
make is already the newest version.
The following packages were automatically installed and are no longer required:
libplasma-geolocation-interface4 libplasmaclock4 libweather-ion4
kdebase-workspace-bin mysql-server-core-5.1 libprocessui4 libprocesscore4
akonadi-server libksgrd4 libtaskmanager4 libqimageblitz4
mysql-client-core-5.1 kdebase-workspace-data libplasmagenericshell4
kdebase-workspace-kgreet-plugins libkephal4 plasma-dataengines-workspace
ksysguardd libkscreensaver5 libkfontinst4 libplasma-applet-system-monitor4
kdepim-runtime plasma-widgets-workspace
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 316 not upgraded.
Reading package lists... Done
Building dependency tree
Reading state information... Done
gcc is already the newest version.
The following packages were automatically installed and are no longer required:
libplasma-geolocation-interface4 libplasmaclock4 libweather-ion4
kdebase-workspace-bin mysql-server-core-5.1 libprocessui4 libprocesscore4
akonadi-server libksgrd4 libtaskmanager4 libqimageblitz4
mysql-client-core-5.1 kdebase-workspace-data libplasmagenericshell4
kdebase-workspace-kgreet-plugins libkephal4 plasma-dataengines-workspace
ksysguardd libkscreensaver5 libkfontinst4 libplasma-applet-system-monitor4
kdepim-runtime plasma-widgets-workspace
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 316 not upgraded.
Reading package lists... Done
Building dependency tree
Reading state information... Done
libc6-dev is already the newest version.
The following packages were automatically installed and are no longer required:
libplasma-geolocation-interface4 libplasmaclock4 libweather-ion4
kdebase-workspace-bin mysql-server-core-5.1 libprocessui4 libprocesscore4
akonadi-server libksgrd4 libtaskmanager4 libqimageblitz4
mysql-client-core-5.1 kdebase-workspace-data libplasmagenericshell4
kdebase-workspace-kgreet-plugins libkephal4 plasma-dataengines-workspace
ksysguardd libkscreensaver5 libkfontinst4 libplasma-applet-system-monitor4
kdepim-runtime plasma-widgets-workspace
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 316 not upgraded.
Reading package lists... Done
Building dependency tree
Reading state information... Done
libusb-dev is already the newest version.
The following packages were automatically installed and are no longer required:
libplasma-geolocation-interface4 libplasmaclock4 libweather-ion4
kdebase-workspace-bin mysql-server-core-5.1 libprocessui4 libprocesscore4
akonadi-server libksgrd4 libtaskmanager4 libqimageblitz4
mysql-client-core-5.1 kdebase-workspace-data libplasmagenericshell4
kdebase-workspace-kgreet-plugins libkephal4 plasma-dataengines-workspace
ksysguardd libkscreensaver5 libkfontinst4 libplasma-applet-system-monitor4
kdepim-runtime plasma-widgets-workspace
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 316 not upgraded.
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Couldn't find package libbluetooth1-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
bluez-utils is already the newest version.
The following packages were automatically installed and are no longer required:
libplasma-geolocation-interface4 libplasmaclock4 libweather-ion4
kdebase-workspace-bin mysql-server-core-5.1 libprocessui4 libprocesscore4
akonadi-server libksgrd4 libtaskmanager4 libqimageblitz4
mysql-client-core-5.1 kdebase-workspace-data libplasmagenericshell4
kdebase-workspace-kgreet-plugins libkephal4 plasma-dataengines-workspace
ksysguardd libkscreensaver5 libkfontinst4 libplasma-applet-system-monitor4
kdepim-runtime plasma-widgets-workspace
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 316 not upgraded.
(cd Libs/C; make clean)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Libs/C'
rm -f rct.o nxt.o nxt_direct_cmd.o nxt_system_cmd.o rcx.o usb.o brick.o get_home_dir.o debug.o pic.o vex.o libroboctl.a *.nr
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Libs/C'
(cd Commands/Legoctl; make clean)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/Legoctl'
rm -f legoctl.o legoctl *.nr
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/Legoctl'
(cd Commands/Vexctl; make clean)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/Vexctl'
rm -f vexctl.o vexctl *.nr
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/Vexctl'
(cd Commands/NXTRemote; make clean)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/NXTRemote'
rm -f nxtremote *.nr *.o
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/NXTRemote'
(cd Commands/NXTNotes; make clean)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/NXTNotes'
rm -f nxtnotes.o nxtnotes *.nr
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/NXTNotes'
(cd Libs/C/Test; make clean)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Libs/C/Test'
rm -f testnxt.o testnxt *.nr
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Libs/C/Test'
(cd Libs/C; make depend)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Libs/C'
rm -f Makefile.depend
for file in *.c; do \
cc -MM -I. -I/usr/local/include ${file} >> Makefile.depend; \
echo -e "\t\${CC} -c \${CFLAGS} ${file}" >> Makefile.depend; \
echo "" >> Makefile.depend; \
done
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Libs/C'
(cd Commands/Vexctl; make depend)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/Vexctl'
rm -f Makefile.depend
for file in *.c; do \
cc -E -I../../Libs/C -I/usr/local/include -MM ${file} >> Makefile.depend; \
echo -e "\t\${CC} -c \${CFLAGS} ${file}" >> Makefile.depend; \
echo "" >> Makefile.depend; \
done
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/Vexctl'
(cd Commands/Legoctl; make depend)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/Legoctl'
rm -f Makefile.depend
for file in *.c; do \
cc -E -I../../Libs/C -I/usr/local/include -MM ${file} >> Makefile.depend; \
echo -e "\t\${CC} -c \${CFLAGS} ${file}" >> Makefile.depend; \
echo "" >> Makefile.depend; \
done
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Commands/Legoctl'
(cd Libs/C; make)
make[1]: Entering directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Libs/C'
Makefile.depend:3: *** missing separator. Stop.
make[1]: Leaving directory `/home/matt/Desktop/OpenVex-0.4.4/cutecom-0.20.0/roboctl-0.3.5/Libs/C'
make: *** [liblego] Error 2
My guess is that it is having trouble compiling cutecom but I am not sure.
I am still not sure what is wrong but I’ve done a little bit of digging into the code and I think that when “make depend” is run it formats the Makefile.depend incorrectly.
And now I realize that it is stopping when compiling roboctl and not cutecom.
I added a “cd …” to the end of the cutecom part of robotize_debian
Thanks much for the feedback. I’ll patch the script to make it shell-independent.
Sorry about the long absence: I’ve been working extra long hours for the past year, and haven’t had any time to play. Things have settled down now, and I’m actively working on Vex development again.
roboctl 0.3.7 contains some important bug fixes for both Lego NXT and Vex.
I’m also in the planning stage of support for Cortex in OpenVex and (later) vexctl.
Do you think OpenVex is a viable programming option for this year’s challenge? I’ve wanted to get acquainted with this platform for awhile now but due to the lack of support for Cortex, I’ve been steered towards EasyC and RobotC.
No offense but this seems like a dead project since it’s managed by only 1 person. I don’t know many people who use this competitively and considering the other options, I don’t see how this provides a worthwhile advantage.
I appreciate your hard work and I hope this project becomes successful and that many people will start using it. Let me know if I can help.
Hello,
I recently stumbled upon Open Vex and think it is a very solid implementation on the Pic controllers (hoping for Cortex support but w/e).
Anyway I was wondering if the only working repo is the one at http://personalpages.tds.net/~jwbacon/Ports/distfiles/ or if there is a public repo where one can commit changes (like a git.) If not I’d be happy to maintain it
P.S. Does anyone know how to detect competition start signals and what not. I figure its just a serial call however if there is a working method no need to reinvent the wheel.
No, I’m not using a source hosting service at this time. You can send patches via email for now. ( jwbacon — tds dot net )
If you’re interested in helping with the Cortex port, I’m happy to delegate big or small tasks. There are ports (FreeBSD and OS X) for the gcc toolchain and stm32loader in the ports section of my website.
As for competition start signals, you might take a look at the Vex default code for MPLAB. This applies only to PIC controllers with RF control. Not sure about Vexnet.
