Author Topic: Why do people not like Microchip?  (Read 15704 times)

0 Members and 2 Guests are viewing this topic.

Online AaronLee

  • Regular Contributor
  • *
  • Posts: 199
  • Country: kr
Re: Why do people not like Microchip?
« Reply #125 on: July 28, 2021, 02:56:34 am »
Because you think on it like pins and not ports. If you connected an 8-bit bus to a port, would you read it bit by bit?
No, you read the port register in a single read instruction.

You have simple macros/defines to access and configure single pins. Your code can be easily reconfigurable by just using defines:
Code: [Select]
#define Toggle(x)     x^=1;
#define LED           LATA1
#define LED_TRIS      TRISA1
#define LED2          LATA2
#define LED2_TRIS     TRISA2
#define BUTTON        RA3
#define BUTTON_TRIS   TRISA3

void init(void){
    LED_PIN=LOW;
    LED_TRIS=OUTPUT;
    LED2_PIN=LOW;
    LED2_TRIS=OUTPUT;
    BUTTON_TRIS=INPUT;
}
void main(void){
    init();
    while(1){
        LED=BUTTON;
        Toggle(LED2);
        if(BUTTON){
            button_detected();
        }
    }
}

For a parallel port, yes, you're correct, it would be stupid to access it as individual pins. That's one of the exception cases.

For your style of defining pins, something similar was what I tried many decades ago. But there were three problems.

First, the "=" operator works fine for Microchip, but isn't compatible across the board with all MCUs. Defining a simple macro to look like a function, but does the same thing, works as a good alternative.

Second, initializing a pin, even if it's done in discrete steps, is often thought of in terms of one atomic operation. If you're setting a pin as an output pin, you'd better be setting the level at the same time (preferably right before setting it as an output). If not, you'll easily get unwanted results momentarily on the pins while it's being initialized. Making it as a function/macro init function for the pin allows this to be done without thinking about it. Of course, a good firmware engineer will code it in the correct order, as you did in your example, but sometimes we all make mistakes and forget things. A well designed macro can handle all of this while generating the same final code, but just making the sure the correct sequence is done, while also making the code more readable.

Third, when I'm developing/debugging, and testing pins with a scope or other test equipment, I reference my code and the schematic to find where I need to probe. I find it easy if I just have my board header file open, see the net name and pin number, and can then also search for that net name to find all occurrences of where I'm using it, so that I can change code easily. I rarely need to know the port number. Pin number (for probing or referencing on the schematic) and net name (for searching my code or also for referencing the schematic) are what I need. If I happen to need to know the port number, I can also call that up using the header file I made for the MCU part number defines, or via the MCU datasheet.

A board header file can easily be scanned to see all the interfaces organized, which pin numbers are being used for each pin of the interface, which levels are defined for those pins, etc. It just makes it all nicely organized from the firmware point-of-view. The more experienced I get as a firmware engineer, the more I realize how keeping things neat and organized like that really help with efficiency and also help greatly when returning to a project after not having worked on it for a number of years, or when a bunch of different projects are being done simultaneously and it's easy to forget details of one particular project. A quick glance at the board header file, and you easily see all the interfaces you're using, along with some brief comments in the header file about each interface, and the mind is instantly refreshed about the details of that project and ready to dig into doing whatever needs to be done. If I'm talking to a hardware, QC, PCB, or other engineer about our project, I always refer to pins by their pin number and/or net name. In general everyday use in firmware, I just don't see the need for using port numbers in the forefront, especially regarding GPIO pins.

Having definitions such as "LED_TRIS" means you're limiting your thinking regarding names to just the Microchip (not even including Atmel) realm. If you're always going to use Microchip exclusively, it might be ok, but when your code is needed to be used across a broad spectrum of devices from various manufacturers, you may find that using functions/macros while define things in terms of functionality rather than specific vendor terminology makes the code much more portable and easier to understand. Even within Microchip, there's quirks in certain devices/families regarding initializing pins, as I recall. It's very easy to forget about those quirks, or fail to recall that those quirks are applicable to the part you're working on.

