tudor
Posts: 5
Joined: Wed Apr 09, 2014 12:07 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Dec 15, 2015 11:44 pm

6by9 wrote:I've just had a fiddle with the firmware. The latest sudo rpi-update release should include a config.txt option of "disable_touchscreen". Setting that to 1 should configure the screen, but not set up the service that drives the touchscreen or backlight driver. I've not tested it extensively, but two pairs of eyes say it does the right thing. If you use it, please let me know if there are issues.
Thank you! It works!
I tested with an empty jessie image and apart from the usual parameters:

Code: Select all

dtparam=i2c=on
dtparam=i2c_vc=on
dtparam=i2c_arm=on
disable_touchscreen=1
disable_camera_led=1
start_x=1
gpu_mem=128
There was nothing particularly difficult.
I also used:

Code: Select all

   { 0x3500, 0xff },
   { 0x3501, 0xff },
   { 0x3502, 0xff },
and the image is slightly under-exposed.

To make it even easier, it would be possible to implement with a mailbox on the gpu a "proxy" for i2c commands for a certain address. In this case the sensor. Then there would be no more fiddling with special settings for i2c0.

lionfish
Posts: 2
Joined: Tue Jan 26, 2016 12:11 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jan 26, 2016 12:20 pm

Thanks 6by9 and others for working on this.

I'm just about to buy a raspberry pi and camera for a project.

Roughly: We need to take a UV photo in the dark, with a modified xenon flash (required due to its high UV output). We're currently using a digital SLR, but want to switch to the raspberry pi and pi cam to get the unit cost down.

Long story short: We want to take a photo with the flash using the raspberry pi camera, so we roughly want to:
1) "Reset all pixels"
2) Trigger flash
3) Start reading out pixel values (in the dark)

I saw on previous threads etc that access to the FREX control etc was impossible before.
I might not be fully understanding the above comments, etc. Does the work you've done allow this now? Or is there a work around?

Thanks again!

User avatar
jbeale
Posts: 3371
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jan 26, 2016 7:51 pm

As far as I know, there is no way to synchronize an external flash with the RPi camera. The OV5647 chip has a "FREX" signal (not even available on the official boards; pinned out on some 3rd party ones) but no one's ever been able to demonstrate it functioning.

One thing to try- you can simply pop the flash at random while the camera is running video (in "night" exposure mode where you have nearly 360 degree shutter angle, so long as ambient light is low enough). In general you will get two adjacent frames with some illumination, for example the top half of frame "A" and the bottom half of frame "B". If you join them together, then you get one mostly complete illuminated frame. Unfortunately, image quality in video mode is never as good as in still-frame mode.

Another thing that could work; just use a long still frame exposure, so the flash timing becomes less critical, but that only works if no other ambient light.

lionfish
Posts: 2
Joined: Tue Jan 26, 2016 12:11 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Jan 28, 2016 9:25 am

Hi jbeale!
First, thanks for helping with this, I owe you!

The quality of the image might not have to be very good at all, so the video idea might work (although I'm worried it will be very thin 'slices' of the video that will be lit by the flash). But I'm liking the sound of the "long still frame exposure": this is exactly what I need - just googled and found other threads about that. The only thing those threads suggest might be an issue is how accurately I can guess when the recording will start and end. (thinking to myself: e.g. It's not *completely* dark without the flash. So if I go with a 500ms exposure, then I'll need to know when it starts to within about 450ms... which I guess will be fairly easy to work out).

And just to confirm: All the pixels of the sensor will be integrating at the same time for the long exposures?

Thanks again! Your post was really useful! Now I know what I need to try.

I'll order the hardware and give it a go!

Mike.

PS Off topic, but I'm going to be taking these photos in UV. It looks like to remove the filter on the camera I should follow these instructions: http://rlab.org.uk/wiki/Remove_IR_filte ... _Pi_Camera
I guess there's not much else (besides glass) that will be in the way, so hopefully that will let UV pass. (I've got various UV notch filters, etc).

backinside
Posts: 16
Joined: Fri May 15, 2015 10:07 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Feb 11, 2016 7:48 pm

Hi,

Just a quick update, it seems, I have the first proof of concept running, I successfully processed the incoming raw image, and sent out the useful tracking info in 14ms after receiving the frame from the camera.
That means, this setup can now actually outperform our USB2 camera connected to an Intel i5
So thank you again jbeale and 6by9 !

Best regards,
Peter
backinside wrote:Hi,

Wow, thank you for the effort jbeale and 6by9 !
Great work, and I've managed to get this up and running in no time!
I'm trying to use this create a low latency tracker for well illuminated objects, since we know the ROI from the previous frame, we only need a couple hundred pixels update the information, so I hope to achieve really low latency when I don't have to decode a jpeg or h264 image

But I'm having a hard time changing to raspiraw source to achieve 720p with 60 fps.
I've tried adding
output->format->es->video.frame_rate.num = 60;
output->format->es->video.frame_rate.den = 1;
But it does not seem to change the callback timing, no matter what resolution I use

Do I need special sensor_regs for that?

Thanks,
Peter

User avatar
jbeale
Posts: 3371
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: Raw sensor access / CSI-2 receiver peripheral

Thu Feb 11, 2016 8:07 pm

glad to hear you got something working. I guess you already know, but FWIW my experience is that with the camera running in "night" exposure mode and recording video at 24 fps, there is not much dead time; the pixels really are integrating nearly the entire frame time. In my case, I found that a 2 millisecond flash once per frame will illuminate very nearly all the pixels, except for somewhat less illumination on a thin horizontal band which are the pixels in the process of being read out; the location of that band depends on the synchronization of the start-of-frame with the flash.

Ihor
Posts: 2
Joined: Fri Feb 12, 2016 3:16 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Feb 12, 2016 3:22 pm

Hello! I am trying to use your application to receive information from the RGB camera through RGB to CSI adapter. This means that I have 24 bits per pixel. Resolution 640 x 480 pixels.
As a result, I get some data (i know that is my data) in raw files, but in the file there is also a lot of garbage and bad frame synchronization. I want to get the file size of 640 by 480 by 3 bytes. Can you explain to me how I should configure your application for my case (i mean encoding settings, resolution, etc)?
And thank you for the application!

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6332
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Feb 16, 2016 9:00 pm

Ihor wrote:Hello! I am trying to use your application to receive information from the RGB camera through RGB to CSI adapter. This means that I have 24 bits per pixel. Resolution 640 x 480 pixels.
As a result, I get some data (i know that is my data) in raw files, but in the file there is also a lot of garbage and bad frame synchronization. I want to get the file size of 640 by 480 by 3 bytes. Can you explain to me how I should configure your application for my case (i mean encoding settings, resolution, etc)?
And thank you for the application!
It sounds like you're using the wrong application. The sensor produces data as 10bits per pixel, but with a Bayer pattern of colour filters over the pixels. To get 24bit/pixel RGB from that requires a fair amount of processing, and is exactly what happens with raspividyuv (the data goes via the ISP to do all that processing in hardware).

