**** BEGIN LOGGING AT Thu Sep 23 02:59:57 2021 Sep 23 04:23:18 I think you can already use socat over a serial port, just using the `fd:` address type. Sep 23 04:23:44 socat readline fd:42 42 You'd obviously need to set the parameters beforehand. Sep 23 04:24:51 actually, < will probably open it O_RDONLY, should use <> Sep 23 04:24:54 socat readline fd:42 42<>/dev/ttyS0 Sep 23 04:26:25 Oh, nvm. socat already has specific tty support, but you're wanting to not use socat. Sep 23 06:45:18 joerg: i've also thought about that... even a fuse driver would help, but... I don't know, maybe that's the way to go Sep 23 06:46:20 Maxdamantus: yep, I need it to be provide a C api, which socat doesn't do, and I need it to be propietary (or written by my in which case I grant permissions to the company to use it without restricting them to the open source license of my choice) Sep 23 06:48:38 ..aand another binary tool is being born Sep 23 06:48:40 :) Sep 23 06:48:56 yeah... I really don't know if I want to do any of this lol Sep 23 06:49:41 If it's just meant to be called from C, presumably what you mainly want is simply something like: int socat(int a_in, int a_out, int b_in, int b_out); Sep 23 06:50:11 Which should just be a few lines of `poll`, `read` and `write`. Sep 23 06:50:26 or if you want to be fancy, `read` and `write` can be replaced with `sendfile` on Linux. Sep 23 06:50:49 anything else is just setting up those fds. Sep 23 06:51:04 he needs it to access different devices, not only serial Sep 23 06:51:10 well, I thought about socat not because it writes from fileno A to fileno B, but because it understands how to open lots of different destinations: a TCP socket is not opened like a file which is not opened like a serial port -which needs baud speed-, etc Sep 23 06:51:21 Right, and since it's a library, it's generally pretty easy to set up those devices. Sep 23 06:51:58 i would split the interfaces and commands parts and make them communicate, even internally Sep 23 06:52:11 int tty = open("/dev/ttyS0", O_RDWR); socat(tty, tty, 0, 1); Sep 23 06:52:47 Maxdamantus: it's not as easy as that, see above about the rs232-spi converter Sep 23 06:53:12 I need an interface that can translate something like write_register(fd, 0x10, 0x44) Sep 23 06:53:41 all in all, not hard to write Sep 23 06:53:42 that would be an ioctl call to /dev/spidevice, but it will be a binary protocol sent to the ttyS0 device Sep 23 06:53:50 well, it's not that it is hard Sep 23 06:53:56 it is that I don't want to do it :D Sep 23 06:53:56 just needs to be thought well before writing anything Sep 23 06:54:26 make it opensource so you can reuse it for future projects Sep 23 06:54:38 that way at least you will have something useful from it Sep 23 06:55:44 yeah, thankfully I can opensource a lots of things I do for the company, they just need an exclusive license for them too Sep 23 06:59:43 Why are you actually avoiding socat anyway? Are you specifically trying to make this solution as a single binary thing instead of just telling people to run `socat readline exec:'./spiserial /dev/spidevX'`? Sep 23 07:00:43 "telling people" Sep 23 07:00:50 there's no people in any of this Sep 23 07:01:21 what would socat accomplish for me, if socat doesn't speak linux's spidev protocol? Sep 23 07:01:37 It solves the socat part of the issue. Sep 23 07:01:46 spidev cannot be write() too Sep 23 07:01:48 The spi to RS232 part is a separate issue. Sep 23 07:02:07 It can if you write that `spiserial` program that talks to your RSR232 device over SPI. Sep 23 07:02:45 same final device two interfaces: /dev/spidev, /dev/ttyS0 with an RS232 converter in the middle Sep 23 07:03:06 both of them require custom code that I cannot introduce inside socat because then I would have to release that as GPL and I can't do that Sep 23 07:03:26 So do it outside of socat and call it using `exec`. Sep 23 07:03:51 why would I call socat if I've already done the hard thing outside? Sep 23 07:04:23 You're talking about reinventing socat. Sep 23 07:04:47 either you didn't undertand or I didn't explained myself Sep 23 07:04:52 >> [07:51:10] well, I thought about socat not because it writes from fileno A to fileno B, but because it understands how to open lots of different destinations: a TCP socket is not opened like a file which is not opened like a serial port -which needs baud speed-, etc Sep 23 07:05:27 I'm talking about a thint that understand how to talk to my final destination chip, even if there are several ways to access it: spidev, rs232-spi Sep 23 07:05:33 s/thint/thing/ Sep 23 07:05:55 so the "socat" part is about "socat" knowing how to open different devices and how to configure them Sep 23 07:06:18 and also socat doesn't have a concept of "spi registers" Sep 23 07:06:49 Right .. so are you intending to reimplement all of those TCP, TLS, SOCKS, etc destinations that socat has? Sep 23 07:07:11 >> [15:57:07] but it'll probably be a very simple thing with just a couple of controllers: generic open, serial port, tcp client and the propietary code we use for the rs232-spi converter Sep 23 07:07:20 so no, of course not Sep 23 07:08:11 Dunno. Just seems a bit weird. In general I'd expect someone creating software for a specific device to just create something that behaves like netcat. Sep 23 07:08:29 ie, talk to the device, expose the interface over stdio. Sep 23 07:09:00 and then you can obviously use something like socat to expose that device over all the protocols that it supports. Sep 23 07:09:17 socat stdio exec:'nc google.com 80' Sep 23 07:10:45 so you'd like socat stdio exec:'spidev-talker /dev/spidev0' for the spidev and stdio exec:'rs232-spi-talker /dev/ttyS0' Sep 23 07:11:05 Yes. Sep 23 07:11:35 Otherwise it's just going to seem like a half-useful version of socat. Sep 23 07:11:53 which also supports some obscure device. Sep 23 07:12:21 well, that is totally and absolutly the point: to support some obscure device Sep 23 07:12:35 and so, if I have to write spidev-talker that know show to interact with /dev/spidev0 Sep 23 07:12:40 Right, so you can do that without reimplementing the socat functionality. Sep 23 07:12:46 and I also have to write rs232-spi-talker that knows how to interact with /dev/ttyS0 Sep 23 07:12:56 why do I want socat for? Sep 23 07:13:20 but I already said I don't want to, and I won't reimplement socat functionality! Sep 23 07:13:24 Your original example used readline. Sep 23 07:13:37 so `socat readline exec:'spidev-talker /dev/spidev0'` Sep 23 07:14:06 and then you get a readline interface over your device, instead of having to ^U when you make a typo. Sep 23 07:14:43 I... didn't used readline for any example, did I'? Sep 23 07:15:21 01:55:17 < ceene> but I'm gonna try to use the same addressing as socat, so this socat's example should work in the end $ socat readline /dev/ttyS0,raw,echo=0,crlf Sep 23 07:15:33 I did, I see Sep 23 07:16:26 maybe that wasn't a good example, I don't really need readline nor any interactivity at all, the part I was referring to was the second destination: /dev/ttyS0,raw,echo=0,crlf Sep 23 07:16:30 The `stdio` target in socat is not actually very useful when used in combination with `exec`. Sep 23 07:16:48 since `socat stdio exec:./foo` is just the same as `./foo` Sep 23 07:17:10 it's only there so you can access all the other socat targets over stdio. Sep 23 07:20:26 So if you're just trying to access your device using stdio, you'll just run your program directly, no need for socat. Sep 23 07:20:40 $ spidev-talker /dev/spidev0 Sep 23 07:20:44 that's the poing I was trying to make! Sep 23 07:21:03 and now, replace spidev-talker and rs232-spi-talker with a single "my-obscure-device-talker" Sep 23 07:23:03 which, if we keep insisting on a stdio interface, should be able to do echo -e "r00 0x23\n r01 0x33\n r02 0x11" | my-obscure-device-talker [SPIDEV:/dev/spidev0 | tty:/dev/ttyS0,raw,b9600] Sep 23 07:23:26 SGTM Sep 23 07:23:58 and there you have the "socat-like functionality" that definitely is not socat but has lots of resemblance to it and could be expanded later to TCP4:192.168.1.2:5400 Sep 23 07:25:01 Looks more like netcat functionality, since it's just a single target talking over stdio. Sep 23 07:25:31 but netcat doesn't know how to configure ttyS0 devices, nor how to speak to spidev, nor anything at all really... Sep 23 07:26:02 and now forget about stdio completely and think in terms of write_reg8 write_reg16 write_reg32 write_reg64 Sep 23 07:26:22 as many different spi devices cannot be written to arbitrary word lengths Sep 23 07:26:55 so, this interface https://github.com/agamez/libARTio/blob/main/io.h Sep 23 07:28:22 of which, this is the simplest implementation, which just calls open() and only supports generic read/write https://github.com/agamez/libARTio/blob/main/io_open.c Sep 23 07:28:51 so now I need an io_spidev.c driver that implements those {read,write}_register functions Sep 23 07:29:14 and after that, I would need an rs232-spi.c driver that would talk to the converter Sep 23 07:29:19 and that's it Sep 23 07:51:03 Hm, so if it's really about connecting two targets together that talk in terms of `write32(int r, u32 v), write16(int r, u16 v), write8(int r, u8 v), read32(int r), ...` commands, I guess that's not covered by socat. Sep 23 07:51:30 correct Sep 23 07:51:53 spi devices can't just be written whatever Sep 23 07:51:57 (unless you serialise the commands into the form above, in which case both targets can again be connected by sharding stdio) Sep 23 07:52:12 Sure. Sep 23 07:52:37 they almost always need a precise number of bytes, that may not be equal for all the registers it exposes, and Chip Select pin must be pulled up/down in the precise moment Sep 23 07:54:04 so a spi device will may need write8(0, 0x23), write8(1, 0x66), write16(2, 0x1133), and all of that can't be replaced by write32(0, 0x23661133) Sep 23 08:14:55 and this would be the initial driver for /dev/spidev: https://github.com/agamez/libARTio/blob/main/io_spidev.c **** ENDING LOGGING AT Fri Sep 24 02:59:56 2021