Go Down

Topic: Rascal (Read 2237 times) previous topic - next topic

Docedison

I saw an ad for a Rascal... Here:http://www.elektor.com/news/rascal-combines-linux-and-arduino.2208065.lynkx?utm_source=UK&utm_medium=email&utm_campaign=news&cat=microprocessor
Is this the "New Arduino"? Thanks are to the copy material from Elektor "Weekly # 180. I Quote:
"Built around a 400 MHz AT91SAM9G20 ARM9 from Atmel, the Rascal is an open source Linux board compatible with Arduino extension cards or shields. Programming the board is easy thanks to a library written in Python from Pytronics that allows easy access to peripherals and shields. The Rascal's firmware comes with a web server that can serve as a programming interface; you can write your applications directly in a web browser connected to the Rascal board.
Another "Clone" or a different ChipKit? Or the Long awaited answer to the Arduino 8 bit limitations?
It "Looks" very interesting... Although I have enough trouble fumbling my way through C & C++ without learning a new OS as well.
There is no Price quoted... "We are temporarily out of stock enter your email address..." So I did. More (I guess) will be revealed later"...
"400 MHz AT91SAM9G20 ARM9" certainly doesn't look very low power, running @ 400 Mhz... and I don't think one could pop a new chip in and "burn a bootloader" But perhaps learning the language in a form more easily relevant to C and C++ in the larger world... Might make learning the language easier, faster and more complete. My only real issue with the Arduino is learning the language... trying to sort what is relevant to the Arduino and what isn't is difficult at times.

Doc
--> WA7EMS <--
"The solution of every problem is another problem." -Johann Wolfgang von Goethe
I do answer technical questions PM'd to me with whatever is in my clipboard

AWOL

Quote
My only real issue with the Arduino is learning the language...

Is Python any simpler?
"Pete, it's a fool looks for logic in the chambers of the human heart." Ulysses Everett McGill.
Do not send technical questions via personal messaging - they will be ignored.

Docedison

No, qualified, though in that I can learn the whole language rather than a subset of the language. I am currently reading "The C++ Primer, 6th Ed" and "A Book on C" I like reading the Primer but I feel somehow that a lot of what I am reading simply isn't very applicable as it refers to C11 rather than C99. The Material in A Book on C... seems to presuppose that one has a basic knowledge of C and this makes many of the examples... Cryptic. Some I can read and understand fully and many might as well be ideograms for all I can get from them. in most cases the answers to my questions are to be found here but figuring out how to search for them is frequently a real challenge as there are many references to many things, many of which are not necessarily accurate or relevant i.e. for earlier versions of the IDE or simply "first attempts", It gets difficult at times to find good information. Sometimes I think I cry just to hear myself cry...

Doc
--> WA7EMS <--
"The solution of every problem is another problem." -Johann Wolfgang von Goethe
I do answer technical questions PM'd to me with whatever is in my clipboard

majenko

Why not just get a ChipKit and keep the same programming environment?

Yes, it may take a bit of work to port some unsupported libraries, but still less work than porting to an entire new language...

wanderson

And at a price of $175 it seems over priced when compared to its competitors (Rasberry Pi, Beagleboard, etc...)

http://store.rascalmicro.com/products/rascal-beta-unit
New true random number library available at: http://code.google.com/p/avr-hardware-random-number-generation/

Current version 1.0.1

cr0sh

#5
Jul 21, 2012, 09:07 pm Last Edit: Jul 21, 2012, 09:10 pm by cr0sh Reason: 1

My only real issue with the Arduino is learning the language...


Since you note in your profile that you are a retired electronics engineer, I'm not sure if what I am going to write will have much bearing, but it is what I would recommend to anyone getting into programming. It is a basic level of knowledge to keep in mind, especially if your intention is to become a professional software developer: Focus on the structure, not on the language.

What I mean by that, is that in virtually all modern (and not so modern) high-level programming languages you are likely to encounter, all utilize essentially the same concepts, and the same forms. This is mainly because (especially with more recent programming languages) they all have influenced one another. I would honestly surmise that the languages of the past which have mostly influenced languages of today, would be Fortran, C/C++, and Pascal.

All have basically the same control/branching structures. All have more or less the same forms of variable assignment structures. All have functional/procedural structures.

Of course, only C++ (discounting any more recent versions of Fortran and/or Pascal) has object-orientation. You can clearly see its influence, though, on other languages like Java, PHP, etc.

Languages like BASIC clearly have a flavor of Fortran about them (when I was a kid, translating Fortran code I found in books at the library over into BASIC for my home computer was something I enjoyed doing). I'm not sure where others like Python, Lua, and Perl fit in, but despite certain differences, they too have similarities with the legacy languages.

