Re: RFC: ov7670 soc-camera driver
On Mon, 16 Mar 2009 08:46:12 +0100 Hans Verkuil wrote: > > I think it's necessary, really. Having two drivers for the same device > > seems like a bad idea. As Hans noted, he's already put quite a bit of > > work into generalizing the ov7670 driver; I think it would be best to > > work with him to get a driver that works for everybody. > > Just FYI: I'll try to get my ov7670 code merged this week. I'm waiting for > Mauro to merge a pending pull request of mine, and then I'll rebase > my 'cafe2' tree and send out a pull request for it. The cafe2 code were merged today. As said, the better is to use the existing ov7670 code, instead of just creating another. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ov7670 soc-camera driver
Jonathan Corbet wrote: > On Sun, 15 Mar 2009 17:10:01 + > Jonathan Cameron wrote: > >> The primary control on this chip related to shutter rate is actualy >> the frame rate. There are rather complex (and largerly undocumented) >> interactions between this setting and the auto brightness controls >> etc. Anyone have any suggestions on a better way of specifying this? > > Welcome to the world of the ov7670! My conclusion, after working with > this sensor, is that is consists of something like 150 analog tweakers > disguised as digital registers. Everything interacts with everything > else, many of the settings are completely undocumented, and that's not > to mention the weird multiplexor at 0x79. It's hard to make this thing > work if you don't have a blessed set of settings from OmniVision. Hmm... And the grape vine / rumour says that they get most of their 'magic' values from customers who tweak the chips enough to get something working. Thanks for all the good work you put in. Only other useful info was the tinyos driver and that was a port of yours in the first place ;) I'm particularly fond of the apparently obvious registers that won't take a write unless something else is in a particular state. > >> Clearly this driver shares considerable portions of code with >> Jonathan Corbet's driver (in tree). It would be complex to combine >> the two drivers, but perhaps people feel this would be worthwhile? > > I think it's necessary, really. Having two drivers for the same device > seems like a bad idea. As Hans noted, he's already put quite a bit of > work into generalizing the ov7670 driver; I think it would be best to > work with him to get a driver that works for everybody. That sounds like a good plan. Now all we need is some time ;) Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ov7670 soc-camera driver
Guennadi Liakhovetski wrote: > On Sun, 15 Mar 2009, Hans Verkuil wrote: > >> On Sunday 15 March 2009 19:50:39 Guennadi Liakhovetski wrote: >>> On Sun, 15 Mar 2009, Jonathan Cameron wrote: From: Jonathan Cameron OV7670 driver for soc-camera interfaces. >>> Much appreciated, thanks! >>> --- There is already an ov7670 driver in tree, but it is very interface specific (olpc) and hence not much use for the crossbow IMB400 board which is plugged into an imote 2 pxa271 main board. > > [snip] > Clearly this driver shares considerable portions of code with Jonathan Corbet's driver (in tree). It would be complex to combine the two drivers, but perhaps people feel this would be worthwhile? >>> Now, there we go... Hans, time for v4l2-device?... >>> >>> This means, I will look through the driver, but we should really think >>> properly whether to pull it in now, or "just" convert the OLPC driver and >>> soc-camera to v4l2-device and thus enable re-use. >> I have already converted ov7670 to v4l2_subdev here: >> >> http://linuxtv.org/hg/~hverkuil/v4l-dvb-cafe2/ >> >> I'm waiting for test feedback (Hi Corbet!) before I'll merge it. >> >> This situation is exactly why we need one single API for subdevices like >> this. As soon as soc-camera is converted to v4l2-device it will just all >> fall neatly into place. >> >> I don't think it is a good idea to merge a second ov7670 driver as that's >> exactly what we are trying to avoid. Migrating soc-camera to the >> v4l2-device/v4l2-subdev framework is the right approach. Otherwise this >> issue will just crop up time and again. >> >> Although not good news for Jonathan, since his work will be delayed. >> Jonathan, to get an idea what all of this is about you should read the >> v4l2-framework.txt document in the master v4l-dvb repository >> (linuxtv.org/hg/v4l-dvb). It will give you the background information on >> the v4l2_subdev structure and associated API that we are migrating towards. >> And soc-camera happens to a framework that hasn't been converted yet. > > Well, I don't think Jonathan's work will be quite in vain - it will > probably help having both drivers (soc-camera and v4l2-device) during the > porting for comparison and feature exchange. But I agree, that it wouldn't > be a right thing to merge this driver in the mainline now. That's fair enough. I'm having to maintain a couple of other drivers out of tree under similar circumstances so one more doesn't make much difference. Hardest bit of this driver was dealing with some board specific i2c quirks anyway which I'd have had to do even if their was a suitable driver in tree. For reference, any changes I make in the meantime will end up in http://git.kernel.org/?p=linux/kernel/git/jic23/imote2.git > > I am willing and planning to do (at least a part of) this conversion, the > only problem is that I don't have much free (as in beer:-)) time for it, Know that feeling, or I'd offer to help ;) Happy to do some testing but probably can't contribute any coding time. Too much in the todo list right now. I'm not entirely clear how the subdev stuff will actually help, but I guess that'll be come clear as the code progresses. > and so far I don't see anyone outside queuing to finance this work:-) In > any case, looks like I'll have to pump up its priority and start working > on it asap. I only have to review the next version of PXA DMA conversion > patches, and then I'll declare a feature-freeze and just plunge into it. > Once started it will be finished some time:-) Sounds, good. Please keep me informed of progress (I'm not going to be that active a reader of linux-media ;) Thanks for the quick responses. Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ov7670 soc-camera driver
On Sunday 15 March 2009 23:23:38 Jonathan Corbet wrote: > On Sun, 15 Mar 2009 17:10:01 + > > Jonathan Cameron wrote: > > The primary control on this chip related to shutter rate is actualy > > the frame rate. There are rather complex (and largerly undocumented) > > interactions between this setting and the auto brightness controls > > etc. Anyone have any suggestions on a better way of specifying this? > > Welcome to the world of the ov7670! My conclusion, after working with > this sensor, is that is consists of something like 150 analog tweakers > disguised as digital registers. Everything interacts with everything > else, many of the settings are completely undocumented, and that's not > to mention the weird multiplexor at 0x79. It's hard to make this thing > work if you don't have a blessed set of settings from OmniVision. > > > Clearly this driver shares considerable portions of code with > > Jonathan Corbet's driver (in tree). It would be complex to combine > > the two drivers, but perhaps people feel this would be worthwhile? > > I think it's necessary, really. Having two drivers for the same device > seems like a bad idea. As Hans noted, he's already put quite a bit of > work into generalizing the ov7670 driver; I think it would be best to > work with him to get a driver that works for everybody. Just FYI: I'll try to get my ov7670 code merged this week. I'm waiting for Mauro to merge a pending pull request of mine, and then I'll rebase my 'cafe2' tree and send out a pull request for it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ov7670 soc-camera driver
On Sun, 15 Mar 2009 17:10:01 + Jonathan Cameron wrote: > The primary control on this chip related to shutter rate is actualy > the frame rate. There are rather complex (and largerly undocumented) > interactions between this setting and the auto brightness controls > etc. Anyone have any suggestions on a better way of specifying this? Welcome to the world of the ov7670! My conclusion, after working with this sensor, is that is consists of something like 150 analog tweakers disguised as digital registers. Everything interacts with everything else, many of the settings are completely undocumented, and that's not to mention the weird multiplexor at 0x79. It's hard to make this thing work if you don't have a blessed set of settings from OmniVision. > Clearly this driver shares considerable portions of code with > Jonathan Corbet's driver (in tree). It would be complex to combine > the two drivers, but perhaps people feel this would be worthwhile? I think it's necessary, really. Having two drivers for the same device seems like a bad idea. As Hans noted, he's already put quite a bit of work into generalizing the ov7670 driver; I think it would be best to work with him to get a driver that works for everybody. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ov7670 soc-camera driver
On Sun, 15 Mar 2009, Hans Verkuil wrote: > On Sunday 15 March 2009 19:50:39 Guennadi Liakhovetski wrote: > > On Sun, 15 Mar 2009, Jonathan Cameron wrote: > > > From: Jonathan Cameron > > > > > > OV7670 driver for soc-camera interfaces. > > > > Much appreciated, thanks! > > > > > --- > > > There is already an ov7670 driver in tree, but it is very interface > > > specific (olpc) and hence not much use for the crossbow IMB400 board > > > which is plugged into an imote 2 pxa271 main board. [snip] > > > Clearly this driver shares considerable portions of code with > > > Jonathan Corbet's driver (in tree). It would be complex to combine > > > the two drivers, but perhaps people feel this would be worthwhile? > > > > Now, there we go... Hans, time for v4l2-device?... > > > > This means, I will look through the driver, but we should really think > > properly whether to pull it in now, or "just" convert the OLPC driver and > > soc-camera to v4l2-device and thus enable re-use. > > I have already converted ov7670 to v4l2_subdev here: > > http://linuxtv.org/hg/~hverkuil/v4l-dvb-cafe2/ > > I'm waiting for test feedback (Hi Corbet!) before I'll merge it. > > This situation is exactly why we need one single API for subdevices like > this. As soon as soc-camera is converted to v4l2-device it will just all > fall neatly into place. > > I don't think it is a good idea to merge a second ov7670 driver as that's > exactly what we are trying to avoid. Migrating soc-camera to the > v4l2-device/v4l2-subdev framework is the right approach. Otherwise this > issue will just crop up time and again. > > Although not good news for Jonathan, since his work will be delayed. > Jonathan, to get an idea what all of this is about you should read the > v4l2-framework.txt document in the master v4l-dvb repository > (linuxtv.org/hg/v4l-dvb). It will give you the background information on > the v4l2_subdev structure and associated API that we are migrating towards. > And soc-camera happens to a framework that hasn't been converted yet. Well, I don't think Jonathan's work will be quite in vain - it will probably help having both drivers (soc-camera and v4l2-device) during the porting for comparison and feature exchange. But I agree, that it wouldn't be a right thing to merge this driver in the mainline now. I am willing and planning to do (at least a part of) this conversion, the only problem is that I don't have much free (as in beer:-)) time for it, and so far I don't see anyone outside queuing to finance this work:-) In any case, looks like I'll have to pump up its priority and start working on it asap. I only have to review the next version of PXA DMA conversion patches, and then I'll declare a feature-freeze and just plunge into it. Once started it will be finished some time:-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ov7670 soc-camera driver
On Sunday 15 March 2009 19:50:39 Guennadi Liakhovetski wrote: > On Sun, 15 Mar 2009, Jonathan Cameron wrote: > > From: Jonathan Cameron > > > > OV7670 driver for soc-camera interfaces. > > Much appreciated, thanks! > > > --- > > There is already an ov7670 driver in tree, but it is very interface > > specific (olpc) and hence not much use for the crossbow IMB400 board > > which is plugged into an imote 2 pxa271 main board. > > > > Thanks go to Crossbow (www.xbow.com) for assistance in developing > > this driver. > > > > This is my first driver related to v4l let alone soc-camera so this > > is probably full of errors. All comments appreciated! > > > > A couple of questions related to this patch. > > > > Unfortunately the data ordering in rgb565 is not that expected by > > the pxa271 which for reasons best known to someone else shuffles > > the bit order coming off the camera. I don't know if this is a > > common problem. I haven't been able to come up with a combination > > of sensor and soc colour modes that will let this through. Anyone > > else met a similar problem? At the moment I'm relying on > > board specific documentation explaining how to rebuild the data > > once an image has been captured, but obviously this is far from > > ideal. > > > > The primary control on this chip related to shutter rate is actualy > > the frame rate. There are rather complex (and largerly undocumented) > > interactions between this setting and the auto brightness controls > > etc. Anyone have any suggestions on a better way of specifying this? > > > > Clearly this driver shares considerable portions of code with > > Jonathan Corbet's driver (in tree). It would be complex to combine > > the two drivers, but perhaps people feel this would be worthwhile? > > Now, there we go... Hans, time for v4l2-device?... > > This means, I will look through the driver, but we should really think > properly whether to pull it in now, or "just" convert the OLPC driver and > soc-camera to v4l2-device and thus enable re-use. I have already converted ov7670 to v4l2_subdev here: http://linuxtv.org/hg/~hverkuil/v4l-dvb-cafe2/ I'm waiting for test feedback (Hi Corbet!) before I'll merge it. This situation is exactly why we need one single API for subdevices like this. As soon as soc-camera is converted to v4l2-device it will just all fall neatly into place. I don't think it is a good idea to merge a second ov7670 driver as that's exactly what we are trying to avoid. Migrating soc-camera to the v4l2-device/v4l2-subdev framework is the right approach. Otherwise this issue will just crop up time and again. Although not good news for Jonathan, since his work will be delayed. Jonathan, to get an idea what all of this is about you should read the v4l2-framework.txt document in the master v4l-dvb repository (linuxtv.org/hg/v4l-dvb). It will give you the background information on the v4l2_subdev structure and associated API that we are migrating towards. And soc-camera happens to a framework that hasn't been converted yet. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: ov7670 soc-camera driver
On Sun, 15 Mar 2009, Jonathan Cameron wrote: > From: Jonathan Cameron > > OV7670 driver for soc-camera interfaces. Much appreciated, thanks! > > --- > There is already an ov7670 driver in tree, but it is very interface > specific (olpc) and hence not much use for the crossbow IMB400 board > which is plugged into an imote 2 pxa271 main board. > > Thanks go to Crossbow (www.xbow.com) for assistance in developing > this driver. > > This is my first driver related to v4l let alone soc-camera so this > is probably full of errors. All comments appreciated! > > A couple of questions related to this patch. > > Unfortunately the data ordering in rgb565 is not that expected by > the pxa271 which for reasons best known to someone else shuffles > the bit order coming off the camera. I don't know if this is a > common problem. I haven't been able to come up with a combination > of sensor and soc colour modes that will let this through. Anyone > else met a similar problem? At the moment I'm relying on > board specific documentation explaining how to rebuild the data > once an image has been captured, but obviously this is far from > ideal. > > The primary control on this chip related to shutter rate is actualy > the frame rate. There are rather complex (and largerly undocumented) > interactions between this setting and the auto brightness controls > etc. Anyone have any suggestions on a better way of specifying this? > > Clearly this driver shares considerable portions of code with > Jonathan Corbet's driver (in tree). It would be complex to combine > the two drivers, but perhaps people feel this would be worthwhile? Now, there we go... Hans, time for v4l2-device?... This means, I will look through the driver, but we should really think properly whether to pull it in now, or "just" convert the OLPC driver and soc-camera to v4l2-device and thus enable re-use. Thanks Guennadi > > Thanks, > > --- > > diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig > index 19cf3b8..646aab3 100644 > --- a/drivers/media/video/Kconfig > +++ b/drivers/media/video/Kconfig > @@ -779,6 +779,12 @@ config SOC_CAMERA_OV772X > help > This is a ov772x camera driver > > +config SOC_CAMERA_OV7670 > + tristate "ov7670 support with soc" > + depends on SOC_CAMERA && I2C > + help > + This is an ov7670 driver using the soc camera interface > + > config VIDEO_PXA27x > tristate "PXA27x Quick Capture Interface driver" > depends on VIDEO_DEV && PXA27x && SOC_CAMERA > diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile > index 72f6d03..ba70539 100644 > --- a/drivers/media/video/Makefile > +++ b/drivers/media/video/Makefile > @@ -142,6 +142,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o > obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o > obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o > obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o > +obj-$(CONFIG_SOC_CAMERA_OV7670) += ov7670_soc.o > obj-$(CONFIG_SOC_CAMERA_OV772X) += ov772x.o > obj-$(CONFIG_SOC_CAMERA_PLATFORM)+= soc_camera_platform.o > obj-$(CONFIG_SOC_CAMERA_TW9910) += tw9910.o > diff --git a/drivers/media/video/ov7670_soc.c > b/drivers/media/video/ov7670_soc.c > new file mode 100644 > index 000..63cbe3b > --- /dev/null > +++ b/drivers/media/video/ov7670_soc.c > @@ -0,0 +1,1150 @@ > +/* > + * A V4L2 driver for OmniVision OV7670 cameras via soc interface > + * > + * Copyright 2006 One Laptop Per Child Association, Inc. Written > + * by Jonathan Corbet with substantial inspiration from Mark > + * McClelland's ovcamchip code. > + * > + * Copyright 2006-7 Jonathan Corbet > + * > + * Copyright 2009 Jonathan Cameron > + * > + * This file may be distributed under the terms of the GNU General > + * Public License, version 2. > + * > + * Todo: Currently only VGA image resolution supported. > + * > + * Queries for review: > + * 1) Here I'm using brightness controls for what are effectively shutter > + * timings. How should this be done? > + */ > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +/* > + * Basic window sizes. These probably belong somewhere more globally > + * useful. > + */ > +#define VGA_WIDTH640 > +#define VGA_HEIGHT 480 > +#define QVGA_WIDTH 320 > +#define QVGA_HEIGHT 240 > +#define CIF_WIDTH352 > +#define CIF_HEIGHT 288 > +#define QCIF_WIDTH 176 > +#define QCIF_HEIGHT 144 > +#define MAX_WIDTH VGA_WIDTH > +#define MAX_HEIGHT VGA_HEIGHT > + > +/* Registers */ > +#define REG_GAIN0x00/* Gain lower 8 bits (rest in vref) */ > +#define REG_BLUE 0x01/* blue gain */ > +#define REG_RED 0x02/* red gain */ > +#define REG_VREF 0x03/* Pieces of GAIN, VSTART, VSTOP */ > +#define REG_COM1 0x04/* Control 1 */ > +#define COM1_CCIR
RFC: ov7670 soc-camera driver
From: Jonathan Cameron OV7670 driver for soc-camera interfaces. --- There is already an ov7670 driver in tree, but it is very interface specific (olpc) and hence not much use for the crossbow IMB400 board which is plugged into an imote 2 pxa271 main board. Thanks go to Crossbow (www.xbow.com) for assistance in developing this driver. This is my first driver related to v4l let alone soc-camera so this is probably full of errors. All comments appreciated! A couple of questions related to this patch. Unfortunately the data ordering in rgb565 is not that expected by the pxa271 which for reasons best known to someone else shuffles the bit order coming off the camera. I don't know if this is a common problem. I haven't been able to come up with a combination of sensor and soc colour modes that will let this through. Anyone else met a similar problem? At the moment I'm relying on board specific documentation explaining how to rebuild the data once an image has been captured, but obviously this is far from ideal. The primary control on this chip related to shutter rate is actualy the frame rate. There are rather complex (and largerly undocumented) interactions between this setting and the auto brightness controls etc. Anyone have any suggestions on a better way of specifying this? Clearly this driver shares considerable portions of code with Jonathan Corbet's driver (in tree). It would be complex to combine the two drivers, but perhaps people feel this would be worthwhile? Thanks, --- diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 19cf3b8..646aab3 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -779,6 +779,12 @@ config SOC_CAMERA_OV772X help This is a ov772x camera driver +config SOC_CAMERA_OV7670 + tristate "ov7670 support with soc" + depends on SOC_CAMERA && I2C + help + This is an ov7670 driver using the soc camera interface + config VIDEO_PXA27x tristate "PXA27x Quick Capture Interface driver" depends on VIDEO_DEV && PXA27x && SOC_CAMERA diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 72f6d03..ba70539 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -142,6 +142,7 @@ obj-$(CONFIG_SOC_CAMERA_MT9M001)+= mt9m001.o obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o +obj-$(CONFIG_SOC_CAMERA_OV7670)+= ov7670_soc.o obj-$(CONFIG_SOC_CAMERA_OV772X)+= ov772x.o obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o obj-$(CONFIG_SOC_CAMERA_TW9910)+= tw9910.o diff --git a/drivers/media/video/ov7670_soc.c b/drivers/media/video/ov7670_soc.c new file mode 100644 index 000..63cbe3b --- /dev/null +++ b/drivers/media/video/ov7670_soc.c @@ -0,0 +1,1150 @@ +/* + * A V4L2 driver for OmniVision OV7670 cameras via soc interface + * + * Copyright 2006 One Laptop Per Child Association, Inc. Written + * by Jonathan Corbet with substantial inspiration from Mark + * McClelland's ovcamchip code. + * + * Copyright 2006-7 Jonathan Corbet + * + * Copyright 2009 Jonathan Cameron + * + * This file may be distributed under the terms of the GNU General + * Public License, version 2. + * + * Todo: Currently only VGA image resolution supported. + * + * Queries for review: + * 1) Here I'm using brightness controls for what are effectively shutter + * timings. How should this be done? + */ +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +/* + * Basic window sizes. These probably belong somewhere more globally + * useful. + */ +#define VGA_WIDTH 640 +#define VGA_HEIGHT 480 +#define QVGA_WIDTH 320 +#define QVGA_HEIGHT240 +#define CIF_WIDTH 352 +#define CIF_HEIGHT 288 +#define QCIF_WIDTH 176 +#defineQCIF_HEIGHT 144 +#define MAX_WIDTH VGA_WIDTH +#define MAX_HEIGHT VGA_HEIGHT + +/* Registers */ +#defineREG_GAIN0x00/* Gain lower 8 bits (rest in vref) */ +#define REG_BLUE 0x01/* blue gain */ +#define REG_RED0x02/* red gain */ +#define REG_VREF 0x03/* Pieces of GAIN, VSTART, VSTOP */ +#define REG_COM1 0x04/* Control 1 */ +#defineCOM1_CCIR656 0x40 /* CCIR656 enable */ +#define REG_BAVE 0x05/* U/B Average level */ +#define REG_GbAVE 0x06/* Y/Gb Average level */ +#define REG_AECHH 0x07/* AEC MS 5 bits */ +#define REG_RAVE 0x08/* V/R Average level */ +#define REG_COM2 0x09/* Control 2 */ +#defineCOM2_SSLEEP 0x10 /* Soft sleep mode */ +#define REG_PID0x0a/* Product ID MSB */ +#define REG_VER0x0b/* Product ID LSB */ +#define REG_COM3 0x0c/* Control 3 */ +#de
