On Sat, Nov 29, 2025 at 2:28 PM <[email protected]> wrote: > > Hi, > > thanks for doing the split - my intention was to order the patches in > the series so it can be cut at any point to still produce correct > result. As in fixes first, then new features in order of likelyhood of > being merged. That way - I thought - would make it possible to simply > create some sort of "mergeable" branch up to and including the last > acceptable commit from the PR without causing more work for someone > else. Did not work, hopefully I'll remember to just split things as much > as possible/reasonable from the outset next time. (If not, you can > remind me to do that instead of doing the work yourself.)
No worries, thanks for adapting branches, I am leaving for a week son so maybe we can make it before end of weekend :-) All 3 updated branches pushed to GH :-) > As for the comments: > > - the coding style errors in avrdx_lowconsole.c and avrdx_init.c are > fixed. Turns out I forgot to checkpatch some files, sorry about that. > Updated branches are avrdx_twi_rfc1-4 and avrdx_twi_rfc1-2. To be sure, > I scanned the series as a whole now and it should hopefully be > everything. Some more typos caught: https://github.com/apache/nuttx/actions/runs/19786767210/job/56694309909?pr=17404 ../nuttx/tools/checkpatch.sh -c -u -m -g 48585b21b5b045541032b02dcea21e1240360ffa..HEAD Used config files: 1: .codespellrc /home/runner/work/nuttx/nuttx/nuttx/Documentation/platforms/avr/avrdx/docs/twi.rst:48: mesages ==> messages /home/runner/work/nuttx/nuttx/nuttx/arch/avr/src/avrdx/Kconfig:417: accross ==> across /home/runner/work/nuttx/nuttx/nuttx/arch/avr/src/avrdx/Kconfig:485: accross ==> across /home/runner/work/nuttx/nuttx/nuttx/arch/avr/src/avrdx/avrdx_twi.c:1352: overriden ==> overridden I fixed them already lets see the CI status now :-) > - the TC74Ax driver not being uORB - well, I was not sure whether to > submit the driver at all exactly because it is not done the new way. But > then I noticed another such driver was merged in August so I posted it. > As for the reasons why the driver is not done the new way, there are > two: > > First - I did not read the documentation. Over my previous submissions, > I was never able to find any howto for writing drivers. As in "if you > want to make driver for X, do this." (Do not take this as a criticism > please, I was thinking about writing such howto but every time I was > done with a feature, it seemed to me that there is actually nothing to > write about because everything is simple, clear and pretty obvious.) So > I got into the habit of simply looking at other code that does the same > thing and adapting it. Only after the driver was almost done, I found > the documents you linked. > > The other reason - and the reason why I did not decide to rewrite the > driver - is that unless I misunderstood the documentation, the new way > uses floats to exchange data and seems more complex overall. My intended > use case is currently 8-bit AVR and I am even not able to compile code > that has floats in it. (That can be probably fixed easily by upgrading > to newer gcc.) Moreover, floats are expensive to handle. So to put it > simple, if I did the driver this way, it would not be of much use to me. > > All in all, if the driver gets rejected because it uses deprecated > interface, that would be completely understandable from my point of > view. However, I have to say that I am not planning to rewrite it in any > forseeable future (maybe if it proved easy to have it configurable for > both interfaces - judging from bmp180 driver it could be - but I don't > think I'll find the time even in such case.) > > - the enum in the TC74Ax driver - changed to > TC74AX_OPERATION_MODE_STANDBY/OPERATING. As usual, this was based on > another driver. Fixed version is in avrdx_twi_rfc1-3 branch. > > Let me know if I missed anything. Raiden already reaised an issue on GH about floats in uORG and there is a proposition to use fixed point built time alternative, please take a look here: https://github.com/apache/nuttx/issues/10644 I will start a mailing list discussion in a moment this seems important :-) Thanks! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
