Tech Insider					     Technology and Trends


			      USENET Archives

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news.uchicago.edu!yellow.newsread.com!netaxs.com!newsread.com!grr!newsfeeds-atl2!
news.webusenet.com!pc01.webusenet.com!news4.srv.hcvlny.cv.net.POSTED!53ab2750!not-for-mail
From: "Steven Frankel" <ste...@61lismore.com>
Newsgroups: comp.robotics.misc
Subject: C++ in Microcontrollers
Lines: 19
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <3dRb9.16701$D02.237789@news4.srv.hcvlny.cv.net>
Date: Fri, 30 Aug 2002 16:02:42 -0400
NNTP-Posting-Host: 24.191.84.242
X-Trace: news4.srv.hcvlny.cv.net 1030741951 24.191.84.242 (Fri, 30 Aug 2002 17:12:31 EDT)
NNTP-Posting-Date: Fri, 30 Aug 2002 17:12:31 EDT
Organization: Optimum Online

Hi all. (I'm BA-ACK)
    After forsaking the robotics world for a while, I've returned (to the
despair of the assortment of mangled robot's I've half-built).
    Anyway, I know you get a lot of requests for help choosing a
microcontroller, so here's one more.
    I've tried the Basic Stamp and the Atmel AVR, which doesn't have a
decent, polished C++ development environment for it, if it has one at all.
    What I need is a good all-around microcontroller platform for general
robotics use that has a good C++ compiler or devlopment environment for
windows. Low-power is a plus. Built-in PWM channels are nice, too. Only
polished solutions. please. No arcane mCUs that no one actually hear of, let
alone uses, please.
    Sorry for the long-winded nature of this post, but I'm bored.

Thanks,
Steve

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newshosting.com!
news-xfer1.atl.newshosting.com!feeder.nmix.net!feeder.swcp.com!news.swcp.com!not-for-mail
From: hud...@swcp.com (Tramm Hudson)
Newsgroups: comp.robotics.misc
Subject: Re: C++ in Microcontrollers
Date: Sat, 31 Aug 2002 05:06:45 +0000 (UTC)
Organization: Southwest Cyberport
Lines: 24
Message-ID: <akpit5$9c8$1@iruka.swcp.com>
References: <3dRb9.16701$D02.237789@news4.srv.hcvlny.cv.net>
NNTP-Posting-Host: inago.swcp.com
X-Trace: iruka.swcp.com 1030770405 9608 198.59.115.17 (31 Aug 2002 05:06:45 GMT)
X-Complaints-To: usenet@swcp.com
NNTP-Posting-Date: Sat, 31 Aug 2002 05:06:45 +0000 (UTC)
X-Newsreader: trn 4.0-test72 (19 April 1999)

Steven Frankel <ste...@61lismore.com> wrote:
> [...] I've tried the Basic Stamp and the Atmel AVR, which doesn't have a
> decent, polished C++ development environment for it, if it has one at all.

Are gcc and g++ not sufficient for your needs?  They seem to fit
most everyone else's requirements on a wide range of platforms.
I use gcc for my AVR systems and have had no problems with lack
of polish.

Although, I would be quite amazed to see an embedded microcontroller
that has enough cpu to spare for running C++ code.  I realize that
you can write efficient C++, but given the limited memory and
lack of any caching, I would expect it to be much slower than
C or assembly.

I haven't tried it yet, but gcj (Java) compiles with the avr target,
too.  The f77 compiler does not, however...

Trammell
-- 
  -----|----- hud...@swcp.com                     H 240-476-1373
*>=====[]L\   hud...@rotomotion.com               W 240-453-3317
'     -'-`-   http://www.swcp.com/~hudson/                KC5RNF

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!snoopy.risq.qc.ca!ps01-chi1!
newsfeeds-atl1.usenetserver.com!news.webusenet.com!pc01.webusenet.com!
news4.srv.hcvlny.cv.net.POSTED!53ab2750!not-for-mail
From: "Steven Frankel" <ste...@61lismore.com>
Newsgroups: comp.robotics.misc
References: <3dRb9.16701$D02.237789@news4.srv.hcvlny.cv.net> <akpit5$9c8$1@iruka.swcp.com>
Subject: Re: C++ in Microcontrollers
Lines: 31
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <kxdc9.11146$Ot6.421212@news4.srv.hcvlny.cv.net>
Date: Sat, 31 Aug 2002 20:53:02 -0400
NNTP-Posting-Host: 24.191.84.242
X-Trace: news4.srv.hcvlny.cv.net 1030841552 24.191.84.242 (Sat, 31 Aug 2002 20:52:32 EDT)
NNTP-Posting-Date: Sat, 31 Aug 2002 20:52:32 EDT
Organization: Optimum Online

Why should C++ be so much less efficient than C? They both compile to the
same assembly code?
"Tramm Hudson" <hud...@swcp.com> wrote in message
news:akpit5$9c8$1@iruka.swcp.com...
> Steven Frankel <ste...@61lismore.com> wrote:
> > [...] I've tried the Basic Stamp and the Atmel AVR, which doesn't have a
> > decent, polished C++ development environment for it, if it has one at
all.
>
> Are gcc and g++ not sufficient for your needs?  They seem to fit
> most everyone else's requirements on a wide range of platforms.
> I use gcc for my AVR systems and have had no problems with lack
> of polish.
>
> Although, I would be quite amazed to see an embedded microcontroller
> that has enough cpu to spare for running C++ code.  I realize that
> you can write efficient C++, but given the limited memory and
> lack of any caching, I would expect it to be much slower than
> C or assembly.
>
> I haven't tried it yet, but gcj (Java) compiles with the avr target,
> too.  The f77 compiler does not, however...
>
> Trammell
> --
>   -----|----- hud...@swcp.com                     H 240-476-1373
> *>=====[]L\   hud...@rotomotion.com               W 240-453-3317
> '     -'-`-   http://www.swcp.com/~hudson/                KC5RNF
>

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
newsfeed.berkeley.edu!ucberkeley!sjc-peer.news.verio.net!news.verio.net!
feeder.nmix.net!feeder.swcp.com!news.swcp.com!not-for-mail
From: hud...@swcp.com (Tramm Hudson)
Newsgroups: comp.robotics.misc
Subject: Re: C++ in Microcontrollers
Date: Sun, 1 Sep 2002 01:52:46 +0000 (UTC)
Organization: Rotomotion Corporation
Lines: 71
Message-ID: <akrrte$vov$1@iruka.swcp.com>
References: <3dRb9.16701$D02.237789@news4.srv.hcvlny.cv.net> 
<akpit5$9c8$1@iruka.swcp.com> <kxdc9.11146$Ot6.421212@news4.srv.hcvlny.cv.net>
NNTP-Posting-Host: inago.swcp.com
X-Trace: iruka.swcp.com 1030845166 32543 198.59.115.17 (1 Sep 2002 01:52:46 GMT)
X-Complaints-To: usenet@swcp.com
NNTP-Posting-Date: Sun, 1 Sep 2002 01:52:46 +0000 (UTC)
X-Newsreader: trn 4.0-test72 (19 April 1999)

[ Rearranged to reflect actual flow of time ]

Steven Frankel <ste...@61lismore.com> wrote:
>"Tramm Hudson" <hud...@swcp.com> wrote in part:
> > Although, I would be quite amazed to see an embedded microcontroller
> > that has enough cpu to spare for running C++ code.  I realize that
> > you can write efficient C++, but given the limited memory and
> > lack of any caching, I would expect it to be much slower than
> > C or assembly.
>
> Why should C++ be so much less efficient than C?

It depends on how you code it.  As I wrote earlier, you can write
efficient C++.  However, most OO design techniques are have very bad
memory access behaviours and depend on memory caches to get decent
performance.

