I suspected as much. I can get signals and power directly from the ICD2’s ICSP connector. This also indicates a probable problem with the breadboard ICSP connector.
Until now I had not ruled out a problem with the connector. I suspected the connector might not be going far enough into the breadboard, but was not absolutely sure until now.
Oh yeah! I can feel success is very close now… 
8-Dale
Update:
I decided not to mess with the ICSP connector I have been using on my breadboard and just use some jumper wires to go from the ICD2 cable to the breadboard. Then I decided it would be good to double check my wiring from the ICD2 cable to my circuit, which I did, and that made me look closer at the ICSP connector diagram on the Olimex site. Something just didn’t seem right, and it wasn’t! I had wired the connections from the ICSP cable of the ICD2 exactly BACKWARDS!
ICSP Connector diagram:
It turns out I actually had two problems instead of one - the ICSP connector not going into the breadboard far enough to make contact, and the connections to my circuit were wired backwards.
Anyway, I HAVE SUCCESS NOW! After I corrected the two problems, I restarted MPLAB, selected the programmer to be the ICD2, and it came right up and correctly identified the 16F877A I have connected. :D:D
I believe having some sort of note attached to the ICSP connection diagram about how the connector is oriented would have been very helpful and may have saved me from wiring things backwards.
I am quite happy now. :D:D:D
8-Dale
This is the longest two man thread ever!
Congrats on the success!
also, that diagram looks like It came from eagle cad. Its just a symbol and I can see how you could wire it backwards without some kind of referenece to pin one.
For future referance, pin one can be identified as a square pad where the connector pin goes through. This is not always the case but it is common to see this on many boards.
It’s actually a 4 man thread now… You and Grasshoppah joined.
Thanks!
That’s what it looks like to me too.
The only thing that clued me in to the wiring problem is I got to looking at position of the connections with respect to the sides of the image. Otherwise, I may never have guessed there was a wiring problem.
8-Dale
What is you goal with this board? Are you just expanding your knowledge or do you have a application in mind that you will be using it for?
Right now, I am going through my learning curve of how to develop with PICs. This is also expanding my knowledge. 
I eventually want to be able to use PICs for robotic projects, either as main controller or at least as slave modules communicating with a main controller. This is also getting me back into programming with C, which I have wanted to do anyway. I want to do all future embedded/robotics development in C/C++ because these are more standard. WALTER is my experimental base for all things new.
8-Dale
Congrats on the success!
As nick said, “Now, go forth, young embedded programmer and multiply!”
SparkFun is a great place to learn about PICs, especially that most of their tutorials are based off of the 16F877A! I’ve got one of 'em somewhere but never got around to using it =/ I want to get one of 'em dev boards first.
Let us know when you have a blinking LED program working. It was such fun turning on the power for the first time for me! I didn’t expect it to work for me 
-robodude666
Thanks, Grasshoppah.
I love Spark Fun and Acroname both - they are great resources for components, widgets, and tutorials. I am working with the blink.c program from Spark Fun right now, and just got my first successful build using the Hi-Tech compiler with MPLAB. Now I have to get the Delay.c file and add it to my project.
I probably won’t even have to post when I have this working. You may hear my yell of joy when I see that LED blinking for the first time…
8-Dale
Hi Dale,
Glad to hear it! I think you got by lucky, because in the past I’ve shipped an ICD2 to a consultant, and he wired a cable for a prototype board backwards. That ICD2 did not survive!
As to Serial # 96, THIS thread is not over yet! It is our intent to develop and exchange ideas on a PIC based 'Bot controller. We’re interested in perusing Peter’s dual-uP project (started last year, I believe). Care to contribute?
I just had an idea, I can STACK two “Quick Flash” ('452/4620 PIC) boards for a “dual uP”.
Alan KM6VV
Well, I have had quite a bit of Q/A experience working jobs at companies like Tektronix. In fact, I once saved a then well known manufacturer of floating point processors for large computers about $50,000.00 in retooling and redevelopment costs when I found a power/ground problem on a project that was in the very last phases before going into full production. I was only working a temporary job there, but they extended my time to nearly a year.
I was feeling like something just was not right, but didn’t know what. Then I happened to be looking at the ISCP connector on the ICD2 and the picture from the Olimex site, which needs a pin one reference. That’s when I figured out the wiring problem.
Well said! Pete’s work is excellent and I think quite a lot can be learned from it and built on it. I think just adding a set of 3 pin headers to his dualPIC board would be a great addition and make it easier to use in projects.
I’ve been saying for quite awhile now that a bot board type board with a stacking setup for addon modules would be wonderful. A nice modular system like this would make it extremely easy to expand with additional modules and help cut down on cable mess - especially in smaller robots.
8-Dale
Hi Dale, Mike,
Three pin headers for servos? I guess I should check out the other peripherals that LM has already figured out.
The Quick Flash ('452/4620) boards are 4" x 4", with a simple 4/40 clearance hole in each corner. Nothing fancy for stacking; no “bussed” M/F connectors all lineing up or anything like that. Proto area, LEDs, only need LCD, power reg., sw and connector on top board. One could simply not populate the lower boards for undeeded parts, and pick up I2C and power, etc. from the top one. I haven’t finished thinking it through. I’ll be doing good to get just one 'Bot board up and running PS2 command and IK code. Immediate waypoint. There’s a signpost on the road up ahead…
Could always just make “simpler” boards below. The board is little too big for Eagle, but a 2" wide prototype area would be OK. So then a dsPIC could be used (below).
Mike, were you doing the vision in another thread? And wanting to “pass through” (dazy chain) SSC32 commands through a 'Bot board? I haven’t checked, but if the SSC32 will simply “ignore” commands not directed to it (and not hang up!), then you can “share” the TTL or RS-232 (as appropriate) signal coming down from the PC. I don’t think the Atom 'Bot board listens to the SSC32 anyway. Likewise the 'Bot board would have to tolerate and ignore commands to the SSC32. It could still respond to the PC. Just a thought. Your video processor (if you have one yet) could likewise here and parse commands directed to it, and ignore others. Two processors responding would be a chore. But RS-485 could handle that with the PC being the master. Each slave ('Bot and Video processor) would be told when to speak. The SSC32 MIGHT be made to play along with this game also. Level converters would be needed… and a handshake line from each used to turn the lines(s) around.
Alan KM6VV
Those nice 3 pin headers like on the bot board and SSC-32 for sensor and servo connections.
I am actually thinking about something more like this. See how nicely everything can stack together and share signals? That’s what I am talking about. I would much rather have a larger board size that could handle socketed chips though, especially for PICs since many have identical or at least very similar pinouts.
Breathe, Alan, breathe…
I hand this dream I had an Extra Class Ham ticket. Now where did THAT come from?
8-Dale
Hi Dale,
I’ve used New Micro boards before. An 8052H with BASIC. Nice boards, but a little pricey.
Larger? As a 'Bot board? I suppose you could go the full diameter of the CH3-R. What is the main diameter of the CH3-R body? Can someone tell me? I’m also curious as to the bolt-hole diameter of the 6 servo horns.
Alan KM6VV
No, I mean just large enough to accomodate socketed MCUs, with an appropriate number of 3 pin headers for sensor and/or servo connections. This could end up being a bit larger than the mini-ABB, but as far as I am concerned that would be alright. I don’t think it would be that much larger of a board, aside from perhaps having a 40 pin socket for the MCU and maybe an auxiliary dSPIC. Both could actually be 28 pin devices like the 2550/2620/2680 and the dsPIC4012. This would help keep the board small and still allow it to pack some serious compute power. I include the 2550 as a possibility because it has USB. Pete’s dualPIC board is designed around the 4620 and dsPIC4011 (the dsPIC4013 should work too). The dsPIC4011 and 4012 both have the quadrature encoder support.
I think a version of what Pete has done with 3 pin headers added and using the 28 pin PIC and dSPIC would be very nice, for example. Oh, and lets not forget those stacking connectors.
I believe the servo horn holes fit 2-56 hardware.
8-Dale
Here is a little update on my progress with PICs so far. I switched from a 16F877A to an 18F4550, because it seems easier to handle the 18F stuff and they have internal oscillators. Once I build the program, program it into the PIC, and release the PIC from reset, it starts blinking the LED.
This is the current code:[code]/*
6/24/03
Copyright Spark Fun Electronics 2003
Classic Blinking Test Routine for the 40 Pin PIC16F877A
Flashes all pins
9/12/2007
Modified to work on the 18F4550 by Dale Weber, with much
help from Grasshoppah.
*/
#include <p18f4550.h> // device dependent interrupt definitions
#define ICD_DEBUG //Enable the ICD
#pragma config WDT = OFF, FOSC = INTOSCIO_EC, LVP = OFF
void delay_ms (int x);
void main()
{
OSCCON = 0x70; // 8 Mhz
PORTA = 0;
TRISA = 0; //0 = Output, 1 = Input
PORTB = 0;
TRISB = 0; //0 = Output, 1 = Input
PORTC = 0;
TRISC = 0; //0 = Output, 1 = Input
PORTD = 0;
TRISD = 0; //0 = Output, 1 = Input
PORTE = 0;
TRISE = 0; //0 = Output, 1 = Input
//Turn Port A to Digital Outputs
ADCON1 = 0x07;
while(1)
{
PORTA = 0xFF;
PORTB = 0xFF;
PORTC = 0xFF;
PORTD = 0xFF;
PORTE = 0xFF;
delay_ms(100);
PORTA = 0x00;
PORTB = 0x00;
PORTC = 0x00;
PORTD = 0x00;
PORTE = 0x00;
delay_ms(100);
}
}
//General short delay - this is not a real ms delay (yet)
void delay_ms(int x)
{
int x1, y, z;
for ( x1 = 0 ; x1 < x ; x1++)
for ( y = 0 ; y < 4 ; y++)
for ( z = 0 ; z < 176 ; z++);
}
[/code]
I need to make a trip to my local electronics store (not Radio Shack) and get some parts such as a 20 Mhz crystal and some other parts to make the USB work.
Grasshoppah (robodude666) has been helping me with this and I finally got a blinking LED tonight with a heavily modified version of blink.c from Spark Fun’s PIC tutorials. Their version is written for the 16F877A. My version works on the 18F4550 now (and probably all other 18F PICs). So far, I understand what I have done to make this work.
I can also use my ICD2 with either INTernal power or TARget circuit power. All I have to do is change an option in the programmer settings of MPLAB. There is no hardware jumper to change like some ICD2’s apparently have.
8-Dale
Hi Dale,
Oh, I see. That wouldn’t be bad. 4" square should do that. A 2nd uP would add a little more. I need to get that dsPIC. I’d try out the I2C stuff first. Although the SSC32 takes a RS-232 feed (TTL). I’m wondering if the SSC32 could be made to do I2C instead? If multiple uPs are being used, it makes sense to use the same bus! Of course, there would be more traffic on the bus. SPI would also be a possibility. An RS- 485 chip on the SSC32 to replace the max-232 could work.
I have a 2550 chip on the UBW (Sparkfun) board. THAT could drive an SSC32 as well! But I’m getting to like the 4620 with it’s additional program size. Add some sensor/servo I/O? I’ll see what my Quick Flash board has. I’ve ALREADY driven a servo with it, and read a shaft encoder (one on board!).
What do you have for a foot sensor? That insect doc has some details on a foot sensor, but it’s a little big maybe. I found some nice little feet (no sensor); the 3/8" molded caps that go on the little tubes used for small endmills (machining). The stacking connectors might be a little harder. But there is a little room in the prototype area. Do you have a connector set in mind? Did Peter’s boards have stacking connectors? He’s used up his boards. I need to see what the conflict pins are doing on my board. Maybe I can put a dsPIC4011 on one of my stack boards.
I found the diameter of the 'bot body, 10.75" through the bolt-hole circle of the servos shafts. Huge! I was expecting to be able to machine a custom body on my little Sherline mill rotary table. Now I’m not sure! Much more work if I have to cut it out by hand!
Greets, Alan!
The SSC-32 is a straight serial (TTL or RS-232) controller. However, what Pete did is he got an SSC-32 connected to the dsPIC on his dualPIC board. The 4620 and dSPIC talk using I2C. It should not be too much trouble to do the same sort of thing with a 2620/2680 and a dSPIC4012. I’ve looked at Pete’s code and am starting to understand what it does, how, and why he did it that way now. I have a long way to go before I fully understand it though, and am concentrating on the I2C stuff right now.
I doubt we will see that for the SSC-32, but it might be possible for the upcoming SSC-NG. I think Mike has mentioned the possibility of having the SSC-NG be usable with I2C or maybe SPI. I will have to check that thread again and see.
I have a 4550 on my breadboard in place of the '877A now. I also have 2550’s, 2620’s, and 4620’s.
Grasshoppah showed me this interesting little sensor, which has two channels. These could act as front and back foot sensors.
For now, I am just thinking maybe a double row of .1" spaced pins as a possibility. Unfortunately, I don’t know if there is a way to have stackability for boards and still have the nice 3 pin headers for sensor and/or servo connections, unless the stacking connectors are on the bottom of the main board. This would require the main (MPU) board to always be the top board in a stack.
8-Dale
Congrats on the blinking LED First step to PICtastic fun! I remember my first LED. It was a red 3mm LED =D I have a video on youtube too! ^^;; I couldn’t stop looking at it all day. I had the LED blinking for the entire day Amazing to watch. I must of showed my mom at least a dozen times.
You can go ahead and buy the 20MHz crystal and other goodies needed for USB Bootloading, but before you start the bootloading I suggest you play around with the PIC a bit more. Install the crystal and modify the FOSC configuration to accept the 20MHz crystal. Play around with delays. Hell, even make a normal delay library that isn’t based off of clock cycles and release it because I’m too lazy to do the math required not to mention I don’t really understand the whole FOSC/4 thing.
Congrats once again and welcome to the world of PICs =D They are a load of fun!
Oh, if you need a pressure/force sensor. Check out FlexiForce. Its an A/D sensor which outputs 0 to 4.2v based on a 0-100lb load on it. They are fairly popular and are interesting little buggers.
-robodude666
Thanks, Grasshoppah!
This is pretty much my plan. I want to understand each step along the way. I have a couple things I want to do with the PIC before I get into the bootloading stuff.
I’m not sure how to create such a delay library, but it will be an excellent exercise. I do kind of understand the FOSC/4 thing. so maybe I can help you with this when I understand it better.
I think I have seen these somewhere, but I can’t remember where. It sounds like these could be ‘calibrated’ to the weight of a robot to tell when it has a foot firmly planted on the ground.
8-Dale
Hi Dale,
Good little program! Now your next exercise, should you decide to accept…
Incrementing patterns on the ports is useful for chasing down wiring errors, etc.
Looks like you’re using MicroChip’s compiler. I can tell by the slight differences; such as #pragma configure. That reminds me, my delay() routine is still way off.
Don’t the 16F parts have internal oscillators as well? But then I always want a crystal anyway.
Yeah, Radio Shack won’t get you very far any more. DigiKey is my main source!
The config statements will very between uP chips, so I’m trying to put them in conditionals so that the processor chosen for the compile will select the proper config. And for boards I define one type (comment out the other choices) to get the pins wired up right. Getting universal (mostly) code to set up the timer chain has proven to be a little more difficult.
Sounds like Sparkfun has done their job!
My friend working on the home-built hexapod was over last night, and loaned me his 'bot again. He’ll be interested to know that the clone ICD2 works fine for you.
Now I’ve got my SSC32 back to try my forthcoming legs out. His legs are built differently, so I’m hoping to get a handle on what ways they are different, and how to adjust the code for them. I can see that he’s mounted the horizontal hip (coxa) servo ON the 'bot body, which actually is a good idea. His knee servo horn is on the right, and ankle servo horn is on the left. Which doesn’t agree with the CH3-R.
LM legs are to be built “3 for the left”, and “3 for the right”. It appears that the knee and ankle servos face one way for left side, and the other way for right side.
I think I’ve realized why: As the position of each leg is calculated in al loop by rotating a normal position “around the body”, three are on one side of the circle, and three on the other. So the signs get flipped in the calculation. To match this, the legs are “flipped over” physically. That’s my theory. I’ll have to “flip” the legs in software for his version. And the hip angles of his 'Bot are reversed as well.
Which came first, the hardware or the software?
Alan KM6VV
PS, what are the scientific names for knee and ankle? Or don’t insects have them? All I find is: coxa, trochanter, femur, tibia, and a foot-complex.