I am currently developing a Qt application which has a window and a serial port module.
My problem is that when I press on the window or move it, the reception of the QSerialPort module (with the readyRead() signal) is blocked. The reception only resumes when I stop acting on the window.
It seems that this is a known problem: https://bugreports.qt.io/browse/QTBUG-34946
However, I am currently in version 5.15.2.
Where do you think the problem can come from and what could be the solution?
Related
Im running Qt on ubuntu. I want to write a simple program that recieves a line from android device(this device already has a program to connect and send info) over Bluetooth. How do i start a bluetooth server in QT? I tried to find examples, but all of them act like a client that looks for connection. My program should wait for connection and once it gets a connection, it waits for incoming messages and reads them.
The Bluetooth API provides connectivity between Bluetooth enabled devices.
You can find Bluetooth examples in Qt website here, also see some Bluetooth examples in Qt Creator examples.
Bluetooth chat example and Bluetooth file transfer example is works for you.
The Bluetooth chat example may be used with various Bluetooth terminal applications. For example you could compile the Qt BT chat example on your computer and connect to it from your cell phone running a Bluetooth Terminal application.
In order to do that all that is needed is to change the UUID values as described here and here. That is, in the chatserver.cpp file of the example one needs to change:
static const QLatin1String serviceUuid("e8e10f95-1a70-4b27-9ccf-02010264e9c8");
Becomes:
static const QLatin1String serviceUuid("00001101-0000-1000-8000-00805F9B34FB");
You may also want to do the same thing in the chat.cpp if you are planning on using the client mode as well (in this case make sure to change the reversed UUID also, as described in this bug).
I have got an Arduino Uno R3 on which I have an accelerometer that I'm playing a bit with. This setup has worked for quite a while now, everything working from uploading to checking the serial output.
Today I started having problems with the com port reporting busy or not connected at all. When I use the default IDE it cant find the arduino at all but when I use a modded IDE (Arduino ERW 1.0.5) seems to find the port to communicate on but it reports it being busy.
I have reinstalled the driver like 5 or 6 times now and searched for any other driver that might work but they wont change anything. I have also checked that my pc actually detects the arduino which it does, it is listed among the COM ports on Device Manager. I also tried changing the Com port from COM3 to COM4 and still it worked for like 3 uploads and then the COM port kinda "disappeared" from the serial port list on the IDE.
EDIT: Weirdly, after closing some programs that seem to have to do with serial communication it works. I have to look into what I close and when.
EDIT2: For now it seems that processing sometimes didnt close properly when not using the stop button on the processing application which then didnt close the connection to the arduino. I havent had any problems since I started to use the Stop button on processing.
Win 8.1
Latest driver and IDE(an modded IDE called Arduino ERW 1.0.5 seem to work a bit better but have the same issues)
One thing I noticed is that if I press the reset button when it starts again it wont send anything through serial, is it defaulting to the Blink program after a reset or what?
For those getting the "port busy" error while connecting Arduino and Process, one fix is to close the serial monitor in Arduino.
For anyone who is struggling with this, you have to give again rw rights to ttyACM0
sudo chmod a+rw /dev/ttyACM0
after that I was able to open the serial port.
I found the problem being in Processing itself, on win 8.1 the P3D option for 3D renderer seems to leave the java process open after closure which causes the serial port to be busy even after the main window is closed.
I simply fixed it by using OPENGL instead of P3D which didn't change anything visibly so I'm fine with it.
I have a problem with Windows CE 6 and a DIGI device with processor Freescale IMX51. I wrote an application in C # using the BSP of DIGI, to use the ARM eSPI (enhanced Serial Peripheral Interface).
Then using the functions issued by DIGI, in debug, I can active a OLED using SPI, but when I launch the application on the device, the OLED no longer works.
I have seen with an oscilloscope that when I load the application in debug mode the number of bits is correct, i.e., the clock has 8 rising edges, but when the application is launched from the device, the clock increases somewhat, that is, I see 9 bits. This also happens when I use the .exe from the debug directory.
I do not understand why this is happening. Can anyone help me solve this problem?
I am starting off with an Arduino Uno and am able to flash some sketches via the Arduino IDE.
Something confuses me though... When I press the reset button on the board I was under the impression that my currently flashed application is removed. That is not the case. It still executes the last flashed application. Is that supposed to happen?
Also when I flash the "bare minimum" sketch with no code instructions, the on board LED on pin 13 is constantly active. Is that the default behavior?
All that the reset does is restart your application you wrote in the arduino code IDE.
Actually, when you press the reset button, the controller is reset and starts execution at a specified address (the reset vector). In the case of Arduino, the address is in the upper end of the flash memory which contains the boot loader. If the boot loader does not see any traffic in the serial line (i.e. an incoming new program) it transfers execution to your program, i.e. setup(), loop() and the works. The program you load to Arduino is programmed in a flash memory, it does not go away that easily.
That button should be labeled REBOOT. That is what it does to the board.
I added this similar answer because I understand that it' conceptually different to re-run the sketch than reset and startup everything
My Arduino is stuck in an infinite loop trying to read from a pin and print it to the serial console. I can't upload any other programs now. What can I do to get the chip out of the loop?
Remove the USB connection, close the IDE, open the IDE, open BareMinimum, hold the reset button, plugin the USB connection, click the upload button 1/2 a second after removing your finger from the reset button.
If you're using an Arduino Uno, you might want to check out Updating the Atmega8U2 on an Uno or Mega2560 using DFU. Apparently there was a bug in the interface firmware.
This may sounds silly but what about disconnect it from the power supply to reset the MCU?
Edit:
I see it is powered via USB; then make sure you disconnect the device, remove/discharge any battery/capacitors whatsoever. If nothing works, close down the Arduino IDE, change the USB port you are using (sometimes it does happen that they get stuck..), reboot the PC.. Good luck!
Reprogramming the interface firmware (see ViennaMike's response) did not work for me, so I purchased another Arduino and turned it into an ISP programmer and overwrote the offending application:
https://stackoverflow.com/a/8453576/1090713
While this approach had some cost, I now have another tool and a way to save an Arduino in the future.
Upload your boot loader using Avr pocket programmer. This solves your MCU reset.
Use Watchdog timer instruction while coding infinite loop provided you are dealing with critical parameter to be written when it restarts.
If you run across the same problem with Arduino Yun, try uploading empty sketch using WIFI as port. It worked for me when I couldn't upload new sketch via USB.
The Arduino will wait a short while when attempting to upload. So you can press the reset and hold it until the Ide shows attempting to upload. then let go of it.
The problem can be that when you click upload the Ide first compiles then at the end of the process attempts to upload. So pressing reset, clicking compile and immediately letting go of reset doesn't always work because you let go of the reset too quickly.