RP2350 port part 2

[Marco Casaroli <ma...@midokura.com.INVALID>]

Hello again,

I have followed Greg's advice and put the files in arch/arm/rp23xx

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:

a. put the instructions how to download pico sdk and set PICO_SDK_PATH so
we can use the files from there
b. download the pico-sdk automatically in the Makefile and use it to build
c. copy the relevant files from pico-sdk to Nuttx tree

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)

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?

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

by the way, of anyone is interested in testing and helping there is my WIP
branch (very dirty for now) here it is:
https://github.com/casaroli/nuttx/tree/pico2

My next steps are to test SMP, UART1, SPI, I2C, ADC, DMA (that I can do
without other accessories).

Thank you.

Re: RP2350 port part 2

[mi...@bofc.pl]

On 2024-08-29 11:57:49, Marco Casaroli wrote:
> > > 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.
Not sure if full removal is good approach here. You did put some work into
it. It would be shame to waste it. I think I would just go on and create
separate pull request for them. You can also semi test things with logic
analyzer. SPI can be tested that way. With SPI you can also connect MOSI to MISO
and test communication that way. Once you confirm driver with bridging or
logic analyzer you can create driver marked as EXPERIMENTAL. This will be a
good indication that driver is somewhat working, but noone should expect
production quality code in there.

-- 
.-----------------.-------------------.----------------------.-----------------.
| 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 |
`----------------------^--------------^----------------------^-----------------'

Re: RP2350 port part 2

[Marco Casaroli <ma...@midokura.com.INVALID>]

On Thu, Aug 29, 2024 at 11:34 AM <mi...@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 |
>
> `----------------------^--------------^----------------------^-----------------'
>

Re: RP2350 port part 2

[mi...@bofc.pl]

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 |
`----------------------^--------------^----------------------^-----------------'