Have to Vent about PICs

Go To Last Post
44 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've used AVR's for about 7 years, and I admit, some of the peripherals drove me batty the first time I tried to get them working. However, the datasheet was a great resource and everything was very well explained.

I started a new job a few weeks ago and we use PICs there. I try to keep an open mind about things so that I don't become a fanboy without reason. I honestly looked forward to trying out a PIC.

The first PIC I used was a 16 bit one and it had some really nice hardware features actually. Most of the peripherals were pin mappable, so you could put the UARTs, SPI, I2C, on just about any pin. It also has a really useful very low current source (0.55uA) which we used to make capacitve touch switches. Here's the problem...

THE DATASHEET SUCKS!!!!!
Code examples... WRONG!!! FLAT WRONG!!! THEY DONT WORK!!!
Register descriptions.... DO NOT EXIST!!! Ok, I enable IPMI by setting that bit to 1. WTF'ing hel is IPMI???
Peripheral descriptions.... INCOMPLETE!!! Ok, the CTMU can be set to trigger an ADC conversion. Nice, exactly what I need. HOW THE F DO I DO IT!!! I SET THE BITS IN THE CTMU AND THE ADC BUT IT WONT TRIGGER!!!

Ok, so lets move on to the next project, this one uses an older PIC12. Oh crap, our $900 compiler doesn't support it and the boss is out. Thats ok, I can write it in assembly.

WTF!!?? ONE WORKING REGISTER! OMG I need to do half a dozen shifts in and out of RAM to do 16 bit math now!

BANK SWITCHING!!! Oh crap, so now half the time I want to write to a register I'm in the WRONG BANK! Even worse, registers that are used together are in DIFFERENT BANKS so I HAVE to bank switch and waste time CONSTANTLY!

Oh well, next project. Another 16 bit PIC. Oh this is nice, a highly configurable internal clock. Oh shit... highly configurable internal clock = really confusing datasheet. Oh well, I'll make an excel spreadsheet. CRAP... their examples are wrong again. CRAP CRAP its not working, oh, I have to write to the registers in a certain order to adjust the clock frequency. Hmm... whats that order.... (15 min later) oh finally, there it is. What does it say to do.... step 1, perform the unlock high byte routine. step 2, write the new data to the high by... WTF!? WTF IS THE "UNLOCK HIGH BYTE ROUTINE!!!" WTF IS IT? WTF WTF WTF IS IIIIIIITTTTT!!!" Its NOT in the datasheet, its NOT in the compiler documentation. I had to download code example after code example until I found someone that did it WITHOUT using their built in compiler routines.

Next project. Wow, this one uses a lot of UARTs. Not a problem, our compiler can handle it (<--- sarcasm). Our elevendy billion dollar compiler, that supports this chip, DOESN'T HAVE MOST OF THE UART CONTROLLING REGISTERS DEFINED! Not only that, but the registers for enabling interrupts for uarts 3 and 4 WERE DEFINED INCORRECTLY!!!! So I spent an hour first determining WHAT was defined, and then dividing that into defined correctly and incorrectly. I spent the next 90 minutes updating the header files to define the controls for UARTs 3 and 4.

Ohhhh... lets move on to the PIC simulator. Is there some kind of rule that you can't define a static variable initialized to something other than 0? I don't know, but if there is a rule against it, the compiler doesn't generate a warning. What it does generate though is NO DEBUG INFORMATION FOR ANY FUNCTION COMPILED AFTER A STATIC VARIABLE IS INITIALIZED WHEN IT IS DEFINED! For example, say I have 3 .c files in my project. main.c, led.c, and uart.c. Lets say in led.c I have 3 functions and function 2 has a line "static Uint8 state = 1;". Now, lets say that the compiler compiles main first, then led, then uart. I will be able to step through code in main, I will be able to step through code in the first and second functions of led but not the third, and I will NOT be able to step through ANY functions in uart! If I move function 2 in led so that it is at the end of the file, then I can step through all of main and led, but still not uart! If I remove led from the project and then add it back in, it gets compiled last, so I can step through everything.

HOLY CRAP it took me nearly a DAY to figure out that initializing a static variable when it is defined KILLS DEBUG INFO WITHOUT WARNING!

/vent

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gee,

That job posting in Denmark is looking better :)

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Feel better now?

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Feel better now?

Jim


I don't know about you, but I do.

I had a job offer several years ago that used PICs, exclusively. Once they told me that they were exclusively a PIC house, I terminated the interview.

It's a shame, as I really think I'd have easily landed the job, too.

Long Live the AVR!!!

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR datasheets are very well written, you never know how good it is until you read the MCU datasheets of other vendors.

I can always find the info about setting up the register at the end of each AVR section in the datasheet.

Some companies have 1 huge datasheet that covers their entire range of MCUs. You have to figure out what parts of the datasheet are applicable or not. It is not hard to do, but it is confusing.

Atmel Datasheets are much more device specific.

Atmel's execution of their products are second to none; price, performance, datasheets, debug tools, etc... I am not sure how they can consistently do this, there are larger companies with more resources that do a much worse job.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Feel better now?

Jim

Tons. I've tried both, and in the world of 8 bit, AVR definitely puts an ass whoopin on PIC. Never used a 16 bit AVR so I can't comment on that, but I can make a conjecture :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Never used a 16 bit AVR
I don't think any of us have...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kevin123 wrote:
Quote:
Never used a 16 bit AVR
I don't think any of us have...

ehhh, yeah i guess not :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well, those PICs issues look pretty annoying, but at least you're not programming rabbit processors...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think you well summarised the life of a PIC programmer. :( I only had a short stint with the PIC.

The only thing good I can say is the fact that Microchip has provided pin compatible upgrades to their chips (like Atmel, VERY UNLIKE Motorola / Freescale) so one does not have to redesign their board just to be faithfull to a company. :evil:

A certain person, that shall remain nameless :) , wants to use 16 bit PICs for his new project. I'm still not conviced about the wisdom of this. The DSP pics seem nice (linear memory map), not sure about tool's costs or the learning curve.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
The DSP pics seem nice (linear memory map), not sure about tool's costs or the learning curve.
I've used the 16-bit dsPICs for a few projects and did enjoy using them. Microchip's C compiler worked fine and their hardware debugger worked fine. One thing I liked better about MPLAB vs. AVR Studio is MPLABs simulator which is easier to use for input stimulus compared with AVR Studio and also has scope-like graphing of pin outputs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
1. WTF'ing hel is IPMI???
Intelligent Peripheral Management Interface
http://www.intel.com/design/servers/ipmi/pdf/IPMIv2_0_rev1_0_E3_markup.pdf

My guess is you don't need it enabled.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just goes to show you:

SILLY WABBIT PIC'S ARE FOR KIDZZZ!!!"

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello All,

I guess I'm going to throw my response out there. (Keep in mind I'm lacking a lot in reference to the experience of most of the people commenting above.) I've started to work with AVRs in the past year because of doing part time work for a small engineering consulting company when I'm not in school. I've got another year to get me BS/MS in EE.

In my limited experience of micros I haven't been disappointed or too frustrated. I've used several of the micros available for the STK500/STK503 and the ap notes, datasheets, etc have been all I need from Atmel. I've only used an AD micro, ADuC814, at my last summer's job and an MSP430 from TI in my class at school, so my micro experience is certainly limited.

In playing the devil's advocate, there has to be some reason that people use PICs. Do they have any benefit? (I realize it might be hard to find someone to respond in an AVR forum.) If PICs are that difficult and AVRs that great, why aren't they ceasing to exist and everyone converting to AVRs? I've never used a PIC, but I have friends who have used them and subsequently talked them up. I'm interested in this discussion and would be interested in someone laying out the PROs vs CONs of AVRs and PICs. If possible try an open mind with bias aside.

Alan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've used both AVRs and PICs (as well as lots of other MCUs).

Although the AVR architecture is nicer in many ways, I prefer PICs. There is a much wider range of devices and they are much easier to obtain - I can even buy them direct from Microchip if I can't get a device here in the UK. Microchip support is much better than that from Atmel, both via their forums and their customer support people. Microchip tools are better, and they provide free versions of all their compilers. Getting hold of samples is very easy - I just request them via their web site and I get them two or three days later (they have an arrangement with Digi-Key).

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ams0178 wrote:
In playing the devil's advocate, there has to be some reason that people use PICs. Do they have any benefit? (I realize it might be hard to find someone to respond in an AVR forum.)

