Open source development for the cortex

[jpearman]

Over the last couple of days, prompted by some of Foster’s remarks, the question of open source code for the cortex has come up again. So I want to throw this question out for debate.

Should we develop an open source development platform for the cortex?

I’m going to say right at the start of this post that my opinion is no we should not, I will explain my opinion at the end but wanted to take a quick look at the development needed as a hypothetical exercise.

First, lets recap what we know about the hardware architecture of the cortex. We know the cortex contains two micro-controllers, the STM32 which we currently program using ROBOTC or EasyC and know as the user processor, in addition to this is a LPC2458, an ARM7 based processor that acts in a supervisory role and therefore is known as the supervisor processor.

The tasks as I understand them (and I have spent a lot of time researching this) are divided between these two processors as follows.

Supervisor
USB
PWM motors 2-9
Power management
Status LED’s

User
Digital ports 1-12
Analog ports 1-8
Speaker port (DAC)
UART1 & UART2 (Serial ports)
I2C port
Motor ports 1 & 10
Rx1 & Rx2

The user processor communicates with the supervisor processor in at least two ways. The first is SPI communication that sends parameters such as motor pwm values and receives such things as joystick position. This also has some digital handshaking associated with it that I don’t yet understand. Secondly is an asynchronous serial channel that is used to program the user processor as well as send debugging information back to the development system.

The supervisor processor is running the master firmware provided by IFI. This controls the USB port in both client mode when connected using a cable to a PC or joystick as well as host mode when connected to the VEXnet WiFI adapter. The 8 RC servo motors are also controlled from this processor and it plays a significant role (although also not completely understood) in competition control.

A new development environment would have several components that would have to be developed.

An IDE which the user interacts with. This could probably be an adaptation of something like Eclipse that we have mentioned before. Eclipse would have the added benefit of being cross platform so the Mac users among us would be happy. An ARM toolchain (compiler, linker etc.) would also be needed but these are also available.

Software to send compiled code to the cortex would be needed, the equivalent of the EasyC download dialog. Again, not a huge problem as the protocol for communicating with the STM32 is well known and IFI has made our lives easier but standardizing on using COM ports for both the programming cable and USB connections.

A runtime library, this is where the real work starts. Think of all the functions currently available, these would all need duplicating in a runtime library. This would include, for example, code to interface to the following sensors.

Ultrasonic
Quad Encoder
Switches (and any other simple digital IO)
Gyro
Accelerometer
Other Analog inputs such as the potentiometer and line sensors.

Code would need to be developed for communicating with the supervisor CPU as I outlined above. Code for the serial ports to drive the LCD display and of course the infamous I2C port for the IMEs. Motors 1 & 10 need pwm code to control their speeds and direction. Although achievable, this is a lot of work made all the more difficult without supporting documentation from IFI.

Now that I’ve laid out the scope of this type of project let me give you the reasons that I would not want to tackle it.

1. CMU and Intelitek have invested time and money into creating two reasonable development environments for us already. They are in business to hopefully make a profit and I would not want to create something that would have an impact on that.

2. When there is currently an issue we can call on tech support and hopefully the issue will be addressed. With a homebrew development system there will probably be no tech support beyond what the developers are willing to do for free. This would be a bad situation for teams using this software.

3. An alternative environment that was not endorsed by IFI, and could potentially cause damage to the cortex due to unforeseen changes made by IFI, would be a liability for the developers. In other words, I don’t want to be responsible for breaking your cortex.

4. After all this work I’m not sure it would be a better system for the average user.

5. I want to build and program robots not make the tools used to do that.

So there are my thoughts I would love to hear from others.

[scott1]

I’m in the 3rd year of a 4 year Software Engineering degree right now and theoretically what you have written sounds awesome and like something I would love to get involved in. However I know I never would be involved in starting something like this and I don’t know of anyone at AURA who would end either. I think most of the dedicated people involved in VEX are already putting in so much of there spare time that its just not fair to expect them to put in hours on a project like this. I think another issue will be who is still involved in 2 years time? I plan to leave University by then and have no idea what I will be doing and where I will be doing it, if a project like this lost to many major contributors I could see it simply dying and leaving lots of people in limbo.

I also agree with your points about support, I think using a community developed solution in competition robots could be a major headache. If there was a major issue and the person who made that code was unavailable it could end up being weeks or months before a solution was found and for competition robots that would be just to long.

However having said that and having read most of the posts in Foster’s threads I could see this being useful for some teams with members who were involved in such a project and could debug any issues found, or class room settings (maybe at a College level more than a High School level). The ability for people to add libraries for sensors not found in the VEX system I could see being the main draw card. And if a project did get started I’m sure there are some members of AURA (probably including me) and possibly other College teams who would contribute.

[1069E]

@Jpearman
You do raise some valid points, and I whole heatedly agree that developing the back-end code for the Cortex hardware would become quite the chore. However, there may be programmers out there who want to squeeze every bit of performance out of the Cortex, or even solve potential problems in existing firmware. (Perhaps firmware patches would become more frequent and effective)

Although my idea is in no way economically practical, I think it would be nice if VEX offered a “developer” disk containing all of the decompiled binaries that make up the current firmware. It wouldn’t be required to purchase it, rather, have it as a part available in the store. As for support? It would be more of a “You are on your own” approach. If you made the decision to buy the disk, you should most definitely have an idea of what you are doing.

Like I said, that’s really unlikely that such a product will be released, but it would be nice.

[MarkO]

I am rolling in some Ideas from other Threads, many thanks to all who have contributed…

Re:
I want top quality sensors, not a speaker

I’m done with crap code from IFI, RobotC and EasyC

An apology, and I did get the robot to work

Programming Tool-Chain

The Programming System for the Cortex Controller does not need to be Open Source, but to have the Level of control that the PIC Controller had would be acceptable for the Programming.

EasyC, which uses the Lite version of the CodeSourcery GCC Compiler, the Secret Sauce is in the easyCRuntimeLib.lib, which performs the Magic to make the Cortex work.

If Intelitek offered a Documented Version of the easyCRuntimeLib.lib for sale, with the Flexibility to link it with whatever you can find to generate Cortex-M3 code with, and maybe a few programming examples, I would buy it…

The EasyC Editor I find difficult to use, because:

Copying Code in the Drag and Drop screen is cumbersome.

When the “C Programming” Windows is visible, you can highlight it with the Mouse or the use the Keyboard and the Control or Shift keys, but you can not Copy it. With EasyC v1.x, 2.x and 3.x you could click on the “Source Files” item in the “Project Explorer” and copy it from there… I believe that you can with EasyC v4.x, but it is no where as obvious.

In Code Editing, the Editor only seems to support the new Cut, Copy and Insert shortcut keys. ( Control-X, Control-C and Control-V )
I stared with Windows 3.0 and I use the Original Keys, ( Shift-Delete, Control-Insert and Shift-Insert ) which seem to work in most every Editor I use, including Visual Studio 10, but not in EasyC.

Hardware, Sensors

Here is a 100K-Ohm Linear-Taper Potentiometer, Radio-Shack Part 271-092. It’s $3.19 ( USD ), it has no Mount, or Easy Way to connect to the Shaft, but it will read just like the Official Vex one, because it is just a Voltage Divider.

Here is how I connect it to the Vex Controller:

[ATTACH]5992[/ATTACH]

On an Analog Input, the Green goes to the Middle ( Signal ), Always and the Red goes to the VCC and the Black to the Ground, or you can reverse the Red and Black.

For Basic Testing, or Choosing Custom Program Settings, these are cheaper than the Vex Ones, but not competition legal.

