ISL79987 Support

[danriches]

Hi, nice work by the way and I'd love to use what you have here. I'm trying to use the ISL79987 and have the full datasheet from Renesas. So far I've configured the chip and I can see data on the MIPI port which isn't there before configuration, so I'm fairly certain it's configured ok. How would I proceed to use your code to pull a still image over the MIPI bus? I'm fairly new to Linux interfacing and am a very accomplished electronics hardware engineer with lots of Windows C# and some Linux C in my belt so all I really need are some pointers. Or I can send you the datasheet if you want, I didn't need to sign an NDA so I won't be breaching any t's & c's.

In fact any pointers on how to go further, even if I use my own code to setup the encoder, would be great. Should I be looking at using MMAL to get the data back?

Many Thanks, Dan

[6by9]

If the datasheet isn't under NDA (I see the request link on https://www.intersil.com/en/products/end-market-specific/automotive-ics/video-decoders/ISL79987.html - just requested it myself) then I'd recommend that you investigate making a V4L2 kernel driver for it rather than using raspiraw. It fits better with Linux standard APIs. raspiraw was really there for prototyping and where there is an issue on NDAs (not that it hides stuff that well as people can easily sniff the I2C).

Kernel device drivers have just been merged for the CSI2 peripheral with https://github.com/raspberrypi/linux/pull/2513 and https://github.com/raspberrypi/linux/pull/2607 to support things nicely.