I had the same thought as you. If AVR was so superior, why is PIC still around? First off, by no means whatsoever is the PIC a bad design. In my opinion its inferior to the AVR, but does it matter that you only have 1 working register if you're writing in C? Unless you're worried about constant shifts in and out of RAM, not really. To be honest, I don't know how GCC handles it either though, for all I know it only implements one or two registers and still does a lot of shifting. I'd be surprised if it did that though.

However, where PIC beats AVR is in the hobbyist world. As said in the previous post, they're cheaper and easier to get. However, as far as MPSIM goes, I hate it. Half of my interrupts for my PIC24 aren't implemented and I never got my ADC stimulus file working at all. Also, I couldn't change the state of an input pin during simulation so I'd have to set it to output, write to the PORTx register, then set it to an input. Lot of trouble to simulate a pin change (though stimulus should be capable of doing this but after the ADC stimulus refusing to work I didn't waste my time here either).

The PIC is also a much better known name. Most people in college use them for projects because they're generally cheaper and from what I hear, Microchip has a good college marking program. Even though I feel that the AVR MCU is a far better MCU, the PIC has them beat because of their other areas.

Oh yeah, avrfreaks.net whoops forum.microchip.com ass any day and all day.

Most of my PIC experience is with the 16 bit so I don't know if its fair to compare it to the AVR. But if it is fair, the only advantages I've found is that the ADC can be set to take 16 readings before interrupting, the UARTs are quad buffered, and the peripherals can be moved to different pins.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How many "hobbyists" do you suppose there are? Enough to make it worthwhile producing a microcomputer? I wouldn't think so. The reason I jumped ship to AVRs was because of the lack of stack, and the endless bank switching, same as a lot of folks I expect. The bank switching for RAM is one thing, but bank switching for code drove me crazy.
Then again, the PIC has been going since 1973, so that might have a bearing on its popularity.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
they're cheaper and easier to get

What makes them "easier to get"? Also do you have some numbers to back up the claim that similarly specified chips are cheaper?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

In playing the devil's advocate, there has to be some reason that people use PICs.

As John A Brown hints at the existence of either PICs or AVRs is not determined at all by what some hobbyists choose. It is what the big companies decide to buy in series of thousands or millions for their products that matters. Now if you where a firm with say 100 embedded software engineers, and the company has worked with PICs for 20 years, would you change the microcontroller brand as soon as you see something that is allegedly better? No, you wouldn't (or your senior boss would send you looking for a new job real soon). I'm not saying that brands are never changed - I'm saying that there are more inputs than the perceived qualities of the competitors, and that there is a fair amount of inertia.

Corollary: If perceived quality would rule alone, then why is the i86 architectures still around when the 68xxx was so much better? (Not to mention the Digital Equipment Alpha. Sob... :cry: )

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I introduced the AVR where I used to work and it was used in a couple of products. They'd previously used a PIC on one system because it was designed by consultants who preferred it. I even used several AVRs interfaced to a PIC for another product, all on the same PCB. I then used a PIC on another product because I was able to use a lot of code that had already been developed. It all depends on what best fits the application.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PICs have been around alot longer, so I guess that is the reason why some of them still use bank memory.

There are more tools available for PIC from third parties. I recall using a few very nice third party simulators.

Microchip is very generous with free samples, you can not get a free sample from Atmel if your life depended on it.

The free C compiler from microchip is really well done. It had a minimalist approach, and the documentation was very good. There is something to be said about having a large company support their free compiler vs not having a single source of support for GCC compilers.

Performance wise, AVR is better, but it is not a huge difference. I remember reading a document named "The truth" published by microchip, that showed that for most instruction executions, PIC is about the same as AVR.

Maybe 3 years ago it was a close call between chosing PIC vs AVR, but now there is no reason not to use AVR. AVR GCC is mature now and AVR dragon is available as a cheap ICE.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I worked with PICs for over 10 years before jumping into AVRs about a year ago. I think it comes down to what you are familiar with and what the application is.

I never had a problem with the PIC bank switching. It is just a matter of understanding how it works. It can sometimes cause code to be larger. For example, I wrote an application using a PIC 4K part. I used assembly since the CCS complier is not very efficient on the 16F parts as they were not designed for C. Due to the bank switching issue, I used about 95% of the code space. I rewrote it using GCC with an Atmega48 and used about 85% of the code space.

As for tools, I think Microchip has a much better selection of tools. The ICD2 is far superior to the Dragon for debugging. It costs 3 times as much but a couple of hours saved easily offsets the cost difference. And it is impossible to lock a PIC part into an "unusable" state as is easily done with the AVRs and the dragon. Once it is locked, I have to use my STK500 to fix the part. Due to the large number of posts, I would say this is big problem with the AVR parts. I don't know of any other microcontroller that has this issue.

Price is relative. In most cases, the PICs are cheaper but it depends on what you need. Ex, the PIC16F886 is $2.22 and the ATmega88-20 is $3.87 from Mouser. The 886 has 8K flash, 386 RAM, and 256 EEPROM. The ATmega88 has 8K Flash, 1K RAM, and 512 EEPROM. I would say that 90% of the time if you are looking at 8K of flash, that 386 RAM and 256 EEPROM is more than sufficient.

And Microchip has some parts that AVR doesn't even begin to address. The PIC 10F and 12F family of 6 and 8 pin devices in the 50 cent to $1 range where you only need 4-5 I/O is hard to beat. I just completed a project for a 400 MHz PLL clock circuit using a $0.72 PIC12F508. I only needed 3 I/O lines and about 120 bytes of code. Of course you have to program in assembly, but that is no big deal.

I've always been able to find what I needed in the PIC data sheets. Again to make a comparison, the 16F886 data sheet is 288 pages. The ATmega88 data sheet is 376 pages. So the ATmega data sheet may go into more detail. When I started with the ATmega48 I had a few problems understanding timers from the data sheet. But the user forum here has a very good tutorial on the subject. And the Microchip forum has always provided very good support also.

Online tech support from Microchip is top notch. Any trouble ticket that I open is usually answered in a couple of hours. I haven't had a need to use Atmel support so I can't speak as to their efficiency. However, I have seen posts here that it can take days to get a reply from them.

I am happy with the few AVR projects I have developed. And the GCC compiler being free is really nice. The Microchip C compiler is free but only works with their higher end chips. It is GCC based and optimization is turned off after 60 days. But you just simply reinstall it to reactivate everything. I tried the CCS C compiler for PICs but was disappointed with it.

The bottom line is that for future projects I will analyze both the AVR and the PIC and choose the appropriate one for the project at hand.

One other thing --- Smiley, that is a nice article on AVRs that you have started in Nuts & Volts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bphillips wrote:
One other thing --- Smiley, that is a nice article on AVRs that you have started in Nuts & Volts.
Thanks, but I almost missed this nice complement because the thread is miss-titled. It should read August PIC versus AVR Rehash Trash Bash

I'm waiting a bit to start copying and pasting some of my earlier rants since this one seems to be a bit too civil for my tastes, and I can't find my 'PICS SUCK, AVR RULZ' tee shirt.

I am glad to see that all the usual suspects returned after our July PIC versus AVR Rehash Trash Bash I was beginning to think folks were getting weary of this topic, but it is nice to see that everyone has turned out. But this month I hope someone else will hang around till everybody leaves to throw out the bottles and mop up the vomit, I mean, come on guys, it's not MY job is it?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yo, Joe! That was really funny!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Microchip is very generous with free samples, you can not get a free sample from Atmel if your life depended on it.

You can get free samples for most of Atmel's products easily, including their ARM series, but you have to go through an authorized distributor. Just contact your sales rep and ask for samples... My local rep even lended me one of the AT91SAM7S dev boards for a week, no charge. I guess it all depends on your rep and how well you are prepared to lie about future business figures to get what you want. ;)

Quote:
The free C compiler from microchip is really well done. It had a minimalist approach, and the documentation was very good. There is something to be said about having a large company support their free compiler vs not having a single source of support for GCC compilers.

GCC is an open-source project, and as such you can get help directly from the developers if need be. For compiler usage there is a plethora of books and web sites out there dealing specifically with certain flavors of GCC. I think GCC is also one of the most often updated compilers out there, and probably one of the most efficient ones (have not worked a whole lot with avr-gcc though, might be wrong).

Quote:
Performance wise, AVR is better, but it is not a huge difference. I remember reading a document named "The truth" published by microchip, that showed that for most instruction executions, PIC is about the same as AVR.

It's not the length that counts, it's what you do with it... ;) If a PIC has to execute those instructions more often due to misdesigned hardware (only one working register, etc...), then AVR is clearly faster.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Microchip uses gcc for the C30 and C32 compilers. They developed C18 themselves.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

