Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
Per Westermark
06/24/10 03:10
Read: 766 times
Sweden


 
#176878 - Avoiding what issue?
Responding to: ???'s previous message
Justin said:
I wasn't talking about my designs.

And why assume that I was talking about your designs? You shouldn't have any corroding pins even if buying electronics off-the shelf. There are many ways to make the electronics work in corroding environments, and changing the pin c-c distance is definitely not on the top of the list. Hardly even on the list at all. The capsules you are disliking are in use in the most demaning environments already with good results. But salt should never be allowed to reach any electronic parts.

Justin said:
Obviously you missed that qualifier at the end that said "maybe a little more poorly".

No, I most definitely did not miss any "maybe a little more poorly". It's just that there are no magic factor producing any "little more poorly" in either direction without looking at a specific problem and specific chips. So without having specific problems/chips, the "maybe a little more poorly" part becomes moot. But do I have to start from scratch and repeat everything I have ever written in this thread in every single post so as not "having missied" something?

I have made several posts that have the implied meaning that:
You always have situations where a specific 8-bit processor will win over a specific 32-bit processor. And you will always have situations where a specific 32-bit processor win over a specific 8-bit processor.

That is not incompatible wtih another statement I have made at least twice.

A 32-bit processor can always be designed to 100% span the feature set and timing of an 8-bit procesor, but the reverse is not true. So there can never be a general case that an 8-bitter must always be able to win over a 32-bitter in speed or suitability of instruction set. There can be situations where an 8-bitter can win in power, but the 32-bitters tends to be released by the companies with the big money and with access to the best factories. So you can normally get 32-bit processors in smaller geometries than the 8-bit processors, which in this case balances any extra power consumption from the extra transistors in the 32-bit cores.

And while busy using a technology where transistors are cheap, you at the same time gets access to great peripherials - the 8051 is a nice processor but every part of it was designed on a very, very, very, very strict transistor budget. Most bang without adding an extra transistor. That makes UARTs, timers, SPI, I2C, ... normally much nicer on 32-bit processors. Or more specifically - a low-end 32-bit processor normally have better peripherials than a high-end 8-bitter in general, 8051 chips included.

I have also specifically mentioned why I have used ARM as example for 32-bit processors. It's the one big 32-bit architecture that is seriously fighting in the microcntrller arena. For other architectures you will find one or more odd variants but for the big part they are competing in the PDA/Phone/Router/PC/... arenas. Release 10 great x86 chips with good microcontroller features and available from one source and I might mention them. Release 1000 variants and I most definitely will.The old 80186/80188 chips did contain a number of pheripherials integrated. But the concept was still more like a "system on a chip" than a microcontroller. I have been using it in more than one design, but only because the availability of alternatives was so much different at that time.

When looking for situations where a 8052 chip will start ahead (but may or may not end up the best choice), you have to focus on something that very few other processors have. That is the dedicated bit instructions that spans a large part of the bits of the instruction set. On one hand, the large number of op-codes consumed for bit instructions means that you lost the instruction space for some more advanced instructions (given availability of more transistor later down the timeline). But the bit instructions makes the chip excellent for programs performing single-bit decisions or single-bit control using a minimum of instructions. A general purpose processor will need extra add/or to perform the same things, which adds number of instructions and bytes of code space and normally extra clock cycles. Some ARM chips does have hw-acceleration outside the core emulating bit read and bit write. But the chip still does not have bit test - it needs a separate instruction for the emulated bit read besides the test/jump.

Since there are 32-bit chips that can manage work-arounds and still end up doing bit operations with similar timing (even if performing multiple 1 or 2-clock instructions) it wont be enough to just claim that projects with bit operations is projects where 8051 chips ends up on top. It's the area where they start with an advantage. The rest of the project requirements will then tell if they will manage to hold the lead, or end up similar or gets dropped.

Justin said:
So, why am I working with an 8051/2? I mean you even go on to say that it is economical to misuse power with [...]

Missuse power? Power doesn't have anything with number of transistors to do? Transistors are not a scarce resource requiring us to count them to be environmentally friendly. And 10 transistors in one geometry can consume less power than one transistor in another geometry. Especially if the 10 transistors are through with the job faster and can then just idle. The current process technologies consumes most energy for transition changes, i.e. the recharging of capacitances. A smaller transistor have a smaller capacitance and so need less power to toggle. It's not until leak currents represents the majority of the loss that the processors will continue to draw a lot of energy even when sleeping. Another thing - most newer microcontrollers have very advanced power routing features. If you don't need UART3, you turn off the supply power to it. The transistors are still there, but not being powered means they will not even leak current.

