Simple Logger

Developer topics relating to software that logs data from ECUs

Moderator: Freon

Java always suffers that misconception

Postby ll » Sun Jun 05, 2005 11:18 am

I think you have some misconceptions about Java and high-level programming in general. Now I make no claims to be an absolute authority but I have been working in the field for quite awhile now with various tools. Each have their own strengths but I think you misunderstand Java's. So let's review

First, I think your claim that java code can easily get "HUGE and slow" is entirely false. It is *much* harder for bad programmers to write bad code in Java (Not that we have any bad programmers here =]) than in C++ or any other natively compiled language.

Secondly, Java provides a massive library of utility objects and frameworks for dealing with most daily development needs. Meaning we won't have to roll our own or deal with tricky integration by using a 3rd party library.

Java pluses:
1. Collections (Lists, Maps, Sets, ect) and Utility classes
2. Abstracted native OS interaction (Files, Streams, I/O, network, GUI)
3. *native* cross platform support (we don't have to do anything to make this run anywhere)
4. Free quality IDEs (Eclipse is great, Netbeans, Sun One).
5. Memory is managed for you.
6. Strict packaging system and OOP implementation promotes clean and well-designed code.

Java Minuses:
1. Huge JRE to install and configure (this is more difficult on windows, IMO)
2. Large memory footprint for standard JRE, but they do have special embedded jvms for portable devices.

I know somebody wants me to put "Swing/AWT are really slow" here, but that just isn't true anymore. Don't believe me? go use OpenOffice or Azureus


C++ pluses:
1. Blisteringly fast (unecessarily fast)
2. teeny-tiny footprint, fine grained memory management
3. Widly used (but declining in recent years).

C++ minuses:
1. Not natively cross-platform compatible. It can be done but it is cumbersome and confusing. Lots of pre-processor marcros and complex compile-time code selection. A toolkit like QT might mediate a lot of this, but I'm not certain.
2. Memory management, unchecked bounds, killer debugging sessions

Now if you wonder why pretty much every major corporation uses a VM based language like Java or MS .NET it is because they deal with a lot of the hassle C/C++ guys used to, so you get to write more application and less framework.

Now if some portion of the code is too slow in Java there is always the option of JNI so you can have your cake and eat it too, but I don't think we'll have a performance requirment anywhere near what would necessitate that. The application I have running currently is just as fast and a lot more functional than anything else I've seen posted here.

I welcome any other thoughts on this platform debate.
ll
 
Posts: 6
Joined: Wed Jun 01, 2005 12:43 pm

I agree with one exception

Postby bofh » Sun Jun 05, 2005 11:23 am

Well... Two. First, I do not think anything needs to "stop." But the sooner it is organized, the more efficient code production will become.

Second, handheld tools are awfully nice. So don't forget WinCE (How appropriate that is spells wince) and Palm. How much nicer would it be to dump and ECU or flash quickly with the Palm, rather than boot a laptop? Yes, a full system should be primary, but keep in mind that we will want to eventually port this to handhelds. Knowing this in the planning stages can help a lot.

PS: My spelling sucks... Two edits this time.
bofh
 
Posts: 50
Joined: Thu Dec 30, 2004 1:59 pm
Location: Houston, TX

Code is up

Postby ll » Sun Jun 05, 2005 9:34 pm

As promised, My code is up source and all. Please be forgiving, I was in a bit of a rush to put this all together before we leave for our honeymoon.

http://forums.openecu.org/viewtopic.php?t=73
ll
 
Posts: 6
Joined: Wed Jun 01, 2005 12:43 pm

Postby realwomble » Sun Jun 05, 2005 9:49 pm

[ Ah whatever. I put my source back up too. ]

Too many egos for one thread.

You're all wrong. C and assembler is the way to go. :lol:
realwomble
 
Posts: 21
Joined: Thu May 26, 2005 4:07 pm
Location: Seattle, WA

No Source?

Postby ll » Mon Jun 06, 2005 6:32 am

realwomble, I checked your thread. The source link points at the same archive as the binary one. Just a .exe and a readme in that one =]. Let me know when you get the source up I'm excited to see your work!
ll
 
Posts: 6
Joined: Wed Jun 01, 2005 12:43 pm

Postby realwomble » Mon Jun 06, 2005 12:26 pm

Link fixed.... E_CUT_N_PASTE

Don't be too excited :) it's just C.

Enjoy your wedding / honeymoon :)
realwomble
 
Posts: 21
Joined: Thu May 26, 2005 4:07 pm
Location: Seattle, WA

Re: Code is up

Postby bofh » Mon Jun 06, 2005 7:04 pm

ll wrote:As promised, My code is up source and all. Please be forgiving, I was in a bit of a rush to put this all together before we leave for our honeymoon.

http://forums.openecu.org/viewtopic.php?t=73


You're about to go on your honeymoon, and your coding? Dude... You NEED an honeymoon! :P Might be time to start a downloads section... Cool stuff coming now!
bofh
 
Posts: 50
Joined: Thu Dec 30, 2004 1:59 pm
Location: Houston, TX

Postby west_minist » Fri Jun 10, 2005 2:59 pm

crazymikie wrote:
http://mikeschear.com/SSM/

In there is:

logger_DEVEL3.c - this is the latest version of the program I've been playing with. It's based off the original version Visceral posted, but I've made it easier to add/remove parameters.

Thanks
Mike


How do I run the code to get stats? do I apply --AFR and so on?

Right now when I ran it, no logging whatsoever.
Last edited by west_minist on Fri Jun 10, 2005 3:15 pm, edited 2 times in total.
west_minist
 
Posts: 515
Joined: Fri Jan 07, 2005 1:31 pm
Location: Barbados

Postby west_minist » Fri Jun 10, 2005 3:12 pm

higB_0x05 wrote:
It worked:

Code: Select all
Message: 80 10 F0 1 BF 40
Message: 6 10 F0 1 BF 40 80 F0 10 39 FF A2 10 11 3D 12 59 40 6 73 FA CB A6 2B 81 FE A8 0
 80 0 0 0 0 0 0 0 DC 0 0 75 1E 30 C0 F0 22 0 0 43 FB 0 F1 0 0 0 0 0 0 0 F0 B8
TIME     RPM     MRP     IGN     AFR     KNK     SPEED   TPS     MAF     EGT     LIT
0.397    721     -10.0   16      14.59   0.0     0.0     1.18    2.99    392     63.5
0.536    720     -10.0   16      14.59   0.0     0.0     1.18    3.03    392     63.5
0.673    712     -10.0   16      14.59   0.0     0.0     1.18    3.03    392     63.5
0.811    702     -10.0   17      14.59   0.0     0.0     1.18    3.03    392     63.5
0.949    700     -9.9    17      14.70   0.0     0.0     1.18    3.06    392     63.5




p.s. im aaronwrx@nasioc[/code]


Hey higB_0x05,

what did you do to get the stats? Did it started logging one connected?

I am using the openport 1.0 connector.
west_minist
 
Posts: 515
Joined: Fri Jan 07, 2005 1:31 pm
Location: Barbados

Postby Visceral » Tue Jun 21, 2005 12:38 pm

Glad to see all the progress people are making. :)

west_minist --
My guess is it may be a serial port issue. The program has it hard coded to be /dev/ttyS0. Do you know what com port the openport connector is assosciated with? You may want to try /dev/ttyS1, /dev/ttyS2, etc.
Visceral
 
Posts: 23
Joined: Thu Dec 30, 2004 10:21 am

Postby west_minist » Tue Jun 21, 2005 6:46 pm

Visceral wrote:Glad to see all the progress people are making. :)

west_minist --
My guess is it may be a serial port issue. The program has it hard coded to be /dev/ttyS0. Do you know what com port the openport connector is assosciated with? You may want to try /dev/ttyS1, /dev/ttyS2, etc.


I change it to ttys1 with no effect. I work on linux machines to. Its Com 1 I am using, which is /dev/ttys0
west_minist
 
Posts: 515
Joined: Fri Jan 07, 2005 1:31 pm
Location: Barbados

Postby Visceral » Wed Jun 22, 2005 11:54 am

Did you step through it in the debugger? If it can't talk to the ECU, or if your ECU's response to the initial send is shorter than expected, it will hang on the recvMsg call. If that's the case, try changing the length of the response (68) to a smaller number.

At a minimum, the program should print:
Message: 80 10 F0 1 BF 40
Visceral
 
Posts: 23
Joined: Thu Dec 30, 2004 10:21 am

Postby west_minist » Wed Jun 22, 2005 2:54 pm

It prints that out. I think I even enable bebug in the program, but to no a vail.

int debug = false ;

change to true

I try the running through the debugger to see what is going on.

I will and see later what happens.
Last edited by west_minist on Wed Jun 22, 2005 4:25 pm, edited 2 times in total.
west_minist
 
Posts: 515
Joined: Fri Jan 07, 2005 1:31 pm
Location: Barbados

Postby west_minist » Wed Jun 22, 2005 2:59 pm

I am using mike code.

http://mikeschear.com/SSM/
west_minist
 
Posts: 515
Joined: Fri Jan 07, 2005 1:31 pm
Location: Barbados

Postby Visceral » Fri Jun 24, 2005 1:32 pm

Try replacing the recvMsg function with this one, and tell me what the output of the program is. (With the VTIME parameter set to a value > 0, the read will timeout if at least one character is read.)

Code: Select all
int recvMsg(ecu_t *e, u_int8_t* msg, int len)
{
  struct termios oldtio, options;
  tcgetattr(e->fd, &oldtio);
   
  tcgetattr(e->fd, &options);
  options.c_lflag = 0;
  options.c_cc[VTIME] = 10;
  options.c_cc[VMIN] = len;
  tcsetattr(e->fd, TCSANOW, &options);
 
  int readLen = 0;
  printf("Before read\n");
  readLen = read(e->fd, msg, len);
  printf("After read\n");
 
  tcsetattr(e->fd, TCSANOW, &oldtio);
 
  return readLen;
}
Visceral
 
Posts: 23
Joined: Thu Dec 30, 2004 10:21 am

PreviousNext

Return to Data Logging Software

Who is online

Users browsing this forum: No registered users and 9 guests