converting evangelical PIC fans to Atmel

Go To Last Post
141 posts / 0 new

Pages

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

Something that will put off PIC users is the lack of a modern AVR IDE. Microchip has released a beta version of their MPLAB-X IDE, whilst Atmel is taking an inordinate amount of time to develop their new IDE. Microchip has gone for NetBeans, which is much slicker than Eclipse and has many features which are lacking in the latter. It's not as good as Rowley CrossWorks, but I quite like it.

Leon Heller G1HSM

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

Quote:

whilst Atmel is taking an inordinate amount of time to develop their new IDE

A little over a year apparently. Is that "inordinate"? And if "vunneland" hadn't made the post, so no one here knew it was in developmnent, then it just "appeared" would that have been better or worse? At least his post promoted debate for suggestions to be made as to what would be important for it to contain.

By the way Leon, have you used Code::Blocks? To answer a question here I downloaded it the other day to one of my Linux VM's and I must say I thought it was the right balance between complexity and ease of use. I'd be interested to know how you think it compares with Rowley, Eclipse and Netbeans.

Cliff

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

I've heard it's pretty good. I'll try it out.

I just downloaded it and tried it on a simple gcc console program. It seems quite good but I don't think it's as suitable for embedded work as the Rowley IDE, NetBeans or Eclipse. It is noticeably faster than the Java-based NetBeans and Eclipse.

Leon Heller G1HSM

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

Imagecraft version 8 just released ships using codeblocks

Imagecraft compiler user

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

What do you think of it?

I've been using PFE for many years as a general Windows text editor, I think I'll ditch it in favour of Code::Blocks.

Leon Heller G1HSM

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

I can create a project, add my existing files to it and they compile. It seems there could be a script or something to cvt a v7 .prj file to a v8 .cvp file but I'm an engineer/applicationprogrammer, not a tools maintainer guy. All the rest of the stuff looks 'powerful'. I was happy using the CUA style windows editor in the old version, and the compiler didn't change/improve/bugfix, so I'm still maintaining with the v7 version.... guess I'm not a good early adopter.....

Imagecraft compiler user

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

Kartman wrote:
Quote:
Yeah, and then they give the files names like "70204A.pdf" so that when you download the whole package you have no idea what you've got without opening or renaming the files.

Is Atmel any better?


If it's one file I can rename it when I save it. If it's a whole batch of files I don't get that option. They should at least provide a little navigation app or html page.

Not the end of the world, certainly, but stupid and user-unfriendly nonetheless.

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

Quote:
it is more like engineer ignorance.

engineers tend to view the world in a black/white fashion. they tend to have trouble understanding the complexity of the real world.

I would say engineer practicality. And I totally disagree that they see the world in black and white. If this were true, then there would never be any innovation. But they do need their datasheets to be black and white. Grey areas in a datasheet would make it useless.

Regards,
Steve A.

The Board helps those that help themselves.

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

Maybe Milli has a point....

http://www.seek.com.au/Job/embed...

Both me and a co-worker thought this was a bit silly - especially that they emphasise the importance of STM32 experience over DSP. I commented that the only specific experience I needed with STM32 was to read the datasheet (user manual) whereas the DSP experience might be a bit more involved...
I should put my hand up for the job - I got my STM32 Discovery board last week, so I can claim legitimate experience. I might be a bit pushed on the DSP though...

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

clearsky1494 wrote:
Hi, Does anyone have some good idea of convincing hardcore PIC fans to Atmel?

With the recent price, and availability problems I'm becoming slowly a PIC/ARM user. Although I was an Atmel fan. And about two years ago I convinced my teacher to start using AVR-s, now he's in trouble, so now I'm a bit more carefull about convincing anybody. Especially because I'm not convinced about AVR either. Good for hobby maybe, but otherwise just an overpriced, outdated, unavailable, poor supported piece of crap(compared to the competitors). But it is easy to use - no doubt there -, if you are able to manage to buy one. And the old AVRs were pretty undestroyable.

Now compare these numbers:
AT90CAN128: (surprisingly :evil: currently unavailable)
1+ € 17,69
10+ € 9,46

LPC1768: (almost 900 available)
1+ € 8,26
10+ € 6,40

and it's a 100 MHz Cortex-M3 with 512 kB Flash, double CAN, Ethernet, USB etc. for less than the half price in small quantity (I'm basically hobbyist), but cheaper also for bigger quantities.

So I will start convince anybody again, if I see ALL Xmegas available in huge quantities and WITHOUT ANY ERRATA.

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

millwood wrote:

PIC has the advantage of a much larger code base and is extremely rugged - a key consideration for industrial applications.

What do you mean by "extremely rugged"? Got an example?

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

Mike B wrote:

• Up to 66 MHz core clock rate
• 2 General Purpose crystal oscillators, 0.4MHz-20MHz
• 2 Phase-Locked-Loops, 80-240 MHz
• 32 KHz low power oscillator (OSC32K)
• Integrated 115KHz RC Oscillator (RCSYS)
• 8 MHz / 1 MHz integrated RC oscillator (RC8M)
• 120 MHz integrated RC oscillator (RC120M)

Do we know whats the maximum speed of the PWM (for 8bit for example)? I read in the datasheet that the maximum Generic clock for PWM is 133MHz. That would be around 520 kHz for 8 bit PWM. And it seems that there are only dividers after that clock input.
Am I reading it correctly?

BTW I wouldn't bet on the availability of AVR controllers.

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

millwood wrote:
one of the things that I liked to show is the "arc test": put a welding gun next to a mcu, let it discharge and see if the code continues to execute correctly.

most CMx chips will execute to about 10cm;
most AVRs to about 5cm;
most PIC10/12/16f somewhere between 3 - 5cm;
most PIC otp chips will execute between 1 - cm;
no mcus that I have tried will execute within 1cm.

Do you have a link to this?

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

millwood wrote:
one of the things that I liked to show is the "arc test": put a welding gun next to a mcu, let it discharge and see if the code continues to execute correctly.

most CMx chips will execute to about 10cm;
most AVRs to about 5cm;
most PIC10/12/16f somewhere between 3 - 5cm;
most PIC otp chips will execute between 1 - cm;
no mcus that I have tried will execute within 1cm.

stuff like this has no value in a nice home / lab environment. but if you are designing for an industrial environment, or for a nuclear hardened applications, your choices of mcus are severely limited to some ancient ones.

that's why you will see many "ancient" chips in brand new designs for the military. and high-reliability embedded computing is so important for larger chips in those applications.

Thats an interesting way to test. Well I haven't used PICs so far, but I found that AVRs are pretty impressive when it comes to ruggedness. I thought many times, that I killed my AVR, but nothing happend it just kept working.
I guess that during the last 5 year since I work with AVRs I killed only a few, and I was a very beginner back then, when I started.

How about the 16 bit PICs and the dsPICs? Do you have experience with them regarding ruggedness?
I would like to build a dimmable constant current supply for LEDs.
And the high speed PWM type PICs are one of the candiates. The other one is so far the TI piccolo series,for example the TMS320F28026.
I just have to find out what is the toolchain for both of them, and wich one is cheaper, and easier to use: including programmer, debugger, development environment.

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

For the 16-bit PICs (dsPIC and PIC24) the MPLAB software and C30 compiler are free, you just need a PICkit 3 for debugging and programming - about $50. Low-cost demo boards are available.

Leon Heller G1HSM

Last Edited: Sun. Jan 9, 2011 - 04:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

millwood wrote:
one of the things that I liked to show is the "arc test": put a welding gun next to a mcu, let it discharge and see if the code continues to execute correctly.

most CMx chips will execute to about 10cm;
most AVRs to about 5cm;
most PIC10/12/16f somewhere between 3 - 5cm;
most PIC otp chips will execute between 1 - cm;
no mcus that I have tried will execute within 1cm.

Do you have a link to this?

millwood wrote:
Quote:
Do you have a link to this?

no, sorry.

I do have a few links to a bridge for sale in Brooklyn. would you like to buy it?

OMG! Are you really admitting that you made it all up? Amazing.

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