There are bound to be other things than can be used as sensors, would they give an unfair advantage in a Competition, possibly.
If the Design Notes were Required to be Opened to the Public, right before their use in a Competition, the Innovative Teams would have possible a One Competition advantage, before other Teams could copy their design. If a Monetary Limit was set, per sensor, say Two at the cost of the Accelerometer or Gyroscope, and Two at Half of That, and Two at Half of that again, that would limit the Number and Expense of 3rd Party Sensors. Plus, there Application would be revealed as a Condition of their Usage.

It is my Understanding that the Web Browser, Firefox is developed with a few Paid Programmers, and many Volunteer Programmers…

Possibly IFI/Intelitek/CMU could evolve to a similar Level of Existence with the Tool-Chain and the integration of Sensors…

HPIM5187.zip (1.4 MB)

[fretless_kb]

I’m not convinced that an open source tool chain would be an improvement for the average team either. For the same reasons you identified James.

I would like to have a program on the PC be able to interface to the robot as well as having joystick control. I suppose there are ways to do this but I lack the skill and time to make it happen just yet. But I think it would be cool to control a number of bots from a computer. More from the education side of this program than for competition.

Cheers Kb

[MarkO]

@fretless_kb

I’m not convinced that an open source tool chain would be an improvement for the average team either. For the same reasons you identified James.

An Open source Tool-Chain won’t Guaranty an Improvement, but it allows someone outside of the Core Developers to implement changes, that might not have been thought of by the Core Developers, or Brought to Completion because of Resource Limitations ( Time, Money, Skills ). Even if those Changes, are not well documented, they can be a Spring-Board for others for their own designs, or be developed into a better Supported Design for the Community as a whole.

I bring my contributions to the PIC Controller as an example,

Vex On-Line Controller Code v2.x (Available Source Version 0.81ß)

and

** Vex Serial Port Reader 0.81ß (VEX On-Line Code Version) **

Both of these were developed by using Research done by others here on the Vex Forum…

At some point in the Near Future, I would like to expand these programs to the Cortex…

I would like to have a program on the PC be able to interface to the robot as well as having joystick control. I suppose there are ways to do this but I lack the skill and time to make it happen just yet. But I think it would be cool to control a number of bots from a computer. More from the education side of this program than for competition.

Cheers Kb

Quazar has done some work in that Area. The VEXnet Joystick Partner Port is a RS-232 Level Interface with this Wiki Page documenting the Protocol, Vex Packet Protocol.

You could program your Cortex to respond to the Second Joystick, and with a Custom Cable, make the Computer be that Joystick.

[Taylor]

How long do we expect the Cortex, as it is, to be used & supported by VEX?

[magicode]

I knew this could be done in competition:

@magicode

In college, at least in gateway, you were allowed to hook anything into the partner port of the joystick. This means unlimited memory, as you can hook a laptop into the partner port, and bit bang out data to the Cortex.

but are you talking about doing embedded programming through that manner?

[MarkO]

@Taylor

How long do we expect the Cortex, as it is, to be used & supported by VEX?

I would expect until the FTL Quantum Singularity Core is developed, or the ARM 64, whichever comes first…

[MarkO]

@magicode

I knew this could be done in competition:

@magicode

In college, at least in gateway, you were allowed to hook anything into the partner port of the joystick. This means unlimited memory, as you can hook a laptop into the partner port, and bit bang out data to the Cortex

.

but are you talking about doing embedded programming through that manner?

Are you Talking to me???

I guess you could Program, “through that manner”. It would require writing special Code to let you do that. It would be faster to disconnect the Serial Port from the Secondary Joystick Port and Connect to the Programming Port and use the Vex Downloader, then connect it back to the Secondary Joystick Port. Unless you want to use Two Serial Ports…

I was thinking more of Control of the Robot.

[jpearman]

@MarkO

EasyC, which uses the Lite version of the CodeSourcery GCC Compiler, the Secret Sauce is in the easyCRuntimeLib.lib, which performs the Magic to make the Cortex work.

If Intelitek offered a Documented Version of the easyCRuntimeLib.lib for sale, with the Flexibility to link it with whatever you can find to generate Cortex-M3 code with, and maybe a few programming examples, I would buy it…

