I am new to Linux system calls.My question is do we have a system call in Linux to plot points on screen.I googled it but could not find any simple explanation for it. I want to write a simple C program in Linux that directly plot a point on screen without the help of a C graphics library.
If there is no such system call how can I create my own system call to plot point on screen?
The lowest level hardware independent graphics interface on linux is the framebuffer. This is manipulated by writing to a device node (generally /dev/fb0) which is the equivalent of a system call, since it is a means of sending requests to the kernel. So this does not require any libraries.
A common approach seems to be to mmap() a chunk of user space memory representing the screen to /dev/fb0 and then manipulating that. There are some ioctl() calls to get information about the framebuffer display. A good starting place for information would be the docs in the kernel source -- src/Documentation/fb is a whole directory, see e.g. "framebuffer.txt" and "api.txt" there. There are a few tutorials and such around if you look online. It doesn't matter particularly which kernel version source you look at -- the last revision of "api.txt" was 2011 and "framebuffer.txt" a decade before that (so the interface is very stable).
Note that you can't use the framebuffer from within X. If you want to do graphics stuff within X, you have to use at least Xlib, or a higher level library built on that.
#define MAX_SCREEN_AREA 100
int Gotoxy(int x, int y)
{
char essq[MAX_SCREEN_AREA]={0}; // String variable to hold the escape sequence
sprintf(essq, "\033[%d;%df", y,x);
printf("%s", essq);
return 0;
}
Try this.
Related
Could you point me in right direction? Now I am looking system call g_io_getattr..
I do not want to call subprocess.
The return would be e.g. 'da0', 'da1' or 'ada0'...
You are most likely going to want to be working with FreeBSD's libgeom - specifically geom_gettree(). The source to freebsd's partedit - shows it being used and the resulting structure being iterated through in the read_geom_mesh and related functions in order to get a list of the disks. What appears to be the source of the geom program also demonstrates some usage of the geom_gettree function and iterating through its returned structure.
I am trying to read the MCU_ID (device electronic signature) from STM32L476 chip using a JTAG ST-Link/V2 on Windows 7. No code has to be uploaded inside the chip, the program shall just be launched on my cumputer and read this information from the flash memory.
I have managed to find and extract the following screenshot from the Reference Manuel given on ST website :
So I have to read the value stored in the flash memory at the adess 0x1FFF7590 by using a C program. I am using the Atollic TrueStudio IDE which is recommended by ST itself, but it seems to me that it includes the "stm32l476xx.h"library which does not even contain any function which could help me.
What I have done so far
After spending days and days looking for some functions or examples to do something as simple as read flash memory, I have asked on this very site How to interact with a STM32 chip memory, which helped me understand a couple of things about what I had to do; nevertheless, I haven't been able to find what I was looking for even after days reading all the links and docs advised in the comments.
I have asked a couple of professionals who told me that I should search for a JTAG driver to interact with the flash memory, but it seems a bit complicated and I haven't been able to found any.
Someone on this site told me that simply using pointer should be enough; the lack of C example and internet tutorials couldn't help me figure out how to do so.
Finally, I started recently digging around STM32Cube and HAL, even since I wanted to avoid using those because I thought that a simple read could be done without having to include those layers. Asking this question is my final hope before trying to use them.
In Conclusion :
I can't show any code since the only thing I have so far is a #include "stm32l476xx.h"and an empty main.
A hint or solution on How to read a STM32L476's flash memory in C would be just perfect. Every example of C (or any programming language which would be as low or higher level) program or instructions interacting with a STM32 chip's memory could help me a lot since it is very hard to find on internet.
Reading MCU ID using ST-Link (graphical interface)
You can use ST-Link Utility (can be downloaded from ST.com here: http://www.st.com/en/embedded-software/stsw-link004.html). After you do Target->Connect you can specify the address and number of bytes you want to read on top of the Window. This also works for the memory area where MCU ID is defined.
For STM32L476 MCU that you use it's going to be memory address 0x1FFF7590, size 0xC (96 bits). Pressing enter should allow you to see the unique ID read from the MCU you're connected to, in form of 3x32 bit values.
Reading MCU ID using ST-Link (command line interface)
ST-Link Utility provides CLI (command line interface) to do the most common operations. This is done using ST-LINK_CLI.exe located in your ST-Link Utility installation directory.
Reading Unique ID as 32-bit values (STM32L476 MCU from the example):
ST-LINK_CLI.exe -r32 0x1FFF7590 0xC
Reading as 8-bit values:
ST-LINK_CLI.exe -r8 0x1FFF7590 0xC
You can also read it to file using -Dump parameter:
ST-LINK_CLI.exe -Dump 0x1FFF7590 0xC D:\temp\out.bin
Keep in mind that you must have the priviledges to write to the destination directory. If you don't run the command prompt with administrative priviledges, in most common cases this means that you won't be able to create the file in locations such as root drive directory (C:\out.bin) or inside "Program Files", where most likely your program is installed (for example by specifying a relative path, such as giving an output file name only out.bin). The program sadly doesn't inform about failed attempts to write the file, however it does say when it succeeds to create the file. The program execution should end with a green line saying Dumping memory to D:\temp\out.bin succeded. In addition, keep in mind that only the following file extensions are supported: *.bin *.hex *.srec *.s19. It cannot be anything because the extension determines the format in which the data will be written to the file.
You can find more information about CLI parameters in User Manual UM0892.
Reading MCU ID using C code
The same can be done using a program loaded into the MCU. You read it by simply accessing the memory directly. Sample code:
#define STM32_UNIQUEID_ADDR 0x1FFF7590
uint32_t id[3];
id[0] = *(STM32_UNIQUEID_ADDR + 0);
id[1] = *(STM32_UNIQUEID_ADDR + 1);
id[2] = *(STM32_UNIQUEID_ADDR + 2);
After this operation id array should contain the same 3x32bit values you've previously read using ST-Link Utility. You may of course choose to read it as uint8_t byte array of size 12, you may even choose to read it into a struct, in case you're interested in the details (lot number, wafer number etc.). This example should however give you a general idea of how to access this value.
There is Texane stlink, that does what you want. It's written in C, interacts with STM32 chips through an ST-Link adapter, and it can read from chip memory.
What you are looking for is not a feature of ST but a feature of ARM.
Remember, ST simply uses an ARM core. I know most programmers load some code in RAM and use that to access flash. You can find these simple programs in the install directory or Keil for example.
I think this is the manual you will need. But I don't know if there is more information behind the login-wall.
I was reading this tutorial on building a simple virtual machine/bytecode interpreter. It had instructions like PUSH, POP, HALT, etc... these instructions are decoded and evaluated in a switch, so you would say if the current instruction equals PUSH, then you would push it to a stack. But what if I wanted to print out a string or character?
In assembly, you would use make a string in .data, push the length, then the message, then the file descriptor for stdout (1), the system write call number so 4 (for 32 bit), and then do int 80.
How would I do something like this for a virtual machine? Would I handle it similarly? I thought maybe I could just dump whatever I wanted to write in a register, and then printf the contents when it has something other than (magic number) in it, but that doesn't seem like a good idea.
"Printing" is assuming having some kind of IO (input/output) system with an output device capable of presenting data on it (as a printer or display). On a virtual machine such a device can be only virtual as well, and it is up to the VM implementation how it would be emulated. For example it can have a specific well-defined memory range, which is the "video memory", such that writing there is interpreted as sending data to the output device, which can be emulated by, say, a textbox in you VM's interface.
You need to create a way for programs to access the screen - they can't do it "automatically".
For example (as suggested by Eugene Sh.'s comment): create a PUTCHAR opcode, which pops a number from the stack and prints it to the screen (with the normal C function putchar).
I am having trouble setting up any kind of functionality to my Kernel that I am writing in C. I have moved on from the steps of writing my boot loader in Assembly, and then compiling and loading my C Kernel into memory and running it.
The problem is, whenever I try to add any sort of backbone such as a VGA graphics class to easily organize methods to render to the VGA memory, my Kernel freaks out and the emulation just starts to continuously redraw itself and I don't see any resemblance to what I am trying to render to the VGA memory.
I have tried setting up a back bone in many different ways, by following countless tutorials online and I am content to use a sort of terminal interface one, if it would start working.
I have been uploading my code to a Bitbucket repository which includes my Makefile, Assembly boot loader, Assembly kernel entry point, and all of my Kernel C source files. I will keep it public and refrain from committing anything into it so you all can reference it until I find the answer I am looking for.
Here is my Bitbucket repository for my "Operating System" in the works.
I am running on Ubuntu 14.04 Desktop 64 Bit. If you need any other information or resources to help you come to an answer, please let me know and I will make an edit.
Thank you in advance for your help and consideration.
EDIT:
Apparently organizing my code to a Bitbucket repository for display is frowned upon, so I will try to give you a detailed jist of what exactly I am doing that might be causing a problem.
My boot loader runs and reads 15 sectors (15 * 512 bytes) of my Kernel into memory, although my Kernel may not have 15 sectors of data this doesn't seem to be causing a problem (Unless it is causing a problem and I don't know about it). I load my Kernel into the address offset of 0x0500 After that, I initialize my stack (Before jumping into my Kernel) to be located at address offset 0x9FBFF.
After that, I jump to my Kernel (Actually, I jump to my Assembly Kernel Entry file which calls the C Kernel's main function).
When my Kernel starts running, it attempts to use some back bone files that I have made to draw text graphics to the VGA memory address 0xB80000. I can do simple things such as this line of code.
unsigned char* vidmem = (unsigned char*) 0xB80000;
*vidmem = 'X';
And it works fine, I can see an X in the top left corner of my emulator along with the other graphics from the boot loader that haven't been overwritten yet.
The problem starts to come in when I try to do more complex things, such as call other back bone source files that attempt to draw text graphics to the screen at different columns and rows, store the last column and row printed to, handle scrolling, print entire strings and account for scrolling and new lines, etc.
I am completely stuck as to why this is happening and I have a moderate to beginner understanding of how this memory and assembly instruction interacts with the computer in a way that might be causing a problem.
Again, any help on this issue would be much appreciated.
The most obvious issue I see is that your logic for addressing VGA memory is wonky.
You declare a pointer to video memory as a unsigned char *:
unsigned char* terminal_buffer;
...
static unsigned char* const VGA_MEMORY = (unsigned char*) 0xB8000;
...
terminal_buffer = VGA_MEMORY;
However, you are then trying to write full VGA character values into each position, e.g. in terminal_init():
const unsigned int index = r * VGA_WIDTH + c;
terminal_buffer[index] = make_vga_entry(' ', terminal_color);
You aren't multiplying the index by 2, so this ends up writing the lower 8 bits of a VGA entry (in this case, 0x20) into each memory location in the VGA buffer. This causes strange results when you start writing text to the terminal, as every other byte ends up interpreted as an attribute pair instead of a character!
Thankfully, the solution is simple: declare terminal_buffer as an array of 16-bit elements:
uint16_t *terminal_buffer = VGA_MEMORY;
^^^^^^^^
(P.S: I recommend taking a look at the OSDev article on VGA hardware.)
How would I change a pixel on a display, in C?
Assume NOTHING: I am using a linux machine from console to do this. I do not want to use GUI toolkits or frameworks to draw the pixel. I do not want to draw the pixel in a window. I want to draw the pixel directly to the screen.
EDIT: I have a screen. I'm on a laptop running linux from console. I'd prefer a solution not using X as I'd rather learn how X works than how to use X.
If theres more information, ask, but don't assume. I'm not trying to build a GUI, and that was the main purpose of blocking assumptions as I don't want people to assume I'm doing things the long way when in reality I'm just tinkering.
EDIT 2: You may use any X11 related libraries provided that you can explain how they work.
If we really assume nothing, can we even assume that X is running? For that matter, can we even assume that there is a video card? Perhaps Linux is running headless and we're accessing it over a serial console.
If we are allowed to assume a few things, let's assume that Linux has booted with framebuffer support. (It's been a couple years since I worked with Linux framebuffers, I may get some of the details wrong.) There will be a device created, probably /dev/fb or /dev/fb0. Open that file and start writing RGB values at an offset, and the screen will change, pretty much regardless of anything: text console, graphical console, full-fledged desktop envrionment, etc. If you want to see if framebuffer support is working, do dd if=/dev/zero of=/dev/fb on the command line, and the display should go all black.
C doesnt have any graphics capabilities - you'd need to use a third party library for this.
You cannot assume a display in C. There is literally no way to do what you ask.
Edit: Okay, you have a display, but again, there's not a whole lot you can get from there. The point is that there are a TON of competing standards for graphics displays, and while some of them (VGA interfaces, for example) are standardized, a lot of the others (display driver interfaces, for example) are NOT. Much of what X (and other display device drivers, such as Windows or the like) do, is have specific interface code for how to talk to the display drivers; they abstract out the complexity of dealing with the display drivers. The windowing systems, though, have HUGE libraries of complicated and specific code for dealing with the display drivers; the fact that these things are relatively transparent is an indication of just how much work they've put into these things over time.
Very primitive and making a lot of assumptions:
fd = open("/dev/fb0", O_RDWR);
lseek(fd, 640*y+x, SEEK_SET);
write(fd, "\377\377\377\377", 4);
In reality, you would use mmap rather than write, and use the appropriate ioctl to query the screen mode rather than assuming 640xHHH 32bpp. There are also endian issues, etc.
So in real reality, you might use some sort of library code that handles this kind of thing for you.
I suppose you could paint to the terminal program that you are using as your console. All you have to do is figure out which one that is and look it up.
Whoops I assumed a terminal. :P
I think what you are looking for is information on how to write to the frame buffer. The easiest way would be to use SDL and render to the frame buffer, or else use GTK+ with DirectFB, although that goes against your edict on not using toolkits or frameworks.