From: Jonathan Kirwan on
On Wed, 13 Sep 2006 20:05:31 GMT, Vladimir Vassilevsky
<antispam_bogus(a)hotmail.com> wrote:

>Jonathan Kirwan wrote:
>
>>>The user interface of a microwave oven is already too complicated to be
>>>developed in asm...
>>
>>
>> I honestly still don't understand where you are taking this. But I
>> suspect that this example is a bit of a strawman. I think the user
>> interface of a microwave oven is a good place for a mostly using a
>> language other than asm, though I suppose there might be a small bit
>> of asm in many of them. However, that isn't how you say things.
>>
>> You seem to suggest, perhaps unintentionally, that such things are
>> also "too complicated" for asm. On that score, this sounds to me like
>> something spoken by someone who probably hasn't developed significant
>> applications entirely in asm.
>
>When I was young and stupid, I developed everything entirely in the asm.

I can't agree that developing entirely in asm is always strictly a
matter of being stupid or young or both, if that is your implication.

>Mostly it was because the early C compilers were very inefficient, full
>of bugs and poorly documented. I was too lazy to learn something new
>and unintelligible, especially when I had such simple and clear tool as
>the assembler seems to be.

And you point?

>Once I developed the application of 500k lines of asm. Finally that got
>me to realize that this is not the right way to do things.

It probably wasn't the right way for that application. I bow to your
knowledge of your application experience here. If you think it was
stupid, it was. All I can do is agree. But that does not provide you
with the right to claim, by fiat, that everyone else is wrong in what
they do. Much as you might imagine otherwise.

>Then the AVR and IAR C appeared. After that, there was absolutely no
>need for me to develop anything in the asm for 8-biter.

And that is the kind of absolutist statement that anyone should be
wary of. It is obviously ignorant of the myriad circumstances that
exist in a world as complex as ours. But feel free to pontificate
about your belief. Just others should realize that this isn't based
on your god-like knowledge of everyone else's circumstances, but
instead on your own narrow vision of them.

> I've done applications spanning many,
>> many hundreds of printed pages of asm (filling some 6 thick volumes,
>
>Why would you need the complete source code in the hardcopy?

At the time, we printed listings and bound them for reference.

>> actually, and including floating point routines, transcendentals, etc)
>
>No problem. I did all of that till I finally realized that there is no
>reason in reinventing the wheel.

A simplistic statement with grand, sweeping implications. But nature
is impassive and unswayed by the force of your own realizations.

I don't mean to be abrupt, but you really do seem to be telling
everyone else their business. Feel free, but it really doesn't change
things.

>> providing timesharing services and interpreters for dozens of very
>> active users entirely in asm and I'm quite sure that the user
>> interface of a microwave oven would be rather trivial by comparison.
>> So it's not out of the bounds, nor even particularly difficult. (In
>> that case, I had little choice at the time, though, due to processing
>> rate capabilities of 1960's technology and available options regarding
>> tools. Today, I'd use a high level language for a very significant
>> part of it.)
>>
>> Asm almost always has some place within the embedded applications I
>> work on. Perhaps 2-5%, or so, in many cases.
>
>Agreed.

At least, we have that.

> In a few cases, 100%.
>
>Example?

I could give several and justify them, but frankly you haven't made me
interested in pursuing it with you. You could go through google and
find some of my comments that discuss some details, though.

>> It depends on circumstances. But reducing asm to zero almost doesn't
>> happen, except in rather trivial test cases. And I'm not just talking
>> about applications I personally write, but those of people I work with
>> in similar product areas. It really isn't unusual.
>
>I did quute a lot of mixed C and assembly programming for the different
>processors. Surprisingly, I never had to use any asm coding with AVR and
>IAR EC++.

That's nice for you and your applications. I have done the same with
some of mine. But you don't find me making such bald claims about
everyone else's choices for their application area as you seem to be
making. Instead, I realize that there are times and places and that I
can only speak better about applications I've actually considered and
worked on.

