Header file:
/* Position Modes (fst_posmode) for F_PREALLOCATE */
#define F_PEOFPOSMODE 3 /* Make it past all of the SEEK pos modes so that */
/* we can keep them in sync should we desire */
#define F_VOLPOSMODE 4 /* specify volume starting postion */
Man page:
The position modes (fst_posmode) for the F_PREALLOCATE command indicate how to use the offset field.
The modes are as follows:
F_PEOFPOSMODE Allocate from the physical end of file.
F_VOLPOSMODE Allocate from the volume offset.
The doc is hard to understand.
Related
I am using libwebsockets library. This exposes certain methods for writing into a log file.
lwsl_warn(...), lwsl_err(...) and lwsl_err(...)
to name the most common.
The output is color coded using ANSI sequences.
Is there a way to set the default color scheme (other than recompiling the library)?
Thanks.
I poked around in the libwebsockets source and found my answer:
The colors are hard coded - so the answer to my original question is "no".
However, the color scheme is not hard to find and edit. It resides in two source files - one of these is compiled depending on options:
libwebsockets/lib/core/logs.c
and
libwebsockets/lib/plat/optee/lws-plat-optee.c
All it takes is to edit the self-explanatory table:
static const char * const colours[] = {
"[31;1m", /* LLL_ERR */
"[36;1m", /* LLL_WARN */
"[35;1m", /* LLL_NOTICE */
"[32;1m", /* LLL_INFO */
"[34;1m", /* LLL_DEBUG */
"[33;1m", /* LLL_PARSER */
"[33m", /* LLL_HEADER */
"[33m", /* LLL_EXT */
"[33m", /* LLL_CLIENT */
"[33;1m", /* LLL_LATENCY */
"[0;1m", /* LLL_USER */
"[31m", /* LLL_THREAD */
};
Then build as before. Once in the libwebsockets/build directory do the following:
make clean
make && sudo make install
sudo ldconfig
... and enjoy!
Context
I am using an i.MX6 ULL application processor with a Goodix 9271 touch-screen display. The display has been added to the device tree and is working correctly. I now wanted to add the touch controller, which is connected to my application processor via I²C. I therefore added
A new node under my I²C node which adds the controller as a device on the bus.
A new pin control group for the application processor to interface with the touch controller
I have enumerated them here:
/* #1: Device node on the I2C bus */
&i2c1 {
clock_frequency = <100000>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_i2c1>;
status = "okay";
/* Awesome new touch controller */
gt9271_ts#5d {
compatible = "goodix,gt9271"; /* Device tree binding */
reg = <0x5d>; /* I2C bus address */
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_gt9271_ts_gpio>; /* Custom pinctrl group node */
interrupt-parent = <&gpio4>;
interrupts = <16,0>; /* GPIO 4 + pin 16 + active high */
reset-gpios = <&gpio4 12 0>; /* GPIO 4 + Pin 12 + active high */
touchscreen-size-x = <1200>;
touchscreen-size-y = <800>;
touchscreen-inverted-x;
touchscreen-inverted-y;
};
/* ... */
};
/* #2: Pin control group */
&iomuxc {
pinctrl_gt9271_ts_gpio: gt9271_ts_gpiogrp {
fsl,pins = <
MX6UL_PAD_NAND_DQS__GPIO4_IO16 0x80000000 /* Interrupt */
MX6UL_PAD_NAND_READY_B__GPIO4_IO12 0x80000000 /* Reset */
>;
};
/* ... */
};
Explanation: bus address
The device data sheet, available here, indicates that two slave addresses are supported: 0xBA/0xBB and 0x28/0x29. The device is set to use 0xBA/0xBB adjusted for 7-bit addressing as recommended in this binding, (so the address assigned in the node is actually 0x5d).
Explanation: control pins
The I²C reset and interrupt are connected (respectively) to GPIO 4, pin 16, and GPIO 4, pin 12. These are reserved for NAND but NAND is not being used with this processor so the pins are free.
Problem
Unfortunately, the touchscreen controller configuration I have added is failing on boot with an I²C related message. I am greeted on boot with the following:
[ 2.118110] Goodix-TS 0-005d: 0-005d supply AVDD28 not found, using dummy regulator
[ 2.126059] Goodix-TS 0-005d: 0-005d supply VDDIO not found, using dummy regulator
[ 2.134510] Goodix-TS 0-005d: i2c test failed attempt 1: -6
[ 2.177733] Goodix-TS 0-005d: i2c test failed attempt 2: -6
[ 2.217377] Goodix-TS 0-005d: I2C communication failure: -6
I have attempted to search the error code (-6) but find sparse to non-existent search results online. I've checked that the connector is physically there and it seems to be.
What steps might I take to diagnose such an error code?
The solution is as follows:
The documentation states that I should include the property in the format irq-gpios. I previously thought I only needed the interrupts property. After adding irq-gpios = <&gpio4 16 0>;, the device passed the I2C test.
I disabled touchscreen-inverted-x;, and touchscreen-inverted-y; by removing those lines. I had incorrectly assumed I needed to do that originally.
Verdict:
Try to follow the documentation precisely.
I am new to Windows API and I just can't seem to figure this out:
According to the documentation the function int GetDeviceCaps(HDC hdc,int index); returns integer values which correspond to the selected item I want to know about. However, how am I supposed to convert the integers to the values?
printf("Rastercaps: %d\n", GetDeviceCaps(hdc, RASTERCAPS));
// rastercaps: 32409
item RASTERCAPS:
values
RC_BANDING Requires banding support.
RC_BITBLT Capable of transferring bitmaps.
RC_BITMAP64 Capable of supporting bitmaps larger than 64 KB.
RC_DI_BITMAP Capable of supporting the SetDIBits and GetDIBits
functions.
RC_DIBTODEV Capable of supporting the SetDIBitsToDevice
function.
RC_FLOODFILL Capable of performing flood fills.
...
Does 32409 mean the device has RASTERCAP values (capabilities) 3,2,4,0 and 9, in the order as stated in their table?
Thank you.
They're bitmasks. In the relevant C header file (wingdi.h) there is
/* Raster Capabilities */
#define RC_NONE
#define RC_BITBLT 1 /* Can do standard BLT. */
#define RC_BANDING 2 /* Device requires banding support */
#define RC_SCALING 4 /* Device requires scaling support */
#define RC_BITMAP64 8 /* Device can support >64K bitmap */
...and many more.
The return value (32409) is made up of the bitwise-or of these values. So, for example, if you wanted to know if the device could support >64K bitmap you would do
int rc = GetDeviceCaps(hdc, RASTERCAPS);
if (rc & RC_BITMAP64) { /* it does support >64k */ }
So in this case, 32409 is 0111111010011001 in binary which means it has the capabilities RC_BITBLT | RC_BITMAP64 | RC_GDI20_OUTPUT | RC_DI_BITMAP |
RC_DIBTODEV | RC_BIGFONT | RC_STRETCHBLT | RC_FLOODFILL | RC_STRETCHDIB | RC_OP_DX_OUTPUT.
See "Bitwise operations in C"
I am developing an application in Atmel Studio 6 using the xMega32a4u. I'm using the TWI libraries provided by Atmel. Everything is going well for the most part.
Here is my issue: In order to update an OLED display I am using (SSD1306 controller, 128x32), the entire contents of the display RAM must be written immediately following the I2C START command, slave address, and control byte so the display knows to enter the data into the display RAM. If the control byte does not immediately precede the display RAM package, nothing works.
I am using a Saleae logic analyzer to verify that the bus is doing what it should.
Here is the function I am using to write the display:
void OLED_buffer(){ // Used to write contents of display buffer to OLED
uint8_t data_array[513];
data_array[0] = SSD1306_DATA_BYTE;
for (int i=0;i<512;++i){
data_array[i+1] = buffer[i];
}
OLED_command(SSD1306_SETLOWCOLUMN | 0x00);
OLED_command(SSD1306_SETHIGHCOLUMN | 0x00);
OLED_command(SSD1306_SETSTARTLINE | 0x00);
twi_package_t buffer_send = {
.chip = OLED_BUS_ADDRESS,
.buffer = data_array,
.length = 513
};
twi_master_write(&TWIC, &buffer_send);
}
Clearly, this is very inefficient as each call to this function recreates the entire array "buffer" into a new array "data_array," one element at a time. The point of this is to insert the control byte (SSD1306_DATA_BYTE = 0x40) into the array so that the entire "package" is sent at once, and the control byte is in the right place. I could make the original "buffer" array one element larger and add the control byte as the first element, to skip this process but that makes the size 513 rather than 512, and might mess with some of the text/graphical functions that manipulate this array and depend on it being the correct size.
Now, I thought I could write the code like this:
void OLED_buffer(){ // Used to write contents of display buffer to OLED
uint8_t data_byte = SSD1306_DATA_BYTE;
OLED_command(SSD1306_SETLOWCOLUMN | 0x00);
OLED_command(SSD1306_SETHIGHCOLUMN | 0x00);
OLED_command(SSD1306_SETSTARTLINE | 0x00);
twi_package_t data_control_byte = {
.chip = OLED_BUS_ADDRESS,
.buffer = data_byte,
.length = 1
};
twi_master_write(&TWIC, &data_control_byte);
twi_package_t buffer_send = {
.chip = OLED_BUS_ADDRESS,
.buffer = buffer,
.length = 512
};
twi_master_write(&TWIC, &buffer_send);
}
/*
That doesn't work. The first "twi_master_write" command sends a START, address, control, STOP. Then the next such command sends a START, address, data buffer, STOP. Because the control byte is missing from the latter transaction, this does not work. All I need is to insert a 0x40 byte between the address byte and the buffer array when it is sent over the I2C bus. twi_master_write is a function that is provided in the Atmel TWI libraries. I've tried to examine the libraries to figure out its inner workings, but I can't make sense of it.
Surely, instead of figuring out how to recreate a twi_write function to work the way I need, there is an easier way to add this preceding control byte? Ideally one that is not so wasteful of clock cycles as my first code example? Realistically the display still updates very fast, more than enough for my needs, but that does not change the fact this is inefficient code.
I appreciate any advice you all may have. Thanks in advance!
How about having buffer and data_array pointing to the same uint8_t[513] array, but with buffer starting at its second element. Then you can continue to use buffer as you do today, but also use data_array directly without first having to copy all the elements from buffer.
uint8_t data_array[513];
uint8_t *buffer = &data_array[1];
Is it hard coded into gcc's source or fetched somehow programatically?
I think it is hardcoded in arch-specific folder, e.g. for sparc
http://www.google.com/codesearch#Yj7Hz1ZInUg/trunk/gcc-4.2.1/gcc/config/sparc/sparc.h
/* No data type wants to be aligned rounder than this. */
#define BIGGEST_ALIGNMENT (TARGET_ARCH64 ? 128 : 64)
/* The best alignment to use in cases where we have a choice. */
#define FASTEST_ALIGNMENT 64
...
/* Make strings word-aligned so strcpy from constants will be faster. */
#define CONSTANT_ALIGNMENT(EXP, ALIGN) \
((TREE_CODE (EXP) == STRING_CST \
&& (ALIGN) < FASTEST_ALIGNMENT) \
? FASTEST_ALIGNMENT : (ALIGN))
/* Make arrays of chars word-aligned for the same reasons. */
#define DATA_ALIGNMENT(TYPE, ALIGN) \
(TREE_CODE (TYPE) == ARRAY_TYPE \
&& TYPE_MODE (TREE_TYPE (TYPE)) == QImode \
&& (ALIGN) < FASTEST_ALIGNMENT ? FASTEST_ALIGNMENT : (ALIGN))
and sparc.c in the same folder.
Some basic alignment rules are defined in gcc/tree.c e.g. for void:
/* We are not going to have real types in C with less than byte alignment,
so we might as well not have any types that claim to have it. */
TYPE_ALIGN (void_type_node) = BITS_PER_UNIT;
TYPE_USER_ALIGN (void_type_node) = 0;
It will be compiled into gcc in the build process.
So, default aligns are compiled in, but can be changed by manipulating TREE type objects from the gcc code.
UPDATE: x86 config has better comments:
/* Minimum size in bits of the largest boundary to which any
and all fundamental data types supported by the hardware
might need to be aligned. No data type wants to be aligned
rounder than this.
Pentium+ prefers DFmode values to be aligned to 64 bit boundary
and Pentium Pro XFmode values at 128 bit boundaries. */
#define BIGGEST_ALIGNMENT 128
/* Decide whether a variable of mode MODE should be 128 bit aligned. */
#define ALIGN_MODE_128(MODE) \
((MODE) == XFmode || SSE_REG_MODE_P (MODE))
/* The published ABIs say that doubles should be aligned on word
boundaries, so lower the alignment for structure fields unless
-malign-double is set. */
/* ??? Blah -- this macro is used directly by libobjc. Since it
supports no vector modes, cut out the complexity and fall back
on BIGGEST_FIELD_ALIGNMENT. */
...
#define BIGGEST_FIELD_ALIGNMENT 32
...
/* If defined, a C expression to compute the alignment given to a
constant that is being placed in memory. EXP is the constant
and ALIGN is the alignment that the object would ordinarily have.
The value of this macro is used instead of that alignment to align
the object.
If this macro is not defined, then ALIGN is used.
The typical use of this macro is to increase alignment for string
constants to be word aligned so that `strcpy' calls that copy
constants can be done inline. */
#define CONSTANT_ALIGNMENT(EXP, ALIGN) ix86_constant_alignment ((EXP), (ALIGN))
/* If defined, a C expression to compute the alignment for a static
variable. TYPE is the data type, and ALIGN is the alignment that
the object would ordinarily have. The value of this macro is used
instead of that alignment to align the object.
If this macro is not defined, then ALIGN is used.
One use of this macro is to increase alignment of medium-size
data to make it all fit in fewer cache lines. Another is to
cause character arrays to be word-aligned so that `strcpy' calls
that copy constants to character arrays can be done inline. */
#define DATA_ALIGNMENT(TYPE, ALIGN) ix86_data_alignment ((TYPE), (ALIGN))
/* If defined, a C expression to compute the alignment for a local
variable. TYPE is the data type, and ALIGN is the alignment that
the object would ordinarily have. The value of this macro is used
instead of that alignment to align the object.
If this macro is not defined, then ALIGN is used.
One use of this macro is to increase alignment of medium-size
data to make it all fit in fewer cache lines. */
#define LOCAL_ALIGNMENT(TYPE, ALIGN) ix86_local_alignment ((TYPE), (ALIGN))
...
/* Set this nonzero if move instructions will actually fail to work
when given unaligned data. */
#define STRICT_ALIGNMENT 0
For arm, mips, sparc, and others archs (which limits unaligned access to memory) the alignment requires of any machine instruction may be recorded in arch.md file (e.g. in sparc.md)