Sometimes it is very convenient to develop GUI on PC, and then port it to the target embedded device. But there is a problem: GUI input/output must be connected to the actual application and BSP functions. What could be an elegant solution for easy attach/detach of the GUI ?
The simple solution could be replace all relevant application functions with dummies when evaluating GUI on PC. This works until the number of such functions is less, then, say, ~100. Not scalable.
What could be the other ways for separating GUI and application?
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
Ask yourself if the GUI really *must* talk to the application. Can it just talk to stubs? A lot of GUI work is moving crap around on a screen and figuring out what belongs where -- stuff that can be done without the application even existing!
But are you sure you have to replace *all* of the functions?
Consider, instead, manipulating a struct that acts as the interface to the application. I.e., twiddle its contents and then signal the application to examine it (and, possibly,
*update* it). Note that this can be an iterative approach (i.e., each time the user does something, tweek the struct, signal the application, then wait for the application to tell you to "resume").
On a desktop, you can have that "signal the application" simply print a message on your console and *you* go tweek the struct AS IF you were the application (assuming the GUI really *needs* this interaction).
[Hard to say without knowing how integrated your user interface is -- or MUST BE -- with the application itself]
Depends on what sort of API you have developed and the communications primitives that your OS supports.
E.g., I treat the user interface as yet another service (instead of "yet another LIBRARY"). So, that service can exist *locally* -- or, on the other end of a wire of some indeterminate length (response time is the tradeoff). The OS just passes messages to whichever services they are intended -- wherever they may be.
If you are just *calling* the GUI (library) directly, you would have a fair bit of work creating wrappers for each of those functions to implement a transport protocol *under* them :<
Look at how Inferno treats the interface (you might even consider using Inferno/Limbo as a production platform).
Many years ago Dan Bricklin had an application GUI interface simulation package called Software Garden that had about the same limit.
At that point it is easier to write and debug the code. What we have typically done is to separate the GUI from the project application through a well defined common global data structure and then treat the GUI as an entirely separate application. By using a well defined data structure an fairly simple application simulator can be written that accesses the data structure. At the debug stage the simulation can be a small window with variables and changeable values. There comes a point where the application goes dynamic and it becomes a process simulator.
BTW the common data interface will do wonders for application reliability.
I may be missing the point here but when I have had similar problems to solve I have linked the GUI to the rest of the application by UDP messages. (Obviously only any use on a target with support for UDP.) This is nice because it means that your application is automatically suitable for remote control and the GUI can run on just about anything and be written in just about anything.
The UDP server on the target can be quite compact if you write your own or it can be part of a full blown 'stack' if that suits.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.