I try to disable all logs on my program,
I did disable esp logs
but when I use printf in my channel and open make monitor
printf still works.
how and why?
I want to disable it.
The system logs and printf are two different things over here. In your project sdkconfig file check if the parameter 'CONFIG_CONSOLE_UART_DEFAULT' is set.
This defines where all your console outputs are dumped into.
In your case you want to disable all the printf logs, you can try setting 'CONFIG_CONSOLE_UART_NONE=y'.
If you are doing it thourgh make menuconfig of esp-idf, it will come under - component config > ESP32-Specific > UART for console output (Default: UART0, TX=GPIO1, RX=GPIO3) > None
Hope I answered to your question. :)
Related
I'm trying to use dbus/tools/GetAllMatchRules.py to get diagnostic information. When I run it without parameters as my regular user I get "GetConnectionMatchRules failed: did you enable the Stats interface?"
I modified GetAllMatchRules to print the specific exception details. It now says
GetConnectionMatchRules failed: did you enable the Stats interface?: org.freedesktop.DBus.Error.AccessDenied: The caller does not have the necessary privileged to call this method
So then I'm wondering, does it work at all? So I sudo su and run it again and it gives me the kind of information I'd expect to see, just not for the right bus. Oddly, if I use the --system parameter, even root gets org.freedesktop.DBus.Error.AccessDenied .
The repository claims, in bus/example-session-disable-stats.conf.in , that
"If the Stats interface was enabled at compile-time, users can use it on
the session bus by default. Systems providing isolation of processes
with LSMs might want to restrict this. This can be achieved by copying
this file in #EXPANDED_SYSCONFDIR#/dbus-1/session.d/
"
But that's clearly not the case because my user can NOT access this information.
I even tried a brute force approach to disabling (commenting out) ALL deny statements at /usr/share/dbus-1/system.conf and reloading and it still doesn't work. I also tried a full system restart in case I wasn't reloading correctly. I also did a system-wide search for system.conf in case it's actually using some other conf file that I'm not seeing, which would mean I'm modifying the wrong thing. I got a big hint that that's not the case when I had a typo (-- instead of --> for commenting out) and it failed to reload, but did reload once I fixed the typo.
I'm ok with the possibility that I can only do this signed in as root, so I also tried modifying GetAllMatchRules to use dbus.bus.BusConnection(), and force-feeding it the session address (unix:path=/run/user/1000/bus) which results in
"org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."
Incidentally, this is the same issue that happens if I leave the code alone but use sudo -E su instead of just sudo su (the -E option in this case means that the $DBUS_SESSION_BUS_ADDRESS variable is retained)
I'm not sure what to try next...
Turns out there isn't currently a solution, the privilege error is simply the code that was chosen to indicate that the method is an unimplemented stub method
For unit testing purposes, I want to be able to run a bare-metal binary with qemu and capture it's output.
Sample file:
#include <stdio.h>
#include <stdint.h>
static void qemu_exit() {
register uint32_t r0 __asm__("r0");
r0 = 0x18;
register uint32_t r1 __asm__("r1");
r1 = 0x20026;
__asm__ volatile("bkpt #0xAB");
}
int main(void) {
puts("This is some example text that I want to capture");
qemu_exit();
return 0;
}
Running with:
qemu-system-gnuarmeclipse --nographic --no-reboot \
--board STM32F4-Discovery --mcu STM32F429ZI \
--semihosting-config enable=on,target=native \
--image <binary>
Displayed to the console is:
QEMU 2.8.0-13 monitor - type 'help' for more information
(qemu) This is some example text that I want to capture
This 'example text' is generated within QEMU and so redirecting stdout to a file does not capture it (only: QEMU 2.8.0-13 monitor - type 'help' for more information
(qemu)). Looking at the available qemu logging options -d help does not offer anything as far as I can see.
EDIT
A hacky solution is to use script to capture terminal session:
script --quiet --command <qemu-shell-script-wrapper>
That's not an upstream QEMU, and 2.8 is also quite old, but hopefully the same things that work with upstream QEMU will work there.
Firstly, assuming you're not actually using the monitor, you can get rid of that part of the output by dropping '--nographic' and instead using '-display none'. (--nographic does a lot of things all at once, including both "no graphical display" and also "default serial output to the terminal, add a QEMU monitor and multiplex the monitor and the serial", among other things. It's convenient if that's what you want but sometimes it's less confusing to specify everything separately.)
Secondly, you say you're using semihosting output but is the guest's stdlib definitely using semihosting for its puts() string output and not serial port (UART) output? The output will come out on the terminal either way but how you tell QEMU to redirect it somewhere else will differ. (I suspect it may be using UART output, because if it were using semihosting output then the redirection of stdout that you tried should have worked.)
If the output from the guest is via the serial port then you can control where it goes using the '-serial' option (most simply, "-serial stdio" to send to stdout, but you can also do more complicated things like sending to files, pipes or TCP sockets.). If it's via semihosting then you can control where it goes using the 'chardev=id' suboption of -semihosting-config.
I am working on Android 9 provided by qualcomm. There are two uart devices /dev/ttyHSL0, /dev/ttyHSL1. ttyHSL0 is used for console and ttyHSL1 for communicating another chip. But my application cannot open /dev/ttyHSL1 device successfully.
it gives;
03-21 13:27:17.635 10303 10303 W edev.serialtool: type=1400 audit(0.0:23): avc: denied { read } for name="ttyHSL1" dev="tmpfs" ino=16426 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:serial_device:s0 tclass=chr_file permissive=0
when i set selinux to permisive mode in console, it works. But it needs to be permanent.
How can i add necessary rule to solve this problem?
Thank you very much and
keep yourself away from the coronavirus
stay#home
I apparently inadvertently changed some setting so all SCPI commands sent to my device that include a question mark throw a -110 (Command Header Error) as documented here:
-110 Command Header Error - Indicates there is a syntax error in the command. In this case two colons between SENSE and VOLT.Example " :SENSE::VOLT:RANGE 10"
All other commands (when used properly, of course) work fine.
Because of the error, my guess is that there's something wrong with how my computer is sending non-letters?
Note: I'm sending commands using #echo "READ?" > /dev/ttyS0. I still receive a reply using cat /dev/ttyS0 but I get a beep and error. (Same error occurs in my C code)
Just figured out the solution!
It appears that somehow (perhaps the blue screen I had yesterday on the Windows where I was running my linux VM from) the settings for ttyS0 were reset so that there was software flow control for sending data but not receiving. Thus, my transmissions didn't work with either no flow control or xon_xoff.
To fix this, I set no flow control on my external serial device and ran stty -F /dev/ttyS0 -ixon on the linux box.
Alternatively, I could have set flow control on the serial device to xon_xoff and ran stty -F /dev/ttyS0 ixoff on the linux box.
I am trying a program in c that controls keyboard handler to blink NUMLOCK & CAPSLOCK LED's as a reaction of ctrl+alt+del push... please help me..
I kinda agree with KP. This is funny...
But if yer serious...
First:
There's a setleds program that might help you get started. It's been around for ages... Try man setleds.
Also, xset can be used (under X-windows) to change leds... (You may have to see which leds are enabled for changing in the X-config file.)
Second:
Detecting ctrl+alt+del is more of an issue as it's flagged specially by init. Look in /etc/inittab or /etc/init/control-alt-delete.conf or someplace like that, and you'll see lines like:
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -h now
Or:
# control-alt-delete - emergency keypress handling
#
# This task is run whenever the Control-Alt-Delete key combination is
# pressed. Usually used to shut down the machine.
start on control-alt-delete
exec /sbin/shutdown -r now "Control-Alt-Delete pressed"
So you'd have to disable that... Or simply have it run your keyboard-blink program rather than /sbin/shutdown.
Also, watch out for "Control-Alt-Backspace" -- Many X11 config setups enable this combination to shutdown the X server. (Option "DontZap".)
Third:
Now you need to find a way to pickup the control-alt-delete keypress. It's not impossible, but it may not be as simple as getc(). (The again, I could be wrong...)
Of course, if you don't want your program to have the keyboard focus. If you want this to happen while other programs are running in the foreground with keyboard focus... Well then yer looking at tweaking the kernel or some kernel driver. (Or having inittab run yer program instead of /sbin/shutdown.)
Any way you slice it, this is not a good Hello World type exercise.
Option:
Find the right place to trap Alt+Ctrl+Del and register a handler.
Use the KDGETLED/KDSETLED ioctl on /dev/console to changes the keyboard LEDs.
Good Luck!