Secondly raspiraw sets the sensor to run with a resolution of 2592x1944, so I don't know you think you're getting 640x480.
There is a 640x480 mode available from the sensor, which happens to have just been logged (viewtopic.php?f=43&t=47798&start=50#p901686). Convert that into an alternate register set in raspiraw and you can get VGA @ 90fps, but it'll still be 10bpp and Bayer patterned.
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.

User avatar
jbeale
Posts: 3371
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: Raw sensor access / CSI-2 receiver peripheral

Wed Feb 17, 2016 1:01 am

RGB to CSI adapter
are you talking about some 3rd-party standalone hardware board that takes RGB analog signals in and generates CSI out? Or the existing RPi camera using the 5Mpixel OV5647 sensor?

Ihor
Posts: 2
Joined: Fri Feb 12, 2016 3:16 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Wed Feb 17, 2016 11:24 am

jbeale wrote:
RGB to CSI adapter
are you talking about some 3rd-party standalone hardware board that takes RGB analog signals in and generates CSI out? Or the existing RPi camera using the 5Mpixel OV5647 sensor?
Yes, you a right! But HW it is not important. I delete i2c processing in raspiraw app, and now i have only mipi-2 interface and it's working. I get the data from the camera, but for some reasons of non-compliance of packaging of data, it lies in file (* .raw) with the trash (at the end or at the beginning of the file). I can make later an example of the file that i received.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6332
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Wed Feb 17, 2016 11:52 am

Ihor wrote:Yes, you a right! But HW it is not important. I delete i2c processing in raspiraw app, and now i have only mipi-2 interface and it's working. I get the data from the camera, but for some reasons of non-compliance of packaging of data, it lies in file (* .raw) with the trash (at the end or at the beginning of the file). I can make later an example of the file that i received.
Hardware is important to actually understand what you're trying to do. Your first post was very ambiguous.

It sounds like you're interfacing to a device similar to the Toshiba TC358743 HDMI to CSI2 bridge chip (I'd guess a TW9992 or ADV7280 analogue video to CSI2, or TC358746 parallel camera to CSI2 bridge). There's ongoing development to get that supported, mainly from this thread. That's using the same CSI2 receiver component, but you can see in
https://github.com/6by9/userland/blob/h ... tc358743.c that it is setting up the main parameters as
#define WIDTH 1280
#define HEIGHT 720
#define ENCODING MMAL_ENCODING_BGR24
#define UNPACK MMAL_CAMERA_RX_CONFIG_UNPACK_NONE
#define PACK MMAL_CAMERA_RX_CONFIG_PACK_NONE

You'll want to check the datasheet for your device to see which CSI2 packet ID (CSI_IMAGE_ID) the data is being sent on - get it wrong and you will get no data in the image buffers.
You may need to grab the latest firmware with "sudo rpi-update" as BGR24 support for the rawcam component was only added in the 1st Feb 2016 update. The latest Raspbian release was 9th Feb 2016, so that may be good too - use "vcgencmd version" to confirm.
The same commit added support for RGB24 and BGR24 on the input of video_render, so gave an easy way of viewing the received data. The raspi_tc358743 displays the output rather than saving it as raspiraw does.
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.

ajf
Posts: 2
Joined: Wed Dec 23, 2015 11:36 am

Re: Raw sensor access / CSI-2 receiver peripheral

Mon Jun 06, 2016 11:14 pm

Hi,

This sounds great, I'm very keen to get this up and running. I've built the userland tools but unfortunately I am unable to locate the start_x.elf file mentioned in the instructions provided by jbeale on Sun Jul 12, 2015 5:22 am (which seem the clearest instructions) https://raw.githubusercontent.com/6by9/ ... tart_x.elf Can anyone tell me where I can get this file? Thanks,

Andy

cybertux
Posts: 1
Joined: Sat Jul 07, 2012 8:44 pm

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 6:04 am

One question, will the raw CSI-2 interface still work on a Raspberry PI 3? I do ask because from this viewtopic.php?f=44&t=138897&p=923243 it looks like I2C-0 is not available for the ARM Core anymore on PI 3

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6332
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 7:20 am

ajf wrote:This sounds great, I'm very keen to get this up and running. I've built the userland tools but unfortunately I am unable to locate the start_x.elf file mentioned in the instructions provided by jbeale on Sun Jul 12, 2015 5:22 am (which seem the clearest instructions) https://raw.githubusercontent.com/6by9/ ... tart_x.elf Can anyone tell me where I can get this file? Thanks,
No need - all the code is now merged into the main firmware (hence the strike through in the first post).
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.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6332
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 7:27 am

cybertux wrote:One question, will the raw CSI-2 interface still work on a Raspberry PI 3? I do ask because from this viewtopic.php?f=44&t=138897&p=923243 it looks like I2C-0 is not available for the ARM Core anymore on PI 3
Correct, as per the 3rd post on that thread.
The camera I2C is connected to pins 44&45 which can be muxed to i2c-1 instead, however there isn't an easy way to control the power/LED GPIOs as they are now on the expander.
PhilE had made a comment that in theory the virtgpio driver should be able to control all 8 lines on the expander via the GPU, but I haven't tried. The relevant section of config is https://github.com/raspberrypi/linux/bl ... -b.dts#L83 with driver at https://github.com/raspberrypi/linux/bl ... bcm-virt.c
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.

