my first 16F88 has me stumped

Status
Not open for further replies.
H

Hank Fletcher

New Member
I'm trying to figure what's wrong with my first attempt to program a PIC. It's probably something simple, but with this being my first time I think I'm getting overwhelmed by the factors!

Anyway, I'm trying to program a 16F88 to flash two LEDs at intervals of 1s. The program is derived from a demo program included with Great Cow BASIC. Here's the program in GCB:


This compiles without any problems and produces the following assembly code:
Everything seems to work fine when I try to program the 16F88:
So I'm wondering:
- I have to hit "release from reset" then I can remove the PIC from the programmer, right?
- I'm not programming the PIC in circuit, just in the ZIF, so should the ICD2 be set to power the target (I'm wondering because the ICD2 I'm using is just getting its power from the USB)?
- Is there perhaps a problem with the circuit I'm using the 16F88 in?

Sorry, but I haven't gotten around to schematic software yet. But it's a simple circuit:
- two LEDs to ground and pins 6 and 7 (RB0 and RB1) of the PIC, 470Ohm resistors between each LED and its PIC pin. Testing reveals the LEDs work fine between ground and the PIC pins (no problems there)
- ground to pin 5 (Vss) of the PIC, 5V to pin 14 (Vdd).

Thanks! Again, I'm sure it's something simple but I can't get my head around it!
 
Last edited:
My laptop is lousy at powering any sort of circuit thru a programmer. Will work on Pic demo boards tho, where the USB provides V+ and the Vpp is seperated off from that.
 
I might not have made that clear. I'm just programming the PIC (out of circuit), and I was wondering what the settings for that ought to be. Confusing the issue is that my ICD2 doesn't have an input for power other than the USB. So the part that's puzzling me is that there's no circuit that needs to be powered, just the PIC in the ZIF, so does that need 5V from the ICD2 or should the ICD2 be set for the PIC to be self-powered?

As curious and relevant that might be, I'm not 100% that it's my only problem.
 
If you are programming your pic with your ICD2 and then transferring it to your circuit then it should work fine.

I'm assuming you either,
Compile your basic code in MPLAB,
or, you assembly the asm file in MPLAB,
or, you import the HEX file into MPLAB.

If you view the disassembly listing (in MPLAB) before programming it should be similar to the asm file.

Mike.
 
You should also check that under menu "Configure->configuration bits" that the box at the top is checked - configuration bits set in code.

Mike.
 
Don't think its a MPLAB thing. Great Cow Basic compiles the basic into a downloadable hex file for the programmer. If the program compiles, an assembly file is also produced for debugging. The chip looks to be programmed and ready to go, but personaly have not used the ICD2.

Maybe the "in circuit" 16f88 wiring needs to be checked over for continuity & voltage. Is the 16f88 in a breadboard? Tried a different location? How is it powered? Is the power decoupled?
 
Nickleflippr, the ICD2 only works with MPLAB. If you don't either compile, assemble or import then the code just isn't there and it will program a blank chip.

Mike.
 
Pommie, sorry if my wires are crossed there, like I said , have not used the
ICD2. When using a Microchip PicKit 2 programmer, it happily imports and downloads the compiled hex file from GCBasic, without the assistance of MPLAB.
 
Hank,

You are not programming your code into the PIC. The following is from an PIC16F88 with the ICD2 as a programmer. I added the bold to the interesting lines.
With the ICD2 set to debugger you should see.
Your output follows.


All you have done is program the configuration bits.

My guess is that you are compiling the Great Cow code with the Great Cow IDE then attempting to program it with MPLAB. If so inside MPLAB you have to import the hex file first. FILE>IMPORT. You need to import the HEX file each time you start the ICD2 IDE.

Also I do not see where the ICD2 in erasing the part. Maybe because you did not have anything to program it figures it does not need to. After you have inported you hex I would expect to see that too.

Does Great Cow have instructions on using their compiler with MPLAB so that you can compile program and debug from within the MPLAB IDE? That would be the way to go.



HTH
 
Thanks for the help so far, guys. I hadn't realized I would need to import the .hex file. I've tried that, but now I get this:
ICDWarn0033: MPLAB ICD 2 does not support programming this device if both the internal oscillator and internal MCLR are selected. You may continue programming, but you are encouraged to cancel, reconfigure your device, and try again.
Click to expand...
I gather that's just an unforeseen complication on my part, in terms of that I can't use the internal oscillator and internal MCLR at the same time on a 16F88? If I set MCLR to on, I think I need a pull-up resistor on the MCLR pin - what value should the resistor be?

FYI the power for my circuit is 5V regulated (and plenty amps). Yes, it's in a breadboard.
 
I just tried that out, setting MCLR on, and it programmed just fine (although for some reason I had to quit out of MPLAB and reload to get it to work?). I put the MCLR pin through a 10K resistor to the 5V in my circuit, and the LEDs are blinking perfectly! I guess the only downside to this is that I'm now one I/O pin shorter than I thought I'd be. There's an argument there for people claiming you can gain two output pins by using an internal oscillator, if by using the int osc you have to give up the internal MCLR (on the 16F88, anyway).

Like I said, the circuit's working fine, but I'm curious - what's the best way to deal with stray capacitance with a PIC on a breadboard circuit (besides keeping wires or leads as short as possible)?
 
Last edited:
If you are that close on pin count use a 28 pin PIC.
 
If you are that close on pin count use a 28 pin PIC.
Click to expand...
I'll keep playing with the 16F88 for now and try to apply it to my project (the recorder robot) - I think it will be good enough for the first attempt (for which I'm seriously considering limiting the number of "fingers," and accordingly the need for as much I/O pins).

But I really think I ought to keep a lookout for a larger pin-count PIC. I know I've seen some popular 28 and 40 pin PICs recommended on this forum, but I can't remember what or where. What can you suggest?
 
the 16F767 (28 pin) is a fun chip for playing with leds and rgb color mixing. It has three hardware PWM modules, so you can do 30 bit color mixing in hardware, without wasting any cpu cycles or much code space.
 
Since you probably need drivers for outputs anyway (relays, etc.), you might consider using one or more cascadable 8 bit serial-to-parallel sinking driver ICs with a 3 pin interface (Micrel MIC5821/MIC5841 or Allegro A6821/A6841). The MIC5841 and A6841 devices even have built in suppression diodes on the outputs for when you're driving relays.
 
justDIY said:
the 16F767 (28 pin) is a fun chip for playing with leds and rgb color mixing. It has three hardware PWM modules, so you can do 30 bit color mixing in hardware, without wasting any cpu cycles or much code space.
Click to expand...

I didn't know that. Wow, I see it in the Data Sheet. I think I need to add one of those series to my next sample order.

Thank you Sir!
 
Status
Not open for further replies.

Similar threads

J
  • Question
Why External Steering Request (XSR) J1939 message has checksum message within the 8-byte Data Field?
Replies
1
Views
3K
Diver300
D
P
Checking my logic.
Replies
12
Views
4K
Pommie
P
K
STM32H750 - Timer preload has no effect - Interrupt
Replies
4
Views
2K
aliarifat794
A
T
  • Solved
Can u help me with this counter!!! (PIC18F46K22)
Replies
8
Views
1K
Ian Rogers
  • Question
PIC-AS DB Assembler Directive Only Building First Two Bytes Of String
Replies
3
Views
3K
Ian Rogers
Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…