millwood wrote:
smileymicros wrote:
OMG! Are you really admitting that you made it all up? Amazing.
what rationale persons would equate having a link to authenticity?
One with sufficient skills to analyze the data on the site? If you send me to a UFO site it would only confirm what I think about the data you posted. If you send me to a site that has information that seems well thought out and presents the experimental method, then I might be inclined to accept the data. In the Banning Millwood thread folks are accusing you of making things up. I have no way of knowing if they are simple conspiring to harm you or if they have seen you do this. So it would be really helpful to see some links to the source of this material so that I'd have the opportunity to verify that those guys are wrong about you and that the data is real.

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

millwood wrote:
smileymicros wrote:
One with sufficient skills to analyze the data on the site?

so Einstein and his relativity must have been wrong because apparently there was no link to verify his theory back then.

the same can be said about Newton or other scientists too.

I guess since we cannot find a link with a picture of you in your underwear, we, as "men of science", must conclude that you cannot possibly have worn underwear.

actually, we shouldn't be talking to you because you couldn't send us a link confirming the existence of "smilymicros".

your assertion has to be one of the most absurd thing I have heard this year.

keep it up and you may win the grand prize, in 11 months, :)

These were all published and other folks had the opportunity to repeat the results. This seems not to be the case with your data. And why do you keep saying 'we', it is getting down right spooky.

millwood wrote:
smileymicros wrote:
millwood wrote:
what rationale persons would equate having a link to authenticity?
One with sufficient skills to analyze the data on the site?

smileymicros wrote:
In the unlikely event that anyone would take this seriously, all they have to do is click on our names to see our posts and judge for themselves upon whom arguments are wasted.

Smiley

I would propose that anyone person wishing to judge for themselves should just look at the above exchange, :)

Hmmm... I must need more tea, that doesn't make any sense what so ever.

But back to your experimental data that seems to put the AVR in a bad light, did you admit to making it all up? If not, do you have anything to support your assertions?

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

millwood wrote:
one of the things that I liked to show is the "arc test": put a welding gun next to a mcu, let it discharge and see if the code continues to execute correctly.

most CMx chips will execute to about 10cm;
most AVRs to about 5cm;
most PIC10/12/16f somewhere between 3 - 5cm;
most PIC otp chips will execute between 1 - cm;
no mcus that I have tried will execute within 1cm.

stuff like this has no value in a nice home / lab environment. but if you are designing for an industrial environment, or for a nuclear hardened applications, your choices of mcus are severely limited to some ancient ones.

that's why you will see many "ancient" chips in brand new designs for the military. and high-reliability embedded computing is so important for larger chips in those applications.

All the hand waving seems to be working, so back to the question: did you make this up as would seem to be implied by the bridge sales statement or do you have any way to verify that this data is real and accurate?

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

EMI tolerance can be affected as much by board design & layout as chip design, so I'd hardly call your "tests" authoritative on "ruggedness". I'll add to that, that I've done a few re-designs [at a customers request] over the years moving away from a PIC design, because the MCU was failing due to EMI. I won't claim that the AVR itself was any better or worse, but the end design based on an AVR was more stable than the legacy PIC design. [customers assessment, not mine] - As I have no empirical evidence that can be peer reviewed here, this is a just a statement to counter Millwood's assertion, and not meant to be taken as an absolute proof of anything.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Glitch, what are some things that had to be done to the PCB design to make it work better ?

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

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

Quote:
one of the things that I liked to show is the "arc test": put a welding gun next to a mcu, let it discharge...etc

More details of test set up please. Pictures would be nice!
Quote:
"arc test"
arc from gun to where?
Quote:
.. I liked to show ....

To whom? Has this been independently verified by others?

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

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

millwood wrote:

glitch wrote:

the end design based on an AVR was more stable than the legacy PIC design.

well, since you couldn't provide a link, it couldn't have been true.

Again, you love to remove the context of the statement to twist it to what you like. My statement was set up, and concluded with the fact that it was my experience on a couple of projects, and that it may not be directly attributable to the AVR itself.

I'll clarify more, as board design was most certainly a factor in hardening the overall design. I cannot say if a PIC design with the same modifications/improvements would have been as stable or not, as that work was never done. [this design was bout improving stability, and bringing in new functionality, not about trying to determine what MCU was more EMI resistant.]

Your statement, on the other hand, was presented as absolute fact that one device is more rugged than the other. Had you predicated your statement with it being your opinion/experience then the discussion that followed would not have happened.