Once you understand the structures, the rest is just syntax. Think of it like the "romance languages" (Spanish, Italian, French): They all have a very similar structure, with the rest being syntax (it isn't quite the same, though, human languages being human and all, and subject to a much wider array of social, political, and other forces which don't exert themselves in the same way on computer languages, not to mention the age difference); if you learn one, you can (in theory) pick up the others much easier than, say - English or German.

That said, there are programming languages out there (but none you are likely to encounter or use) that will make you go "WTF?" - and some of them are based on interesting constructs meant to make them easier to utilize in certain scenarios or for certain purposes. Once you begin to appreciate what the world has settled on (mostly) for "standard programming structures", looking into these other languages can be an interesting diversion (like LISP, Prolog, Brainf*ck and Whitespace, etc)...
I will not respond to Arduino help PM's from random forum users; if you have such a question, start a new topic thread.

LOL, wanderson beat me with nearly the identical comments on RaspPi and $175 price.

Only thing I could add is if you want that internet control, the BitLash library could go a ways...



http://www.spcomputing.com

wanderson


I would honestly surmise that the languages of the past which have mostly influenced languages of today, would be Fortran, C/C++, and Pascal.

All have basically the same control/branching structures. All have more or less the same forms of variable assignment structures. All have functional/procedural structures.


I really don't think Fortran has had much influence on any language in the last 40 years.  Indeed I think that more recent incarnations of Fortran have been more on the receiving end of such influence.


Of course, only C++ (discounting any more recent versions of Fortran and/or Pascal) has object-orientation. You can clearly see its influence, though, on other languages like Java, PHP, etc.


C++ object orientation, like the additions for pascal like languages and presumably fortran like, are really add-ons.  You can use OO methods, but you are not required to.  Which is why Arduino code for the most part doesn't tend to use much of the OO functionaility.


Languages like BASIC clearly have a flavor of Fortran about them (when I was a kid, translating Fortran code I found in books at the library over into BASIC for my home computer was something I enjoyed doing). I'm not sure where others like Python, Lua, and Perl fit in, but despite certain differences, they too have similarities with the legacy languages.


Very early basic were indeed Fortran like though thankfully less import on hollerith coding, but once Gates got his empire going, he changed it in many modern ways.  Modern basics don't look like, nor have much in common, with traditional fortran


Once you understand the structures, the rest is just syntax. Think of it like the "romance languages" (Spanish, Italian, French): They all have a very similar structure, with the rest being syntax (it isn't quite the same, though, human languages being human and all, and subject to a much wider array of social, political, and other forces which don't exert themselves in the same way on computer languages, not to mention the age difference); if you learn one, you can (in theory) pick up the others much easier than, say - English or German.


All true, but it is not just syntax, it is methodology.  There is a world of difference between a traditional strucutural coding approach (which I think still works very well for embedded programs) and object oriented techniques which were originally developed for building very large applications.


That said, there are languages out there (but none you are likely to encounter or use) that will make you go "WTF?" - and some of them are based on interesting constructs meant to make them easier to utilize in certain scenarios or for certain purposes. Once you begin to appreciate what the world has settled on (mostly) for "standard programming structures", looking into these other languages can be an interesting diversion...


Forth is an excellent example of a different language, LISP is another...  Both make my eyes water...
New true random number library available at: http://code.google.com/p/avr-hardware-random-number-generation/

Current version 1.0.1

jraskell


Which is why Arduino code for the most part doesn't tend to use much of the OO functionaility.


What Arduino code would you be referring to?  Most (if not all) of the Arduino library utilizes OO substantially.  Serial, Servo, Wire, SPI, Ethernet, etc are all objects.

If you are referring to user code, that's entirely up to the user.  The vast majority of samples are written in straight C because they are targeted towards non-programmers.

I write the majority of my own projects utilizing C++.

wanderson



Which is why Arduino code for the most part doesn't tend to use much of the OO functionaility.


What Arduino code would you be referring to?  Most (if not all) of the Arduino library utilizes OO substantially.  Serial, Servo, Wire, SPI, Ethernet, etc are all objects.

If you are referring to user code, that's entirely up to the user.  The vast majority of samples are written in straight C because they are targeted towards non-programmers.

I write the majority of my own projects utilizing C++.



The Arduino libraries use more of the OO nature of C++, but not by much.  One specific example is that I/O tends to be function/procedure based  rather than stream based.  Another is that even when OO techniques are used the actual implementations are by nature limited.  An example that comes to mind is the print functionality which doesn't cover all of the actual object/type possibilities within the standard environment.

OO methodologies do not seem to work well for devices with such limited resources.  By nature good OO design tends to be less concerned with resource use, which makes sense since OO was developed to build programs that are larger than any uC can hope to run.  And efficient use of resources is the over riding concern of embedded design.
New true random number library available at: http://code.google.com/p/avr-hardware-random-number-generation/