The ADV7282-M (shares https://github.com/raspberrypi/linux/blob/rpi-4.14.y/drivers/media/i2c/adv7180.c as the driver) is a very similar device to yours so is probably a good reference. The one thing I see no reference to is how the device handles interlacing. The ADV7282M has a deinterlacing block built in (I2P they call it), so the Pi doesn't have to worry. Other devices don't always make the field signalling obvious, and that then becomes a problem.

[6by9]

I should say that there is a bit missing in V4L2 land with regard defining and switching between inputs on subdevices. There seems to be some movement for tvp5150 implementing it, which may wake things up a bit - https://www.spinics.net/lists/linux-media/msg136869.html

If that doesn't work then I may ignore upstream and just support mapping the S_INPUT V4L2 ioctl to the underlying s_routing call. It worked for adv7282m, but upstream complained that it was incorrect as S_INPUT is meant to define input connectors, not potential input modes.

[danriches]

Thanks for the info much appreciated. I think you're right about going down the driver route for V4L2. Just one last question for you, say I have a board with an ADV7282M on it connected up do I just modprobe for the hardware and then use V4L2 to capture stills and video as I would have done with the RasPi camera? Or is there another particular way I should be doing this?

Kind Regards, Dan

[6by9]

As this is all Linux code running on the ARM, you need device tree to configure it. That should also load the required modules to support the hardware.

The kernel has a device tree overlay for the ADV7282M already - https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/overlays/adv7282m-overlay.dts To load it you should only need to add dtoverlay=adv7282m to /boot/config.txt and it'll merge the requried config to device tree. There are a few differences between versions of the Pi over which GPIOs are used to interface with the camera connector, so Pi 0/0W/B+/2B will require dtoverlay=adv7282m, i2c_pins_28_29=1.

The interface to V4L2 is as per the kernel docs - https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/v4l2.html. The ADV7282M produces UYVY (YUV422) images. Few of the VideoCore blocks handle that, but the ISP does, and as of last week the MMAL video_encode component integrates it too. If you want to display the images via the Pi then you'll have to run them through the ISP. For an example app that pulls V4L2 and MMAL together as efficiently as we can, then look at https://github.com/6by9/yavta. There's a little bit of messing around to set up the buffers appropriately, but once that is done it is relatively simple.

[6by9]

FYI I requested the datasheet from Renesas and am now in correspondence with one of their reps.

[danriches]

Excellent, I've got an ADV7280-M part on a PCB almost ready to test it out with a video source so I can be sure certain aspects work before trying to write the device driver. That'll be the next stage after the testing. I'll then stick to the device that gives out the best quality signal. As it happens I've got a chap from Anglia coming to visit me next week for application support on the Renesas part. I'll keep you posted on how it goes plus any other information you might find useful :)

Dan

[6by9]

Is it Alvin by any chance? That's who has contacted me.

[danriches]

Yes it is, I'm booked for Tuesday 17th. Hopefully I'll make some progress with the AFE on the part and I've got questions regarding interlacing and any Linux driver source code he may have access to. He's queried Renesas about this so I'm just waiting for a response...

[6by9]

Snap. You're obviously not far from Cambridge then. He's dropping in to Pi Towers at 1:30pm. I've asked the same question of him over source code, interlacing, and exactly how it is encapsulating the data over the CSI2 bus.

[danriches]

How funny, I'm not that far really, I work in Bishops Stortford well Takeley just off the M11. I'm sure between us we can get this working (that's if the chip supports the right modes of course). If I had another spare PCB I'd send it over but unfortunately I only have two total and one isn't working right, they are just breakout boards really with the minimum support parts on such as regulator, crystal, decoupling and input impedance matching network. Pending the outcome from Alvin and if I can get the other board working I'll see if I can send it over....

[danriches]

I nearly forgot that Renesas also do the TW9992 which is a dual channel NTSC/PAL to MIPI-CSI2 decoder. I also have the datasheet for that chip but elected the ISL79987 as the TW9992 is only single MIPI lane output. However as the ADV7280-M works the TW9992 may also work...

[6by9]

So the main difference between the ISL7998x and ADV728x is that the ISL will capture multiple inputs simultaneously, whilst the ADV will only capture one at a time. It depends on your use case as to whether that is a limitation to you.

The first mechanism that the ISL uses for multiplexing the multiple inputs using multiple CSI2 virtual channels isn't going to be practical on the Pi, and certainly not via the V4L2 driver (rawcam might be vaguely possible). The Pi only supports programming one data type value for "image" data, with everything else being classified as "data" because it is typically used for the embedded data from camera sensors. That might allow two inputs at a time, but that's the maximum. V4L2 doesn't really have a mechanism for setting up virtual channels either. The second mechanism of line interleaving all the frames has the potential to work, but I haven't read enough of the spec to work out if that puts other constraints on synchronisation of the inputs.

I have an ADV7282M eval board and hookup to the Pi if you have issues with the ADV7280 and want to evaluate the ADV performance without debugging the board (http://www.analog.com/en/products/audio-video/mipi-video-devices/adv7282.html#product-evaluationkit)

[danriches]

I'm really only after the cleanest signal capture I can get and after trying a certain Pi Hat from the US I came to the conclusion that the way they were processing the signal allowed too much interference in. The signal was not good enough for the device this is intended to built in which is medical image capture. Compared against using a PC with a Conexant USB device the signal was drastically different and this is why I'm trying to find a best fit candidate by either using the ADV728x or the ISL7998x devices. I know the Pi Hat in question used the ADV728x as a front end but captures as parallel data (non -M part) and further processes the data in an fpga and then through a MIPI bridge. I'm sure it can be done with lots less components and with careful attention to grounding etc a nice clean capture can be done. I only want stills at first but video later on would be nice if possible.

I've also raised a request through a contact at Renesas to see if they can send me the Linux drivers for both ISL and TW parts so I have a known working starting point to alleviate any mistakes I may introduce through daftness mainly ;) We'll see what happens though...

[6by9]

Sounds like the PiCapture SD1. Yes it's quirky in that it's converting the YUV data from the ADV7xxx back to Bayer in order to emulate a Pi camera, but that will have an inherent loss in quality.

The results I've had from the ADV7282 look pretty good. I was using an old Panasonic DMR-EX85 Freeview HDD/DVD recorder as a source, playing back a Freeview recording (IIRC it reencodes rather than recording the raw bitstream, so there is a slight loss there). The ADV can take a moment to sort out the AGC correctly, but after that it looks pretty clean. I'm back in the office tomorrow so could share a recording from it if that would help.

I'm not sure if Renesas have Linux drivers already for it - they seem to be fairly good at upstreaming stuff as soon as it is written. I would be surprised if they didn't have some form of test app, or default register set that they can say "send this and you should get CSI2 data". That'd be a good starting point, and fits with raspiraw easily.

[danriches]

Hi, I've just populated my ADV7280A-M pcb and connected it up, added the dtoverlay=adv7282m to config.txt and booted up the Pi 3B+. Do I need the "i2c_pins_28_29=1" added for the 3B+ and am I right in connecting the I2C bus of the ADV7280 to the CSI I2C pins or should I have used the GPIO port?

I've also checked in /dev and there's nothing new that I can see in there, dmesg shows nothing and neither does lsmod, is there a way I can check the driver loaded correctly?

Sorry for the barrage of questions, your help has been brilliant and is ever so much appreciated.

Kind Regards, Dan

[6by9]

44&45 (the default for the overlay) is correct on a 3B+.

Use sudo i2cdetect -y 0 to confirm that the device is found. The adv7282 overlay uses address 0x21 by default. If it is found on a different address then you'll need to amend the overlay. IIRC There is an address pin on the chip that switches it between 0x20 and 0x21.

lsmod to confirm that which modules are loaded. I'd expect to see bcm2835_unicam and adv7180 listed.

The device tree setup is exported via /proc/device-tree/. I'd expect to find a node for the adv7282 under /proc/device-tree/soc/i2c@7e205000/, and also the unicam driver as /proc/device-tree/soc/csi1@7e801000

[danriches]

Well after looking around and then having a slap forehead moment in stupidity I realised I hadn't got the latest kernel with drivers installed so after compiling that and installing it I can now see the unicam and adv7180 driver loaded, hurrah! Time to carry on and see how far I get...

Incidentally I got a response back from Renesas and their reply was:

"There are evaluation boards for these devices and the software and other documentation comes with the boards. The product line prefers customers buy the boards as support for these products can be quite time consuming when starting a project from scratch.

I will attach some documents that describe the boards. You will need to contact a sales office for pricing and delivery and for any further technical support with these products. "

So, I look for the Eval board and it's 6 times the price of the ADV728x, wow really!! So for the moment I'll stick with the ADV728x series and see what quality I get from it, if it's better than the PiCap SD1 then I'll stay with it. I'll still speak to Alvin on Tuesday and see what he says though but I'm starting to think the ISL79987 is a dead end with regard cost and effort required to implement it.

Have a great day, Dan

[6by9]

The drivers are all merged and in the latest rpi-update image. I'm not sure if they caught the recent Raspbian kernel bump or not. Looking at it, it is the device tree compatible string that dictates which set of inputs the driver allows, so whilst the 7282m overlay is likely to work you may want to create your own to get the correct settings. There isn't a huge difference between 7280m and 7282m though, so it may cover your use case.

The ISL parts are automotive grade which bumps the price up significantly, but should also guarantee the availability for many years. Eval boards also tend to be way overpriced for what they are, but the volumes over which to spread R&D costs are low so they almost have to be.

A picture of my lash up is at https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=195139#p1221456 A quick capture from my Panasonic DMR-EX75 via S-Video - https://drive.google.com/file/d/1bk5dTnpvMfLuTvnDbG9ej5PQELGlK1B1/view?usp=sharing. Yes it's a widescreen recording that hasn't got the pixel aspect ratio corrected. The stutter at ~6seconds was Linux deciding that it needed to save some data over my NFS mount and blocking the fwrite call, therefore stopping the app servicing the incoming data. Use a new thread to do the saving, and/or faster storage, and all should be good. (Actually I appear to have a second thread to do the saving, so something stranger is going on).

[6by9]

Curiousity got the better of me over how to encode the widescreen nature of the recording. Setting

        encoder_output->format->es->video.par.num = 64;
        encoder_output->format->es->video.par.den = 45;

is the answer in this case, resulting in https://drive.google.com/file/d/1zasiFagDXwmUVLGt162VO2cqcXTQ_Rc5/view?usp=sharing

[danriches]

Outstanding, very nice I must say! I've now got my board configured and using Yavta I get a blue screen preview, after some more poking around with a scope I can see the oscillator of the ADV7280 is running nicely but my camera (finepix 6900z) isn't giving out video. So I'm stuck for a video source until I'm back in the office unless I can find my sons portable DVD player. But so far I'm very happy and once I can see a captured image I'll be dancing as much as my knackered back will allow ;)

Thank you ever so much for your help, it's been awesome. Once I've got everything working I'll either have to send you a bottle of something or pop over to Pi Towers and say hello with a bottle of your choice in hand. Again, you've been a god send, thank you very very much.

Kind Regards, Dan

[danriches]

Hmm, one issue I have is no colour in the stream. I got my camera working and connected it to a TV to check the video source and it's nice and clean although somewhat pixelated (interpolated from the actual camera resolution) and has colour. It's standard composite video btw.

I've also tweaked the impedance matching and tried a trimmer too, no luck and the voltage levels are correct too. But all I get is black and white frames, nice and clean but still black and white. Any ideas?? Is there a way to supply the ADV7280-M with some other parameters in Yavta to change the configuration or should I do this myself before running the yavta app?

Thanks, Dan

[6by9]

Ignore yavta for now as it sounds like you need to check at the V4L2 level, and there v4l2-ctl is the best tool. Composite PAL at 50Hz? v4l2-ctl --get-detected-standard should return

pi@raspberrypi:~ $ v4l2-ctl --get-detected-standard
Video Standard = 0x000000ff
    PAL-B/B1/G/H/I/D/D1/K

yavta takes the detected format and calls VIDIOC_S_STD with it. If the chip can't detect the standard then you will get odd results. v4l2-ctl -V will also tell you the resolution of the capture, which will be 720x480 for NTSC or 720x576 for PAL. (There are only the two options).

There is a missing bit in the ADV driver for actually selecting the input. I've added a hack so the module parameter at /sys/module/adv7180/parameters/dbg_input will set the input when the standard is queried. Values are

#define ADV7182_INPUT_CVBS_AIN1 0x00
#define ADV7182_INPUT_CVBS_AIN2 0x01
#define ADV7182_INPUT_CVBS_AIN3 0x02
#define ADV7182_INPUT_CVBS_AIN4 0x03
#define ADV7182_INPUT_CVBS_AIN5 0x04
#define ADV7182_INPUT_CVBS_AIN6 0x05
#define ADV7182_INPUT_CVBS_AIN7 0x06
#define ADV7182_INPUT_CVBS_AIN8 0x07
#define ADV7182_INPUT_SVIDEO_AIN1_AIN2 0x08
#define ADV7182_INPUT_SVIDEO_AIN3_AIN4 0x09
#define ADV7182_INPUT_SVIDEO_AIN5_AIN6 0x0a
#define ADV7182_INPUT_SVIDEO_AIN7_AIN8 0x0b
#define ADV7182_INPUT_YPRPB_AIN1_AIN2_AIN3 0x0c
#define ADV7182_INPUT_YPRPB_AIN4_AIN5_AIN6 0x0d
#define ADV7182_INPUT_DIFF_CVBS_AIN1_AIN2 0x0e
#define ADV7182_INPUT_DIFF_CVBS_AIN3_AIN4 0x0f
#define ADV7182_INPUT_DIFF_CVBS_AIN5_AIN6 0x10
#define ADV7182_INPUT_DIFF_CVBS_AIN7_AIN8 0x11

The default input also used to be for 0x0E for differential composite on AIN1&2. I pushed a further patch that selects the lowest permitted value for the device (typically 0x00 CVBS_AIN1).

I assume you've adopted the recommended single-ended input network with 24 and 51 ohm resistors, and 100nF coupling capacitor as per the datasheet.

[danriches]

Hi,

Yes I've got the standard single ended front end network, I was starting to think the Colour Kill was triggering but no. After checking with v4l2-ctl --all I can see that it thinks the video is NTSC, here's a fragment of the commands output:

Video input : 0 (Camera0: ok) Video Standard = 0x0000b000 NTSC-M/M-JP/M-KR Format Video Capture: Width/Height : 720/480 Pixel Format : 'UYVY'

I guess I need to tell it the signal is PAL, set the width and height and go from there, is that right? I would use V4L2 API calls for this too...

Actually "v4l2-ctl -d /dev/video1 -s pal-B" and then running yavta for a quick test and I get colour. I'll go through my application which already uses V4L2 and update it and see what happens. Thank you :)

Kind Regards, Dan

[6by9]

Generally I've found the standard detection to work pretty well, so it's strange that it's not working for you.

I believe v4l2-ctl --all is printing out the selected format, not the detected one. Manual selection should work as well, although yavta will still be checking the detected format and setting that on you.

[danriches]

I've had great success with this chip thank you ever so much for the input and feedback, sterling work! I was just wondering if you know what the state of play is with the ADV748x driver which is in the source tree? Does it just need an overlay, has it been tested etc.

Sorry to be a pain again ;)

Kind Regards, Dan

[6by9]

adv748x is still under active development by others (look through the linux-media mailing list archives), although it appears against a Renesas platform (Salvator-X). You'll find a bundle of changes between 4.14 and 4.18 too. I don't have a suitable board to evaluate, but I'm happy to investigate the software if someone else supplies me the hardware (no guarantees I can get it working though).

The thing to watch for is that they're often using the Media Controller API to set up complex pipelines, which I've deliberately avoided at the present time as we have no complex processing. That's part of the reason that we have an issue with adv7282-m and the input switching, and few other people are bothered. When we're only controlling a sensor and receiver I see no point in adding the complexity, but it might happen later.

Binding docs for adv748x at https://github.com/raspberrypi/linux/blob/rpi-4.18.y/Documentation/devicetree/bindings/media/i2c/adv748x.txt It has 2 CSI2 outputs from the one device, and I don't know if we can easily weld that together at the moment. (Compute Module would be one option as it has 2 CSI inputs). Nothing stopping a few hacks to make it work of course, or possibly only wiring up one of the CSI2 outputs. There is a video-mux driver to allow connecting one receiver to multiple sources (eg FSA641. That does appear to be Media Controller API only, with little chance of using the basic subdev API. With a quick look it's not obvious what they're using to do the muxing (GPIO, I2C, pinctrl, magic) - too many layers of abstraction. The current Unicam driver won't work with that anyway as it queries the source during probe to work out the supported formats, and the mux can cause those to change. Not a huge problem, but would require rework.

It'd be worth doing some extra digging on how ADV748x handles interlacing on the SD path if that is the bit you're after. I've had a browse of the public data and find no references to it. The I2P in the ADV728[0|2] solves a huge number of issues in that area. There may be tricks that need to be pulled to get it to work.

[danriches]

The interlacing issue is exactly what I'm trying to find out too. If it can produce progressive output and the driver can be asked to change the input from HDMI or composite then that'd be fine for me. If it can do these then I'd be more than willing to get a couple of boards made and send you one. I'd also only need one of the CSI busses connected as one does all the input modes and the other only does standard definition therefore the primary CSI port is the only one of use to me.

I'll look into finding out if there's an I2P core in it and let you know.

Many Thanks, Dan

[6by9]

Ouch on eval kit price - https://www.verical.com/pd/analog-devices-misc-kits-and-tools-EVAL-ADV748XEBZ-985238?utm_currency=GBP £536!

[6by9]

If you were building a board, then a pair of CSI connectors would make sense as the chip exposes two entirely independent CSI interfaces (one 4 lane for HDMI/VGA input, and one 1 lane for SD). It might be worth going for the 22pin connector used on the CMIO for the 4 lane version, although you may then need custom adapter cables.

Not having an I2P core isn't a show stopper, but not having a mechanism for identifying the fields would be. We're only working at standard def, so deinterlacing can happily be done on VideoCore if we have the right information.

[6by9]

OK there is detail on interlacing in http://www.analog.com/media/en/technical-documentation/user-guides/ADV7481_UG-747.pdf page 193 Unfortunately I don't think any of the options offered there will work as I don't believe the receiver exposes the line start/end line numbers (registers 0x1F, 0x20, 0x21, and 0x22 all rely on manipulating that).

On the plus side, reg 0x10 on page 52 indicates you can redirect the SD CSI data over the 4 lanes CSI bus. That saves external muxes if you only want one input at a time.

[danriches]

How do you get around the lack of I2P core? I can produce a board with both the CSI ports if needed but I'd rather keep it RasPi 3B+ compatible only, although I suppose I could add the 22pin connector outline and just solder down whichever is required. I really do only need the one source input at a time for the end product (medical image capture) so if I can just use the one chip for both HDMI and Composite sources that'd be great. I couldn't find the eval board myself and £536 is a real killer, it'd be cheaper to build my own 3 or 4 boards!!

I need some feedback further up the management hierarchy even though I'm the only hardware developer before I go down the route of making a few dev boards up, but if you're willing to collaborate with the software side I'm absolutely more than happy to send you a board or two to keep. I dare say that the schematics would be fairly simple and I could share the video front end section only too but would need authorization first of course.

Dan

[6by9]

How do you get around the lack of I2P core?

If you can get access to the frame/line start line numbers, then the problem is solved. Otherwise you're pretty much stuffed.

There is a debug feature in the Pi CSI2 receiver that may be able to extract the required data. You can set up a packet comparison against a particular virtual channel and data type combination, and optionally store the word count and ECC of that packet. Compare against the frame start, and word count is the frame number that we're after. It's a custom hack to the otherwise generic CSI receiver driver, but has the potential (not guaranteed) to solve this problem. Whether we'd merge it into the main kernel is a different question. TBH I haven't looked at the adv748x driver closely enough to work out whether it supports enough stuff to work with this anyway. It might drive me to implement the Media Controller API stuff, but that adds significant overheads for the application too.

Connectors etc is totally up to you, the main thought was that 2 lanes can be quite limiting for HDMI capture. We've had similar problems with the TC358743 driver over 2 lanes only coping with 1080P30 as RGB or 1080P50 as UYVY. That chip is fairly flexible with CSI2 rates vs HDMI rates, whereas I think the ADV is more limited to pixel rate in = pixel rate out. If you're not bothered about HDMI then stick with the ADV7282M and you'll save all the problems we've discussed this morning :-)

I take it you'd found the full schematics and PCB files for the EVAL-ADV7481 board? https://ez.analog.com/docs/DOC-16502. Ignore all the bits about the Blackfin and ADV7511

[danriches]

Hmm, it most certainly sounds like it's not worth the bother at the moment, I had come up with a rather convoluted way of getting around the issue whilst still using the 7280 on the CSI port and a couple of video encoders which essentially go from HDMI to pixel bus and then pixel bus to analog SD. Yes, very ott but that may be the only way I can cater for the future need of hdmi/dvi input.

On the ISL79987 front and looking through the datasheet it constantly mentions 480i output over the MIPI CSI bus but there is one single bit in register page 5, register 0x05 bit 5 which says: 1 = 720x480 or 720x576 Standard Definition Progressive mode operation. For internal test only. It's default setting is 0. I'll ask Alvin what this is but in my mind it's that the progressive scan ability was added but not good enough to release as a feature. We'll see what he says tomorrow anyway. Thanks 6by9 ;) Kind Regards, Dan

[6by9]

If there were a sensibly priced ADV748x board available then I'd love to have a play. If you have a potential need for HDMI input then it sounds like that is probably worth investigating, but I understand getting the green-light from management. Interesting looking at the description for the Renesas Salvator-X with the ADV748x - https://elinux.org/R-Car/Tests:rcar-vin#Test_V4L2_FIELD_SEQ_TB_and_V4L2_FIELD_SEQ_BT

