On Tue, Jun 28, 2005 at 10:33:26AM -0400, Maarten Hofman wrote:
> Rochester, 28 juni 2005.
> 
> Wow... Only doing PICmicros since May, and already I get a direct
> question from Byron A. Jeff himself... *shivers*. But I do like lists.

You talk about it like it's a big thing. I was just curious.

> 
> > > I started my PIC
> > > adventure in May, and because of Myke Predko's book I started with the
> > > PIC16F84A, but it became clear that was a bad choice in many different
> > > ways.
> > 
> > Care to list?
> 
> In order of importance:

> 1) The PIC16F84A doesn't have an internal oscillator. This makes the
> electronics and especially the prototype more complicated, and eats
> two of your precious pins. Worse: if you later decide to upgrade your
> circuit with the PIC16F628A, you STILL can't use those pins, because
> the resonator is connected to them.

That's one on my list. I wouldn't recommend a part to a newbie that didn't
have the internal oscillator block incorporated.

> 2) I'm pretty sure some people would like their PIC to speak to their
> PC in some way, if just to send a few words of configuration to it.
> Granted, you can connect a RS-232 to a PIC16F84A with a mere 10KOhm
> resistor (though I recommend adding those two diodes as well, just in
> case). However, what you save in hardware, you suffer in software...
> Waiting for start bits, timing the distance right, and certainly
> reducing the speed of your application. With the PIC16F628A you need
> three instructions (as well as a little setup, and an additional
> transistor and resistor, to invert the incoming signal) and all works
> as it should. Note that the entire code to get the PIC16F628A to work
> with RS-232 is listed in its datasheet, so it's not like you have to
> figure things out yourself.

BINGO!!! A bit of setup complexity alleviates a lot of management as your
applications become more complicated. Hardware periperals give a huge
abstraction to the stuff they manage. It's set and forget.

For the USART in particular Fr. McGahee's PICUART tutorial is outstanding
for both learnint about all of the USARTs nuances and for having a drop
in piece of code to run it.

> 3) The PIC16F84A has only 1 KWord of program memory. Now usually I
> would say that is a lot, but my first application already ate over 800
> of those words. The PIC16F628A has 2 KWords, which is much better (and
> still has no paging issues).

The 16F648 and the 16F88 are even better with 4K apiece. But paging
does finally rear its ugly head across the 2K boundary.


> 4) The PIC16F84A costs $4.87, and the PIC16F628A costs $2.24. Now this
> might not seem like much, but it goes against my Dutch nature to pay
> more for less.

Agreed.

> 5) Granted, I used only 36 of the 68 registers in my first
> application, but that was because I knew there were only 68 of them.
> Had I had the 224 registers that the PIC16F628A provides, it would
> have made for a much nicer result.
> 6) My second application used 100 bytes of internal EEPROM memory (and
> the PIC16F84A has only 64 of them)... You might say: yes, but that was
> your second application. But note that the timeframe between the two
> applications was less than a month.

Right. That's another point I always make. Many tutorials approach the 
newbie as if they were going to stay newbies forever. It's OK to start
there. But a tutorial should plan on giving the newbie the skillset to
function as a intermediate developer. That means introducing concepts
that while in the beginning may seem out of place should still be
presented. Olin pounds a perfect example of that in terms of using
relocatable code. It requires some setup in the beginning, but it should
be taught from the beginning.

> I'm sure others might have other reasons, but this was the reason why
> I was very disappointed in my choice for the 16F84A.
> 
> > Agreed on both choices. The 16F88 has virtually every hardware component
> > packed into a single 18 pin part.
> 
> Not only that, but the PIC16F88 allows you to change its own program
> memory. I'm still waiting for that part to arrive, but I see huge
> possibilities for that feature.

Bootloaders are a mainstay of my PIC development. If you are willing to
either give up or share the hardware USART then you can use the sparcfun
bloader. Only takes 255 bytes of code.

I plan on starting with Tato's ploader which you can find here:

http://propic2.com/ploader

It has the advantage of using a software USART as it was developed for the
16F819 which doesn't have a hardware USART. However, I find the protocol
a bit lacking. The key is that it's working code. So it should be too hard
to get ported.

> > You may even want to consider stepping up to 18F family too.
> 
> You're probably right. I''m also curious about the PIC16F688... But
> that is the opposite direction (less pins).
> 
> > That must be frustrating for a newbie. I always recommend using the data
> > sheet and the Family reference manual for the particular part.
> 
> Yes, the datasheets work well. I especially like their example code.

The family reference manual has even more code. It's the reason I suggest
to newbies to learn assembly even if they plan to use a highlevel language.

> As for problems newbies might encounter with the 16F628A compared to
> the 16F84A: I think these issues are very minor (and need to be
> learned anyway) and are insignificant compared to working around the
> limitations of the 16F84A. There are enough samples for the 16F628A
> out there that show how to initialise the ports to enable or disable
> peripherals, and the datasheet isn't that big either (one session in a
> bathtub should get you through it).

I used this dontronics page for 16F84 to 16F628 conversion.

http://www.dontronics.com/cat_hard_micro_pic.html#628spec

BAJ
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist