raiden00pl commented on PR #10077: URL: https://github.com/apache/nuttx/pull/10077#issuecomment-1683443643
> It's fine with sample rate around 1KHz. Good to know. Could you reveal the CPU freq? I guess uorb is not a problem for powerful processors, but with limited resources character device seems more reasonable. > could you give more examples except sensor? at least, analog, audio, crypto, efuse, input, ioexpander, lcd, leds, math, mmcsd, motor, mtd, net, battery, rc, rptun, serial, timer, video follow the You can just `grep -R file_operations drivers/` and filter out all `upper-half` logic implementation. Most of it is sensors, but quite a few drivers from what you listed are there as well. To be honest, I didn't count which approach is more popular, but it doesn't matter much. I want to show that the division into upper/lower is not the norm for I2C/SPI based drivers. > Nobody forces user to use uorb, both interfaces keep in this patch. But we don't have enough resource to improve the raw driver interface which we don't use, so it's better to decouple both implementations. I completely understand that you aren't interested in developing the old approach and that's ok. But from the initial look of this PR and discussion here, I got the impression that you'd want to get rid of the old sensors approach. So I'm hoping that's not the case, at least without much open discussion. Two separate sensor implementations will duplicate a lot of code. If you don't want to separate some common logic between implementations for the sensor, you can at least move the register definitions to a common private header for bmi160.c and bmi160_uorb.c -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