The hardware it self don't support capturing frames in this field mode however it is possible to do two captures to the same buffer and provide user-space with sequential frames containing both top and bottom fields.

So we're not unique in having problems receiving these weird interlaced formats.

The TC358743 exists currently for HDMI capture, and if required then others have got interlaced reception working, although only via raspiraw rather than V4L2 (https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=109137&start=450#p1331592 and the exchanges that then followed). 2 known quanitites may be a better bet than one slightly unknown one.

I'm rereading the ISL datasheet before Alvin comes tomorrow. Page 24/25. In the Pseudo single frame mode. the chip inserts an 8 byte header before each line that is sent. Byte 2 includes a field flag. That is going to require a lot of copying data around to put it in the right places. It's all possible, but a modest overhead. As I said before, we could do 2 cameras via the standard CSI2 virtual channel mechanism, but no more.

I don't know what the price point is for the ISL, but being automotive grade I suspect significantly more than the ADV chips, and AIUI you don't need the simultaneous capture capabilities which will increase the complexity (and cost).

[danriches]

I'll let you know if I get a green light from management for the ADV748x, like you say it'd be nice to play with and if it can work then that'd be great. At this point though as we currently need composite input first and HDMI later on I'll stick with the ADV7280A-M, it works and is so much nicer than the PiCapture SD plus I have the feeling that the ISL79987 isn't going to be what we want. As I turns out though the Renesas part is actually cheaper than the Analog Devices part by about £3 which did surprise me, but then again if the ISL part doesn't convert to progressive scan output that may be why it's cheaper. It'd probably need some internal frame buffer to merge two frames before sending them out and memory isn't cheap at the speeds we're talking about inside a tiny little video encoder.

It may mean I have to create another board which is based upon the TC358743 and is swapped out for the ADV7280 when an upgrade is required. At least this way the whole product won't need a reconfigure in terms of networking etc, just driver overlays.

Anyway we'll see what Alvin says, I could be wrong....

[6by9]

A useful conversation this end with Alvin, and it sounds like you had a similarly positive conversation.

ISL does look possible. Two fields per frame mode would make deinterlacing easier, even if the register is described as "For internal test only". That would allow for up to 2 channel simultaneous capture relatively easily. Deinterlacing on the Pi GPU doesn't take that format at the moment (I'm reading it as top/bottom rather than line interlaced), but would be fairly easy to tweak to support it. That said it also only currently takes YUV420, so would need a further tweak to take YUYV.

Interesting that Anglia also represent Analog Devices, so I am investigating getting an EVAL board for the ADV7482. Reading the specs very carefully, the 7481 only goes up to 720p60 or 1080i60 (75MHz pixel clock), whereas the 7482 will do 1080p60 (162MHz pixel clock). Shame that it drops MHL, but reality is that there are very few devices that support it. edit take it back. 7481 does MHL to 720p60/1080i60, but HDMI to 1080p60 (162MHz), so either would work.

[danriches]

Yes our conversation went rather well and I've got all the linux driver code which I guess he gave you too. I haven't been given an NDA to sign yet but probably will have to. I had the same thought that two field mode might work but said to Alvin that you'd be the person that knows.

I'd rather use the Renesas part because of the price but timescales will probably prevent that at least for the time being. I'll get the other isl79987 test board built and send it over to you if you want. I'm also looking into getting a prototype board made up for the 7481 to play around with for a future hdmi requirement if i can get hold of the parts that is.

All very interesting stuff and so much work to do, right now I've got to get back on with this product as the poe power supply Pcbs have arrived for stuffing and testing. 4 weeks until customer testing starts, no pressure!!

Have fun, Dan :)

[danriches]

Hi Dave,

I'm a bit stumped and probably doing something wrong, I'm using V4L2 to grab video and images but the output image data isn't being stored as a jpeg. If I enable the camera and use the official camera connected up my application saves a single frame as a jpeg no problem at all. With the ADV7280 it saves 810Kb of data of some unknown format. Is that because of this line: fmt.fmt.pix.pixelformat = V4L2_PIX_FMT_JPEG;

