Working with the PSoC

[PortugazD.Ace]

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!
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!!!!

[iblis432]

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?

[PortugazD.Ace]

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?

[kamocat]

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:
http://forums.usfirst.org/showthread.php?t=13082

[PortugazD.Ace]

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?

[kamocat]

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:
http://www.cypress.com/?id=1353&rtID=113

[iblis432]

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.

[PortugazD.Ace]

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.

[Ether]

Originally Posted by PortugazD.Ace

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 <R63> and <R64> 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 <R63> and Rule <R64>, 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 <R56>). 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.

[PortugazD.Ace]

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.

[EricVanWyk]

Originally Posted by PortugazD.Ace

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

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.

[Radical Pi]

Originally Posted by kamocat

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.]

actually...http://frcdirector.blogspot.com/2010...-part-iii.html

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!

[iblis432]

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)

[PortugazD.Ace]

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.

[EricVanWyk]

Should've mentioned this earlier - http://www.cypress.com/?app=forum
That forum will likely be much better suited for you, as they actually know what they are doing

Originally Posted by PortugazD.Ace

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.

Word of Fair Warning - That is a big chunk to bite off. You'd be well served by breaking it down into a few smaller chunks.

Consider using I2C or SPI instead of Ethernet as your communication protocol - they are slower, but have fewer "gotchas" and are better supported by the PSoC.