I could go on and on about what I think is well-structured/organized MCU programming, but then in the end it's just my personal opinion, and I'm in no way want to force my opinion on anyone else. I do though think the MCU world is very lacking in teaching good techniques. There's countless books teaching good general programming techniques, but when it comes to MCU programming, and accessing hardware/peripherals, almost all the materials concentrate way too much on specific MCU coding for the one MCU they're teaching about, and very little on making the code portable and thinking beyond that particular MCU.
 

Offline rcbuck

  • Frequent Contributor
  • **
  • Posts: 283
  • Country: us
Re: Why do people not like Microchip?
« Reply #126 on: July 28, 2021, 03:40:03 am »
Quote
How often do you use the pin config and code generation stuff?
Sal, sometimes I use it and sometimes I don't. My last two STM32 projects have used Lwip so I had to use the code generation tools for that. Since I was already in the CubeMX setup it was just easy to also do the pin configuration there. I haven't noticed STM32CubeIDE being slow. But then again I am a slow programmer.

I always use #define for all pins. That is the only way to keep any hair on your head.

Last week I did a small PIC project using the PIC16F18313. I only used 2 GPIO pins but I #defined them. I was using I2C so I used the Microchip XC8 built in library function for that. I only have the free version of XC8 and not the fully optimized version. Code size ended up being 385 bytes of flash and 9 bytes of RAM. I don't think you can beat the 75 cent cost of the micro with any other family. At least not in the U.S.
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 17715
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Why do people not like Microchip?
« Reply #127 on: July 28, 2021, 04:35:58 am »
Yeah, I like doing that.  In fact I take that process to its fullest; like here:
https://github.com/T3sl4co1l/Reverb/blob/master/pindefs.h

Note that avr/io.h defines rich macros and names for registers and bits already (give or take a few mistakes, the ones I know about are enumerated in a neighboring file), this just makes them application specific; and declares a few handy expressions/statements to further work with them.  The bus-oriented registers are noted by comments, so the reader knows not to shuffle things around randomly; and yeah, the individual bits of them don't get used much.  This file starts as an Excel sheet (also in the project), where you fill in names and roles, and copy code out for further cleanup and additions.  It's sort-of generated, but not meant to be live generated due to the edits.

Finally, Notes.txt logs/discusses some hardware/software design issues, but here mainly logs complete pin assignments as a crude netlist, describing the hardware (I didn't produce a schematic for this project, and kind of don't need to; also, this was a necessity as it was hand wired..).  I usually put MCU pin defs at the top of main.c to help reference and motivate things.


Most manufacturers have their own tools for stuff like this; it's handy, but beware the pile of definitions they create, and how much repetition they may do.  For example, identical sections used in init and handler functions.  I recall ST Cube being pretty baroque about this.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline apurvdate

  • Contributor
  • Posts: 41
  • Country: in
Re: Why do people not like Microchip?
« Reply #128 on: July 28, 2021, 11:59:18 am »
There was no exposure to PIC or ARM during our college coursework. Only a slight mention by instructor as alternate family of controllers. 1st ever micro we used was atmel's variant of 8051 i.e. 89C51. Then it was AVR thing only. By the time we finished college and had any real experience with either PIC or ARM, arduino boom came. As we were already familiar with AVR, arduino was the thing for us.
Only after working as trainee & few basic jobs, we had any interaction with either ARM or PIC (depending where you worked).
I literally worked 1st time with a PIC last year during lockdown.
So its not like we don't like PIC / microchip, its just the situational thing where we started with AVR and moved to ARM.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5120
  • Country: gb
Re: Why do people not like Microchip?
« Reply #129 on: July 28, 2021, 05:08:15 pm »
Microchip are really good until you read the errata. Oh whole I2C peripheral unusable? Oh.

Ah, I remember the I2C peripheral being completely non-functional on a PIC24F16KA102 I used for some project about 9 years ago. IIRC, I had to implement a bit-bang I2C. Funny.

Sounds odd. I have two projects based on exactly this device, both with I2C, with no problems using my usual PIC boilerplate on it.

That's not to say Microchip don't screw up I2C, much of the PIC32 range is an industry joke in this respect, and has been for a decade.
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 7179
  • Country: fr
