Application GUI as Embedded Interface

[MrAureliusR]

Hey again everyone! I might be opening a can of worms here by asking for advice on the topic, but I really am at a crossroads and would love to hear everyone's feedback and experiences.

I've been programming in C for years and years now -- I would say I'm at the 'advanced' level, but probably not 'guru'. I really love the language, I've done tons of projects with embedded microcontrollers and it's all been merry and great fun.

Where I have little experience is in interfacing with PCs. I use both Windows and Linux, and don't really care which OS the solution comes under, though I suspect it may be easier in Linux. I really want to be able to quickly (and that's the key) whip up a GUI on my PC which can access some sort of hardware to communicate with a prototype board (be it through USB, serial port, even parallel -- the interface doesn't matter, as long as it's relatively easy to access, with or without OS libraries). I just want to be able to send information back and forth, for example click different buttons which send commands to the uC, which then sends data back to be displayed in a box. In my head this all seems so simple....

So, what I'm really wondering is, which language would suit this best? I know that these type of questions can really get the fanboys going (myself included, when it comes to C anyway) but I'm looking for honest answers. I've looked at C++, Java, and Python mostly, though there are libraries for building GUIs with C (FLTK, GTK+, QT, etc...) and most of those have interfaces for the above languages.

The real kicker here is fairly rapid prototyping. I know that, for example, TI's Code Composer Studio comes with something called GUI Builder, which is supposed to do exactly this, and while it sounds appealing I'm not sure how standard it is, or if it's at all easy to use, though I might look more deeply into that. I know (or at least the fanboys have told me) that Python can be really great for quickly throwing together code and getting something working. I'm not a huge fan of Java, but honestly if it offers a good solution here I'd be willing to look at it.

I'm basically going to commit to learning a whole new language. Naturally, I've sort of been leaning towards C++ as most of my IDEs will support C++ as well (especially GCC of course) but again, it could go either way -- I'd even stick with C if it'll do the job. I know that Python has a million and one libraries, so I was kinda hoping there would be both a GUI library and a UART or USB library... So, it boils down to:

1) Quick and easy to prototype with
2) Decent graphics library (though nothing too advanced)
3) Easy access to the PC hardware, whatever port or protocol used

So, I'm holding my breath, and waiting for the impending explosion 

Really curious to hear what people have to say!

[jdraughn]

For me it would be C# using Microsoft Visual Studio Express, easy to access serial or network with tons of tutorials and example code - but it would be pretty much Windows only.

[miguelvp]

Visual Studio Express? why?

Visual Studio Community is free and without the limitations of Express.

https://www.visualstudio.com/vs-2015-product-editions

I didn't upgrade to the 2015 one, I'm still on the 2013 version

https://www.visualstudio.com/en-us/news/vs2013-community-vs.aspx

[slateraptor]

I feel like what you're trying to accomplish is what NI's LabView does fairly well. Of course, LabView is not cheap...but I didn't see cost as one of your design constraints either. It's not a "programming language" in the traditional sense.

Disclaimer: I hate LabView with a bleeding passion, but it would be disservice on my part if I didn't acknowledge that when it comes to creating quick, usable GUI panels for interfacing with simple hardware, it does a pretty decent job.

[tggzzz]

It partly depends on what the GUI widgets are going to be. Virtually any toolchain is going to be able to have "button" and "LED" widgets built in. It becomes more interesting when you want more "specific" widgets - at that point you have decide whether or not you want/need to develop application-specific non-standard widgets (e.g. a realtime oscilloscope or logic/spectrum analyser display), or whether you are assembling "standard" widgets such as knobs and meters.

If you are interested only in knobs, meters, graphs, LEDs, buttons, then choose whichever library has suitable widgets and glue them together in whatever language the library uses.

If you are interested in developing application specific scope/LA/SA class widgets, then you will need to look at the extensibility of the library widgets, and understand whether the underlying abstractions can be re-used for your purposes.

Now for the personal bias...

In 1991-1994 I watched 2 experienced C developers build a pretty crappy GUI in C++. The spent most of that time (3 years!) fighting the language and compilers - even then they could have done it in 10% of the time using Smalltalk. (And yes, there are several contemporary HP and Tektronix instruments that use Smalltalk for their GUI).

By comparison, in 1997 Java had been available for ~1 year. I was astounded at the range of and sophistication of commercially available libraries - especially compared with those that weren't available in the 9 year old C++! For my first Java programs, I developed several more sophisticated GUIs within 6 months, on my own. A very significant difference.

Of course, I wouldn't recommend Smalltalk nowadays, but neither would I recommend C++ for fast turn-around prototyping. Consider the language characteristics noted in the C++ FQA at http://yosefk.com/c++fqa/ (I'm fond of the "const correctness" section!). Those problems aren't particularly visible when doing embedded code, but they do hit you at the GUI level.