If you have a valid EasyC license then you have this already (not sure what the EULA for EasyC says about this though). It is documented in as much as the functions in the library are the same functions you use in EasyC. My problem with the EasyC runtime is that some functions are (IMHO) really badly written, SetLCDText for example has long delays associated with it that should not exist in a real time embedded system.

The EasyC Editor I find difficult to use, because:

Copying Code in the Drag and Drop screen is cumbersome.

When the “C Programming” Windows is visible, you can highlight it with the Mouse or the use the Keyboard and the Control or Shift keys, but you can not Copy it. With EasyC v1.x, 2.x and 3.x you could click on the “Source Files” item in the “Project Explorer” and copy it from there… I believe that you can with EasyC v4.x, but it is no where as obvious.

In Code Editing, the Editor only seems to support the new Cut, Copy and Insert shortcut keys. ( Control-X, Control-C and Control-V )
I stared with Windows 3.0 and I use the Original Keys, ( Shift-Delete, Control-Insert and Shift-Insert ) which seem to work in most every Editor I use, including Visual Studio 10, but not in EasyC.

When I use EasyC I immediately jump into user code and skip the flowchart editor, I don’t use the built in text editor much and either use Notepad++ or (more often) use my preferred Mac text editor. I run EasyC in a virtual machine on the Mac with the project in a shared directory, I edit the code on the Mac side (on a second screen often), save, go to EasyC and hit compile.

@fretless_kb

I would like to have a program on the PC be able to interface to the robot as well as having joystick control. I suppose there are ways to do this but I lack the skill and time to make it happen just yet. But I think it would be cool to control a number of bots from a computer. More from the education side of this program than for competition.

Cheers Kb

Mark is correct in his comments about the partner port, you could send any information encoded as pseudo partner joystick data to the cortex. I also have partial joystick simulation working over a direct USB link to the cortex, it didn’t make much sense over the serial programming cable as the joystick is already present, although I did also do that at one point. Never had the time or motivation to finish up that code and the USB driver was proving to be tricky.

Sensors

If we did have an alternative library, perhaps a hybrid where things like the user to supervisor processor communications, competition control, downloading and debugging support were provided in object file form and other functionality provided in the form of source code, then I would predict that new functionality could/would be added far quicker than Intelitek currently provides it.

[MarkO]

@jpearman

If you have a valid EasyC license then you have this already (not sure what the EULA for EasyC says about this though). It is documented in as much as the functions in the library are the same functions you use in EasyC. My problem with the EasyC runtime is that some functions are (IMHO) really badly written, SetLCDText for example has long delays associated with it that should not exist in a real time embedded system.

I do have a Valid EasyC License, but for those who don’t have EasyC and that just want to Program, it would be nice to offer them a Legal Solution .
Not just Documentation for the Official EasyC functions, but Documentation for the Back-End Functions that do the Interfacing… So if you don’t like the SetLCDText function, you can replace it with your own code.

When I use EasyC I immediately jump into user code and skip the flowchart editor, I don’t use the built in text editor much and either use Notepad++ or (more often) use my preferred Mac text editor. I run EasyC in a virtual machine on the Mac with the project in a shared directory, I edit the code on the Mac side (on a second screen often), save, go to EasyC and hit compile.

I like IDE’s, and have spent a lot of time in EasyC 1.x, but I find the Bigger EasyC gets, the More Cumbersome it gets…

Mark is correct in his comments about the partner port, you could send any information encoded as pseudo partner joystick data to the cortex. I also have partial joystick simulation working over a direct USB link to the cortex, it didn’t make much sense over the serial programming cable as the joystick is already present, although I did also do that at one point. Never had the time or motivation to finish up that code and the USB driver was proving to be tricky.

An official USB Driver would be nice to bypass the Joystick, although it might be misused in competitions, either by Interference, or I don’t know if you could Pair a Joystick and a Computer to a Cortex controller at the same time to achieve an unfair advantage.

Sensors