Re: Why do people not like Microchip?
« Reply #130 on: July 28, 2021, 05:28:46 pm »
Microchip are really good until you read the errata. Oh whole I2C peripheral unusable? Oh.

Ah, I remember the I2C peripheral being completely non-functional on a PIC24F16KA102 I used for some project about 9 years ago. IIRC, I had to implement a bit-bang I2C. Funny.

Sounds odd. I have two projects based on exactly this device, both with I2C, with no problems using my usual PIC boilerplate on it.

I took a look at the project. There was a clear mention in the changelog that the I2C module was not functioning properly and that a software-based I2C had to be implemented. Unfortunately, there is no detail about what exactly was not working right, but AFAIR, it was not even clocking. It may have depended on silicon revision? I had extensive experience with Microchip MCUs at the time, so the probability of a misconfiguration explaining the issue was very low. And, that was the only PIC MCU I used that I couldn't use I2C with in the 16-bit line.

I had kept the code for hardware I2C in this project, so I just took a look at it. I can't see anything wrong. I was using the I2C1 peripheral. All functions were the same as what I used for other PICs.
Here is the init function, which was the only thing specific (configuration + rate):

Code: [Select]
void I2C_Init(void)
{
// I2C 1.
I2C1CON = 0x3200; // I2C1: Stop in idle mode
I2C1BRG = 99; // SCL: 10 kHz @1MHz

IFS1bits.MI2C1IF = 0;
IFS1bits.SI2C1IF = 0;
IEC1bits.MI2C1IE = 0;
IEC1bits.SI2C1IE = 0;

I2C1CONbits.I2CEN = 1;    // Enable I2C module
}
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5120
  • Country: gb
Re: Why do people not like Microchip?
« Reply #131 on: July 29, 2021, 08:42:08 am »
Microchip are really good until you read the errata. Oh whole I2C peripheral unusable? Oh.

Ah, I remember the I2C peripheral being completely non-functional on a PIC24F16KA102 I used for some project about 9 years ago. IIRC, I had to implement a bit-bang I2C. Funny.

Sounds odd. I have two projects based on exactly this device, both with I2C, with no problems using my usual PIC boilerplate on it.

I took a look at the project. There was a clear mention in the changelog that the I2C module was not functioning properly and that a software-based I2C had to be implemented. Unfortunately, there is no detail about what exactly was not working right, but AFAIR, it was not even clocking. It may have depended on silicon revision? I had extensive experience with Microchip MCUs at the time, so the probability of a misconfiguration explaining the issue was very low. And, that was the only PIC MCU I used that I couldn't use I2C with in the 16-bit line.

I had kept the code for hardware I2C in this project, so I just took a look at it. I can't see anything wrong. I was using the I2C1 peripheral. All functions were the same as what I used for other PICs.
Here is the init function, which was the only thing specific (configuration + rate):

Code: [Select]
void I2C_Init(void)
{
// I2C 1.
I2C1CON = 0x3200; // I2C1: Stop in idle mode
I2C1BRG = 99; // SCL: 10 kHz @1MHz

IFS1bits.MI2C1IF = 0;
IFS1bits.SI2C1IF = 0;
IEC1bits.MI2C1IE = 0;
IEC1bits.SI2C1IE = 0;

I2C1CONbits.I2CEN = 1;    // Enable I2C module
}

Hmm, that's unfortunate! These are over a decade old, I'd have thought Microchip would've flagged up any I2C issue by now in the errata. I know it takes them a while sometimes...

FWIW, I just put a little unit test together from scratch with my boilerplate I2C targeting an FRAM, and it does seem fine.


 
The following users thanked this post: woofy

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 7179
  • Country: fr
Re: Why do people not like Microchip?
« Reply #132 on: July 29, 2021, 05:59:05 pm »
Hmm, that's unfortunate! These are over a decade old, I'd have thought Microchip would've flagged up any I2C issue by now in the errata. I know it takes them a while sometimes...

