AVR-Chat

tom,

i'm half way to being converted! by nothing more than the quality of
your post alone! ;-)

the last time i wrote anything substantial (>10 years ago), i went for
delphi instead of VB or VC++, does that make me a PIC or an AVR person?  

now if, i say if, i decide to go with AVR. which chip and tools would
you recommend i start with? assuming that i am not going to stop with
one project...
is the atmega169 a good chip to start with?
is the ATAVRBFLY (butterfly?) a worthy toy to learn with?
should i get the stk500 or are the better alternatives?

could you recommend some good sites/links (beside this one of course)
for me to read up on?

thanks.

--kong


--- In AVR-Chat@yahoogroups.com, Thomas Keller <tkeller1@n...> wrote:
>
> Kong wrote:
> 
> >hi all,
> >foa, newbie here, so pls go easy, if you could ;-)
> >i'm looking at building a weather station. google tells me there are a 
> >few out there based on PIC. someone suggested AVR atmega169 but i'm
put 
> >off by its mlf packaging.
> >i'll need adc, lcd, push buttons, ram/flash to store data history, 
> >serial to PC later. it looks like pic16f877 should be the trick for me 
> >but i figure i should give avr a chance. so i'm here looking at the 
> >whys/why-nots of using AVR to build my weather station.
> >ok. flame away.
> >cheers
> >-ls kong
> >  
> >
> Kong,
> 
>   There is nothing inherently "wrong" ( or "right," for that matter)in 
> choosing a PIC over an AVR, or vice versa.  Among the denizens of this 
> particular mailing list you will, of course, find most promoting and 
> advocating the use of the AVR family (odd thing, that).
> 
>   My take on the ifferences is as follows (not necessarily in any order 
> of importance):
> 
> 1)  efficiency.  The PIC line is a four phase clocking architecture, 
> which means that each instructiins take at LEAST 4 clock cycles to 
> complete.  The AVR is a single-phase clocling architecture.  The 
> majority of instructions cvomplete in a single clock cycle.  This means 
> that, all other things (fabrication technology, etc.) being equal, the 
> PIC will requuire more power per instruciton to get the job done.
> 
> 2) computing architecture.  The PIC has what I personally consider
to be 
> a very clumbsy architectural design.  The registerset usage is not 
> orthogonal,  memroy addressing isn't linear, etc.  While PICs are 
> imminently programmable (witness the massive nuymber of PICs in use,
and 
> the hughe number of hobbyist projects based on PICs), these 
> architecturalk detailsmake them more difficult to program.  Some people 
> seem to see the very small PIC instruction set as a plus.  I do not.
> 
> 3) While there are a large number of different AVR processors avaiable, 
> the PIC line swamps the AVR line in terms of numbers of family members. 
> Moreover,  there can be fairly substantial differences in the way
things 
> are done from one PIC family to another.  Forthe most part, AVRs are 
> AVRs. Within reasonable limits, what works on one AVR will work on 
> another (exluding, of course, the use of hardware resources such as 
> additional peripheral features in the larger, more powerful familky 
> members).
> 
> 4)  While some newer PIC support ISP (In System Programming) without 
> specialized expensive hardware and software, many (most?) do not.  
> Worse, the programming hardware that works for one PIC family may or
may 
> not work for the next more powerful family up the line, which can be a 
> real headache if you discover that theprocessor you chose is lacking in 
> some speed or hardware resource you need, and overlooked in your
initial 
> selection.
> 
> 5)   **ALL** of the software you will need to develop a project on te 
> AVR is freely available, including some stellar quality software 
> directly from Atmel.  For the PIC line, you'll pretty muvch be limitewd 
> to what you can purchase (though not exclusively).  I am not aware
of an 
> implmentation, for example, of gcc for the PIC, but it is out there for 
> the AVR (primary reason for this, I suspect,is the complexity of 
> supporting a wide range of PIC processors, with the massively differing 
> hardware and software requirements).
> 
> 6) back to the programming issiue a moment:  for about $5 (retail cost 
> of components) you can easily construct a programming dongle usable
with 
> ANY AVR processor.  A DB-25M connector, 5 strands of wire, and a means 
> of connecting the wires at the other end to the AVR (I saw oe guy who 
> useed mini-alligator clips - not something I would recommend,
however).  
> I don't know of anyone who can put together a PIC programming platform 
> for $5.
> 
> 7)  Though I haven't searched exhaustively for PIC support, my 
> experience in searching for AVR support onthe World Wide Web has been 
> p[leasantand highly productive.  I wuld be verysurprised to see the 
> level and scope of free web basedsupport for the PIC that I have found 
> for the AVR family.
> 
> 8)  IN terms of raw speed,  AVRs are availablew, in general, up to 20 
> MIPs in performance.  PICs (with the exception of the dsPIC line) are 
> restricted to 10 MIPs, max.  (there is one AVR that offers 48 MIPs 
> performance, but it is a special unit, and I don't consider it fair to 
> include it in this comparison(the AT76USB370, 48 Mhz clock, up to 12 
> Mbps USB 2.0).
> 
> 9)  Finally, and most importantly:  if you go with PIC, you  will not 
> enjoy the benefits and pleasures of dealing with all of us, here in AVR 
> land!!!!
> 
> tom
>