If we did have an alternative library, perhaps a hybrid where things like the user to supervisor processor communications, competition control, downloading and debugging support were provided in object file form and other functionality provided in the form of source code, then I would predict that new functionality could/would be added far quicker than Intelitek currently provides it.

Exactly… This goes back to my Outside Developers providing support in areas the Official Developers are unable to…

[fretless_kb]

Thanks guys, it’s funny because I thought of the partner joystick port just after I posted, But I’d really like to have (if only limited) 2 way communication with the robot while also having the joystick. Most of my teams robots require 2 drivers, I have an evolving prototype that I overload the joystick controls for the particular ‘mode’ the robot is in. It would be cool to have a computer program as my second driver, Once the communications framework was in and the on-board ‘realtime response’ code was set I could make more and more sophisticated PC code without the hit of download / test / fix / download… So a proof of concept using the programming cable would be fine to start. It seems Vex had identified direct PC to Robot Communication as an upgrade path, I’m guessing it is being out prioritized.

I’m not sure I have the free time to come up to speed and tackle a project like that just yet. I might try some sort of 2nd joystick emulator though.

Cheers Kb

[jpearman]

@fretless_kb

Thanks guys, it’s funny because I thought of the partner joystick port just after I posted, But I’d really like to have (if only limited) 2 way communication with the robot while also having the joystick. Most of my teams robots require 2 drivers, I have an evolving prototype that I overload the joystick controls for the particular ‘mode’ the robot is in. It would be cool to have a computer program as my second driver, Once the communications framework was in and the on-board ‘realtime response’ code was set I could make more and more sophisticated PC code without the hit of download / test / fix / download… So a proof of concept using the programming cable would be fine to start. It seems Vex had identified direct PC to Robot Communication as an upgrade path, I’m guessing it is being out prioritized.

I’m not sure I have the free time to come up to speed and tackle a project like that just yet. I might try some sort of 2nd joystick emulator though.

Cheers Kb

I’m going to link to a few old threads here to remind everyone what has been done before.

So you have a number of choices for PC to cortex communication.

First, I did a joystick emulator a few months ago and posted code here.

If anyone want to create a new program loader it’s pretty easy, the protocol is based on the STM32 USART bootloader app note AN3155, although with a little extra magic if you are using the serial programming cable, I touched on the magic in this post but I will leave the exact details out here.

ROBOTC has it’s own serial protocol that it uses after the virtual machine is running. Using this protocol pretty much everything on the cortex can be controlled. Here is a screen shot of part of my “corecom” software that I posted about months ago. Something based on this could “drive” the robot running software on a PC, reading the sensors and controlling the motors directly. Absolutely not competition legal but fun all the same.

[ATTACH]6040[/ATTACH]

[fretless_kb]

Yes I remember the post of the Cortex status, I had to go back and re-read the post. knowing how to interface and grab the data / and pass joystick like commands would be awesome.
In the thread https://vexforum.com/t/mac-cortex-robotc-debug-application/19365/1 you indicate you communicate with the Cortex via ‘normal programming cable’ is that the USB A-A cable? or Prolific Serial cable?

Cheers Kb

[jpearman]

@fretless_kb

Yes I remember the post of the Cortex status, I had to go back and re-read the post. knowing how to interface and grab the data / and pass joystick like commands would be awesome.
In the thread Mac Cortex/RobotC debug application - Technical Discussion - VEX Forum you indicate you communicate with the Cortex via ‘normal programming cable’ is that the USB A-A cable? or Prolific Serial cable?

Cheers Kb

Actually Kevin, both. Here’s some background.

I originally wrote this code for ROBOTC V2.32, at that time the cortex was still using the old style USB connection which was based on a Human Interface Device (HID). As I wrote this code primarily to run under Max OSX, I created a VEX HID class based on an existing HID class I had so the Mac could communicate over USB. I also supported the serial cable using the prolific driver on the Mac and, as a byproduct of this, could support the serial adapter with a PC version of the code.

