I need control code so I can use my OOPic C with the PS2 controller to control my robotic arm. If you know where I can get code for an arm it would be great. I would like to find code already in the “OO” language, but if not then it would still help me out if it was for an arm. All the code I have seen is in the Basic Atom’s basic or the BS basic. I really need a program for the OOPic C. I am wanting to use a wired controller by the way. My robotic arm has five degress of freedom.
Sorry, buddy, I’ve never seen any code for an arm in OOPIC.
I guess that means that you’ll actually have to learn how to program.
GASP
To be honest, learning a programming language (even if it’s your first programming language) is not difficult, especially if there’s adequate tutorials, example code, and a decent manual.
I believe that OOPICs have all of that.
Translating the code from Atom into OOPIC is doable if you have a good understanding of your chip.
The differences between the two chips are miniscule, even though the code may look a bit different.
The hardest part about programming an arm is probably learning to deal with inverse kinematics.
You’ll be happy to hear that LM has quite a few excellent tutorials on IK.
There also happens to be a tutorial for driving an H-Bridge with an OOPIC, which you may find useful for basic reference.
lynxmotion.com/images/html/build023.htm
If you’re looking for a quick-fix solution, you can purchase a BASIC ATOM and simply load the code that’s already been made for the arm.
I think, though, that in the long run, you’ll have a lot more fun learning how to program the chip you have.
There’s something very rewarding about being able to say “Yea, I made that”.
That is exactly the experience I have been having since I started building W.A.L.T.E.R., my first robot. This has been one of the most rewarding experiences I have had to date - doing all the hardware, software, and even mechanical stuff that building a robot requires. 
I am not known for my mechanical dexterity, you see. 
8-Dale
I am learning the language farely well, the only problem I am having is knowing what kind of object to use to detect the PS2 controller. I am not saying I am an expert because I just started OO language, but I can say that I purdy much know the basics of programing. I actually have an Atom microcontroller, but like you said, I don’t want to use it because I really want to learn OO and I want to solve the problem instead of going the easy route which is something I always seemed to take. I didn’t buy it because of the programing though. My arm seems to do OK, but it’s not perfect, but it is what I need for the project. My arm isn’t where I’m having problems though. I am having problems figuring out a program for the PS2 controller.
Ahh…
It didn’t sound like you had the basics down, in your first post.
In that case, we can probably help you.
I’ve never used an OOPIC, but I am currently writing code for a local Robotic FIRST team’s PS2 controllers in C.
So I can probably tell you what you need to look for.
From what I’ve gathered from the two ATOM PS2 tutorials, Next Step PS2 tutorials, and example code, the PS2 uses a form of SPI (sycronous serial) communication.
This page that I googled is probably what you’re looking for, concerning the necessary OOPIC object:
oopic.com/ospi.htm
Here’s a run down of what the ATOM code tells me we need to do:
(All pin references below are what the tutorial names the PS2 pins to be.)
Before doing any communication, set the CLK pin high.
Any time we need to send or recieve data, we must first set the ATT pin low.
After the send/recieve, we set the ATT pin high again.
This is sort of a way to slap your controller so that it knows to listen up.
When you send data, you’ll be sending up to 18 bytes in a row (when setting up controller configurations) or as little as one byte (when requesting information back from the controller).
All this happens on the CMD pin.
When sending data, make sure that you’re sending out the most significant bit first (the 7th bit, in our case).
It’s important to remember that your PS2 is the slave and that it won’t magically start sending you things.
You have to tell it to do so.
When reading from the slave, the slave is going to be sending the least significant bit first (the 0th bit, in our case).
You’ll always read from the DAT pin.
From those example programs, it looks like:
(I’m showing the values in binary below, since they make more sense than hex or decimal.
Your micro will be wiggling the CMD pin to a 0 or a 1 to do this communication, so it’s nice to look at it in binary, since it’ll look like what your micro is actually doing on that pin.)
send: B’0000 0001’
recieve: 1 byte (Controller mode)
send: B’0000 0001’, then B’0100 0010’
recieve: 3 bytes (Controller mode, Digital Directional Buttons, Digital Action Buttons)
send: B’0000 0001’, then B’0100 0010’, then B’0000 0000’, then something*, then anothersomething*
recieve: 4 bytes (R Joystick X, R Joystick Y, L Joystick X, L Joystick Y)
*I don’t understand exactly where “something” and “anothersomething” are getting their values (called “large” and “small”, respectively, in the example code).
In the code, they’re given the values of temp(8 and 7), respectfully.
But, temp(8 and 7) are given no values, so I’m guessing that “something” and another “something” both are: B’0000 0000’
I haven’t yet read the SPI section of the PIC (the set of micros that I’m familiar with) datasheets, so I might be missing something (i.e. do we pause between each byte we send?).
I’m also pretty sure that the CLK line needs to be wiggled in some way, perhaps in sync with sending or recieving each bit.
I’m going to be programming all this in assembly, so I’ll probably have more trouble than you will with your OOPIC.
On the plus side, though, I’ll probably be forced to get a better understanding of how it works down at the micro level, which is always nice.
When I get something that works (or if I get stuck and frustrated) I’ll post the code.
Assembly is nasty to look at if you’re not used to it, but you’ll be able to see how things work by reading the comments.
Hope this helps…
Can someone verify all of this?
I’m going to be writing the code for it sometime this week, so it’d be nice to know if I’m accidently inventing things.
Well, I got bored yesterday night, so I sat down and wrote the code.
I’m almost finished with it (about 400 lines of assembly, yuck!) but I’ve hit a road block.
After reading my micro’s data sheet on SPI communication, I found out four things:
(1) The CLK wiggling that I mentioned earlier is all done by my processor (sweet!).
(2) My micro only sends and recieves most significant bit first.
(3) In SPI communication, my micro both sends and recieves at the same time.
(4) And my micro MUST both send and recieve something during every CLK wiggling.
The first is nice.
The second doesn’t bother me, since I’ll only be recieving things and storing them backwards.
I can always do an algorithm to reorder things.
I’ll be sending in the right direction, so I won’t be messing up the PS2.
EDIT
Even better idea.
All I gots to do is hook up the IFI’s PORTD pins in reverse order to my 877’s PORTD pins.
Then it’ll read the byte backwards, which saves me from needing an algorithm to fix things.
EDIT
The third one makes me leery.
The ATOM seemingly completely seperates SHIFTIN and SHIFTOUT as two totally different operations.
In my micro, I have to read from and then overwrite to a variable to make another SPI cycle occur.
The fourth reinforces my leeriness.
In the code found here, the second to last SHIFTOUT has only two bytes sent, while the corresponding SHIFTIN has three bytes coming in:
lynxmotion.com/images/html/build026.htm
How is that possible?
I can understand how having more SHIFTOUT bytes works; I just ignore the bytes that are sent to me every time I send/recieve.
No biggie.
But, my micro requires me to send something when I want to recieve something.
My choices are: send an 0x00, send a predetermined value that will mean nothing to the PS2 (do you guys know one?), or change my micro’s SPI data out pin to an input.
I have no clue how the first option would effect the PS2, because I don’t understand how the syntax for speaking to it.
I don’t know if there’s any predetermined “just send me another byte” characters for the PS2, so the second option doesn’t help me.
The third option seems promising, but I wanted to check with you guys.
My data sheet tells me that changing the SDO (Syncronous Data Out) pin to an input would effectively send a “dummy” character to the PS2, because the pin would be on high impedance.
So, should I send a third “dummy” character to make up for the extra character that I’m recieving?
For any who are interested in etching their corneas and getting severe headaches, you can view my current code here:
lynxmotion.net/viewtopic.php?p=13195#13195
I didn’t want to clutter up this thread with it, as it’s over 400 lines long and still growing.
I still need help with this. I need help on setting the SPI object up. I don’t know what binary values I will need and how to make the SPI read them from the PS2 controller. I don’t know how I need to represent the values of the buttons. I’m not even sure I know how to set up the math of the controls but I think I can manage on that part, for I mainly just need help on setting up the basic communication from the PS2 controller and the OOPic-C using the oSPI object and constants or whatever else I need to us. I purdy much understand which pins are used for what but I don’t know how to send and receive values from the pin, that’s where I need help; the communication.
Looks like you were busy!
I have not done any SPI programming on a PIC, but I have done it on an AVR processor. If I remember properly it also did both input and output on the same time. What I remember doing was that I used two other IO pins as Chip Enables, one for the input chips (74HC589) and one for the output chips(74LS595). Depending on which operation I was doing (input from swtches), outputing to LCD, etc, I would enable or disable the appropariate signals.
I wonder if you could do something similar with SEL signal? Just a thought…