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
On Thu, Aug 29, 2024 at 11:34 AM 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:
>
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
On 8/28/2024 9:43 AM, raiden00pl wrote:
I don't know what was the initial intention about `drivers/`, only Greg can
answer this question.
All directories except for arch/ and board/ should have only generic
code that can be built with all all compilers and for any target. That
is true for almos
arch/drivers looks like a better idea than just drivers/
but arch/ contains one directory per architecture: arm x68 risc-v. and
drivers is not an arch.
drivers/arch/ could also be used.
Sebastien
On 28/08/2024 18:03, Lwazi Dube wrote:
On Wed, 28 Aug 2024 at 11:43, raiden00pl wrote:
I don
On Wed, 28 Aug 2024 at 11:43, raiden00pl wrote:
> I don't know what was the initial intention about `drivers/`, only Greg can
> answer this question.
> But what I see now is that `drivers/` implement `upper-half` drivers, and
> arch specific drivers implement "lower-half" drivers (there are proba
I don't know what was the initial intention about `drivers/`, only Greg can
answer this question.
But what I see now is that `drivers/` implement `upper-half` drivers, and
arch specific drivers implement "lower-half" drivers (there are probably a
few exceptions
to this rule).
For this reason, pollu
On Wed, 28 Aug 2024 at 09:21, raiden00pl wrote:
> As Alan said `drivers/` should remain independent from `arch`.
> The clean separation of arch from the rest of the code is one of the nicest
> things about NuttX and it should stay that way.
>
I won't argue against clean separation, but why does
As Alan said `drivers/` should remain independent from `arch`.
The clean separation of arch from the rest of the code is one of the nicest
things about NuttX and it should stay that way.
But the problem of reusing the same low-level driver code across different
arch implementations is an unsolved
Actually inside drivers/ are supposed to have only generic drivers (upper
half drivers that work with all chips).
Please don't use drivers/ for arch specific drivers, that is not the way
NuttX is supposed to be.
Today we don't have a simple way to share arch drivers, as you can see for
each stm32
Hi,
My personal opinion: use arch/arm/src/rp23xx and arch/risc-v/src/rp23xx
With shared drivers in drivers/rp23xx
And separate board configs for arm and riscv.
Not sure if nuttx wants to support an hybrid arm+riscv port as a single
build !
So there is no need to invent new dirs.
Sebastien
Galaxy
Original message From: Matteo Golin
Date: 8/26/24 4:19 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: Re:
RP2350 port Thanks for getting it working! I'd like to try out NuttX on the new
Picos,so I'm excited development has started so quickly!Not much advi
Thanks for getting it working! I'd like to try out NuttX on the new Picos,
so I'm excited development has started so quickly!
Not much advice for the other questions, but for number 2 maybe there could
just be a raspberry-pi-pico2 board and the selection between ARM and RISCV
is done via Kconfig?
13 matches
Mail list logo
