Notices
Results 1 to 19 of 19

Thread: C++ vs. Java

  1. #1 C++ vs. Java 
    Forum Freshman
    Join Date
    Jun 2010
    Posts
    15
    I'm just wondering, but what would be better to use to program a processor chip C++ or java??


    Reply With Quote  
     

  2.  
     

  3. #2  
    Forum Freshman
    Join Date
    Feb 2010
    Posts
    84
    Define "processor chip" please...

    If you are talking embedded micro-controllers like the PICs, I'm not sure there is a Java available. Java makes it difficult/impossible to get to the actual hardware and uses RAM memory at the drop of a hat, so it might not be a good choice for small systems.


    Reply With Quote  
     

  4. #3  
    Forum Freshman
    Join Date
    Jun 2010
    Posts
    15
    oh, sorry, I decided to use a stamp processor

    yeah, don;t think i will be using Java, seeing as it creates more of an application program, where as i need something with a more custom close to a robotics operating system type software that works on instant command. so possibly some form of C unless there are other languages I'm not looking into...
    Reply With Quote  
     

  5. #4  
    Forum Freshman
    Join Date
    Feb 2010
    Posts
    84
    Well, the Basic Stamp is exactly that. I believe the big selling point is the BASIC programming environment that makes it fairly easy to use, but IIRC lacks things like a random() call...I'm a bit of a stick-in-the-mud when it comes to (over)simplifying things so I have not seriously used the Stamp.

    I have seen two examples of Java post-processors for embeded systems (for the first Lego MindStorms and an earlier device with which I was futzing). They took the Java and compiled it down to embedded code rather than running a JVM on the device, and therefore had a number of limitations. Which is kinda funny since Java was originally proposed as a low level embeded language and has now become a high-level server standard...

    The most useful language for small systems is C, without the ++, so that is probably what you will find out there. MicroChip has nice free(ish) C compilers and libs for all their PIC chips. And C will do you well in learning other languages and environments.
    Reply With Quote  
     

  6. #5  
    Forum Freshman
    Join Date
    Jun 2010
    Posts
    15
    Ok, well is Basic Stamp is easy to use, then i will most likely stick with it.

    Well if they compiled the Java down to an embedded code and it was limited, it sounds like they took a few steps backwards......but since it went from a low-level to a high-level, i guess that was an alright move

    Ok, i will take a look into C. I guess it couldn't hurt to learn the original language
    Reply With Quote  
     

  7. #6  
    Forum Freshman
    Join Date
    Feb 2010
    Posts
    84
    For robot cars you might look at this cute little kit:
    http://www.junun.org/MarkIII/Manual/index.jsp
    It uses a PIC chip, and some kind of programming environment that I've forgotten about. I thought it was a BASIC Stamp thing, but that must be some other kit.

    As I said, I'm not thrilled with Basic of any kind, and while the Stamp is pretty easy to learn and use it looks to be fairly limiting in the long run... There's also some hypotheses that learning Basic as your first language makes it impossible to learn a real programming language later on...

    I actually like Java as a reasonable combination of procedural programming and Object (dis)Orientation, but the OO bits can distract one from learning _proper_ structured design (which is somewhat impossible with Basic as well). Compiling Java down to machine code is a good compromise for embeded systems. What you lose is all the schmancy reflection and just-in-time class loading that are only useful in big systems for the most part anyway.
    Reply With Quote  
     

  8. #7  
    Forum Freshman
    Join Date
    Jun 2010
    Posts
    15
    Ok, so would you suggest using a PIC chip for robotics ( i proabably should have said what it was being used for from the begining)?

    Well, in this case maybe i will put off learn Stamp for a while

    Hmmm, doesn;t really sound that bad, i will look into this more....
    Reply With Quote  
     

  9. #8  
    Forum Freshman
    Join Date
    Feb 2010
    Posts
    84
    That all depends on the robot, non?

    If what you want to do is start and stop a couple of motors to make a little car run around on your floor, pretty much anything will do. Get a kit with the Stamp and have at it.

    Once you get more sensors and actuators you may need more I/O or processing poop and will want to graduate to more complicated controllers. The PICs run the gammut, and the Stamp is just a PIC (or some other brand of micro-controller, I forget) with a simple programming interface. The Arduino is the latest darling of the robishobby world, you might look into that as well.

    My RoboCars: http://www.etantdonnes.com/ROBOCAR/Collective/ contain an ATmega128 - a grown up PIC -- and a two-way radio which is connected to a PC running the real programs. The cars themselves just implement commands to move and sense and report back to base. I don't have a good way to monitor the processing load, but I suspect that the chip is mostly loafing with 13 sensors and two motors. Compare and contrast with my handwaving estimate of human I/O at about 150M sensors (including all the eye rods and cones) and some unknown millions of motor neurons, and you may want to prepare for upward expansion...
    Reply With Quote  
     

  10. #9  
    Forum Freshman
    Join Date
    Jun 2010
    Posts
    15
    hmmmm, yes basically one that runs motors, for now....

    Yeah, i just heard about the arduino actually, it is suppose to be one useful little sucker, supposedly

    sounds good, but one question, can the programs work w/o having to monitor it?
    ~If you don't know, then you better ask somebody~
    Reply With Quote  
     

  11. #10  
    Forum Freshman
    Join Date
    Feb 2010
    Posts
    84
    OK, now we are apparently in an infinite loop.... define: "monitor it"...

    If you mean: Can one make an autonomous system that doesn't get stuck in a corner? Yes, given a sufficiently non-complex corner. Just as with humans there can arise situations which are beyond the capabilities of the system.
    Reply With Quote  
     

  12. #11  
    Forum Freshman
    Join Date
    Jun 2010
    Posts
    15
    Ok, sorry, what i meant was can the program maintain itself with out my watching it operate? so if it were to get into a situation it could fix, then it should just shut down until it can be tended to. But mostly, if i were to leave the room, leaving the computer running that is broadcasting the signal to the robot while I am away, could it still function to its highest possible capacity?
    ~If you don't know, then you better ask somebody~
    Reply With Quote  
     

  13. #12  
    Forum Freshman
    Join Date
    Feb 2010
    Posts
    84
    I see, now yer getting all philosophical on me...
    No copenhagen quantum mechanics here.

    One answer is: It's as good as your programming, until either the hardware or software crashes.

    Another is: As long as the environment is less complex than the program.

    My little guys have a rectangular arena with walls that they can't jump. In one instance they have a simple three state FSA that takes all four bumper signals (actually six counting a general collision detector and a battery stall current signal, both of which work...sometimes) as inputs, and controls the two wheel motors as outputs. So they can -- usually -- "know" when they hit something and respond with a back-up-and-turn-away motion. I've had five of them running for hours in un-attended (both by me and mostly any audience as well) installations a number of times. I've also had them learn how to respond with reinforcement learning code, as described in that presentation I ref'ed some time back.

    In a more complex environment -- say, more cars, cul-de-sacs, changing boundaries, and/or failing sensors -- three states might not be enough to keep them from just ramming into walls until their batteries die. But, of course, anything is (im)possible with software...

    You say "leaving the computer running that is broadcasting the signal to the robot" which I think is presupposing that you have a radio connection to your robot car (like mine). And in fact, a bi-directional radio. This is taking you out of the Basic Stamp and Arduino camp, as I don't know that either of those has two-way RC features. For the time being I would stick with just having the local controller on the robot deal with all the situations itself. You can expand later, non? Actually, have you considered the Lego MindStorms kits? They're pretty nice.
    Reply With Quote  
     

  14. #13  
    Forum Freshman
    Join Date
    Jun 2010
    Posts
    15
    Yes, I am occasionally very philosophical
    not really too good at quantum mechanics

    So there will be many different outcomes varying on the different wares and environments the robot will range in.

    Extremely random questions about these robots, what purpose is it they serve or are they just recreational?

    So your saying I can plan and plan, but there will be only two overall outcomes:
    1) I will keep planning and never actually build the robot
    2) build the robot and miss something all most impossible to for see

    But letting the controller on the robot deal with it's own situations, isn't that a bit A.I.(ish)?

    Ahhh, Lego mindstorms, now there were some good times they're very good but it's the lego part that gets in my way
    ~If you don't know, then you better ask somebody~
    Reply With Quote  
     

  15. #14  
    Forum Freshman
    Join Date
    Feb 2010
    Posts
    84
    "Plans are useless. Planning is essential." Dwight Eisenhower

    Any kind of responsive system is "A.I.ish", but you may be thinking of adaptive rather than just behaviorist stimulus-response. Start simple and build up. I've heard the new Lego system is pretty good, and there were other programming systems for the old Mindstorms that allowed one to bypass the kid-level graphical programming system. I've seen some pretty sophisticated Lego 'bots made by high school students.
    Reply With Quote  
     

  16. #15  
    Forum Freshman
    Join Date
    Jun 2010
    Posts
    15
    True, true

    oh then its the adaptive part of A.I. programs i dislike
    As for the new lego mindstorms, NXT, I like its capabilities but it took away the many essential part of Legos, the bricks, other wise there good programing wise, they also have new sensors which are decent, but the motors are WAY to big. but the use ethernet cords to communicate. Guess that makes it easier to hack if nessecary *wink wink*
    ~If you don't know, then you better ask somebody~
    Reply With Quote  
     

  17. #16  
    New Member
    Join Date
    Jul 2010
    Posts
    3
    C++, data and functions can be declared outside of any class definition.Java, all data and functions must be declared within class definitions.C++, Java permits only one parent per class.Java class constructor functions can also explicitly invoke parent constructors with the super keyword.
    [Spam Link Removed]
    Reply With Quote  
     

  18. #17  
    Forum Freshman
    Join Date
    Jun 2010
    Posts
    15
    There are more limits on java per class where C++ has very few limits, basically
    ~If you don't know, then you better ask somebody~
    Reply With Quote  
     

  19. #18  
    New Member
    Join Date
    Jul 2010
    Posts
    1
    Definitely java would give you the best result and security too...



    computer repair
    Reply With Quote  
     

  20. #19  
    Forum Freshman
    Join Date
    Feb 2010
    Posts
    84
    PostPosted: Wed Jul 21, 2010 10:53 am Post subject:
    There are some differences between C++ and Java :

    1. Java is slightly slower than C++.
    2. Java garbage collection is the big productivity gain.
    3. In C and C++ data types (such as int) are hardware dependent while in Java, the size and manner of representation of data is specified, to facilitate machine independence of code.
    4. C++ support pointer while Java doesn't
    5. C++ support multiple inheritance while Java can't.
    Just a few minor points....

    1. The speed issue seems to go back and forth. Java has made some major strides, but if you need to squeeze the last flop out of something I guess C/ASM is still THE WAY...

    2. Yay GC!!! Keeping track of all those pointers is probably the reason C is so slow (hah).

    3. The actual "int" type in Java is native in representation, but specified to be 32 bits in all cases. With C the size of the int can vary according to the platform. This has lead to the header-meta-types int16_t, int32_t, etal, which you can probably never count on having defined anyway. The annoying Java int issue is that, if you use the regular serialization process to write ints to a file it puts them in Motorola (big-endian) format, whereas just about every platform in use these days is little-endian...

    4. Yay Pointers!! I wish I could use them in Java, but then all the other features would be compromised.

    5. Multiple inheritance...meh...Java has Interfaces which are cleaner and almost as useful.

    AND:

    6. I wish Java had a #define #ifdef equivalent. But that opens a can'o'worms.
    Reply With Quote  
     

Bookmarks
Bookmarks
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •