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.
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.
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.
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 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.
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.
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.
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...
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.
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.
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.
-- Cato
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.
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.