I'm trying to develop a Qt application to a custom linux built with Buildroot for Raspberry PI 4. My goal is to make an GUI through Touch interface and for that I'm using an USB Infrared frame.
My Problem
When I try to interact with a frame, I can move the dial, but when i try to use another dial it behaves like the first pressed dial didn't get released (like when you press mouse 1 and don't release it anymore).
It just stays selected and I can't interact with any other thing in the application.
I run the program using this command :
./dials -platform linuxfb
and here is the frame I am talking about.
What I tried so far
I tried some of the examples provided by Qt that came with buildroot. They seem to work just fine with the mouse in both the Raspberry and in Ubuntu (my PC). Also I tried the same examples in Ubuntu with the touch frame and they also worked flawlessly .
I've set QT_QPA_EVDEV_TOUCHSCREEN_PARAMETERS:/dev/input/event1 , if I don't do this it doesn't even move anything.
I am using windows and I installed the Arduino IDE from Microsoft store, but I wanted to code everything in VS Code. When I want to run the program or select the board it just says this:
Cannot find Arduino IDE. Please specify the "arduino.path" in the user settings. Requires a restart after change.
How can I fix this, where can I find the arduino.path?
Install PlatformIO extension for VS Code. It has Arduino framework and it works with all possible boards, and then some.
For me nothing could make Arduino IDE.app (2.0 beta) work. Switching to 1.8.6 (Arduino.app), putting that into my Applications folder (so the path is /Applications/Arduino.app) and setting the VSCode setting to:
"arduino.path": "/Applications/Arduino.app"
Fixed this error (and got me to select a board, which I was able to do with the command palette. Make sure to open the new non-beta Arduino.app and add any existing board manager jsons, such as esp32 in my case, that might have already been added to the beta Arduino. The libraries appear to already be in place.)
I also had to add this to my C/C++ settings for includePath:
${workspaceFolder}/**
/Users/<owen>/Library/Arduino15/packages/esp32/hardware/esp32/1.0.6/**
At this point "verify" began working. It was still pretty slow, and flashes the Arduino splash screen while running, so I'm now going to follow the platformIO advice and see if it's any better.
P.S. At first I also got an error about [Warning] Failed to generate IntelliSense configuration but think I fixed this by clicking the "don't show again" or similar on the popup that appeared in the lower left. (Similar errors show up on syntax issues, so could be related to that instead.)
After I searched for this issue and did not find a solution yet, I will ask here:
I have a Windows 10 computer with Arduino IDE 1.8.5 installed.
When I try to connect my Arduino Industrial 101, it is not possible to select the COM port in the IDE. Additionally, it isn't even shown in the device manager as "unknown device" as e.g. Arduino COM port doesn't work or Arduino doesn't get recognized state.
Before anyone asks:
-I ran the installer as administrator
-The device drivers are installed (At least they were ticked in the installer programm)
-I have this issue on a second computer (Windows 7 with Arduino IDE 1.8.5), too
Does anyone have a solution for this issue?
EDIT: I tried again with the NodeMCU: The IDE shows COM port 7 in the information area on the lower right but when uploading I get a "Failed to open COM7" error. So, it seems to be a general IDE issue...
Ok, I found the issue... You won't believe me but either it was a broken cable or a cable that does not have enough power supply somehow. Strangely, this was the official cable from the Arduino package I got. My Samsung mobile cable saved the day^^
I've created some Web API methods in .NET 4 / Visual Studio 2010 (and have now ported it to VS 2013 RC).
I want to consume them from a Windows CE / Compact Framework app using RestSharp.
Regardless of how I call these methods, though, I need to know the IP Address to use for the app running the Web API methods. I can access it from a browser using "localhost" and the port number Visual Studio displays when running the View for the Web API project in the browser (works fine, returns XML in Chrome).
But: how can I call it from my Windows CE / Compact Framework app? The emulator in which I run it doesn't believe that it and localhost are really on the same machine, so I can't use that, nor the machine's actual IP address as, again, it is delusional about who/where it is.
So: what is the workaround? How can I test this?
More details about this can be seen here: RFC on HttpWebRequest vs RESTSharp from Windows CE / Compact Framework 3.5
UPDATE
Vasily, my guess was that you meant for me to do this:
...but that led to this:
Note: I get the same when I choose the other option from the dropdown asociated with the "Enable NE2000 PCMCIA network adapter and bind to:" czechbox, namely "Intel(R) 82579LM Gigabit Network Connection".
And trying to install http://go.microsoft.com/fwlink/?linkid=46859 (both the 64-bit and the 32-bit flavors) slapped me with:
So tell me, I implore: Is there balm in Gilead, so that there may be joy in Mudville tonight?
UPDATE 2
In step 6 (bullet 6), I did this:
...which got me first a message that the software didn't install correctly, with the option to retry or assert that, no, everything is really fine (I chose the latter), but then this:
...IOW, I don't make it to step/bullet point 7
Then again, this Peek cat did warn, "Note that this is very much a “works on my machine” experience. If it burns your house down, don’t hold me responsible."
My house didn't burn down (I don't think - I'm not there right now), but the process to extract the file did fail ignominiously.
You can use workstation network card by the emulator. Todo it you have to select "Use installed network card" checkbox and select the card from the list. after that you can use the workstation ip.
This was helpful for me:
Windows Virtual PC and the Microsoft Device Emulator
I've had to use it more than a couple of times.
I saved the file as a PDF to my network folder, so it took me a while to find the link.
When I try to connect to local ports, Computer -> Connect local, using Portmon v. 3.02, I'm getting an error message, Error 2, in a small error dialog box:
I run the tool as an administrator (if not, I get error 6).
By the way this is a Windows 7 x64. On 32-bit, in Windows 7 x86, it works fine. How can I fix this problem?
Sysinternals' Portmon works only on 32-bit versions of Windows. It does not support 64-bit (probably its driver is not signed).
From the Portmon homepage:
Runs on:
Client: Windows XP (32-bit) and higher (32-bit).
Server: Windows Server 2003 (32-bit) and higher (32-bit).
In Windows Explorer, right click on portmon.exe --> select Properties --> click the Compatibility tab, and Run in Windows XP compatibility mode. It works fine like that in Windows 7 64-bit.
"Error 2" is "Cannot find the file specified", that is, cannot find a required DLL file.
Originally, you got this error when you tried to run Portmon from a network location: that broke the security trust, causing Portmon to be untrusted (or perhaps just messing up the search path somehow).
On my copy of Windows 7 64 bit, Microsoft Dependency Walker (depends.exe) tells me that PORTMSYS.SYS (the file created/loaded by Portmon.exe), has unresolved dependencies on ci.dll, clfs.sys, hal.dll and kdcom.dll.
Those are the
code integrity
common log file system
hardware abstraction layer
kernel debugger com
libraries, and they aren't actually missing: if they were, Windows wouldn't boot. However, I don't see a copy of those files in SysWow64. This suggests to me that the problem is not with portman.sys: the problem is with the win32 compatibility layer in Windows 7/64 bit: It doesn't support debug properly.
It is now 2018. There is no 64-bit version of Portmon. Serial ports are a legacy standard. The Windows 7 problem was fixed by the release of Windows 8.1. However, there is a faint chance that some Visual Studio utility or security update back-ported to Windows 7 will fix the problem. Perhaps someone who is familiar with SysWow and debugging will comment.
Instead of portmon for Windows x64, you can use an emulator of a pair of virtual COM ports and a simple program that will connect the physical port and one of the virtual ones, as well as perform the logging function.
To create a pair of virtual COM ports you can use:
com0com (preferably version "com0com-2.2.2.0-x64-fre-signed", because it contains signed x64 driver)
Virtual Serial Ports Emulator (VSPE), every time it starts on x64 it asks to purchase a driver, but it works even if you refuse.
Simple mapping and logging program can be found e.g. here or you can write it yourself, it is simple.
The sequence of actions is follows:
Сreate a pair of virtual COM ports using emulator (for example, COM28 and COM29)
Let the external device be connected to the computer COM1 port. In the program, whose exchange with external device we want to listen to, we set up a port COM28 (instead of СОМ1) for communication.
In the mapping program, we set up that we want to bind and log ports COM1 and COM29 (don't forget to set the port baud rate).
I haven't tried it yet, but this question mentions com0com. It creates two virtual serial ports and emulates a null modem cable between them. It claims to be able to run on 64 bit Windows. I'm not sure whether it comes with software that lets you just pipe input from a real port into one of the virtual ports. One of the FAQ's says that you can turn on logging.
I guess in the worst case, you could write your own small program that pipes data from a real port to one of the virtual ports and logs it all.
There's also this question on open-source alternatives that mentions a couple of projects.
I've used AccessPort
http://sudt.com/en/ap/download.htm and it works great. Very similar to Portmon
Don't start Portmon from a network drive/path or something else.
Copy on to the hard disk drive, e.g. on the desktop, restart and try again!
If you run Portmon in compatibility mode, it will work.
Check Make older programs run in this version of Windows.
It says:
To run the Program Compatibility troubleshooter:
Open the Program Compatibility troubleshooter by clicking the Start button Picture of the Start button, and then clicking Control Panel. In the search box, type troubleshooter, and then click Troubleshooting. Under Programs, click Run programs made for previous versions of Windows.
Follow the instructions in the troubleshooter.
The above is a public explanation from Microsoft for a common situation when running older applications in Windows.
But, I can say it briefly;
Right click on portmon.exe
Select menu about "troubleshooting compatibility problem" or something like that (I'm using a foreign version of Windows, so I don't see correct name of that menu in English.)
Select automatic mode
It will detect the problem and recommend Windows XP (SP2) mode
Select it and execute Portmon again.
I hope it works!
Instead of Portmon you can also use the IO Ninja program with the "Serial Monitor" plugin.
It gives a little less information than Portmon, but in a more understandable form. The main thing is, just like a Portmon, it allows you to see the data that is transmitted between a third-party application and an external device via a serial port. The program works under modern versions of Windows (I tried it myself on Windows 10 x64). The aforementioned plugin "Serial Monitor" is paid (but has an evaluation period).
Note: the port that you want to monitor must first be connected to the "IO Ninja" program, and then opened in a third-party application whose exchange with an external device you want to track.
Just to test that the hardware is working, you could perhaps boot a Linux live CD and run the statserial and/or minicom program to verify that it works. The Knoppix distribution seems to contain both those programs.
Serial ports on Linux are named /dev/ttyS0 for COM1, /dev/ttyS1 for COM2, etc.