I am trying to port a Clean graphics library (specifically, ObjectIO) to Linux with GDK. The library consists of a non-OS-specific part, which I don't want to touch because of compatibility issues, and an OS-specific part which I can touch.
One of the functions I have to implement is one that takes raw data from a .bmp file and has to build a GdkPixbuf from this. This function has to be written in C.
I am aware of the function gdk_pixbuf_new_from_file(), but I do not get the file name (and can't change that, as it's in the non-OS-specific part of the library). I only get the raw data.
I saw this manual entry, and I guess I could use gdk_pixbuf_new_from_data(), but this requires that you know the row stride of the image, of which I'm unsure how to get it.
Is there a way to get the row stride from the file? If not, the only possibility I see is to create a temporary file with the data and then call gdk_pixbuf_new_from_file() - but that would be really ugly.
You want to use the function:
int stride = cairo_format_stride_for_width(CAIRO_FORMAT_RGB24, ImageWidth);
Related
Context
I'm currently working on a firmware for a STM32F411CEU6, using STM32CubeIDE, I'm going to be programming several UC's, everyone of them is going to have an ID (a 32 bit unsigned number), this number is static and it will never be change in his lifespan, we are a small team but maybe we will have to program a few hundred of these devices, so changing the value associated whit that ID in the code manually will be kinda exhausting, and time consuming, so, my question is:
¿Is there a way to compile different versions of firmware so it generate several .bin files, each one whit the only difference that this single constant change?
¿Is there a way to automate this process?
What have I thought
I have thought on defining this constant (and other constants if I have to) on a header file, then use something like Python to make different versions of the code, but then I would have to open every project or workspace and still have to compile and produce every .binfile manually, ¿Is there a way to produce the .bin file from python (using the STM32CubeIDE), or something like that?
Additional information
Working on a STM32F411CEU6
Using STM32CubeIDE
I have basic knowledge in python C++
Medium-advance knowledge in C
Thanks in advance!
Any help would be very much appreciated
Here are a few ideas.
The STM32F411 chip is pre-programmed (by STMicro at the factory) with a 96-bit unique device ID. Perhaps you can use the device's unique ID for your purposes rather than creating and assigning your own ID value. See Section 24.1 of the reference manual. This seems much safer than trying to create and manage a different bin file for each ID value.
If you really want your own custom ID value, then program the ID value separately from the firmware bin file so that you don't need to create/manage different bin files for each unit. Write the program so that the ID value is at a known fixed address in ROM. Use the linker scatter file to reserve that address for the ID value. Program the ROM of each unit in two steps, the bin file and the ID value.
If you really want to incorporate the ID value into the bin file then you can use a tool such as srec_cat.exe to concatenate bin (also hex or srec) files. It's very versatile and you should study the man page. One example of how you could use this tool is this: In the source code for your program, declare your unique ID value a constant pointer to a constant value located at a fixed address in ROM beyond the end of the ROM consumed by the bin file. Build the bin file like normal. Then run srec_cat.exe to concatenate the unique ID value to the bin file with the appropriate offset. You could write a script to do this repeatedly for each unique ID value. Perhaps this script runs as a post-build action from the IDE. This solution could work but it seems like a maintenance nightmare to ensure the right bin file gets programmed onto the right device.
If using a hex file is an option, you could avoiding the need for re-compilation like so:
Reserve some flash space outside of your program (optionally configure the linker script to make sure no data is placed in that section).
Use a python script to generate intel hex data with the required ID placed in the reserved location.
Simply concatenate the two hex files and program as usual. I tested this with STM32 ST-LINK Utility / STM32CubeProgrammer.
To generate the hex data, you can use the intelhex package. For example:
import struct
from intelhex import IntelHex
from io import StringIO
ID_FLASH_ADDRESS = 0x8020000
hex_data = StringIO()
ih = IntelHex()
ih.puts(ID_FLASH_ADDRESS, struct.pack('<I', chip_id))
# Output data to variable
ih.write_hex_file(hex_data)
# Get the data
hex_data.getvalue().encode('utf-8')
Notes:
See the struct documentation for the meaning of '<I'.
I output the data to a variable, but you could also write directly to a file. See intelhex documentation.
I have a piece of code using a FILE* file with a fwrite:
test = fwrite(&object,sizeof(object),1,file);
I want to serialize some internal data structure with an indexing structure (so, I'm using neither Google's Protobuf nor Cap'n Proto, since that is a custom data structure with some specific indexing requirements). Now, inside my project, I want to use Google Test in order to test the serialization, in order to check that what it has been serialized it could be deserialized and easily retrieved, too. In the testing phase, I want to pass to fwrite a FILE* object which is not a file, but a handler to some allocated main memory, so that no file is procuded, and that I can directly check the main memory for the results of the serialization. Is it possible to virtualize the FILE* and to write directly into the main memory? I would like to keep fwrite for writing data structures for performance reasons, without being forced to write two different methods for serialization (Sometimes i'm writing on the fly with no further memory occupation for transcoding). Thanks in advance.
One way is to create a dynamic library with all those fopen/fwrite functions (that would do something for your magic filename and fall back to the original ones otherwise) and load it with LD_PRELOAD. To fall back to the originals, resolve them with "dlsym" and RTLD_NEXT.
Another way is to include a special header at the top of the library/test which would have a statement like "#define fopen my_fopen". Inside the file with the implementation of "my_fopen" you need to put "#undef fopen" before including original "stdio.h". This approach will only work for your source code files that include the header but will not hook the functions for the binary libraries that you link.
fopencookie did the job I was looking for.
http://man7.org/linux/man-pages/man3/fopencookie.3.html
Can I Create FILE Instance (FILE*) by byte[ ] data (on Memory)? Don't Write file.
(C, Linux)
I Need for 'MiniSEED' format data parsing by offical MiniSEED Library.
These Library is supported parsing 'MiniSEED' format packet Data that was written in file.
But I Need to parsing 'MiniSEED' data in Byte[] array directly. don't create real file.
(because I must get 'MiniSEED' data by realtime TCP Packet, continuously
and These Library support only way to parse data by written file.)
So I try to solve the problem Created FILE Instance by byte[] data directly.
I think this solution is best way without changing the library as an easy way.
You can create a FILE handle from in-memory data in Linux, because the Linux C libraries do support fmemopen() from POSIX.1-2008.
Calling fmemopen(buffer, size, "r") yields a read-only FILE handle to an in-memory object containing size bytes at buffer.
However, I don't understand why you'd need such a thing.
The official Mini-SEED library does provide function msr_unpack() (and msr_unpack_data()) to parse Mini-SEED data records.
The functions you are probably looking at using, ms_readmsr() and ms_readtraces() (or their thread-safe variants ms_readmsr_r() and ms_readtraces_r(), just read each record from the file, passing each to msr_unpack() (and in case of traces, to mst_addmsrtogroup() or mstl_addmsr()).
In other words, the library does support parsing in-memory data. Your assertion that it only supports parsing files is clearly incorrect.
The man pages describing the library functions do not seem to be available on the net, but if you download libmseed sources, you can read the library function man pages using man -l libmseed/doc/[function].3.
As a compromise, you might use mmap to create a direct mapping between the memory and the file. This will allow you to update the contents directly (by accessing the memory) and the library may access the same data through the file interface. Under Unix systems, depending upon the size of the data, the file may not actually need to be written to disk. It may reside in the kernel's cache structure for faster access (this happens by default: nothing extra you need to do).
No, there's no portable, standard way of creating a FILE * that represents an in-memory stream of bytes.
The typical solution is to instead make the read and write function(s) hookable, so that instead of hard-coding e.g. read() you make the library call an (optionally) application-supplied function.
I want to be able to use OpenGL to create a video output file instead of the usual display on screen output. I am thinking by not using glutPostRedisplay() or (SFML version, which is something like this:) window.Display(), and somehow using glReadPixels() instead.
glReadPixels puts the pixel content into an array in memory (as you might already know) but how can I convert that into a frame, and string several frames together in a video file? And what format would the video file be in, so that I can play it?
I should explain why I want to do this: A lot of physics simulations can take a very long time to calculate enough information to display one frame, so it's better to leave it running overnight and play the video file the next morning. You wouldn't want to keep coming back every 5 minutes to see what had happened.
glutPostRedisplay is part of GLUT and not something specific to OpenGL.
You normally do offscreen rendering using either a PBuffer or using a hidden window and a framebuffer object.
Converting a image into a video can be done in various ways. For example you could utilize FFmpeg using image2pipe as input format and write the raw image data to the ffmpeg process standard input. A much simpler scheme would be to dump each frame into a separate image file. Using libpng is straightforward. You can then merge the individual images into a video.
However when doing physics simulation you should not dump the final rendering into a file. Instead you should store the simulation data for later playback, as you then can adjust rendering parameters without having to re-simulate everything. And you will have to make adjustments to the renderer!
I'm making a program and one of the things it needs to do is transfer files. I would like to be able to check before I start moving files if the File system supports files of size X. What is the best way of going about this?
Go on with using a function like ftruncate to create a file of the desired size in advance, before the moving, and do the appropriate error-handling in case it fails.
There's no C standard generic API for this. You could simply try creating a file and writing junk to it until it is the size you want, then deleting it, but even that isn't guaranteed to give you the info you need - for instance another process might have come and written a large file in between your test and your transfer, taking up space you were hoping to use.