At 09:38 04/12/99 +1000, Des Bromilow wrote:
>I see mention of fuses,

"fuses" are configuration items such as oscillator setup (crystal, RC) or
protection of internal program memory (so that it can't be read after
programming). they are mapped into some addresses (outside of the address
range of the internal program memory) for the programming algorithm, but
are not actually part of the internal program memory; they are programming
time-only items.

>OTP,

One Time Programmable: imagine an eprom without erasing window.

>I know some PICs have address space on the chip...

all pics have their built-in program memory; some as (erasable) eprom, some
as otp eprom (usually you get the same part in both erasable for
development and otp for production), and some newer parts as flash eprom
(only then, no otp version of these). most of the pics can't easily use
external program memory. the only exception to that is with an interpreter
(for eg. forth or basic) in the internal program memory: these then can use
external (serial) eprom for program storage, depending on the interpreter.
but then it's not actually the pic running the program in the external
memory: it's the interpreter. the pic runs the interpreter (in the internal
program memory).

>What would be the best way to get started int PICs.

probably many best ways... :) i found microchip's app notes helpful. get
the book and read a bit around in it. get a 16f84, some means to program
it, and start making it do something.

>With a PIC, does it automatically try to read the serial EEPROM on startup
>(powerup)? or does it attempt to read the OTP code? What is the powerup
>response of an unprogrammed PIC?

pics use their internal program memory; the default (all ones) maps to a
certain code (depending on the type of the chip), which usually does next
to nothing -- at least nothing externally visible. all ports etc. are in a
default state (as given in the data sheets -- mostly all inputs) and all
timers, interrupts and such disabled.

pics don't use serial eproms to initialize, they simply execute the code in
the internal program memory.

>I'm thinking I could have my code in a EEPROM and alter it as I develop my
>skills and designs, and then program it into the OTP once I'm pleased with
>it, and ready to embed it.

the low cost approach is to have a number of eprom types of the chip you're
working with, reprogramming and erasing them. or start better with one of
the flash types (eg. 16f84) -- the core functionality is the same as in all
other midrange types, so you can work out the basics and test your
algorithms (as long as they don't rely on special hardware only found in
bigger types) and you don't have to erase them for reprogramming. speeds
the cycle up.

>I like the idea (and low pin count) of serial EEPROM/comms as used in
>I2C...... Is there a file/description on this to help me understand it?

philips has quite some stuff on their web site (they invented i2c). they
also have a data book with their i2c devices and a good description of i2c
(which all can be found on the web site also). do a search on their site
with "i2c" and up comes all kind of useful stuff, including an article "i2c
and how to use it" or somesuch.

>Will a I2C PIC automatically talk to a PC using this with just the comms
>package on the PC? or does the PIC need additional code to talk to the PC?

neither the pic nor the pc does i2c without special software (and a bit of
hardware on the pc side). but you can use easily normal serial comm on the
pic side, and then you can use normal comm apps on the pc to talk to your
pic. you find various examples about how to implement i2c on a pic in
microchip's app notes.

ge