| ??? 08/19/09 14:25 Read: times |
#168396 - The embedded world is larger than your tiny island Responding to: ???'s previous message |
Richard Erlacher said:
Per Westermark said:
Richard said:
I can say that because much of the code I've worked on was written in ASM 20-30 years ago and the product is still in operation being used as intended, and simply required a bit of upgrading to add or support additional equipment or features. Maybe not so relevant. The question is: Do you have recent knowledge from extensive work in both assembler and C? To compare an apple to a pear, you need similar experiences with both. I'm not sure I need recent experience with HLL's to make the decision that the macroassembler does the job adequately. Further, I don't believe the HLL is particularly helpful for the small programs that can be managed on an 805x. The question is: Without recent experience with HLL's, you will have a hard time to figure out how good a C compiler can be at doing the job. Next thing - what "small programs that can be managed on an 805x"? A 8051 with 64kB of code space (and not filling the flash with just lookup tables) can handle very complex operations. It is most often the fantasy of the developer who sets the limit. Remember that most control systems don't need reaction times in the low us range but are fine with 10ms or 100ms response times. 64kB is room enough for a huge set of rules, and 10ms or 100ms is enough time for a huge number of computations. Richard said:
Nobody produces the same hardware. We simply continue to use the same hardware that was built 30 years ago. There's been no need to produce anything except as requirements have crept up. It is, after all, a one-off. So, you are giving an example of a one-off product, while your main thing all the time is the production costs of your high-volume products? You are switching directions wildly with your arguments - are you feeling cornered, or just having a hard time focusing on what your arguments are? For a one-off, I would not consider the potential to save cents on the processor. I would consider the development time. Richard said:
Richard said:
Don't forget the microcontroller task:
Examine inputs (including current context) and take appropriate action. But the controlling part can be quite complex. And when a system is non-linear, or you have unknown constants, it may not be applicable to use lookup tables. The "controlling" part is just a set of jump-tables. That's why it's large but fast. For each set of inputs, in each context, there's a jump table. That's what does the lookup. It's just about six lines of ASM, of which four are always the same. Yes, I do know that your jump-tables are used for lookups. That is what they are used for... But the issue is that jump tables can only solve a limited set of problems without having the size (and number of lookup levels) quickly explode into infinity. Richard said:
Richard said:
What simpler method than table-lookup could there be? It may be simple, but only capable of handling a subset of problems without exploding to infinite size. And if the customer is allowed to configure the behaviour, you may have to build the tables dynamically and store in way more expensive RAM. And if the system is non-trivial, you would normally not build your tables by hand, but instead use software to generate them. It can't become infinite because the number of inputs is finite. It can only handle a subset of all possible problems, but every other MCU has a finite number of inputs, too, and that regardless of whether it's in ASM or HLL. Did you really read what I wrote? Did you understand it? When you add time as a parameter, then a limited number of inputs will still represent an infinite state. Input A is low. Input A is high and changed "now". Input A is high and changed within 5 seconds. Input A is high and changed within 10 seconds. ... The processor may have 8 analog inputs. Each input may have a 10-bit range. Now you have 80 bits of input. Combine your analog readings with filtering for short-term noise and then add long-term trend processing and the states will grow quickly. And when the customer may adjust parameters (or the system is self-learning), you will either have to use explicit code, or dynamically build your tables. If you store dynamically built (and large) tables in RAM, you will quickly need a lot of RAM, which will limit the number of applicable processors. And if you need code to build the lookup tables in the product, then that code is way faster to write in C than in assembler. |
