On 04/11, Jonathan Cameron wrote: > On Sun, 10 Apr 2022 19:37:52 -0300 > Maíra Canal <maira.canal@xxxxxx> wrote: > > > On 04/10, Jonathan Cameron wrote: > > > On Thu, 7 Apr 2022 00:23:29 -0300 > > > Maíra Canal <maira.canal@xxxxxx> wrote: > > > > > > > Hi everyone, I am Maíra Canal an undergrad student at the University > > > > of São Paulo, Brazil, pursuing > > > > computer engineering. I wish to participate in the GSoC 2021 as a part > > > > of the Linux Foundation, IIO Project. > > > > > > Hi Maíra, > > > > > > Nice to 'meet' you ;) > > > > > > > > > > > I have been contributing to the Linux kernel for a couple of months > > > > and have more than 20 > > > > accepted patches in a couple of subsystems. > > > > > > > > I started looking through the catalog of Analog Devices Inc. and I'm > > > > pretty interested in writing a driver for gyroscopes, inertial > > > > measurement units (IMUs), magnetometers, pressure sensors, proximity > > > > sensors, or temperature sensors. But, while looking through the > > > > catalog, I could not figure out a sensor that would be relevant to > > > > Linux Kernel. I mean, I would like to work on a sensor that would be > > > > relevant to the community and to Analog Devices Inc. > > > > > > > > In that sense, I would like to know if anyone in the IIO community > > > > could recommend a sensor that would make sense for the company and the > > > > IIO community. Any suggestion is appreciated! > > > > > > I'm not going to recommend a particular sensor, but more offer some general > > > tips on what 'sort' of device makes a good target for a GSOC. > > > Finding a sensor means trawling datasheets and I'm tight on time today > > > + I've no real insight into what the ADI folk might like to see > > > supported! > > > > > > The nature of a GSOC driver submission is often a little different to > > > how an experienced driver author might go about things, simply because you > > > will / should be looking for feedback at more stages of development and > > > hopefully to upstream things in multiple stages. An old hand at IIO > > > drivers will often just jump directly to a driver supporting all the > > > features they wish to target. As such, the 'perfect' device to target > > > should meet a few requirements that may not be true for the approach of jumping > > > straight to the end goal. Note this is equally true for other people > > > starting out writing drivers - though they can often do very simple > > > devices first and that is not a good plan for a GSOC project where > > > you need to have a progression during the project. > > > > > > Try to find something that offers some advanced features to provide > > > stretch goals but make sure the basic functionality will work with > > > a much simpler driver. So devices that provide straight forward > > > registers to access the latest channel value are great, whereas > > > those that only offer a streaming interfaces / fifo may be less suitable. > > > However if they offer both that is perfect as the fifo make a good > > > later feature for a GSOC project if things are going particularly > > > well! For a real stretch goal, find a device with features that > > > we don't support at all today (perhaps new sensor types, or some > > > other new feature) as they'll give you the experience of defining > > > new ABI + possibly modifying the IIO core to meet some requirements. > > > > > > Another thing to look at it is whether the part is sufficiently > > > different from those supported by existing drivers to justify a > > > separate driver. If not, you may find your GSOC project becomes > > > simply adding an ID! (then rapidly choosing a second device to > > > work on). > > > > > > Hope that provides a few hints on what to look at. Probably the best > > > way around is to suggest one or more parts you think look interesting > > > then we can give feedback on whether we think they'd be a good choice > > > or not. > > > > Hi Jonathan, > > > > I really appreciate the answer. Thank you for your attention and time! > > > > During the week, I ended up picking the ADXL375 accelerometer (although I am > > open to any change proposed by ADI or the IIO community). Based on that device, > > I wrote a proposal and I would appreciate if you provide some feedback on the > > device choice and proposal: https://pt.overleaf.com/read/xsmmdpvzqrhd. > > Unfortunately that part hits the second to last paragraph above. > > It's so nearly compatible with the ADXL345 that the driver already supports it: > https://elixir.bootlin.com/linux/v5.18-rc1/source/drivers/iio/accel/adxl345_i2c.c#L42 > This is very common for these types of devices as there are often many similar > variants, usually with different ranges or with small additional features, or numbers > of interrupt pins etc. Another fun one is parts with ratings for different applications > but identical software interfaces being given different part numbers. > I think in this case the two parts have different scaling, but are otherwise > identical. > > So probably need to find another part. Hi, Jonathan I took another look at the Analog Devices Inc. catalog and choose another couple of options: - ADPD188BI and ADPD410x: are optical devices based on SPI/I2C. I guess they might be too bold for a GSoC project. - MAX31875: is a Temperature Sensor based on I2C. Different than the optical devices, this one might be too simple. - LTC2499: is a multiplexed ADC sensor. For now, it is my best option. If possible, I would like to get your input on those options. Sincerely, Maíra > > Jonathan > > > > > Regards, > > Maíra > > > > > > > > Good luck! > > > > > > Jonathan > > > > > > > > > > > > > > > > > Sincerely, > > > > Maíra Canal > > > >