I think it is because the only pixelformat the ADV7280 comes up with is UYVY when I list the formats supported for it. How then do I go about converting this data to a jpeg or best still an uncompressed bitmap. Sorry to be a pain but I have scoured the interweb for hours and hours to no avail and you're my last hope. I'll try my utmost to leave you alone in future though ;)

Many Thanks, Dan

[6by9]

FYI I've got ADV7282-M working producing interlaced video and being signalled on the V4L2 buffers. See https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=218933 and https://github.com/6by9/linux/tree/rpi-4.14.y-unicam-interlaced You have to enable the module parameter allow-interlaced to stop it blocking you selecting interlaced modes, and will log a warning every time you try setting the format to interlaced, but sources that request V4L2_FIELD_ALTERNATE should be correctly set to report V4L2_FIELD_ODD or V4L2_FIELD_EVEN on the buffers it generates. Murphy's law says that I will have got the sense inverted, but there you go. It's not documented for ADV7282-M as to whether a value of 1 or 2 is top or bottom, nor whether the chip is automatically compensating that NTSC and PAL differ as to whether top or bottom is sent first, so a few things still to finalise.

[6by9]

The driver is purely exposing the raw data. There is no encoding available. If you request an unsupported encoding then the V4L2 API states that the driver will choose an alternate/default supported format. https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/vidioc-g-fmt.html With the Pi camera the V4L2 driver cheats and combines the camera with ISP, and video encoder, and image encoding to give one super component that can produce almost anything.

