I have ported uCLinux on an embedded board and want to provide it a GUI
layer.
Actually my board is consist of an ARM processor and other peripherals and
a touch screen display.
Actually this is a small embedded board which I have made .
I want to display various gui widgets like buttons , scrollbars etc . I
want to use QT for this purpose.
But I don't know how to proceed , how I can make the QT GUI layer to
interact with kernel
So , can you tell me how can I make it to talk to the uClinux kernel, I
mean how can I interface it to the kernel.
Thank you
I'd suggest you to use an embedded Linux build system. The historical one for systems based on uClinux is called uClinux-dist, but you can also use other build systems such as Buildroot. It already integrates Qt, so you'll only have to select an option, run make, and you'll have a Busybox+Qt system ready.
From the graphical side, Qt can directly use the kernel framebuffer, so as soon as your kernel has the framebuffer driver for your platform, you're ok. For the input side (keyboard, mice, touchscreen, etc.), Qt uses the Linux input subsystem, so if your input devices are supported by the kernel, Qt will be able to use them directly, with nothing additional needed.
Take a look at LVGL. It's easy to port and comes with many widgets.
Related
I'm developing an operating system targetting the ARM architecture, more specifically, a RaspberryPi 4B. For that I've already managed to use the "Mailbox Property Interface" to draw some shapes on the screen. Out of curiosity I would like to know if it was possible to use OpenGL (or OpenGL ES, preferably) to render future more complex graphics. If possible, how do I do it?
You want to find out which driver the usual Raspberry Pi software uses, then adapt that driver to work on your OS. This is the code that interprets your OpenGL commands and translates them to the GPU's native language. Note there is both a kernel part and a user-space part.
It's probably not worth trying to write your own. Graphics is a whole field of study, it's like writing another OS just for the graphics card.
I'm trying to find a good GUI library I could use to create a program on the computer that connects to a microcontroller by USB. I've never done any GUI work before but I have done a lot of webpage design/tools. We are going to program the microcontroller with C but I don't think the GUI will need to be C. It needs to work on Windows, so probably compile on Windows too. I've also never done any USB transmission but I'm hoping to take it one step at a time.
Right now I'm looking at using GTK but it needs a bunch of other things to download with it. I'm also going to look at QT and someone else suggested making a Windows Forms Application. There's a lot of options out there so I'm having trouble figuring it out.
As for my requirement, it just needs to be a very simple GUI that has a few control buttons, a display area (info from microcontroller), a notification area (basically error messages go here), and maybe a graph. I've included a prototype GUI help give you an idea of what I'm doing.
Edit: It needs to run and compile on Windows. We don't really have a budget for it, free open source is preferred. I don't need something elaborate and fancy, I just want to get it done as fast as possible.
We are using a TTL-232R cable, UART interface. I know nothing about USB transmission, school has crushed me.
From what you've specified, I would set base-camp up at Java.
Java in Eclipse to write the code.
Java Swing libraries (helped by the WindowBuilder plugin for Eclipse) to "draw" the GUI. It is very easy to create "Windowsy" GUIs using these.
JFreeGraph libaries to allow you to create graphs very easily, again from within Eclipse.
RXTX library for "virtual COM port" serial communication within Java (it doesn't sound like you're using proper USB, but just RS232 with a USB adapter).
Your created GUI would run on any machine with Java installed, which is not a big ask for the end user. You can even create a Windows executable/installer from the resulting Java files if you wanted it to be a (apparently) native Windows application.
And - bonus - all the tools mentioned are free as a bird.
It will kind of depend on what kind of compiler, IDE, etc you will settle on. If you are going to windows cold, and
money is an issue, then open source is always a good thing to look at. I have enjoyed using eclipse and Code::Blocks IDEs. For C/C++, I use minGW. In terms of GUI plug-ins, HERE are some conversation with GUI recommendations specifically for use with Code::Blocks.
If money is not an issue, I have use National Instruments LabWindows/CVI full dev kit forever. It is one of the easiest ANSI C compilers/IDE I have ever used. It is only ANSI C, but has extensions to make using instrumentation easy. I have written a little USB stuff (not much), sockets, instrumentation, and many GUI apps.
Please comment what tools you currently prefer, I may have other suggestions.
Lazarus CodeTyphon has cross platform native compiler with GUI working on every supported platform. It supports 8 OS-CPU host layers (Win32, Win64, Linux32, Linux64, FreeBSD32, FreeBSD64, Solaris32 and Solaris64), and 25+ OS-CPU target layers. It also incorporates many graphical widgets and SCADA like behaviour with PascalSCADA and other components. There are wrappers for LibUSB.
I would use Microsoft Visual Studio to develop the GUI. They offer a free version called Express. I would use the C# language but MSVS supports other languages as well so just choose whichever you're most comfortable with. The best thing about MSVS is that there are millions of developers out there, which means that you will be able to search for and find lots of examples for how to use an RS-232 COM port or USB interface. I'm guessing that you'll be able to find GUI objects for graphing and other objects as well. (The basic stuff like buttons and edit boxes is all built into MSVS.)
BTW, you need to sort out whether you're using an RS-232 COM port or a USB interface. They're both serial interfaces but they're not the same thing. Either could work.
How do GUIs get built inside operating systems. Lets use two examples, say GTK+ in Ubuntu verses a Java JFrame. I thought that operating systems using some kind of graphical user interface would have to provide some system calls to be able to display windows. So for example, if I installed a version of Ubuntu on a machine, with out downloading any software I should be able to make a system call to display a window. It appears though that isn't the case. I have to install and download the SDK for GTK+ which allows me to create windows with buttons, etc. So then my question is with Java, how does Java then build it's JFrames? I understand that there is a Java Virtual Machine running ontop of the Linux system, but how does the Java virtual machine make calls to actually display the window? Along with GUIs comes the events that the user interacts with them. At the Java level, the JVM handles all the lower level calls, and you get OnClick() events etc. How does the JVM actually call and work with those calls? Same with GDK+? I understand this is a broad question with many different answers, but any help would be greatly appreciated.
Let's take Linux as an example. There are several layers:
Kernel (Linux) and operating system (GNU) - Knows how to work the hardware, including graphics.
Windowing system (X) - Uses graphics functions to draw windows.
Desktop (eg Gnome) - Applies global styles such as window borders.
(Usually) A toolkit such as GTK - Knows about widgets, how to draw them and how to style them.
Your application.
On Windows, the Kernel, OS, windowing system, desktop and widgets are all bundled together. In this case the toolkit probably doesn't draw its own widgets, but uses them directly from Windows.
In any case, the toolkit insulates your application from the platform-specific details and automatically does the right thing.
How would I go about creating a "gamepad" which appears to DirectInput applications as a normal game controller but the state of its controls is actually defined by software?
Write a device driver to pretend to be one.
Specifically, Windows device drivers handle what are called Interrupt Requests via the Interrupt Request Protocol - which boils down to a wrapped up structure and a set of buffers internally in the driver.
Now the next thing you need to know is that many drivers are actually layered, or stacked, or whichever name you want to use. So for example to write a disk driver, you might interface with the driver above it (as a disk class) but use a driver below it (scsi port, for example) to actually send commands to your devices.
That's how real devices work. Fake devices need to conform to the top level interface requirements, e.g. a disk, or a controller, or a mouse, or whatever it is. However, underneath they can do anything they like - return whatever values they like.
This opens up the possibility of controlling a driver via a user-mode application and pretending to "be" a device. To send a driver messages, you can DeviceIoControl to it; then to actually get those messages you can either:
Stuff them in the Irp that makes up that DeviceIoControl.
Have the driver read them out of your process' memory space.
Drivers can also access \\Registry\\Machine and various other, non-user-specific non-explorer registry areas, so it is possible to communicate that way.
Finally, there's no saying you can't filter existing IO, rather than make it all up via a new device. There are a great many options and ways you can go about doing this.
If you're going to do this, you'll need:
VirtualKD or an expensive debugger cable and two PCs.
You probably also want to start with the references on this blog post. You'll find that there are essentially a bazillion different names for driver code, so I'll interpret some of them:
WDM = Windows Driver Model, basically the NT driver model mixed with (some of) Windows 9x.
KMDF = Kernel mode driver framework - drivers of the above type use this, plus additionally WDF (Windows Driver Foundation) which is a set of libraries on top of WDM to make it quicker to use.
UMDF = User mode driver framework - write a driver without the danger of kernel mode. If you can, use this, as kernel mode drivers that go wrong will bluescreen (in driver parlance, bugcheck) your system.
Edit: I'm not massively knowledgeable on DirectInput - there may be a way to override the various API controls in use via DLL redirection and the like, which may be simpler than the way I've described.
There is vJoy opensource project: http://sourceforge.net/projects/vjoystick/ - can be worth looking at.
The easiest solution may be to emulate an XInput device (Xbox 360 and One). These are supported in most modern games and the set up is very simple. Here is a C++ project here that provides this without any installed drivers or external dependencies: https://github.com/shauleiz/vXboxInterface/
I know it is an old question but for anyone which is interested in this topic it is also worth looking at this project called ViGEm.
You can emulate some well known gamepads like Microsoft Xbox 360 Controller, Sony DualShock 4 Controller and Microsoft Xbox One Controller. The project offers also some API to interact with these virtual controllers. E.g. the C# API can be found here
The simplest solution I found was using vJoy and its C# wrapper.
You need to download the vJoy driver from here.
You can use the vJoy SDK for implementing a feeder program: https://github.com/njz3/vJoy/tree/master/SDK/c%23
Use the C# starter project for this, or simply add the two .dll-s to your existing project as references from the x86 or x64 folder.
You can find instructions on how to use the api in the readme.odt file.
I'm working on an embedded system using ThreadX. The project will involve a GUI.
I'm looking for a port of wxWidgets for embedded on ThreadX operating system.
My search has turned up wxWidgets for embedded Linux and WinCE.
Also, is wxWidgets difficult to port to a new (different) OS?
Thanks,
(The project tools are C++ using Greenhills compiler and ThreadX operating system with ARM9 processor and conservative amount of RAM and FLASH.)
There is no wxWidgets port to ThreadX. And while porting wx to a new OS is usually not a problem at all, porting it to a different GUI toolkit is quite a lot of work. I don't know anything about GUI in this OS but basically you have the choice between wrapping native GUI widgets in wx API (supposing that the platform does have some native GUI) or implement just a small subset of graphical primitives natively and use wxWidgets own widgets implemented in wx itself (so called wxUniversal port). The latter is usually less work and as it's needed to do the former anyhow, this is what we usually advise people to do first anyhow. But wrapping native widgets (again, if any -- some embedded platforms don't have any native GUI at all) results in more native look-and-feel, of course.
In any case, you shouldn't expect this to be trivial to do, creating a new port will require some effort although usually you can reduce it if your application needs just a subset of wx GUI functionality in the first place. The only simple solution is to make X/DirectFB/GTK+ work on your platform and use the corresponding existing wx port but this might be unacceptable because of extra resources consumption due to the use of another toolkit.
Finally, if you do intend to port wxWidgets to a new platform, wx-dev mailing list would be the right place to ask for help and advice.
Do you have a strong reason not to use Express Logic's own PEGX GUI library?