This may have plagued the early silicon revisions, dunno. I possibly got ahold of the first silicon revision for the parts used on the prototypes, and once the project was completed, I never bothered to check with newer silicon revisions if the hardware I2C would work. But yes, I could not find any mention of this in the errata for this part. I can just assure you that it wasn't working whatsoever. Now looking back at my code, maybe the bug was related to the fact I set the "stop if Idle" flag? I can't remember if I ever tried clearing it.
 

Offline radiolistener

  • Super Contributor
  • ***
  • Posts: 1848
  • Country: ua
Re: Why do people not like Microchip?
« Reply #133 on: July 29, 2021, 09:39:01 pm »
because they are expensive and have too small resources in comparison to other microcontrollers  :)
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2577
  • Country: ca
Re: Why do people not like Microchip?
« Reply #134 on: July 30, 2021, 02:49:11 pm »
Inside is a Xilinx Zync CPU with dual Arm Cortex A-9's and a FPGA section. Xilinx is one of the few vendors who does provide a bare metal development environment. Yet when I turn on the scope, it's obvious they didn't use bare metal. That's further confirmed when I watch the teardown video and see when connected to the UART debug port the messages coming from U-Boot and then Linux. Why? If bare metal was available, why didn't they use it?

That's a strange argument. Sure, you can replace PIC10F320 with a Zynq running Linux. Why not do it? They used it in the scope after all. Whether this would make things easier ... I doubt.
 

Offline esepecesito

  • Regular Contributor
  • *
  • Posts: 63
  • Country: de
Re: Why do people not like Microchip?
« Reply #135 on: July 30, 2021, 04:26:35 pm »
My story why I did not like it:
1) I used a couple of controllers for a project, and they just stopped working, without apparent reason. MANY with similar problems, different controllers, buy in different providers. Never had a similar problem with Atmel 8051 or the MOT HC05 HC08 (at that time we were making lots of projects with all of them)
2) Once I was searching for a CAN controller, and the one from Microchip had so many discrepancies with the CAN standard, that it seamed to me they didn't even read the standard.
That being said, it was like 20 years ago... but I never got over it.
 

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 1274
  • Country: gb
Re: Why do people not like Microchip?
« Reply #136 on: August 02, 2021, 08:58:27 am »
1) I used a couple of controllers for a project, and they just stopped working, without apparent reason.

My experience is the opposite, once you have a working system it just keeps on going. Once you get past the errata, I find the device silicon to be reliable and robust, to the extreme that a number of PICs I've used run at 200 Celcius for weeks. Perhaps you were experiencing software issues though.

I can see (and mostly agree with) the issues that people have with Microchip, but IMO the positives often outweigh the negatives (depending on project);
Good device availability
Pin compatability between devices
GCC based compilers are old but have all the features I need and are well tested
I find the datasheets easy to follow and mostly correct
Peripherals are generally easy to setup
DMA in PIC24 and PIC32 is great
Familiarity - once you know a lot of gotchas in one eco-system it becomes more comfortable. Better the devil you know :P (but that applies to any system of course)
 
The following users thanked this post: Sbampato12

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 12630
  • Country: gb
    • Mike's Electric Stuff
Re: Why do people not like Microchip?
« Reply #137 on: August 02, 2021, 09:40:25 am »
Familiarity - once you know a lot of gotchas in one eco-system it becomes more comfortable. Better the devil you know :P (but that applies to any system of course)
Yes, it applies to any system, but I believe Microchip is unique in having one "system" covering a very wide range of parts from tiny 8-bitters to big fat 32-bit devices.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2577
  • Country: ca
Re: Why do people not like Microchip?
« Reply #138 on: August 02, 2021, 12:38:35 pm »
Yes, it applies to any system, but I believe Microchip is unique in having one "system" covering a very wide range of parts from tiny 8-bitters to big fat 32-bit devices.

That is changing now. The newer PIC32C devices are renamed Atmel SAM parts which have completely different flavours of periphery. Designers at Microchip think that Harmony provides enough abstraction to smooth the difference.
 

Online AaronLee

  • Regular Contributor
  • *
  • Posts: 199
  • Country: kr
