search

rbei-etas / busmaster

BUSMASTER is an Open Source Software tool to simulate, analyze and test data bus systems such as CAN. BUSMASTER was conceptualized, designed and implemented by Robert Bosch Engineering and Business Solutions (RBEI). Presently it is a joint project of RBEI and ETAS GmbH.
http://rbei-etas.github.com/busmaster/
GNU General Public License v3.0
916 stars 487 forks source link

Provide multi-platform support #45

Open etas-lorenz opened 12 years ago

etas-lorenz commented 12 years ago

Port BUSMASTER to a platform library that is OS-independent, e.g. .NET, Java, QT or anything other appropriate.

yegorich commented 12 years ago

I'd suggest QT. As for build system I'd take CMake. Aside from managing milti-OS build environment, it will also take care of packaging (deb, rpm, NSIS, WiX)

With socketcan Linux provides really nice unified CAN stack, so this could be handled as one software driver.

etas-lorenz commented 12 years ago

Personally I also prefer QT. Especially as QT offers an old documentation on how to migrate from MFC to QT: http://doc.qt.nokia.com/solutions/4/qtwinmigrate/winmigrate-walkthrough.html

In my opinion the best way to approach this is to start with one of the EXTERNAL_TOOLS. We should try to separate one of these tools in a multi-platform console application and a GUI frontend that we later on migrate to e.g. QT.

As an intermediate solution, I was also thinking about using libwine to compile everything under Linux. However the MFC license prohibits to distribute any resulting binaries. So we would have no installer. A close alternative and therefore possible migration path to get away from MFC is the Windows Template Library (http://wtl.sourceforge.net/), which was set under an Open Source license by Microsoft.

yegorich commented 12 years ago

If Qt is intended to be used anyway, why not converting EXTERNAL_TOOLS to Qt from the very beginning? Qt is much more than GUI (http://doc.qt.nokia.com/stable/classes.html), Why bother with such an old stuff as WTL?

etas-lorenz commented 12 years ago

Yes, I agree for EXTERNAL_TOOLS a complete migration directly to Qt makes sense. What do you think of the idea of splitting each EXTERNAL_TOOL to a command line tool and a GUI frontend?

For the rest, I'm not sure regarding the effort. Is it possible to introduce Qt step by step... So having intermediate versions partially based on MFC and partially based on Qt?

yegorich commented 12 years ago

What about making one binary for both, but with a symlink? Converter and GConverter (like vim and gvim). In main() you just examine the argv[0] and then decide if you need to start GUI or not.

As to your second question, I'm not a great Qt/MFC expert. Don't know if it's possible.

etas-lorenz commented 12 years ago

Symlinks are great. But then we have to tell the Windows guys what this is :-) Ok, but I like this approach. Let's say, the GUI will come up, unless you give the input and output file names as arguments to the program, then it will execute only on command line and will provide success/failure on stdout.

yegorich commented 12 years ago

I just forgot I'm not in a "Schlaraffenland" :-( Windows is still there to care about.O.K. let's take your approach.

etas-lorenz commented 12 years ago

I've upload some CMakeLists.txt and build.bats for the DBC converters: https://github.com/rbei-etas/busmaster/commit/ecfb3d41dc0cd0fedfc9c5e3ce8b5c316f3009de

At least CMake look rather simple to integrate...

yegorich commented 12 years ago

Great! CMake is rather simple to start with.

Looks good to me. From now on other frameworks like Qt could be easily tested.

etas-lorenz commented 12 years ago

I worked on migrating one of the converters DBC_2_DBF to Qt and CMake. All non-GUI functions are now conform to the C++ Standard Library. All GUI functions are replaced by Qt functionality. I uploaded the changes to my personal branch at https://github.com/etas-lorenz/busmaster. It builds and runs under Linux and Windows. All tests were positive.

However this is a proof of concept. We still have to make the decision, whether Qt, Gtk, wxWidgets or anything else will be our future application framework. But as mentioned, I personally favor Qt and CMake.

etas-lorenz commented 12 years ago

Here is a comparison of Qt, Java and .NET, which is left in the current discussion on the future platform.

Qt:

Java:

.NET:

yegorich commented 12 years ago

Some pros for Qt:

  1. it is C(++), so you can user API libs or OS APIs without conversion
  2. Qt can be run without external X-server
  3. Qt was made a little bit more independent from Nokia, so I hope it has a good future

One big contra for Java & .Net:

some times it can be a real big pain to work with OS native APIs, because you have to transfer data, structures, objects from real world into managed one. I had to port one API library written in C and must say, it was really tricky in some parts

I don't know if iOS support for BUSMASTER is so important. I think the problem here is more the lack of CAN drivers.

That were my 2 cents

nostar commented 10 years ago

Has there been any more activity with this? I would really like to see a linux version of busmaster.

nostar commented 10 years ago

I would also contribute heavily to this effort. My $0.02 on the gui toolkit is that Qt is a good option, but another that I have development experience with it gtkmm, the C++ wrapper for Gtk. I think most people in general like Gtk, but shudder at the thought of gui programming in straight C. Gtkmm handles that issue nicely. I was a contributing developer to the ardour project (http://www.ardour.org) which is written using gtkmm.

etas-lorenz commented 10 years ago

It seems there is a strong community behind Qt. :+1:

BUSMASTER consists of different modules. Especially the ones that have no "live real time view" can easily be separated from the main application and migrated to Qt:

I also like a clear separation of Non-GUI functionality which should be written in C++11 and GUI functionality which can be written in Qt (or whatever is appropriate if they are separated anyway).

We also need a build-framework that runs under Windows and Linux. I propose to use CMake as it's used by the KDE project and is well supported in Qt Creator.

@nostar: Are you interested to start with one of these and we'll try to support you as much as possible? We've a daily WebEx telco to which I can invite you.

timoc commented 10 years ago

Can i suggest a good cmake template: https://github.com/davisford/cmake-cpputest And Qt5 - QML http://www.kdab.com/using-cmake-with-qt-5/ QT uses a model view controller pattern, and so automatically enforces the separation. QML separates the view layer from the c++ code.

dbcb commented 10 years ago

Hi there, i have written a programm called mfc2qt that converts microsoft rc files to QT UI/H/CPP files. I use it currently to port TortoiseGit to Qt. It is not in a releasable state at the moment but may be usefull to port Busmaster to QT after release. I don't have committed the stuff yet, because people start forking right after i added a one line markdown document.

BTW: I miss ES-690 support in Busmaster.

etas-lorenz commented 10 years ago

I've seen your mfc2qt repository. Can you upload the newest version?

ES590/ES690 is one of the first generation ETAS hardware interfaces and unfortunately will not be supported by the ETAS BOA framework. I asked for it at well...

dbcb commented 10 years ago

No sorry, it is not in a releasable state yet. Nonetheless i can convert the busmaster resource file with mfc2qt and you can take over if you want.

ES-690: Busmaster is not usable for us without support for devices like ES-690 I hope that this device will be added or at least the spec of the device will be published.

etas-lorenz commented 10 years ago

Yes converted resource files would be good. How would you like to do this? Fork our repository and put the Qt files in the corresponding folders? This would be best in my opinion.

dbcb commented 10 years ago

mfc2qt creates three files for every Microsoft Resource IDD entry (cpp,hpp,ui). The class and file names are taken from the IDD. Example for dialog resource IDD_DEBUG_OUT:

Missing feature in current mfc2qt release:

What i can do is run mfc2qt against the BUSMASTER resource file and send you a zip file back with the converted files or i fork the project and use a different folder for the converted files.

BTW: Busmaster Ressource files uses japanese language. It might be a good idea to translate it to english before converting it with mfc2qt. Qt use a different approach to support n18. Refer to QtLinguist for more information.

etas-lorenz commented 10 years ago

Better fork it. In your commits I'll see what files are added. ZIP files usually doesn't pass our company's e-Mail server.

We're using two different ways for translation. One is based on GNU GetText and the other is based on resource files in local language for the dialogs and windows. We should english and japanese resource files.

yegorich commented 9 years ago

@dbcb any progress? Your mfc2qt repo still has only README and license stuff.

dbcb commented 9 years ago

@yegorich. As I said before i will release mfc2qt if it is stable. I just allmost finished AsciidocToGo and will then make a run with mfc2qt on the busmaster repo. There is still the problem that some original busmaster dialogs are in japanese language, so i have to think about a pre translation process before running mfc2qt on the busmaster source. Does anybody know if there are any visual studio tools to do translation of resource files?

etas-lorenz commented 9 years ago

I'm not happy with our translation technologies anyway as we use two different solutions for it.

I like GNU GetText or similar tools (Qt Linguist), which depend on string tables and have a fall back to english language. Also non software developers can do translations, different to MFC.

With MFC resources files we have a second solution which unfortunately requires that we setup dialogs for any language independently. If we want to change one dialog then, we have to do it in all other language dialogs as well. This is inefficient and error prone.

So just ignore the japanese resource files. We can do a proper translation within Qt afterwards again. This approach should be easier.

etas-lorenz commented 9 years ago

Have you seen that I've introduced CMake as step towards multi-platform support? With this it's already possible to change the development environment, e.g. to QtCreator. However due to MFC, we are still bound to VC++ as compiler and Windows as OS.

nostar commented 9 years ago

@dbcb it would be a huge help just to have your script do what you describe, create Qt classes and ui files for all of the dialogs in the BUSMASTER.rc file. Like etas-lorenz said, I would skip the japanese file all together and I agree that internationalization would be better redone from scratch after the qt port has made way, using QtLinguist/gettext tools. If you could produce the zip file you mentioned, I will use that to create a qt fork of busmaster and start on a port.

That being said, as I said before, I need to insert a disclaimer here that at any time I may seem to disappear off of the face of the planet with no warning, but at the moment I do have some time to start working on this a little bit.

@etas-lorenz how long until 2.6.0 is released with all of the contest additions? I think i should wait until that happens before I make a fork.

etas-lorenz commented 9 years ago

We found a couple of issues in the Ethernet contributions from the #1 contest winner and currently fix these. This will be released as v3.0.0. As we've done some work on the LIN Database Editor in parallel, we'll release this even before as v2.6.0. The milestone planner should have the latest release dates.

Regarding where to start with Qt. You can also pick out parts of BUSMASTER which should ideally be separated anyway, such as CAN Database Editor, Test Automation Editor, Function Editor of Node Simulation, ...

dbcb commented 9 years ago

Still no time.... fighting width PDU-API / VCI. Have to change parser to UTF-16 In mfc2qt to support busmaster.rc. @etas-lorenz : I would prefer qmake over cmake :-). BTW: With the switch to QT most modules must be changed / rewritten. This would be a great opportunity to improve source code and create code that is "almost" MISRA compatible. IMO Busmaster should have coding guidelines.

mls-ssjblue commented 6 years ago

Hi, is there any update regarding whether multi-platform(linux) support is available for busmaster?

jabba80 commented 4 years ago

Reanimating a 9-year old issue.... is there any progress? I really would love to see a linux-version. Implementing socket-can there would also move some effort (drivers) into the kernel. As far as I know J1939 is also a thing in the kernel socket-can implementation.

csgui commented 3 years ago

Hello all,

Is there any update on that topic of supporting multi-platform?