On 2024-08-29 11:17:06, Marco Casaroli wrote: > I have some more questions for you. I start a new email thread to not > generate noise in the previous discussion. > > 1. The RP port needs some hardware (include) files from pico-sdk. Should I: Nuttx does not include nor use any of the OEM SDK. This is double edge sword. It takes longer to implement driver, but those drivers are usually better fitted, better quality and less buggy than OEM drivers.
If these are only register definitions than you may be able to get away with this (if license permits it and by doing some reformating). Including code is probably a no go. > 2. (if answer to Q1 is option a, then), should I reformat the imported code > to match NuttX or I can just drop the files there without any > modifications? (they are BSD-licensed) Usually reformat won't cut it as you need to follow Nuttx specifi API. Second thing is maintaning that code. OEM code tries to handle all possible cases, so there are a lot of code. And drivers usually need only a small subset of features that is required for it to work. Not going for corner cases make code so much smaller and easier to maintaing. If you reformat OEM code, someone has to maintain it - and just copying updated file from OEM will not work. > > 3. Should I aim to make this port work on rp2040 (and rename it to rp2xxx) > - the drivers are very similar, or should I keep it separated and target > rp23xx only? Code deduplication is always good thing. Problem is that it's a lot of work to kickstart it. Because of that there are tons of duplicated code - especially for stm32, stm32wl5 and stm32wb. They are mostly the same, but are still duplicated. > > 4. How should I test the peripherals? I don't have all the LCD displays and > the other accessories supported by RP2040 port. Should I: > > a. keep the peripherals code for LCD, etc and hope that it will work > (explain in the documentation that it is not tested) > b. just add the minimum code without those peripherals support > c. buy the missing stuff or find other people to test it before I open the > PR Best is C of course :) but noone will expect from you to buy stuff to write the drivers - you do it only if you want to support project using not only your time but also money. So go B. It's better to not have things than have them half cooked in buggy state (I'm looking at you zephyr). -- .-----------------.-------------------.----------------------.-----------------. | Michal Lyszczek | Embedded C, Linux | Company Address | .-. opensource | | +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo| supporter | | https://bofc.pl `----.--------------: Brzezinka Sredzka PL | /`'\ & | | GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/) programer | `----------------------^--------------^----------------------^-----------------'
signature.asc
Description: PGP signature