For instance, if you have an object with virtual methods, each time
you call one of them it has to be looked up in the object's vtable.
This indirection can be expensive, but is largely hidden since the
frequently accessed vtables should be in the CPU's cache.  Most MCU's
do not have any memory caches, so you have to take the memory hit
to get the vtable base from the object, then another to get the function
pointer and possibly another when you do an indirect jump.  You pay
this price every time you call that method; there is no amortization.

Templates can help, since they allow compile time resolution of most
functions while inheritance typically does not.  If you're not careful,
however, you can end up with lots of similar code fragments as each
templatized function gets expanded for each type that is passed in.
With a large memory desktop system, this is not as much of a concern.
On a MCU with 8 kb of program space, you would quickly exhaust your core.

Exceptions require stack storage of the continuation blocks.  Some
MCU's have very small hardware stacks that will easily be blown by
the exception cleanup code.

The STL typically trades space for speed.  Fine on a machine with
lots of core, but awful on an MCU.  The template expansion of the
STL containers will also cost you in program space.

And so on.  Most C++ features come with a price.  Stroustrup had a
goal of "If you don't use it, you don't pay for it" and that is
largely reflected in the memory and runtime costs of different features.  

> They both compile to the same assembly code?

If you stick to the intersection of C and C++, then they will likely
compile to the same assembly code.  However, you might as well have
written it in C at that point; the C++ compiler doesn't give you any
additional benefit on that subset.

If you are very careful and know what the compiler will produce for
different C++ constructs, then it is possible to write efficient C++
code.  Indepth examination of the compiler's output is required to
understand the costs of the different C++ features.  A good background
in the theory of programming languages also helps you know what is
likely to be involved in the implementation of each feature.

My experience is that it is possible to write space and speed
efficient C++.  It is not easy and does require far more knowledge
about the implementation of the libraries than typically required
plus an "unnatural chumminess with the compiler".  Down that way lies
madness and unportability...

Trammell
-- 
  -----|----- hud...@swcp.com                     H 240-476-1373
