| ??? 07/20/09 00:05 Read: times |
#167571 - There are things they can do ... but should they? Responding to: ???'s previous message |
Per Westermark said:
No, Richard. I don't think your post do represent a summary of the issues debated. When cornered, you twist in other directions claiming the discussion has all the time been about something else.
Richard Erlacher said:
"It seems that you frequently refer to things unrelated to 805x processors in this half of the site." No, I think you frequently thinks the 8051 is unique, and whenever someone discusses something you haven't thought about, you think: this is not 8051. Most concepts that leads to more efficient programming of an AVR chip is also meaningful for an 8051. You use the 8051 as you did 20 years ago. If the 8051 had stayed in a time pocket for the last 20 years, it would have been a dead processor. The only reason it is still alive and well is because people are all the time bringing in the latest knowledge from the rest of the world, and trying to integrate this knowledge. Todays C compilers runs rings around the compilers from the 1980. But you will never notice, unless you are willing to test. Some of the things you've brought into this and other threads cause me to believe you have an agenda other than the promotion of the intersts of the 805x community. That's why I mention the frequent reference to "more advanced" architectures, etc. From where I sit, it looks as though most of the posts are from people working with 805x. Until you came on the scene, few references to ARM, for example, were made, though some people did mention that they exist. Since ARM has its own interest groups, I figure that's where people will discuss them, just as they discuss 805x here. I suppose it's quite appropriate to kick around the ins and outs of using ARM or AVR or whatever on the Chat discussion board, but repeatedly bringing it into threads on this side seems unfitting to me. For purposes of this forum, it is unique. It's supposed to be the subject of threads introduced here. I did mention C and C++. And you responded with "just where do you see C++ compilers for 805x?".
You ass-u-me-d that there where no C++ compilers for 8051. One of many situations where you assume that things aren't applicable to a 8051. l did assume that you'd be unaware of them, but last time we had a discussion of HLL's here, someone mentioned that they'd brought in a couple of C++ toolsets. I wasn't aware that their existence was so prominent. Next thing - extremely few programs in any language is millions of lines of code. The majority of C++ applications (on PC or on enbedded platforms) is probably between 1k and 100k lines of code. Today's operating systems are very good at running large number of concurrent applications and letting them communicate using shared memory or networking. For maintainance reasons you normally don't do those huge applications anymore. It is not fun having 30 year old applications living their own life. When C++ was being introduced, it was touted as an advance for programming in the large. The goal was to make integration of work product from large teams more convenient, for projects like Windows, and other OS projects. I didn't realize that 'C' was inadequate and that large-scale programming techniques and tools needed to be introduced to the 805x market. With 64kB of code space, you would probably be able to fit up to about 10k lines of code - C or C++ - into the chip as long as you are careful about the design.
Next thing is that you see C++ and Windows of examples of where everything goes wrong. But note that M$ have already moved away from C++. They didn't manage to screw it up enough with C++, so they have moved on to C#. They think that .NET will solve all security worries and are ready to let the PC processor emulate or just-in-time-compile. One thing here is that C++ is a C compiler with a more strict type checking. Then you can decide if there are other parts of the C++ extensions you want to use. But you do not need to. C++ was originally designed to allow you to take your C code and recompiled with a C++ compiler. Then step-by-step adjust the code where it was deemed advantageous to adjust the code. "Lowly 8051." Yes, I'm pretty sure that the people who did work with massively parallel code at the university would think a 8051 or a ARM7 or a PIC or an AVR to be lowly processors. I do not think they are good examples of people who will start writing embedded applications and make a big mess of things. Remember these fools you regularly talk about, that got their education by using 8GB machines? Exactly how fun do you think they would think it is to play with something that does 1..100 MIPS? Sorry, but I think you gave a bad example. On the other hand, a Computer Science education should include basic knowledge about electronics, about processor architectures etc. And EE students who wants to work with microcontrollers will not use 8GB-equipment machines to do their LED panel projects or scanning and debouncing 4x4 keyboards. Back to the cellphones. The problem is time. Too much features in too short time. And it is we - the customers - who expects all the new releases with all the new features. The marketing department has a preplanned release date based on a big fair or similar. Most cellphones actually works quite ok. Especially after having received a firmware update - the things the caring developers wanted to do, but the management didn't allow. Better sound quality isn't a problem the cellphone manufacturer can do anything about. It is something the network owners are not too interested in, since more bandwidth represents an extra cost to them. But then again, I don't have a problem with the sound quality. I don't use a cellular phone for streaming any music using the audio channel. If I want to use it to listen to MP3 music, I can have it locally. If streaming something - it will use the GPRS or 3G network and can stream in any protocol the phone supports. And the more advanced phones most definitely streaming of hifi-quality sound. The next thing with cellphones is that it is hell-on-earth for the operators. They need to upgrade their cells with new featues all-the-time, to allow more time-slots, new frequencies, new encodings for SMS/MMS, push-to-talk, etc, etc. They regularly have to sneak in new firmware updates in the base stations while minimizing the effect it will have in the millions of network users. And since a huge percentage of all uses is for M2M, there are no longer any safe hours for updating. 03:00 in the morning may just as well be the time when the milk truck reports in the previous days all jobs - all milk collected at the different farmers. I certainly agree, at least to the extent that the features are crap, pasted in to mask the fact that the basic system can't maintain a connection, nor can it avoid dropouts. Until they develop a system that can function worldwide without a dropout rate lower than one per 10 billion users per half-century, they needn't bore me with other "features" that waste bandwidth but don't work very well either. Keep in mind, that the old PCM system that served for decades was all digital, aside from the last mile, yet tolerated single-bit errors very well. Bit errors in the current system cause syllables to be dropped. Switching between cells causes similar dropouts ... and then there are the dropped connections ... Please remember now that it was you who did bring in the cellular phones. Yes, I mentioned them because they're a perfect example of the "progress" in the telecom industry thanks to higher technology. The promoters of the flawed new technologies are always pointing out that they can do something, but haven't considered at all whether they should. However, I still hold that, all factors being equal, the guy who can properly program a task in ASM, is able to program it correctly in HLL, assuming he understands the HLL, than one who cannot, no matter how well he knows the HLL. RE |
