I was just commenting on the Python code which drives the communication with simple bitbang logic. The actual serial protocol seems like half duplex SPI (without a select pin), but after reading 24 bits data, extra clock pulses are required to indicate gain and channel for the next conversion. Since the SPI peripheral on RPi can be configured for bit length, it seems doable using SPI.
I think you're right, and (having checked again) there's plenty on Google juxtaposing that chip/module and SPI. But I think it's only fair to highlight any areas in which I might possibly be giving out bad advice to a less-experienced user... if for no other reason than that there are plenty of users more experienced than I, who might feel the need to slap me down ungraciously if I do not :-)
If I've used Linux SPI at all, it was strictly from a Raspberry Pi to a piggybacked Arduino-like board rather than to a specific sensor, but I managed to lose a few chunks of sourcecode due to a damaged SDCard so I'm not sure I still have a copy.
I have, however looked quite a lot at GPIO, and would make some observations.
First, avoid anything that uses any kind of memory-mapped I/O for GPIO, since it will be hopelessly platform-specific... and might in practice be tied to a particular RPi model.
Second, the portable /sys interface has limited performance and can be extremely difficult to use since there is no provision for locking a device once it's in use so a different shell session can add/remove GPIO bit etc.
Third, the newer portable /dev interface solves some of these problems but is badly broken in some areas: see
https://forum.lazarus.freepascal.org/index.php/topic,56063.msg417205.html#msg417205 and overall thread.
And most importantly, before getting too embroiled with any particular middleware or library find out which of the above it's using.
MarkMLl