I have this simple code
#include <QtCore/qdebug.h>
#include <QtCore/qcoreapplication.h>
#include <iostream>
using namespace std;
int main(int argc, char **argv)
{
cout << "pluto" << endl;
QCoreApplication app(argc, argv);
qDebug() << "pippo" << endl;
return app.exec();
//return 0;
}
I compiled it with MinGw in Eclipse with no errors, but when I run the code no string message appear on the consolle. What is wrong? Thanks.
Luca
For cout to work on Windows, you need to have CONFIG+=console in the .pro file. It shouldn't have any effect on any other platform, so you can just add it there. You can use qmake conditionals if you only want it for debug builds or something., or you can pass it to qmake as command line option, if it is more convenient for your workflow:
qmake ...other args... CONFIG+=console
Under Windows, qDebug() output by default goes to Windows debug logs. You can get it in two ways:
Use an application such as an IDE or standalone DebugView tool from Microsoft.
Use qInstallMessageHandler Qt function in your program code, and catch the debug output, and do what you want with it, such as print it with cout and/or log it.
If you really need have that on output, you can try with QTextSteam:
#include <QTextStream>
QTextStream cout(stdout);
cout << "string\n";
QTextSteam cerr(stderr);
cerr << "error!\n";
Related
I got my program running fine as explained at: How can you make a micropython program on a raspberry pi pico autorun?
I'm installing a main.py that does:
import machine
import time
led = machine.Pin('LED', machine.Pin.OUT)
# For Rpi Pico (non-W) it was like this instead apparently.
# led = Pin(25, Pin.OUT)
i = 0
while (True):
led.toggle()
print(i)
time.sleep(.5)
i += 1
When I power the device on by plugging the USB to my laptop, it seems to run fine, with the LED blinking.
Then, if I connect from my laptop to the UART with:
screen /dev/ttyACM0 115200
I can see the numbers coming out on my host terminal correctly, and the LED still blinks, all as expected.
However, when I disconnect from screen with Ctrl-A K, after a few seconds, the LED stops blinking! It takes something around 15 seconds for it to stop, but it does so every time I tested.
If I reconnect the UART again with:
screen /dev/ttyACM0 115200
it starts blinking again.
Also also noticed that after I reconnect the UART and execution resumes, the count has increased much less than the actual time passed, so one possibility is that the Pico is going into some slow low power mode?
If I remove the print() from the program, I noticed that it does not freeze anymore after disconnecting the UART (which of course shows no data in this case).
screen -fn, screen -f and screen -fa made no difference.
Micropython firmware: rp2-pico-w-20221014-unstable-v1.19.1-544-g89b320737.uf2, Ubuntu 22.04 host.
Some variants follow.
picocom /dev/ttyACM0 instead of screen and disconnect with Ctrl-A Ctrl-Q: still freezes like with screen.
If I exit from picocom with Ctrl-A Ctrl-X instead however, then it works. The difference between both seems to be that Ctrl-Q logs:
Skipping tty reset...
while Ctrl-X doesn't, making this a good possible workaround.
The following C analog of the MicroPython hacked from:
https://github.com/raspberrypi/pico-examples/blob/a7ad17156bf60842ee55c8f86cd39e9cd7427c1d/pico_w/blink
https://github.com/raspberrypi/pico-examples/blob/a7ad17156bf60842ee55c8f86cd39e9cd7427c1d/hello_world/usb
did not show the same problem, tested on https://github.com/raspberrypi/pico-sdk/tree/2e6142b15b8a75c1227dd3edbe839193b2bf9041
#include <stdio.h>
#include "pico/stdlib.h"
#include "pico/cyw43_arch.h"
int main() {
stdio_init_all();
if (cyw43_arch_init()) {
printf("WiFi init failed");
return -1;
}
int i = 0;
while (true) {
printf("%i\n", i);
cyw43_arch_gpio_put(CYW43_WL_GPIO_LED_PIN, i % 2);
i++;
sleep_ms(500);
}
return 0;
}
Reproduction speed can be greatly increased from a few seconds to almost instant by printing more and faster as in:
import machine
import time
led = machine.Pin('LED', machine.Pin.OUT)
i = 0
while (True):
led.toggle()
print('asdf ' * 10 + str(i))
time.sleep(.1)
i += 1
This corroborates people's theories that the problem is linked to flow control: the sender appears to stop sending if the consumer stops being able to receive fast enough.
Also asked at:
https://github.com/orgs/micropython/discussions/9633
Possibly related:
https://forums.raspberrypi.com/viewtopic.php?p=1833725&hilit=uart+freezes#p1833725
What appears to be happening here is that exiting screen (or exiting picocom without the tty reset) leaves the DTR line on the serial port high. We can verify this by writing some simple code to control the DTR line, like this:
#include <unistd.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <termios.h>
#include <sys/types.h>
#include <sys/time.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <signal.h>
int main(int argc, char **argv)
{
int fd;
int dtrEnable;
int flags;
if (argc < 2) {
fprintf(stderr, "Usage: ioctl <device> <1 or 0 (DTR high or low)>\n");
exit(1);
}
if ((fd = open(argv[1], O_RDWR | O_NDELAY)) < 0) {
perror("open:");
exit(1);
}
sscanf(argv[2], "%d", &dtrEnable);
ioctl(fd, TIOCMGET, &flags);
if(dtrEnable!=0) {
flags |= TIOCM_DTR;
} else {
flags &= ~TIOCM_DTR;
}
ioctl(fd, TIOCMSET, &flags);
close(fd);
}
Compile this into a tool called setdtr:
gcc -o setdtr setdtr.c
Connect to your Pico using screen, start your code, and then disconnect. Wait for the LED to stop blinking. Now run:
./setdtr /dev/ttyACM0 0
You will find that your code starts running again. If you run:
./setdr /dev/ttyACM0 1
You will find that your code gets stuck again.
The serial chip on the RP2040 interprets a high DTR line to mean that a device is still connected. If nothing is reading from the serial port, it eventually blocks. Setting the DTR pin to 0 -- either using this setdtr tool or by explicitly resetting the serial port state on close -- avoids this problem.
I don't know why it works, but based on advie from larsks:
sudo apt install picocom
picocom /dev/ttyACM0
and then quit with Ctrl-A Ctrl-X (not Ctrl-A Ctrl-Q) does do what I want. Not sure what screen is doing differently exactly.
When quitting, Ctrl-Q shows on terminal:
Skipping tty reset...
and Ctrl-X does not, which may be a major clue.
Trying to record execution of Hello World with WinDbg from store.
WinDbg settings:
Executable path: C:\Users\...\Documents\Visual Studio 2017\Projects\TestApplication\Debug\TestApplication.exe
Output directory: c:\Users\...\Documents\
Code:
#include "stdafx.h"
#include "iostream"
using namespace std;
int main()
{
std::cout << "Hello World!\n";
return 0;
}
Error:
TTD: No trace files were identified from this record session
The debugging session could not be started: Path cannot be null.
Parameter name: path
Why it's does not work? What I am missing?
Occasionally TTD recording has trouble creating TTD files to paths with spaces. Recommend entering or pointing Output Directory to save TTD files to a path with no spaces.
Dear All I have a small Fortran program containing preprocessor macro. Below is a minimal example. On mac os x, it works well but when I compile it on windows 7 (64-bit) it always prints unknown operating system. I am using gfortran-4.8.0 (mingw32) on windows 7.
program foo
implicit integer(i-n), double precision (a-h,o-p),
+ character*8(x-z)
*
#ifdef _WIN64
zterm = 'wxt'
#elif _WIN32
zterm = 'wxt'
#elif __APPLE__
zterm = 'aqua'
#elif __linux
zterm = 'x11'
#elif __unix
zterm = 'x11'
#elif __posix
zterm = 'x11'
#else
print*, 'unknown operating system'
#endif
end program foo
Changing #ifdef _WIN64 to #if defined (_WIN64) did not help. Any suggestion will be appreciated.
This might be GFortran PR 42954. Since GFortran started using libcpp instead of running cpp in a separate process, many of these built-in macros are missing.
As a workaround, you can as part of your build process generate a file with these builtin macro definitions which you can then include. E.g. have a make target which runs
gcc -E -dM - < /dev/null > builtins.inc
Then your sources should depend on builtins.inc in the Makefile, and in the beginning of your source files you
#include "builtins.inc"
I have a simple OpenGL/GLFW test program in Eclipse
#include <iostream>
#include <string>
#include <GL/glew.h>
#define GLFW_INCLUDE_GLU
#include <GLFW/glfw3.h>
void errorCallback(int error, const char *description)
{
std::cerr << description << " (GLFW error " << error << ")" << std::endl;
}
int main(int argc, char **argv)
{
int returnValue = 0;
try {
// Initialise GLFW.
glfwSetErrorCallback(errorCallback);
if(!glfwInit()) throw std::string("Could not initialise GLFW");
/* ...do everything else... */
} catch(std::string const &str) {
std::cerr << "Error: " << str << std::endl;
returnValue = 1;
}
return returnValue
}
However, running it causes the following to come up in the console:
X11: Failed to open X display (GLFW error 65542)
Error: Could not initialise GLFW
i.e. it fails during glfwInit() (I commented out all the code just to make sure it doesn't actually happen during window creation or something). However, navigating to the build directory (using my file manager, not Eclipse, that is) and manually launching from there works just fine.
Anyone know what the problem could be?
Sounds to me like Eclipse clears all or some of the environment variables when launching the program. The environment variable DISPLAY tell the program how to connect to the X11 server. Without that information it can't open the display, giving you that error.
Simple test to verify this: Add the following like right before glfwInit() (never mind that this is not C++ and doesn't use iostream, but that's okay for a quick test:
fprintf(stderr, "DISPLAY=%s\n", getenv("DISPLAY"));
You must include the headers stdio.h and stdlib.h.
Eclipse indeed wasn't passing any environment variables to my program (thanks datenwolf for getting me started). It's possible to select which environment variables to pass to the program by going to Run Configurations, selecting the appropriate launch configuration under "C/C++ Application" (I only had the default one), opening the Environment tab and then hitting the select button (it lists all available environment variables) and picking which ones you want.
I just installed Allegro 5 from the terminal as outlined here: http://wiki.allegro.cc/index.php?title=Install_Allegro5_From_SVN/OSX#Preliminaries. However, when I try to write a program, it has trouble including allegro.h. I have tried:
#include <"allegro5/allegro5.h">
#include <iostream>
using namespace std;
int main () {
cout<<"foo"<<endl;
}
but I get the following error when I compile (using g++):
foo.cpp:1:33: error: "allegro5/allegro5.h": No such file or directory
I have also tried:
#include <"/usr/local/include/allegro5/allegro5.h">
#include <iostream>
using namespace std;
int main () {
cout<<"foo"<<endl;
}
but I get the following error when I try to compile:
foo.cpp:1:52: error: "/usr/local/include/allegro5/allegro5.h": No such file or directory
I know the file at /usr/local/include/allegro5/allegro5.h exists. I have already tried #include <"/usr/local/include/allegro5/allegro.h"> and #include <"allegro5/allegro.h"> as well all with similar results. I know this is a pretty basic question and I just want to be able to write a program which can successfully include allegro.
The double quotes are erroneous and the file is not correct. It should be:
#include <allegro5/allegro.h>