libmut help
 

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!

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.

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?

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?

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

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)
--

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?

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

Thanks!

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.

You people and your VB :lol:. 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 :p.

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

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 :)

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.

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 :D.

...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.

If you need something in VB.NET I'll send you the source code of the early version of Mitsulogger 1.0 I know what you intend to do with it, and I have no problem with the code forking for that purpose. PM me on aktivematrix.

The one thing I hate about VB.NET is how difficult it is to get it compiled to native code, I do like VB.NET because its more similar to C# which makes transitioning for me alot easier.

I have been programming in VB for a long time, I always hated the Runtime, and I see .NET as the same type of crap, but its the language I'm most proficient in and makes it alot easier to quickly produce an app in my work environment where there is no time to learn and program at the same time. Earlier versions of VB COULD compile to native code (at least in VB5 and VB6), but it was IFFY about how it did it. It was clearly not optimized, and still clearly had dependencies on compoments you might have used (OCX files) that were not always able to be compiled into the runtime files.

VB.NET (or any .NET code) really does a nice job of allowing components to communicate with eachother without jumping through hooks, and take a modular approach to things. But this is the nature of using CLR code.

I do have tools that compile .NET CLR code to native binary code, but it has a few drawbacks, mainly its difficult to get the results to communicate with eachother very easily. This is much easier to do in C++ after you jump through a few hoops, but after you do its much better to work with.

I'm not going to devend VB.NET because even though I'm a proficient programmer in it, I don't particularly like how things "work" in it. But to say it VB.NET cannot do the same things any other tool that creates CLR code is just plain FALSE, everything available in one is available in all. If your compiling to a native binary, then its mostly true.