toalan wrote:
The free C compiler from microchip is really well done. It had a minimalist approach, and the documentation was very good. There is something to be said about having a large company support their free compiler vs not having a single source of support for GCC compilers.
Just in, a direct quote from MicroChip Hell:
Quote:
Student Edition/Demo
The Student Edition is free! It has all the features of the full compiler and libraries. After 60 days, the optimizations related to procedural abstraction and to the extended instruction set of the newer PIC18XXXX devices will be disabled. Code compiled after the expiration date will function but may occupy more memory space.
So FREE as in freeforsixtydaysthenyerscrewed.

Quote:
...vs not having a single source of support for GCC compilers
Somebody done been smoking that wacky weed.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The previously compiled code will still work, of course.

If the code needs to be recompiled making some mods to it will fix any problems. Or, a full license can be purchased if the additional features are required; the compiler isn't expensive.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
So FREE as in freeforsixtydaysthenyerscrewed.
Well, more like FREE for 60 days then generated code might have a larger code size. In my limited experience, I didn't notice a significant code size difference with and without the additional optimizations. I could imagine other code bases may experience more of a difference, though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
The previously compiled code will still work, of course.

If the code needs to be recompiled making some mods to it will fix any problems. Or, a full license can be purchased if the additional features are required; the compiler isn't expensive.