UYVY is a raw uncompressed image. https://fourcc.org/pixel-format/yuv-uyvy/ or https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-uyvy.html It's YUV4:2:2, so the chroma planes are subsampled horizontally by a factor of 2, and the chroma values are interleaved inbetween the luma samples.

What format are you after? If you only want monochrome then you can just take every other byte to form a 720x576 8bpp greyscale image. If you want colour then it'll be easiest to feed it through the MMAL ISP component to convert it to RGB or other planar YUV (this is what yavta does). At SD resolutions you could do it on the ARM cores, but it'll burn more power.

[danriches]

I'm really after full colour 24bit bitmap images so I guess I need to route the data through MMAL of which I know nothing at all. Guess I should start reading ;)

If I can easily get jpeg's off the bat at almost zero compression then that'd be ok since I could convert the images on the Windows service that picks up the images but I'd rather not add this because of the code everywhere syndrome it encourages.

I managed to get Toshiba on board with the TS358743 and they're sending me samples plus I have the B101 V1.4 board to test before hand for HDMI integration and there is no HDMI licensing fees to mess around with either because of the end product type. I tried to explain this to Analog Devices but they were having none of it so I've ditched all but the ADV7280 for composite video now. The product will have both interfaces inside but dependant on the customers requirements the CSI ribbon is on one interface or the other and just an SD card swap will have it running in either mode. Not the best of course but all I could come up with as the timeframe to release is end of October 2018, argh!!

Nice work on the interlacing by the way, I like all this video stuff but sometimes I just have to stop and walk away from the computer so I don't break something, physically that is ;)

[6by9]

For RGB888 or BGR888 you may as well use MMAL. I'll see if I can tidy up some code to make a reasonable example. yavta is doing all the relevant steps, but also has a load of extra crud in there as it was originally a V4L2 test app. JPEG is easy enough to tack on the end of the ISP (the JPEG block can't take UYVY) within MMAL if that is what is required, but will also increase latency slightly.

Some companies do seem to not want to sell chips! I've got a followup meeting with Alvin and his counterpart who deals with AD tomorrow, so we'll see if there is anything worth pursuing there. I'd like to get the ADV748x working as a challenge, but I haven't sold it to management here, and there enough other things going on to keep us busy.

As neither of us appear to be actively wanting to use the ISL79987 any more, I'll close the issue. I'll post a link to example code tomorrow, but otherwise please switch to the forum for further support (Camera board, or Interfacing).

[gsautr]

