|
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 |
PIC programmer
Started by ●April 11, 2004
Reply by ●April 13, 20042004-04-13
|
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 |
|
|
Reply by ●April 13, 20042004-04-13
|
> 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 |
|
|
Reply by ●April 13, 20042004-04-13
|
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 |
Reply by ●April 13, 20042004-04-13
|
>> 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. |
|
|
Reply by ●April 14, 20042004-04-14
|
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 |
|
|
Reply by ●April 14, 20042004-04-14
|
>> 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 |
Reply by ●April 14, 20042004-04-14
|
> 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 |
|
|
Reply by ●April 14, 20042004-04-14
|
> If one can post about this I will be very happy, because > Microchip doesn't talk much about those problems. Are you talking about Microchip, company that makes PIC MCUs? If yes, then try with www.microchip.com It might help :) Here's a list of few documents that cover programming issues: - Complete Mid-Range Reference Manual - Complete PIC18C Reference Manual - A PC-Based Development Programmer for the PIC16C84 - In-Circuit Serial Programming of Calibration Parameters Using a PICmicro Microcontroller - PICmicro Device Programming: What You Always Wanted to Know (But Didn't Know Who to Ask) - How to Implement ICSP Using PIC16CXXX OTP MCUs - How to Implement ICSP Using PIC17CXXX OTP MCUs - How to Implement ICSP Using PIC16F8X FLASH MCUs - How to Implement ICSP Using PIC12C5XX OTP MCUs - Downloading HEX Files to External FLASH Memory Using PIC17CXXX PICmicro Microcontrollers - Downloading HEX Files to PIC16F87X PICmicro Microcontrollers - PIC12F508/509 Memory Programming Specification - PIC16F505 Memory Programming Specification - PIC16F54 Memory Programming Specification - PIC16F57 Memory Programming Specification - PIC16F627A/628A/648A EEPROM Memory Programming Specification - PIC16F630/676 EEPROM Memory Programming Specification - PIC16F7X7 FLASH Memory Programming Specification - PIC16F818/819 FLASH Memory Programming Specification - PIC16F87/88 FLASH Memory Programming Specification - Programming Specifications for PIC18FX410/X490 Flash MCUs - Programming Specifications for PIC18FXX39 FLASH MCUs - PIC16F87XA FLASH Memory Programming Specification (DS39589A) - PIC16F72 FLASH Memory Programming Specification (DS39588A) - In-Circuit Serial ProgrammingT (ICSPT) Guide - FLASH Memory Programming Specification for the PIC16F716 - In-Circuit Serial ProgrammingT for PIC16C433 OTP MCUs - PIC12F6XX/16F6XX Memory Programming Specification - PIC18F2331/2431/4331/4431 FLASH MCU Programming Spec - PIC18F6X2X/8X2X FLASH Microcontroller Programming Specification - PIC18FX5X5/X6X0 Flash Microcontroller Programming Specification - PIC18FXX80/XX85 FLASH MCU Programming Specifications - In-Circuit Serial ProgrammingT for PIC16C715 OTP MCUs - MCP2505X In-Circuit Serial Programming Specifications - On-Chip Debugger Specification - PIC12C5XX/PIC12C5XXA/PIC12CE5XX Memory Programming Specification - PIC12C67X/PIC12CE67X Memory Programming Specification - PIC12F629-675 EEPROM Memory Programming Spec in Development Tools Programming Specifications - PIC14000 Memory Programming Specification - PIC16C50X Memory Programming Specification - PIC16C55X Memory Programming Specification - PIC16C5XX Memory Programming Specification - PIC16C64X/66X Memory Programming Specification - PIC16C6XX/7XX/9XX Memory Programming Specification - PIC16C7XX Memory Programming Specification - PIC16F62X Memory Programming Specification - PIC16F7X FLASH Memory Programming - PIC16F87X Memory Programming Specification - PIC16F8X EEPROM Memory Programming Specification - PIC16HV54X Memory Programming Specification - PIC17C7XX Memory Programming Specification - PIC17CXX Memory Programming Specification - PIC18CXXX Memory Programming Specification - PIC18FXX2/XX8 Programming Specification - PIC18FXX20 FLASH MCU Programming Specifications > thanks for your posts No problem. Copy/Paste. Regards, Igor |
|
|
Reply by ●April 14, 20042004-04-14
|
> 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 |