Leon

So it is FREE!, REALLY SERIOUSLY NO JOKE FREE!*

Smiley

*For 60 days if you are a student. Then it becomes inexpensive**, but even if you don't pay our code size crippling feature probably won't hurt you much.

**More than you want to pay, but less than we'd like to get.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why is my ICD mk1 no longer supported? IIRC it costed me almost the price of a JTAG Mk2. :(
New version of MPLAP and ZAAAAP you MUST buy ICD Mk2 or use the older version of MPLAB.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try slapping on a voltage supervisor circuit on a PIC that you also want to ICSP (in circuit serial program)-- their ICSP uses up to 13.5V to program. Most micropower voltage supervisors are not specified to take that voltage. This becomes more of a pain when you want your operating voltage to be 3.3V or less.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Why is my ICD mk1 no longer supported?
You MAY be able to get a discounted ICD2 if you call your Microchip rep.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not THAT crazy! :-) I still have MPLAP 5.2 that supports my old modules if I ever need to work on them.

Last time stamp on PIC files are about 4 years old. So all modules are well out of warranty.

Fortunately the AVR modules that followed can be plugged into PIC system, so I don't really intend doing any more with PICs...but as Mr. Bond said "NEVER SAY NEVER"!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
toalan wrote:
The free C compiler from microchip is really well done. It had a minimalist approach, and the documentation was very good. There is something to be said about having a large company support their free compiler vs not having a single source of support for GCC compilers.
Just in, a direct quote from MicroChip Hell:
Quote:
Student Edition/Demo
The Student Edition is free! It has all the features of the full compiler and libraries. After 60 days, the optimizations related to procedural abstraction and to the extended instruction set of the newer PIC18XXXX devices will be disabled. Code compiled after the expiration date will function but may occupy more memory space.
So FREE as in freeforsixtydaysthenyerscrewed.

Quote:
...vs not having a single source of support for GCC compilers
Somebody done been smoking that wacky weed.

Smiley

I just want to clarify my statement, GCC has great support. But the support is from kind hearted people, you can not expect someone who is not getting paid to put in as much effort as someone who is getting paid. Companies like IAR are still around, even after GCC, because of the single point of support that you can depend on.

bphillips brought up a great point; no fuses to screw up with PIC. That is one less potential point of problems. I am sure we all atleast once had problems with fuses getting messed up on AVR, especially the debugwire fuse.

It has been a few years since I touched PIC, but my general feeling was that every aspect of PIC; tools, software, datasheets, etc..., was very well finished, everything pretty much worked like it was supposed to. It was the ideal micro for me to cut my teeth on.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Microchip replaces tools like the ICD 2 free if they ever fail, even if the user blows them up by doing something silly. One doesn't even have to return the faulty unit first.

