Convert []u8 to [*]u64

Hello, in one C lib I must give to struct [*]u64 buffers for read and write. I have *[]u8 buffers. So, can I do transform it somehow?
C example code:

uint8_t tx[] = {
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0x40, 0x00, 0x00, 0x00, 0x00, 0x95,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xDE, 0xAD, 0xBE, 0xEF, 0xBA, 0xAD,
	0xF0, 0x0D,
};
uint8_t rx[ARRAY_SIZE(tx)] = {0, };
struct spi_ioc_transfer tr = {
	.tx_buf = (unsigned long)tx,
	.rx_buf = (unsigned long)rx,
	.len = ARRAY_SIZE(tx),
	.delay_usecs = delay,
	.speed_hz = speed,
	.bits_per_word = bits,
};

My function in Zig:

const c_ioctl = @cImport({
    @cInclude("sys/ioctl.h");
});

pub fn writeAndRead(self: *Spi, write_buf: *[]u8, read_buf: *[]u8,) !?[]const u8 {
    const len = write_buf.*.len;

    var tr = spidev.struct_spi_ioc_transfer {
        .tx_buf =  write_buf,
        .rx_buf =  read_buf,
        .len = len,
        .delay_usecs = 0,
        .speed_hz = self.speed,
        .bits_per_word = self.bits,
    };

    if (c_ioctl.ioctl(self.fd, spidev.SPI_IOC_MESSAGE(1), &tr) == -1) {
        if (get_ioctl_err()) |err| {
            std.log.err("Ioctl Error: {s}\n", .{err});
        }
        return error.SpiTransferFailed;
    }

    return read_buf.*;
}

So may be you can give me an advice and some examples, it’ll be great :heart:

Also I’ve used

const c_ioctl = @cImport({
    @cInclude("sys/ioctl.h");
});

cause in std.c, ioctl uses only 32 bits for request, instead of 64. I dk if I’m doing wrong here. Didn’t found other solution :confused:

What is the declaration of tx_buf and rx_buf in both C struct spi_ioc_transfer and Zig spidev.struct_spi_ioc_transfer ?

It’s #include <linux/spi/spidev.h>

In Zig I reuse it
const spidev = @cImport({
    @cInclude("linux/spi/spidev.h");
});

var tr = spidev.struct_spi_ioc_transfer {
      .tx_buf =  write_buf,
      .rx_buf =  read_buf,
      .len = len,
      .delay_usecs = 0,
      .speed_hz = self.speed,
      .bits_per_word = self.bits,
};
Its code:
#ifndef SPIDEV_H
#define SPIDEV_H

#include <linux/types.h>
#include <linux/ioctl.h>
#include <linux/spi/spi.h>

/* IOCTL commands */

#define SPI_IOC_MAGIC                   'k'

/**
 * struct spi_ioc_transfer - describes a single SPI transfer
 * @tx_buf: Holds pointer to userspace buffer with transmit data, or null.
 *      If no data is provided, zeroes are shifted out.
 * @rx_buf: Holds pointer to userspace buffer for receive data, or null.
 * @len: Length of tx and rx buffers, in bytes.
 * @speed_hz: Temporary override of the device's bitrate.
 * @bits_per_word: Temporary override of the device's wordsize.
 * @delay_usecs: If nonzero, how long to delay after the last bit transfer
 *      before optionally deselecting the device before the next transfer.
 * @cs_change: True to deselect device before starting the next transfer.
 * @word_delay_usecs: If nonzero, how long to wait between words within one
 *      transfer. This property needs explicit support in the SPI controller,
 *      otherwise it is silently ignored.
 *
 * This structure is mapped directly to the kernel spi_transfer structure;
 * the fields have the same meanings, except of course that the pointers
 * are in a different address space (and may be of different sizes in some
 * cases, such as 32-bit i386 userspace over a 64-bit x86_64 kernel).
 * Zero-initialize the structure, including currently unused fields, to
 * accommodate potential future updates.
 *
 * SPI_IOC_MESSAGE gives userspace the equivalent of kernel spi_sync().
 * Pass it an array of related transfers, they'll execute together.
 * Each transfer may be half duplex (either direction) or full duplex.
 *
 *      struct spi_ioc_transfer mesg[4];
 *      ...
 *      status = ioctl(fd, SPI_IOC_MESSAGE(4), mesg);
 *
 * So for example one transfer might send a nine bit command (right aligned
 * in a 16-bit word), the next could read a block of 8-bit data before
 * terminating that command by temporarily deselecting the chip; the next
 * could send a different nine bit command (re-selecting the chip), and the
 * last transfer might write some register values.
 */
struct spi_ioc_transfer {
        __u64           tx_buf;
        __u64           rx_buf;

        __u32           len;
        __u32           speed_hz;

