| ??? 02/10/10 08:51 Read: times |
#173016 - questions and answers Responding to: ???'s previous message |
Jez, in his usual nice calm and charming manner, said:
Why? While the question is useful indeed, I believe it does have valid answers. Andy Neil said:
What, exactly, do you mean by "computer"? Another good question. Andy Neil said:
There are far better architectures available for "computer"-type applications - some at similar costs to comparable 8051-derivatives... Please, elaborate. Andy Neil said:
Usually, "computer" is taken to mean a general-purpose device for running any application(s) the user may choose. Generally, the 8051 architecture is not a good choice for this - not least because of the (relative) difficulty of loading applications! Now THIS is not true. A '51 with exposed "biblical" external bus is as much von Neumann as Harvard. And, before you start complaining that these devices are obsolete, loading an application into any IAP-capable (i.e. self-programmable) derivative from an external memory/drive is a snap; while remaining single-chip. And, there are derivatives with RAM used as code memory - they may not be the mainstream general purpose ones, but there are quite a couple of them out there. And, Jez or anybody else could whip you up one with any memory addressing scheme from an FPGA. And, should things go as smooth as mass production, Lynn Reed of Tekmos or anybody else will be happy to concoct you one exactly as per your needs. In this regard, '51 is maybe the MOST suitable contemporary 8-bitter for the task. But I am still curious on what would be YOUR favourite processor core in application like this. Andy said:
The 8051 is a micro-controller; designed for embedded control applications - not really as a general purpose processor. True, but now I would like to return to the first, Jez's question. Why. There are quite a couple of industrial applications, where a device has basically two modes of operation: most of the time it works autonomously, unattended; but from time to time it needs adjustment. For the former, the bare microcontroller is sufficient; the latter requires some user interface. For the reasons of cost, this is usually stripped down to a couple of LEDs, and/or a couple of 7-segment displays, or a simple display like the 2-line alphanumeric LCD. Everybody who used such can witness that the UI is usually a pain - and a double one, one is to write it so that it is at least so-so usable, the other is to actually use it. The usual solution is to have some communication port, bring in a laptop or so, connect and adjust from there. But then there's the hassle with the laptop in the industrial setup, and also one has to do double work - write both a communication. Most of the time the local cumbersome UI remains as a backup, so that's triple work. Video is a big, big bonus for this purpose. But it is usually quite expensive. Not only the device - both display and the chip to drive it - but also to write the software. While there may be many different displays and the methods to control them, it may pay out to have standard libraries for displaying on them. And standard methods to run setup and checking utilities (yes, that's perfectly fit for command line). The mass storage is another useful issue. You can have the main app but also utilities (such as setup and testing apps used only seldom, at initial setup or so), but also allows for easy making of logs. And, to make it easily move programs and data between PC and the gadget, SD is perfectly fit nowadays. Quite a lot of people are still familiar with the whereabouts of DOS (and a few are familiar with *nices), so it makes sense to make these things work similarly from the point of view of the user. --- Now at this place one can easily say: hey, there are those nice and really cheap one-board PCs today, or, if you want, there are those 32-bitters with all those fancy interfaces built in. And you can get Linux on them and go. Cut it here. Once you start thinking along these lines, it gets extensive and expensive, fullstop. You CAN do this, why not, but that's a wholly different business. --- I always remember the measurement setup I contributed and used when doing my thesis back then. It was based on a PC - the real stuff, two 180kB single sided floppies, no HDD, running DOS2.2 and GWBASIC from one, and the application from the other, where the results were also logged (there was surprisingly plenty of space on a 180kB floppy! ;-))) ). Directly controlled a couple of steppers (through a simple IO card) and took measurement from 2 or 3 devices through RS232. In 1993 it had already the junk status, but, hey, it was perfectly fit for the task! I run the measurements overnight, as noise was a huge issue; and then took the floppy with the logs and transferred to a "real" PC to process them. See some similarity? JW |
