PIC32 programming and debugging can be made with PICKit2 so (for example under Eclipse) you get essentially all the toolchain for free, no code size limits etc. PICKit2 is one of the cheapest dev tools on the market (that is PIC18F2550 + 4 bjts + crystal) and can not only program and debug PIC8 but also ISP program AVR8 chips. Although not explicitly stated - supplying a school laboratory with PICKit2 + a bunch of PIC8 and PIC32 would cost a fraction of comparable functionality AVR8 set.
Just to be clear. The PICkit 2 can only program a small number of PIC32 microcontrollers. The PIC32MX250F128B is NOT one of them. See the PICkit 2 device list. You would be better off with the PICkit 3 for programming the newer microcontrollers.
You would be better off with the PICkit 3 for programming the newer microcontrollers.
But the PICkit 3 is slooooow when programming pic32's. For real/professional work you have to use the ICD3 which is much faster but also much more expensive.
No problem for companies but could be a problem for students.
Just to be clear. The PICkit 2 can only program a small number of PIC32 microcontrollers. The PIC32MX250F128B is NOT one of them. See the PICkit 2 device list. You would be better off with the PICkit 3 for programming the newer microcontrollers.
This is only true if you use the MPLAB X IDE. With
pic32prog you can flash devices with a PICkit 2 which you can't with MPLAB X, so it is not a hardware limitation, but they crippled their software intentionally to sell their PICkit 3.
they crippled their software intentionally to sell their PICkit 3.
Stopping adding new part support is not the same as "crippling".
Just to be clear. The PICkit 2 can only program a small number of PIC32 microcontrollers. The PIC32MX250F128B is NOT one of them. See the PICkit 2 device list.
That is inconceivable! Also AVRs weren't mentioned on their list
Now, being serious, here is a recent
ejtagproxy Readme.
Stopping adding new part support is not the same as "crippling".
+1. Although it would be nice of them if they provided some API for adding new devices to their programming GUI.. Consider Microchip "no" policy when buying their tools.
Microchip's final official release of the device file (1.62.14) for the PICkit 2 standalone application supported 17 PIC32MX devices, but PICkit 2 support for the same devices under MPLAB was never added although at the time they were already supported with a PICkit 3 or an ICD2 or 3. Similarly, MPLAB X beta supported the ICD 2, but that was totally dropped from the final release.
Its one thing to freeze support for legacy hardware tools, but quite another to actively remove support for them. If you have all the software components available to support a part but choose not to, the difference between 'stopping adding new part support' and 'crippling' is so fine that to most of us its imperceptible.
I am talking about the Standalone PICkit 2 GUI (PICkit2V2.exe) provided by Microchip. Not MPLAB X IDE.
It uses a binary device file to control the programming.
New devices have been added by users using the PK2Device Editor written by dougy83@gmail.com The latest user device file I have is version 1.63.148 with a minor change found in a forum that I added.
As stated, the MPLAB X IDE uses a different mechanism for the PICkit 2 and newer devices can't be added.
I was unaware of the pic32prog program.
Here's the list of supported PIC32s:
PIC32MX320F032H
PIC32MX320F064H
PIC32MX320F128H PIC32MX320F128L
PIC32MX340F128H PIC32MX340F128L
PIC32MX340F256H
PIC32MX340F512H
PIC32MX360F256L
PIC32MX360F512L
PIC32MX420F032H
PIC32MX440F128H PIC32MX440F128L
PIC32MX440F256H
PIC32MX440F512H
PIC32MX460F256L
PIC32MX460F512L
MCHP could go the ST Discovery/Nucleo route and start doing loads of cheap Microsticks all then way instead of this Pickit 2/3 nonsense if they wanted to!
If you have all the software components available to support a part but choose not to, the difference between 'stopping adding new part support' and 'crippling' is so fine that to most of us its imperceptible.
The easiest way for the vendor to validate the "no" policy is to (Atmel's version)
"Because of hardware limitations of this tool ... 200$ upgraded new version, thank you".
Or alternative Microchip version (paraphrasing MarkF):
MPLAB X IDE uses a different mechanism for the PICKit3 and newer devices can't be added. Fear not, PICKit4 only $55.99 today!
With pic32prog you can flash devices with a PICkit 2
A great little program, simple to use and it 'just works'. A few days ago I got my first PIC32 chip (an MX150F128B). With pic32prog I had it running on a breadboard in under 10 minutes (hardest part was the wiring!). To save typing I added the line "pic32prog ${ImagePath}" to end of build in the project properties in MPLABX - now I have '1-Click' compile and program in 15 seconds.
they crippled their software intentionally to sell their PICkit 3.
Not so much 'crippled' as just dropped support. Microchip supplies full source code for the PICkit2, so it can be updated forever if anybody can be bothered. That
has been done for the PIC32MX250F128B.
I am talking about the Standalone PICkit 2 GUI (PICkit2V2.exe) provided by Microchip. Not MPLAB X IDE.
The class uses a Microstick II with the DIP chip. I do not know the difference between it and the PICkit. I think I will make a list of all the "kits" and software Microchip sells and ask someone to explain it all.
I bought a Microstick II because I thought the course was going to be posted on YT (now I am sure it will not be). Since I know NOTHING about this, I hope to get a LED to flash in a year.
Before I even take it out of the box, I have run into problems and will post a new topic on it.
The Microstick II uses MPLAB C IDE see this info sheet
http://ww1.microchip.com/downloads/en/DeviceDoc/51951B.pdf
the microstick ii has programmer built in. I think all pins exposed to headers except the oscillator and maybe the power pins. (been a while since I poked the microstick ii, its a nice simple little dev board for the pic32)
Yes its amazing Zilog is still around who could have tought that!
They are not attractive enough to get acquired
I am talking about the Standalone PICkit 2 GUI (PICkit2V2.exe) provided by Microchip. Not MPLAB X IDE.
The class uses a Microstick II with the DIP chip. I do not know the difference between it and the PICkit. I think I will make a list of all the "kits" and software Microchip sells and ask someone to explain it all.
I bought a Microstick II because I thought the course was going to be posted on YT (now I am sure it will not be). Since I know NOTHING about this, I hope to get a LED to flash in a year.
Before I even take it out of the box, I have run into problems and will post a new topic on it.
The Microstick II uses MPLAB C IDE see this info sheet
http://ww1.microchip.com/downloads/en/DeviceDoc/51951B.pdf
The PICkit 2 and 3 are just debuggers, the Microstick II (and all Microsticks) include a debugger on board together with the target device which is socketed.
Let us know the problems you're having, we might be able to help. I'm not affiliated to Microchip in any way, but I do use their products pretty extensively.
[Zilog is]not attractive enough to get acquired
I mentioned that the Z80 architecture also lives on in some of the Renesas chips (probably via NEC who used to be a Z80 second source.)
I haven't actually used one of these, but I read through enough of the documentation to have a distinctively bad feeling about how desirable it might be to extend a fundamentally 8-bit architecture to 32bit ALUs with large amounts of memory, code space. Renesas is perhaps the most successful company to try this, although you can see plenty of this in other 8bit architectures that have been stretched beyond the point where someone should have stopped. PIC (8bit), MSP430, and AVR all start to get pretty annoying when you start looking at the "extended memory" models. You can attach a bank-switching scheme to just about anything, but that doesn't mean you shouldn't start looking at true 32bit cpus instead...
[Zilog is]not attractive enough to get acquired
I mentioned that the Z80 architecture also lives on in some of the Renesas chips (probably via NEC who used to be a Z80 second source.)
I haven't actually used one of these, but I read through enough of the documentation to have a distinctively bad feeling about how desirable it might be to extend a fundamentally 8-bit architecture to 32bit ALUs with large amounts of memory, code space. Renesas is perhaps the most successful company to try this, although you can see plenty of this in other 8bit architectures that have been stretched beyond the point where someone should have stopped. PIC (8bit), MSP430, and AVR all start to get pretty annoying when you start looking at the "extended memory" models. You can attach a bank-switching scheme to just about anything, but that doesn't mean you shouldn't start looking at true 32bit cpus instead...
While that's true, when programming C on the PIC16 using XC8, the bank switching is hidden from the programmer. That's good and bad, good that the programmer doesn't usually have to worry about it, but bad in that the programmer is pulled away from the implementation details and cares less and less about performance. We've seen that on desktop and server software over the past couple of decades as distributed non-deterministic systems have become the norm, relying on stochastic performance measurement after the event, not at the point of design and implementation, because to model it is simply too complex or the individual unit performance metrics simply don't exist. Embedded systems very often can't work that way, guaranteed performance usually isn't an optional feature.
One reason why the PIC16 is still hugely popular include the vast and continually expanding range of peripherals often taking work away from the core, and thus reducing power consumption. In some implementations, the core can sleep while the peripherals take care of the work (SMPS for example), only to wake for initialisation and mode changes or exception handling.
when programming C on the PIC16 using XC8, the bank switching is hidden from the programmer.
Really? What's the maximum size of an array or other contiguous RAM data structure? Doesn't the presence of SFRs in each data bank really mess that up? (One of the things that was greatly improved in PIC18, IIRC?) (Although, I'm talking more about the issues that happen when systems break a 64k limit, rather than the relatively minor issues associated with the PIC's 2k code pages. IIRC, PICs don't go there, and have some pretty strong limits on total RAM size as well. (Yea for Microchip having a better grasp of the limits of their architecture than some other vendors!)
And in any case, it places an extra burden on the compiler (the real reason for RISC: "let's make things easier for compiler writers!"), so avr-gcc and msp-gcc both get relatively obnoxious trying to deal with "extended memory" versions of their respective chips, and have other restrictions (or "bugs.")
I think our sentiments are in general agreement. XC8 for example deals with large data structures using the FSR(s) rather than bank switching, so an additional level of complexity is introduced by the compiler to hide the mess underneath. And yes, I agree, sometimes the compiler refuses to generate code. I would say though that if you are using large data structures other than simple arrays on PIC16 it's probably not the right device for you anyway, as you say the RAM on PIC16s is pretty small in general. Apart from specifically generating a case to force this on PIC16, I can't remember recently encountering this as a problem in a real project.
I remember dealing with some of the early PIC16 and PIC18 compilers 10 or 12 years ago where you had to deal with the bank switching and memory allocation completely manually yourself, which was pretty time consuming, and as your project grew you found yourself having to juggle data structures around several times to make objects fit into the various RAM banks, it wasn't pretty.
XC8's effective array/object size limit on the 'classic' midrange (PIC16Fxx/xxx) core is the lesser of available RAM in one bank or 80 bytes, as more than that cant be fitted in one bank without stomping on the 16 byte shared (unbanked) area. The enhanced midrange (PIC16F1xxx) core also maps all its banked RAM contiguously higher up the memory map so this restriction is removed