tmedicci commented on issue #15319: URL: https://github.com/apache/nuttx/issues/15319#issuecomment-2867167540
Then his code has been partially reused, but mostly replaced by Espressif pull request [#15079](https://github.com/apache/nuttx/pull/15079). Yes, we just keep adding more features to it. > I understand that you want to extended support to more chip variants etc. But it broke already working functionality and makes code much more complex with much higher and unnecessary overhead. There is a misunderstanding here: we didn't switch to the common-code approach. https://github.com/apache/nuttx/pull/13298/files from @Vajnar already used the common code. > As Martin reports, range is hard limited to -1000 to +1000 etc. I couldn't find any report of that. Any issue report should contain very detailed information on how to reproduce a bug. Everyone should be able to reproduce it and test it by themselves. If a commit or MR is pointed out as being responsible for introducing a bug, please provide test results before and after applying it. > I have even fear that there can be lose of the counts because counter seems to be reset between reads and returns accumulated in the QENC driver. This is very subjective. Can you provide testing results comparing it before and after applying [#15079](https://github.com/apache/nuttx/pull/15079)? Again, let's be very practical: claims of _this approach is better than that_ for existing code are very subjective. If there are bugs related to something we implemented (and were working before), we will try to fix them as soon as possible according to our backlog. Otherwise, we can't guarantee that any personal preferences will be implemented. -- 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: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
