Simply put yes you should be able to get other sensors up and running.
You've actually got register sets in there for 3 devices already:
- Omnivision OV5647 (the V1 Pi camera module)
- Sony IMX219 (the V2 Pi camera module)
- Analog Devices ADV7282-M (analogue video to CSI2 bridge chip).
There's also a related app using the same pieces but driving the Toshiba TC358743 HDMI to CSI2 bridge chip at at https://github.com/6by9/raspi_tc358743
We've also used it for a couple of other sensor tests as well.
Amusingly it's also used internally by one of the big sensor manufacturers for some of their development work
Most sensors do have PLLs on the front end to adapt to many oscillator frequencies, but 9.6MHz, 19.2MHz, 24MHz, and 27MHz are the standard ones you tend to find. It's be worth checking with Sony for their recommendation.
The Raspberry Pi Compute Module (CM) exposes all 4 CSI2 data lanes on the CAM1 interface if you need to be running at those rates. Using the CM3L+ means you've got pretty much a Pi3 but you'll need to find a USB hub and USB LAN adapter.
raspiraw is useful for quick development, however as you say it is not cross platform.
The cross platform API should be V4L2, however various manufacturers use it in slightly different (incompatible) ways. IIRC imx6 is pretty much standard. NVidea is close to standard. Qualcomm do all sorts of odd things.
For V4L2 you would implement a subdevice driver for your sensor along the lines of https://github.com/raspberrypi/linux/bl ... c/imx258.c
, and then tie it together to the bcm2835-unicam driver for the CSI2 receiver using device-tree, eg https://github.com/raspberrypi/linux/bl ... verlay.dts
Please note that V4L2 will only be delivering the raw frames. Should you want any processing then you can look at https://github.com/6by9/yavta
which takes the frames from V4L2 and passes them back into MMAL (the Pi multimedia API) for processing through the ISP. There is also ongoing work with http://libcamera.org/
to produce cross-platform complex camera pipelines.
The biggest niggle with kernel drivers is that they have to be licenced as GPLv2, and therefore you have an obligation to release the source code for it. Some sensor manufacturers can be awkward over releasing register sets, so that can present a problem. Sony generally seem to be OK over it, but speak to them early if you want to go this route.
On the Pi you do have the option of sticking with raspiraw which is licenced under a BSD 3-clause licence, therefore you can keep it closed. I don't know how feasible that would be on other platforms.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.