Re: Beginning PICs

I've used alot of different micros and never had problems with random
resets.
Only reason you might would be bad hardware layout or bad hardware design.

Messing with AVR fuses is trivial. Messing with PIC banking is a huge mess.
Did I mention PIC have very poor support for pointers while AVR was designed
for pointers.
Very important to write an efficient C compiler.

The only free C compilers for the PIC are toys. AVR has free GCC C Compiler
that is highly recognized.

"Wolfgang Mahringer" <yeti201@xxxxxx> wrote in message
news:y1TRe.2$J72.1840268@xxxxxxxxxxxxxxxxxxxxxxxxxx
> Hi Tom,
>
> Thomas Magma schrieb:
>> I'm a fan of the PIC.
>
> Me too :-)
> And I want to throw in 3 more arguments:
> 1) I have never seen more ESD/spikes/bad supply robust micros
> than the PICs, which makes it easier to do applications which
> should *not* reset every now and then.
> Forget that with AVRs. May be the main reason, PICs are
> widely used in automotive areas.
> 2) Programming AVR chips is a mess. Once you muck up the
> fuses, you have to tinker around to repair that.
> *Much* easier with PICs.
> 3) Free C compilers are available for PICs. No need to bother
> with banked RAM.
>
>>>I don't want to start a flame war - but need to ask - which would be a
>>>good solution to begin PIC programming?
>>>This would include not only the chip but the programmer & tools.
>
> I would install one of the free C compilers on top of MPLAB.
> You should also purchase a ICD2 debugger (maybe there are
> DIY projects also). This makes life much easier :-)
>
>>>Kits are good too.
> No need. A bit of breadbord and a soldering iron is all you need.
>
> greetz,
> Wolfgang
>
> --
> From-address is Spam trap
> Use: wolfgang (dot) mahringer (at) sbg (dot) at
>


.

Relevant Pages

  • Re: Moving from 8051 to AVR
    ... This applies to working with the AVR just ... Yes, that was the original argument - although it has now been slightly sidetracked by your claim as to *why* it is good, which was that it means any old PC programmer can then write good embedded code for the chip. ... IAR have plenty of knowledge of C compilers, but they have their own particular way of handling microcontroller functionality that has no place in standard C, such as handling flash memory spaces. ...
    (comp.arch.embedded)
  • Re: C programming on ARM
    ... You can't rely on these things having a consistent pointer size - you should not even rely on the C requirement of a "void *" supporting them all (embedded compilers don't always follow the standards if they conflict with generating good object code for real-world source code). ... Look at the AVR, for example - it has different address spaces for flash and ram data, so the pointers are incompatible. ...
    (comp.arch.embedded)
  • Re: C programming on ARM
    ... But as you say C doesn't map onto these architectures, ... Look at the AVR, for example - it has different address spaces for flash and ram data, so the pointers are ... There are indeed architectures which can't fully support standard C. ... work on standard C compilers. ...
    (comp.arch.embedded)
  • Re: Purchase microcontroller dev. kit
    ... char b; ... Even on compilers which don't support it directly, the way to deal with code like that is clearly explained in user manuals and FAQs. ... The two most sensible families of small microcontroller for beginners or general use are the AVR and the msp430. ... Nothing you write now will be reused significantly in the future, and all embedded code has at least some layers of non-portable code anyway. ...
    (sci.electronics.design)
Loading