On Thu, Aug 29, 2024 at 11:34 AM <michal.lyszc...@bofc.pl> wrote: > 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. >
Thank you for the clarification. These are not drivers. The driver are indeed part of the port. These files are just register definitions and structs, so only .h files, not .c. I could generate it with SVDConv, or just copy the already generated code from their sdk. Should I reformat the generated code? (I am talking about this code: https://github.com/apache/nuttx/tree/master/arch/arm/src/rp2040/hardware) > > > 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. > > As in question 1, the drivers are in the NuttX port and not imported by the SDK > > > > 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. > > I will ignore RP2040 for now. > > > > 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). > I will remove the code for stuff I cannot test right now. Thank you. > > -- > > .-----------------.-------------------.----------------------.-----------------. > | 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 | > > `----------------------^--------------^----------------------^-----------------' >
