Open source development for the cortex

[jpearman]

Originally Posted by 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.

Originally Posted by 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]

Originally Posted by 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]

Originally Posted by 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.

[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 http://www.vexforum.com/showthread.php?t=43594 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]

Originally Posted by 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 http://www.vexforum.com/showthread.php?t=43594 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]

Originally Posted by 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

Originally Posted by 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.

Originally Posted by 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.

Originally Posted by 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?

Originally Posted by 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.

Originally Posted by 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