My all-time favorite development platform and language is Delphi, the code is easy to write, runtime code is small and fairly streamlined, components that you use can all be embedded into the binary code, along with all resources (this applies to C++ also, but I'm not a fan of C#) Newer versions of delphi can compile to CLR or Native code.

CLR Has a MAJOR advantage though, the code written will run on anything that has a proper implementation of the .NET framework (2.0 or 3.0) where native binaries might not in every case. Hence the reason why I'm FORBIDDEN from compiling to native binaries at work.

Performance is kinda iffy, Windows itself is so bloated that most of the time, performance issues are not .NET related. Machines are so fast these days that most of the simpler apps don't benefit from native binary, especially if what your doing is communication related where your at the mercy of your communication pipelines.

But .NET CLR code has one big drawback, it can be easily "Disassembled" back into source, its not as pretty as the original, but its still possible to "look under the hood" fairly easily. Then you have obfuscation tools which will make it harder to read and discourage most people from bothering, but this does slow the code down.

And is it just me, or do C programmers come across as arrogant and closed minded?

There are some specific cases where this is true. C# allows you to use unmanaged code directly with the "unsafe" specification which VB.Net does not allow you to do. Now before you go and say it, VB.Net does allow you to interact with some unmanaged code with the use of IntPtr. But it only allows you to do relatively "safe pointer" manipulation. So even the IntPtr type in C# and in VB.Net are not even the same (in C# you can hang yourself with it if you like).

There are a couple other low level differences between the two...see if you can find the Microsoft Whitepaper on VB.Net vs C# where the actual people who work on it can expand on those differences a lot better than I can.

I should have put Delphi there last night as well, great language even though I haven't touched it in 7 years now :lol:.

On the "you can get back the source code". That's the risk of using any IL type language. You can do the same thing with Java. It might not revert as "Cleanly" as a CLR language. But if I am determined enough I don't need to have the exact line by line code to figure out how your program does its work. The ballpark will do :D.


Well they feel they have earned their due :lol:. For them if you can't do your pointer arithmetic right your a nobody...which I guess based on what they do everyday is a valid point.

I was young enough to come along by the time C++ had already started its rise and I prefer it over flat C any day :lol:.

C/C++ programming skills now in some cases are becoming very scarce. The big complaint in the field from many hiring managers now is that when they go out to talk to the college kids, most of them know C#, Java, VB etc. but not C/C++. They are still some jobs out there that need those skills but as the line from Harry Potter goes "there is a difference between doing what is easy and what is right".

I think my points slipped by.

1. He isn't actually just accessing a serial port, he is accessing a USB peripheral, and has the 'managed' code doing additional work.

2. His current usage is basically your scheme. I wrote the relevant pieces in C++ and put it in an ActiveX control. I did that because it offers maximum tool coverage (VB, VB.net, C#...) It is slightly less convenient than true .net components, but all the hype about reliability and efficiency is just that, hype (don't believe me, do a little stepping in SoftIce).

So, from my point of view you are arguing solely that VB should be replaced by C#. The way I see it, it is a miracle that projects of any scope get written in either. Seriously, I have tremendous respect for folks who can develop an app of any size in either language. VB is, like a typical scripting language, extremely free form and lends itself well to chaos.

C#'s existance is something of a mystery to me at all. C++, like C, is inherently a system level language. C++ was not a radical departure from C. And despite the grossly overused inheritance mechanism, is primarily a C with better encapsuation. Both languages are still quite close to the machine. C# seems to be based on the idea that a simulation of a system level language, without system level power, is a good RAD environment. To me, it seems the worst of both worlds, a non intuitive, relatively low level syntax, but a lack of system level power. Place it on top of a truly ill conceived framework, and, again, it is suprising to me that folks get big things done at all.

What doesn't surprise me is the number of folks staying with VB. RAD environment users are generally just trying to get something done. From their point of view, there is little benefit to learning what is fundementally a system level language, just to access the same crappy framework and components.

Actually, I think I would detest the .net framework less if there was such an effort to present it as object oriented. When your string object inherits the ability to produce debug strings from your fundemental object, and knows less about the internal structure of strings than still another object, it is no longer surprising that Washington State has more varieties of hallucinagenic mushrooms growing natively than any other state in the union... Think about it, how else could 'Hungarian Notation' have come to exist? I know, let's de-encapsulate something as fundemental as a variable name... :rolleyes:

Seriously, I agree with MJ. Delphi was probably closest to what a RAD environment should be. Pascal was developed as a computer science learning language and the Pascal with objects was quite well done.

It had a following, but once Microsoft bought VB the writing was, as you say, on the wall.

-jjf

Edit: If hiring managers are complaining about C++ skills, then they are stupid. The problem isn't language skills - languages come and go, just like OS's. The problem is fundemental programming skills, which have never been exactly plentiful. For example, we ask folks to write a simple program in 'psuedo code', or any language they like, to perform a simple task. Applicants always fall into one of three catagories:

An alarming number can't formulate a working algorythm at all, regardless of degrees or listed experience. Don't hire them.

Some can formulate a working scheme, these folks have promise, but will require investment.

A tiny number of folks formulate a working scheme and, automatically, put in handling for error cases. These folks can actually come in and produce in short order, rather they need to learn a new langauge and OS or not.

Fair enough I read your post wrong then I guess...:D.

Expand please :D.

Hungarian needed to die for a while and lo and behold it did when the chief proponent of it left the company. This unfortunately is the big problem of being dominant to the point of monopoly....one very very tiny person makes decisions that effects every one else...whether they are right or wrong.

Yes, I agree with you and my company is like yours. Also when the new people come in they get a chance to learn whatever they need to learn and are given smaller coding tasks to get up to speed (i.e don't let them go and change some core part of Office the first day at work).

However some people in the field don't have that luxury. They need someone to come in and write that C/C++ code (because for whatever reason no other langauge can do what they need done) and it needs to be written yesterday. So they don't have the "warm up" time to allow someone to learn the language. They need to be ready to go from day 1 and if thats what they need then they are going to go out there and hire that way.

Its a very "short termed" type of vision but it does happen out there.

This has mostly been covered, but I wanted to chime in...

As someone who develops in .NET languages (VB and C#) and C/C++ for a living, I see each with its own strengths and weaknesses.

.NET - good for rapid development, bad for optimal speed, need to install the framework

C/C++ - fast execution, takes longer to write, error prone, recompile to support other platforms.

One thing I commonly do is to write a .NET app with a modular structure and then go back later and convert single pieces to c++ as time and necessity dictate.

How did we get so off topic? I didn't expect to see such PL waxing on evom. Maybe this is the time for me to bring up ML, or haskell.

Oh. I have a better idea. I should go write a MUT library in Prolog. Can you imagine. :lol:

Seriously though, what's the point? This could go on forever and ever (and probably will). C and C++ are not the same. C++ is not a superset of C. It's a completely different language that shared a bunch of syntax (but not all). I certainly don't think here is anything wrong with high level/scripting/meta/whatever languages. I actually think it it important to program in as MANY languages as possible. Believe it or not, there are several dozen that I use on a regular basis.

Why did I write libmut in C? Why do I think that the mut code _needs_ to be written in C. Well, the OS interface is in C and libmut is supposed to be a system library. What else would be reasonable. If you want to use something else wrap it. I provide wrappers for 12 (yes twelve) languages. Nobody seems to notice that fact though.

MJ: I'm sorry if my pointers comment came across as arrogant. I don't really think that it was. It was just playful teasing. However what is arrogant (not directed at you) is to believe that someone else's skills aren't worth learning.

My problem with VB is not primarily the language specification. It is the fact that the only good implementation is closed source and available at a SIGNIFICANT cost. That limits the long term viability of the project. On this one I am very stubborn. Two pieces of software you need the source to.

1) your OS kernel
2) your development system.

d

I was actually busting your chops because we talk about this all the time. :) I happen to agree with most of the points here, only that working in the environments that I have to deal with, you dont have many options, so you need to be as proficient as possible in as many languages as possible. Unfortunately my life revolves around VB and VB.NET at my current job (UGH!)

Anyone who knows me knows I'm fairly proficient in many different things, but I choose my platforms carefully and with reason. I say Libmut needs to be written in LOGO, Cobol, or Fortran, preferrably on a TRS-80 or PDP-11 if you need higher horsepower and can tow a trailer.

It might be argued that C++ is no longer a C superset, since the full ANSI feature set can no longer be implemented with a pre-compiler alone, but for the first decade or so, I can assure you - it was. Remember, it was called "C with classes" for years.

There were some more radical departures, like Objective C, but they died out.

Codgi: As far as elaborating, look back to a litmus test I proposed in the 70's - can a language be used to implement it's own compiler. Or, closer to the source, look to Dr. T. It was he, not I, that first pondered with 3.0 if C# had yet reached legitimate language status.

I don't know that I really disagree with anything Donour has said. To me, languages are just tools, some are built with different purposes in mind. I've literally lost count of the assembly mnuemonics I've learned. I *am* underwhelmed with Java and C# because I do not understand the reasoning behind adopting C like syntax and precedence headaches for high level, portable scripting languages. Both always seemed more like marketing than computer science, but that is just my opinion.

I also think that .NET was poorly designed at it's inception. Given the overhauls to date, I'm not alone.

I guess my fundemental point is that I see nothing wrong with using tools at hand and accomplishing something. It is like the huge arguments we used to have over vi and brief, totally missing the more important factors by focusing on relatively insignificant factors. People may think language is huge, but having written several applications wholly in 68K assembly language in the early days of MIDI, I tend to think that even languages, like editors, are less of a factor on productivity than you might think.

-jjf

Incorrectly of course. There is legal C code which is not legal c++ and some features work in completely different ways. Consider 'static' keyword. The C use of this has been completely absorbed by namespaces in c++ and 'static' is used for something else.

Go ahead, ask me about my porting pain. :-p

Don't tell apple that.

I actually think they are a _bigger_ factor than people realize, but not for the one people claim. I assert you need to the right tool for the job, and it never happens that something is the right tool for EVERY job. I'm afraid I started this EDIT:mud fight with the assertion that VB isn't the right tool for ANY job.

emacs forever!

.
.
.

:lol:


d

I'll give you one better.

I N T E R C A L

Branching is only done with jumps -- but there's no GOTO. There's a COMEFROM.

oh. and before every assignment, you must ask please.

d

jcs, next time you see me on MSN Messenger send me a message and I'll send you the SourceCode to EvoScan.

Fair enough. Even though I would argue that since all the C# compiler does is spit out documented IL code you probably could have done this from C# 1.0.

"Scripting" languages now are supporting a whole lot more of the core software infrastructure today than they did even say 5 years ago. Having them use that syntax makes it easier for some of the "old hands" to port thier code and settle in.

On this same point, I meant to take a shot at your earlier comment on Pascal and its being developed as a computer science learning language. While I do like Pascal, I also don't know if I necessarily believe that just because a language was specifically developed according to some arbitrary CS guidelines that I can believe in it as being good for both developers and the final code produced. But thats a topic for another story :).


Sun's JVM (easiest comparison) has gone through similiar overhauls in its recent past...go and compile old Java code with "-deprecate" on and see what I mean. The platform independent VM type concept went mainstream in the mid 90s and it will take some time to mature. But rest assured like it or not VMs and virtualization in general seem to be the way forward for the field (note more and more virtualization stuff is being built into the next gen OSes...and also note the increased number of companies who actually run their servers in VMs instead of on pure physical hardware).


Anyway this is now getting way off topic. It was fun though...we'll have a go another time I suppose {thumbup}.

Thanks all. Hamish, I already have the Evoscan source you sent me in September, but never opened it until now when I realised it will also open in VB 2005 Express. There is a multi custom request ID utility that has been written for Evoscan that I posted on aktivematrix on my read/write address thread that works for now.

With so many clever people we should have more writing assembly code for the ECU :) It is a pointer festival! I have just booked my first ever two week holiday since I started working as a doctor nine years ago (only ever had a week before because of rotas!), half of it on a beach in Sri Lanka, and I can't just veg out in the sun and turn my brain off, so I'll have to learn something then - probably C or the preferred variant. It would mainly be an object orientated stuff to do PC stuff, and presumably just a very basic C to do microcontroller/ECU stuff. Suggestions on books/websites to learn anyone?

Back on topic: I also took a look at libmut and the LogWorks module source. Good stuff guys!

Back off topic: John, if you are going to learn a language right now I would suggest C++. The OOP foundation of it translate well into C#, VB, Java, etc.

Codgi mentioned above that VMs are the wave of the future. I agree. Platform portability is becoming more important than ever. Just think of how powerful cell phones will be in 10 years and keep in mind that the variety of manufacturers and platforms will still be there...they should all be targeted by the same source (in theory)

By the creator? I'd think he would know what he was trying to do originally... ;)

Serioulsy, If you haven't done so, it is well worth reading THE DESIGN AND EVOLUTION OF C++. Quite literally, the objective was to add classes to C. I had the benefit of seeing this fairly close up.

The language has evolved considerably, as has C. The K&R samples I first read would not compile with default settings on a modern C compiler. But the reason that the syntax is the same was because, quite literally, the original objective was to make an incremental improvement.

Of course, tools always get used in different ways than you would expect. When MIDI was new, we briefly discussed how simple and lame it was. But Chris at Sequential said that we were overthinking, it would only be used to connect two keyboards together. Simililarly, no one figured that major GUI applications would be written in C++. The thinking was that RAD tools would continue to involve. C++ was intended to be a better system level language. That is why features like inline, const, and so on, things that bite the performance minded, appeared right away.

Static had to evolve because there is 1 and a half extra levels of scope. However, firm C roots are clear, when you define a variable at the top of the file, it is inherently global, not file scope, by default, just like C.

Templates were inevitable, C's concept of casting was inherently non type safe. Although we pictured it a little differently, everyone knew early on that something like the standard template library was an obvious use of class inheritance. Namespaces came later, once the language was being designed by committee. Multiple inherentance is there to prove it can be done (though using it is generally a bad idea) and I've long thought that friend exists because I hated the very idea, but it is a lot more likely that they are there because Grady thought it was legit and useful.

As far as Objective C, don't be confused by the namesake. I'm referring to Coad's pioneer work on inheritance and scope. In very early post production Digital Audio circles, Paul Hershenson convinced me that it was a workable modal and the first edit based digital audio filesystem was based on a naming convention and simple pre-processor tool we rolled internally (Edit based means that files only duplicate large, raw sound data, when required and raw blocks are protected by reference counts).

We kept strict rules on the use of inheritance, which is something many projects might benefit from today. The C++ 'style' that so many people seem to feel they need to adopt actually leads to a lot of extra lines and hidden code dependancies.

This sort of pointless use-it-just-because-everyone-does, like hungarian notation, can make porting a real chore. But, again, the langauges share syntax because the original name and the final name reflect the goal, an incremental improvement on a successful langauge.

C#, on the other hand, was a new scripting language, so the choice of C/C++ syntax was somewhat arbitrary and, I think, probably a big part of VB's continued popularity.

As far as the tools, lots of folks think as you do. I'm in the minority. I'm used to it. I also think that winging it is generally bad (I write experimental test code as well, but I discard it once I've learned what I need to know). I'm also a big fan of designing for testability, a concept that has never really caught on in the main stream.

Sorry we are off topic, it is actually an area of interest to me, particularly since I don't have a programming 'faith'. Again, things come and go, I think it is the ability to break problems done into solvable chunks, build those chunks, etc., that holds value over time.

-jjf

Hi Guys,

Can anybody point me to the source codes of Evoscan and MUT logger (early versions) may be ?

ty
-harsha

AFAIK, the evoscan sources aren't generally available. The libmut sources are still at their original location and will be indefinitely: http://www.cs.unm.edu/~donour/cars/libmut/.

That being said, I haven't owned a mitsubishi in a few years so it is likely to get no more updates.

donour

hi donour,

I tried your code, thanks for that. But when I ran the test it didn worked.
I was properly installed FTDI drivers to my linux pc - ubuntu
and also built the libmut lib, config, make, make installed.
then I connected the openport cable to my car and started the engine.
and ran > ./mut_test ~/test.log

it didn worked. it always says "We shouldn't be here - init failed."

but FTDI read commands works properly at FTDI linux driver examples / eeprom /read <ret>
To Remove the VCP driver as described in section 1.1:
sudo rmmod ftdi_sio <ret>
sudo rmmod usbserial <ret>
Run the sample application: sudo ./read <ret>

Could you please help me with it. thanks :)

Btw this code worked. its referring another set of FTDI commands : https://github.com/niallm90/libftdim...2b12e366d69b5d

Wow, this one makes me dig deep into my memory. I believe that error is the result of a baudrate error. Do you have any experience programming in C? It's likely an very easy fix.

d