Re: Why do people not like Microchip?
« Reply #139 on: August 02, 2021, 01:00:25 pm »
That is changing now. The newer PIC32C devices are renamed Atmel SAM parts which have completely different flavours of periphery. Designers at Microchip think that Harmony provides enough abstraction to smooth the difference.
Hahaha, HUGE mistake. IMHO, too much emphasis on Harmony will be Microchip's downfall. Harmony is nothing but a complete piece of turd framework that should have been killed off long before they released it.
 

Offline HB9EVI

  • Frequent Contributor
  • **
  • Posts: 620
  • Country: ch
Re: Why do people not like Microchip?
« Reply #140 on: August 02, 2021, 04:02:01 pm »
for my needs Microchip has some nice A/D and D/A converters, also the low power Opamps are useful.
That I switched from PIC to AVR (before the time Microchip bought AVR), had one main reason: avr-gcc
if there was a well developed opensource compiler for PICs, I'd likely stay with them.

yea I know there is SDCC, but its PIC14/PIC16 ports are still not out of beta stage

nowadays I don't bug neither with ATXmega nor with PIC32; simple ARM mcu is all you need (if you get any from reliable sources due to the chip crisis)
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 7179
  • Country: fr
Re: Why do people not like Microchip?
« Reply #141 on: August 02, 2021, 04:22:38 pm »
Speaking of Harmony, which I've never used, is the whole source code provided by Microchip?
 

Offline esepecesito

  • Regular Contributor
  • *
  • Posts: 63
  • Country: de
Re: Why do people not like Microchip?
« Reply #142 on: August 02, 2021, 06:03:40 pm »
1) I used a couple of controllers for a project, and they just stopped working, without apparent reason.

My experience is the opposite, once you have a working system it just keeps on going. Once you get past the errata, I find the device silicon to be reliable and robust, to the extreme that a number of PICs I've used run at 200 Celcius for weeks. Perhaps you were experiencing software issues though.

I can see (and mostly agree with) the issues that people have with Microchip, but IMO the positives often outweigh the negatives (depending on project);
Good device availability
Pin compatability between devices
GCC based compilers are old but have all the features I need and are well tested
I find the datasheets easy to follow and mostly correct
Peripherals are generally easy to setup
DMA in PIC24 and PIC32 is great
Familiarity - once you know a lot of gotchas in one eco-system it becomes more comfortable. Better the devil you know :P (but that applies to any system of course)

Note I said it was looong time ago... maybe now they are in fact much better than others. At that time I really doubt it.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 4201
  • Country: fi
Re: Why do people not like Microchip?
« Reply #143 on: August 02, 2021, 06:16:11 pm »
I have hard time believing that Microchip MCUs have had such quality problems that they just "stop working".

OTOH, it's normal to have very mysterious problems when working with MCUs because these are complex devices with many possible failure modes; not only limited to ESD, reset pin connections and power bypassing, but also some software issues seem to cause something like hardware failure while it really is a software problem! (I always refer to the case where a small bug in I2C initialization code made some 3-4 units out of batch of 30 fail in the init, others work perfectly, appearing like a soldering/ESD issue!)

The number of such problems obviously goes down with experience. Just changing to different product family or manufacturer may seemingly solve the problem because the actual culprit just goes away without the need to do the (expensive) root cause analysis, but this doesn't mean there was something wrong with the original product, the designer was just a bit inexperienced, or even if very experienced, just unlucky to hit some strange hard to debug problem.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 21460
  • Country: nl
    • NCT Developments
Re: Why do people not like Microchip?
« Reply #144 on: August 02, 2021, 07:53:27 pm »
I have hard time believing that Microchip MCUs have had such quality problems that they just "stop working".

OTOH, it's normal to have very mysterious problems when working with MCUs because these are complex devices with many possible failure modes; not only limited to ESD, reset pin connections and power bypassing, but also some software issues seem to cause something like hardware failure while it really is a software problem! (I always refer to the case where a small bug in I2C initialization code made some 3-4 units out of batch of 30 fail in the init, others work perfectly, appearing like a soldering/ESD issue!)
But you have to ask yourself if you want to use a microcontroller which is so finicky to use. In the end such bugs end up costing time. Time which costs money and delays product introduction which in turn reduces sales. For smaller volumes (*) you are better off using microcontrollers which have not been optimised down to the last transistor and which have proper I/O pads. If you look at the Attiny for example: the Vih level of 0.8V has no meaningfull noise margin. This can be problematic in noisy environments. Especially compared to a proper CMOS input which typically has a Vih of 0.7*VCC.

