jcsbanks

I'm trying to learn about libmut, but I can't seem to find it. I can bring up the website http://www.cs.unm.edu/~donour/cars/libmut/ , but can't navigate the sourceforge stuff, I don't understand it. Can anyone give me an idiot's guide please?

I was thinking I might use it to write something in Visual Basic (which I'm also a newbie at).

SH2 assembler no problem, but all this stuff puzzles me!

JoeBee

You can go to the "Browse CVS Repository" Section: http://pyxede.cvs.sourceforge.net/pyxede
The you can/must download each sourcecode file with a "save as" click.

If you you don't want to do that, you must install a cvs Software on your PC.
With this software you can download the whole tree. But I don't have experience with that. The Linux guys are much more comfortable with this stuff.

donour

iTrader: (6)

http://sourceforge.net/cvs/?group_id=144766

Why, oh why, would you want to do that?

If you want to get your feet wet writing an app in an bytecode intrepreted, dynamically typed language. Try python or ruby.

d

EDIT: I can also just email you a tarball of the source if you want. Getting from CVS would be better though as you can pull updates without having to coordinate with me.

EDIT2: You do know that libmut doesn't currently support windows, right?

jcsbanks

Sorry as you can see from my questions "projects", "integrated development environments" and "libraries" scare me to death, as does to be honest all the void and funny arrows and brackets in C!

I can hide behind the simple structure of a microcontroller fine where I can just see all my code easily.

To be able to test things I suppose what I want is a file I can edit that will run from Windows that will open a MUT connection with all the inits and baud rate changes to the ECU and then have two simple commands that can send each request ID and receive a reply. Is this possible? I won't always be able to use the existing loggers because I might need to do logic that compares results or sends groups of requests etc.

Sorry if I'm a bit slow to pick this up. Suggestions?

donour

iTrader: (6)

Yes it's possible. It isn't even really that difficult. The problem is that libmut is written to use unix style serial ports. If you want to add code to use windows COM ports, that's fine. I'll even include the changes back in the original libmut distribution and give you credit.

I haven't written a program from a windows COM port in more than ten years, so I only have a vague notion of how they work. I'd be happy to answer questions though.

Oh and get used to them pointers! That's what separates the men from the boys.

d

EDIT: I include with libmut a set of wrappers that let you use the library from python. An example python program to do what you want would be very, very short and look a little something like:

--

port = libmut.open("port_foo_bar")

while 1:
port.write("0xF")
print port.read(1)
--

jcsbanks

I will try to read up on python, but I still have no idea how I translate this array of files into an exe I can click from my desktop.

I can open "BASIC" and imagine writing a program like this (details not precise, just to illustrate)...

set bit on comport #2
wait 200ms
clear bit on comport #2
wait 1000ms
open comport #2 at 15kbaud
write #0xFF comport #2
write #0xFE comport #2
etc

Then I'd be connected, and can:

write requestid comport #2
read response comport #2

If response=whatever then do this etc.

Maybe I'm missing the obvious?

jfitzpat

If you just want to get to a Tactrix cable for MUT from Visual Basic, I put the stuff in the LogWorks plug-in out as an open source control at Enginuity.org (CableTools). You can pick up the activeX control from LogWorks or rebuild it from source.

-jjf

jcsbanks

Thanks!

jcsbanks

Thanks again jfitzpat, downloaded the Open Port 1.3 Control Test executable and it works a treat to connect. Then I loaded the source of the VB application into VB2005 Express and it moaned about default properties of objects but still builds and runs without errors. So I think now I can edit things in this VB project to do other custom stuff, like read or write blocks of memory through the MUT protocol add ons I've put into the ECU. To start with what is effectively a logger like this is just great for me and just what I needed!

Thanks all for the help, having a great time learning new skills whilst contributing where I can.

codgi

iTrader: (22)

You people and your VB . C# with managed C++ and you have that port singing in no time. You can talk directly to the com port via DCB...I wrote something to do that about 3 years ago. Could find the source if you really wanted it I suppose...but that sounds like work .

jfitzpat

Actually, pretty much wrong on all fronts. He is calling C++ code, with a dash of assembly. It bypasses the MS comm stack altogether, invoking the FTDI driver via deviocontrol calls. The driver, in turn, uses URBs to access the USB peripheral.

It also does multiple ECU protocols, including one whose legal timing is quite difficult to generate from non kernel space in windows.

However, 'managed C++', under a psuedo language, in the context of an unstructured library to invoke a few native Win32 calls does sound like a classic Microsoft approach to serial communications. Remember, it took almost 10 years for the OS to offer a fully working interrupt driven ring buffer. We always figured that Bill wrote the first one and everyone was afraid to fix it lest they get fired...

-jjf

codgi

iTrader: (22)

I wasn't referring specifically to what he was doing right now I was saying that if I was going to talk to the com port I wouldn't do it via VB . I like the C# to managed C++ interface which you allows you to do the "easy" stuff in C# and then handle the low level stuff in managed C++. If hes going to do something quick and dirty then at least do it in a language (if it is feasible) that will be around for a good foreseeable time in the future...who knows when VB's time is up (if it was up to me I would have pulled the plug on it years ago)...even though clearly post 1999 (.NET's appearance) the writing is on the wall...

You may be right as to how feasible it is for this particular case

jcsbanks

I have no IT training, but understand assembler and BASIC. I know I need to learn C at some point, but at present I just can't produce C code like I can assembler or BASIC. I think the stuff I tried to read on C was probably not very good or I wasn't sufficiently motivated.

Can anyone explain what I'm really missing by using VB rather than C? The applications seem to work and are not really performance intensive. The big reason to learn C seems to be how universal it is.

For programming the ECU with patches C is a non-starter I think because I need control over every instruction and what registers and memory addresses it uses. The ECU code itself seems to be compiled C, and it can be convoluted and messy using more instructions than necessary.

codgi

iTrader: (22)

At the end of the day all higher level languages do is make raw machine code easily readable for the average human. Whether they are "hard compiled" directly into a "true" executable (C, C++) or into an intermediate language (IL) (Java, C#, VB.Net) (which a JIT (Just-In-Time) runtime (JVM, CLR respectively) takes and produces the machine code instructions for you at run time) what you write ends up as raw assembly at some point.

The reason you might say that the code is convoluted or takes more instructions than necessary actually ends up being related to the point above. Being able to translate what you write in a high level language into raw assembly instructions depends on the compiler...in some cases it will produce incredibly optimized code that a pro assembly developer might have taken weeks/months to produce. On the other hand it might produce the most rubbish translation ever (your case point).

I remember when I was at school, two of the professors did an experiment. One was a very good assembly programmer, and the other a good C++ programmer. They wrote a bunch of similar programs and then compared the final assembly generated. The good C++ professor (because of certain compiler optimization flags he turned on) 9/10 times it was able to produce a program whose assembly output was more optimized than the assembly professor.

I'll be clear to state my bias that I have never liked VB from day one when it was a JIT only language (needed its runtime installed to run any VB programs since it only compiled them into an IL...even though around VB 5 onwards I think they made it so that you could also produce hard compiled binaries...but I could be wrong here since I didn't care about it back then and still don't now ). Back then the overhead of having the runtime load and then turning the IL into native code could end up making VB programs considerably slower than their C/C++ or even Delphi counterparts.

It also has always been a "quick and dirty" language which meant that its main focus was to make programming easier for the user and not necessarily make the finished program it self optimized. This meant that even when you had the option of producing "true" exes from VB5 on they weren't anywhere as optimized as they could have been.

Now with the advances in both the programming of runtimes and machine hardware in many cases for what you want to do the difference between the raw performance of JIT vs "true" compiled code in many cases is negligible (as you note above).

The only reason VB is still around is because MS is slowly trying to wean users off of it. They moved VB to the CLR world where C# is king. It is clearly going to fully replace VB at some point in future because it is easier to write, easier to read and clearly has more power and more speed. It therefore puts a hard number on the days of usefulness left out of the VB language.

C is the old big powerful dog. It produces good native code and with the correct libraries (or ones you make yourself) you can talk directly to all the good parts of the OS. You can also write flat assembly in a C program (once you declare it correctly from what I remember...but I haven't touched C in about 5 years now so my memory might be off) and have it successfully compile (there are some cases such as drivers and what not where this may actually be a good idea)...something that many of the newer languages don't allow you to do.

Ironically its great power, being able to do anything is its great weakness...e.g pointers. Pointers are great, they allow you to do just about anything...but incorrect usage of them also allows you to write subtle bugs that are hard to find via visual code reviews (such as deleting the contents of a pointer, but keeping the pointer itself around which ends up with it pointing to null).

Higher level languages such as VB shield the user from these type of issues. So what are you missing? The ability to really get down there at a low level and do a lot of good stuff....do you need it for what you need to do? Probably not .

jcsbanks

...goes away to read about CLR

Thanks for the info.

I don't like PCs for programming because I don't understand them. I like microcontrollers because they are so simple in comparison, and the hardware isn't hidden from you. So I get my low level kicks from that and just use a PC like a tool.