AT89S52 - PLCC vs DIP Package


Hi All
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
different ?
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
Kind Regards
Lodewicus Maas
Reply to
Lodewicus Maas
Loading thread data ...
All correct. It's down to what you prefer.Maybe the board space is limited, so forcing the use of PLCC.
Reply to
TTman
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
Regards
Reply to
Lodewicus Maas
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.
formatting link

Atmel, at its own site here:
formatting link

provides a ZIP file with include files you can use with SDCC (among other compilers):
formatting link

Here's something else:
formatting link

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.
Jon
Reply to
Jon Kirwan
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.
Reply to
=?ISO-8859-1?Q?Hans-Bernhard_B
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.
Reply to
Chris Stratton
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 control panel.
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.
Jon
Reply to
Jon Kirwan
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.
Reply to
Chris Stratton
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 Language"
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.
Jon
Reply to
Jon Kirwan
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 scripting language.
Should the search fail, I could find a handy OTP device and create one ;-)
Or I could just point to any microprogrammed machine with immutable microcode...
Reply to
Chris Stratton
I'll leave it to you, then.
Jon
Reply to
Jon Kirwan
Thanx for all the replies
So, in laments terms: C is more popular than Assembly Language, but Assembly language is more complex and powerfull ?
Do I understand this correct ?
Reply to
Lodewicus Maas
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.
Franssoa
Reply to
Franssoa
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.
Reply to
=?ISO-8859-1?Q?Hans-Bernhard_B
["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 unit. ;-)
--
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.
 Click to see the full signature
Reply to
Stef
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.
Reply to
malte
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 device.
Reply to
larwe

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.