*>=====[]L\   hud...@rotomotion.com               W 240-453-3317
'     -'-`-   http://www.swcp.com/~hudson/                KC5RNF

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
bloom-beacon.mit.edu!newsswitch.lcs.mit.edu!snoopy.risq.qc.ca!newsfeed.news2me.com!
ps01-sjc1!news.webusenet.com!pc01.webusenet.com!news4.srv.hcvlny.cv.net.POSTED!
53ab2750!not-for-mail
From: "Steven Frankel" <ste...@61lismore.com>
Newsgroups: comp.robotics.misc
References: <3dRb9.16701$D02.237789@news4.srv.hcvlny.cv.net> 
<akpit5$9c8$1@iruka.swcp.com> <kxdc9.11146$Ot6.421212@news4.srv.hcvlny.cv.net> 
<akrrte$vov$1@iruka.swcp.com>
Subject: Re: C++ in Microcontrollers
Lines: 82
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <WPec9.12383$Ot6.475604@news4.srv.hcvlny.cv.net>
Date: Sat, 31 Aug 2002 22:21:07 -0400
NNTP-Posting-Host: 24.191.84.242
X-Trace: news4.srv.hcvlny.cv.net 1030846838 24.191.84.242 (Sat, 31 Aug 2002 22:20:38 EDT)
NNTP-Posting-Date: Sat, 31 Aug 2002 22:20:38 EDT
Organization: Optimum Online

Well, this is certainly an annoying thing to find out.I really don't like
programming in C very much. Making what should be object-oriented
programming conform to C is quite annoying and frustrating. I'm actually
quite surprised to see that people don't really program in C++ for robotics.
Ah... well...


"Tramm Hudson" <hud...@swcp.com> wrote in message
news:akrrte$vov$1@iruka.swcp.com...
> [ Rearranged to reflect actual flow of time ]
>
> Steven Frankel <ste...@61lismore.com> wrote:
> >"Tramm Hudson" <hud...@swcp.com> wrote in part:
> > > Although, I would be quite amazed to see an embedded microcontroller
> > > that has enough cpu to spare for running C++ code.  I realize that
> > > you can write efficient C++, but given the limited memory and
> > > lack of any caching, I would expect it to be much slower than
> > > C or assembly.
> >
> > Why should C++ be so much less efficient than C?
>
> It depends on how you code it.  As I wrote earlier, you can write
> efficient C++.  However, most OO design techniques are have very bad
> memory access behaviours and depend on memory caches to get decent
> performance.
>
> For instance, if you have an object with virtual methods, each time
> you call one of them it has to be looked up in the object's vtable.
> This indirection can be expensive, but is largely hidden since the
> frequently accessed vtables should be in the CPU's cache.  Most MCU's
> do not have any memory caches, so you have to take the memory hit
> to get the vtable base from the object, then another to get the function
> pointer and possibly another when you do an indirect jump.  You pay
> this price every time you call that method; there is no amortization.
>
> Templates can help, since they allow compile time resolution of most
> functions while inheritance typically does not.  If you're not careful,
> however, you can end up with lots of similar code fragments as each
> templatized function gets expanded for each type that is passed in.
> With a large memory desktop system, this is not as much of a concern.
> On a MCU with 8 kb of program space, you would quickly exhaust your core.
>
> Exceptions require stack storage of the continuation blocks.  Some
> MCU's have very small hardware stacks that will easily be blown by
> the exception cleanup code.
>
> The STL typically trades space for speed.  Fine on a machine with
> lots of core, but awful on an MCU.  The template expansion of the
> STL containers will also cost you in program space.
>
> And so on.  Most C++ features come with a price.  Stroustrup had a
> goal of "If you don't use it, you don't pay for it" and that is
> largely reflected in the memory and runtime costs of different features.
>
> > They both compile to the same assembly code?
>
> If you stick to the intersection of C and C++, then they will likely
> compile to the same assembly code.  However, you might as well have
> written it in C at that point; the C++ compiler doesn't give you any
> additional benefit on that subset.
>
> If you are very careful and know what the compiler will produce for
> different C++ constructs, then it is possible to write efficient C++
> code.  Indepth examination of the compiler's output is required to
> understand the costs of the different C++ features.  A good background
> in the theory of programming languages also helps you know what is
> likely to be involved in the implementation of each feature.
>
> My experience is that it is possible to write space and speed
> efficient C++.  It is not easy and does require far more knowledge
> about the implementation of the libraries than typically required
> plus an "unnatural chumminess with the compiler".  Down that way lies
> madness and unportability...
>
> Trammell
> --
>   -----|----- hud...@swcp.com                     H 240-476-1373
> *>=====[]L\   hud...@rotomotion.com               W 240-453-3317
> '     -'-`-   http://www.swcp.com/~hudson/                KC5RNF
>

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!
news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!cyclone2.usenetserver.com!
news.webusenet.com!feeder.nmix.net!feeder.swcp.com!news.swcp.com!not-for-mail
From: hud...@swcp.com (Tramm Hudson)
Newsgroups: comp.robotics.misc
Subject: Re: C++ in Microcontrollers
Date: Sun, 1 Sep 2002 03:09:24 +0000 (UTC)
Organization: Rotomotion Corporation
Lines: 65
Message-ID: <aks0d4$1hb$1@iruka.swcp.com>
References: <3dRb9.16701$D02.237789@news4.srv.hcvlny.cv.net> 
<kxdc9.11146$Ot6.421212@news4.srv.hcvlny.cv.net> <akrrte$vov$1@iruka.swcp.com> 
<WPec9.12383$Ot6.475604@news4.srv.hcvlny.cv.net>
NNTP-Posting-Host: inago.swcp.com
X-Trace: iruka.swcp.com 1030849764 1579 198.59.115.17 (1 Sep 2002 03:09:24 GMT)
X-Complaints-To: usenet@swcp.com
NNTP-Posting-Date: Sun, 1 Sep 2002 03:09:24 +0000 (UTC)
X-Newsreader: trn 4.0-test72 (19 April 1999)

