SDCC for Vex is here!

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.

All the details can be found at:

http://personalpages.tds.net/~jwbacon/vex.html

Many thanks to Ag Primatic, who did most of the work on the SPI interface and also helped clear several other hurdles.

Happy hacking,

 Jason

Yo,

I’m currently on MPlab with student C18 which does not do optimization on code, so does SDCC do code optimization?

Thanks

Regards,
James

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.

Jason

Wow! Really cool! i better try it sometime. But i’m still using EasyC, so i’m not much good at all with just C programming.

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. :slight_smile:

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.

Jason

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:

  1. SDCC (Small Device C Compiler) or MCC18

  2. A progamming tool
    Windows:
    IFI Loader
    Unix/Mac:
    vexctl (part of the roboctl project)

  3. 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.

For best results, FreeBSD and Mac users should install SDCC and roboctl
via FreeBSD ports (http://freebsd.org/ports) or MacPorts (http://macports.org).

Other *nix users may find SDCC and roboctl in their operating system’s
package collection.

If not, roboctl can be installed manually after downloading from
http://personalpages.tds.net/~jwbacon/Ports/distfiles/.

SDCC can be installed manually via the instructions at
http://sdcc.sourceforge.net/.

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.

Jason

any tips on getting roboctl to install on ubuntu?

Can you be more specific???

Are you having dificulty with tar-gzip? Is there a Library Dependency problem? Is the SDCC not generating proper Machine Code??

Did you try running the debian-install script? Ubuntu is really a souped-up version of Debian. If it doesn’t work, email me the exact error messages.

-J

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

Also I am running Ubuntu 10.04

Fixed the problem.

Ubuntu’s default shell is dash so I had to change the “make depend” to “make depend SHELL=/bin/bash” in the debian-install script

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.

Regards,

-J

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.