A discussion group for the PICMicro microcontroller. Also called the Microchip PIC, this list is dedicated to the use and abuse of this fine, simple, microcontroller. Close to topic posts are welcome, ie. general electronics.
|
What is the difference between a serial port based PIC programmer and a parallel one? |
|
|
|
> What is the difference between a serial port based PIC programmer and > a parallel one? They use different ports :) To say more you should ask the difference between specific programmers, especially serial port programmer vary from DIY almost-no-components to professional ones with professional prices. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products |
|
Hello, Has anyone experience with the design of a hardware pic-programmer (pic16f877) and the design of compatible programming software (in Visual Basic for example))? Or some information about how to do it, something more practical than Microchips's information? :-) Thanks in advance, Matti Laevaert, student in electronics, Belgium |
|
|
|
> Has anyone experience with the design of a hardware pic-programmer > (pic16f877) and the design of compatible programming software (in > Visual Basic for example))? Or some information about how to do it, > something more practical than Microchips's information? :-) Yep. http://www.voti.nl/wisp http://www.voti.nl/wisptool http://www.voti.nl/wisp628 http://www.voti.nl/xwisp Everything is available to study. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products |
|
|
|
--- In , "Wouter van Ooijen" <wouter@v...> wrote: > > visit www.picallw.com Has anyone experience with the design of a hardware pic-programmer > > (pic16f877) and the design of compatible programming software (in > > Visual Basic for example))? Or some information about how to do it, > > something more practical than Microchips's information? :-) > > Yep. > > http://www.voti.nl/wisp > http://www.voti.nl/wisptool > http://www.voti.nl/wisp628 > http://www.voti.nl/xwisp > > Everything is available to study. > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: www.voti.nl > consultancy, development, PICmicro products |
|
Hello, I'm working on PIC programmer and I need advice. After spending one day on Internet checking all of the existing solutions both hardware and software, and one additional day to read all of those ICSP Manuals from Microchip, and another day to evaluate signals from ICProg using digital o'scope, I decided to use Tait classic programmer with ICProg. I have a problem with SPI connection and you can see details if you download PICLISTProg1/2.pdf files that I just uploaded to this group. Link: http://groups.yahoo.com/group/piclist/files/ Question is: should I go with schematic 1 or 2? Any other suggestions? Sch2 looks more straight forward since jumper is used but Sch1 could work as far as I know... am I right about Sch1? I want to avoid that jumper, obviously :) What I'm trying to do is to build simple, reliable and low cost (but not 'El Cheapo') programmer that can deal with PIC ICSP in both normal (+13V) and LVP (+5V) mode, I2C serial EEPROMs and SPI serial EEPROMs (or any other serial device that can be connected to this programmer). Regards, Igor |
|
OK, folks I think I saw enough opinions about PIC programmer. I think you own more experience than me, so I belive you. Until I will be able to get a decent osciloscope and analize the signal I will use JDM to put the software into PICs. I'm not able to imagine why is so hard to shape some serial signals, but I will get this in future. I'm a little bit dissapointed because the thread was moved in another direction ( see USB versus RS232, PC future, and other things ), but I was curious about what kind of signals you must provide to the PIC's pins to respect the Microchip specifications. Maybe I will make you angry, but I really don't see why so much trouble with reflections and signals shape constructions. As a matter of fact, the comunication speed is not so high. If one can post about this I will be very happy, because Microchip doesn't talk much about those problems. thanks for your posts |
|
|
|
> I really don't see why so much trouble with reflections and signals > shape constructions. As a matter of fact, the comunication speed is > not so high. Reflection, crosstalk etc. has nothing to do with communication speed, only with signal rise time. You can get lots of bouncing when you send a fast-rising 1 Hz square wave over a 1m cable to a high-impedance receiver. One of the toughest problems I evert hunted down (note: I am a computer programmer, not a hardware guy!) was a bundel of some 32 address + 16 data wires running maybe 10 cm from a bus to a bunch of buffer chips (it was a kind of bus riser). The bus was of course driven with a low impedance (and the bus itself was properly terminated at the ends!), but the receivers were high-impedance. When a certain combination of address and data was presented on the lines the (edge-triggered) receiver would consequently read a different value (this happened only on a few address+data combinations!). A high-speed local analyser showed the problem nicely. It disappeared totally when even a modest (10k) load was placed on the lines near the receiver. > If one can post about this I will be very happy, because > Microchip doesn't talk much about those problems. Because it is not a PIC issue, it is general electronics. Like they don't explain Ohm's law. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products |
|
|
|
This thread has taken some turns as you mentioned and some of us are interested in getting a better programmer. Can you help us a little and search for programmers and add them to the database on the piclist pages ? Since you will be one of the people who get the most from this project, is it fair to ask you to help us in some small way. One of the software packages available for many different programmers is www.ic-prog.com and they also offer links to different schematics for some popular units. Dave --- In , "ydexter" <ydexter@y...> wrote: > OK, folks > > I think I saw enough opinions about PIC programmer. I think you own > more experience than me, so I belive you. Until I will be able to get > a decent osciloscope and analize the signal I will use JDM to put the > software into PICs. I'm not able to imagine why is so hard to shape > some serial signals, but I will get this in future. I'm a little bit > dissapointed because the thread was moved in another direction ( see > USB versus RS232, PC future, and other things ), but I was curious > about what kind of signals you must provide to the PIC's pins to > respect the Microchip specifications. Maybe I will make you angry, but > I really don't see why so much trouble with reflections and signals > shape constructions. As a matter of fact, the comunication speed is > not so high. If one can post about this I will be very happy, because > Microchip doesn't talk much about those problems. > > thanks for your posts |
|
|
|
Microchip have a data sheet for programming their serially programmed PICs. This is most of the range, but there are some that are not covered by the data sheet. The data sheet is 260 pages so it's not too easy to describe the programming method in one post. Here is my attempt. Excuse me if I miss some details here and there. 4 things are needed for programming: Vdd, Vpp, clock and data lines. Vdd, should be abe to be set between 2V and 6V. Vpp should be 12V - 14V. The data and clock lines are TTL or CMOS levels. The general idea is that the programmer sends a 6 bit instruction to the PIC using the data and clock lines followed by a 15 bit data word. This is normally an instruction to programme a memory location. It has to be done several times and then read back until the return data matches what has been written at a variety of Vdd voltages. The data is then written to the location more times accordig to the number taken to get valid data being read back. The number of times data is written can be up to 100 for each location. Then the memory location is incremented and the process is repeated. The basic problems in the simplest programmers are: Vdd should be a variable voltage at up to 100mA. Vpp should be a variable voltage also up to 100mA. Most cheap programmers don't provide 2 x 100mA power to the chip and nor do they offer variable voltages. The data and clock lines from a serial port programmer are RS232 compliant (1 is -3 to -12V, 0 is +3 t +12V) the levels have to be converted to 0V and 5V. The timing between the clock and data lines is critical. Now, the average serial port will provide up to about 25mA of current on each of the lines. It will take up to 8 lines to provide 200mA of current that the programmer should be able to provide, so the power supply is compromised. Cheap and simple programmers don't allow variable voltages. While it is possible to do without them, the programming is not as stable as with a production programmer. RS232 ports are difficult to control through Windows when the timing is critical between the clock and data lines. It is quite an achievement to do this under Windows bearing in mind the operating system gets in the way and the port was never designed to be driven this way. Timing can be compromised because of the poor real time response of Windows (and other operating systems). The programmig is very interactive. Some of the cheaper programmers don't provide a return data path, so the programming is carried out according to a best guess rather than writing followed by testing for each byte. Data stablity can be poor and erasing can be difficult in the future as a result. All of these compromises can be accepted individuallly by most PIC devices. Add several of them together and one can see why some programmers work for some chips and not others, work on some PCs and not others and work for one length of lead ad not another. Add the 'in circuit programming' capability to a cheap programmer where the target system has a huge effect on the programmig parameters and it almost becomes surprising that the cheap programmers work at all. Let me state very clearly here: I am not criticising any of the cheap self build programmers. They all have a purpose and they provide an effective low cost entry to PIC programming. My concern about them isn't the designers' abilities, it is more about the variables that a programer will meet in the real world. Remember that I have written in a few paragraphs some of the requirements that Micropchip set out in 260 pages. The detail of programming each device is far more complex than I suggest with a quick gloss over of the procedure and there are excpetions to almost every programming parameter that I have mentioned. To the programming purists - my apologies for missing important chunks of the procedures. And to those who have a mind to build their own from my description: There is still 206 pages to be read before you even think about starting. While I am writing, Dave Mucha in other posts has requested information regarding programmers in the database he has set up. I am currently working with dave and two others looking at the feasability of designing a reliable unviersal programmer for self build. It will help greatly if you can enter the details of any third party programmer that you have used. the More we know about what exists, the better we can assess the needs for a new design. Thanks to all who can make the contributions Peter --- In , "ydexter" <ydexter@y...> wrote: > OK, folks > > I think I saw enough opinions about PIC programmer. I think you own > more experience than me, so I belive you. Until I will be able to get > a decent osciloscope and analize the signal I will use JDM to put the > software into PICs. I'm not able to imagine why is so hard to shape > some serial signals, but I will get this in future. I'm a little bit > dissapointed because the thread was moved in another direction ( see > USB versus RS232, PC future, and other things ), but I was curious > about what kind of signals you must provide to the PIC's pins to > respect the Microchip specifications. Maybe I will make you angry, but > I really don't see why so much trouble with reflections and signals > shape constructions. As a matter of fact, the comunication speed is > not so high. If one can post about this I will be very happy, because > Microchip doesn't talk much about those problems. > > thanks for your posts |
|
>> I really don't see why so much trouble with reflections and signals >> shape constructions. As a matter of fact, the comunication speed is >> not so high. Correct. Many people, some of whom do not really understand transmission line effects, make mountains out of molehills when it comes to this subject. There is much folklore in this area of electronics. >Reflection, crosstalk etc. has nothing to do with communication speed, >only with signal rise time. You can get lots of bouncing when you send a >fast-rising 1 Hz square wave over a 1m cable to a high-impedance >receiver. This would be true only if the components were incorrectly matched. You should not get any bouncing. Whether it is a high-impedance or low-impedance receiver is irrelevant. What matters is that the transmitter, transmission line and receiver should all be of the same impedance, be that high, medium or low. However, a correctly designed low speed communication line should never be presented with a fast rise time signal. Such signal components should be filtered out. >One of the toughest problems I evert hunted down (note: I am a computer >programmer, not a hardware guy!) was a bundel of some 32 address + 16 >data wires running maybe 10 cm from a bus to a bunch of buffer chips (it >was a kind of bus riser). The bus was of course driven with a low >impedance (and the bus itself was properly terminated at the ends!), but >the receivers were high-impedance. When a certain combination of address >and data was presented on the lines the (edge-triggered) receiver would >consequently read a different value (this happened only on a few >address+data combinations!). A high-speed local analyser showed the >problem nicely. It disappeared totally when even a modest (10k) load was >placed on the lines near the receiver. The fact that you needed extra loading indicates that the bus was not correctly terminated as you claim. The receivers themselves ARE the terminators. If they were high impedance and the bus was low impedance then they might require shunts to prevent reflections. Doing so however, totally defeats the whole concept of impedance matching. It's purpose is to ensure the most efficient transfer of energy from the source to the load. As a bonus, reflections are eliminated. BTW, it is bundle not bundel. |
|
|
|
On Tue, 13 Apr 2004, ydexter wrote: > OK, folks > > I think I saw enough opinions about PIC programmer. I think you own > more experience than me, so I belive you. Until I will be able to get > a decent osciloscope and analize the signal I will use JDM to put the > software into PICs. I'm not able to imagine why is so hard to shape > some serial signals, but I will get this in future. I'm a little bit > dissapointed because the thread was moved in another direction ( see > USB versus RS232, PC future, and other things ), but I was curious > about what kind of signals you must provide to the PIC's pins to > respect the Microchip specifications. Maybe I will make you angry, but > I really don't see why so much trouble with reflections and signals > shape constructions. Use the Jdm for example with an ICSP and a cable of 80cm long. Tell me whe you have programmed ok an A device. Then you will understand all the folks have pointed here. Thank you, Vasile |
|
|
|
>> You can get lots of bouncing when you send a >> fast-rising 1 Hz square wave over a 1m cable to a high-impedance >> receiver. > > This would be true only if the components were incorrectly > matched. Bright guy. I take it you use either high-impdance wires, or the impedance of your special high-impedance receivers matches that of a wire (30..300 ohm area)? > However, a correctly designed low speed communication > line should never be presented with a fast rise time signal. Now we are talking buisiness. What do think the rise time is of a PIC output, a parallel port output, or a TLL (for instance HC, HCT) output? Note: I do not mention the serial port, those outputs are deliberately slowed. > The fact that you needed extra loading indicates that the bus was not > correctly terminated as you claim. No. It indicates that the 10 cm stub was long compared to the rise time. BTW the bus itself was build on a multi-layer PCB, in which the transmission wires sandwiches coax-like between earth layers and wires. The (high impdance!) recievers on the other cards were sufficiently close to the transmission wires. This was a space project, it had all been simulated and analysed to death, except for the riser card, which was a debugging aid which would never go to space, and hence was not simulated, analysed and tested to the same standards. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products |
|
> Use the Jdm for example with an ICSP and a cable of 80cm > long. Tell me > whe you have programmed ok an A device. Then you will > understand all the > folks have pointed here. But the worst of all is that you might actually succeed using PC 1, only to discover that it fails using PC 2. Designing something to work on your desktop is not exactly the same as designing somethig that must fork for lots of other people. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: www.voti.nl consultancy, development, PICmicro products |
|
|
|
> Designing something to work on > your desktop is not exactly the > same as designing somethig that must > fork for lots of other people. If it forks for everybody, then we have a LOT of new babies and a LOT of new Dad's typing with a baby in one arm! Maybe we need a 'babies' folder in the photos secion. Dave |
|
--- In , "Wouter van Ooijen" <wouter@v...> wrote: > > I really don't see why so much trouble with reflections and signals > > shape constructions. As a matter of fact, the comunication speed is > > not so high. > > Reflection, crosstalk etc. has nothing to do with communication speed, > only with signal rise time. You can get lots of bouncing when you send a > fast-rising 1 Hz square wave over a 1m cable to a high-impedance > receiver. I got that, I read some papers and they count very much on rise and falling time, measured in V/micros. I know what you said. |
|
I'm not the kind of person you can trust, believe me or not. --- In , "Dave Mucha" <davemucha@j...> wrote: > This thread has taken some turns as you mentioned and some of us are > interested in getting a better programmer. > > Can you help us a little and search for programmers and add them to > the database on the piclist pages ? > > Since you will be one of the people who get the most from this > project, is it fair to ask you to help us in some small way. > > One of the software packages available for many different programmers > is www.ic-prog.com and they also offer links to different schematics > for some popular units. > > Dave > --- In , "ydexter" <ydexter@y...> wrote: > > OK, folks > > > > I think I saw enough opinions about PIC programmer. I think you own > > more experience than me, so I belive you. Until I will be able to > get > > a decent osciloscope and analize the signal I will use JDM to put > the > > software into PICs. I'm not able to imagine why is so hard to shape > > some serial signals, but I will get this in future. I'm a little bit > > dissapointed because the thread was moved in another direction ( see > > USB versus RS232, PC future, and other things ), but I was curious > > about what kind of signals you must provide to the PIC's pins to > > respect the Microchip specifications. Maybe I will make you angry, > but > > I really don't see why so much trouble with reflections and signals > > shape constructions. As a matter of fact, the comunication speed is > > not so high. If one can post about this I will be very happy, > because > > Microchip doesn't talk much about those problems. > > > > thanks for your posts |
|
|
|
--- In , "ydexter" <ydexter@y...> wrote: > I'm not the kind of person you can trust, believe me or not. This answer surpizes me. I assume that you have looked at the stuff that is already freely available and that your posts on the subject were after you found units that did not meet your needs. To that end, I assume you at least looked at more than one device and that you would have some record of what you liked or did not like, even if it was just memory. I was not asking for a professional review, just a listing and the name and the url for it. And, that is not very much to ask if you will be get biggest reward from having some very expeianced engineers take their time to design a device that does not meet your needs. Since one of your first posts listed that you did not want to pay $20.00 for a device that only has $10.00 in parts, I assume that you would be willing to keep the project cost low. The current PIC unit we have a general layout for is close to $20.00 in parts, not including shipping. As I had mentioned in a very early post, if it takes one person one day to read the 200 plus pages, one day to design and layout a board, one day to build it, and one day to fix any errors, then one day to create a very detailed website so a novice can follow the directions, you can easily see that there is no possible profit for someone who then sells 10 units a year. And, yes, it may take slightly more than a day to read the documents. Dave |