* For high volume products it is quite normal to have a couple of hundred produced which are then tested for durability and component variations (and thrown into the shredder afterwards).
« Last Edit: August 02, 2021, 08:10:45 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1322
  • Country: us
Re: Why do people not like Microchip?
« Reply #145 on: August 02, 2021, 08:40:42 pm »
Speaking of Harmony, which I've never used, is the whole source code provided by Microchip?

Yep. It's here: https://github.com/Microchip-MPLAB-Harmony
Complexity is the number-one enemy of high-quality code.
 
The following users thanked this post: SiliconWizard

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 4201
  • Country: fi
Re: Why do people not like Microchip?
« Reply #146 on: August 03, 2021, 11:35:02 am »
Yes I agree about the concept of avoiding finicky parts to save time, but I have never heard about PIC micros being "finicky" before. In fact I think their simplicity helps save time. Same can be said about AVR. Well early AVRs did have issues with their internal reset circuit but that got fixed. I didn't know about some specific AVR having such strange non-CMOS-like input voltages. All ATTinys I have used (that would be 2313, 25 and 85, mostly) have, AFAIK, normal CMOS inputs and in fact they have more noise margin than some logic gate ICs, ignoring of course proper schmitt trigger ICs which are the best when this is important.
« Last Edit: August 03, 2021, 11:37:08 am by Siwastaja »
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 2577
  • Country: ca
Re: Why do people not like Microchip?
« Reply #147 on: August 03, 2021, 02:33:38 pm »
Last week I did a small PIC project using the PIC16F18313. I only used 2 GPIO pins but I #defined them. I was using I2C so I used the Microchip XC8 built in library function for that. I only have the free version of XC8 and not the fully optimized version. Code size ended up being 385 bytes of flash and 9 bytes of RAM. I don't think you can beat the 75 cent cost of the micro with any other family. At least not in the U.S.

PIC16F15213 must be much cheaper than 75 cents even in single quantities.
 

Offline rcbuck

  • Frequent Contributor
  • **
  • Posts: 283
  • Country: us
Re: Why do people not like Microchip?
« Reply #148 on: August 03, 2021, 04:53:33 pm »
Quote
PIC16F15213 must be much cheaper than 75 cents even in single quantities.
That is true but I did not have the PIC16F15213 in my parts box. 75 cents plus $7.99 Mouser would have made it a $9 part.

Better wording would have been "I don't think you can beat Microchip's low cost 8 pin micros with any other mainstream family." I know there are some 10 cent Chinese chips but they have no support tools.

I have been using PICs since 1995 and have an overall positive view of the parts. However their support and documentation over the last 5 years or so has really gotten bad. One thing you ABSOLUTELY MUST do before using any PIC part is read the errata. Otherwise you will get bitten in the ass. I have never seen any PIC part just "stop working for no reason". When they stop working it is something I have done wrong in my code.

For the last 3 years I have been mainly using STM32 parts except for small 8 pin projects. I did a PIC32 project a couple of years ago but still prefer the STM32 parts for my larger projects.
 

Offline nigelwright7557

  • Frequent Contributor
  • **
  • Posts: 408
  • Country: gb
    • Electronic controls
Re: Why do people not like Microchip?
« Reply #149 on: August 03, 2021, 05:33:29 pm »
I have used PIC's since about 1985.
I have managed hundreds of successful projects since then.

However, MPLAB X is not easy to use.
Harmony while helpful can go very wrong sometimes.
I always keep a backup of my projects on another drive for when Harmony does fail as it quite often does.

The PICKIT's dont work very well. My PICKIT 4 lasted a week ! so went back to PICKIT3 which while runs my code rarely debugs correctly.
Do not buy Chinese PICKIT copies, the one I got was always going wrong.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf