I require clarifying some basics concepts. These are as follows:
What does "MCU" stand for?
Why are OTP devices preferred over ROM version of PICmicro?
Is it that a PICmicro has either a ROM, EPROM or a Flash Memory to store a
software application instruction?
What is the basic difference between Asynchronous and Synchronous
communication?
I understand that the different program memory are either ROM,RAM,EPROM or
Flash Memory. What type of program memory falls under UV Erasable and OTP
device ?
Can the memory size be increased or decreased according to application
requirement?
What is the Electrical specifications for PICmicro to operate on AC(at what
voltage)?
On Mon, 1 Dec 2003 05:49:47 -0500, Prasad, Satyaprakash (Consultant)
wrote:
::What does "MCU" stand for?
In the case of a PIC Microcontroller, there are other electronic
definitions for the abbreviation.
::Why are OTP devices preferred over ROM version of PICmicro?
OTP are normally used once the code has been finalised for a
commercial product, and where the manufacturer won't need to update
the devices and also to afford a greater protection from someone
stealing the code. Also for production the devices are much cheaper
than the flash ones. All Pics have ROM, I think you meant
EPROM/EEPROM.
::Is it that a PICmicro has either a ROM, EPROM or a Flash Memory to
::store a
::software application instruction?
As far as uC's are concerned ROM is OTP and is often masked IE. the
code is manufactured into the device by the manufacturer (Microchip)
type of memory EPROM is Electrically Programable ROM and Flash or
EEPROM is Electrically Erasable PROM.
::What is the basic difference between Asynchronous and Synchronous
::communication?
Asynchronous communication requires the timing signal to be part of
the data stream and can alter during the communication- your modem
for instance.
Synchronous will have a separate clock line and the data will be sent
at specific times during the clock period.
::I understand that the different program memory are either
::ROM,RAM,EPROM or
::Flash Memory. What type of program memory falls under UV Erasable
::and OTP device ?
EPROM
::Can the memory size be increased or decreased according to
::application requirement?
I'm not sure what you mean on this one, if you have a device that has
4K of program space, but your program only uses 2K then you are fine.
::What is the Electrical specifications for PICmicro to operate on
::AC(at what voltage)?
On this one I have to have an attack of the Olin's and suggest you
read the data sheet. I assume you mean what AC voltage can appear at
the pins. To which the pedantic answer would be it can't, you need to
have DC.
I think to answer that one more helpfully, you need to perhaps give
an example of what you're thinking about.
OK the above answers may explain why I'm still jobless after 18
months.
cdb wrote :
>
> OTP are normally used once the code has been finalised...
> ...and also to afford a greater protection from someone
> stealing the code.
Now, I didn't know that the code protection was different
in the OTP devices ! In what way ?
> Also for production the devices are much cheaper
> than the flash ones. All Pics have ROM, I think you meant
> EPROM/EEPROM.
>
> As far as uC's are concerned ROM is OTP and is often masked IE. the
> code is manufactured into the device by the manufacturer (Microchip)
> type of memory EPROM is Electrically Programable ROM and Flash or
> EEPROM is Electrically Erasable PROM.
ROM : Read Only Memory. Usualy masked-programmed when manufactured.
PROM : Programmable ROM. As in the C parts.
EPROM : Erasable (UV) PROM. As in the JW parts.
EEPROM : Electrically EPROM. Most PICs has some...
Flash : A variant of EEPROM, more or less.
> Asynchronous communication requires the timing signal to be part of
> the data stream and can alter during the communication- your modem
> for instance.
Most commonly, async comm uses start/stop bits to syncronize. Note that
the 8 data bits are actualy sent syncronicly between the start and stop
bits, in a way.
> Synchronous will have a separate clock line and the data will be sent
> at specific times during the clock period.
The "clock" isn't sent at all. Both ends uses some "framing" bytes to
syncronize. During the frame, they are free wheeling using theirs
internal clock.
The biggest diff between the two, is that sync comm is "free wheeling"
for a whole "data block", async just for a single byte.
> OK the above answers may explain why I'm still jobless after 18
> months.
> -----Original Message-----
> From: Jan-Erik Soderholm XA (TN/PAC)
> [EraseMEjan-erik.xa.soderholmspam_OUTTakeThisOuTERICSSON.COM]
> Sent: 01 December 2003 11:51
> To: PICLISTspam_OUTMITVMA.MIT.EDU
> Subject: Re: [PIC]:PIC Fundamentals
>
>
> cdb wrote :
> >
> > OTP are normally used once the code has been finalised...
> ...and also
> > to afford a greater protection from someone stealing the code.
>
> Now, I didn't know that the code protection was different
> in the OTP devices ! In what way ?
>
I've read that some tricks with masking and UV light can be used on the
windowed parts to erase the fuse area without erasing program memory. So OTP
(with no window) is a bit more secure, purely on a physical level.
> > Synchronous will have a separate clock line and the data
> will be sent
> > at specific times during the clock period.
>
> The "clock" isn't sent at all. Both ends uses some "framing" bytes to
> syncronize. During the frame, they are free wheeling using theirs
> internal clock.
To be exact: in an synchronous protocol the clocking information is
somehow send for each data bit, either explicitly (using a separate
line, like in SPI or I2C) or implicity, mixed with the data (like in
manchester). In an asynchronous protocol the clock is not send for each
data bit, instead the bits are sampled relying on some timing (which
must hence be sufficiently the same for sender and receiver).
> > Now, I didn't know that the code protection was different
> > in the OTP devices ! In what way ?
>
> I've read that some tricks with masking and UV light can be
> used on the windowed parts to erase the fuse area without
> erasing program memory. So OTP (with no window) is a bit more
> secure, purely on a physical level.
OK. But I read cdb's post as compairing OTP and Flash devices...
> Hi All,
>
> I require clarifying some basics concepts. These are as follows:
>
I'll add what I can.
> What does "MCU" stand for?
I always assumed "Micro Control Unit", but I could be wrong.
> Why are OTP devices preferred over ROM version of PICmicro?
OTP (one time programmable) is programmable (by you or me) whereas ROM
(read only memory) usually means mask programmed at the factory. Lots of
NRE (non-recurring engineering) costs, and other complications.
> Is it that a PICmicro has either a ROM, EPROM or a Flash Memory to store
a
> software application instruction?
This question doesn't completely make sense, but there are various versions
of PICs that use all these memory types. With the ease of development Flash
is fast taking over the market share.
> What is the basic difference between Asynchronous and Synchronous
> communication?
Asynchronous- literal translation- without sync. Think of two guys in two
light houses with two watches. Between noon and one I set my light to the
value of the first bit, about 12:30 you look out and see if it's a one or
zero- second bit between one and two, you check about 1:30, and so on.
Several hours later you have the information. Of course electronics do it
much faster. >100K times a second is common. Obviously this requires a more
accurate clock the faster you go.
Synchronous- with sync. Same example, but after I set my light, I blow the
foghorn. You here the horn and check the light. the watch is unnecessary.
> I understand that the different program memory are either ROM,RAM,EPROM
or
> Flash Memory. What type of program memory falls under UV Erasable and OTP
> device ?
OTP is a PROM (programmable read only memory), the JW parts (UV erasable)
are considered EPROM (erasable PROM). Functionally the only difference is
the glass window. (in modern devices, once upon a time there were actually
"fuses" that you blew when programming) But to confuse the issue some more
there's also EEPROM (or E2PROM, Electrically erasable PROM) I believe only
one PIC was released that uses that for main memory. But most of them have
some EEPROM on board for storing program information.
> Can the memory size be increased or decreased according to application
> requirement?
Different chips are available with more or less, but the options are
limited. There are a few dozen different parts available with various qty
of ram, rom, eeprom, and peripherals.
> What is the Electrical specifications for PICmicro to operate on AC(at
what
> voltage)?
Uh, PICs don't like AC. The like a nice steady stream of 5V (some go as low
as 2.5V). AC and voltages above about 6V will give it a bad day.
On Mon, 1 Dec 2003 12:51:11 +0100, Jan-Erik Soderholm XA (TN/PAC)
wrote:
::Now, I didn't know that the code protection was different
::in the OTP devices ! In what way ?
By this I meant that you can not use a programmer to override any
protection fuses that may have been set - AFAIK it would be a case of
removing the 'lid' getting the 'handy dandy' microscope out to try
and trace the code.
::ROM : Read Only Memory. Usualy masked-programmed when
::manufactured.
::PROM : Programmable ROM. As in the C parts.
::EPROM : Erasable (UV) PROM. As in the JW parts.
::EEPROM : Electrically EPROM. Most PICs has some...
::Flash : A variant of EEPROM, more or less
I thought that was more or less what I said - it is certainly what I
meant.
On the Asynch.Synch thing, I think we may have a different
interpretation, but mean the same thing.
Synchronous - The a data bit is transmitted at a specific point
during a clock pulse - and normally there is a data line and a clock
line as in SPI, Microwire and IIC transmissions.
Asynch on the other hand (leaving out the gnd line) is often a
minimum of one line, and can be self clocking as well as the framing
method you describe.
> I've read that some tricks with masking and UV light can be
> used on the
> windowed parts to erase the fuse area without erasing program
> memory. So OTP
> (with no window) is a bit more secure, purely on a physical level.
But the dies are the same, so the difference is not more than a
carefully applied piece of sandpaper...
>
> To be exact: in an synchronous protocol the clocking information is
> somehow send for each data bit, either explicitly (using a separate
> line, like in SPI or I2C) or implicity, mixed with the data (like in
> manchester). In an asynchronous protocol the clock is not
> send for each
> data bit, instead the bits are sampled relying on some timing (which
> must hence be sufficiently the same for sender and receiver).
Well, there *was* a reason I suggested in my first
reply to go get some serial communication book. :-)
AFAIK, The IBM/SNA protocol is sync, and uses a "framing"
system, where the receiver is "syncing" at the beginning
of each frame.
Manchester code isn't a "clock" signal at all, is it ?
I thought it was a special coding to get a zero DC level
on the transmission medium, but with no builtin clock info
as such, or ? The syncing/framing has to be done after the
manchester decoding, I think.
As per your entire posting to my questionnaires, everyone has confirmed that
the PIC cannot operate on AC.
If it so please extend your information for Brown Out Reset characteristic
within PICmicro. If PICmicro operates on DC does it really requires one
feature like that?
Regards,
Satya Prakash Prasad.
-----------------------------------------
This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof.
> > Obviously this requires a more
> > accurate clock the faster you go
>
> This is common mistake: required accuracy does not depend on baudrate,
> see many previous threads.
You are, of course, correct. I intended to imply a clock with finer
resolution. In the example a watch was used, clearly a seconds hand isn't
going to cut it at real world speed. :-)
I wrote :
> > ::EPROM : Erasable (UV) PROM. As in the JW parts.
>
> I thought that was more or less what I said - it is certainly what I
> meant.
You said : "EPROM is Electrically Programable ROM", which *might* not
been what you meant, how would I tell...
> On the Asynch.Synch thing, I think we may have a different
> interpretation, but mean the same thing.
>
> Synchronous - The a data bit is transmitted at a specific point
> during a clock pulse - and normally there is a data line and a clock
> line as in SPI, Microwire and IIC transmissions.
Yes, regarding *those* sync comms. But not *other* sync comms (e.g. SNA).
> AFAIK, The IBM/SNA protocol is sync, and uses a "framing"
> system, where the receiver is "syncing" at the beginning
> of each frame.
That protocol is sort of half-way between synchronous and asynchronous.
That pattern is called the sync, it is used to get the clock-recovery
oscillator in phase with the send clock. The data part contains explicit
clock info, except for certain bit patterns, which are modified by 'bit
stuffing' to insert some clock information (but not for each bit).
> Manchester code isn't a "clock" signal at all, is it ?
> I thought it was a special coding to get a zero DC level
> on the transmission medium, but with no builtin clock info
> as such, or ?
It is a way to encode clock and data together in one signal. The zero DC
level is a usefull property, but not the only reason to use manchester.
At 01:13 PM 12/1/2003 +0100, you wrote:
>Manchester code isn't a "clock" signal at all, is it ?
>I thought it was a special coding to get a zero DC level
>on the transmission medium, but with no builtin clock info
>as such, or ? The syncing/framing has to be done after the
>manchester decoding, I think.
It is a coding to get a zero DC level, BUT it also has the benefit of
providing a clock too. The key with synchronous is that there has to be
some kind of clock transmission scheme and if there is not a separate
explicit clock line, then the clock is intermixed with the data through
some line encoding scheme such as Manchester encoding. There are other
line encoding schemes such as RZ or B8ZS or many others that provide a
similar service. The commonality for any line encoding scheme that
provides clock recovery is that there is guaranteed to be some transitions
within a certain time period. A transition is where the receiver's clock
can be synchronized with the transmitters clock, and then usually held over
using a PLL.
> -----Original Message-----
> From: Wouter van Ooijen [spamBeGonewouterSTOPspamEraseMEVOTI.NL]
> Sent: 01 December 2003 12:08
> To: KILLspamPICLISTspamBeGoneMITVMA.MIT.EDU
> Subject: Re: [PIC]:PIC Fundamentals
>
>
> > I've read that some tricks with masking and UV light can be used on
> > the windowed parts to erase the fuse area without erasing program
> > memory. So OTP
> > (with no window) is a bit more secure, purely on a physical level.
>
> But the dies are the same, so the difference is not more than
> a carefully applied piece of sandpaper...
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: http://www.voti.nl
> consultancy, development, PICmicro products
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply
> us! email EraseMElistservEraseMEmitvma.mit.edu with SET PICList DIGEST in the body
>
> As per your entire posting to my questionnaires, everyone has
> confirmed that
> the PIC cannot operate on AC.
>
> If it so please extend your information for Brown Out Reset characteristic
> within PICmicro. If PICmicro operates on DC does it really requires one
> feature like that?
Yes it does. A brown out can be on a dc voltage as well as an ac voltage.
The PIC detects a dip in the supply which then resets the processor. If it
did not have this feature and the supply dipped enough to corrupt the data
and or stack, the PIC would be in an unknown state. Clearly not good.
Jan-Erik Soderholm XA (TN/PAC) wrote:
> Manchester code isn't a "clock" signal at all, is it ?
> I thought it was a special coding to get a zero DC level
> on the transmission medium, but with no builtin clock info
> as such, or ? The syncing/framing has to be done after the
> manchester decoding, I think.
Manchester does have an average DC level of 1/2, which can be useful in some
applications, like radio transmission. However, machester also mixes the
clock and data into a single stream. A manchester stream of any length can
be sent without the need to re-sync. A receiver can infer the bit rate once
both a long and short interval have been seen.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
>What exactly do you do consulting in if you don't know this stuff?
Well I am a Software Consultant for a mid standard firm for a project
ongoing on Foxpro. Out of my self-interest and to compete industry standards
I am trying to update my qualifications with the technology.
>And if this isn't your field, what context did all these questions come up
in?
Everyone has to begin from some point. I am a very hard learner. If my
question annoys you I am sorry for that. But I am dedicated to learn and
update my skill set. I prefer my understanding to be clear at the elementary
level.
Regards,
Satya Prakash Prasad.
-----------------------------------------
This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof.
> I understand that the different program memory are either ROM,RAM,EPROM or
> Flash Memory. What type of program memory falls under UV Erasable and OTP
> device ?
There is a point here that perhaps wasn't described very well in the
previous posts. The PIC is a Harvard architecture device, and as such, has
multiple data busses, and consequently, multiple memories. On the PIC,
there are actually 3 memories, although one is implemented more like an I/O
device.
The PIC program memory is organized by words, whose length depends on the
particular PIC family. The program memory may be CMOS PROM (OTP or 'C'
devices), UV Eraseable PROM ('JW' devices), or FLASH ('F' devices). In
general, you cannot store data in the program memory, other than as literals
which are part of an instruction. (There are ways of doing this but they
are pretty clumsy, partly because the word length is different than the
length of the registers.)
All PICs include some RAM, which Microchip insists on calling "File
Register". RAM is organized by bytes, and in most PIC models, is banked.
Note that unlike a von Neumann machine, instructions cannot be executed from
RAM. Most of the PIC registers are also mapped into the file register
address space.
Some PICs also contain electrically eraseable PROM. This is actually
treated more like an I/O device and is useful for storing parameter or other
nonvolatile data, but it's slow and clumsy compared to the file register
memory.
The program memory is 12, 14, or 16 bits wide, depending on the family. The
file register and EEPROM are 8 bits wide.
> Hi All,
>
> I require clarifying some basics concepts. These are as follows:
>
> What does "MCU" stand for?
Micro controller unit?
> Why are OTP devices preferred over ROM version of PICmicro?
Huh? All PICs have "ROM", OTP devices have, in the past been cheaper, but
with today's flash parts I see little reason going with a part available in
OTP (there are a few reasons, i.e.. USB, really cheap, etc.).
> Is it that a PICmicro has either a ROM, EPROM or a Flash Memory to store a
> software application instruction?
All you described is "ROM", although some PICs can change program memory.
> What is the basic difference between Asynchronous and Synchronous
> communication?
Synchronous transmits a clock, asynchronous does not transmit a clock (each
device has it's own local clock which is put in sync with the other devices
clock, usually on a bit edge).
> I understand that the different program memory are either ROM,RAM,EPROM or
> Flash Memory. What type of program memory falls under UV Erasable and OTP
> device ?
ROM/EPROM. Unless you have a specific reason forget OTP even exists.
> Can the memory size be increased or decreased according to application
> requirement?
With most PICs no. Some PICs (in the 18 series) can address external memory
so they can technically have their memory increased. Generally if you need
more memory you move to a bigger part in the line.
> What is the Electrical specifications for PICmicro to operate on
> AC(at what
> voltage)?
[Jan-Erik]
>>AFAIK, The IBM/SNA protocol is sync, and uses a "framing"
>>system, where the receiver is "syncing" at the beginning
>>of each frame.
>
>
[Wouter van Ooijen replied]
> That protocol is sort of half-way between synchronous and asynchronous.
> That pattern is called the sync, it is used to get the clock-recovery
> oscillator in phase with the send clock. The data part contains explicit
> clock info, except for certain bit patterns, which are modified by 'bit
> stuffing' to insert some clock information (but not for each bit).
SDLC/HDLC - the real subject of this conversation - is a synchronous
protocol! Because the protocol is bit- (not character-) oriented it uses
flags (of 6 consecutive '1' bits) to mark begin and end of frames (there
can be any number of data-bits between two flags). Bit stuffing (a
zero-bit after 5 consecutive 1-bits) is required to distinguish 'data'
from 'flag' bit patterns.
BTW SNA is much more than than a datalink protocol!
Regards, Rob
--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/
On Mon, Dec 01, 2003 at 05:49:47AM -0500, Prasad, Satyaprakash (Consultant) wrote: {Quote hidden}
> Hi All,
>
> I require clarifying some basics concepts. These are as follows:
>
> What does "MCU" stand for?
> Why are OTP devices preferred over ROM version of PICmicro?
> Is it that a PICmicro has either a ROM, EPROM or a Flash Memory to store a
> software application instruction?
> What is the basic difference between Asynchronous and Synchronous
> communication?
> I understand that the different program memory are either ROM,RAM,EPROM or
> Flash Memory. What type of program memory falls under UV Erasable and OTP
> device ?
> Can the memory size be increased or decreased according to application
> requirement?
> What is the Electrical specifications for PICmicro to operate on AC(at what
> voltage)?
>
> Thanks in advance.
> Regards,
> Satya Prakash Prasad
>
Wow, if that's not a homework assignment for an Intro to
Microcontrollers class, I don't know what is...
> On the Microchip BBS, I saw a statement that the code protect fuse
> is covered by a metalization layer which prevents UV from erasing it.
Yes for some types, no for others. IIRC there is a document somewhere
that states for which this (metal shield) is indeed the case. For the
others it is just a 'fatter' eprom cell that will erase (much) slower.
But with the flash PICs now all that eprom bullshit is almost history :)
>
> > What does "MCU" stand for?
>
> I always assumed "Micro Control Unit", but I could be wrong.
>
Both answers were right, really. Now that microcontrollers are "popular",
"microcontroller unit" is probably what one is referring to. Originally, "MCU" stood for
"microcomputer unit" which simply meant a microprocessor (MPU) with memory.
I believe those definitions are in a set of Motorola 8 -bit microwhatever data books I
got 15 yrs ago. They're stored away. That year they were brown, my last set of Mot
books were blue. Who cares? Remember the 6809E and friends?
mitvma.mit.edu with SET PICList DIGEST in the body
