Help with circuit(programming pics)

I'm not using the serial port but the parallel port.

No I haven't but like I said, it works fine for driving LED's. The whole reason of using all the mosfets is to get the voltages up to the proper voltage. The voltages comming out of my parallel port are about 4V. This is why I use an external power supply with 5V and 13V(or whatever as I can vary it. Actually it needs to be about 10-12V for the pic.

Again, I'm using the parallel port instead of the serial port. (not sure if I mentioned that) and all the voltages on the pin's of the pic are correct and within spec. (again, that is the whole point of using the circuit instead of just connecting the parallel port pins straight up to the pic(specially since some pics require ~ 2.5V or 3.3V))

Jon

You may want to check the condition of your serial port.

If you're using a USB-232 converter, that could be your first problem.

they don't work very well. Also, Voltage levels in many cases are not high enough to drive these circuits properly. Originally, most RS-232 ports gave you a nice level output, in the range of 8 volts and up. now days, they keep dropping the voltages because these new engineers keep insisting there was never a standard for voltage levels which is bull crap. It's more marketing to make cheaper products that operate on the edge to save a few cents.

have you tried a different computer and port?

--
"I\'m never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

On a sunny day (Sun, 28 Oct 2007 14:08:58 -0600) it happened "Jon Slaughter" wrote in :

Some suggestions: On the par port always use separate routines to set or read a bit, never set 2 bits at the same time. Always use read-modify-write, or at least a variable that holds the current port states. Make sure no other driver accesses the par port (printer?).

Make sure you got the memory areas correct for each pic. Make sure you mask correctly for word width, for example 0x3fff. Before programming it send command erase ID and configuration (fuses). Always run a verify if not read protected.

Has been a while since I wrote pic prog stuff, but this is sort of important.

Also make sure you do not send data too fast... Modern computers are very fast, and you will need delay loops.

I cannot seem to access a.b.s.e right now, this server does not have it, and I dunno where my list of the old servers is (on some disk).

I used software that I know works at least for some pics and it is a very popular programmer. It does everythign you say so thats not the problem(assuming I trust it... I do not know what it is actually doing but like I said, its popular and I know it worked on one pic I did a long time ago).

It would be nice to rule out the software though... if anyone has a logic analyzer they could check it out for me ;) Almost all the pics are programmed in a similar fashion but I doubt the software has it wrong... on the other hand I can't see what is wrong with my circuit... but chances are thats there the problem is. (and like I said, it's most likely with the reading of the pic)

I've tried programming it at different speeds and everything I could think of but nothing. I have no idea where the problem is which really sucks. A logic analyzer would come in handy in seeing if its a problem with the circuit but I don't have one. As far as I know the pic's could be dead(highly unlikely) and there would be no way for me to know ;/

If your interested in helping you might try taking a look at winpic,

Again, I seriously doubt there are any problems with the software and I know the circuit is working for the most part but I cannot figure out whats wrong ;/

"Jon Slaughter" schreef in bericht news:I%5Vi.2465$% snipped-for-privacy@nlpi068.nbdc.sbc.com...

Hmm... Microchip does not know the PIC16F817 so I expect it to be a typo. PIC16F871 maybe? Have a look at:

Harware design and software for programming several types of PICs, including PIC16F871 and PIC 18F2550.

As for your own experiments I guess it to be timing problems. Not only in pulse length but also in rise and fall-times of the edges. Too fast maybe as bad as too slow. Very hard to find out without a logic analyser or at least a multichannel o'scope.

petrus bitbyter

probably not... using WinPic and it has worked

linked too.

