MPLAB Snap $15 programmer/debugger

[cdev]

I actually do have the source code to most of the devices that I would like to burn. But you're right, I would be unlikely to succeed and get the full benefit of learning without more contextual knowledge.

Actually, you just told me what I wanted to know, that I can run the development tools on Linux natively. So, $15 isnt such a large risk, so I think I will do it. Even though there is also a possibility that some of the hardware I have now might be able to act as a PIC programmer.

Do you know if a WinChipHead CH341A could? It can output 3.3 or 5 volts, I dont think it could or should go higher (without help at least) Probably not worth the trouble.

"An expert is a person who has made all the mistakes that can be made in a very narrow field" - Niels Bohr

[cv007]

Pretty much anything that can wiggle some pins can be made into a programmer.  The problem is its not worth the effort anymore. With a low cost supported programmer, you can press a button in mplax which compiles the code and downloads it into the target. You also get the ability to use the debugger. You then get to put your effort into writing programs and reading datasheets instead of fighting with your programming tools.

[jaromir]

Actually, you just told me what I wanted to know, that I can run the development tools on Linux natively. So, $15 isnt such a large risk, so I think I will do it. Even though there is also a possibility that some of the hardware I have now might be able to act as a PIC programmer.

I made programmer for most of modern PIC 8-bitters from arduino - see https://github.com/jaromir-sukuba/a-p-prog That is probably as cheap as you can get (2USD). Together with SDCC and GPUTILS you have nice opensource combo to build PIC projects under Linux or whatever is your choice. I used this combo on a few projects, with no major issues. I used this to build and upload code from RaspberryPi.
That being said, for years I use MPLABX+XC8+ICD3(PicKit4) on my Linux machines for most of the time, just because it's more convenient.

[cdev]

*Thank you!*

I am definitely going to try your program out (if I can figure out how to!)

Now I just need to get some 8 bit PICchips!

I am sure I am going to have some questions in a bit for you.

Are there any other IDEs that work with PIC? (Answered in your post already!)

Just as a platform to get my feet wet?

Also are there any PIC simulators or emulator software I can fool around with while I am waiting for the chips to get here?

[jaromir]

For 8-bitters, I'm not sure. All the time I use simulators, I use the ones in MPLABX.
On the other hand, AFIAK SDCC uses gpsim for regression tests - see http://gpsim.sourceforge.net/ Oh, and once upon a time, there was onen-source IDE called PikLab - see http://piklab.sourceforge.net/ It seems to be long dead, but perhaps you can use it as organ donor.
If you feel adventurous, you may also take a look at my reverse engineering of PIC18 debug module http://jaromir.xf.cz/hdeb/bdm/bdm.html I'd say modern ones are not that much different, giving you option to build your own debugger.

[cdev]

Man there sure are a lot of PIC devices, why so many different parts, certainly wouldn't it be cheaper for them to make less parts and offer best in class functionality for less through more volume?

Looking at your programmer, if I want to dedicate one of my cheap Arduino boards to it and give some of the many old DIP sockets I have a useful purpose in life, why not? I can "Be a big spender" LOL.

Cool. I think there is at least a 50/50 chance I can figure this out.

Thank you for all the links! It turns out that I already had almost all of this software installed on my PC. So now I can check out the PIC software that I have downloaded without the actual PICs.

[macboy]

For any given "family" of devices, you have multiple similar, nearly identical parts. You will usually see a few options for pin count, and for each of those, there will be a few options for memory size (FLASH and RAM). For each of those, there will be multiple package options (DIP, SOIC, QFP, etc., etc.). So yes, you might have dozens of part numbers for essentially the "same" device. All of those will share basically the same set of peripherals, timers, and other capabilities, differing only in aforementioned memory, pin count, and package.

For the hobbyist, you can ignore the lower memory options. The lower memory parts are for mass production when the features and code are final and you want to pick the cheapest part that fits. Depending on how you like to prototype, pick your favorite package, maybe DIP or SOIC, and ignore the rest. You can probably play around and prototype with the largest pin count, then maybe choose a smaller pin count when you spin a PCB for it.

So really, it mostly boils down to what peripherals do you need? Then think about speed, memory size, data size (8/16/32 bit native). I find the list narrows down quite quickly.

[NorthGuy]

Man there sure are a lot of PIC devices, why so many different parts, certainly wouldn't it be cheaper for them to make less parts and offer best in class functionality for less through more volume?

PICs have long history. There were lots of bad ideas, improvements etc. But they still keep making the old ones since people still use them, which is a good practice. If you concentrate on newer parts, there will be not that many of them, they will be cheaper than the older ones and generally better.

[perieanuo]

Just buy mikroe stuff, solid as rock, knows all hw.
I repaired more times original Microchip programmers in a electronic research company, I used for years professional and chinese programers, aside microchip I never repaired another programmer.
That's all folks
Regards,pierre


Envoyé de mon iPad en utilisant Tapatalk

[cdev]

I've noticed many people are now selling the older Pickit3 USB programmer for around $15.

Which is the best choice-that or the SNAP for both programming in a dip socket and ICSP? 

Also, where do you buy your PIC chips?

Let me be more specific. Is buying PICF675 chips maybe 10-20 on ebay asking for trouble?

