Spoiler: Could this be the new software for the FRC 2006?

CoreChart™FR is a flowchart like Graphical Icon Assembler designed for the popular FIRST Robotics Competition robotics controllers. Based on CoreChart Professional it simplifies the programming of the PIC18F8520 chips in the Innovation First Inc robotic controllers used by the competition. CoreChart underpins the highly successful University High School Industry Robotic Peer Mentoring Program for microchip Innovation Skills development.

Looks like CoreChart has been developed for the FRC.
http://www.elabtronics.com/CorechartFR_FRC_Example_Manual.pdf

Could mean easier programming in the 2006 season.

Anyone have any insight?
http://www.elabtronics.com/CoreChartFR.htm

Here is a link to a TRIAL download: (30 days)
http://www.elabtronics.com/CoreChartFR_Setup.zip

Bah, where’s the Mac version? :stuck_out_tongue:

USE AT YOUR OWN RISK! This software has not been endorsed by either FIRST, IFI or Radio Shack Publicly to use on any of the products.

This seems similar to the programming software for the Radioshack Vex kits. Its called “EasyC” and it makes the average school teacher or high school student a “programmer” in about 30 seconds. While this program is only in beta, I have gotten a chance to work with it (and gotten my hands on one of those nifty little orange programming boxes) and it is amazing. You simply pull a motor or sensor or if statement, etc from a box on the left into your “work area” and it creates a visual flowchart of the code you are creating.

It is great to see that there will be a full scale version of this for FRC robots as well. Makes my job about 1000x easier :smiley:

With out a default program its kind of useless for first. Wonder how the the master-slave would be handled. I didn’t see any SPI subroutines. No pic C . Goes from graphic to assembler. Would be interesting if they duplicated the IFI effort and it was approved for competition.

I don’t see a reason why it has to be approved for competition. I thought IFI’s stance always was if you modify the code and introduce a bug it’s your problem, not theirs.
IFI put a built in safety mechanism. If your “user processor program” doesn’t play nicely and behave the way the “master processor’s program” wants you to it will shut off the outputs making your robot dead in the water.

This software has not been endorsed by either FIRST, IFI or Radio Shack Publicly to use on any of the products.

I think it could be “Endorsed” by FIRST. The title says " for FIRST" and it’s got FIRST logos on the website. Seems to be they would have to gotten permission to endorse it…just my thoughts…

If its really for an FRC bot, why are there pictures of a Vex bot on the page?

I haven’t tried it out yet, so I’ll ask:

It sounds similar in idea to the LEGO RIS default programming environment. Is it?

If in fact FIRST decides to go with this, and based on the information provided, it seems like there’s a good chance that they will, I really hope that they don’t require teams to use the program (which they probably won’t).

While a tool like this can be very useful in teaching logic and program flow, it quickly becomes messy and hard to read when you start doing complex things.

Just look at the VEX Controller Examples on the page listed in the original post. Check out the example on page 16. Simply looking at the code makes it impossible to figure out what’s going on. I look at the diagram and am immediately overwhelmed by a barrage of shapes and colors. The text on the symbols is useful for some things (like pwm01 = 40), but for others it is very non-helpful. “IF Zero”…are they saying “if(0)” or “if(somevariable == 0)”, and if so, what is somevariable? They also use GOTOs, which can be incredibly confusing and are usually taught to be avoided at all costs.

In an example in the FRC examples on page 14, I look at their flowchart and understand what they’re doing, but without reading their description, where does TEMP2 come from? It turns out that it is set in the Get_Analog_Value routine, but who would’ve guessed? Is it hard-coded that rc_ana_in1 gets assigned to TEMP2 or is that user definable?

Point is, it adds a layer of abstraction that makes the code harder to read. Does this mean that we’ll have to compile twice? Once for the flowchart, then once again to compile the assembly into the IFI code skeleton?

I understand that the programming world is moving toward things like SDL and UML to autogenerate code, but there is still no substitute for learning how to write code for yourself. In fact, I contend that you are better off learning to program in a textual language then applying that knowledge to autogeneration. There’s just so much control you can have with a high level graphical language, not to mention that the generated code is usually enormous and inefficient (two things that cannot be sacrificed on the FIRST controllers)

I think that the money and effort spent on developing this tool would have been better spent coming up with a solid curriculum to teach students how to program in C. With a little time and practice, I think that most people would find that there is no magic involved in programming.

I appreciate the efforts made by Elabtronics, and I hope that there are some people out in the FIRST community that will benefit from them. I just don’t see myself using a graphical tool like this on anything complex.

This seems very similar to programming in FLL. Most teams use Robolab (graphics based) but teams are allowed to use ScriptEd (which is a scripting language) (even if BricX isn’t allowed).

Bah, I’ll stick with LabVIEW. Once I figured out how to control the RC with LabVIEW, I haven’t looked at C code.

Yes it does. Very much so.

If you think about it while a lot of people prefer the normal programming of an FRC bot using mplab. This could help some teams who may not have the mentor support to teach a student C. I think its still a benefit to the FIRST Community no matter what. There will always be teams that will not have the full capabilities as others and this is something to help those teams.

I sure hope they DON’T switch to this… Programming is already really easy (I mean, all hardward interfacing code is provided, the autonomous scripting is there if you choose to use it, etc.) and more simplification would just ruin any remaining challenge to it IMO.

Or maybe provide it but still let you use C…

Bahh… I think you programmers are overlooking something. While it might be easier for the initiated, C++ is a nightmare to learn in a matter of weeks for people with no prior experience. For small teams who barely get away with programming enough code to make their robot move in a few directions, this thing could be a godsend. For people who don’t understand C, this could help them to actually have some autonomous code among other cool features that wouldn’t have been possible before. True, it would be a bad thing to require the use of it for all FIRST teams, as many teams have programmers that are fully capable of coding in C, but I think it’s shortsighted to blast something that you aren’t familiar with.

Ultimately, used as another tool to help teams get off the ground faster, this thing could be great.****

^^^ Totally in agreeance :smiley:

I’ve seen a demo of the software that VEX will use and it is very similar to this. It contains pre-written sub routines, but you can still write your own. The best part is that you do not need to know the language and still be able to generate code…

Perhaps then people should get familiar with C before the season? I can understand why this might be good, but at the same time, it kind of punishes the people who really know what they are doing, IMHO. Besides, part of the FIRST experience is exposing people to things they’d find in the real world, and in the case of programming, that’s C and not some drag and drop thing.

Right. You are almost exactly right. This would be a “beginner” thing to help people starting out learn some basic things of C then after there first season they can spend time learning the real stuff for the second season.

I believe you are wrong on the real world thing from what i understand. Most of the time yes its learning the true language like C or whatever and flat out coding. But form what i understand there are places that use things like this all the time. In the REAL WORLD the is a easy way and a hard way. The easy way is a quick solution that you can’t do much with and isn’t very efficient. The hard way is a time consuming more efficient solution that you can do everything with. Most of the time in the real world you have to deal with the “hard way” a lot more.

In the real world there are times where you know nothing at all and have to learn it on the spot, and most of the times are that way. But then there are other times when you can spend time and learn it well.

This is an example. You have the time to use this program and learn some basic stuff from it. That will start you out. Then you can move on to the real code and stuff in between the first and second season. I believe if everyone does it this way there going to learn so much more and its going to stick in there brain so much better.

Wouldn’t you rather have someone learn it and have it stick with them rather than learn it and not stick with them?

Anyway thats my $.02 worth. You can agree or disagree… i am just stating my opinion on how i think students would learn better.

CoreChart does have a very user friendly interface. But it is a real assembler. CoreChart is 1:1 with machine code ( assembler ) instructions, 32K of
PIC memory means you can use 16K ( 16000+ ) instructions.

CoreChartFR includes the operating system for FRC, but CoreChart and CoreChart Professional are used on bare PIC chips to program real world PIC products.

CoreChart is industry strength and it is used by engineers in defence and scientific research organisations because it is simple to get started and speeds up PIC applications. The dramatic reduction of “time to market” by CoreChart in PIC applications is critical to a business in the real world.

As an example, one industrial product of ours is called an ‘Intercooler Spay
Controller’ for turbo cars. It measures ( to 1% accuracy ) the duty cycle of
the fluctuating car ignition injectors, and 2 temperatures, and 2 adjustment
pots at a sample rate of 10,000 samples per second, then evaluate and output a high speed control signal as well as an updated LED display - all at the same time in real time on the car to cool the turbocharger so it does not
overheat. This is no big deal. The big deal is that CoreChart enabled the
software to be written using just 200 instructions ( which uses 400 bytes of
memory ) on a 1k PIC chip running at 4MHz - which leaves lots of room for
expansion. The product is getting rave reviews and is selling very well.