lines(suppose to be open collectors but they

programming the pic in high voltage mode. That

on Q3 which turns off Q which turns off PIC

I invert the line in the software so its

are non-inverting.

the pic drives Pic Data high, Data Read goes

attached a to Data Read and it supplies some

here to stop that?

trying to program the pic. (I don't use

invert the lines appropriately and test it

VPP and the voltage is what it should be. Each

send a low voltage in the software and a high

why it won't program. I've tried slowing

analyzer so I used LED's and as far as

PIC24 I actually used a different circuit since

also did not work(I think my circuit had a

VPP translating to 13V. I suppose I could have

don't have any P-Ch Mosfets and an N-channel

The software automatically holds Data high

can see that it reads the data when I manually

driver and a bjt. I was able to program the

programming spec so it should have worked AFAIK.

the 18F2450 or the hex driver to test it

I used to use the FPP and a homemade PIC Programmer Pro. But gave up cause I needed ICD capabilities. I use Mchips ICD2 now. You should look into it, only ~$200. Edge transitions on the port can cause problems, but I don't deal with the issue anymore.

Cheers

Oops. Its the 917.

Well, I kinda want to know why my circuit won't work.

Why would being to slow be a problem? The PIC's can accept about a 5Mhz signal so I seriously doubt I'm going to fast. The parallel port is only running about 50khz max. I figure slowing it down would only help rather than hurt.

The pic programmer from that site is very similar to what I used a long time ago except I didn't use any regulators because I had a bench supply.

I've recently posted schematics for a PICkit 2 compatible kit with

18F1320 Tutor I sell called Junebug, also the ICD2 Inchworm schematics and instructions can be found on my site at Most JDM and parallel port type programmers don't work with fast machines or modern operating systems like XP or Vista. The Junebug is the way to go IMHO, it's USB based, fast and is supported under MPLAB 7.62 (which supports both programming and debugging most 16F & 18F PICs) It works, is easy to build and very reliable.

I know it can be fun, but seriously, don't bother making your own programmer, it's not worth the grief. Spend $100 and buy a real one that is already fully debugged and guaranteed to work.

The last thing you want when programming micros is to be left wondering whether it's your programmer at fault or your own code.

BTW, the parallel port is a notoriously finicky beast to use. You might get it working on your machine only to have it fail on another machine.

Dave.

Jesus christ!! Can anyone actually look at the circuit instead of saying its a waste of time? I know its better to buy one but I want to know if the circuit itself is bad or not.

Also, almost all programmers do not support the newer PIC24's so its a waste since thats what I want to use. I'd rather be able to program a PIC myself since it shouldn't be that hard(since I have the software to do it).

I'm much more interested in what might be wrong with my circuit than actually programming a pic at this point in time. If that wasn't the case I would have already brought a programmer such as the pickit2.

I also know that most programmers use a pic as a proxy to program instead of the parallel port. Again, at this point in time I'm not interested in the various methods of programming pics and what is better or not but only in why my method isn't working(because it's more about learning than about doing).

On a sunny day (Mon, 29 Oct 2007 14:35:52 GMT) it happened "Jon Slaughter" wrote in :

If you could post it to a normal site, and not to the hardly availabe binary groups. But if your LEDs go on and off as they should, why should it be wrong? Decoupling? Do you have a scope?

Well, I thought that binaries was pretty much available to everyone...

The pic is the 917 and not the 817. Not that it really matters much.

I have a scope but unfortunately it uses the parallel port(its one of those crappy velleman pc scopes... a big mistake to buy but thats all I have).

What do you mean by decoupling? What is there to decouple?

I imagine the circuit works except that there is an issue with reading from the pic. (even though it works manually when I short the PIC data pin(actually there is a resistor in there from the PIC data side so that gounding the pic data pin doesn't cause a short on the power supply)

I'll play around with it some more and see what I can come up with but hopefully someone will spot the flaw so I don't waste to much more time on it. (I want to know what is wrong with it because as far as I can tell it should work which means either I don't understand something critical or I'm just missing something simple(in either case I want to know)).

Thanks, Jon

On a sunny day (Mon, 29 Oct 2007 16:59:43 GMT) it happened "Jon Slaughter" wrote in :

I checked on an other server news.isu.edu.tw and it had the binaries but only upto 8 october.... Lost of newsservers no longer carry binaries to reduce bandwith. Web-2 is taking obver lots of tha tpicture stuff, videos...

Got it. Some remarks, your 100k source resistors are way to high for a fast pull down. (PIC-data and PIC-clock). I do not understand you pre-occupation with MOSFETS :-) What MOSFET? Are you sure that the clock and data output levels are the same as the PIC supply? Same for PIC Vpp, and I *think* I had a decoupling cap from Vdd to ground, also requiring lower pull-down (say source) resistors in your case to get good fall times.

Oops. Next a scope project perhaps. Get an old analog one for little money.

10 MHz should be enough for things like this.

OK lemme see my own programmer... Yes, 100nF from Vdd to ground,. !MCLR is pulled down by a NPN and has 2k2 to the prog voltage.

Your signals will now go low like this: --- | \\ _| \\_

[A

On a sunny day (Mon, 29 Oct 2007 17:22:43 GMT) it happened Jan Panteltje wrote in :

PS where is the Vdd switch????

On a sunny day (Mon, 29 Oct 2007 17:22:43 GMT) it happened Jan Panteltje wrote in :

OK, my error, top left. May I suggest you replace all the drain 1k resistors by wires, and replace the source 100k and 1M reistors by say 4k7. If those 1k drain resistros are some short circuit protection, then why not put 75 Ohms in the drain of Q2 for example?

I assume you mean R8, R11, and R18? I don't see how they can affect the speed. Are you saying that basically the resistors act with internal capacitance(in the pic part) so that it forms an RC circuit?

I used that high because I wanted to limit the current when the pic was on. I guess that might be a bad idea? What kinda values should I be using? 1k?

I used mosfets because they seem like a much better choice than BJT's? What else could I use? (I'm looking at a discrete solution here because I want to have more control and it needs to be robust because there is a wide difference in voltage levels between different pic families).

(the mosfets I'm using are 2N7000)

Well, I was hoping once I get the pic programmer done I could build me a scope. The velleman scope is a POS. I figured that because its pc based I could have keep a history of the signal and hence use it sorta like a logic analyzer but the software does not keep the data in a history buffer. You can only scoll back a little ways(dependent on the sampling rate). Shit, I have 1GB of memory and surely it could keep several seconds of the signal and let me scroll.

It also claims to be 50mhz but I somehow doubt that. I kinda stopped looking for analog scopes because most are over priced and those few that show up on ebay that look like good deals are probably not.

I think it might be fun to try and make my own scope though but I need to get this pic stuff out the way. (well, I have some other projects I need to do before that)

(I sorta want a scope that will do at least 100mhz and 2-4 channels)

? I added 4uF bypass cap on the power pins of the chip.

[A?

So maybe the circuit is not the issuing but the timing? I figured that since I'm using mosfets and the pic uses schmitt trigers that it shouldn't matter all that much? Specially since I'm not sending data very fast. (its rated for max 5mhz and I'm sending about 1/100th of that(actually, its probably more like 1/1000). I'm not really trying to maximum speed here.

Once I'm able to program a pic(well, any pic) with the parallel port I'll either buy me a pic programmer or use another pic to program it and use USB for the pc interface. I just need to understand why my circuit isn't working for the reasons I gave before.

Thanks, Jon

On a sunny day (Mon, 29 Oct 2007 17:48:37 GMT) it happened "Jon Slaughter" wrote in :

R8, R11, R18, AND R6.

Yep. There is charge,m and to get the voltage down it needs to be removed. If it goes down slow, then the next pulse may have started before the voltage is below logic zero threshold, also there are rise and fall times specified by Microchip, although I would have dto look, but it is in any PIC dataheet.

Well, BJT works just as fine, have only a few hundred milivolt drop when on.

Yes that should work with a 2.1 V treshold.

There was a recent discussion here about scopes, maybe you have read it...

So with 4uF on the chip, and 100k to ground (R8) rc = 4 10^-6 x 10^5 = .4 seconds. But I hope you switch Vdd, and if so, the soft will have to wait until the 4uF is charged Via Q2? before it does anything, well tha tis just an extra power spike, decoupling with 100nF works just fine. And the 4uF is tantalum? else a 100nF poly cheaper.

Look up rise and fall time specs for your PIC For going low, 100k in say 50 pF = 5x10^-11 x 10^5 = 5x10^-6 is already 5uS. I would think nanoseconds are specified.

Yeah, they are just there for limiting. I don't know what I used in the circuit when I actually built it or if I used them at all.

If I remember correctly the mosfets have capacitance which do effect the speed so those resistors are not necessarily good at high speed(I think this is what your getting at). But If thats the case I can't see why it really matters when using such a low communication speed in the first place. Sure I might lengthen the rise and fall times but it shouldn't matter at such a low speed?

That might be the problem. The datasheet doesn't have any max rise and fall times but only min delays. This is why I figured that it shouldn't matter because the delays only basically determine the max transfer speed... and I'm well below that. It could be causing the problems though. I was trying to limit the power used to program as its already 20mA. (the pic is suppose to draw about 10mA max)

I also have to worry about limiting the current to the parallel port as I don't want to burn it up but I guess this doesn't have anything to do with the pull downs after the mosfets(R8, R11, etc...).

Since I have to use a high voltage anyways the mosfets work well and get me within about 5mV within the lower power supply so its not big deal and probably work better than BJT's in this case?

I have about 7V to work with so thats why I chose them.

I'm not sure how long the software waits. That could be a problem too. The specs for the Pic24 recommend 10uF on the power pins and I just had 4uF tantalums so thats what I used.

In the programming spec it doesn't mention any except for MCLR it has max

1.0us. All others are minimum times or just delays.

Your probably right though in that those resistors are slowing down everything to much. I didn't take that into account when I was making it and just used pull downs that were large enough to reduce the current. I probably over did it.

Hopefully thats all thats wrong with it though. Does the idea look right to you though? I mean, its pretty simple so it should work in "theory"?