Going back to post #15, I am reminded of the rhetorical question, who taught the Wright Bothers how to fly? While Mike's suggestion to use some 74HC chips may not be a commercial success, for the hobbyists I see on these forums struggling with their first programmable chips, it may be useful. If they need a cheap, programmed chip to make their their first programmer, where do they get that chip?

There is certainly value in both approaches, I hope that those of you who know how to make a programmer without a pre-programmed chip won't abandon that project.

Regards, John

 

Of course, it's much more than 1000 different PICs.

The design is very simple. It's PIC16F1454 (or PIX16LF1454 connected through LDO) which connects to USB - it doesn't even require a crystal - amazing PIC. Then it uses pins to manipulate MCLR,PGC, and PGD. Since it's LVP-only, nothing else is needed. There are more advanced models with level shifter which can program at 2.5, or even 1.8V (although not many PICs are capable of being meaningfully programmed at 1.8V). I cannot post the code as it is commercial. I'll post the link when it goes online - it has full schematics (although very small). It is not going to be expensive. We're developing a system (compiler, tools and such), and we needed a programmer/debugger for it, but the development of the system is moving along very slowly and it is so happened that the programmer is ready, so we decided to release it as a standalone programmer without waiting for the rest of the system.

 

A default (all parts) search on Microchips MAPS selector yields:

"Search Results 1046 MCHP parts found"

 

Going back to post #15, I am reminded of the rhetorical question, who taught the Wright Bothers how to fly? While Mike's suggestion to use some 74HC chips may not be a commercial success, for the hobbyists I see on these forums struggling with their first programmable chips, it may be useful. If they need a cheap, programmed chip to make their their first programmer, where do they get that chip?

I could not disagree with this any more than I do.

Getting your very first micro-controller blinky LED to work has so many pitfalls and traps for the newbie I strongly recommend getting a pre-assembled and tested development board, a complete programmer (with a debugger too of course), along with some tutorials with known good code.

When starting if you build your own board, build a programmer, write some code, hit GO and the LED don't blink... what to do?

You have so many flimsy links in your chain you have no idea where to begin troubleshooting.

Far better to take many small steps over a few huge steps and fall flat on your face.

 

Ernie's objections are noted and I admit that building a programmer for the new LVP spec without any programmable parts is probably more of an academic exercise now days. Five or six years ago, before we had $4.30 Launchpad boards or $3.00 Arduino boards, Byron Jeff mentioned on PICLIST that he was looking for a way to put an inexpensive, perhaps almost disposable, serial LVP programmer at every position in his computer labs. At that time, parallel ports on PCs had all but disappeared and an inexpensive circuit that could do asynchronous to synchronous as well as synchronous to asynchronous using a few off-the-shelf 74HC chips (to support the new LVP protocol) was an interesting challenge.

Now days we don't even have serial ports but it seems you could use a $3.00 Arduino Nano, without any additional circuitry to speak of, to program all of those devices that support the new LVP protocol. It might be a relatively inexpensive way to "test the waters", so to speak, for those hobbyists that may not have the resources to buy a PICKIT 3, or for those hobbyists with no interest in PIC programming who simply want to copy an existing project one time only.

 

NorthGuy, I hope you'll remember to mention it here when your programmer is ready for sale. I've read up on the PIC16F1454 series myself, and it does seem to have a lot of capability for the money. A USB interface that doesn't even need a crystal oscillator is quite something. (Though one has to note, the FTDI interface chip doesn't need a crystal either.)

Anyway, I'm proceeding with my LVP programmer. In the last couple of days, I've got it to perform all the functions on the target processor--reset address to 0 in either program or configuration space, advance the address, load data, read data, program and erase, all based on individual commands over a serial port. I'd feel more comfortable if Microchip had included an instruction for "report present address" but you have to work with what you're given. Then on the PC end, I've put together code to open a hex file and read it into an array. I did consider just opening the file and sending it off to the programmer one line at a time, but it seems more efficient to assemble all the data and then send it, and it's not as if 8K 16-bit words are going to cause the computer to run out of memory. What I'm thinking of is filling any unused locations in the array with 0x3FFF (same data that the processor's 14-bit ROM words are loaded with after an erase operation) and then sending uniform 16-word blocks to the programmer, while skipping any block that only has 0x3FFF in every location. It means some ROM locations will get erased to 0x3FFF and will then have 0x3FFF loaded into them, but I like the idea that I don't have to fool around with addresses of locations that need to be programmed versus those that don't.

It's also necessary to have a file to send to the PIC16F1617 target processor, or the whole project would be pointless. I've got MikroC to compile a very simple program which will toggle a couple of port pins and allow me to verify how fast it's running using a scope.

 

NorthGuy, I hope you'll remember to mention it here when your programmer is ready for sale. I've read up on the PIC16F1454 series myself, and it does seem to have a lot of capability for the money. A USB interface that doesn't even need a crystal oscillator is quite something.

As usual, it took a little bit longer, but it's ready: http://www.northernsoftware.com/nsdsp/

If you click on this page http://www.northernsoftware.com/nsdsp/brd/ you can find useful links on the left which list the pinout and different connection schematics, which are very simple actually.

PC/Linux software is here - http://www.northernsoftware.com/nsdsp/soft/

I cannot post the firmware. But it is possible to buy a pre-programmed chip for DIY.

BTW: Here's benchmarks - http://www.northernsoftware.com/nsdsp/speed.htm - as you can see PIC16F1454 is quite capable.

 

Excellent product. My objections vanish when using a pretested programmer with debug capability, though the price point is very close to a PICkit, especially now that cheap clones or back door gray market PICkits are available from China.

I especially like the isolated USB unit, that is well worth the price of admission. I would even guess you set the price point too low on that one (but please don't raise it until after I buy one).

A nitpicking point is your claim to be "several times faster than a PICkit III". Speed is mostly determined by the target device, how fast the flash can flash. The data rate is inconsequential with respect to that (unless Microchip had sped things up in the 3-4 years since I made my programmer).

A job well done, I wish you nothing but overwhelming sales numbers and lots of happy customers.

 

Thank you Ernie!

The speed is an interesting question. The speed is determined by two processes - you need to transmit data to the chip, then you need to wait until the flash is programmed.

In older and smaller chips, the block size is small and waiting times are long. Therefore, transmission time is very small compared to the time you have to wait while the chip is doing flash programming. A good example is PIC16F873. It takes 8.7s to program it (write only, but with data EEPROM). Nearly all of this time is spent waiting. Transmission is nothing compare to this - the chip can be read back in 0.3s.

As the block size increases, and flash gets better (less waiting times), the situation reverses. PIC32MZ with 2MB flash only requires 4s of waiting time! On the other hand, transmitting 2MB of data to the chip becomes a challenge. Hence, writing and reading times are very close - 40.8s to write (without verification) vs 36.7s to read.

Looking at the numbers I measured with PICkit3, for some reason, it is lagging even with smaller chips (15.3s compared to 1.7s with PIC16LF1519; 9.1s compared to 1.8s with PIC18F4550). I didn't measure anything below 32K of memory, thus I automatically skipped chips similar to PIC16F873. So, I decided to test PIC16F873 (not A) right now. It took 22.6s for PICkit3 compared to 8.6s for NSDSP (write and verification of full chip without data EEPROM). This is a surprise for me. For that chip, I expected the numbers to be much close to each other. I don't know the inner workings of PICkit3, but for some reason it works slower than I would expect.