I found a suitable wallwart (9VDC@500mAH) and have it connected to the ICD. I also have the ICSP socket wired up to a 16F877A. I decided to use this for my first try at programming since I know there is a lot of code for it, including several boot loaders. This is also the PIC the ooPIC II+ uses.
Yes, you can read from and write to the 23017 chips via I2C. There is also an MCP23S17 that is the same except it uses SPI instead of I2C.
Now, I think all I have to do is get power to my solderless breadboard for the rest of whatever I want to connect. I’m a little confused as to what power needs to go to the PIC though. I would obviously need stand alone power when not programming or debugging using the ICD2. When I am programming, does power only come from the ICD2, hence the need for a stand alone power pack?
That’s a good plan! The ooPIC uses and '877A? I thought it was 4620 family. But I think the pinout is very close.
That sounds like an interesting part. Although the '595 and '597 chips work fine for me. Might save a gate, 'tho if they have a CS.
Just wire up the PIC like you were going to run it by it’s self; and make the VCC, VSS, etc connections with the ICSP. You should be fine. Check out a PICDEM board if you’re still in doubt.
Yes, the ooPIC II+ is based on the 16F877A. The pinout is the same as the 18F4620, 4680, and I believe 4685. I have verified this is the case for the 4620 and 4680, which is the big reason I started looking at the OOBOT boards.
I have not used the SPI flavor, but the 23017 (I2C) has 3 address lines so up to 8 of them can be used on a single I2C bus. The MCP23S17 does have CS and hardware address lines.
That’s what I thought, and what I did. MPLAB still doesn’t see the 16F877A though. I have MPLAB set for power from the ICD2. This may be where I have the problem.
Then I should be able to use these chips on the QuickFlash board (18F452) as well. The 4550 will be close, but I think tx/rx get moved (USB).
I got the LCD working, and the SPI maps OK. Same pins. Whew! Not that it matters, but it is more convenient. I dug up an 18F4620, so I’ll shift over to that chip to double my memory (64K). More memory map work to do (HAL). Next I want to get the Real Time interrupt going, and get SPI called off of it.
This weekend I should have more SES leg parts!
I read the data sheet, looks promising. I think we get by cheaper with discrete ICs, 'tho (commercial products, count pennies).
This is indeed what I have wired up, but MPLAB is still complaining that it can’t verifiy my chip is what it is expecting. Now I am wondering if my ICSP connector is going far enough into the breadboard to make contact with the circuit.
Everything I have looks fine as far as I can tell. I wired up the ICSP connector according to the datasheet for the 16F877A, and even included the PGC ping which most say is not needed now. The wiring is not complex (just the ICSP connector to the 16F877A), so I don’t know where my problem is.
Did you buzz the connections out? Also make sure the '877A has power as well. What’s on your RESET line? That could kill it. '877A is different then plain '877, but you probably knew that!
I’ve never used the older '877, so the '877A is brand new to me. There is an option in MPLAB for power, and I have that set to be powered from the ICD2 since that is the only power I currently have connected to the '877A.
Unfortunately, I don’t even have a logic probe or multimeter here - and know I need to get one or both. I have that on my must get list now, and it looks like this may have to come before getting my OOBOT board. I am starting to work with stuff now that definitely requires some decent test equipment.
I need to find out if power is even getting to the '877A and if not, how far it is getting. My ICSP connector could be the problem, but I don’t know if that is the case right now.
I think I will try the brute force approach and run some jumper wires direct from the ICD2’s ICSP connector to my circuit. That would at least show whether the board’s ICSP connector is my problem (if everything works then).
Mike, go read the whole thread, silly… ") We have taken a few detours along the way.
I’d set it up for “powered from the DUT”, and give your board a filtered 5V supply (caps!). Do you already have another PIC that does something? Try to power it up.
I’m never far from a 'scope, or a good DMM at the least. In a pinch, an LED and a 220 ohm resistor can tell you things. Properly set up, a PC and a parallel port can be useful as well.
The LED should be able to tell you if there’s power. And also if you have a ground. Look for the level on the RESET pin as well.
Sometimes the pins push up, rather then into the board/socket. You can often make them longer by pushing them further into the insulation. Use another pin to gage their depth.
Hi MIke, What’s this? Do we have a new participant? We’re currently on the PIC on this thread, and mentions of the ooPIC.
I’ll have to see if I can get 5V to my breadboard. I might be able to tap it off one of the bot board servo/sensor connectors, which should be enough running from a 2800mAH battery.
I’ve used the LED method as a logic probe before, and usually have one wired up to most of my circuits. It’s time to wire one up for this one now.
I will check everything out. I know the problem has to be something simple. There just isn’t that much that can go wrong here, aside from not getting good power and ground, a bad PIC, ICSP connector not making good contact, etc.
It shouldn’t take much. You can add a 5v reg to the prototype board, and then just use a wall-wart. Be sure to add filtering.
They are quite often useful. And connected up to a uP, they can serve as flags to mark when one gets into a particular routine or state. I used the built-in LEDs on my board just last night to tell me if and when I got into some initialization code and then later an interrupt routine. Sometimes it’s easier then using a 'scope! I’ve now got a “heart beat” LED flashing from a counted-down loop (1 PPS) driven by this periodic interrupt 100 mS).
I already have RS-232 interrupts; and intend to drive SPI for PS2 off of this low priority interrupt, as well as flag time slices for multi-tasking.
There are some PC-based logic analyzers available also. I haven’t used them for ages, but you might want to check it out. You can’t beat a good 'scope. Well, a logic analyzer might be a contender!
Yeah, they usually are! The more tools, the better to see with!
I used several LEDs when I was wiring up my LED sequencing circuits to tell when I hit certain code points and such. Yes, they are very useful when used this way.
I would love to have one of these but am affraid they are outside my budget. I would have to save up to get one. I’ve had formal electronics training, so I know how to use all the different test equipmrnt, including 'scopes. I wish I could afford to equip even a low cost but decent test bench.
Today is debugging day! I should be able to figure out what is wrong with my PIC programming circuit and start fiddling with PICs a bit.
I did as you suggested and got 5V power to my circuit from an external source (tapped off a servo connector on the bot board of WALTER). So far, I still can’t get MPLAB to recognize the 16F877A chip. I also connected an LED to check polarities and such.
My circuit has power where it should have it, but I still can’t get the ICD2 to see the PIC. It is starting to look like something is wrong with my ICD2, because MPLAB refuses to let me deslect the power from ICD2 option so I can get power from my circuit. I can’t get any signal from the ICSP connector on the ICD2 at all. The green LED on my ICD2 has not gone off and no red or yellow LED on at any time except briefly at power on. It seems like something should be working, but it isn’t.
Does this mean I have a bad ICD2?
This is what I am getting from MPLAB now:
Connecting to MPLAB ICD 2
ICD0019: Communications: Failed to open port: (Windows::GetLastError() = 0x2, 'The system cannot find the file specified.
')
ICD0021: Unable to connect with MPLAB ICD 2
MPLAB ICD 2 Ready
8-Dale
Sorry to jump in the middle. I haven’t read the entire thread so excuse me if my questions were previously answered.
What pins on the 16F877A chip do you have connected to what? I remember I had a problem with my 18F chip where I didn’t have a pin on 5v or something which kept it from working.
Here are a few tutorials from SparkFun about MPLAB related things:
Its a bootloader designed for the:
16F87x
16F87xA
16F88
16F819
You should checkout the tutorial section in general if you haven’t yet! There are a bunch of great articles for people new to the PIC world. They REALLY helped me out in the beginning!
the MCLR is the programming pin if I remember correctly. Check the 16f87xa datasheet for more info on it. Or wait for a reply from someone with more PIC knowledge
I don’t recognize the “file missing” error. You might re-install MPLAB. Do you have a current MPLAB? We’re up to 7.6x or something, any 7 should be a good bet, unless instructed otherwise by SparkFun. Did you set up MPLAB for USB (under program / options or something like that)?
You either need to import or compile and link (I assume you have) in MPLAB. Look at the “program memory” for real code. (Although the MPLAB should/can even try to program anyway if programmer is OK.
You can tell it to “connect” again.
I wouldn’t doubt that there is a Forum on SparkFun for the ICD2 clone.
Maybe your clone only wants to work in “ICD2 powered” mode by design?
I don’t pay much attention to the LEDs on the ICD2, but if MPLAB is not up yet, and when you first power the PC on, you should see yellow and/or red.
It’ll want to find (in my case) power on the DUT before it will attempt to program.
I get a yellow (busy) while it’s programming (or downloading, as I recall).
Do you think possibly that it wants to download when you get these errors (before you try to program?). Then the missing file could be the “operating system” it wants to download.
Could the ICSP clock and data lines be reversed?
Alan KM6VV
P.S. You might want to post the schematic of what you have so far.
I updated to MPLAB 7.62 before I started this project. The ICD2 is setup for USB - I guess MPLAB detected it automatically.
I have done that and now I am getting slightly different results:
Connecting to MPLAB ICD 2
...Connected
Setting Vdd source to MPLAB ICD 2
ICDWarn0020: Invalid target device id (expected=0x71, read=0x0)
...Reading ICD Product ID
Running ICD Self Test
...Passed
MPLAB ICD 2 Ready
This is with MPLAB set to power from the ICD2. I believe I know where the problem is now - it’s the ICSP connector on the breadboard. I don’t think this connector is going far enough into the board to make proper contact with my circuit. I will try your suggestion of pushing the pins of the connector down so they go further into the board.
There is and I am registered as a user.
This is a possibility, and I will check into this further.
What does DUT mean? I am not familar with this abbreviation.
I also get the yellow LED when MPLAB is downloading a new OS and programming it into the ICD2.
If I change the PIC type, MPLAB will download a new OS for the ICD2.
I will make up a schematic and post it. At this point, I no longer suspect a problem with the ICD2. I am pretty sure it’s the ICSP connector on the breadboard causing the problem now.
No, Grasshoppah, I did not miss it, and am going to check everything out.
In fact, I have already read some of that, even before I started working on this ICD2 stuff. One of the reasons I decided to start out with the 16F877A, is there is a version of bloader and such for it.
The pinout is the same as the 18F4620, 4680, and I believe 4685. I have verified this is the case for the 4620 and 4680, which is the big reason I started looking at the OOBOT boards.