>> Of course, I'm sure that there are times and places where assembly is
>> simply not used by the application developers -- but those places will
>> be where priorities and trade-offs are be markedly different from
>> mine. No criticism should be lobbed, either way. We know what we are
>> doing, just as I'm sure you do. My solutions wouldn't make sense to
>> some other application areas and their solutions wouldn't make sense
>> to mine.
>>
>> My only suggestion might simply be that being facile with assembly is
>> an enabling skill.
>
> From my experience, the people who are aggressively advocating the
>assembler are the ignorants who stuck with the seeming clarity and
>simplicity.

I don't think anyone _advocates_ assembly. Instead, folks _do_ wind
up having to deal with sweeping claims by people like you and trying
to put some measure of balance into them. If you see that as
advocacy, that's not my problem. There are (and were) times and
places. Sometimes, the circumstances _do_ warrant some assembly.
Sometimes, none. Sometimes, a lot. And even today, sometimes
entirely. You really have no business telling anyone that this isn't
the case. Though I definitely agree that time and tool availability
has moved the lines around over time.

> You can use it, or not, as the application
>> requires. But if you don't have much facility or familiarity with it,
>> enough that you are comfortable applying it, then you won't. Even
>> when the situation might be improved or completed more quickly with
>> it. (It would be manifestly wrong to suggest these situations do not
>> ever occur.)
>
>If you have the right set of m
From: Vladimir Vassilevsky on


Joerg wrote:

> Hello Vladimir,
>
>>
>>>> So, you are talking about using the asm for the really primitive
>>>> applications, like toys, tools, timers, dimmers, etc.
>>>>
>> Primitive applications are developed by the primitive people who are
>> paid the primitive money for their primitive job. The company can make
>> a lot of money from it however it is a completely different story.
>>
>
> What you call primitive applications are everywhere.

Petty bother.

The engineers I
> have seen working on these are intelligent people, often more so than
> those who do not have to find their ways around limited budgets. Their
> jobs are not primitive but rather challenging. Have you ever designed a
> consumer product that must be produced for less than $5? It's fun.

It could be fun. However there is no money for the engineer in the
development of the primitive stuff. It is the job for the technicians.
The reality is the bigger is the project and the higher is the level of
abstraction, the more money is paid. Just compare the salaries.

>
> Oh, and neither I nor clients have a problem receiving primitive money :-)
>
The simple stuff goes to China and India first ;)

Vladimir Vassilevsky

DSP and Mixed Signal Design Consultant

http://www.abvolt.com




From: Ulf Samuelsson on
"Joerg" <notthisjoergsch(a)removethispacbell.net> skrev i meddelandet
news:uQDNg.886$IA.0(a)newssvr11.news.prodigy.com...
> Hello Ulf,
>
>
>>>>so how do think other engineers design MSP430 products without this
>>>>info? Same problem with the AVR datasheets. Design by experimentation
>>>
>>>We generally don't anymore. We tried a design using an AVR's internal
>>>comparator. The next revision put it back in an external device. On the
>>>other hand the ADC has been adequate for a lot of purposes. Our general
>>>policy now is that any internal analog components on uCs should be
>>>presumed worthless until proven otherwise, especially considering the
>>>lack of adequate specifications. We suspect they let the digital guys
>>>build them for fun or something. :)
>>
>> No, the designers doing the analog stuff for the AVR is separated from
>> the
>> digital designers
>> by a significant ground plane it is so large that some people call it the
>> "Baltic Sea". ...
>
>
> Does "Baltic Sea" imply that AVRs are designed in Viking country, like
> MSP430s were really born in Teutonia (or rather Bavaria)?
>

Some peoiple claim that AVR means Alf and Vegard's Risc processor
but Alf and Vegard claims it does not mean that at all.
Vegard designed the initial CPU core and Alf wrote the compilers
while studying in Trondheim, Norway which is indeed Viking country.
The Analog cells are designed in Finland, which is not core Viking country.
Some ASSPs like the PWM, CAN and USB AVRs are designed
in Nantes, France which can hardy be claimed to be Viking country
although that part was so close to the atlantic coast that they
were bound to get the odd Viking "tourist".

>
>> The truth is that you cannot expect to have the same analog capabilites
>> in a
>> a CMOS process suitable to do all the other nice things you want in a
>> micro.
>
>
> Not necessarily. We have done mixed signal ASIC (full custom) with serious
> logic functionality on board. These include front end amps that feature a
> noise figure close to discrete solutions and up to 30MHz.
>
Sometimes it is a cost-performance tradeoff.
Atmel Grenoble (just sold off) delivered 2 Gigasample ADCs
so it can be done, but that does not mean that you can sell this in volume
as part of a micro.

When you build an ASIC you have design parameters that you have to meet.

A little different when you design general purpose micros.
Many of the current crop of AVR parts were designed for a certain white
goods manufacturer.
Sometimes specs are reduced to meet draconian cost targets.

At the same time, I do believe that a smart microcontroller company needs to
invest in analog technology
to allow integration of discrete analog.

> Just look at the analog tricks you can perform with a CD4007UBE (full
> CMOS) or a 74HCU04 (also full CMOS). The main thing is to consult with
> analog people before a SoC approach is chosen. That's not happening IMHO
> so we analog guys end up doing designs discrete that could have been uC.
> Over and over.
>
> Sometimes it helps to communicate before a chip design and not after.
> Example: IMHO the decision by TI to take the ADC function out of the new
> HW-multiplier equipped F2xxx device was not a good decision. It'll cost
> design-wins.
>
> --



--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB


From: Joerg on
Hello Vladimir,

>>>
>>>>> So, you are talking about using the asm for the really primitive
>>>>> applications, like toys, tools, timers, dimmers, etc.
>>>>>
>>> Primitive applications are developed by the primitive people who are
>>> paid the primitive money for their primitive job. The company can
>>> make a lot of money from it however it is a completely different story.
>>>
>>
>> What you call primitive applications are everywhere.
>
> Petty bother.
>

Huh?

> The engineers I
> >> have seen working on these are intelligent people, often more so than
>> those who do not have to find their ways around limited budgets. Their
>> jobs are not primitive but rather challenging. Have you ever designed
>> a consumer product that must be produced for less than $5? It's fun.
>
>
> It could be fun. However there is no money for the engineer in the
> development of the primitive stuff. It is the job for the technicians.
> The reality is the bigger is the project and the higher is the level of
> abstraction, the more money is paid. Just compare the salaries.
>

Maybe you have never worked on consumer gear. Or maybe you aren't living
in the US. The folks who design thermostats, toys, entry systems or
other consumer gear earn top Dollar. Just ask Jim Thompson here in the
NG (who has for example done a chip design for an air freshener). You
need to be a really good engineer to create such things in the presence
of a tight BOM budget.

>>
>> Oh, and neither I nor clients have a problem receiving primitive money
>> :-)
>>
> The simple stuff goes to China and India first ;)
>

The production of it goes to China, sure. Some of my designs are also
being produced there right now. Also some design will go but, believe it
or not, it's often the higher level code writing that goes there (to India).

--
Regards, Joerg

http://www.analogconsultants.com
From: Yuriy K. on
Joerg wrote:

>> BTW, does SDT have more than one undo level?
> I don't remember since I generally do not need an undo command ;-)

Hm-m-m. Are pencil and mylar tape good enough?

>>> And we still have the same incompatibilities where the only way to
>>> get the data into the layout package is a netlist.
>>
>> Try to use the same package for both schematic capture and PCB
>> routing. You will see a huge improvement in compatibility.

> Sure. My new CAD (Cadsoft Eagle) does that.

Obviously, any modern package does that.

BTW, what is the reason to use bad new software instead of good old SDT? :0

--
WBR, Yuriy.
"Resistance is futile"
First  |  Prev  |  Next  |  Last
Pages: 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
Prev: Tiny Bootloader
Next: Link&Locate 86?