When the master firmware was updated along with the release of ROBOTC V3.00, IFI changed the USB device to be a communications device class (CDC) and provided a driver for that on the PC side which (other than the fact that CMU changed many things in the protocol as well) allowed the PC version to work with the USB cable essentially for free. On the Mac side, OSX tries to use the new CDC device with a built in driver but, as the cortex does not simulate a standard CDC device, that driver would not work. Under OSX there are two ways of communicating with USB devices, you can either create a kernel extension (kext) or control them from user code which is the preferred way for most applications accessing custom devices. Unfortunately as the cortex thinks it is a CDC, the OS sort of hijacks the device and does not allow a user applications to access it. To get around this you have to create what is known as a “codeless kext”, a kernel extension that matches the USB vendor and product ids but does not contain any driver code. Once this is installed the USB device is accessible from a user space driver which is integrated into my application. The CDC USB works much better than the old HID USB used to, I would have preferred that IFI had made it a vendor specific device so I could have avoided the kext tricks but obviously use under OSX is not really a consideration.

The ROBOTC protocol is rather interesting. As we all know ROBOTC is based on using a virtual machine running on the cortex and a compiler that creates a type of intermediate machine code. Each different instruction is known as an opcode and will have additional data associated with it depending on what the opcode is. A line of code such as

bLCDBacklight = 1;

When compiled becomes the hex codes

11 11 09 01

The first 11 is the opcode for setting a byte value (opcdSetSourceValueByteConst), the 11 09 indicates the backlight.

The serial protocol is also based on these opcodes but wrapped in a message packet. The serial command for setting the LCD backlight is as follows (again in hex).

77 99 33 08 12 11 09 00 02 01 00 2F

77 99 33 is the message header
08 is a byte count
12 is the opcode for assign source value (opcdAssignSourceValue)
11 09 is the location for the LCD backlight

etc. (i forget all the details right now)

you can see all the opcodes in the header file OpcodeDefinitions.h

Once you figure out the protocol it makes a lot of sense and is easy to use, the trick is figuring it out

The downside to this protocol is that it can change with each new release of ROBOTC. It was not intended for us to use but rather the ROBOTC IDE and debugger to be able to communicate with the VM running on the cortex. It’s mainly for this reason that I have never publicly released the corecom software as testing with each new version of ROBOTC and also check compatibility with all the old versions that may still be running is a bit of a chore, however, for my own use this is not much of a concern as if it breaks I just fix it.

[fretless_kb]

Thanks James, Lots to ponder here, all very interesting. I think for my goal of computer interfacing with a Robot I probably would still get the Vex Pro and go that route. I still haven’t fully committed to that investment.

However, This line of development could be very useful if only to figure out how to improve my ROBOT C Code and Debugger use. I really like the amount of information the debugger provides, but find it somewhat difficult to wade through the pieces (of data) I have found several times we are working on a specific capability we have to jump between Motor tabs, Variables (which sometime we re-code where they are defined to group them together) I would love to have the ability to define a dashboard to allow all the key data items for a particular debug scenario be defined together. Easy C has the Graphic Output capability which was awesome, until performance degraded from one release to the next and for other reasons I’ve drifted away from Easy C.

One last Question then I need to do more thinking and research I think before I have more questions for you or others.

In your experience with the Cortex Monitor Code does the Cortex always pass back all the data the debugger allows, specifically I would be concerned with the Global and Local variables, or are there ‘modes’ or something that allow or restricts the information flow?

I try to write efficient code (this often requires multiple passes at writing functions) but some of the limitations of the VM result in what I would call an over-use of global variables, and ultimately all the variables global or local are passed through the debugger. Is this traffic controllable? or is it alway on? Assuming you can turn the info stream on and off from the Cortex to the ‘debugger’ Is the amount of information passed back from the Cortex controllable? or is it (as I suspect) a dump of everything the RobotC debugger sees?

Cheers Kb

[jpearman]

@fretless_kb

