Assuming you purchased a cortex, what you want to do is quite possible but there is no documentation and those who have done it generally have not released any details. Depending on your requirements, you may be better off with the VEXpro as it is open source and would allow TCP/IP communication with the host PC. Perhaps tell us a bit more about your planned use, how many motors? What sensors? What are the real time constraints (ie. from receiving sensor data how quickly do you expect to be able to have a motor respond), this is probably the most important aspect of what you are trying to do if I understand you correctly. Anyway, here are a couple of links where I discussed some previous work in this area.
I took a quick look at the EasyC protocol, I’ve never been particularly interested in the online window but this is a partial explanation of it’s working.
Serial communication, 8 bit, no parity 115200 baud.
To enable online control send the hex string
C9 17 65 29 01 64 03 04 05 06 07 08 09 0A
No idea of the details of this, not important at this point
To disable online control send
C9 17 65 29 00 00 03 04 05 06 07 08 09 0A
When in online mode ASCII strings are sent by the cortex, they look like this
__DI 1 1 1 1 1 1 1 1 3 3 3 3 128 1 0
__AI 64 1023 68 64 63 64 64 64
__IME 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Data for digital, analog and IME sensors
Motor control is done using binary commands, general form (in hex) for neutral position is
C9 17 22 2C 7F 7F 7F 7F 7F 7F 7F 7F 7F 7F
Four byte header and ten hex values ranging from 0x00 through 0xFF for the ten motors, the third byte above (the 0x22) is a checksum byte and is the addition of the 11 following bytes. So to put motor 1 at max forward speed would be.
C9 17 A2 2C FF 7F 7F 7F 7F 7F 7F 7F 7F 7F
Anyway, it’s sort of trivial to reverse engineer the rest but I don’t have time right now. If you have a software engineer working on this project it should be an easy task but, to be honest, this would not be the route I would take, there are better ways.
The “old” programming cables had USB->RS232 converter (the infamous prolific PL-2303) followed by 232->TTL conversion and some proprietary toggling of the RTS controlled by the PIC Mark mentions. The magic toggling controls competition modes when connected to a PC and also is able to put the master CPU into boot load mode. See this post.
The “new” programming cable (which I don’t yet have) implements the new VEX communications HID class so presumably has some other type of CPU doing the USB->serial conversion.
I also wish it were a little cheaper, say $35 (or find 9 friends and use the $29.99 bulk price?), I have been tempted to build one using an arduino but the cost would still be at least $25 plus connectors, enclosure etc. so it’s not really worth it other than as a programming exercise. Probably use this part https://www.sparkfun.com/products/11098
I don’t have the New Programming Cable, but I would guess that it has an FTDI USB-to-Serial chip rather than the PL-2303 USB-to-Serial chip.
The Old Programming Kit has Two Parts, the USB-to-Serial ( RS-232 Serial that is )with the PL-2303 ( mine has the PL_2303 XA / HXA chip, not supported under Windows 8 ) and the RS-232 Serial to TTL Serial adapter with the little PIC 12Fxxx chip… If your computer has an RS-232 Port Built In, you only need to use the Second Part of the Programming Cable Set, also, since the First Part is a common USB-to-Serial ( RS-232 Serial ) adapter, a different manufacture’s cable could be used.
Since the New Programming cable is One Unit, they could skip the [/ATTACH]
I doubt that, the VEX CDC implementation is not standard as far as I can tell, I think the whole idea of the new cable was so that only one driver was needed which would work with direct USB connection to the cortex as well as the programming adapter. The cortex shows as VID 0x04d8 (which is microchip) and PID as 0x000b which should be a 10 channel A-D converter, who ever developed the firmware did what a lot of us do and probably started with a demo project which was modified. VEX really should have paid the $2000 necessary to get their own vendor ID but it’s too late now. I also wish the CDC implementation had been standard so that custom drivers are not needed on other OS’s, I wrote a user side driver for OSX but it still needs a codeless kernel extension to make it work as OSX thinks it should be a “standard” CDC device. I forget exactly why its not standard but it was something to do with joystick data using a different endpoint from serial port data.