| joerg | aiui not only the interfaces differ but also the payload data aka protocol? Then it doesn't make much sense integrating it all into one blob, no? | 01:35 |
|---|---|---|
| joerg | I'd probably implement a device driver for the rs232-spi converter that exposes a /dev/SPIrs232 device interface, Sort of similar to /dev/ttyUSB which hides the USB part of a USB<->rs232 dongle | 01:39 |
| Maxdamantus | I think you can already use socat over a serial port, just using the `fd:` address type. | 05:23 |
| Maxdamantus | socat readline fd:42 42</dev/ttyS0 | 05:23 |
| Maxdamantus | You'd obviously need to set the parameters beforehand. | 05:23 |
| Maxdamantus | actually, < will probably open it O_RDONLY, should use <> | 05:24 |
| Maxdamantus | socat readline fd:42 42<>/dev/ttyS0 | 05:24 |
| Maxdamantus | Oh, nvm. socat already has specific tty support, but you're wanting to not use socat. | 05:26 |
| ceene | 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 | 07:45 |
| ceene | 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) | 07:46 |
| KotCzarny | ..aand another binary tool is being born | 07:48 |
| KotCzarny | :) | 07:48 |
| ceene | yeah... I really don't know if I want to do any of this lol | 07:48 |
| Maxdamantus | 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); | 07:49 |
| Maxdamantus | Which should just be a few lines of `poll`, `read` and `write`. | 07:50 |
| Maxdamantus | or if you want to be fancy, `read` and `write` can be replaced with `sendfile` on Linux. | 07:50 |
| Maxdamantus | anything else is just setting up those fds. | 07:50 |
| KotCzarny | he needs it to access different devices, not only serial | 07:51 |
| ceene | 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 | 07:51 |
| Maxdamantus | Right, and since it's a library, it's generally pretty easy to set up those devices. | 07:51 |
| KotCzarny | i would split the interfaces and commands parts and make them communicate, even internally | 07:51 |
| Maxdamantus | int tty = open("/dev/ttyS0", O_RDWR); socat(tty, tty, 0, 1); | 07:52 |
| ceene | Maxdamantus: it's not as easy as that, see above about the rs232-spi converter | 07:52 |
| ceene | I need an interface that can translate something like write_register(fd, 0x10, 0x44) | 07:53 |
| KotCzarny | all in all, not hard to write | 07:53 |
| ceene | that would be an ioctl call to /dev/spidevice, but it will be a binary protocol sent to the ttyS0 device | 07:53 |
| ceene | well, it's not that it is hard | 07:53 |
| ceene | it is that I don't want to do it :D | 07:53 |
| KotCzarny | just needs to be thought well before writing anything | 07:53 |
| KotCzarny | make it opensource so you can reuse it for future projects | 07:54 |
| KotCzarny | that way at least you will have something useful from it | 07:54 |
| ceene | yeah, thankfully I can opensource a lots of things I do for the company, they just need an exclusive license for them too | 07:55 |
| Maxdamantus | 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'`? | 07:59 |
| ceene | "telling people" | 08:00 |
| ceene | there's no people in any of this | 08:00 |
| ceene | what would socat accomplish for me, if socat doesn't speak linux's spidev protocol? | 08:01 |
| Maxdamantus | It solves the socat part of the issue. | 08:01 |
| ceene | spidev cannot be write() too | 08:01 |
| Maxdamantus | The spi to RS232 part is a separate issue. | 08:01 |
| Maxdamantus | It can if you write that `spiserial` program that talks to your RSR232 device over SPI. | 08:02 |
| ceene | same final device two interfaces: /dev/spidev, /dev/ttyS0 with an RS232 converter in the middle | 08:02 |
| ceene | 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 | 08:03 |
| Maxdamantus | So do it outside of socat and call it using `exec`. | 08:03 |
| ceene | why would I call socat if I've already done the hard thing outside? | 08:03 |
| Maxdamantus | You're talking about reinventing socat. | 08:04 |
| ceene | either you didn't undertand or I didn't explained myself | 08:04 |
| ceene | >> [07:51:10] <ceene> 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 | 08:04 |
| ceene | 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 | 08:05 |
| ceene | s/thint/thing/ | 08:05 |
| ceene | so the "socat" part is about "socat" knowing how to open different devices and how to configure them | 08:05 |
| ceene | and also socat doesn't have a concept of "spi registers" | 08:06 |
| Maxdamantus | Right .. so are you intending to reimplement all of those TCP, TLS, SOCKS, etc destinations that socat has? | 08:06 |
| ceene | >> [15:57:07] <ceene> 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 | 08:07 |
| ceene | so no, of course not | 08:07 |
| Maxdamantus | 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. | 08:08 |
| Maxdamantus | ie, talk to the device, expose the interface over stdio. | 08:08 |
| Maxdamantus | and then you can obviously use something like socat to expose that device over all the protocols that it supports. | 08:09 |
| Maxdamantus | socat stdio exec:'nc google.com 80' | 08:09 |
| ceene | so you'd like socat stdio exec:'spidev-talker /dev/spidev0' for the spidev and stdio exec:'rs232-spi-talker /dev/ttyS0' | 08:10 |
| Maxdamantus | Yes. | 08:11 |
| Maxdamantus | Otherwise it's just going to seem like a half-useful version of socat. | 08:11 |
| Maxdamantus | which also supports some obscure device. | 08:11 |
| ceene | well, that is totally and absolutly the point: to support some obscure device | 08:12 |
| ceene | and so, if I have to write spidev-talker that know show to interact with /dev/spidev0 | 08:12 |
| Maxdamantus | Right, so you can do that without reimplementing the socat functionality. | 08:12 |
| ceene | and I also have to write rs232-spi-talker that knows how to interact with /dev/ttyS0 | 08:12 |
| ceene | why do I want socat for? | 08:12 |
| ceene | but I already said I don't want to, and I won't reimplement socat functionality! | 08:13 |
| Maxdamantus | Your original example used readline. | 08:13 |
| Maxdamantus | so `socat readline exec:'spidev-talker /dev/spidev0'` | 08:13 |
| Maxdamantus | and then you get a readline interface over your device, instead of having to ^U when you make a typo. | 08:14 |
| ceene | I... didn't used readline for any example, did I'? | 08:14 |
| Maxdamantus | 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 | 08:15 |
| ceene | I did, I see | 08:15 |
| ceene | 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 | 08:16 |
| Maxdamantus | The `stdio` target in socat is not actually very useful when used in combination with `exec`. | 08:16 |
| Maxdamantus | since `socat stdio exec:./foo` is just the same as `./foo` | 08:16 |
| Maxdamantus | it's only there so you can access all the other socat targets over stdio. | 08:17 |
| Maxdamantus | So if you're just trying to access your device using stdio, you'll just run your program directly, no need for socat. | 08:20 |
| Maxdamantus | $ spidev-talker /dev/spidev0 | 08:20 |
| ceene | that's the poing I was trying to make! | 08:20 |
| ceene | and now, replace spidev-talker and rs232-spi-talker with a single "my-obscure-device-talker" | 08:21 |
| ceene | 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] | 08:23 |
| Maxdamantus | SGTM | 08:23 |
| ceene | 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 | 08:23 |
| Maxdamantus | Looks more like netcat functionality, since it's just a single target talking over stdio. | 08:25 |
| ceene | but netcat doesn't know how to configure ttyS0 devices, nor how to speak to spidev, nor anything at all really... | 08:25 |
| ceene | and now forget about stdio completely and think in terms of write_reg8 write_reg16 write_reg32 write_reg64 | 08:26 |
| ceene | as many different spi devices cannot be written to arbitrary word lengths | 08:26 |
| ceene | so, this interface https://github.com/agamez/libARTio/blob/main/io.h | 08:26 |
| ceene | 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 | 08:28 |
| ceene | so now I need an io_spidev.c driver that implements those {read,write}_register functions | 08:28 |
| ceene | and after that, I would need an rs232-spi.c driver that would talk to the converter | 08:29 |
| ceene | and that's it | 08:29 |
| Maxdamantus | 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. | 08:51 |
| ceene | correct | 08:51 |
| ceene | spi devices can't just be written whatever | 08:51 |
| Maxdamantus | (unless you serialise the commands into the form above, in which case both targets can again be connected by sharding stdio) | 08:51 |
| Maxdamantus | Sure. | 08:52 |
| ceene | 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 | 08:52 |
| ceene | 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) | 08:54 |
| ceene | and this would be the initial driver for /dev/spidev: https://github.com/agamez/libARTio/blob/main/io_spidev.c | 09:14 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!