(Not a super lot, and the application likely isn't that critical but I would hate to get fakes.)

[NorthGuy]

Also, where do you buy your PIC chips?

Let me be more specific. Is buying PICF675 chips maybe 10-20 on ebay asking for trouble?

I prefer buying at https://www.microchipdirect.com but they're sold everywhere - DigiKey, Mouser etc.

Instead of PIC12F675, you can buy something newer such as PIC16F15313, which is cheaper and better.

[cdev]

Thank you!

Also, where do you buy your PIC chips?

Let me be more specific. Is buying PICF675 chips maybe 10-20 on ebay asking for trouble?

I prefer buying at https://www.microchipdirect.com but they're sold everywhere - DigiKey, Mouser etc.

Instead of PIC12F675, you can buy something newer such as PIC16F15313, which is cheaper and better.

[oPossum]

I've noticed many people are now selling the older Pickit3 USB programmer for around $15.

Which is the best choice-that or the SNAP for both programming in a dip socket and ICSP? 

The Snap can not do chips that require high voltage (~12V) programming. The 12F675 is one of the older chips that does, so the Snap would not work.

For the newer PIC and AVR the Snap would be the one to get. The current device support list is attached.

I have been buying from Arrow lately because they currently have free shipping. I usually buy from Mouser or Digikey.

[oPossum]

Search eBay for "pickit adapter" if you want a ready made ZIF programming socket board.

I use the j1sys products.
https://www.ebay.com/itm/231507323729

[cv007]

SN@Pmate is becoming reality (for me anyway).

I had previously shown a few pictures of my idea to make a SNAP adapter so we can get 3.3v/5v from the SNAP. I also added an Esp32 as a telnet-serial adapter so any serial output from the target can simply go back to the sn@pmate and not need another serial-usb adapter. It worked ok, but MCHP will eventually get their features rolling on the snap where there can be a channel back to the pc via the snap (at least I get that impression from reading the help, but may be wishful thinking).

So I decided to simplify, and stick to the main idea. An adapter board that fits in a standard case so we (I) can get the 5/3.3v for the target power. I cannot figure out what that 3.3v regulator is on the snap board (mainly its current capacity), so just decided to do my own 3.3v from the usb 5v with the advantage I can probably get a little extra current by using a buck converter with better efficiency. The 5v is limited by the snap (via a current limit ic) to about 1 amp, so the limitation is probably going to be that or whatever the usb port is willing to deliver. Should be plenty in any case.

I also decided to make available all 8 pins even though I currently only need the 5. I really don't like any connectors, so decided to go with one I dislike the least- a 10pin idc shrouded/keyed header. One row matches with the 5pin pic scheme, so can use any 5pin connector currently used with a pic (although male/female is reversed, but no matter because it is always wrong anyway). There are 2 pins for power- 3.3v/5v which is always available (the snap power pin does what it originally designed for- detect target voltage only, so can still use external power if wanted). The remaining 3 pins are for whatever MCHP wants to do with them in the future (or maybe are already used, I don't know).

I designed and sent away for the pcb's, 3 from oshpark, and 10 from jlpcb (I wanted white, and wanted to check these doods out). The jlpcb boards to about 8 days, the oshpark boards took about 3 days longer. 

I'm still not done, but close (need to cut case for connector cutouts). I'm kind of making it up as I go. I didn't know what I was going to use for contacts between the boards so just made a contact board to attach to the snap, and some holes in my snap board to make some kind of contact connection. There is only 2mm space between boards, and by the time you add a contact pcb in there, there is only 0.4-1mm space. I'm sure there is something available, but could not find anything that would work with that small gap. Anyway, an rg58 center conductor became my 'spring' contacts. Everything fits snugly in the box, so am not too worried about maintaining contact.

Some photos of progress -
https://photos.app.goo.gl/HA7EgmibKAuhWsRN7
(the hammer was used to drive a tight-fitting wire through the snap and the contact board- then snipped both sides and used a punch to 'rivet' the boards together- was just trying to come up with a non-solder way to get those boards connected)


By the way, I have been using the snap on a pic32mm, and it works quite well. I think it may even be faster than the speed of light. There have been a few times I wold have to unplug/plug when mplabx could not find it, but it was usually when doing usb stuff (incorrectly) on the pic32mm. Unless they decide to somehow screw up the firmware in the future this is a nice little programmer/debugger. Just needs a case and some power output.

[Ian.M]

As mentioned a lot earlier in the topic,  if you need old device support and full current device support for PICs (but not ancient PIC16C... and PIC18C... devices),  a PICkit 3 clone is your best low cost option.  Get the PIC you want to work with in a DIP package (up to 40 pins) and stick it in a solderless breadboard with Dupont pinned jumpers to the PICkit 3.

Extracting firmware from PICs in commercial devices is extremely difficult as PCs have protection bits that can be cleared to prevent reading of the program memory by an external programmer.  A few of the earliest flash PICs had flawed protection and there were exploits to recover the memory contents, but you can assume that any PIC from this millennium cant be cracked non-non-invasively if the device manufacturer set up the protection correctly.  However various specialist reverse engineering companies operating in countries with lax copyright law enforcement claim to be able to recover the firmware of any PIC by decapping and microprobing given three identical sample devices.  Prices are typically in the three or four figure USD range, so don't count on a PIC to keep your company's software 'secret sauce' secure against well-funded competitors.

Once you have a firmware image, disassembling it is fairly easy (but tedious), and it is possible to get the disassembly to the point that you have a source file that will build an identical firmware image.  However there wont be any meaningful variable or subroutine or label names, so the result will be of little use if you want to develop it further.  If the original firmware is the product of a high level language compiler, the difficulty of reconstructing an equivalent source file in that language increases exponentially, even if you know the exact compiler version used.   If not, well, its the software equivalent of turning a cooked beefburger back into a cloned cow!