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.
To use LibVexBot, you will need the following:
SDCC (Small Device C Compiler) or MCC18
A progamming tool
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.
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.
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.
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.