Current version 1.0.1

jraskell

Quote
OO methodologies do not seem to work well for devices with such limited resources.


I think that's a common misconception.  The constraints imposed by these limited resource micros are no less constraining using procedural methodologies than they are with OO methodologies.  The vast majority of OO features have little to no real impact on either code size or code performance.  And the few exceptions that do exist should be taken into consideration even when used on PC based platforms (at the very least, the programmer should be aware of the impact they have).

Encapsulation:  Classes in and of themselves have no impact on binary size or performance.  A handful of functions and global variables will take up just as much ram and flash as a class encapsulating them.

Inheritance: Excluding virtuals (which is really polymorphism), utilizing inheritance also has no impact on binary size or performance.  It's just good code reuse practice.

Polymorphism: This does impose some overhead in both performance and RAM (as a vtable needs to be created and then used at runtime to determine which virtual method needs to be called).  If used extensively, the RAM overhead can certainly get out of hand, but judicious high level usage can still provide some value-add even on these micros.

Function Overloading:  Another handy feature that does get used extensively by the Print class.  Again, no impact on code size or performance.

Operator Overloading:  Same as Function Overloading.

Templates:  The only thing Templates change is the amount of code you have to write, and it reduces that.  Another win there.

Now, once we start getting into comparing the C 'standard' library to the STL, things become less favorable, but that's mitigated by the fact that Arduino does not provide an implementation of the STL (though one or two third party implementations are floating around out there), nor is it a valid reason for not utilizing all the other strengths of the C++ language.

wanderson

Code written for re usability will almost always be more bloated than code customized for the specific task.  O-O only makes sense if the design objective is reusability.  The Arduino platform is a perfect example.  What little OO in the Arduino, which is what makes it so easy and begginner friendly is precisely why the Arduino way is so much slower and more flash intensive than straight C/C++ for the AVR written for specific tasks.

Compound that with OO's feature of masking the low level implementation, and you have a mechanism that will produce bloated code when used by typical programmers.  Now it is certainly possible for a seasoned OO programmer to write code that is as efficient as that written in straight C or even asm, provided they pay attention to the low level implementation of that code.  And if they are doing that there is little (to no) benefit in the OO approach over the previous Structured approach.  OO only becomes a clear advantage when the resources are for all intents unlimited or when the project size is extremely large.  And that would be defined large on a scale where even the most extensive and powerful embedded application would still qualify as small.
New true random number library available at: http://code.google.com/p/avr-hardware-random-number-generation/

Current version 1.0.1

jraskell


Code written for re usability will almost always be more bloated than code customized for the specific task. 


That is a rather vague statement, and while I wouldn't argue it's technical validity, I will absolutely argue it's practical impact.  I'm assuming here that you really mean optimized when you say customized, since virtually any code one would write can be considered 'custom'. The reality is, very few projects require optimized code to get the job done.  Reusability should ALWAYS be a design objective, with optimizations performed only where deemed necessary to meet the goals of the project.


Compound that with OO's feature of masking the low level implementation


I wholeheartedly disagree with that statement.  Masking of low level implementation has nothing to do with OO vs procedural.  If you're using a third party library that isn't open source, then the implementation of that library is masked from you regardless what language it's written in.  If the sources are available, then it's implementation isn't masked.


Now it is certainly possible for a seasoned OO programmer to write code that is as efficient as that written in straight C


I've already shown that the majority of C++ features incur no overhead with regards to code size or performance.  Bottom line is, there is nothing inherently inefficient about C++ compared to C.  That's a fallacy, plain and simple.  Yes, it takes experience to write efficient code, but an inexperienced programmer is just as likely to write inefficient C code as they are C++ code.  And for the record, though not really applicable to the Arduino, the STL is a very efficient library.


OO only becomes a clear advantage when the resources are for all intents unlimited or when the project size is extremely large.


Again, I have to disagree.  The advantages of OO code become clear with just a few thousand lines of code, which doesn't even come close to pushing the limits of the Arduino unless it makes extensive use of RAM or utilizes some fairly large third party libraries (the latter case really meaning it's much larger than a few thousand lines of code). 

Encapsulation alone is far better than having a few dozen global variables and dozens of functions whose only real organization is in their naming convention.  Hell, it's better than having half a dozen globals and a handful of functions in even a small project.

florinc

Quote
Polymorphism: This does impose some overhead in both performance and RAM (as a vtable needs to be created and then used at runtime to determine which virtual method needs to be called).  If used extensively, the RAM overhead can certainly get out of hand, but judicious high level usage can still provide some value-add even on these micros.

Polymorphism without new() is like a fish without a bicycle.

jraskell

And what is a fish going to do with a bike?

Go Up