New 32 System-on-Chip

*(http://slashdot.org/article.pl?sid=04/10/08/1734250&tid=137&tid=1) (I know its probably not going to happen for 2005) The features on this chip really are amazing when compared to our dinky 8bit microchips.

I wonder if any team will consider using such an advanced SOC and interface it with the current system to get the added processing power and features.*

Hummm… Lunix on a FIRST robot, sounds like fun! :slight_smile: It would be nice to see this happen while I am still on a FIRST team but I doubt this would happen for several years. Due to the fact that many teams had trouble with the 8-bit processors. But it would be cool none the less if a team was able to interface it legaly to the current controller.

Even if we can’t use the 32 bit chips for FIRST robots, I might implement one in the robots I make to see how much faster I could get the processing done.

I disagree, I think teams will have an easier time with a 32 bit chip mainly because it would be a lot easier to use code written for 32 bit systems; code that is a lot easier to find.

If you’re writing your code in C (as most teams are, obviously), then there’s very little noticeable difference between writing for an 8 bit or a 32 bit CPU. The whole point of languages like C is that it abstracts things like the type of CPU from the programmer.

Last year while developing for the new RC we set up a system that allowed us to compile our RC code on a desktop machine for testing. If you take a few precautions then it’s very easy to write code that runs without modification on almost any platform, and a good deal of code that you might think of reusing is probably written like this anyway.

Despite the fact that the chips you reference are 32 bit, they still have “dinky” amounts of RAM and FLASH (comparable to the amounts available in the current PIC processor that the RC uses). The $3 part only has 8KB of RAM and 32KB of FLASH. I don’t think you’re going to see anyone running Linux on that any time soon.

Besides, even if someone did manage to squeeze uClinux into one of these, there’s not going to be much room left for application development!

Due to the fact that many teams had trouble with the 8-bit processors.

What specific problems are you talking about? Can you provide some examples? I thought the new RC went over quite well considering it’s a new programming language.

I’ve been working with the 32 bit ARM chips lately, particularly the “thumb” sized system on a chip ones. You can switch to a 16 bit instruction set for speed and space, but still do 32 bit operations (including floating point). This is the same chip that’s in your GameBoy, PDA, car and lots of other embedded devices.

I’m hoping FIRST will switch to these eventually, as they are much more powerful than a PIC. A lot more RAM and FLASH to work with. A tad bit more expensive, but the GNU ARM compiler is free and will host on Windows or Linux. Certainly capable of running embedded Linux if necessary.

I’m thinking FIRST should allow us to choose from a variety of robot controllers, even choose one of our own.

I’m looking at this for my own homegrown robot: http://www.littlearm.com

The technical complication of this far exceeds the bennifits. Essentianlly, you would have to create some sort of generic slot type interface. With multiple I/O pins and voltage lines. This is because every microcontroller or DSP has a different pin out. It is a safety concern if a user written routine has direct control over PWM or relay outputs, therefore we must talk to Innovation FIRST’s microcontrollers before information is sent to the PWMS or relays.
Because of this, each microcontroller or DSP a team would like to use would need to have a custom PCB made so they could interface with the generic slot.

I would like to hear some actual reasons as to why we should move away from the current microcontrollers. In engineering, you decide what products you are going to use based on requirements. Our requirement is that the microcontoller has to be low cost, have enough I/O, easilly programmed, have enough internal/external storage space, and be able to loop a default program before the time out (~ 25ms, IIRC).

I think the microcontoller IFI chose perfectly met their requirements.

http://www.charmedlabs.com/

I’ve been working with the 32 bit ARM chips lately, particularly the “thumb” sized system on a chip ones. You can switch to a 16 bit instruction set for speed and space, but still do 32 bit operations (including floating point). This is the same chip that’s in your GameBoy, PDA, car and lots of other embedded devices.

You know there are devices that actually allow you to turn your gameboy into a robot.

Allot of time and money went into the 2004 controller. It’s good enough for what it needs to do. I would rather see the current controller expanded to support a co-processor bus or port and a supported communication protocol.
This way an advanced team could add co processors of their choosing and have a standard to interface with the First controller. Example: a co processor to read interrupts from drive train encoders and then send
total distance traveled and calculated velocity for each wheel to the robot controller when polled. A co processor to track the IR sensors and do the position calculations. I picked up some microcontrolers from http://kronosrobotics.com/xcart/customer/home.php
this summer for our team to look at as coprocessors.
Gary Deaver