User avatar
Akane
Posts: 41
Joined: Tue May 27, 2014 1:20 pm
Location: Tsukuba, Japan

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 8:15 am

6by9 wrote:PhilE had made a comment that in theory the virtgpio driver should be able to control all 8 lines on the expander via the GPU, but I haven't tried. The relevant section of config is https://github.com/raspberrypi/linux/bl ... -b.dts#L83 with driver at https://github.com/raspberrypi/linux/bl ... bcm-virt.c
Do you know how to use the virtual GPIO driver? I've been trying to use it, but it doesn't work.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6332
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 9:08 am

Akane wrote:
6by9 wrote:PhilE had made a comment that in theory the virtgpio driver should be able to control all 8 lines on the expander via the GPU, but I haven't tried. The relevant section of config is https://github.com/raspberrypi/linux/bl ... -b.dts#L83 with driver at https://github.com/raspberrypi/linux/bl ... bcm-virt.c
Do you know how to use the virtual GPIO driver? I've been trying to use it, but it doesn't work.
You have to use the sysfs infrastructure, or a kernel driver. wiringPi, raspi-gpio, etc, won't be able to talk to it as it is not a BCM283x peripheral.
It shows up as /sys/class/gpio/gpiochip100, with /sys/class/gpio/gpiochip100/ngpio currently saying 2. Increase #gpio-cells in device tree and I would expect to be able to expand that up to 8.
gpio100 won't currently export, so is obviously in use. "cat /sys/kernel/debig/gpio" gives a ? as to what it is registered to, but it is to something in the kernel.
gpio101 will export, but I haven't tried wiggling it.
Somewhere in the past I have posted a list of the connections made to it. The forum search is failing me for now.
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.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6332
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 9:41 am

Oh dear, wishful thinking on my part that device tree would do the magic.
https://github.com/raspberrypi/linux/bl ... virt.c#L21

Code: Select all

#define NUM_GPIO 2
Base is also hard coded to 100.
I guess that means a kernel recompile to increase ngpio.
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.

User avatar
Akane
Posts: 41
Joined: Tue May 27, 2014 1:20 pm
Location: Tsukuba, Japan

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 11:25 am

Sorry. Because SD load-based LED driver is working at the same time, I mistook the virtual GPIO driver doesn't work.
Now I see the ACT LED is blinking through the Mailbox interface! Wow!

Could you tell me which off(set) is aliased to FXL6408 ports?

And I can't comprehend why the off(set) of ACT LED is 0.
According to dt-blob, Raspberry Pi 3's LEDS_DISK_ACTIVITY is FXL6408's #3 port. So the off(set) should be 3, shouldn't it?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6332
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 12:01 pm

It looks like I'd already directed you to the dt-blob.dts file back on viewtopic.php?f=72&t=18292&p=934096#p933712

As listed there:
2 - LEDS_DISK_ACTIVITY
3 - LAN_RUN
4 - HDMI_CONTROL_ATTACHED
5 - CAMERA_0_SHUTDOWN
6 - CAMERA_0_LED
7 - POWER_LOW

I'm afraid I don't have more detail than that. I'm guessing that the board activity LED is on 0 based on the Linux driver.

Then again the firmware code handling the other side appears to be ONLY calling into the handler for the activity LED, so perhaps that isn't generic. There is an alternate RPI_FIRMWARE_... value defined that may be of help, but as it isn't declared in the kernel I'm guessing dom had a good reason not to use it. I'll check with him.
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.

User avatar
Akane
Posts: 41
Joined: Tue May 27, 2014 1:20 pm
Location: Tsukuba, Japan

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 12:16 pm

6by9 wrote:It looks like I'd already directed you to the dt-blob.dts file back on viewtopic.php?f=72&t=18292&p=934096#p933712

As listed there:
2 - LEDS_DISK_ACTIVITY
3 - LAN_RUN
4 - HDMI_CONTROL_ATTACHED
5 - CAMERA_0_SHUTDOWN
6 - CAMERA_0_LED
7 - POWER_LOW

I'm afraid I don't have more detail than that. I'm guessing that the board activity LED is on 0 based on the Linux driver.