Thanks James, Lots to ponder here, all very interesting. I think for my goal of computer interfacing with a Robot I probably would still get the Vex Pro and go that route. I still haven’t fully committed to that investment.

I would also like to get my hands on a VEX Pro but the limited funds I have for this hobby will not allow that for a while.

One last Question then I need to do more thinking and research I think before I have more questions for you or others.

In your experience with the Cortex Monitor Code does the Cortex always pass back all the data the debugger allows, specifically I would be concerned with the Global and Local variables, or are there ‘modes’ or something that allow or restricts the information flow?

The information returned back to the PC is determined by the message sent from the PC, in other words, the cortex only sends back what you ask for. Variables are a bit tricky and I do not display them in corecom. The ROBOTC debugger has to associate memory addresses with variable names, it can do this as it assumes the source code running was the last thing you compiled and downloaded. Without the source code and knowledge of the way variables were assigned to memory it is difficult (well actually impossible) to display them by name from a user developed application.

I will send you a pm with some more useful info I would rather not post publicly.

[fretless_kb]

RE: the Vex Pro, I want to ensure I have the time to work on it before I invest the capitol. At least with the Cortex I have the excuse I am working out examples for the Teams.

RE: Debugger Stream, That is very interesting to know I will have to try some experiments to see If I can assess robot and or Link performance changes based upon program size and number of tabs open in the debugger, it could prove useful in the future.

Cheers Kb

[stevedh]

Hi
Just thought I’d resurrect this thread after having a chance to play a bit with the cortex based system I recently got for my Daughter.

Personally I’d see this attracting a different user to the current and may even open cortex up to another market, i.e the hobbyist enthusiast who isn’t rich enough to go for vex pro, but wants to go beyond the limits (such as 12k ram) imposed by RobotC and EasyC.

1stly to comment on the initial set of comments posted by jpearman

@jpearman

1. CMU and Intelitek have invested time and money into creating two reasonable development environments for us already. They are in business to hopefully make a profit and I would not want to create something that would have an impact on that.

I think this would have minimal impact as I think it would be of interest to a different market, i.e. enthusiasts and hobbyists as apposed to High Schools and clubs wanting to enter competitions.
A Homebrew solution is likely to be more complex to setup and probably less friendly to code.

@jpearman

2. When there is currently an issue we can call on tech support and hopefully the issue will be addressed. With a homebrew development system there will probably be no tech support beyond what the developers are willing to do for free. This would be a bad situation for teams using this software.

Again different market, anyone who used this would have to accept this, but in my experience if there are enough enthusiasts to develop this then an answer to a problem will probably exist somewhere on a forum.

@jpearman

3. An alternative environment that was not endorsed by IFI, and could potentially cause damage to the cortex due to unforeseen changes made by IFI, would be a liability for the developers. In other words, I don’t want to be responsible for breaking your cortex.

There would of course have to be a disclaimer to that effect for anyone who wanted to use it. But the likelyhood of damage should be pretty small. Were there any problems reported along this line with the Pic and its alternative software solutions?

@jpearman

4. After all this work I’m not sure it would be a better system for the average user.

For the average user It wouldn’t, but for a hobbyist/ enthusiast who wants to push the cortex to its limit it would be better then what is current on offer.
For my daughter who wants an easy way to program the cortex it wouldn’t. I also see it as maybe not being competition legal… maybe…
If it was mine then I’d soon want to brake out of the limits imposed by the current software.

@jpearman

5. I want to build and program robots not make the tools used to do that.
   .

Where as I quite like programming tools, and so do others, although admittedly I have very little spare time. However seeing the sort of home-brew stuff enthusiasts can produce you just need the right people… horses for courses and all that.

Personally I’d love to see the cortex internals documented and be able to delve into the hardware, maybe re write the usb/wifi code (are its limits on the cortex hardware or software?), and perhaps use it more like a baby vexpro.

I think the reason this wont happen though is that vex pro exists and opening vex up to those outside its very niche market could possibly have an impact on vex pro sales.

anyway just some thoughts

Steve