I'm building a real time simulink application to interface with a robot. Is there a way to output variables to the terminal when I run the executable (C code generated by simulink coder and then built)?
I ultimately want to see the output of the axes a joystick I have connected.
As it stands now, when I run the application, the prompt goes blank and the robot's speaker turns on (as intended). Before I start controlling its joints with a controller I want to see actual output of the analog sticks in the terminal so I know that it actually works.
It's just a way for debugging.
So my question is: How do I echo out variables into the terminal using simulink coder?
Related
I'm starting to use CubeIDE to program a NUCLEO-F401RE board (with sensors attached) and in one of my projects I had to get the voltage of the board and print it somewhere on my laptop (connected to the board via usb cable).
I got this to work using HAL_UART_Transmit function to send the string and PuTTY, on my laptop, to receive and print the string.
Now, I noticed that there is a Console integrated in the IDE where the IDE automatically prints control information, compilation errors and such and I'd like to print the voltage (possibly using printf since I'm programming in C) here rather than using PuTTY, but it doesn't seem so straightforward (as in many other IDEs that I've used) from what I've read on the internet, for instance, here.
I get that here we have two different computers talking to each other, so printing using printf is not as easy as in other situations where code is written, compiled and executed all on the same computer.
My question is:
why isn't there a "console tab" in the IDE where the result of the printf, generated on the board, is displayed? And if there is, how to set it up? Is it simply some settings configuration in the project properties or do I have to modify the low level I/O C functions as stated in the discussion linked above?
Thank you.
Create a new Command Shell Console.
Configure the new Console just as you did with PuTTY.
I am currently developing an audio application using Portaudio.
To test it, I would like to control the input and thus check the output of my application. However, I would love to achieve this only internally.
Do you know of any software able to emulate a soundcard, whose output would be the input of my Portaudio program and whose input would be the output of my Portaudio program?
Working under Raspian, i have 2 Setups where i am generating 6 gnuplots in a C-program (with pipes). I have gnuplot 4.6, patchlevel 0 installed on both.
Setup A: Everything works as expected.
Setup B: The plots are not generated. I started to investigate some time, downloaded the examples for the C-Interface. It compiled and executed the examples without error, but no images showed up. when i entered the commands via shell manually (for example sine.png)
gnuplot
gnuplot> set terminal png
gnuplot> set output sine.png
gnuplot> plot sin(x)
the output is generated as expected.
Conclusion: I suppose I am missing some librarys on system B. but since nothing is actively complaining, I don't know where to start searching?
By hazard I figured out what the problem was - speed. I found out that placing a
sleep(x.y);
in between my code is solving the problem. Since I'm not working on a time critical application and the code doesn't have to be optimized, the problem for me is solved.
Apparently on windows this issue is well known, see here. Still unclear to me why this would happen on the newer hardware only.
I am trying to interface a 16x2 LCD with Beagleboard xM using GPIO. I have done this by using a shell script and it's working very good. Now I want to achieve the same functionality by writing a kernel module. I know little bit about kernel programming as I'm in the learning phase. Need some guidance. Thanks in advance!
Writing a kernel module is different then shell scripting. You must write your own code in C++, declaring the kernel mode, and then compile it. I found one example, but don't have time to check it, so I am leaving that to you.
Here is one example of writing kernel modules, and here is one tutorial for interfacing 16x02 lcd.
If you have a script you can load it like a module in linux ,
In /etc/rcS.d folder you will find a lot of scripts like S13-some_name.sh . These scripts will be automatically run by the kernel while booting up. So you can just add your scipt here to make it as a module
So one thing have to do is find the last number used in these list of scripts and rename your driver script by prepending the next number to the last in the list
for eg:
if the last script in /etc/rcS.d is S53logger.sh
Rename your scipt as S54-name-.sh (don't forget to change attributes by chmod +x)
If the /etc/rcS.d is not present there might be a file rc.local file you just add the driver script to it
How exactly would one go about getting an OpenGL app to run fullscreen straight from the terminal (Ubuntu Server 9.04)? I've developed an application for visual diagnostics on my server, but, I'm not totally sure the best way to get it to run in a windowless environment.
Ideally, I would run my program:
./visualdiagnostics
and have that launch the OpenGL app. Then, via a simple Ctrl+X key binding, I'll kill the app and go back to the terminal.
Do I need to install X11 and then somehow launch it from within the program? What would be the best way to detect if it's already running and, start/stop it if necessary?
And FYI: No, I'm not trying to get this to run over Putty or anything... I have a monitor hooked straight up to the server. The server has proper video drivers installed.
There are several parts to your task. Keep in mind that some of this can be very distro-specific; but since you said Ubuntu we'll talk Ubuntu!
Also you tagged this question C however I am starting off with a common Linux pattern: a native application with a Bash shell script wrapper. Perhaps once you get things working well you might fold that functionality into C if you have to.
Detecting whether X is running
Being root can help a lot. Some things that work.
pgrep Xorg
Check whether /var/lib/gdm/:0.Xauth exists. This will be there even if nobody has logged in but GDM is running.
ls -l /home/*/.Xauthority (Even if you're not root you can at least confirm whether you are running X.
Piggybacking an existing X session
You did not specifically mention it but if you are root at the console, or if you want to run the app as the same user who is already logged in, it's pretty easy.
You have to get the DISPLAY and XAUTHORITY environment variables right, and once you do you can use the existing X display.
For DISPLAY you might just assume :0 or you could find an existing X program (x-session-manager is the GNOME standard) and read its environment from /proc/PID/environ. Variables are in key=value format delimited by a null byte. For example, if its PID is 12345:
cat /proc/12345/environ \
| ruby -ne 'puts $_.split("\0").select {|e| e.starts_with? "DISPLAY=" }'
For XAUTHORITY you could get it the same way. Or if you prefer guessing, it's almost always /home/whoever/.Xauthority
Once you have those two variables, running X code is easy, for example:
env DISPLAY=:0 XAUTHORITY=/home/brian/.Xauthority ./visualdiagnostics
Stopping X
This one is easy if you're root: /etc/init.d/gdm stop. killall Xorg will work too.
If you are a user, kill your own Xorg or x-session-manager process. (I'd welcome input from others for the canonical way to do this. Maybe some dbus-send message?)
Starting X
I would recommend xinit whose goal in life is to fire X and run exactly one program.
For example: xinit ./visualdiagnostics
You can also tell xinit what resolution to run X at which may or may not be important to you. (This becomes important in the full-screen section below.)
The problem with this is you will have no window manager— no maximize and minimize buttons. It's not just cosmetic. Usually an app is useless because a popup window cannot be moved or you cannot focus on the right input field. However if you have a special app it could be sufficient (see full-screen below).
The next step would be my answer to everything: another shell script wrapper! Something simple that starts the window manager and then becomes your program should work.
#!/bin/bash
#
# Start visualdiagnostics once xinit calls me.
/usr/bin/metacity& # Or ratpoison, or fluxbox, or compiz, etc.
exec ./visualdiagnostics
It's important to exec (become) the main program because once that first program exits, X will shut down.
Running fullscreen
I am not 100% certain on this. Some ideas:
Try the standard X -geometry parameters to set 0,0 as the upper-left corner and +x+y for your horizontal and vertical size. How do you know the size? Either you hard-coded it when you launched xinit or you could ask the X server. xwininfo -root will tell you and there is an xlib API call that would do that too—check the xwininfo source I guess.
Your app itself can request maximization and/or resizing to fill the screen. I'm not familiar but it is definitely in the X API.
Some of the more configurable window managers can be pre-configured to run you maximized already. This is probably what I personally would check first. Your wrapper script could create a $HOME/.fluxboxrc just by echoing some hard-coded configs > the file.
Summary
The others are right. X is not strictly necessary sine OpenGL can run against a framebuffer. However considering how ubiquitous X is and how much work has gone into automating it for distributions, I would probably invest my effort into the X route as it might be easier long-term even though it's a little convoluted.
(By the way, I sincerely hope when you say "terminal" you mean you are at the text console, not gnome-terminal that would be awful! :)
Well I am clearly not sure my answer might help you out.
Long ago when I was student, I manage to do so (launching an openGL app from a terminal only linux installation) by installing frame buffer. As long as I remember I needed to recompile my kernel (as framebuffer was/is a kernel module).
This was maybe 5 years ago on a debian distrib, and I don't know how does it work now for up-to-date debian distrib as Ubuntu. Maybe framebuffer is compiled statically in the binary kernel provided by default with Ubuntu. May be not. Maybe framebuffer is irrelevant now... Or I may be totally wrong and not remembering every details of my own adventure 5 years ago now ..
Have a look on Google ! ;-)
Hope it will help...
**
Update:
**
What is frame buffer ?
How to install it? Here or there
As yves pointed out, you can avoid running the X server if you use the framebuffer. Actually, the framebuffer modules are often yet available (for example, they are used to have the tux logo during the kernel start or a text terminal with fancy images in the background), this anyway depends on the distribution and the settings you are using.
The kernel side is quite primitive so I'd suggest to use some higher level library such as DirectFB. The framebuffer is usable without problems but don't expect the same maturity level than a full blown X server.
Are you trying to have the video be on the monitor connected directly to the computer?
Is X running on the server?
If X is running, you can do
export DISPLAY=:0.0
which tells X apps to connect to the X server at localhost, rather than where' you're coming from.
If you're actually logging in locally (from a direct terminal) ... yes, you need X installed and running.