Justin said:
You still avoided my original question and gave me that salesman like approach. What is the "suitable market"?

Nope. I have not ignored the question.

The problem with the thread is that it somehow makes the assumption that you can subdivide the embedded market into niches and each niche can then be tagged as 8051 model x, 8051 model y, PIC z, AVR w, ... Even tiny projects are multidimensinal meaning that there will not be a single metric to select the best chip. And as soon as we have a multidimensional problem we may end up with equations that can't be solved exactly or with a formula. So we need to do an iterative solve and may not be able to prove that we can find the optimum - maybe our iterations can only find some sub-optima. We can identify a number of big no-no and throw out large groups of processors breaking these no-nos. At the end, we have a couple of handfuls of candidates left, and will have to pick one with no more hard evidence to use. That is a good time to pick one you feel good for, even if that is a subjective measurement. But at least "I like" means you may have a happier time during the development stage. Kind of working with people you like.

Saying that a specific problem area should always use a 8051 chip is similar to saying that a specific area should always use a Silabs C8051F92x-93x. It can only end up in a large number of "why" that can't be answered. Why say that a problem area should always use a chip with 64kB of flash and specially designed for low power? Maybe the unit is always powered from 230V mains? Maybe the expected code size is 300 byte? Maybe the need is only for 3 I/O pins?

It is possible to discuss generic selection processes. What is important to look at before selecting a chip. But there will never be a "best" chip. Subdidide the enbedded world once, twice, ... twenty times. That could at the most give you one million small pieces of the embedded world. But these piaces will probably still have one or more unhandled parameters - parameters that means you can't pick one specific processor and say it is the "best" processor for this tiny niche. And even if you see a very suitable processor, it may end up being suboptimal within weeks or months because of new processor releases.

Since there is a huge overlap between different microcontroller families, you can't just loosen the rules a bit and upgrade from a single specific model from a specific manufacturer into saying that the nice is best handled by a specific architecture. You will normally always find multiple architectures that have multiple models that are well suited for the task. And there isn't even any hard natural limits between 8-bit, 16-bit or 32-bit problems.

In the end, you get a thread filled with debate. Nothing wrong with that, as long as you realize why you get a debate instead of a list of target areas where a 8051 should be used. Suitable areas^H^H^H^H^Hprojects for 8051 chips are areas^H^H^H^H^Hprojects where the used 8051 isn't a misfit. The exact same projects may be suitable for a PIC. Or for an AVR. Or an MSP430. Or a number of other architectures. It all comes down to the large areas spanned by different models in an architecture, and the large overlap between architectures.

It is 10 or 100 or maybe even a million times easier to talk about "do not" than "do". Everyone would agree with "Do not use a PC-class processor for a lamp timer". But try the reverse. What is the best processor for a lamp timer? Suddenly, you get a lot of open issues:
- extremely low power because driven by capacitive feed? Or maybe months running on supercap?
- number of outputs - one lamp or 16? maybe just 8-bit is enough?
- able to PWM-control the lamp with great precision withut burden on the core?
- RTC to keep time individually or radio-controlled clock or just counting cycles from mains?
- huge set of control points or just four on/four off times?
- support to drive a LCD directly? Or send data using 4-bit or SPI or UART? Or just LEDs for feedback?
- ...

Even for a trivial product in a very well defined niche you get a huge set of open parameters. A generic 8051 with an intelligent LCD controller? Or an ARM chip with hw support to access the LCD glass with no extra glue logic? Or a nanoWatt PIC? Or a custom 4-bit chip with special peripherials designed especially for shipping millions of lamp timers? All debates claiming that a 32-bit processor is overkill have to remember that there exists 4-bit processors too, so you could have the debate that 8-bit processors are overkill. But are they? And when?

Justin said:
I will recommend the 32-bit PIC because everyone likes the ARM or has only worked with ARM.

That is silly. Recommend a processor because you see objective reasons to recommend it. Don't recommend anything just "because". What are your view on the development tools needed for your 32-bit PIC? You do recommend them? And you also recommend the PIC because of price and availability? And multitude? And amounts of independent sample code or documentation? Their CAN controllers? Or because Microchip claims that they are "designed for best-in-class 32-bit performance and accompanied by a vast offering of software." Or exactly what are your objective reasons for your recommendaton? Just to be anti isn't a good reason.