[ Outlook damaged quoting fixed ]

Steven Frankel <ste...@61lismore.com> wrote:
> Well, this is certainly an annoying thing to find out.I really don't like
> programming in C very much. Making what should be object-oriented
> programming conform to C is quite annoying and frustrating.

OO is more of a design feature than an implementation one.  You can
write OO code in C without losing any of the features; it just does
not have the compiler support for the constructions.  This does have
the benefit of making the costs of the advanced OO designs more
apparent to you.

If the microcontroller is too small for your OO design and OO
implementation, you have two choices:

1.  Rewrite it in C or assembly
2.  Get a larger procesor

Sometimes #1 is easier.  Sometimes #2 is better.

> I'm actually quite surprised to see that people don't really program
> in C++ for robotics.

What did I write that implies that?  You asked about C++ for
microcontrollers, not for robotics in general.  I use a variety of
high-level languages in my robotics projects, just not on the small
microcontrollers that don't support it very well.

For instance, my current autonomous helicopter project has assembly
on the Tiny12, a MCU with no RAM:

  http://autopilot.sourceforge.net/cgi-bin/source?onboard/src/tinystick.S

I also use C for an embedded board with a AVR Mega163 that does sensor
processing and realtime tasks that are not suitable for C++ and general
purpose operating systems:

  http://autopilot.sourceforge.net/cgi-bin/source?onboard/rev2/servo.h

C++ is used for the onboard flight controller (that does not run in
realtime) and helicopter simulator to tune the controller:

  http://autopilot.sourceforge.net/cgi-bin/source?sim/src/controller/Guidance.h
  http://autopilot.sourceforge.net/cgi-bin/source?sim/src/heli-sim/Servo.h

Perl is used for data processing and groundstation display:

  http://autopilot.sourceforge.net/cgi-bin/source?downlink/bin/plotter
  http://autopilot.sourceforge.net/cgi-bin/source?efis/gs

And Java for onboard telemetry:

  http://autopilot.sourceforge.net/cgi-bin/source?downlink/net/sf/autopilot/
  downlink/uav/TelemetryServer.java

The C++, Perl and Java all run on non-microcontroller based systems.
Most of it is either Linux iPAQs onboard the helicopter or Linux laptops
for use in the field as ground stations.

Trammell
-- 
  -----|----- hud...@swcp.com                     H 240-476-1373
*>=====[]L\   hud...@rotomotion.com               W 240-453-3317
'     -'-`-   http://www.swcp.com/~hudson/                KC5RNF

Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!
snoopy.risq.qc.ca!ps01-chi1!newsfeeds-atl2!news.webusenet.com!pc01.webusenet.com!
news4.srv.hcvlny.cv.net.POSTED!53ab2750!not-for-mail
From: "Steven Frankel" <ste...@61lismore.com>
Newsgroups: comp.robotics.misc
References: <3dRb9.16701$D02.237789@news4.srv.hcvlny.cv.net> 
<kxdc9.11146$Ot6.421212@news4.srv.hcvlny.cv.net> <akrrte$vov$1@iruka.swcp.com> 
<WPec9.12383$Ot6.475604@news4.srv.hcvlny.cv.net> <aks0d4$1hb$1@iruka.swcp.com>
Subject: Re: C++ in Microcontrollers
Lines: 76
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <K7gc9.12840$Ot6.531188@news4.srv.hcvlny.cv.net>
Date: Sat, 31 Aug 2002 23:50:35 -0400
NNTP-Posting-Host: 24.191.84.242
X-Trace: news4.srv.hcvlny.cv.net 1030852202 24.191.84.242 (Sat, 31 Aug 2002 23:50:02 EDT)
NNTP-Posting-Date: Sat, 31 Aug 2002 23:50:02 EDT
Organization: Optimum Online

I see. Are there any microcontrollers available that can handle C++ without
any ultra-optimization or am I going to have to go up to an SBC?
"Tramm Hudson" <hud...@swcp.com> wrote in message
news:aks0d4$1hb$1@iruka.swcp.com...
> [ Outlook damaged quoting fixed ]
>
> Steven Frankel <ste...@61lismore.com> wrote:
> > Well, this is certainly an annoying thing to find out.I really don't
like
> > programming in C very much. Making what should be object-oriented
> > programming conform to C is quite annoying and frustrating.
>
> OO is more of a design feature than an implementation one.  You can
> write OO code in C without losing any of the features; it just does
> not have the compiler support for the constructions.  This does have
> the benefit of making the costs of the advanced OO designs more
> apparent to you.
>
> If the microcontroller is too small for your OO design and OO
> implementation, you have two choices:
>
> 1.  Rewrite it in C or assembly
> 2.  Get a larger procesor
>
> Sometimes #1 is easier.  Sometimes #2 is better.
>
> > I'm actually quite surprised to see that people don't really program
> > in C++ for robotics.
>
> What did I write that implies that?  You asked about C++ for
> microcontrollers, not for robotics in general.  I use a variety of
> high-level languages in my robotics projects, just not on the small
> microcontrollers that don't support it very well.
>
> For instance, my current autonomous helicopter project has assembly
> on the Tiny12, a MCU with no RAM:
>
>   http://autopilot.sourceforge.net/cgi-bin/source?onboard/src/tinystick.S
>
> I also use C for an embedded board with a AVR Mega163 that does sensor
> processing and realtime tasks that are not suitable for C++ and general
> purpose operating systems:
>
>   http://autopilot.sourceforge.net/cgi-bin/source?onboard/rev2/servo.h
>
> C++ is used for the onboard flight controller (that does not run in
> realtime) and helicopter simulator to tune the controller:
>
>
http://autopilot.sourceforge.net/cgi-bin/source?sim/src/controller/Guidance.
h
>   http://autopilot.sourceforge.net/cgi-bin/source?sim/src/heli-sim/Servo.h
>
> Perl is used for data processing and groundstation display:
>
>   http://autopilot.sourceforge.net/cgi-bin/source?downlink/bin/plotter
>   http://autopilot.sourceforge.net/cgi-bin/source?efis/gs
>
> And Java for onboard telemetry:
>
>
http://autopilot.sourceforge.net/cgi-bin/source?downlink/net/sf/autopilot/do
wnlink/uav/TelemetryServer.java
>
> The C++, Perl and Java all run on non-microcontroller based systems.
> Most of it is either Linux iPAQs onboard the helicopter or Linux laptops
> for use in the field as ground stations.
>
> Trammell
> --
>   -----|----- hud...@swcp.com                     H 240-476-1373
> *>=====[]L\   hud...@rotomotion.com               W 240-453-3317
> '     -'-`-   http://www.swcp.com/~hudson/                KC5RNF
>

			        About USENET

USENET (Users’ Network) was a bulletin board shared among many computer
systems around the world. USENET was a logical network, sitting on top
of several physical networks, among them UUCP, BLICN, BERKNET, X.25, and
the ARPANET. Sites on USENET included many universities, private companies
and research organizations. See USENET Archives.

		       SCO Files Lawsuit Against IBM

March 7, 2003 - The SCO Group filed legal action against IBM in the State 
Court of Utah for trade secrets misappropriation, tortious interference, 
unfair competition and breach of contract. The complaint alleges that IBM 
made concentrated efforts to improperly destroy the economic value of 
UNIX, particularly UNIX on Intel, to benefit IBM's Linux services 
business. See SCO v IBM.

The materials and information included in this website may only be used
for purposes such as criticism, review, private study, scholarship, or
research.

Electronic mail:			       WorldWideWeb:
   tech-insider@outlook.com			  http://tech-insider.org/