AVR & Automation
2008-06-13 by mooodij
Yahoo Groups archive
Index last updated: 2026-04-28 22:41 UTC
Thread
2008-06-13 by mooodij
Its more than a year that Im using AVRs in order to use them in my projects. But now Im in doubt are they really suitable & comfortable for automation projects??? are they really trustable for this purpose??? Ill be gratify if somebody do me a favor & guide me about these .
2008-06-16 by Enki
It's more than seven years I'm using Atmel AVR in automation projects without any problems. Mark Jordan
On 13 Jun 2008 at 11:11, mooodij wrote: > Its more than a year that Im using AVRs in order to use them in my > projects. > But now Im in doubt are they really suitable & comfortable for > automation projects??? > are they really trustable for this purpose??? > Ill be gratify if somebody do me a favor & guide me about these . > > > ------------------------------------ > > Yahoo! Groups Links > > >
2008-06-16 by Philippe Habib
I'm really curious about what it is that gives you doubts. Could you explain what it is that leads you to question using the AVRs?
-----Original Message----- From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf Of mooodij Sent: Friday, June 13, 2008 4:11 AM To: AVR-Chat@yahoogroups.com Subject: [AVR-Chat] AVR & Automation Its more than a year that Im using AVRs in order to use them in my projects. But now Im in doubt are they really suitable & comfortable for automation projects??? are they really trustable for this purpose??? Ill be gratify if somebody do me a favor & guide me about these .
2008-06-16 by John Samperi
At 02:48 AM 17/06/2008, you wrote: >I'm really curious about what it is that gives you doubts. He works for Microchip??? Regards John Samperi ******************************************************** Ampertronics Pty. Ltd. 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA Tel. (02) 9674-6495 Fax (02) 9674-8745 Email: john@ampertronics.com.au Website http://www.ampertronics.com.au *Electronic Design * Custom Products * Contract Assembly ********************************************************
2008-06-16 by Philippe Habib
I'll admit that I mostly use PICs and my only use of the AVR was due to a client requirement. That said, I didn't find any real reasons to hugely favor one over the other. The AVR feature set on the part I used is pretty much available on a PIC with small differences. Price was about the same. It was just a matter of learning a new set of quirks to get it all to do what I wanted. So when I hear that a part isn't suitable for doing X, I have to wonder what the thought process of the person is.
On Jun 16, 2008, at 1:17 PM, John Samperi wrote: > At 02:48 AM 17/06/2008, you wrote: >> I'm really curious about what it is that gives you doubts. > > He works for Microchip??? > > > Regards > > John Samperi > > ******************************************************** > Ampertronics Pty. Ltd. > 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA > Tel. (02) 9674-6495 Fax (02) 9674-8745 > Email: john@ampertronics.com.au > Website http://www.ampertronics.com.au > *Electronic Design * Custom Products * Contract Assembly > ******************************************************** > > > ------------------------------------ > > Yahoo! Groups Links > > >
2008-06-16 by John Samperi
At 07:32 AM 17/06/2008, you wrote: >The AVR feature set on the part >I used is pretty much available on a PIC with small differences. Like a memory map that looks like Swiss cheese for the Pic? :-) And if it were made of Swiss cheese would not be enough for a mouse. Lets see 16F876 vs a Mega88...they both run at 20MHz...except that the PIC has a div by 4 in the clock cct. Pic has <400bytes of fragmented ram, the m88 has 1K of linear ram. Pic from $7-$9 At Digikey for a pdip, m88 at about half that.... I think I would stick with a M88, but I'm biased :-) Regards John Samperi ******************************************************** Ampertronics Pty. Ltd. 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA Tel. (02) 9674-6495 Fax (02) 9674-8745 Email: john@ampertronics.com.au Website http://www.ampertronics.com.au *Electronic Design * Custom Products * Contract Assembly ********************************************************
2008-06-16 by Roy E. Burrage
Cost of tools - AVRs cost significantly less to get started, including a development board, than the PICs any day ... and this is for commercially available, high quality development tools. Clock cycles per instruction cycle - not a big hairy deal at high frequencies and slow machine operation but can be significant when trying to conserve power by using lower frequencies. Paginated memory - used to be a bigger issue prior to the 18 series, not so much now. Instruction set - we eventually must make a decision to either have a smaller instruction set to remember with larger code size because of it or to have a larger and more powerful instruction set for smaller code. Also see above comment about instruction cycles at lower clock frequencies. This may not be an issue when using high level languages, but all we use here is assembler. Peripherals - the greater number of peripherals available on most chip versions is a significant factor when standardizing on several models to keep in stock. Availability - we've never had a problem with availability of AVRs. PICs are another story. Obsolescence - when Atmel obsoletes a part they always have a model that will plug into the same hole, perhaps with some minor changes to the code. Microchip has not been so kind. Hardware - PICs have several gotchas that aren't obvious where the AVRs have always been more straight forward. Using an external crystal comes immediately to mind. I spoke at length about sunny beaches on more than one occasion trying to get the oscillator working with our first PIC project. I could opine about the experience level of AVR versus PIC users and how I've told several people over the years that when they want to get serious about microcontrollers they need to concentrate on AVRs (right Aaron?), but that might start a religious war. The PIC user groups also seem to be more forgiving of those who would borrow, or share, store boughten code and programming tools from one another, tools that others have developed and offer for sale in order to support their nasty habits ... like feeding their families. Just my $0.022 ... REB Philippe Habib wrote:
> I'll admit that I mostly use PICs and my only use of the AVR was due > to a client requirement. That said, I didn't find any real reasons > to hugely favor one over the other. The AVR feature set on the part > I used is pretty much available on a PIC with small differences. > Price was about the same. It was just a matter of learning a new set > of quirks to get it all to do what I wanted. So when I hear that a > part isn't suitable for doing X, I have to wonder what the thought > process of the person is. > > > On Jun 16, 2008, at 1:17 PM, John Samperi wrote: > > >> At 02:48 AM 17/06/2008, you wrote: >> >>> I'm really curious about what it is that gives you doubts. >>> >> He works for Microchip??? >> >> >> Regards >> >> John Samperi >
2008-06-17 by Jim Ronald
Also, the open source community has embraced the AVR, including compilers, libraries, programming hardware and software and many projects.
----- Original Message ----- From: Roy E. Burrage To: AVR-Chat@yahoogroups.com Sent: Monday, June 16, 2008 6:56 PM Subject: Re: [AVR-Chat] AVR & Automation Cost of tools - AVRs cost significantly less to get started, including a development board, than the PICs any day ... and this is for commercially available, high quality development tools. Clock cycles per instruction cycle - not a big hairy deal at high frequencies and slow machine operation but can be significant when trying to conserve power by using lower frequencies. Paginated memory - used to be a bigger issue prior to the 18 series, not so much now. Instruction set - we eventually must make a decision to either have a smaller instruction set to remember with larger code size because of it or to have a larger and more powerful instruction set for smaller code. Also see above comment about instruction cycles at lower clock frequencies. This may not be an issue when using high level languages, but all we use here is assembler. Peripherals - the greater number of peripherals available on most chip versions is a significant factor when standardizing on several models to keep in stock. Availability - we've never had a problem with availability of AVRs. PICs are another story. Obsolescence - when Atmel obsoletes a part they always have a model that will plug into the same hole, perhaps with some minor changes to the code. Microchip has not been so kind. Hardware - PICs have several gotchas that aren't obvious where the AVRs have always been more straight forward. Using an external crystal comes immediately to mind. I spoke at length about sunny beaches on more than one occasion trying to get the oscillator working with our first PIC project. I could opine about the experience level of AVR versus PIC users and how I've told several people over the years that when they want to get serious about microcontrollers they need to concentrate on AVRs (right Aaron?), but that might start a religious war. The PIC user groups also seem to be more forgiving of those who would borrow, or share, store boughten code and programming tools from one another, tools that others have developed and offer for sale in order to support their nasty habits ... like feeding their families. Just my $0.022 ... REB Philippe Habib wrote: > I'll admit that I mostly use PICs and my only use of the AVR was due > to a client requirement. That said, I didn't find any real reasons > to hugely favor one over the other. The AVR feature set on the part > I used is pretty much available on a PIC with small differences. > Price was about the same. It was just a matter of learning a new set > of quirks to get it all to do what I wanted. So when I hear that a > part isn't suitable for doing X, I have to wonder what the thought > process of the person is. > > > On Jun 16, 2008, at 1:17 PM, John Samperi wrote: > > >> At 02:48 AM 17/06/2008, you wrote: >> >>> I'm really curious about what it is that gives you doubts. >>> >> He works for Microchip??? >> >> >> Regards >> >> John Samperi > [Non-text portions of this message have been removed]
2008-06-18 by Philippe Habib
I can't argue with anything you're saying. If I were making a rational choice of processors purely on the merits, I'd go AVR. I work mostly with PICs because my clients mostly have used them in the past and want to stick with what they know and for the most part, people like to make use of the large amount of code I can re-use instead of paying me to rewrite it for a new compiler and micro. The memory map on PICs isn't as bad as it used to be, and using a high level language I'm pretty much isolated from it anyway.
-----Original Message----- From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf Of John Samperi Sent: Monday, June 16, 2008 3:16 PM To: AVR-Chat@yahoogroups.com Subject: Re: [AVR-Chat] AVR & Automation At 07:32 AM 17/06/2008, you wrote: >The AVR feature set on the part >I used is pretty much available on a PIC with small differences. Like a memory map that looks like Swiss cheese for the Pic? :-) And if it were made of Swiss cheese would not be enough for a mouse. Lets see 16F876 vs a Mega88...they both run at 20MHz...except that the PIC has a div by 4 in the clock cct. Pic has <400bytes of fragmented ram, the m88 has 1K of linear ram. Pic from $7-$9 At Digikey for a pdip, m88 at about half that.... I think I would stick with a M88, but I'm biased :-) Regards John Samperi ******************************************************** Ampertronics Pty. Ltd. 11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA Tel. (02) 9674-6495 Fax (02) 9674-8745 Email: john@ampertronics.com.au Website http://www.ampertronics.com.au *Electronic Design * Custom Products * Contract Assembly ******************************************************** ------------------------------------ Yahoo! Groups Links No virus found in this incoming message. Checked by AVG. Version: 8.0.100 / Virus Database: 270.3.0/1505 - Release Date: 6/16/2008 7:20 AM