Entering the embedded world... help?

Jonathan Kirwan wrote:

> >My publisher is Elsevier, and they sell to anyone, anywhere, with money
>
> Strange.  Just the other day I just noted a comment by scientists who
> refuse categorically to review for, submit to, or subscribe to
> Elsevier owned publications -- unless and until they provide open
> access to the scientific papers after 6 months.

I don't think that changes my sentence above - Elsevier will _SELL_ to
anyone with money, right?

Scientific papers are a special case, I don't pretend to understand the
politics of academia. If I was going to emulate someone in my writing
career, it would be Dean Koontz (mass market), not Shakespeare (art).

Writing technical books is no way to make a living of course, but it's
fun and that's the main point. Once in a while a royalty check appears
on my doorstep, and that's money from the heavens, typically disbursed
frivolously.

>Have you thought about implementing some of this in an FPGA/CPLD? The rs232 ports, IO, PWM and tone generation are almost trivial to implement (when you know what you're doing).

Hrm. I don't think I want to implement RS232 in software. I expect I
could, but I'm really looking for a small cheap board with ethernet and
serial ports already in place, and a nice little TCP/IP stack on board.
Writing my own TCP/IP, in particular, is no fun at all.

There's a fair amount of logical state in what the room controller
does. It's intergrating inputs from phone, doorbell, water sensor,
touch sensors, 2 motion sensors, door and window sensors, a complicated
stereo protocol over RS232, and taking complex commands from ethernet.
It's generating 4 channels of 0-10v for dimming lights, controlling the
stereo (which has a lot of states and modes and rules), tones, and a
bunch of on/off devices like amps and LEDs. It handles things like "If
the room is in Movie mode, AND someone opens the door, then bring up
the back lights so they can find their seat, then fade back down". "If
playing music, and doorbell is pushed, mute music, play doorbell tones,
blink LEDs, resume music." The cases sound simple individually, but
having the responses and reactions all interruptable and adjustable on
the fly in realtime, amounts to a good sized state machine.

As a software engineer, I'll put in a plug for OO languages. State
machines like that are a lot nicer when you have an OO language. Though
I personally DON'T like Java, because of the overhead it imposes, but
it did make the state management a lot simpler. I could have done it in
C, but the code would have been that much more obscure, and having
things to be trivial to modify (as I change gear) is very important to
me.

C++, despite some of what I read here, is better than C for just about
anything where perfofrmance matters. The key with C++ is not to use it
stupidly (which is easy to do and frequently done.) Used with an eye
towards efficiency (ie, no STL, no misuse of new/delete, leave the
string classes alone, use well designed classes with a minimum of
virtual declarations), it produces better code than C compilers,
because C++ demands fully specified interface, so it can optimize more
intelligently than C.

Maybe that's not true in the embedded world - no idea how good the
tools are in this space. But I have every hope of wriring in C++. If I
can't find good tools, I can always cfront it down to C, and compile
that.

Unfortunately, I've seen a lot of stupid C++ - but then I've seen C
which is absolutely obscene. As someone who writes VMs and optimizing
compilers as fun projects, there is a LOT I can say about using C++
right, where Java went wrong, and where C could have been a little bit
better. :-)

> Hrm. I don't think I want to implement RS232 in software. I expect I
> could, but I'm really looking for a small cheap board with ethernet and
> serial ports already in place, and a nice little TCP/IP stack on board.
> Writing my own TCP/IP, in particular, is no fun at all.

I meant using an FPGA/CPLD to implement the PWM and enable you to handle
a much larger number of IOs than with a stand alone uC. Uart cores can
easily be implemented (there are free ones about) if you don't have
enough in your chosen uC, as you say the TCP/IP implementation is best
left to the software.


An Altera EP1C6 in 240 QFP gives you about 170 pins to play with!




Nial.

larwe wrote:

> Tim Wescott wrote:
> 
> 
>>>First off, what's a good processor?
>>
>>Why does _everyone_ ask that.  There's gazillions to choose from.
> 
> 
> Different people ask it for different reasons. Almost half of my
> upcoming book talks about roughly half a dozen different processors,
> and why those specific chips might be one "correct" answer to the
> question "which CPU should I learn? [to get into the embedded world]"
> That's about 60,000 words on the topic, and it's only an introduction.
> 
I'll look for it.
> 
>>>I'd like to code in C++ or C, but I can learn assemblers. Coding is not
>>>a problem for me; blowing up hardware occasionally is. Because I like
>>
>>Most everyone uses C or C++ these days.
> 
> 
> I take a bit of exception to the idea that "everyone uses C++",