[edit] seems that millwoods posts have been stripped out, making my, and others, comments a bit confusing. Moderators please feel free to delete any of my posts that stem from millwoods comments, in order to try and keep this thread coherent.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

glitch wrote:
[edit] seems that millwoods posts have been stripped out, making my, and others, comments a bit confusing. Moderators please feel free to delete any of my posts that stem from millwoods comments, in order to try and keep this thread coherent.
I sort of felt this was coming so I made sure to quote him for posterity.

It is good to know that a thread can be stripped like this. I wonder if the stripper would comment on this long overdue bit of moderation?

Smiley

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

he did, check out the banning millwood thread in the site forum.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

we have strippers here? :shock:

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

dksmall wrote:
we have strippers here? :shock:
Yeah, haven't you seen my YouTube video? Wathc it and you'll never eat salami again.

Smiley

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

The stripper commented here https://www.avrfreaks.net/index.p...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

In terms of reliability, my experience has lead me to believe that PICs are more rugged than AVR. Back in 2005/6 when I was working with both PIC and AVR, I killed maybe a dozen AVRs on the breadboard and only about 2 or 3 PICs. Both were used in similar applications. The whole Fuse issue with AVR makes things worse, often when a fuse screws up on AVR I consider the chip dead as I do not want to spend 15 minutes rewiring my STK500 from serial programming mode to parallel mode and then back.

In a finished product, AVR seems as reliable as any other uC I have worked with.

You may think you are doing the person a world of good by trying to convert them to AVR, but the reality is that you are probably doing them more harm than good. From an 8bit PIC, they can easily move upto a 16bit PIC or even a 32bit PIC, same debugger and same IDE. With AVR the only upgrade path is Xmega, same IDE and same debugger, but personally I think the 16 bit PICs are more attractive and the 32 bit PICs are on a whole other level. Yes you can go with AVR32, but the only commonality with AVR is the $300 MK2 debugger.

To me AVR does not have anything to make it stand out from other uCs in the same price range for my applications. You want outstanding peripherals go with PSOC, you want super modern peripherals go with anything but AVR, you want brutal processing power go with ARM cortex. AVR occupies a middle ground, I can appreciate the middle ground when I was first starting out as it was a warm and fuzzy place.

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

Thread update:

I spent another two months trying to figure out how to make an Atmel uC do what I wanted it too. I finally gave up. I presume PIC would have been just as hard.

Instead, I decided to use an Android tablet to control the medical device I was building. I taught myself Java and Android programming languages, then had to figure out how to use the tablet to interface to USB to control the external devices I was using. I have done so, and though the time I spent learning to do all of that may have equalled the time I would have spent learning AVR products, the skills and knowledge I have acquired has far more vocational and pragmatic value that if I had stuck with Atmel.

That project is nearly finished and I am working on another one where I plan to connect the Android tablet to a microcontroller on a different medical device.

Now I am looking for a microcontroller that I can learn quick and integrate into my next design. I want to be able to learn this in a matter of weeks, not months or years.

As I made clear in earlier posts, I am far more interested in getting a good product out the door soon than becoming an expert in the minutia of Atmel or PIC uC design.

After two years my answer to the thread question remains the same. "How do you get people to switch to Atmel from PIC?" MAKE IT VERY EASY FOR A NOVICE TO LEARN AND USE!

