N. Coesel wrote:
At 20:29 04-04-08 -0700, Vitaly Luban wrote:
N. Coesel wrote:
If you write you code portable, you can use and CPU you want.
That is not true. First of all, certain "features" of the mspgcc make it
difficult to
use even highly portable code on MSP w/o additional sizable effort.
In that case you are doing something very wrong.
Really? Most of my apps one way or another are about wireless. Packed
structs are a must.
How mspgcc handles them comparing to other C compilers?
I'm using the same code
(even the standard library from MSPGCC) on several ARM devices, MSP430 and
Renesas devices without any pain. Just hit compile and go (ofcourse the low
level hardware drivers and startup-code are different).
Drivers are about 90% of all my development as of now. The rest is
stable for a long-long time.
Besides,
debugging on an embedded device is not the fastest way to debug.
This is also not exactly true. While it is possible to do the "proof of
concept" this way,
real embedded code on a production board will have totally different
timing profile, so
any possible timing bug /race will possible be unnoticed in a PC
implementation, Then,
That is an often heard excuse. But in practise very few processes are real
time. Race conditions can be eliminated by carefull design.
Few? Well, "real" realtime, when someone die or something explode if
controller does
not react in time, maybe not. But performance critical - definitely. My
approach beats
yours hands down, earlier this year I had a pleasure to see jaws dropped
at some very large
japanese company when my design had shown double performance against
"theoretical
limit" predicted by "experts" from one large american company. So much
for your
"carefull design" allegedly eliminating races...
peripherals, like a/d and d/a converters etc. one can use on a PC will
have different
charaqcteristics like linearity, error magins, noise... That makes it
impossible to do real
world debugging using simulation.
I'd like to turn that around. On a PC you can simulate the extends of
noise, non linearities, etc, etc to proof software works even if the analog
parts are on the edge of their specs.
BS. While possible in theory, the amount of effort needed to create a
precise enough simulation
makes it nonfeasible in reality.
And ofcourse it takes some experience
to know what kind of constructs work or won't work on an embedded device.
All constructs work equally everywhere. Well, as long, as compiler is
not buggy. :)
It's cost/performance difference that matters. And it's the cost that
makes some of them
nonfeasible.
Being able to maintain software is the key word here. Rewriting or
maintaining different versions for different platforms is a real pain in
the ass (and can kill a company because they got trapped by a solution).
Just a few weeks ago I wrote a set of routines that will work on
microcontrollers (like ARM, MSP430), Windows and Linux. This means a bug
can be fixed or functionality added for all platforms in one go. Because
the routines where designed with the microcontroller environment in mind
they have a very low memory footprint if they have to. Using GCC as a
compiler is a key factor here.
Been there, heard that. Top level control app - maybe. Device and
application performance
critical code, that's ~90% of any controller application - never.
Just write
for Windows/Linux first and then port your code to the embedded device.
And you'll end up with something that hardly fits into flash and subpar
on performance at best.
Have you done any real project so far? Real device that's produced in
enough quantity
to force you to shave fractions of cents from the design as every extra
0.1 cent in the BOM
means some $100,000.00 loss for you? Try it and you'll see for yourself
that you're wrong
here.
If you have to shave off such small amounts, then the exchange rate of de
dollar, oil prices, salary increases, etc have more influence on your
product price than adding or removing a resistor from your design. And yes
I have been doing real projects for the past 15 years.
15 years? Hard to believe looking how you pile up factors that are
completely irrelevant
to one another into one heap... I wonder if you use the same approach in
your designs... :)
Vit.
