AVR-Chat

No religious war, just a statement of fact.

If you can cite an example of replacing a chip without the replacement 
being both pin and code compatible I'd like to see it.  That hasn't been 
my experience in the past 10 years or so.  Not only do they replace with 
pin and code computability, but they give more functionality for a lower 
price.

Availability...show me one manufacturer who didn't have delivery 
problems over the past 10 years.  I can remember LM7805, LM78xx chips in 
general, being on allocation several years ago.  Is there a more common 
chip on the face of this planet?  The only time I've had a problem with 
AVR availability has been when I had to go to someone other than 
Digi-Key or Mouser for stock and had to order larger quantities than I 
wanted.  The rep was generally able to help there, though.

Tools?  Are we going to complain about free software tools?  Their 
hardware tools are also much more reasonably priced.

Support?  Admittedly, the local manufacturers' rep firm leaves a bit to 
be desired in technical expertise, but the factory guy has been very 
supportive and the local rep has been very willing to bring what ever 
other resources might have been necessary.  Several of them have been, 
for that matter.  I'll state right here and now that DuRant Lewis in the 
Raleigh, NC, office has been nothing but supportive.  He has gone so far 
as to FedEx a replacement ISP to me when I got stupid one night and blew 
mine up...at no charge.

Atmel might be a bit less free with their samples.  However, a real 
company isn't going to balk at paying a couple of bucks for their 
parts.  I've not had a problem getting samples but have had to ask for 
them and explain the application rather than being able to order on-line 
as with Brand X.

The bottom line seems to be that Atmel has focused their products and 
support toward real industrial and commercial applications rather than 
hobby applications.  To be sure, both have a place.  We just have to 
decide where we, as developers, are going to focus our efforts too.


REB



dlc wrote:

>Bah humbug.  Another religious war.  I love the AVR, but I hate Atmel. 
>Their tools are weak, they replace parts (with parts that aren't pin 
>compatable) at whim and sometimes are difficult to even get in the US. 
>However, they are the only choice of cheap micros for Mac or Linux 
>developers, so, I endure.  On the other hand, I hate the PIC 
>architecture but in general love the support that I get from Microchip. 
>  So, as usual, pick your poison.
>
>DLC
>
>Roy E. Burrage wrote:
>  
>
>>Minimum 4 times a day scrub with lye soap and a scrub brush or a 
>>scouring pad, rinse with clorox water.  Do this for a week after each 
>>PIC project and you should be okay.  A saturated solution of NaCl in 
>>water will also do as a substitute for the clorox water and should do 
>>the trick.  With time, after a couple of projects, you'll decide a PIC 
>>isn't worth the pain.
>>
>>I met one of the guys on this list several years ago on another...and he 
>>decided to start with PICs.  I noticed he listed all of his PIC tools 
>>for sale soon after he tried an AVR project.
>>
>>
>>REB
>>
>>
>>
>>David VanHorn wrote:
>>
>>
>>    
>>
>>>On 7/2/07, John Samperi <samperi@ampertronics.com.au> wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>At 07:58 AM 3/07/2007, you wrote:
>>>>  
>>>>
>>>>
>>>>        
>>>>
>>>>>What I'm wrestling with at the moment, is what the SONAR wants though.
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>>It MUST be that darned PIC messing with your mind :-)
>>>>  
>>>>
>>>>        
>>>>
>>>Yup.. Pic rays..
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>>but you CANNOT read the data using the broadcast address..
>>>>>    
>>>>>
>>>>>          
>>>>>
>>>>That makes sense otherwise all units would try and respond at the same
>>>>time and...crash...
>>>>  
>>>>
>>>>        
>>>>
>>>True, but if you have only one device on the bus, then why not let it respond.
>>>The thing that bugs me is that this isn't a documented behaviour, and
>>>their support guys said that what I was doing (including the broadcast
>>>address) ought to be working.
>>>
>>>
>>>
>>>
>>>
>>>      
>>>
>>>>Must admit it is getting interesting though, I tried to compile the test
>>>>code on Brian Dean's website but unfortunately it must have been written
>>>>with an earlier version of WinAVR and the new one does not want to compile.
>>>>  
>>>>
>>>>        
>>>>
>>>The second write of the address seems broken, unless I'm reading it
>>>wrong, he's setting up to not get an ack but testing for the ack in
>>>the result code.
>>>
>>>
>>>      
>>>
>>
>> 
>>Yahoo! Groups Links
>>
>>
>>
>>    
>>
>
>  
>