Electronics > Microcontrollers

Why do people not like Microchip?

<< < (44/57) > >>

poorchava:
I started looking at Microchip again, since I can't buy any STM32 nowadays, and C2000 are just a too much of a pain to use for a general purpose microcontroller.

I've used them until like 7...8 years ago. Stuff that used to throw me off:
-all 8 bit PICs (10, 12, 16, 18) are SHIT. Much slower than AVR, non-vectored interrupts, memory banking, etc. The only reason I'd fathom to use them would be either some ultra low power application, or something that would use some of their weird (but admittedly - interesting) peripherals like CTMU.
-dsPIC30s were total CRAP. I recall one of those drawing so much current it was actually very warm. And this wasn't some shorted GPIO.
-all parts had frequent read/modify/write problems
-silicon bugs. My favorite was some PIC24H which was advertised as 'USB OTG OMG WTF' and the first paragraph in the errata was 'USB doesn't work'.
- I recall that onc upon a time they were aggressively marketing paid compiler versions that resulted in almost 50% smaller code... That's when I looked at the disassembly and found out that the free version was deliberately adding dummy instructions to blat the code and slow it down.... Great... Maybe it's different now, I don't know.

westfw:

--- Quote ----all 8 bit PICs (10, 12, 16, 18) are SHIT. Much slower than AVR
--- End quote ---
That's not entirely true.  The PICs take 4 clock cycles per instruction (vs 1 on the AVR), but they also frequently allowed clock speeds about 4x faster than similar AVRs.


--- Quote --- the free version was deliberately adding dummy instructions to blat the code and slow it down...
--- End quote ---
There was a lot of debate on whether it was adding dummy instructions, or whether their "no optimization" code was REALLY dumb.  (avr-gcc -O0 code is also really horrible.)  If you assume that the unoptimized code was aimed at some abstract VMish thing that put a C-like architecture on top of the PIC decidedly un-C-friendly CPU, it was almost within the realm of believability.  It was pretty awful, though.

--- Quote ---Maybe it's different now, I don't know.
--- End quote ---
It is in fact much better now.  Not great, but no longer in the "this is completely horrible" range.

AaronD:

--- Quote from: poorchava on November 08, 2021, 12:15:52 am ----all 8 bit PICs (10, 12, 16, 18) are SHIT. Much slower than AVR, non-vectored interrupts, memory banking, etc. The only reason I'd fathom to use them would be either some ultra low power application, or something that would use some of their weird (but admittedly - interesting) peripherals like CTMU.

--- End quote ---

I wouldn't go quite that far.  Yes, the CPU is awful compared to AVR, and the almost-requirement to use a proprietary compiler that is focused more on commercial profit than on hobbyist accessibility (it never was GCC-compatible and probably never will be), makes it even worse.  But they seem to have a lot more peripherals for the price than AVR, even for the bog-standard stuff.  So if I can make the peripherals do all the work and keep the CPU as just a supervisor with only a small amount of less-critical "glue logic", then that makes a PIC the better choice.