Hi @6by6, I was wondering if there was any more progress with ADV7282M or CVBS input board? I’ve been playing with SD1 and OpenFrameworks to create a video mixer in the style of the old Panasonic WJ and Roland V4 mixers, and getting multiple (unadulterated) PAL inputs via V4L would be a dream come true!

[6by9]

@autr - you've tagged the wrong person (6by6, not me).

It's done. I have an ADV7282M eval board working with a jury rigged output to get it into the Pi (SMA fly leads tacked on to a Pi camera board). Not cheap (~£110), but available from the normal candidates.

There are standard V4L2 drivers and a device tree overlay in our standard kernel. I haven't tested against 4.14 recently, but it's certainly working in 4.19 by adding dtoverlay=adv7282m to /boot/config.txt (amend to dtoverlay=adv7282m,i2c_pins_28_29=1 on a Pi0, 1, or 2). By default that enables the deinterlacing block in the ADV7280M or ADV7282M, mainly as signalling the fields isn't documented very well for this device, so I wasn't intending on merging support unless we had confirmed it was all correct.

Whether anyone will design a standalone board which has one of these chips on board, and then actually sells it at a sensible price is a totally different question.

[Davidsastresas]

Hello,

I have much interest on the ADV7282M support for the pi. as I understand @6by9 it is fully functional by now? I would use it for both component y/pb/pr and vbs, with resolutions up to 1080p.

If you confirm me that I am ordering right now the eval board, and after a few days of testing if everything seems all right we have hardware engineers here for designing a final board. We could make some extra boards and send some to you and maybe more people if there is interest. We can also contribute writing documentation if needed for the usage of this driver.

I wait for your answer, thank you very much for your time. Best regards.

[6by9]

@Davidsastresas Please read the chip description from Analog Devices for the ADV7282 https://www.analog.com/en/products/adv7282.html

10-Bit, 4× Oversampled SDTV Video Decoder with Differential Inputs and Deinterlacer

Component (Y/Pb/Pr), s-video (Y/C), and composite (cvbs) signals are all supported, but only at NTSC or PAL SDTV resolutions. I'm not aware of any suitable bridge chips with analogue input and higher resolutions, they all tend to have HDMI inputs, eg Toshiba TC358743 (supported by kernel drivers) or Analog Devices ADV748x (theoretically supported, but not proven on the Pi).

[danriches]

Hi,

I've already made an ADV7280A-M board and sold 2 to a person in Germany. They work absolutely fine up to 720x576 higher than that I don't know and don't think they do according to the datasheet. My board only supports single 75ohm cvbs sources and not the separate component sources as my customers seem only to want this. Hopefully our boards don't clash if you see what I mean from a commercial point of view...

All the best, Dan.

[Davidsastresas]

Oh, I was so excited when I found the thread that I didn't even double check that. I thought indeed it was adv7482. On my application is mandatory that 1080p at least from component video. ADV7482 don't even have eval board it seems, so it is going to be longer than I thought. In any case we are probably trying to develop it on a near future, so I will keep you guys updated in case we finally go for it.

@danriches in any case all of this were meant to be inside a system we are working on. We were not thinking on making any kind of business with the boards alone, I suggested that about the extra boards in case somebody wanted them for all of us to benefit from a cheaper final price due to more units produced :). I will let it know in case we finally go for the ADV7482 if anybody is interested.

Thank you very much both @danriches and @6by9 for your time.

Best regards.

[6by9]

AFAIK adv7482 is still only SDTV via the analogue input. https://www.analog.com/media/en/technical-documentation/data-sheets/ADV7482.pdf page 18

STANDARD DEFINITION PROCESSOR The ADV7482 is capable of decoding a large selection of baseband video signals in composite (both single-ended and differential), S-Video, and component formats. The video standards supported by the video processor include....

There is an eval board - https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/eval-adv7842.html I believe you have to contact Analog Devices or one of their distributors to get one - they aren't on the open market.

There are kernel drivers for the ADV784x chips - https://github.com/raspberrypi/linux/tree/rpi-4.19.y/drivers/media/i2c/adv748x. These have been tweaked further in more recent releases. IIRC They have mainly been developed against the imx6 platform, and are using the media controller API for some configuration.

[6by9]

Hmm, I may take that back https://www.analog.com/media/en/technical-documentation/user-guides/UG-214.pdf section 2.

The ADV7842 supports the decoding of a component RGB/YPrPb video signal into a digital YCrCb or RGB pixel output stream. The support for component video includes 525i, 625i, 525p, 625p, 720p, 1080i, 1080p, and 1250i standards, as well as many other SMPTE and HD standards.

I'd advise you to talk to Analog Devices for some guidance.