EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: senso on February 06, 2015, 10:25:41 pm
-
Good night everybody,
So, I have a long time project that is finally almost done, and I want to make a simple GUI for it to work under windows, my only real constrains is that it must work nicelly with a serial port.
Like two years ago I looked into Qt but at that time it didn't support serial ports nativelly, but I have seen that is not the case anymore, my other idea was C#, but it seems like a total overkill for my needs, maybe I end up resorting to Visual Basic.
The project is a simple digital programmable ignition for two stroke engines, so almost all my needs is a variable size table to input RPM/advance pairs, a graph to see the ignition curve and a couple text boxes to set basic numeric configuration, maybe one or two radio buttons, but thats it.
In the future I will also support electronic power valves(servo like) so I want a tab to hold the power valve configuration, another tab for ignition timing and another for the basic configs, my general idea is just to do it like the Ignitech software, I don't need or want to have has many features, has a lot of them depend on the bike having a built in battery to keep the cdi running with the engine stopped.
(http://s28.postimg.org/qr2nlkxzx/cdi1.png)
(http://s28.postimg.org/eqh7kuql9/cdi2.png)
(http://s28.postimg.org/prccpviu5/cdi3.png)
All input is welcome, best regards.
-
I would use Python and PyGTK. One advantage of this is it will be cross platform, if that matters, it can run on Linux and MacOS X with minimal or no modifications.
You can easily draw pretty antialiased graphs, Glade lets you scale interfaces to any screen size, you can design visually (using LibGlade tool) and export XML file to load interfaces dynamically.
I worked on this project using Python/PyGTK which used a serial port on Windows. The company released the code as public domain:
http://batteryshowdown.com/source.html (http://batteryshowdown.com/source.html)
(beware, it's a complete and utter hack-job -- was in a rush to finish it)
-
Oh, multi-threading, never done that :palm:
It might be a bit more complex than I though it would be.
Don't take this as an offense, but I will move this question to a more programming centric forum.
Thanks for the answers.
-
Python makes multithreadng easy. Use multiprocess module. Most modules are threadsafe, but you should check the docs to be sure. Obviously all of Python's advantages come at the disadvantage of speed, as it is an interpreted language...
-
Choose an development environment which you are comfortable with. If you target platform is Windows only, Visual Studio (express editions are free) is a major point to consider with regard to comfort and convenience. Whether you use VB or C# doesn't really matter, since both are .NET framework languages. If you want to write your application exclusively for Windows, i would say don't bother with Python - but to be fair it has to be said that there is a Visual Studio plug-in which adds support for IronPython (a Python implementation integrated with .NET).
However, if you start contemplating about cross-platform, a .NET-based project is not really the way to go... (there is Mono having WinForms, but it can be a bit wonky when dealing with complex UIs, and i don't know how well Mono would deal with serial ports. Also, Mono is not a standard package on Linux distros, i guess...).
Qt has a QtSerialPort module (introduced with Qt 5.1), so if you already have experience with Qt and you like it, you might consider doing a Qt-based C(++) project.
Python might be an option too, of course, if is not a requirement that the program installation on a Windows box should also be doable by inexperienced users.
P.S.:
WPF is not so much about multi-threading, it's about data-binding. If you you are inexperienced with a GUI design approach that is largely based on data-binding, then WPF would require some learning effort. Although, once you have understood it, you will always get the creeps when faced with developing in a GUI framework that's not offering good support for data-binding...
Edit:
Firefox spellchecker at work :palm: ...doesn't know "multi-threading", see picture below for the hilarious spellchecker suggestions...
-
I have been using wxCTB for over a decade for using a serial port in Linux and Windows software.
http://sourceforge.net/projects/wxcode/files/Components/wxctb-0.9/ (http://sourceforge.net/projects/wxcode/files/Components/wxctb-0.9/)
It's supposed to be a WxWidgets component but it doesn't ty into any of the WxWidgets stuff so it compiles and works just fine when compiled into a C++ program.
-
my other idea was C#, but it seems like a total overkill for my needs
Doesn't get any simpler than with C# SerialPort class.
-
Python might be an option too, of course, if is not a requirement that the program installation on a Windows box should also be doable by inexperienced users.
Python has support for generating a compiled exe package, along with all required drivers and utilities. No need to pre-install Python to make it work. You can then use software like Nullsoft Install System to generate an appropriate installer. You don't even need to include your source code (only the compiled bytecode *.pyc, which can be obfuscated if desired)
-
WPF is good if you can get your head around being multi-threaded. C# has reasonable and easy serial port support. Run it on a background thread to keep the GUI stuff separate.
Darn you stole my answer :+ . Actually I've never had a multithreading issue. Rather I've never thought about it and it hasn't been a problem.
-
Python might be an option too, of course, if is not a requirement that the program installation on a Windows box should also be doable by inexperienced users.
Python has support for generating a compiled exe package, along with all required drivers and utilities. No need to pre-install Python to make it work. You can then use software like Nullsoft Install System to generate an appropriate installer. You don't even need to include your source code (only the compiled bytecode *.pyc, which can be obfuscated if desired)
Hehe, that means i will have to look into this :)
-
As you might be able to tell from the variety of answers, there is no one correct answer. It is also hard to tell you without knowing significant background on your project. Due to you asking the question and wanting something simple, I expect you need something that has a shallow learning curve. For my job, I currently work on an application using Qt with QML. I have found it to be quite nice, but I don't think it is a good match for your needs. I also like WPF but it has a large learning curve and sometimes simple things can be quite hard. I would also stay away from python. The community tends to be server-centric and have limited development tools for GUI work. They still cannot figure out what version of the language they want to use.
I hate to say it but, go with the safe answer C# and Windows.Forms. Stay away from VB.NET, not just because the language sucks but because it will be harder to find information on it when you have a problem. I have yet to find an IDE as good as Visual Studio, that really makes a difference. There are better languages out there than C# but you can find plenty of 3rd party tools for it, tons of information online, and it is well supported.
-
[...] I also like WPF but it has a large learning curve and sometimes simple things can be quite hard. [...]
If you are not experienced in WPF, then simple things will appear hard, because of the amount of learning you have to invest. It doesn't mean that simple things are hard, there are just being done differently. In reality, once you have understood how to use WPF properly, a lot of things are far, far easier and simpler than in WinForms, or other "traditional" GUI frameworks (of course, WPF has an odd thing here and there, but so does practically any framework of reasonable complexity).
The underlying question is: Would it be worth to put the efforts into learning WPF just for this application? Well, assuming i do not dramatically underestimate the complexity of the application GUI, i would say no (unless senso has the time and some general interest in WPF...)
For my job, I currently work on an application using Qt with QML. I have found it to be quite nice, but I don't think it is a good match for your needs.
Why do you believe it is not a good match? Creating both static, rather simple UIs and complex, dynamic UIs with QT is comparatively easy. If senso has already prior experience with C++/Qt, then it is a rather good match. In the end it comes down to (A) what is senso's prior knowledge, and (B) what are his desires to learn different languages/frameworks...