I do too, particularly because that's almost exactly not what I said. 
Was your misrepresentation of my statement a debater's trick, an honest 
mistake, or do you have your language blinders on a bit too tight today?

If you have good enough blinders on not only can you see 'C or C++' as 
'C++', you can pretty much decide anything about anything and feel good 
about your decision.

> especially in the embedded arena. I guess it's been a few months since
> this particular chestnut was sizzled on the coals in c.a.e., so maybe
> we should just cut and paste the last argument thread to save
> everyone's time.
> 
> I'm starting to see an approach that approximates sanity with regards
> to the use of Java in high-end embedded projects, rather than C++ (a
> language which is abhorred on any architecture by all right-thinking
> embedded engineers - and of course, only an exceptionally jaded
> masochist who has lost the phone number of his dominatrix or can no
> longer afford her dungeon rates would contemplate C++ on an 8-bit
> micro).
> 
> If you're prepared to live with the overhead of C++, 

The only overhead of C++ is the overhead that you choose to allow into 
your program -- if you know what you're doing.  Anyone who can figure 
out how to compile to assembly and inspect the resulting code can figure 
out how much overhead each language feature exacts, and choose whether 
to embrace or reject that language feature.  I have yet to meet a C++ 
library that tries to pull in the entire standard template library just 
because I'm adding 1+2.

> and you're
> convinced that there is something to be gained in your application from
> a language that has OO syntactic elements (like C++) rather than merely
> OO capability (like C), using Java instead can be a pleasant surprise.

Particularly when your real-time motion control processor goes off line 
to do garbage collection in the middle of a move.  That'll be a 
surprise, but only pleasant if you like smoke and flying metal.

It will be a pleasant surprise for the processor and memory 
manufacturers when you have to discard that 16 bit thing that should 
have been fast enough to go to an ARM or a PowerPC just to get the job done.

> Among other advantages of Java over C++, it is occasionally possible to
> find someone who can answer a Java question both exactly and correctly.
> Furthermore, positively several Java questions do not have as their
> "real" answer a 5,000 word argument amongst five language lawyers. No
> C++ question can be answered without either:
> 
> a) employing several language lawyers of opposing viewpoints, and/or
> 
> b) developing a new draft standard defining a version of the language
> with the desired functionality.
> 
> Dogma is a wonderful thing, isn't it?

I haven't found that to be the case at all.  Certainly there is a lot of 
smoke and heat generated by people who cannot tell the difference 
between a languages potential for weirdness and the level of normalcy 
you can achieve with just a modicum of restraint.

There are also excellent books, Stroustrop's reference and "Thinking in 
C++" among them that are authoritative, accurately predict what the 
average compiler will do, and don't require lawyers, sea- or language-, 
to interpret.

Hysteria is a wonderful thing, if you use it right.
> 
> In Australian universities, they [used to?] teach a subject called
> creative accounting. The core of this subject is: Your company bought
> $X, sold $Y and received $Z over the past year. Your CEO, stockbroker
> or drug dealer wants the company to show a profit of $F. Obtain this
> result in a GAAP-compliant way.
> 
> In the past, I've seen vast practical use for this coursework in terms
> of justifying (or killing) value engineering projects, obfuscating
> projected bill-of-materials costs, and demonstrating that a department
> has met its budgetary goals. But the single most useful fact it taught
> me is that all metrics not directly derived from underlying measurable
> physical phenomena are nonsense - 

And many that _are_ directly derived from underlying physical phenomena 
are also nonsense, if you fail to get your correlations right.

> and cost/productivity/reliability
> savings realized by moving to C++ are at the bad end of the spectrum.

Not in my universe.
> 
> Moving from assembly to C at a certain [fuzzy] size/complexity point
> can be justified merely in terms of the number of people that are
> comfortable programming in the language (though I am quite convinced
> that there's more gain than merely this one point, and most c.a.e
> readers would agree with this).

Ditto for C++, in the real world.
> 
> Moving to C++ in embedded projects(*) requires justifications that
> typically end in the words "MY GOD! A MAUVE DOLPHIN ON A BICYCLE IS
> FLYING PAST THE WINDOW!" (Alt-F4 PowerPoint drivel while everyone looks
> out the window). "This concludes the presentation; in summary, you
> should do what I say".
> 
> 
> (*) Special exceptions apply. These are mostly ludicrous, e.g.
> designing a project that is not a PDA around Windows CE.
> 
I have written and/or maintained moderately large projects in assembly, 
C and C++.  All have their advantages or disadvantages.  As you go to 
larger and larger projects it makes more and more sense to use C, then 
C++.  If you are working on a large project with realistic requirements 
for processor efficiency and tools availability then C++ makes a pretty 
good choice.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

Tim Wescott wrote:

> >>Most everyone uses C or C++ these days.
> >
> > I take a bit of exception to the idea that "everyone uses C++",
>
> I do too, particularly because that's almost exactly not what I said.
> Was your misrepresentation of my statement a debater's trick, an honest
> mistake, or do you have your language blinders on a bit too tight today?

A strong mix of the first item in your list, plus a hefty dose of
simply being in a fey mood and ready for some fun.

However, in a semi-serious vein I must point out that you made no
distinction between the two in the sentence I requoted at top; your
sentence can reasonably be construed as "Everyone uses C or C++ and
it's a toss-up which".

If you meant to say "most everyone these days uses an HLL, and for
embedded applications most people choose to use C whereas a significant
minority choose to use C++" I would not have objected much - although,
in terms of code volume on the shelf, assembly language is still at
least 30% of all products. Consider that the really high-volume
projects use the really cheap micros. I've seen numbers that say asm
40%, C 40%, C++ 10%, other 10%, and I'm quite prepared to believe them.

The problem is, people who talk about this stuff get into their niche
and see everything else from that perspective. Few people routinely
work with a broad spectrum of systems from 4-bit to 64-bit and code
volumes from a few hundred bytes to a few dozen megabytes.

> Hysteria is a wonderful thing, if you use it right.

I believe that was partly my point. I hope I successfully conveyed a
sense of how silly it can be to get utterly dogmatic.

> > and cost/productivity/reliability
> > savings realized by moving to C++ are at the bad end of the spectrum.
>
> Not in my universe.

Is the spaceship ticket merely a token representing permission to take
one ride between these universes, or is the exact chemical composition
of the ink an important factor in the ride?

> I have written and/or maintained moderately large projects in assembly,
> C and C++.  All have their advantages or disadvantages.  As you go to
> larger and larger projects it makes more and more sense to use C, then
> C++.

I disagree. The scale slides from assembly language to C on a code
volume basis, fairly unambiguously. The choice to move to C++ generally
involves taking a right-angle turn into a different dimension; for
example, using an OS that is built on the assumption that the app layer
is written in C++, or using cheap app programmers to write reams of
brute force and ignorance on PCs, then recompile it to run in the
embedded environment. Code volume _DOES_ go up in these situations, but
I don't believe it's the driving force behind the move to C++; more a
consequence of the types of projects into which C++ might
(semi-rationally) be specified.

This is of course a religious issue on which no consensus can possibly
be reached, and I respectfully reserve the right to pursue my faith and
convert others where feasible, much as you will do.

Although it won't convince anyone who doesn't side with me already, I
am compelled to disclose that I have seen practical side-by-side
examples of separate engineering teams attempting to implement the same
functionality in C vs C++, and the results are quite unambiguous; more
bugs, endless development cycle, spiraling resource usage (both in the
hardware and amongst personnel!)

The incompetence argument is almost irrelevant, even if it's
applicable; if you have a box of screwdrivers but no hammer, why would
you try to assemble your woodwork with nails?

On 24 Feb 2006 07:19:02 -0800, "larwe" <zwsdotcom@gmail.com> wrote:

>
>Jonathan Kirwan wrote:
>
>> >My publisher is Elsevier, and they sell to anyone, anywhere, with money
>>
>> Strange.  Just the other day I just noted a comment by scientists who
>> refuse categorically to review for, submit to, or subscribe to
>> Elsevier owned publications -- unless and until they provide open
>> access to the scientific papers after 6 months.
>
>I don't think that changes my sentence above - Elsevier will _SELL_ to
>anyone with money, right?

I wasn't disagreeing with you, at all.  It was just funny to me, the
coincidence.  So this was a resonating response of mine to your
impulse function.  ;)

>Scientific papers are a special case, I don't pretend to understand the
>politics of academia. If I was going to emulate someone in my writing
>career, it would be Dean Koontz (mass market), not Shakespeare (art).

Et tu, Brute?  :)

>Writing technical books is no way to make a living of course, but it's
>fun and that's the main point. Once in a while a royalty check appears
>on my doorstep, and that's money from the heavens, typically disbursed
>frivolously.

Understood.  I've no idea how the technical books business compares
today with 15 years ago, 25 years ago, or 35 years ago.  But Asimov
wrote a lot about his own experiences as a young writer and how it
took on an unexpected life of its own, later on.  He never really
expected it to replace his "regular work" as a chemist.

Jon

larwe wrote:

> Jonathan Kirwan wrote:
> 
> 
>>>My publisher is Elsevier, and they sell to anyone, anywhere, with money
>>
>>Strange.  Just the other day I just noted a comment by scientists who
>>refuse categorically to review for, submit to, or subscribe to
>>Elsevier owned publications -- unless and until they provide open
>>access to the scientific papers after 6 months.
> 
> 
> I don't think that changes my sentence above - Elsevier will _SELL_ to
> anyone with money, right?
> 
> Scientific papers are a special case, I don't pretend to understand the
> politics of academia. If I was going to emulate someone in my writing
> career, it would be Dean Koontz (mass market), not Shakespeare (art).
> 
-snip-

Uh, check your history -- Shakespeare _was_ mass market in his time -- 
why do you think there's so much low comedy in everything he did, even 
his dramas?

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"ScottM" <scott@mayo.name> wrote in message 
news:1140796823.990469.42600@i40g2000cwc.googlegroups.com...
>
> As a software engineer, I'll put in a plug for OO languages. State
> machines like that are a lot nicer when you have an OO language. Though
> I personally DON'T like Java, because of the overhead it imposes, but
> it did make the state management a lot simpler. I could have done it in
> C, but the code would have been that much more obscure, and having
> things to be trivial to modify (as I change gear) is very important to
> me.

I prefer OO *design* and a neutral language. I routinely write OO in C, and 
much prefer it to C++, which to my mind is flawed (private elements in a 
public class definition? wtf?). I also have seen far too many C++ projects 
flounder due, IMO, to over-reliance on language features and not enough on 
design. I feel I can do a better job of implementing the spirit of OO in C 
(neutral, limited semantics) than I can in C++.

> Used with an eye
> towards efficiency (ie, no STL, no misuse of new/delete, leave the
> string classes alone, use well designed classes with a minimum of
> virtual declarations), it produces better code than C compilers,
> because C++ demands fully specified interface, so it can optimize more
> intelligently than C.

In theory, I take your point. In practice, not so sure.

> Maybe that's not true in the embedded world - no idea how good the
> tools are in this space.

They're getting better, for sure. It's far more common now to use C in 
embedded projects; years back we simply couldn't afford the overhead vs 
assembler. And it's not just that hardware resources (RAM etc) are cheaper - 
the venerable 8051 still sees a lot of use, and probably most 8051 code (I'm 
guessing) is written in C these days.

It's not just the tools, though, it's the understanding (as you indicate) of 
what's actually going on under the hood. The main thing about embedded work 
is that It Must Not Fail At Runtime. This often means no heap, and a healthy 
distrust of runtime language features (garbage collection, late binding etc 
etc). There's a mindset involved in writing code such that it's robust *by 
design* and simply can't generate runtime errors - one can write bad code in 
any language. My experience has been that C++ does not per se promote good 
code - it tends to promote obfuscation due to confusion over whether "data 
hiding" means "lack of side effects" (as it should) or "where the **** is 
this member variable defined and used??" ;). My (strongly-held) view: the 
clearer the code, the more likely it'll be bug-free.

> Unfortunately, I've seen a lot of stupid C++ - but then I've seen C
> which is absolutely obscene.

Yup ;).Fairly recently I had to maintain someone else's code. This guy was 
held in high respect - mainly, it seems, because no-one else could 
understand his code. His main() function had 1435 lines and 30-odd gotos. 
Good going, chap. (I scrapped it and started over.)

Steve
http://www.fivetrees.com 

Tim Wescott wrote:

> Uh, check your history -- Shakespeare _was_ mass market in his time --
> why do you think there's so much low comedy in everything he did, even
> his dramas?

Mmm, it was a very bad example but the best I could think of. Can you
name an author that would be recognized by name but doesn't write stuff
people actually read?

Tim Wescott wrote:
> larwe wrote:
> 
>> Jonathan Kirwan wrote:
>>
>>
>>>> My publisher is Elsevier, and they sell to anyone, anywhere, with money
>>>
>>>
>>> Strange.  Just the other day I just noted a comment by scientists who
>>> refuse categorically to review for, submit to, or subscribe to
>>> Elsevier owned publications -- unless and until they provide open
>>> access to the scientific papers after 6 months.
>>
>>
>>
>> I don't think that changes my sentence above - Elsevier will _SELL_ to
>> anyone with money, right?
>>
>> Scientific papers are a special case, I don't pretend to understand the
>> politics of academia. If I was going to emulate someone in my writing
>> career, it would be Dean Koontz (mass market), not Shakespeare (art).
>>
> -snip-
> 
> Uh, check your history -- Shakespeare _was_ mass market in his time -- 
> why do you think there's so much low comedy in everything he did, even 
> his dramas?
> 

And some give impression that Chaucer was "prim and proper" ;)