But for data-processing kinda stuff, AVR wins by a mile in the 8-bit world!  It was wonderful, having learned on PIC, to use an AVR for the first time to make a DMX lighting controller.  A little bit of peripheral work just to move data in and out, and TONS of memory and number-crunching.  Just to declare a single, 2-dimensional array (scenes x channels) to occupy several kB would be a tall order on a PIC, but the AVR was like, "Yeah, sure!  What else ya want?"  Not to mention working through all of that data within one refresh cycle.
(PIC's do tend to have higher maximum clock rates, but not *that* much higher.  32MHz/4=8MIPS for PIC, vs 20MHz=20MIPS for AVR.  Plus, AVR likes to include a single-cycle multiplier more than PIC does.)


--- Quote from: poorchava on November 08, 2021, 12:15:52 am ----dsPIC30s were total CRAP. I recall one of those drawing so much current it was actually very warm. And this wasn't some shorted GPIO.

--- End quote ---

:o  Good to know that.  I've been casually looking for a good DSP chip myself, that supports 8-ch bidirectional audio + HID as a USB device, plus some audio ADC's and DAC's, and can use my own code to get the latency way down for the analog-to-analog signal path.  (most libraries use a block size of 64 samples or so, but I need single samples)  I'm guessing that's not it.


--- Quote from: poorchava on November 08, 2021, 12:15:52 am ----all parts had frequent read/modify/write problems

--- End quote ---

Never had a problem with that myself.  Maybe because I learned on them and treated that oddity and its workaround as "normal"?  I'm not even sure what it is.


--- Quote from: poorchava on November 08, 2021, 12:15:52 am ----silicon bugs. My favorite was some PIC24H which was advertised as 'USB OTG OMG WTF' and the first paragraph in the errata was 'USB doesn't work'.

--- End quote ---

:-DD  That's good!  I wouldn't put it past them though.  Too much marketing pressure to get it out NOW!???


--- Quote from: poorchava on November 08, 2021, 12:15:52 am ---- I recall that onc upon a time they were aggressively marketing paid compiler versions that resulted in almost 50% smaller code... That's when I looked at the disassembly and found out that the free version was deliberately adding dummy instructions to blat the code and slow it down.... Great... Maybe it's different now, I don't know.

--- End quote ---

The official explanation is that all versions initially output the "free" assembly by concatenating prefab entries from a lookup table that each have enough wrapper code around them to guarantee that they all work in every context as-is, and then the paid versions go back and clean that mess up according to how much you paid for it.  In that sense, it's not artificially stuffing the output with dummy instructions, but yeah, the completely uncleaned code that you get from the free version is pretty bad.

But the chip does end up doing what the source tells it to do.  In that sense, it's a "good" compiler, but ONLY in that sense.

SiliconWizard:

--- Quote from: AaronD on November 08, 2021, 01:50:11 am ---
--- Quote from: poorchava on November 08, 2021, 12:15:52 am ----dsPIC30s were total CRAP. I recall one of those drawing so much current it was actually very warm. And this wasn't some shorted GPIO.

--- End quote ---

:o  Good to know that.  I've been casually looking for a good DSP chip myself, that supports 8-ch bidirectional audio + HID as a USB device, plus some audio ADC's and DAC's, and can use my own code to get the latency way down for the analog-to-analog signal path.  (most libraries use a block size of 64 samples or so, but I need single samples)  I'm guessing that's not it.

--- End quote ---

Well, the dsPIC33 series is much better, more recent and more powerful. If you were interested in the dsPIC series.
The dsPIC30 series was really not that bad. It was ALOT more powerful, and easier to use than anything Microchip had released before. But yes they were power hungry and would heat up quite a bit. Absolutely no reason to go for them these days, unless the extended VDD range up to 5.5V could do something for you. Otherwise, dsPIC33 is the way to go. Of course if you want a 16-bit Microchip dsPIC. There are certainly many other and more powerful options these days.

T3sl4co1l:

--- Quote from: westfw on November 08, 2021, 01:38:59 am ---
--- Quote --- the free version was deliberately adding dummy instructions to blat the code and slow it down...
--- End quote ---
There was a lot of debate on whether it was adding dummy instructions, or whether their "no optimization" code was REALLY dumb.  (avr-gcc -O0 code is also really horrible.)  If you assume that the unoptimized code was aimed at some abstract VMish thing that put a C-like architecture on top of the PIC decidedly un-C-friendly CPU, it was almost within the realm of believability.  It was pretty awful, though.

--- End quote ---

Which IS, AFAIK, the explanation with GCC -- the IL is particularly ill-suited to AVR so makes rather boneheaded decisions, and performs little optimization once it's there [which, I think you're already keenly aware of!].  And that kind of makes sense, for all the machines GCC targets.  It seems to have improved a bit since GCC 10 or so; 8 was actually doing worse on a number of cases than 4 or 5.  (I've personally more than doubled the speed of some DSP routines with asm, versus avr-gcc 8.1.0.)  It would be... surprising? If a PIC-exclusive tool weren't optimized towards that family, but yeah, who knows.

Tim

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version