If the GUIs are going to be on workstations and you need to control pixels in real time, consider Java + JavaFX.

Otherwise you have a wide choice!

[AndreasF]

I agree with the C#/.NET Visual Studio Express/Community recommendations. Very easy to build some simple GUI's and to interface to a serial port.

[Karel]

You write that you use both Linux and windows. Consider Qt. It's much better than msvc/dotnet. And you will not shoot yourself in the foot by being locked-in on windows...
To setup a programming environment for Qt  is peace of cake and you don't need to download gigabytes of software.
Also, documentation, support and programming examples are excellent.
Long time ago, I started with MSVC++. Then I switched to GTK. Then I made the move to Qt. It's the best Toolkit so far.
And Qt is not just a graphical toolkit.l It's a complete C++ framework that contains many usefull classes (including serial port).
Good thing as well is that you can write C code in C++. No need to rewrite all your C-code.

[dom0]

For a C programmer Qt/C++ is probably a good choice, although you shouldn't make the mistake of thinking that C++ is "C with classes" (it isn't). Many people find it really likable, even C-diehards like Torvalds.

I also enjoy Qt/Python very much, the bindings are superb and there are tons of useful libraries in the PyPI. In many instances it's quicker to develop with than with Qt/C++, however, naturally the integration of the individual tools (UI designer, code editor, ...) are not as tight as with a static language like C++. Also, deployment is a tad harder with Python, especially for Windows. OTOH there are good libraries for instrumentation, graphs and math available.

Qt provides two separate UI toolkits, Widgets and Quick, the former is a classic toolkit for desktop applications, the latter is based around a declarative language to rapidly create custom UIs (although you can do desktop apps just fine, too, but it's obviously not the main target of Quick) centered around touch and high performance on small devices.
Quick requires 3D hardware, Widgets doesn't, you likely want Widgets for the desktop and Quick for e.g. Raspberry Pis or other SBCs you stuff into enclosures with a touch screen. Quick is really great for embedded apps, although you do notice sometimes that it's not as mature as Widgets, some things are not documented very well.

I would advise against GTK, the Windows support (both from a technical and a community perspective) is very poor and the documentation is rather lacking.

Java is neither a bad language (it's remarkably good given it's time of conception and designers, although they of course made some cardinal mistakes that bite you very hard in the ass sometimes) nor a bad framework per se, and it's very likable for backends, however none of the available UI toolkits deserves a "cross-plattform seal of approval". They just don't. They neither look nor feel like a native UI even at a superficial level, no matter what the toolkit promised you. Deployment can get nightmarish very quickly, although it works good in many cases. It requires a Java runtime (obviously) which many people don't have on their private computers anymore due to continuing security concerns.

[Howardlong]

I tend to agree that from a developer's perspective framework based languages like Java and C# may be popular, they aren't quite so popular with end users and IT operations because:

O Prerequisites to deployment that can often conflict with other framework-based deployments
O Very frequent and time consuming security updates
O Frameworks going out of support
O Why should an end user have to glue together a developer's software?

Fortunately many Java deployments these days come with their own ring fenced Java runtime, but this is not universal, and it generally makes for a much larger download.

Qt is OK, but make sure as a developer you have the exact toolchain available for maintenance, I have found that things frequently get deprecated and finding the right toolchain archive again can be difficult if not impossible.

This is going to sound mad, but I still write basic UIs the Charles Petzold way in C using Win32 as I have done for over 25 years. The only problem I had recently with this was about three years ago when the dickheads at Microsoft made their C runtime break on Windows XP as the startup code called some Win API that didn't exist on that platform. At that time about 50% of the deployed base was Windows XP. They tried to make it sound like it was by design, but if that was the case it's even more retarded. Anyway they fixed it in a later service release.

[nctnico]

You write that you use both Linux and windows. Consider Qt. It's much better than msvc/dotnet. And you will not shoot yourself in the foot by being locked-in on windows...

Don't rule out wxWidgets which is Qt's open source competitor. Also based on C++ and it doesn't need you do distribute a runtime. I can e-mail the programs I make with wxWidgets because they are relatively small. If you are going into WxWidgets you'll really need to buy the book.

[dom0]

I once used Win32, too, but it's just a painfully cumbersome API, especially the newer ones introduced after XP. Basic stuff like layouts just takes lots and lots of code and well, yeah, that list just goes on. It's not like you can't do things, they just always require lots of code.

Re. toolchains, yes, archiving them is always a good idea for large libraries.

[Kalvin]

Qt is very nice and productive environment for creating GUI based applications. Qt's framework provides excellent components for data manipulation and threads.

Of course, one can create simple GUI apps with serial port support using plain Python. Python has tons of nice components available for data processing, like scipy and numpy.

Qt has bindings also for Python, so combining the two, one can create extremely capable applications in a very short time.

[diyaudio]

Hey again everyone! I might be opening a can of worms here by asking for advice on the topic, but I really am at a crossroads and would love to hear everyone's feedback and experiences.

I've been programming in C for years and years now -- I would say I'm at the 'advanced' level, but probably not 'guru'. I really love the language, I've done tons of projects with embedded microcontrollers and it's all been merry and great fun.

Where I have little experience is in interfacing with PCs. I use both Windows and Linux, and don't really care which OS the solution comes under, though I suspect it may be easier in Linux. I really want to be able to quickly (and that's the key) whip up a GUI on my PC which can access some sort of hardware to communicate with a prototype board (be it through USB, serial port, even parallel -- the interface doesn't matter, as long as it's relatively easy to access, with or without OS libraries). I just want to be able to send information back and forth, for example click different buttons which send commands to the uC, which then sends data back to be displayed in a box. In my head this all seems so simple....