Justin said:
Not one time did I say "great love of ARM chips".

If you do read the sentence, you'll notice that it is I who are using the expression "[...] wasn't because the great love of ARM chips [...]" so why do you assume that anything I write are magically a claim that someone else have said the same thing?

Justin said:
Why is it assumed that 32-bitter inherently implies ARM? Isn't that just a bit odd.


The first post contained four references to "ARM". The second post two. So obviously the ARM family is on peoples mind. Must be a reason why. Probably not an odd reason. They aren't exactly under heavy pressure from other 32-bit architectures in the embedded world...

List of 104 messages in thread
TopicAuthorDate
So What Is An 8051/2 Good For?      Andy Neil      06/17/10 16:35      
   thoughts      Erik Malund      06/18/10 04:36      
      The Future of the 805x      Joseph Hebert      06/18/10 08:40      
         PARC      Rob Klein      06/18/10 09:01      
            Bigger Hammers      Joseph Hebert      06/18/10 09:37      
               re: Bigger Hammers      Rob Klein      06/18/10 10:59      
               The opposite problem seems more common here!      Andy Neil      06/18/10 15:50      
         Would Toyota have had the problem if ...      Erik Malund      06/18/10 09:31      
            Toyota: Case in point      Joseph Hebert      06/18/10 09:46      
            RE: Toyota      Andy Neil      06/18/10 10:17      
               It was a mechanical fix ...      Richard Erlacher      06/18/10 22:37      
            Parallel Processing      Justin Fontes      06/18/10 10:35      
               Sometimes the practical reality is of little consequence      Richard Erlacher      06/18/10 22:45      
                  Totally Agree, but I was looking for a magic bullet      Justin Fontes      06/18/10 23:09      
                  RE: "outperform"      Andy Neil      06/19/10 01:10      
                     There are some operations ...      Richard Erlacher      06/19/10 06:19      
                        rephrased      Erik Malund      06/19/10 06:44      
                        Now, you are extrapolating      Per Westermark      06/19/10 06:44      
                           good points, but      Erik Malund      06/19/10 07:12      
                              How many 8051 chips uses 0.13u?      Per Westermark      06/19/10 08:57      
                                 not yet      Erik Malund      06/19/10 13:05      
                           not exactly ...      Richard Erlacher      06/20/10 09:39      
                              Do not get focused on one operation...      Michael Karas      06/20/10 10:20      
                              any 8-bit instruction can exist in a 32-bit processor      Per Westermark      06/20/10 12:14      
                                 Yes, but does it?      Richard Erlacher      06/22/10 07:54      
                                    So have you looked at any other processors?      Per Westermark      06/22/10 09:37      
                                       not a point of disagreement, but you missed it anyway      Richard Erlacher      06/22/10 22:50      
                                          A good point      Justin Fontes      06/22/10 23:10      
                                             beg to differ      Michael Karas      06/22/10 23:23      
                                             Disagree entirely!      Andy Neil      06/23/10 00:45      
                                          Yes, auto-increment/decrement is standard and not "feature"      Per Westermark      06/23/10 00:29      
                                             What I wanted to point out ...      Richard Erlacher      06/23/10 06:07      
                                                Same same all the time. no "one size fits".      Per Westermark      06/23/10 07:46      
                                                   and the most important point is (drumroll) ....      Erik Malund      06/23/10 09:49      
                                                Comparing Apples to Oranges      Andy Neil      06/23/10 08:03      
                                          Prices are comparable      Andy Neil      06/23/10 01:00      
               Parallel processing        Oliver Sedlacek      06/22/10 02:40      
                  Sweeping generalisation!      Andy Neil      06/22/10 03:22      
                     Not a magic silver bullit      Per Westermark      06/22/10 04:20      
                        Fond memories      Oliver Sedlacek      06/22/10 07:58      
                        A magic bullet      Justin Fontes      06/22/10 10:17      
                           Most concepts already exists in the wild      Per Westermark      06/22/10 11:31      
                           Another generalisation        Andy Neil      06/22/10 14:43      
                           Speed vs latency      Oliver Sedlacek      06/22/10 14:47      
                              Why 8051?      Andy Neil      06/22/10 15:08      
                                 Isn't it obvious?      Justin Fontes      06/22/10 23:17      
                                    ARM simpler than 8051      Oliver Sedlacek      06/23/10 00:21      
                                       Generalisation      Andy Neil      06/23/10 01:34      
                                          ARM 'MCUs' have their limitations too!      Valentin Angelovski      06/24/10 07:52      
                                             You normally engineer with a backup plan      Per Westermark      06/24/10 08:20      
                                    No, it's not!      Andy Neil      06/23/10 01:27      
                                       Im just trying to provide an argument      Justin Fontes      06/23/10 10:33      
                                          x bits are just one parameter among many      Per Westermark      06/23/10 11:27      
                                             Avoiding the issue      Justin Fontes      06/23/10 21:09      
                                                Avoiding what issue?      Per Westermark      06/24/10 03:10      
                                          They say it because it's true!      Andy Neil      06/24/10 00:59      
                                          RE: ARM is not the only 32-bitter      Andy Neil      06/24/10 01:15      
                                    Please don'g generalize      Per Westermark      06/23/10 01:28      
                                 Heterogenous multiprocessing widespread      Oliver Sedlacek      06/23/10 00:17      
                  Re: Multicore 8051      Valentin Angelovski      06/24/10 06:48      
                     ALU chaining      Oliver Sedlacek      06/24/10 06:57      
   Well... maybe      Jez Smith      06/18/10 14:47      
      A Linear Accelerator?      Joseph Hebert      06/18/10 15:28      
         Its one of these      Jez Smith      06/18/10 15:51      
      please, repeat      Stefan KAnev      06/19/10 04:56      
         All I was saying was      Jez Smith      06/19/10 10:39      
   So what the '51 are good for...      Jan Waclawek      06/21/10 13:54      
      Not terribly helpful      Andy Neil      06/21/10 14:46      
         Always up to the developers      Per Westermark      06/21/10 15:24      
            RE: The manufacturers tells us...      Andy Neil      06/21/10 15:30      
               Sales - "may be used for" presented as "recommended"      Per Westermark      06/21/10 16:41      
               pretty hot, low-power and small      Maarten Brock      06/22/10 15:17      
                  Automotive...      Andy Neil      06/22/10 15:26      
         but answers your original question (at least the one...      Jan Waclawek      06/22/10 10:19      
         MCS51 still rocking !!!      Kiran V. Sutar      06/23/10 05:14      
            Scale      Andy Neil      06/23/10 06:09      
            Missing the point      Andy Neil      06/23/10 06:21      
               Impossible to generalize into fields      Per Westermark      06/23/10 08:09      
                  An appropriate generalisation...      Andy Neil      06/23/10 10:20      
               You are right..Andy Neil      Kiran V. Sutar      06/24/10 05:27      
                  Cheers!      Andy Neil      06/24/10 05:43      
                     No..only AT89C52 can be used      Kiran V. Sutar      06/24/10 05:56      
                        why do you insist on Atmel?      Erik Malund      06/24/10 06:05      
                        what a strange post      Erik Malund      06/24/10 06:09      
                        Tools?      Andy Neil      06/24/10 07:12      
                           Multiple manufactuers with (almost) identical chips      Per Westermark      06/24/10 07:48      
                              Getting better      Andy Neil      06/24/10 08:52      
                                 Unified interrupt controller is really great      Per Westermark      06/24/10 09:28      
                           Yes, even with free tools for PIC/AVR      Kiran V. Sutar      06/24/10 08:38      
                              I mean no offense, but ...      Richard Erlacher      06/26/10 09:59      
                              Similar difficulties coming to 8051/2?      Andy Neil      06/26/10 10:28      
                                 Same same      Per Westermark      06/26/10 11:18      
                  Is it your purchase price or why so sure AVR or PIC are off?      Per Westermark      06/24/10 05:55      
                     Answer to Per and Erik...      Kiran V. Sutar      06/24/10 06:38      
                  Living in the past      John D. Maniraj      06/24/10 09:44      
                     Thanks John D. Maniraj      Kiran V. Sutar      06/25/10 03:54      
                     locking      Erik Malund      06/25/10 07:20      
                        RE: Locking      Andy Neil      06/25/10 07:32      
                        Agreed, but      John D. Maniraj      06/25/10 11:00      
                           fairly easy      Erik Malund      06/25/10 11:53      
      Don't forget consumer devices      David Good      06/24/10 13:45      
         A perfect application      David Good      06/25/10 10:49      
   8051 vs ARM      Valentin Angelovski      06/24/10 08:34      
   just thought of one case      Erik Malund      06/24/10 12:32      

Back to Subject List