| Forum: System Design |
 |
02. Aug 2008, 00:20 CET | Link |
Juha said:
I'm still thinking running two JVMs just to write to a serial port is a horrible waste of system resources. Unless somebody can show me howconsumer JREaka Java6N10 can do this effectively. However, if getting the daemon done in C is going to hold us back because most of us are more comfortable with Java then Java it shall be.
What jvm are we planning to target? As of Java 1.5, JVMs share memory space for class bytecode. So, running multiple JVM's isn't as resource intensive as it used to be. Not to mention that you can scale the heap size way back for simpler Java programs. With 10 minutes worth of effort, I'll bet you I can reduce the JVM's default memory footprint by 75%.
Not to mention that I've suggested before (and I'll continue to suggest) that for the device-level stuff, it's not necessary to have a full-blown JVM... I can boot-strap in a smaller set of classes and reduce the heap size even further.
As for CM15A implementation, I like it because it's based on file I/O abstraction which immediately isolates us from the native driver process. This however will only apply to certain operating systems.
I'm glad you like it :) You know, this is also an option on those same certain operating systems
for doing RS-232 communications as well? But the Java code to do it won't be platform independent (as my CM15A implementation is currently platform dependent as opposed to my CM11A and CM17A implementations which are platform independent).
I still instinctively prefer a socket abstraction for serial communication over Java Comms API. Socket is the more generic and therefore the most flexible solution of the two.
Yeah, I'm not exactly sure what happened to you in a past life to cause you to form this opinion of the Java Comm API, but the API and drivers themselves are relatively stable... the only issues I've ever seen come when you try to access the serial port from multiple processes (which is just wrong anyway :).
However, I agree, and still am of the opinion that it is better to isolate driver software (anything that does the actual communication to the hardware) in its own process so that you can kill and respawn that process at will. But I'm of the opinion that this is due to problems with hardware in general (not the driver or the software), as you never know when you'll need to reset
the hardware.
5 Replies: | |||
|---|---|---|---|
Wade Wassenberg wrote on Aug 02, 2008 00:20:
Mostly my concern is the memory use for the embedded system. Target Java 6 is fine. Google for Can you get the heap down to low single digit MB? Then my argument for C daemon will go away. Relatively speaking it might still be a waste of resource but a more acceptable waste. Wade Wassenberg wrote on Aug 02, 2008 00:20: Yes I do know we can go a long way with the file abstraction. And the reusability of those implementations is what I'm thinking about as well. It's just a choice we need to make really. We can easily get away with platform dependent implementations because the controller core is dynamic and modular, you just package the implementations you need. On the other hand being platform independent is 'nice'. But then I'd rather be platform independent via socket API than Java Comms API (both need to be backed by system binaries anyways) since the former seems like a more useful abstraction. I'm willing to leave it to whoever comes up with the code first at this point. Revise if stronger arguments appear. Wade Wassenberg wrote on Aug 02, 2008 00:20: Well it's mostly that Java Comms seems like a useless API. If the RI's are available on systems that abstract devices as files already, then what's the point? I was looking at rxtx.org and took that they were leaning a bit towards gnu.io as the API of choice. What's your take on it? Wade Wassenberg wrote on Aug 02, 2008 00:20: Well, isolation is the bottom line. I don't care what the underlying reason is.
Juha Lindfors |
|||
The only bad thing about jdk 6 is it's a little tougher for the mac users out of the box. I checked out the source and tried to build last night but had to jump through hoops to get a jdk6 installation up and going on my powerbook. It raises the barrier of entry for an albeit small slice of the community. |
|||
ruel loehr wrote on Aug 02, 2008 01:27: I'm gonna let you in on a little OSS community secret... see the thing to do here is to figure out how to get jdk6 working on your powerbook, and document each of the steps as you go... then when you're done... publish a step-by-step guide to doing it on your website. Call it a HowTo, and voila! You're Famous! :) And when you do, I promise, I'll reference it from all of my stuff whenever I need to plug Java on Mac :P Add a little tequila... to your Java http://www.agaveblue.org |
|||
ruel loehr wrote on Aug 02, 2008 01:27: Hey Ruel, Is that a situation that is expected to continue for a long time? There's no Java 6 at all or it just needs some extra work to set up? BTW, saw your note on build/test infrastructure. We'll definitely be needing work on that. Once we get a bit more code down ;-)
Juha Lindfors |
|||
Juha Lindfors wrote on Aug 02, 2008 00:55: I'll take a look at Java6U10 when I get some time and get back to you on this. Otherwise, I'll spend some time playing with my JVM... I've done it before, and so paring it down isn't too difficult. I'm positive I can get it into single digits of MB, but just how low is a challenge I'm willing to take up! :) Well it's mostly that Java Comms seems like a useless API. If the RI's are available on systems that abstract devices as files already, then what's the point? You're absolutely right. It's useless if you are running on a *nix and if you don't care about platform independent code. Platform independence is the only real benefit of the comm api. I was looking at rxtx.org and took that they were leaning a bit towards gnu.io as the API of choice. What's your take on it? Before I comment here, out of the interest of fair disclosure, I'd like to point out that I wrote the HowTo for rxtx.org and therefore, I'm a bit biased :) That being said, I think the reason Trent decided to go that way was so that he could eliminate the dependency on Sun's proprietary jar file which he couldn't distribute with his package (either because they wouldn't let him, or else he just didn't want to risk being sued). And it appears that Trent knew something we didn't, because he did this before Sun stopped supporting/allowing downloads of version 2 of Java Comm. The good news is that rxtx runs on windows, so it is still a good solution for writing platform independent rs-232 apps. In fact, due to my recent learning that Sun is no longer supporting java comm (as I learned today... I didn't have a reason to know it since I already have copies of it on my computer), it might behoove me to migrate TJX10P over to gnu.io. I might just add this to my list of TODOs. Well, isolation is the bottom line. I don't care what the underlying reason is. I care, I like to do things for the right reasons :P (cheap shot, I know... please don't hurt me :) Add a little tequila... to your Java http://www.agaveblue.org |
Add a little tequila... to your Java http://www.agaveblue.org