What's your (embedded) poison?

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Inspired by [1], a bit of a poll for yezall. What is your language of choice for avr32 development?

Do you have any complaints about the AVR32 support for your preferred language? I don't mean "I can't work buildroot to give me GCC", more like "I wanna talk Ada!". (Incidentally has anyone touched gnat for avr32? That would be sweet..).

Personally, my 2 bobs'orth is for C. I like to think that I can tell C++ programmers apart by the way they make blood run down the monitor and ectoplasm to spew forth from USB ports. But then I'm full of strongly voiced but weakly based opinions ;-)

I have put Scripting as a major language choice 'coz I know of a fair few embedded Linux projects which just require a little bit of bash glue around existing programs and libraries.

If you use Java, which JVM do you use?

If you're a Python, what limitations are there around the usable features?

Does anyone bother running full-fat Perl or does the easier-to-compile {mini,micro}perl work for you?

Thanks,
-S.

[1] http://www.mail-archive.com/linu...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

C, with a assorted scripting glue (some of it auto generated by C programs at runtime) and one heck of a meta-Makefile which I'm sure could be accomplished in an easier way.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll be the odd guy out. I chose C++ because it's what I'm most familiar with and because it's portable. Many of my apps get re-used across multiple projects which are built anywhere from Linux-Windoze. If I know I will be purely embedded, I go with C.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In what way is C++ more portable than C?

Portability is about writing your code that way... mine typically compiles for win32, blackfin-uclinux, avr32-linux, linux-i686-pc, etc...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For my situation the portability is more about cross applications than just platforms, i.e. code re-use.

Most of my applications are written in C++. I guess it's a bit of semantics how I used the term "portable".
I should have been more specific.

Again I'm most familiar with C++ which is why most of my applications are written this way. I work on many large projects which take advantage of C++ objects, inheritance and standard template library tools.

I'm also open to new ideas as to why I shouldn't use C++ in an embedded situation.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SFlynn wrote:
I'm also open to new ideas as to why I shouldn't use C++ in an embedded situation.
My only real dislike of C++ (though it's a big one) is that it's been cobbled together quite messily and as such it's incredibly easy to shoot yourself in the foot. If you go ahead and struggle through and use the more powerful features of the language (specifically exceptions and RTTI) you end up with massive, slow binaries. At least by embedded standards.

It seems to me that while it is easier to write some types of good code in C++ than C, it's also much easier to write horrendous steaming piles of bit-vomit. In my experience many C++ programmers fall in to that last category.

I do a lot of large projects as well. Anything which can afford to be done in Java is, but anything *-critical is done in C. As such I've now worked out how to write C in such a way as I can take it between projects with the minimum fuss. YMMV :-)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:
it seems to me that while it is easier to write some types of good code in C++ than C, it's also much easier to write horrendous steaming piles of bit-vomit.

I'm curious if the use of objects and inheritance fall into the "write horrendous steaming piles of bit-vomit" category? I do take occasional advantage of virtual function but I try to only use pure virtual when ever possible.

When I write my code I always start from a UML design before proceeding to code. I believe most C++ programers either skip this step because they don't understand the benefits of a well designed architecture (C programmers are not exempt from this either) or simply don't even know about UML.

squidgit wrote:
If you go ahead and struggle through and use the more powerful features of the language (specifically exceptions and RTTI) you end up with massive, slow binaries. At least by embedded standards.

I also don't like to use exception handling. I feel it complicates interfaces and is a lazy way of handling error conditions and can often be mishandled, leading to crashes. A simple boolean/enumerated return works perfectly fine in 99% of the cases.

As far as RTTI though... I do use the dynamic_cast call on limited occasions. It is the safest way to cast an assumed object type.
My question to you is will simply including this support in your project cause the whole binary to bloat/slow or will this be limited to the areas of code where the call is made?

Sorry to turn this thread into a C++/C efficiency breakdown thread but I thought it's still related to the threads basic goal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I voted C, I'm using C...

But since there is some magic java hardware block in the AVR32 AP7xxx I think it is strange that you can't run java programs under Linux by default on i.e. NGW100.

I mean sun did open source java some time back,
and if someone put a funny hardware block why don't make sure that you could use it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In some ways Ada is sweet:

S : AVR_String;
...
for U in S'Range loop
 ...
end loop

However, I am afraid I have to stick with C++.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SFlynn wrote:
I'm curious if the use of objects and inheritance fall into the "write horrendous steaming piles of bit-vomit" category? I do take occasional advantage of virtual function but I try to only use pure virtual when ever possible.

Objects and inheritance are good things, but they have to do with design, not implementation. In other words, you can do it in C as well.
Quote:
When I write my code I always start from a UML design before proceeding to code. I believe most C++ programers either skip this step because they don't understand the benefits of a well designed architecture (C programmers are not exempt from this either) or simply don't even know about UML.

I know UML and I hate it.

IMO it's almost impossible to come up with a good design up front. Better to just start implementing when you have a rough idea about the design and not be afraid to refactor and throw stuff away. Intelligent design sucks.

Quote:
I also don't like to use exception handling. I feel it complicates interfaces and is a lazy way of handling error conditions and can often be mishandled, leading to crashes. A simple boolean/enumerated return works perfectly fine in 99% of the cases.

Right on. I prefer error handling using "goto". I'm not kidding.

Quote:
As far as RTTI though... I do use the dynamic_cast call on limited occasions. It is the safest way to cast an assumed object type.
My question to you is will simply including this support in your project cause the whole binary to bloat/slow or will this be limited to the areas of code where the call is made?

I think it will add a bit of extra data to every object you have since dynamic_cast and friends need to be able to identify the type of the object at run time.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jsiei97 wrote:
But since there is some magic java hardware block in the AVR32 AP7xxx I think it is strange that you can't run java programs under Linux by default on i.e. NGW100.
Java on ARM is IMHO a strange story. As fare as I recall ARM insists you need a special ARM JTEK (Jazelle Java Technology Enabling Kit) license to be allowed to execute the BXJ instruction and enable the Jazelle extension. Again as fare as I recall there was a bit of a fallout between Sun and ARM about his years ago.

You can run Java without the Jazelle extension on ARM. If you use a JIT compiler it shouldn't be to bad - if you manage to find an ARM Java VM with a JIT compiler.

These days you can get open-source Java ME (not SE) for ARM in the form of the open-source phoneME project. I didn't check what they do with regards to Jazelle. Sun's Squawk should also run on ARM, but I am not sure if this was for ARM7 or ARM9.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

andreie wrote:
In some ways Ada is sweet:
Absolutely. I love the fact that if it's Right(tm) it lets you do it. Functional, prodecural, object-{based,oriented}, powerful threads and concurrency constructs, seamless distribution and rpc etc etc. Lovely!

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jsiei97 wrote:
But since there is some magic java hardware block in the AVR32 AP7xxx I think it is strange that you can't run java programs under Linux by default on i.e. NGW100.
The JamVM has been ported to AVR32 and works quite nice. The main limitation is that, by default, JamVM grabs 128MB of RAM when it starts up, something the NGW just don't have. Of course you can reduce that but it doesn't run as well.
jsiei97 wrote:
I mean sun did open source java some time back,
That doesn't mean a huge amount, there are plenty of standards more open than Java that the AVR32 doesn't support :-)
jsiei97 wrote:
and if someone put a funny hardware block why don't make sure that you could use it?
But yes this did puzzle me for a while. I guess it'll come some day

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SFlynn wrote:
squidgit wrote:
it seems to me that while it is easier to write some types of good code in C++ than C, it's also much easier to write horrendous steaming piles of bit-vomit.

I'm curious if the use of objects and inheritance fall into the "write horrendous steaming piles of bit-vomit" category? I do take occasional advantage of virtual function but I try to only use pure virtual when ever possible.
Nah, but as how says, they aren't language-specific. They're about program design and can be done in C (though things like polymorphism and dynamic dispatching kinda need a language which supportes them directly).
jsiei97 wrote:
When I write my code I always start from a UML design before proceeding to code. I believe most C++ programers either skip this step because they don't understand the benefits of a well designed architecture (C programmers are not exempt from this either) or simply don't even know about UML.
I certainly take good care to design my programs and UML is one way to represent that desing. It works for some, not for others. I personally tend to use a massive whiteboard covered in a bastardized UMLish set of scribbles, arrows and funny coloured markers; I'm quite a visual person like that. All code's better if you think about it first!
jsiei97 wrote:
squidgit wrote:
If you go ahead and struggle through and use the more powerful features of the language (specifically exceptions and RTTI) you end up with massive, slow binaries. At least by embedded standards.

I also don't like to use exception handling. I feel it complicates interfaces and is a lazy way of handling error conditions and can often be mishandled, leading to crashes. A simple boolean/enumerated return works perfectly fine in 99% of the cases.
Agreed. Of course, if the language is Java or Ada and the builtins throw exceptions then you're forced in to using them and end up turning a whole rocket ship in to lots of very small pieces of rocket ship ;-) http://en.wikipedia.org/wiki/Ari...
jsiei97 wrote:
As far as RTTI though... I do use the dynamic_cast call on limited occasions. It is the safest way to cast an assumed object type.
My question to you is will simply including this support in your project cause the whole binary to bloat/slow or will this be limited to the areas of code where the call is made?
The bloat will be universal, the slowing will be at each callsite. As you say above, it's the safest way to do that but with the safetynet comes tradeoffs, as always.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To bad you can not select two choices on the poll. Since I an using two of the options.

Life's to short for waiting on slow CPU's

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:
(though things like polymorphism and dynamic dispatching kinda need a language which supportes them directly).

You can do polymorphism in C by sticking a bunch of function pointers in a struct (which becomes your vtable). I don't know what dynamic dispatching is, but it sounds like the same thing except you're using a hash table instead of a struct.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how wrote:
squidgit wrote:
(though things like polymorphism and dynamic dispatching kinda need a language which supportes them directly).

You can do polymorphism in C by sticking a bunch of function pointers in a struct (which becomes your vtable).
Indeed you're right and I have done that (as has anyone who's touched kernel code I'm sure :-) ).
how wrote:
I don't know what dynamic dispatching is, but it sounds like the same thing except you're using a hash table instead of a struct.
It's kinda polymorphism in reverse:

declare
  H1: Human;
  H2: Human'Class := ...;
begin
  ... Frob (H1) ...
  -- Static binding: the compiler knows the specific type of H1.
  -- Therefore it can choose an implementation out of an
  -- overloaded set.

  ... Frob (H2) ...
  -- Dynamic binding: H2 may be anything from Human class,
  -- eg Human, Man, Woman whatever..  The compiler cannot
  -- select an implementation from an overloaded set at
  -- compile time so the appropriate implementation is
  -- dynamically chosen at run-time.
end;

And yes, if you tag your types then, along with a hashtable you can implement dynamic dispatching. I guess when it comes down to it everything hits the CPU looking the same and with appropriate dicking about C can be persuaded to generate pretty much any design pattern you want. Maybe I should have said "things like polymorphism and dynamic dispatching kinda need a language which supportes them directly or a good amount of time and patience." ;-)

-S.