Customer support really is excellent. On a couple of occasions I've had their engineers phone me back to make sure that the problem has been solved.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Microchip replaces tools like the ICD 2 free if they ever fail, even if the user blows them up by doing something silly. One doesn't even have to return the faulty unit first.
This is one thing that Atmel does not do.

Quote:
Customer support really is excellent. On a couple of occasions I've had their engineers phone me back to make sure that the problem has been solved.
I have had mixed results over the years... depends on who answers the ticket. Out local FAE makes up for any shortcomings of the web/phone support.

Quote:
Code compiled after the expiration date will function but may occupy more memory space.
Try compiling the Microchip USB bootloader as-is and it won't fit in the boot section w/o the optimizations. Also for their Zigbee devices you need that optimization so that you can actually do something besides squeeze the stack in.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

no fuses to screw up with PIC

How would that influence the descision of a professional? I'd expect that mistake to be done repeatedly only by a noob amateur hobbyist, and surely a professional would have the tool to remedy the problem in the unlikely event he'd do the mistake twice?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:

no fuses to screw up with PIC

How would that influence the descision of a professional? I'd expect that mistake to be done repeatedly only by a noob amateur hobbyist, and surely a professional would have the tool to remedy the problem in the unlikely event he'd do the mistake twice?

But anyway, there ARE fuses to screw up with a PIC.
However, one thing Microchip got right was to specify a method of embedding fuse info in the .HEX file.
I've spent far too much time trying to translate AVR fuse info into something meaningful for various manufacturer's(of programming equipment) seemingly random fuse definitions.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Someone finally have the same experience as me!

 

I am similar in that I worked with AVR for 5 years and had a cross over period and a learning curve when I started using the SAMD21 and SAMC21 range. But I have to say, the IDE and integration with their Harmony framework is atrocious! I seem to be able to hard fault my PIC32 part constantly when debugging, but runs fine when not. When I use their bloatware drivers, things work...at first. I started developing my app around one of their interrupt driven timers and the callback function was implemented in the main loop. So my app (based on someone elses) kept loosing time if the app was held up for a couple ms. So instead I wrote my own from scratch. I2C I have found has significant hardware issues and once it crashes, its done. in the end I ended up just bit banging it because that was easier than polling it.

 

They made datasheets for a complete series of components when a general "product family" for my part. The issue is that if you want to have a look at the registers and what they do, they tell you to look at the specific datasheet. So yep, that's fine you get it up, and its like IF REGISTER IS DEFINED, you can do this, IF THIS REGISTER IS DEFINED, you can do this. In the end I need both open on a screen each so i can work out what registers I actually have and what they actually do.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can tell you Atmel is not all sweetness and light. There's plenty of horror stories with Atmel parts - poor doc, defects etc. Every manufacturer has them.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Someone finally have the same experience as me!

 Well, as of 8 10 years ago...

 

Last Edited: Tue. Nov 27, 2018 - 03:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now I finally know why Microchip bought Atmel.  So that they wouldn't have to bring all this PIC "documentation" up to the level of AVR's documentation.  Clients who have figured out how PICs work continue to get their specific variant of the devices in the 16-bit range, and anyone new to the game gets pointed towards the AVRs (and Arduino, if they're lucky).

 

I got my first PIC programmer in 1995 after ten years of dealing with "crash-and-burn" ultraviolet-erased EPROM chips and 8051-based CPUs.  The new-at-the-time flash memory was fantastic, but the PIC instruction set was too primitive to take seriously.    A few years later, and the AVR came along with the same flash memory (and simple DIY parallel-port device-programmers), extended peripherals,  fast pipe-lined architecture, and robust, flexible instruction set.   I tried for many years in the pre-internet days to convert to C language for AVR, but wasn't able to do it until the Arduino system was introduced.  

 

As far as having huge difficulties with the commercial compilers and hardware-development platform IDEs, I avoided all that by never having any money to buy the stuff in the first place.  I could never get a job doing embedded-system programming, because I had "no experience" doing embedded-system programming, despite having done it for ten years.   That's why I love Arduino so much: between all the tutorials on the web, the free IDE, the trouble-free USB/AVRdude interface, and an initial outlay of about $20 USD for a few Nano boards, I2C module boards, and a PC-based USB Logic Analyser, anyone can do near-professional semi-custom embedded-system development without having to be in a corporate environment.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh come on! You could train a chimp to write C. It's hardly rocket science is it??