So, what I'm really wondering is, which language would suit this best? I know that these type of questions can really get the fanboys going (myself included, when it comes to C anyway) but I'm looking for honest answers. I've looked at C++, Java, and Python mostly, though there are libraries for building GUIs with C (FLTK, GTK+, QT, etc...) and most of those have interfaces for the above languages.

The real kicker here is fairly rapid prototyping. I know that, for example, TI's Code Composer Studio comes with something called GUI Builder, which is supposed to do exactly this, and while it sounds appealing I'm not sure how standard it is, or if it's at all easy to use, though I might look more deeply into that. I know (or at least the fanboys have told me) that Python can be really great for quickly throwing together code and getting something working. I'm not a huge fan of Java, but honestly if it offers a good solution here I'd be willing to look at it.

I'm basically going to commit to learning a whole new language. Naturally, I've sort of been leaning towards C++ as most of my IDEs will support C++ as well (especially GCC of course) but again, it could go either way -- I'd even stick with C if it'll do the job. I know that Python has a million and one libraries, so I was kinda hoping there would be both a GUI library and a UART or USB library... So, it boils down to:

1) Quick and easy to prototype with
2) Decent graphics library (though nothing too advanced)
3) Easy access to the PC hardware, whatever port or protocol used

So, I'm holding my breath, and waiting for the impending explosion 

Really curious to hear what people have to say!

C# is probably the fastest to learn and prototype stuff for windows only (I personally have been doing lots of WPF stuff and its not easy but very polished compared to most frwameworks when done correctly), however as the guys here already pointed out, Qt is better for cross platform development, not sure how steep the learning curve is to get up to speed.

[Mechatrommer]

I once used Win32, too, but it's just a painfully cumbersome API, especially the newer ones introduced after XP. Basic stuff like layouts just takes lots and lots of code and well, yeah, that list just goes on. It's not like you can't do things, they just always require lots of code.

thats why you use MFC for it. just like Qt, wxWidget and whatnot, they encapsulate the hardcoded Win32 API you bothered so much.

btw, i got a copy of wxWidgets manual book from the net sometime ago, can anyone suggest preferably a complete downloadable manual for the Qt? or upp? because those 3 are most talked about, i'm yet to decide which one to use and capable of minimal effort to build GUI and custom widget control/object... here are the list i checked last time...
https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries
https://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments

[Karel]

http://www.physik.uni-freiburg.de/~kernas/The%20Book%20of%20Qt%204%20-%20The%20Art%20of%20Building%20Qt%20Applications%20(No%20Starch%20Press,%202007).pdf

http://www.bogotobogo.com/cplusplus/files/c-gui-programming-with-qt-4-2ndedition.pdf

http://doc.qt.io/qt-5/gettingstartedqt.html

http://doc.qt.io/qt-4.8/classes.html

http://doc.qt.io/qt-5/classes.html

[Mechatrommer]

[max_torque]

For really quick n dirty GUI  stuff i use MS Excel!  It has VB built in, and because it's a spreadsheet program at heart, handling data once you have it is easy.  Super quick to prototype using it

[dom0]

I once used Win32, too, but it's just a painfully cumbersome API, especially the newer ones introduced after XP. Basic stuff like layouts just takes lots and lots of code and well, yeah, that list just goes on. It's not like you can't do things, they just always require lots of code.

thats why you use MFC for it. just like Qt, wxWidget and whatnot, they encapsulate the hardcoded Win32 API you bothered so much.

MFC is not much different from the Win32 API and not comparable to any of the modern frameworks mentioned in this thread...

[miguelvp]

I once used Win32, too, but it's just a painfully cumbersome API, especially the newer ones introduced after XP. Basic stuff like layouts just takes lots and lots of code and well, yeah, that list just goes on. It's not like you can't do things, they just always require lots of code.

thats why you use MFC for it. just like Qt, wxWidget and whatnot, they encapsulate the hardcoded Win32 API you bothered so much.

MFC is not much different from the Win32 API and not comparable to any of the modern frameworks mentioned in this thread...

FWIW, both Qt and wxWidgets are from the early 90's, MFC is from the same time. There is really nothing truly modern I prefer to call them all mature frameworks.

[Mechatrommer]

the only difference is MFC is Windows only, there is no #ifdef LINUX branch. and of course in very detailed implementation of them which is typical among (non-IEEE-standardized) brand names.

[bson]

To just whip up quick programs, Python and Tkinter (https://docs.python.org/2/library/tkinter.html) makes this ridiculously quick and easy, and cross-platform.  This can then be combined with numpy, scipy (for fft, filter generation, etc), sympy (to e.g. turn passive netlists into transfer functions), lambdas (e.g. functions that combine functions to build filters), python-ivi to interface with instruments (without littering your kernel with NI's flaky Visa support), matplotlib for plotting, and tons and tons of open-source code examples out there (including the runtime and all libraries themselves).  Python has its problems, but functional prototyping is exactly what it shines at.

[dom0]

I once used Win32, too, but it's just a painfully cumbersome API, especially the newer ones introduced after XP. Basic stuff like layouts just takes lots and lots of code and well, yeah, that list just goes on. It's not like you can't do things, they just always require lots of code.

thats why you use MFC for it. just like Qt, wxWidget and whatnot, they encapsulate the hardcoded Win32 API you bothered so much.

MFC is not much different from the Win32 API and not comparable to any of the modern frameworks mentioned in this thread...

FWIW, both Qt and wxWidgets are from the early 90's, MFC is from the same time. There is really nothing truly modern I prefer to call them all mature frameworks.

There where very major changes to Qt since Qt 1. MFC has been updated since then (I like to think of it as backporting of new APIs to MFC), but there were essentially no design changes. This makes a _huge_ difference.

[nctnico]

IMHO the biggest problem with MFC is that Microsoft has dropped it about 20 years ago in favor of VB and when that didn't caught on C#. MFC is most definitely not the way to go. On the other hand there are several GUI design tools for Qt and WxWidgets which allow to create an application quickly.

[John_ITIC]

Where I have little experience is in interfacing with PCs. I use both Windows and Linux, and don't really care which OS the solution comes under, though I suspect it may be easier in Linux. I really want to be able to quickly (and that's the key) whip up a GUI on my PC which can access some sort of hardware to communicate with a prototype board (be it through USB, serial port, even parallel -- the interface doesn't matter, as long as it's relatively easy to access, with or without OS libraries). I just want to be able to send information back and forth, for example click different buttons which send commands to the uC, which then sends data back to be displayed in a box. In my head this all seems so simple....

I have been reading the answers to your post. It appears you are an embedded developer that "needs" (not "wants") to develop a basic GUI on "some" OS to help stimulate your embedded system. The choice of GUI development tools entirely depends on your skills, the amount of investment in learning you want and the target OS and communication link used.

For sending basic commands across a serial port you can use good old Visual Basic 5. There is very little learning curve. However, it is outdated technologies so you'll be learning "old stuff" that have little use in 2015.

If you want to invest the time to do a "proper" GUI on Windows then I'd recommend C#/WinForms. This is fairly quick to learn and is very powerful even for professional GUIs. For a quick start, pick up Petzold's book on the subject (now $0.01 on Amazon.com):
http://www.amazon.com/Programming-Microsoft%C2%AE-Windows%C2%AE-Developer-Reference/dp/0735621535/ref=sr_1_4?s=books&ie=UTF8&qid=1434237921&sr=1-4&keywords=programming+windows+forms

[codeboy2k]

+1 more vote for Qt ...

I've used both Qt and WxWidgets, and I prefer Qt.  I find the entire Qt environment to be quite pleasant and easy to work in.  There is a much larger community of Qt developers than Wx developers, and there is alot of helpful information out there and very decent online references and examples.

There are Qt Classes for everything, and when you use their classes you really gain in portability.  I've written software in Qt that runs on Windows, Linux and OS X without any problems, and uses networking, filesystems, fonts and graphics, timers, and message passing between different components.  Across 3 different platforms the development interface is the same and quite literally ran on each platform with just a recompile.

One forum member posted that you need to keep your toolchain used, this is so absolutely TRUE! You must keep the Qt libraries and gcc toolchain around if you ever want to build your application again, i.e. for maintenance fixes.  Version changes of both the Qt libraries or the GCC compiler will often make an application not compile any more without far-reaching code changes.  For maintenance, you never want to change code like this other than the bug fixes you need to implement. So yes, keep your libraries and toolchain squirreled away.  I use a virtual box for this very purpose. Spin it up and I can build an older app again because it has everything I need to built that specific app on the virtual disk image.