Pickit3 ordered -- what else?

Giving up on my efforts to program a 12F675 with my antique EPIC programmer. Just ordered a Pickit3.

So my next question is I may have to also update my PBP as well ? (I have version 2.46a).

And finally --

I may give up on the 12F675 all together -- only bought it because it seems popular and low cost -- I just need it for a very simple LED controller.

Can anyone think (possibly) of another PIC that comes in an 8pin DIP with just a few ports -- hopefully with an internal osc (but an external rc would be ok) that is easily programmed with the EPIC and PBP 2.46a ?

ah ha -- 12c508 maybe ? it's an old one I know.

What is it that you want to do with the 12F675 ?

If the 12F675 does what you want then just stick with it, it's fine. If you're giving up on it due to the issues you're having programming it think again, you'll have the same problem with the next chip.

Why you'd want to use the 12C508 is beyond me, at the very least go with the 12F508 but nah, why? I mean, OK, if you're designing a product and building thousands then buy the cheapest you can find, if you build one then just use what you have or what you want to play with. I just did a little protoboard project with a 12F675.

If you really want to move "up" while sticking to the 8-pin package then perhaps the 12F1840 might be an interesting choice but for that you'll need to upgrade PBP.

/Henrik.

Henrik -- so I'll be fine with the new programmer and version 2.46a of PBP for the 12F675?

I know each version needs different mplab versions. It's been a long time away from PIC's, getting up to speed and "trying" not to have headaches.

Bought a pickit3 which is on the way. I was only considering the 12C508 because my programmer is old and I never had any issues (at all) with those eeprom chips.

Ok -- here's my final question on my 12F675 and EPIC issue -- then I'll just wait for the new programmer.

