Is there any functional/performance benefit from using the 44-Pin PLCC
package instead of the 40-Pin DIP package ?
I read through the PDF datasheets available, but would like to get some
feedback from someone who have maybe used both ?
Can the PLCC package be programmed using a normal At89S52 programmer with a
40-PIN ZIF connector , and a DIP to PLCC adapter, or is the code also
I've noticed the PLCC have 44 Pins, with 1 pin on each side marked as
N/C" - so assume the internals will be identical
Can the AT89S51/2 and AT89C51/2 be programmed in either C or Assembly
Language , or can any language be used ? Most of the examples I find on the
net makes use of C which indicates to me that C might be more popular, or
maybe easier than Assembly Language
Any language that has been crafted to the AT89C51/2 will work.
I don't know of a popular or semi-popular or even pretty rare micro
that can't be programmed in its own assembly language. It doesn't
really take that long to write an assembler, usually, so most have
them and they are almost always free to use, as well.
With the 8031/2 CPU core, assemblers and compilers go a LONG WAY back.
My very first MCU design project where I designed everything on my own
(about 1982) was based on an Intel 80C32 (I still have a box of 100 of
them here) and used a freely available "table assembler" developed in
the State of Washington for people developing projects for those with
disabilities. The assembler was free, symbolic, trivial to use and
worked quite well.
At the time, although I was quite familiar with C having used it
working on Unix v6 for years before, C outside of the Unix world was
still a bit of a rare bird then. So a C compiler would have cost me
an arm and a leg and was out of the picture for this hobby app. All
that has changed over the following decade (1980's) and beyond. There
is everything from the 8052 BASIC that Intel released (I have several
incarnations archived, including the original manual in paperback form
here within reach right now) to C to just about anything else. Good
time to be asking for something working on an 8031/2 core processor.
Probably the processor core with the most compiler/interpreter hours
poured into it, now.
Besides BASIC and regarding C, you can try out SDCC at no charge.
Atmel, at its own site here:
provides a ZIP file with include files you can use with SDCC (among
Here's something else:
And that's only a quick shot, quickly found on the web (which you are
perfectly capable of doing, yourself) from someone who has never used
SDCC with the Atmel AT89 series. (I have some of their AT89 chips,
they just never were better than other options in a project by the
time I thought I might want to try them out.)
I have integrated the use of SDCC with SiLabs parts and their IDE,
though. And it works just fine.
Regarding other languages, other than BASIC and C and C++, I'm sure
there will be a post about Forth. Wait for it.
You can use any language you have a translator system for that targets
the 8051 architecture. C is pretty much the universal default choice,
though --- with some assembly added to the mix.
C is generally easier to write in than assembly; except for those cases
where it isn't, e.g. where things like processor status flags or special
opcodes are involved, which C doesn't support directly.
iphone? original TI graphing calculator?
Sometimes the barriers aren't being able to compile the code, but
being able to load it onto the device... if there's an operating
system or an interpreter in the way, it may not be possible to run
native code unless you can find a way to break through that.
Never owned one. But if I extracted the cpu from the environment, I
bet I could program it in assembly.
I didn't mean to suggest that people couldn't prevent the use of
assembly. The old timesharing systems, like HP's 2000F BASIC, didn't
offer assembly either. But the cpu (2116) was easily programmed in
assembly (machine code, at least) if you were sitting there at the
Well, although you seem to have managed to misunderstand me or else
manufacture artificial circumstances to intentionally change my
meaning, I'm hoping no one else went that way with it.
I did not misunderstand you, but raised a point about the ongoing
validity of base assumptions. Not everyone will always be able to
choose to code on evaluation or custom boards, they may instead have
to write for chips wrapped in products by equipment/device vendors who
may or may not be interested in letting third parties write bare metal
applications. If you are always going to be in a position to think of
a "micro" as the actual IC, that's great... but it's not clear that
everyone will consistently be in such a position... something we
perhaps should generally be starting to worry about given the growing
market popularity of "programmable, but only in a sandbox, results
distributable only with approval" devices.
Sorry, Chris, but the "Can the AT89S51/2 and AT89C51/2 be programmed in either C or
Assembly Language , or can any language be used ? Most of the
examples I find on the net makes use of C which indicates to me
that C might be more popular, or maybe easier than Assembly
My answer was appropriate to the question. I have no idea at all why
you care to add artificially manufactured conditions the OP almost
certainly wasn't asking about -- and certainly didn't express.
But feel free. I will leave that to you.
Because while your answer was appropriate to the question, it was
explicitly stated as a general answer rather than one specific to the
context of the question. I commented on areas where that generality
starts to break down in practice for popular programmable
microcomputing devices, if not in literal application to "micros".
Though I would bet that if we look hard enough, we can find a chip
that is by itself limited to processing some interpreted or sandboxed
Should the search fail, I could find a handy OTP device and create
Or I could just point to any microprogrammed machine with immutable
Lodewicus Maas a écrit :
I'm beginner in microcontrollers, but if I can resume my poor
experience, you can combine both.
You could use C for general or complex operations (like : float a=3/4)
and assembly machine where you need a total control of execution time or
an acces to the microcontroller features non easily accessible in C.
I'll assume you meant "layman's terms"...
No. It's not really justified to claim either C or assembly to be "more
powerful" just like that, without specifying what kind of power you're
looking for. The two have different powers in different areas.
Assembly lets you get at every last bit of the machine, whereas C saves
you from having to care about every last bit of the machine all the time.
["Followup-To:" header set to comp.arch.embedded.]
Yes, that is possible, but you have to consider the execution time of a
floating point division on a 8051, it's not a PC with floating point
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
There is no comfort without pain; thus we define salvation through suffering.
You indeed misunderstood him.
EVERY micro can be programmes with assembly.
The Iphone and an TI Calculator are not micros. They are devices
containing micros. Get the micros out, and programm them in asm.
There have been some micros that were essentially impossible to
program in assembly language, because they have an on-die ROMmed
interpreter for a high-level language (BASIC typically, as used in
1980s pocket computers). If the BASIC does not include PEEK/POKE/USR
or equivalent functions, there is no way to get native code onto the