        __u16           delay_usecs;
        __u8            bits_per_word;
        __u8            cs_change;
        __u8            tx_nbits;
        __u8            rx_nbits;
        __u8            word_delay_usecs;
        __u8            pad;

        /* If the contents of 'struct spi_ioc_transfer' ever change
         * incompatibly, then the ioctl number (currently 0) must change;
         * ioctls with constant size fields get a bit more in the way of
         * error checking than ones (like this) where that field varies.
         *
         * NOTE: struct layout is the same in 64bit and 32bit userspace.
         */
};

/* not all platforms use <asm-generic/ioctl.h> or _IOC_TYPECHECK() ... */
#define SPI_MSGSIZE(N) \
        ((((N)*(sizeof (struct spi_ioc_transfer))) < (1 << _IOC_SIZEBITS)) \
                ? ((N)*(sizeof (struct spi_ioc_transfer))) : 0)
#define SPI_IOC_MESSAGE(N) _IOW(SPI_IOC_MAGIC, 0, char[SPI_MSGSIZE(N)])


/* Read / Write of SPI mode (SPI_MODE_0..SPI_MODE_3) (limited to 8 bits) */
#define SPI_IOC_RD_MODE                 _IOR(SPI_IOC_MAGIC, 1, __u8)
#define SPI_IOC_WR_MODE                 _IOW(SPI_IOC_MAGIC, 1, __u8)

/* Read / Write SPI bit justification */
#define SPI_IOC_RD_LSB_FIRST            _IOR(SPI_IOC_MAGIC, 2, __u8)
#define SPI_IOC_WR_LSB_FIRST            _IOW(SPI_IOC_MAGIC, 2, __u8)

/* Read / Write SPI device word length (1..N) */
#define SPI_IOC_RD_BITS_PER_WORD        _IOR(SPI_IOC_MAGIC, 3, __u8)
#define SPI_IOC_WR_BITS_PER_WORD        _IOW(SPI_IOC_MAGIC, 3, __u8)

/* Read / Write SPI device default max speed hz */
#define SPI_IOC_RD_MAX_SPEED_HZ         _IOR(SPI_IOC_MAGIC, 4, __u32)
#define SPI_IOC_WR_MAX_SPEED_HZ         _IOW(SPI_IOC_MAGIC, 4, __u32)

/* Read / Write of the SPI mode field */
#define SPI_IOC_RD_MODE32               _IOR(SPI_IOC_MAGIC, 5, __u32)
#define SPI_IOC_WR_MODE32               _IOW(SPI_IOC_MAGIC, 5, __u32)



#endif /* SPIDEV_H */

You need to cast using @intFromPtr from pointer to u64: .tx_buf = @intFromPtr(tx.*.ptr);


You can also simplify your function:

pub fn writeAndRead(self: Spi, write_buf: []u8, read_buf: []const u8,) !?[]const u8 {
    const len = write_buf.len;

    var tr = spidev.struct_spi_ioc_transfer {
        .tx_buf = @intFromPtr(write_buf.ptr),
        .rx_buf = @intFromPtr(read_buf.ptr),
        .len = len,
        .delay_usecs = 0,
        .speed_hz = self.speed,
        .bits_per_word = self.bits,
    };

EDIT: changed @bitCast to the correct @intFromPtr

1 Like

error:

error: cannot @bitCast from '[*]u8'
        .tx_buf =  @bitCast(write_buf.ptr),
                            ~~~~~~~~~^~~~

function:

pub fn writeAndRead(self: *Spi, write_buf: []u8, read_buf: []u8,) !?[]const u8 {
    const len = write_buf.len;

    var tr = spidev.struct_spi_ioc_transfer {
        .tx_buf =  @bitCast(write_buf.ptr),
        .rx_buf =  @bitCast(read_buf.ptr),
        .len = len,
        .delay_usecs = 0,
        .speed_hz = self.speed,
        .bits_per_word = self.bits,
    };

I am sorry.
The correct casting is: @intFromPtr

1 Like

Thank you!
Can you give an advice about that?

std.c.ioctl is declared with variadic arguments pub extern "c" fn ioctl(fd: c.fd_t, request: c_int, ...) c_int
std.os.linux.ioctl is cleaner: pub fn ioctl(fd: fd_t, request: u32, arg: usize) usize

Prefer the linux version, if you expect the software to be linux only.
Otherwise ensure that the third parameter is usize. For example: @as(usize, @intFromPtr(&tr))

1 Like

Why are you storing pointers as u64’s? In general, you should use a pointer type for pointers, yeah? Also @ptrCast and @alignCast are your friend, but be careful with the latter! I recommend that you make the [*]u8 into align(8) [*]u8, then you hopefully don’t need an alignCast.

1 Like

u64 is the struct member in the linux driver SPI bus api.
The question should be directed to the linux kernel developers.

2 Likes