Programming in *nix

Hi gang,

I’m a newcomer to the VEX world and use Unix for almost all my computing. I’ve done some digging around, and while there doesn’t seem to be any solid support for VEX in the Unix world yet, it looks like we’re VERY close.

I’d like to help drive home the winning run, but before I go and reinvent another wheel, I thought I’d open up a discussion get input from anyone who might already be ahead of me on this one. I’m wondering if anyone out there has worked with SDCC ( or Piklab ( for VEX coding.

SDCC support for the PIC chips seems to be coming of age as we speak, and while Piklab is in its infancy, it looks almost ready for use as well.

I also found some simple PIC loader tools (ifi-pictools and ifi-reloaded_qt) which don’t work with my VEX (OK, my son’s VEX - I keep forgetting). Again, it looks like they could with just a little modification.

I wrote a simple C program to test communication with the VEX, and it wasn’t hard at all (thanks to ( I’m going to finish off a working VEX loader of my own, as soon as I find some info on the hex file format.

If anyone has information to share on this topic, I’d love to hear it. I’ll be maintaining a page on my WEB site ([ to share what I know about VEX programming under Unix.

One more request: Please don’t degrade this thread into another Windows vs. Linux smack-down. I’d like to keep this project positive and productive. My aim is to help *nix users, not pick on Windows users.


Jason Bacon]( to share what I know about VEX programming under Unix.)

Glad to have you here…
I have only a few minutes to type, FRC just “kicked off” yesterday, and time is a-waste-n… :wink:

Microchip only seems to have the Host compiler for Windows, but if you can find or Port a Cross Compiler for the PIC 18, that is what you need.

) or Piklab ( for VEX coding.

SDCC support for the PIC chips seems to be coming of age as we speak, and while Piklab is in its infancy, it looks almost ready for use as well.I have worked with neither… SDCC looks to be a Compiler… It will need to generate Microchip PIC 18 version 2.4 compatible Code, in order for it to work with the Vex.

PIKLAB appears to be an IDE, and if it works under U*IX with the Microchip C18 compiler, it must be using WINE or some other Windows “shim”.

In an effort to reduce to complexity of Embedded Programming, the Vex has Two Microchip PICmicro® PIC18F8520 processors, The MASTER one that only VexLabs has Proprietary Code for and the USER one that VexLabs has PIC C 18, version 2.4 Libraries to interface with your code.

I would “lean toward” using PIKLAB and the Microchip C18 version 2.4 compiler with WINE.

I have heard that others have got Microchip C18 compiler with WINE to work under Linux.

My son is only 7, I bought my own Vex’s…

I have a link somewhere to the PIC Serial Loaded specification that IFI (AKA VexLabs) used to write their Loaded… I think this is the document, A FLASH Bootloader for PIC16 and PIC18 Devices. Also the Vex Programming Hardware, which you can buy ALL BY ITSELF, has the PIC12F629/675 processor in it.

Thanks for the Link to but you need to clean it up, it has a ‘)’ in it…

if you are a good unix programmer, why don’t you make a “wrapper” that translates the unix code into C and then compiles in easyC pro or into MPLAB

sorry if this is impossible or out of the question, ive never programmed unix

UNIX (or UIX) is an Operating System (Like Windows XP), not a Programming Language… EasyC or MPLAB and the PIC C18 compiler are all Windows Applications, which means that they don’t work as Linux (or UIX) applications. (With the help of WINE and Linux running on i386 platforms, some Windows applications will run on Linux as an Operating System. IIRC, someone has the Command Line PIC C18 compiler working with WINE)

Also (History Lesson here), the Programming Language ‘C’ was developed for UNIX, and is instrumental in Porting UNIX to other Hardware Platforms.

Yes, SDCC is a cross compiler for several types of MCUs. PIC support is the latest addition, but it’s still in the works, so I don’t know how reliable it is yet. The next question will be the Vex libraries. It may be possible to use the libraries from mcc18, but I’m not at that level of understanding yet. There may also be distribution restrictions on the Vex libraries, but we’ll cross that bridge when we get there…

I think that would be a step forward from MPLAB under WINE, but I’m more interested in developing SDCC support for the VEX, since this would free everyone from OS and CPU constraints. Configuring WINE is very inconvenient compared to running a compiler natively, and limits users to i86 machines. Someone with a PPC Mac, or Unix on a Sparc or Alpha machine will be out of luck with mcc18. MS VirtualPC on a Mac or QEMU emulating an i86 on a Sparc won’t cut it. Way too slow… I installed SDCC on the old G3 using MacPorts, and it works great.

I’ve run MPLAB with mcc18 under WINE on PC-BSD as well. It issues a few warnings at startup, but otherwise seems to work fine.

Thanks for the tips!

I mainly use PC-BSD (a desktop-enhanced FreeBSD) on my desktop machines, but I also have an old iBook G3 and a MacBook, and have Xubuntu running on an older machine just to stay up to date on Linux and test my code on a third *nix platform. All my Windows systems are under emulation now (Parallels and Win4BSD).

Unix is not a language, but a class of operating systems that are all compatible with each other at the source code level. I.e., a program written on one Unix-like platform will compile with little or no modification on others, even if they run on different CPUs. Examples include IBM’s AIX, FreeBSD, Linux, Sun Solaris, etc. My goal is to program the VEX in C under Unix. Since EasyC and MPLAB run only under Windows, we have to find other options. The SDCC compiler and Piklab IDE are both open source, so they will run under just about any Unix platform. BTW, the C language was actually created as a “portable assembly language” in order to facilitate the design of a portable operating system (the original Unix) at AT&T in the early 1970s. Seems natural that it’s now so popular for embedded programming.

i know i meant programming IN unix and using the API’s

I now have a working VEX loader. I incorporated the code into my legoctl project, and renamed the project “roboctl”. The project currently includes a C library called libroboctl.a which supports Lego NXT and VEX communications, and two separate commands called “legoctl” and “vexctl”.

FreeBSD and Mac OS X users can install via FreeBSD ports or MacPorts. ( See )

Other *nix users can fetch the source from


and build it manually.

I haven’t yet figured out how to automatically get the VEX controller into programming mode. I know that dropping the RTS line is part of it, because Linux and OS X were causing it to go back into programming mode when the the serial device (/dev/cu.usbserial or /dev/ttyUSB0) was closed. I solved this problem by dropping RTS with an ioctl() call immediately after opening the device, so that it wouldn’t drop when calling close(). This in itself does not trigger programming mode, however. If anyone knows the right incantation, please let me know. It would be nice if users didn’t have to push the button on the programming module every time they run vexctl.



A quick status update: I managed to code and upload a (useless) program to the VEX using SDCC. It required a modified 18f8520 linker script, which is available on my WEB site:

One remaining obstacle to writing useful programs: I have no idea yet how to access the ports on the VEX using SDCC. So far I haven’t been able to find any technical documentation on how the VEX ports are tied into the PIC controllers. Info on the PIC controller itself is abundant.

What would be ideal would be some PIC assembly code demonstrating how to read input ports, set motor ports, and set up an ISR from the user controller. From there I could develop some simple VEX libraries for SDCC.



Did you look in the “ifi_definitions.h” file and compaire the to the PIC 18F documentation?? I am away from home, but I will look in to it in a few days…

(Posting from Sunny [70F] Long Beach, CA)

Might you mean ifi_default.h? I couldn’t find an ifi_definitions.h file anywhere. I haven’t had time to study the default code thoroughly, but maybe that should be the next step.



I think the main magic file you want is ifi_picdefs.h, with some additional goodness in ifi_default.h and ifi_aliases.h.


  • Dean

Yes, you are both right… I was Posting off the “Top of My Head”.

Thanks, gents.

I took a closer look at the default code. This helps some, but it appears that the code for doing the real communication is in IFI_Initialization(), Getdata() and Putdata(), which are not included in the source distribution.

It would be nice if we could convince the powers that be to open up a bit more to programming alternatives (as Lego has). I’ve been very pleased with the quality and variety of the Vex hardware, but rather disappointed with the limited choices for programming. I think if they released the full specs, some really cool stuff would come out of it.



Because Vex is used for Competitions, there is a Master Processor that has Ultimate Control of the Vex Controller. We (mere mortals) get to program the User Processor, which must give control to the Master Processor with the Getdata() and Putdata() functions. IFI (Vex Labs) won’t share the Code Details of the Master Processor.

We are constantly exploring new ways to expand the options available to our customers; however the integrity of the Vex System for use as a competition platform is important to us, and to our customers.


Thanks for chiming in, John. Would Vexlabs consider providing some basic support for SDCC in the near future?

E.g., SDCC-compiled versions of the closed-source libraries would make it a simple matter to port the default code to SDCC. This would allow users to program the Vex from just about any platform out there.

This would be especially useful for non-Intel machines, mainly PowerPC Macs, but a few users might use an old Sparc system or an ARM running Linux. On Intel Macs, and PCs with FreeBSD, Linux, etc. we can use Parallels, WINE, QEMU, Win4*, etc. to run the Windows binaries, but this is rather cumbersome, so some native tools would really be appreciated here as well.



I can’t comment on what we are considering for the future.

I forwarded your comments on to the people who would make decisions of this type (and who would be better suited to evaluate your suggestion).


Thanks, I appreciate the swift action. I don’t know exactly what the concerns are about maintaining the integrity of the system for competition, but it appears to me that Vex Labs is in a position much like other hardware vendors. I would suggest looking at nVidia as a model of how to protect the privacy of hardware specs while working with the open source community. They offer partly open, partly closed source drivers for FreeBSD and Linux. This keeps the users happy and reduces their motivation to create 100% open source drivers, which might reveal more about the GPU than nVidia would like.

I think the same concept would work with SDCC for Vex. Now that SDCC supports the PIC processor, it will only be a matter of time before people figure out how to program the Vex with it. If, however, Vex Labs provided some closed-source libraries for SDCC, they could maintain a degree of control over SDCC development.

The situation is somewhat easier than nVidia’s: Whereas nVidia has to adapt their drivers to every platform, one set of SDCC libraries could support all development platforms, since the libraries are specific to the target PIC processor, not the platform that runs the cross-compiler.

With the libraries provided by Vex Labs, I suspect the open source community would focus their efforts on building development tools around them. ( And adapting those that exist already, like Piklab. )



You might want to look at my open source Vex libraries. It shouldn’t be to hard to port them to SDCC: