Working with the PSoC

I am currently working on how to work with the PSoC. It uses a special form of C. I had the idea to create something like a sub computer with it, setting it up with some RAM and an external data source. my only problem is, I don’t know how to program the thing in the first place!:frowning:
I have a little experience with C++, but only with windows programming. I don’t have a clue on how to do hardware programming in C. Help Please!!!

I’m a bit confused at what you are trying to do with it. Are you doing something seperate from FRC with it or are you just trying to use it for the driver station IO?

This is for next years’ compitition. You see, no one on my team know how to work with the PSoC. So I’m pretty much doing all of the work on it. My idea is to set up a base control program in the PSoC, and then create special programs stored on SD cards. The SD cards are inserted into a SD slot on the control station, and the station sends the data to the PSoC on the robot. Are you following me so far?

That sounds interesting.
I think the biggest problem you’ll run into is that FIRST hasn’t released their source code for the PSoC or the Driver Station.
Here’s a thread from a year ago on this:

I don’t need their source code. I intend to write my own. The reason I started this thread was because I need some tutorials on PSoC hardware programming. I noticed that I can use C++, so that will be helpful in the programming process. But in my final project, because I intend to use an external memory system(RAM), I need to use a good bit of C. So can anyone post tutorials on PSoC3 hardware programming?

Oh, I’m sorry, I misunderstood you.
I thought you were intending to put the PSoC on the driver station.

The User’s Manual has a basic example. Here’s a list of sample projects:

I’m not sure on the rules for using the PSoC in that way are. If its legal, that sounds like a great idea and I may be interested in doing the same, but I have a feeling there will be a rule somewhere stopping you.

The only rules for custom electronics are that the circuit cannot interfere with another teams robot in any way, shape, or form. that and the electronics cannot be outside of the robots footprint.

<R03> Custom circuits and COTS electronics are expressly PROHIBITED if they:

A. Interfere with the operation of other ROBOTS.

B. Directly affect any output devices on the ROBOT, such as by directly powering a motor, supplying a PWM signal directly to a speed controller or supplying a control signal directly to a relay module (see Rules and for the specific exception regarding CAN-bus devices).

<R50> Custom circuits shall NOT directly alter the power pathways between the battery, Power Distribution Board, speed controllers, relays, motors, or other elements of the robot control system (including the power pathways to other sensors or circuits). Custom high impedance voltage monitoring or low impedance current monitoring circuitry connected to the ROBOT’S electrical system is acceptable, because the effect on the ROBOT outputs should be inconsequential.

8.3.8 Custom circuits may be used to indirectly affect the robot outputs by providing enhanced sensor feedback to the cRIO-FRC to allow it to more effectively control the ROBOT.

<R68> All outputs from sensors, custom circuits and additional electronics shall connect to only

A. other custom circuits, or the following:
B. additional COTS electronics, or
C. input ports on the Digital Sidecar, or
D. input ports on the Analog Breakout, or
E. the RS-232 DB-9 serial port on the cRIO-FRC, or
F. the Ethernet bus connected to Port 2 of the cRIO-FRC, or
G. the CAN-bus if and only if all Jaguar speed controllers on the CAN-bus are wired in full compliance with Rule and Rule , or
H. the sensor inputs on the Jaguar speed controller.

Custom circuits and additional electronics are allowed to utilize the Port 2 Ethernet bus and/or the CAN-bus to communicate between devices. Note however, that the ROBOT must be controlled by the cRIO-FRC (see Rule ). Thus, any additional devices on the Ethernet or CAN-bus must not provide command signals that do not originate from the cRIO-FRC It is our intent to incrementally open access to the full control system technologies in a controlled manner that reduces the risk of “unanticipated surprises” as we gain experience with the system.


My idea follows all of the rules. the system is only for dectecting enviromental changes and telling the cRIO how to react using preprogrammed commands in the cRIO. that is all I want the PSoC to do. also, don’t forget that those were last years rules. the rules could be different this year.

I see I don’t need to give any of my standard warnings :slight_smile:

For what it is worth (nothing), my understanding of last years rules agrees with (my understanding of) your understanding.

The best advice I can give you is to plan your project out into small, proveable chunks. At each step along the path, you should be able to point to something and say “this proves that it is working the way I think it is”.

For example, it may be worthwhile to make a simple version in which it simply reports whether or not something is true using a simple pin. You can attach an LED or a multimeter to this and watch it blink.

Also, don’t be intimidated by the PSoC’s programming environment. If you already know C++, you are well on your way. Again, just start simple.

As to its hardware configuration, this is done graphically. The interface is relatively straight forward, but I’d do a tutorial or two first just to get a lay of the land.

If you look through this year’s rules there is something stopping you.

<R60> The control system is designed to allow wireless control of the ROBOTS. The Classmate PC, FirstTouch I/O module, cRIO-FRC, speed controllers, relay modules, wireless bridge, batteries, and battery charger shall not be tampered with, modified, or adjusted in any way
A. User programmable “dashboard” code in the Classmate PC may be customized. (tampering includes drilling, cutting, machining, gluing, rewiring, disassembling, etc.), with the following exceptions:
B. User programmable code in the cRIO-FRC may be customized.
C. Dip switches on the cRIO-FRC may be set.
D. Speed controllers may be calibrated as described in owner’s manuals.
E. The supplied fans attached to the Victor speed controllers may be powered from the Victor power input terminals.
F. The fuse on the Spike relays may be replaced with a 20 Amp Snap-Action circuit breaker.
G. The alligator clips on the battery charger leads may be replaced with Anderson Power Pole connectors (note: this is a recommended modification).
H. Wires, cables, and signal lines may be connected via the standard connection points provided on the devices.
I. Fasteners may be used to attach the device to the OPERATOR CONSOLE or ROBOT.
J. Labeling may be applied to indicate device purpose, connectivity, functional performance, etc.
K. Brake/Coast jumpers on speed controllers may be changed from their default location.
L. If CAN-bus functionality is used, limit switch jumpers may be removed from a Jaguar speed controller and a custom limit switch circuit may be substituted (so that the cRIO-FRC may read the status of the limit switches).
M. If CAN-bus functionality is used, the Jaguar firmware must be updated as required by FIRST (see Rule <R63-D>).
N. If the FirstTouch I/O module is not used as part of the OPERTOR CONSOLE, the embedded software may be modified. If the First Touch I/O module is used as part of the OPERATOR CONSOLE, the default software image must be used.

Sure there is a possibility this rule ceases it’s existence for the 2011 season.

The Cypress IO board is going to be on the robot, not attached to the control console.

Ah okay then, sorry about that, I did misread your earlier post.

I find that this would definitely be a good idea, seeing as the PSoC card also has a fair amount of sensors on it too. The proximity sensor on there for example might of been useful for this year’s game.

As I work out the symantics of my base program and the circuit schematics, I will post attachments so that way, everyone is on the same level.

Dang the rules!

there goes my idea to have autonomous driven by a rat fetus’ brain >.<



More specifically:

Source code for the Cypress board is now available. There’s a link on the Robot Control System page of our website, or you can go directly here.

I’ve looked at it, it’s the code used in FRC. Hope it helps!

I grabbed this source code when it first came out to the public, but have yet to actually take a look at it. I’m very interested in this idea, I had thought about something similar last year but thought that rules were in the way, but I see now they are not. You certainly have my mind thinking about next year’s game. I’d be very interested in seeing your results. I’m just curious, how are you attaching it to the robot? (ethernet, CAN ect)

I’ll probably create a custom circuit board using DipTrace, and designing an ethernet port into it. I’ll probably have to talk to my team’s programmer on setting up a command conversion tool.