DEFINE OSCAL_1K 1 (I'm using this based on all the samples at melabs regarding the 12F675 and choosing internal osc in WINPIC)

Tried both MCLR off and MCLR ON.

I know the programmer is fine as I've tested it with other chips -- and it's doing that Vpp before Vdd thing. (Box unchecked in WINPIC).

First error I get is --

"USING DEFAULT OSC CALIB WORD INSTEAD OF 0x003FFF"

Then I get an assortment of errors including something about "Windows playing with LPT1 or something like that"

Another is "003FFF wanted 002828"

Just throwing this out if someone sees something obvious -- if not I'll just give up on using the EPIC. (Wanted to get something done this weekend, hence my attempts).

Michael, I'm afraid I can't help with the EPIC programmer stuff and to be honest I'm not entirely sure what exactly DEFINE OSCAL_1K 1 is doing but I THINK it tells the assembler and/or programming software WHERE the factory calibration for the oscillator is stored (which is the last location in program memory, 1k for the 12F675) so that it can read it before erasing the memory and then write it back to the same location when the device is programmed. Don't quote me on that though.

Now that I think about it, are you absolutely SURE you have the correct device selected in the programming software. I can't understand why it's trying to access (if that IS what it's doing) adress 16384 on a device with only 1024 qords. 3FFF is 16383 which would be wrong for a 1k device. 3FF is 1023 which would be correct. but again I'm out on deep water here so mostly speculating.

/Henrik.

I don't know if this will help. This was the header from some working code I did a long time ago. Note I had DEFINE_1K 1 commented out , so it must not have been needed in my application. Change the configs for your needs

Code:

---

; Initialize your hardware first  '
;-----------------------------------------------------------------------------
; pin definitions  PIC12F675
; Pin 1 Vdd +5vdc                      Pin 8 Vss GND
; Pin 2 GP5  Sample 2                  Pin 7 GP0 AN0    ISP Data
; Pin 3 GP4  Sample 1                  Pin 6 GP1 AN1    ISP CLK
; Pin 4 MCLR tie to Vdd thru 10k        Pin 5 GP2 TX pulse
;-----------------------------------------------------------------------------

'        __CONFIG  _CP_OFF & _CPD_OFF & _BODEN_OFF & _MCLRE_ON & _WDT_OFF & _PWRTE_ON & _INTRC_OSC_NOCLKOUT

DEFINE OSC 8'4
OSCCON = $70
'define OSCCAL_1K 1
DEFINE  ADC_BITS        10            ' Set number of bits in AD result
DEFINE  ADC_CLOCK      3            ' Set AD clock source (3=rc)
DEFINE  ADC_SAMPLEUS    50            ' Set AD sampling time in uS


'CMCON = %00000111
ANSEL = %00010011
TRISIO        =%11000011
GPIO        =%00000000
WPU =%00000000
'OPTION_REG = %
ADCON0= %10000101

---

yes -- do have the right device chosen on winpic and micro code. I'll give some of Mark's stuff a whirl and then give up.

maybe that OSCCON will do it ?
new one on me.

by the way --
chose 12F675 (in winpic) then says --

config word #1 3FFC
config word #2 3FFF

then after a programming attempt in red I get where it says "bandgap"
cal=0x003000 oscillator cal=0x003FFF


THANKS much.

Quote:

---

Originally Posted by Michael

maybe that OSCCON will do it ?
new one on me.

---

Michael,

The code above was for a pic12f683. I must have cut and paste some older code without changing the notes.
After looking at the 675 data sheet it has no osccon register. Sorry for the bad info and hope you get your project
working

Hmm, that's weird.... Looking at the 12F675 datasheet it doesn't appear to HAVE an OSCCON register and trying to compile code with OSCCON=$70 in it fails - not surprising so I don't know what Mark is doing there.

EDIT: Ah, OK, code for another device, that explains it.

The OSCCAL register is used to tweak the internal oscillator up/down a bit in order to get as close to 4MHz as possible. When the chip is manufactured they find out the "best" value for OSCCON (which can differ from chip to chip obviously) and store that value for us at the last location in FLASH memory. So what DEFINE OSCCAL_1k 1 does is to instruct the assembler to generate code for us to retrieve that value from location 1k and put it in the OSCCAL. I don't think it has anything to do with the programmer and any descent device programmer (which I'm sure the EPIC is) WILL retain the calibration value at the last location by Reading it and re-Writing it when it programs the device.

The 12F675 only has one CONFIG word and it's located at adress 2007h and not 3FFCh that the error message seems to indicate. And why it complains about a config word #2 when there's only one in the device I don't know. I really have no idea what's going on there.

/Henrik.

Ok -- you guys really know your stuff -- appreciate all your help. Time to move on and just use the pickit3 when it arrives.

Not sure if this helps, It's an old (and I mean old) bit of code that I wrote for a friend to fade a light like the one on Dr Who's tardis (I can't actually recall if the code fades the LED correctly as I don't have a 12F675 to hand). It could probably be written a lot simpler, but I was learning PBP at the time (still am so most of my code is never tight :) )

If you comment out the config setting in the 12F675.INC file in the PicBasic folder it compiles using MPSAM without error.

Code:

---


@ __CONFIG _INTRC_OSC_NOCLKOUT & _WDT_ON & _PWRTE_ON & _MCLRE_OFF & _BODEN_ON

 __CONFIG
 _INTRC_OSC_NOCLKOUT
 _WDT_ON
 _PWRTE_ON
 _MCLRE_OFF
 _BODEN_ON

TRISIO.0 = 0  'Set GPIO.0 to output.
ANSEL.0 = 0    'Set GPIO.0 to digital               
VRCON = 0        ' Voltage reference disabled
OPTION_REG.7 =    0


led var GPIO.0
i var byte
getout var bit

main:
for i = 1 to 254                                             
    Pwm GPIO.0,i,1
    pause 5
    if i=253 then
        i=1
        GetOut=1
        endif
  next i

if Getout=1 then goto down

down:
for i = 254 to 1 step -1                                             
  Pwm GPIO.0,i,1
    pause 5
    if i=2 then
        i=1
      GetOut=0
        endif
  next i

if Getout=0 then goto main

---

Might be worth giving it a go one last time with your old programmer. It's been years (circ 2001) since I used WinPIC and an old JDM programmer, but I do recall it was very hit and miss at programming. I seem to remember some other version like WinPIC-PRO or something as being an alternative which I think worked better. Might be worth a quick google if you still want to try and resolve this.