(And don't insult him because he is a novice. Every time I think of Atmel, I remember how I was treated in this thread. If Atmel is no easier to learn than it was two years ago, I will see if PIC is easier to learn - and if their forums are more supportive of non-engineers.)

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

Quote:

MAKE IT VERY EASY FOR A NOVICE TO LEARN AND USE!

I haven't read the whole thread but didn't Arduino do exactly this? It's been a revolution to microcontroller programming and has maybe increased the numbers getting involved ten fold. (OK perhaps an over-estimate but its hugely significant).

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

MarqTwine wrote:
Now I am looking for a microcontroller that I can learn quick and integrate into my next design. I want to be able to learn this in a matter of weeks, not months or years.

Surely that depends on a number of factors. How many microcontroller features do you need? How much performance (higher performance parts tend to be more complicated to use)? How much familiarity with microcontrollers (the more you have, the more you tend to know what you don't know, and how to find it)?

So, any details?

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

MarqTwine wrote:
(And don't insult him because he is a novice. Every time I think of Atmel, I remember how I was treated in this thread. If Atmel is no easier to learn than it was two years ago, I will see if PIC is easier to learn - and if their forums are more supportive of non-engineers.)
You won't get very far with this if you indict an entire forum based on the responses of a few folks trying to piss you off.

To use a forum effectively you have to be willing to ignore the insulting and off topics stuff and use the relevant information.

Avrfreaks is getting better about moderating the chaff, but since that is a labor intensive voluntary effort you can't expect perfection.

I think in this very long thread you will find the good answers too you question. If you require that the crap be filtered for you, I doubt you'll find any microcontroller forum suitable.

Smiley

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

Quote:

If you require that the crap be filtered for you,

Actually I can do that for you if you like? It seems to me that most of what might be considered "insult" in this thread was posted by one person (who's subsequently been banned for the behaviour) so I can just chop those posts out if you like? Without them I'm not sure what else would be considered insulting? On the whole most people here are otherwise happy, helpful souls.

Moderator.

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

I glanced through the first 60 messages or so. Nothing seemed that bad to me. Several posts gave very honest appraisals of pros and cons of different microcontroller families.

IMHO, most 8-bit controllers are fairly easy to program. You will use a low-level register access. There will be a multitude of me-too libraries.

The 32-bit jobs are a lot more complex, but you might have the advantage of just using standard Java and avoiding any intimate knowledge.

I doubt if Einstein could be proficient in Cortex-M# in a fortnight. He could probably get to use a single set of manufacturer's libraries.

Blinking a few lamps and running a few timers is easily done with an Arduino (or mBed)
Running a missile system is better done with proven languages, protocol stacks and libraries.

Choosing an appropriate approach is the first step.

David.

p.s. if messages 61-132 are bad tempered, so be it. I will believe you. You may need to filter the 'better' replies.

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

Um, if the original poster wanted to know how to make his avr do something specific, why did he ask about converting pic users to avr?

(Though we do sometimes jump all over a novice who asks a silly question because he doesn't know any better. Of course, I ask silly unanswerable questions 'cause I don't know any better.)

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

clawson wrote:
It seems to me that most of what might be considered "insult" in this thread was posted by one person (who's subsequently been banned for the behaviour)
For which you guys are to be thanked.

The temperature and odor here really is improving due to your and other moderators efforts.

Thank you.

Smiley

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

Quote:
I want to be able to learn this in a matter of weeks, not months or years.
I want to become an astronaut by next week, I want a quick lesson on how to fly those space shuttle thingies. Richard Branson is recruiting...

Sorry my friend but things take time wether we like it or not!

For heaven's sake you are talking about a "medical device" attached to an Android programmed by someone who says "I taught myself Java and Android programming languages"????

What happens when someone dies because of a hardware or software glitch?

Or do you think people spent YEARS trying to become the best they can in a chosen field just for fun?

Ok, Ok I'm ranting now and probably will need to ban myself but this has made my blood boil first thing in the morning. And I haven't even had any coffee yet!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

The world's population of dolts and fools is increasing rapidly.

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

MarqTwine wrote:
As I made clear in earlier posts, I am far more interested in getting a good product out the door soon than becoming an expert in the minutia of Atmel or PIC uC design.
You do not need to become an expert, just become competent. If you want to design and implement with embedded micros, without understanding them, then I do not see you ever producing a quality product using them, except maybe by accident or luck. In this case just hire someone who is competent to do the work you do not want to do.

If you really do not want to become competent with embedded micros then stick with platforms like the Android tablet which you appear to understand.

Sorry, too me it sounds like you are complaining that you cannot get a free lunch in the embedded world :wink:. Certain classes of medical devices even ones designed and implemented by true experts still require internal review by other experts, special documentation, lockouts, special testing, adherence to any applicable laws and sometimes also outside or government reviews. You probably know if your products fall into these classes or not.

There is no insult intended in this post. Using something you already know, learning the new stuff yourself or hiring outside help just seems to be sound advice to me. Any of these should be able to get you to a good product.

Pages