Then again the firmware code handling the other side appears to be ONLY calling into the handler for the activity LED, so perhaps that isn't generic. There is an alternate RPI_FIRMWARE_... value defined that may be of help, but as it isn't declared in the kernel I'm guessing dom had a good reason not to use it. I'll check with him.
Thank you!
Yes. The off(set) of the activity LED is 0. 1-7 seem not to be connected to any LED.
So the virtual GPIO buffer is only for the activity LED currently.
I'm looking forward to seeing the new Mailbox tag or a better LED controlling interface!

EDIT:
I made a working example of the usage of the GPIO virtual buffer: https://github.com/Terminus-IMRC/rpi3-gpiovirtbuf
Last edited by Akane on Tue Jun 07, 2016 11:49 pm, edited 1 time in total.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6332
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 2:38 pm

Doh, I should have looked a few lines further up in the blob.

Code: Select all

            [email protected] { function = "output"; termination = "no_pulling"; }; // BT_ON
            [email protected] { function = "output"; termination = "no_pulling"; }; // WL_ON
            [email protected] { function = "output"; termination = "no_pulling"; }; // ACT_LED
            [email protected] { function = "output"; termination = "no_pulling"; }; // LAN_RUN
            [email protected] { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Hotplug
            [email protected] { function = "output"; termination = "no_pulling"; }; // Camera LED
            [email protected] { function = "output"; termination = "no_pulling"; }; // Camera shutdown
            [email protected] { function = "input";  termination = "no_pulling"; polarity = "active_low"; }; // Power low
So that is what 0 & 1 do - Bluetooth and WLan power.

Confirmed with Dom, bcm_virt_gpio is only controlling ACT_LED on output 2, so not terribly helpful. It's also polled every 100ms on the GPU.

He has given his blessing to using two currently undocumented mailbox values - they were only not in the kernel through not having been needed. They should drop into your example code very easily.

Code: Select all

      GET_GPIO_STATE             = 0x00030041,
      SET_GPIO_STATE             = 0x00038041,
SET takes two words - a GPIO pin number in [0], and a value in [1]. The GPIO number is as in the blob, so 133 and 134 for the camera control lines.
GET also takes two words - a base GPIO number in [0], and a pointer to where to write the state in [1].
Note that the polarity can be defined in the blob, so invert the value you may be expecting if looking from the outside world.

Please remember that twiddling these may have undesired consequences to system stability - the GPU drivers think they own these GPIOs, so they may try putting them back to their state if you do strange things.
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.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 6332
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Raw sensor access / CSI-2 receiver peripheral

Tue Jun 07, 2016 10:20 pm

Quick hack based on your app (saved me some time!)

Code: Select all

commit a577dadeb3197d5c5f1b42fc75abfe8aff1f840c
Author: Dave Stevenson <[email protected]>
Date:   Tue Jun 7 22:05:16 2016 +0000

    Test of SET_GPIO_STATE calls
    
    GPIO 134 is the camera LED GPIO
    GPIO 133 is the camera power GPIO

diff --git a/raspberrypi-firmware.h b/raspberrypi-firmware.h
index 9d167b6..dfbb855 100644
--- a/raspberrypi-firmware.h
+++ b/raspberrypi-firmware.h
@@ -62,6 +62,8 @@ enum rpi_firmware_property_tag {
        RPI_FIRMWARE_GET_EDID_BLOCK =                         0x00030020,
        RPI_FIRMWARE_GET_CUSTOMER_OTP =                       0x00030021,
        RPI_FIRMWARE_GET_DOMAIN_STATE =                       0x00030030,
+       RPI_FIRMARE_GET_GPIO_STATE =                          0x00030041,
+       RPI_FIRMWARE_SET_GPIO_STATE =                         0x00038041,
        RPI_FIRMWARE_SET_CLOCK_STATE =                        0x00038001,
        RPI_FIRMWARE_SET_CLOCK_RATE =                         0x00038002,
        RPI_FIRMWARE_SET_VOLTAGE =                            0x00038003,
diff --git a/rpi3-gpiovirtbuf.c b/rpi3-gpiovirtbuf.c
index 213a831..feef093 100644
--- a/rpi3-gpiovirtbuf.c
+++ b/rpi3-gpiovirtbuf.c
@@ -160,6 +160,8 @@ int main(int argc, char *argv[])
        unsigned *addr = NULL;
        unsigned off;
        int val;
+       uint32_t gpio_set[2];
+       int i;
-       if (argc != 2) {
+       if (argc < 2) {
                fprintf(stderr, "error: Invalid the number of the arguments\n");
                usage(argv[0]);
                exit(EXIT_FAILURE);
@@ -172,11 +174,31 @@ int main(int argc, char *argv[])
 
        mb = rpi_firmware_open();
 
-       rpi_firmware_property(mb, RPI_FIRMWARE_FRAMEBUFFER_GET_GPIOVIRTBUF, &gvp, sizeof(gvp));
-       addr = mapmem_cpu(BUS_TO_PHYS(gvp), 4096);
-       gpio_set(addr, off, val);
-       unmapmem_cpu(addr, 4096);
-       addr = NULL;
+       //rpi_firmware_property(mb, RPI_FIRMWARE_FRAMEBUFFER_GET_GPIOVIRTBUF, &gvp, sizeof(gvp));
+       if(argc == 3) {
+               gpio_set[0] = val;
+               gpio_set[1] = atoi(argv[2]);
+               fprintf(stderr, "Set state of %d to %d\n", val, atoi(argv[2]));
+               rpi_firmware_property(mb, RPI_FIRMWARE_SET_GPIO_STATE, gpio_set, sizeof(gpio_set));
+       } else {
+               for (i=0; i<10; i++) {
+                       gpio_set[0] = val;
+                       gpio_set[1] = 1;
+                       fprintf(stderr, "On\n");
+                       rpi_firmware_property(mb, RPI_FIRMWARE_SET_GPIO_STATE, gpio_set, sizeof(gpio_set));
+                       sleep(1);
+                       fprintf(stderr, "Off\n");
+                       gpio_set[0] = val;
+                       gpio_set[1] = 0;
+                       rpi_firmware_property(mb, RPI_FIRMWARE_SET_GPIO_STATE, gpio_set, sizeof(gpio_set));
+                       sleep(1);
+               }
+       }
+
+//     addr = mapmem_cpu(BUS_TO_PHYS(gvp), 4096);
+//     gpio_set(addr, off, val);
+//     unmapmem_cpu(addr, 4096);
+//     addr = NULL;
 
        rpi_firmware_close(mb);
        mb = -1;
Running "./rpi3-gpiovirtbuf 134" then sits there and flashes the camera LED 10 times.
Add "dtoverlay=i2c1-bcm2708,sda1_pin=44,scl1_pin=45,pin_func=6" to /boot/config.txt, run "./rpi3-gpiovirtbuf 133 1", and "i2c-detect -y 1" shows up the sensor on address 0x36 :D

That needs a bundle of tidying up, but it's very tempting to shift the GPIO control for this to totally use this mechanism.
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.

User avatar
Akane
Posts: 41
Joined: Tue May 27, 2014 1:20 pm
Location: Tsukuba, Japan

Re: Raw sensor access / CSI-2 receiver peripheral

Wed Jun 08, 2016 5:47 am

Thank you very much, Steve!
I'll test them.

ajf
Posts: 2
Joined: Wed Dec 23, 2015 11:36 am

Re: Raw sensor access / CSI-2 receiver peripheral

Fri Jun 10, 2016 1:57 pm

6by9 wrote:
ajf wrote:This sounds great, I'm very keen to get this up and running. I've built the userland tools but unfortunately I am unable to locate the start_x.elf file mentioned in the instructions provided by jbeale on Sun Jul 12, 2015 5:22 am (which seem the clearest instructions) https://raw.githubusercontent.com/6by9/ ... tart_x.elf Can anyone tell me where I can get this file? Thanks,
No need - all the code is now merged into the main firmware (hence the strike through in the first post).
Ah, thanks, I read forwards from jbeale's post didn't see you'd updated the first post.
Its working just fine now thanks.

Return to “Camera board”