Re: Introduction + incoming RISC-V port(s)

[Grr]

El mar, 3 ago 2021 a las 6:49, Alan Carvalho de Assis ()
escribió:

> Unfortunately NuttX is not for faint of heart people (same to the
> Linux kernel)

I don't know about Linux but what makes NuttX not for the faint of heart is
you, the core programmers. I explain why:

*Config Nightmare*
NuttX menuconfig is a minefield. The first time I tried to test NuttX,
selecting desired options caused a compilation crash because there are a
lot of broken combinations (I fixed 4 or 5 to flex my muscles), especially
regarding networking. When I *repeatedly* talked about making it easier for
newbies, nobody even blinked and when I came with a GPIO subsystem that
allows easy configuration via menuconfig, you showed complete lack of
interest

*Balkanization*
Device support in NuttX is ludicrous. If I want to connect an SPI device
like MCP2515 to a *supported random board*, I have to port the driver
because the existing driver is tied to Blue Pill and one or two other
boards. As anyone understands, a supported SPI peripheral *should* work
with *any* supported board because a driver should work at bus level, *not*
board level. If I'm a newbie that doesn't want or can go that deep, I'm SOL

*Double Standards*
I tried to correct the situation and developed a new SPI subsystem that
doesn't tie drivers to a specific board, just to clash into header file
mess: with the excuse of modularity, header files are mixed with source
files, making it very difficult (I suspect on purpose) to build a
board-agnostic driver system

Of course, modularity is something for *others* to observe. The leader can
enforce modularity and at the same time recommend to use internal
interfaces when needed (
https://www.mail-archive.com/dev@nuttx.apache.org/msg05752.html)

*Networking Phobia*
Back in 2015, I asked about SocketCAN on NuttX (
https://nuttx.yahoogroups.narkive.com/RMKDgEcn/canopen-stack) but Nutt
didn't want to even hear about it and *ERASED MY QUESTIONS FROM NEWSGROUP*.
Five years later, Nutt was deploring that SocketCAN port to NuttX was
rusting in a branch. And this schizophrenic attitude towards networking
shows in NuttX

In sum, it's not that NuttX is hard. It's that *NuttX IS MADE HARD,
PROBABLY ON PURPOSE*

In that scenario, Robert's position is perfectly understandable and even
advisable. I myself will follow suit and go to a better RTOS, where I don't
have to fight against everything to get the work done. I've wasted enough
time

Good bye


> I know you are not an stupid guy and you have great
> projects under your belt, but think also about your attitudes here.
> Read again all the complains you did in your emails and imagine the
> other side of your computer are few guys that spend years of their
> life making that code.
>
> BR,
>
> Alan
>
> On 8/3/21, Robert Lipe  wrote:
> > This iteration of BeagleV hardware is canceled .
> > Given the friction of landing PR#3965, I'm just going to abandon it and
> > mark that CL closed and will be unsubscribing from the lists.  There's
> > probably nothing worth heroic efforts to preserve; only a few of those
> 108
> > commits were real work with the rest just feeding the machine. That basic
> > PR will be needed by the likes of  SiFive Unmatched and other RISC-V
> > hardware.
> >
> > The NuttX tech is interesting, but I spent an unreasonable amount of time
> > chasing ghosts in the build system and the culture. A style guide that's
> so
> > complex that you can't teach it to a machine and blocking submits because
> > unrelated files have C99 comments inside an embedded string is just not a
> > fit for me.
> >
> > Thanx to those of you that genuinely tried to help onboard a new dev.
> Good
> > luck to the project on your journey to be accepted by Apache.
> >
> > RJL
> >
> > On Wed, Jun 23, 2021 at 10:03 AM Abdelatif Guettouche <
> > abdelatif.guettou...@gmail.com> wrote:
> >
> >> *So I've kicked that back in, but it appears I have to wait for a
> >> (gasp)human**to push a button*.
> >>
> >> This is actually a Github thing and is outside of our control.  It's
> >> pretty
> >> new too, so we too have to get used to it.  As Nathan said, this only
> >> applies to first time contributors.  Subsequent contributions should go
> a
> >> bit smoother.
> >>
> >> On Wed, Jun 23, 2021, 3:37 PM Nathan Hartman 
> >> wrote:
> >>
> >> > On Tue, Jun 22, 2021 at 11:12 PM Robert Lipe 
> >> wrote:
> >> >
> >> > > >
> >> > > >
> >> > > > > The presubmit flips out about C99 comments. Even that's too
> >> radical.
> >> > So
> >> > > > > much for being king. :-)
> >> > > >
> >> > > > You can use C99, but you cannot forgot to follow the Coding Style,
> >> > > > //
> >> > > > comments shouldn't be used :-)
> >> > > >
> >> > >
> >> > > It's actually worse than that. You can use C99 comments at the end
> of
> >> > > a
> >> > > line
> >> > > but not at the beginning
> >> > >
> >> > > frobnicate();  // this is accepted
> >> > > // this is an error
> >> >
> >> >
> >> > That is a bug in nxstyle.c and sho

Re: ESP8266 support

[Grr]

There's a protocol to use SPI as network link, which obviously has much
bigger bandwidth and potential

If you're not in a hurry to implement the solution and are interested in
developing a better one, count me in

El jue., 3 de jun. de 2021 9:02 AM, Flavio Castro Alves Filho <
flavio.al...@gmail.com> escribió:

> Hello,
>
> I am using UART.
>
>
> Em qui., 3 de jun. de 2021 às 10:44, Grr  escreveu:
> >
> > What physical link will you use to connect 8266 and main board?
> >
> > Your project is very interesting and opens a lot of potential for
> > inexpensive distributed control
> >
> > El jue., 3 de jun. de 2021 8:27 AM, Flavio Castro Alves Filho <
> > flavio.al...@gmail.com> escribió:
> >
> > > Hello,
> > >
> > > I am working on the integration between a STM32F4Discovery based board
> > > to a ESP8266-WROOM-2 module, in order to have WiFi connectivity.
> > >
> > > My plan is to implement a thread using USRSOCK and the ESP8266
> > > functions available in netutils, using as reference the work
> > > previously done with GS2200m.
> > >
> > > Looking at NuttX source code, I couldn't find any example of an
> > > application that implements the ESP8266 functions. Is there any place
> > > where I can find reference for this use?
> > >
> > > Best regards,
> > >
> > > Flavio
> > >
> > > --
> > > Flavio de Castro Alves Filho
> > >
> > > flavio.al...@gmail.com
> > > Twitter: http://twitter.com/#!/fraviofii
> > > LinkedIn profile: www.linkedin.com/in/flaviocastroalves
> > >
>
>
>
> --
> Flavio de Castro Alves Filho
>
> flavio.al...@gmail.com
> Twitter: http://twitter.com/#!/fraviofii
> LinkedIn profile: www.linkedin.com/in/flaviocastroalves
>

Re: ESP8266 support

[Grr]

What physical link will you use to connect 8266 and main board?

Your project is very interesting and opens a lot of potential for
inexpensive distributed control

El jue., 3 de jun. de 2021 8:27 AM, Flavio Castro Alves Filho <
flavio.al...@gmail.com> escribió:

> Hello,
>
> I am working on the integration between a STM32F4Discovery based board
> to a ESP8266-WROOM-2 module, in order to have WiFi connectivity.
>
> My plan is to implement a thread using USRSOCK and the ESP8266
> functions available in netutils, using as reference the work
> previously done with GS2200m.
>
> Looking at NuttX source code, I couldn't find any example of an
> application that implements the ESP8266 functions. Is there any place
> where I can find reference for this use?
>
> Best regards,
>
> Flavio
>
> --
> Flavio de Castro Alves Filho
>
> flavio.al...@gmail.com
> Twitter: http://twitter.com/#!/fraviofii
> LinkedIn profile: www.linkedin.com/in/flaviocastroalves
>

Re: CAN example crashes

[Grr]

>
> Are we still talking about apps/examples/can?


No, we're talking now about Disruptive Solutions' setup as he described it
in the message before my question

apps/examples/can is a
> low-level driver test that does not use any intervening protocol and
> only operates in loopback mode.  It just verifies the loopback in its
> "normal" configuration...  What comes in must be the same as what was
> sent out... but can be used in non-loopback mode with reduced
> functionality.
>

Re: CAN example crashes

[Grr]

No, I mean on top of that: CANopen, UAVCAN, other?

El sáb., 8 de may. de 2021 12:44 PM, 
escribió:

> You mean CAN FD or the CAN V2.0B? I use the standard with Extended ID's.
> (MCP2515 / SPI) for automotive interaction.
>
>
> https://ww1.microchip.com/downloads/en/DeviceDoc/MCP2515-Stand-Alone-CAN-Controller-with-SPI-20001801J.pdf
>
> Ben
>
> -Oorspronkelijk bericht-
> Van: Grr 
> Verzonden: zaterdag 8 mei 2021 19:09
> Aan: dev@nuttx.apache.org
> Onderwerp: Re: CAN example crashes
>
> Hello.
>
> What protocol do you use on top of CAN?
>
> El sáb., 8 de may. de 2021 12:03 PM, Disruptive Solutions <
> disruptivesolution...@gmail.com> escribió:
>
> > I use the CAN solution from NuttX with the SPI MCP2515. Made my own
> > referenceboard for it. Is doing miliions of messages with multiple nodes.
> > Works like a charm!
> >
> > Ben
> >
> > Op za 8 mei 2021 6:30 p.m. schreef murat tologlu :
> >
> > > Thanks for all the answers. I look forward to try Alan's next
> > > tutorial :) BR,
> > >
> > > On 2021/05/08 16:24:51, Tim Hardisty  wrote:
> > > > >> Is there any description somewhere about this example ?
> > > > >>
> > > > >There is some in apps/examples/README.md, but not a lot of info.
> > > >
> > > > Not much, no, but the example code is pretty self-explanatory!
> > > >
> > > >
> > > >
> > >
> >
>
>

Re: CAN example crashes

[Grr]

Hello.

What protocol do you use on top of CAN?

El sáb., 8 de may. de 2021 12:03 PM, Disruptive Solutions <
disruptivesolution...@gmail.com> escribió:

> I use the CAN solution from NuttX with the SPI MCP2515. Made my own
> referenceboard for it. Is doing miliions of messages with multiple nodes.
> Works like a charm!
>
> Ben
>
> Op za 8 mei 2021 6:30 p.m. schreef murat tologlu :
>
> > Thanks for all the answers. I look forward to try Alan's next tutorial :)
> > BR,
> >
> > On 2021/05/08 16:24:51, Tim Hardisty  wrote:
> > > >> Is there any description somewhere about this example ?
> > > >>
> > > >There is some in apps/examples/README.md, but not a lot of info.
> > >
> > > Not much, no, but the example code is pretty self-explanatory!
> > >
> > >
> > >
> >
>

Re: STM32 EXTI context

[Grr]

Thank you very much for your explanation. I didn't check irq_attach() in
depth and didn't discover what you mention

I've found
https://cwiki.apache.org/confluence/display/NUTTX/High+Performance%2C+Zero+Latency+Interrupts.
It seems a good start for that subject


El mié, 21 abr 2021 a las 9:30, Nathan Hartman ()
escribió:

> On Wed, Apr 21, 2021 at 9:03 AM Grr  wrote:
> >
> > Hello to all.
> >
> > I was studying EXTI handling in STM32 and noticed irq handlers (as
> defined
> > in stm32_exti_gpio.c) have three parameters: irq, context and arg.
> >
> > And they are never used
> >
> > If handlers are looked up in the vector table, which only have handler's
> > address, where do these parameters (specially context) come from?
> >
> > TIA
> > Grr
>
> Unless you are using Zero Latency Interrupts, ALL interrupt vectors
> point to one interrupt handler. The IRQ handlers you were looking at
> are called from within the single interrupt handler. See
> irq_dispatch() in sched/irq/irq_dispatch.c to see where the 'context'
> parameter comes from.
>
> Cheers,
> Nathan
>

STM32 EXTI context

[Grr]

Hello to all.

I was studying EXTI handling in STM32 and noticed irq handlers (as defined
in stm32_exti_gpio.c) have three parameters: irq, context and arg.

And they are never used

If handlers are looked up in the vector table, which only have handler's
address, where do these parameters (specially context) come from?

TIA
Grr

Re: Sleep Resolution

[Grr]

> 1nsec means 1GHz, it is very hard to achieve the required accuracy even
> with the high end CPU. But since the standard defines nano_sleep, up_ndelay
> looks not so unreasonable.
>

I don't mean 1 ns

I mean delays in the order of _dozens_ of ns

100 MHz (a very reasonable frequency nowadays) means 10 ns per cycle, so a
standard function that eases the task of delaying a few cycles for things
like hold times is a _very_ needed tool


> > El mié, 24 mar 2021 a las 22:34, Xiang Xiao ( >)
> > escribió:
> >
> > > Another way to avoid the calibration is to reuse the hardware timer in
> > the
> > > busy loop:
> > >
> > >
> >
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_alarm.c#L60-L74
> > >
> > >
> >
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_timer.c#L122-L144
> > >
> > > On Thu, Mar 25, 2021 at 11:42 AM Gregory Nutt 
> > wrote:
> > >
> > > >
> > > > > Why not call up_udelay or up_mdelay? The arch/soc should provide a
> > best
> > > > > implementation for you.
> > > >
> > > > I was wondering that too.
> > > >
> > > > Also, as a side note, it is very important to calibrate the delay
> loop
> > > > using in those functions.  If the delay loop is properly calibrated,
> > > > these can be very accurate (but I suspect most people no longer
> > > > calibrate the delay loop).
> > > >
> > > > There is an app at apps/examples/calib_udelay that can be used to do
> > > that.
> > > >
> > > >
> > >
> >
>

Re: Sleep Resolution

[Grr]

Why not use msec & usec delays?

Because the need is nsec delays

My question is:

Why not add a portable, general purpose nsec delay function to Nuttx?

El mié, 24 mar 2021 a las 22:34, Xiang Xiao ()
escribió:

> Another way to avoid the calibration is to reuse the hardware timer in the
> busy loop:
>
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_alarm.c#L60-L74
>
> https://github.com/apache/incubator-nuttx/blob/master/drivers/timers/arch_timer.c#L122-L144
>
> On Thu, Mar 25, 2021 at 11:42 AM Gregory Nutt  wrote:
>
> >
> > > Why not call up_udelay or up_mdelay? The arch/soc should provide a best
> > > implementation for you.
> >
> > I was wondering that too.
> >
> > Also, as a side note, it is very important to calibrate the delay loop
> > using in those functions.  If the delay loop is properly calibrated,
> > these can be very accurate (but I suspect most people no longer
> > calibrate the delay loop).
> >
> > There is an app at apps/examples/calib_udelay that can be used to do
> that.
> >
> >
>

Re: Sleep Resolution

[Grr]

for(delay = 0; delay < transfer->dev->afterstart; delay++);

afterstart is loop's limit, which determines the desired delay length,
known by definition

El mié, 24 mar 2021 a las 14:57, Johnny Billquist ()
escribió:

> Well. There was nothing in there that showed me that afterstart == 0. Is
> this a known fact, or an assumption?
>
>Johnny
>
> On 2021-03-24 21:47, Grr wrote:
> > Since afterstart = 0, there should be no loop to optimize out except ONE
> > value test
> >
> > One hundred cycles for that would seem excessive for me
> >
> > TWENTY THOUSAND CYCLES for a _zero_ loop?!?
> >
> > Maybe in Java
> >
> >
> >
> > El mié, 24 mar 2021 a las 14:30, Gregory Nutt ()
> > escribió:
> >
> >>
> >>> Weird behavior:
> >>>
> >>> Simply changing loop counter variable from uint16_t to volatile
> uint16_t
> >>> causes initial delay (with variable delay = 0) going from ~500 ns to
> >> ~120 us
> >>>
> >>> The code is
> >>>
> >>> uint16_t delay;
> >>>
> >>> select_function();
> >>> for(delay = 0; delay < transfer->dev->afterstart; delay++);
> >>>
> >>> Any ideas?
> >>>
> >> I imagine that the delay loop is no longer being optimized out. That is
> >> what volatile is supposed to do (people often don't understand that, it
> >> is a great interview question).
> >>
> >
>
> --
> Johnny Billquist  || "I'm on a bus
>||  on a psychedelic trip
> email: b...@softjar.se ||  Reading murder books
> pdp is alive! ||  tryin' to stay hip" - B. Idol
>

Re: Sleep Resolution

[Grr]

Since afterstart = 0, there should be no loop to optimize out except ONE
value test

One hundred cycles for that would seem excessive for me

TWENTY THOUSAND CYCLES for a _zero_ loop?!?

Maybe in Java



El mié, 24 mar 2021 a las 14:30, Gregory Nutt ()
escribió:

>
> > Weird behavior:
> >
> > Simply changing loop counter variable from uint16_t to volatile uint16_t
> > causes initial delay (with variable delay = 0) going from ~500 ns to
> ~120 us
> >
> > The code is
> >
> > uint16_t delay;
> >
> > select_function();
> > for(delay = 0; delay < transfer->dev->afterstart; delay++);
> >
> > Any ideas?
> >
> I imagine that the delay loop is no longer being optimized out. That is
> what volatile is supposed to do (people often don't understand that, it
> is a great interview question).
>

Re: Sleep Resolution

[Grr]

Weird behavior:

Simply changing loop counter variable from uint16_t to volatile uint16_t
causes initial delay (with variable delay = 0) going from ~500 ns to ~120 us

The code is

uint16_t delay;

select_function();
for(delay = 0; delay < transfer->dev->afterstart; delay++);

Any ideas?

El mié, 24 mar 2021 a las 12:21, Gregory Nutt ()
escribió:

>
> > What I'm trying to do is to generate hold and disable times for SPI CS,
> > which should be about 50 ns
> That resolution is too high for any system timer.
> > I started by an empty for loop but it seems optimization gets rid of it
> (I
> > haven't researched the issue properly). Then I thought a proper function
> > would be better but got stuck in that expression "sleep resolution"
>
> Add volatile to the loop counter variable and the optimizer will not
> remove it.
>
>
>

Re: Sleep Resolution

[Grr]

This is a SocketCAN driver for MCP2515 with a new SPI system that
streamlines the select->write->read->deselect process and so exposes the
need to guarantee hold time between read and deselect and disable time
between deselect and next select

Looking at David's code, it seems the loop is the right answer. The DWT
cannot be used for a portable solution but maybe an inline function. Thanks
for the idea

I believe NOPs are optimized away but it seems asm("") or something close
to that is not

It would be nice to incorporate a general solution for this problem to the
Nuttx toolbox

El mié, 24 mar 2021 a las 11:24, David Sidrane ()
escribió:

> What HW is this on?
>
> -----Original Message-
> From: Grr [mailto:gebbe...@gmail.com]
> Sent: Wednesday, March 24, 2021 10:09 AM
> To: dev@nuttx.apache.org
> Subject: Re: Sleep Resolution
>
> Thank you very much for your response
>
> What I'm trying to do is to generate hold and disable times for SPI CS,
> which should be about 50 ns
>
> I started by an empty for loop but it seems optimization gets rid of it (I
> haven't researched the issue properly). Then I thought a proper function
> would be better but got stuck in that expression "sleep resolution"
>
> For that scale (10 SYSCLK cycles), a loop is probably OK but I wanted to
> make sure there's not a more appropriate system tool
>
> El mié, 24 mar 2021 a las 10:46, Sara da Cunha Monteiro de Souza (<
> saramonteirosouz...@gmail.com>) escribió:
>
> > Hi Grr,
> >
> > I have never needed to use this function neither this range (ns).
> > But I used the usleep function which resolution is defined as
> > CONFIG_USEC_PER_TICK.
> > But maybe, in your case, for such range, you should consider using a
> > hardware timer or a Timer Hook.
> > Take a look at this wiki:
> > https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays
> >
> > Sara
> >
> > Em qua., 24 de mar. de 2021 às 13:37, Grr  escreveu:
> >
> > > Hello to all.
> > >
> > > Looking for the right way to create a _very_ short delay (10-100 ns), I
> > > found clock_nanosleep, whose description says:
> > >
> > > "The suspension time caused by this function may be longer than
> > > requested
> > > because the argument value is rounded up to an integer multiple of the
> > > sleep resolution"
> > >
> > > What is the sleep resolution and where/how is defined?
> > >
> > > TIA
> > > Grr
> > >
> >
>

Re: Sleep Resolution

[Grr]

Thank you very much for your response

What I'm trying to do is to generate hold and disable times for SPI CS,
which should be about 50 ns

I started by an empty for loop but it seems optimization gets rid of it (I
haven't researched the issue properly). Then I thought a proper function
would be better but got stuck in that expression "sleep resolution"

For that scale (10 SYSCLK cycles), a loop is probably OK but I wanted to
make sure there's not a more appropriate system tool

El mié, 24 mar 2021 a las 10:46, Sara da Cunha Monteiro de Souza (<
saramonteirosouz...@gmail.com>) escribió:

> Hi Grr,
>
> I have never needed to use this function neither this range (ns).
> But I used the usleep function which resolution is defined as
> CONFIG_USEC_PER_TICK.
> But maybe, in your case, for such range, you should consider using a
> hardware timer or a Timer Hook.
> Take a look at this wiki:
> https://cwiki.apache.org/confluence/display/NUTTX/Short+Time+Delays
>
> Sara
>
> Em qua., 24 de mar. de 2021 às 13:37, Grr  escreveu:
>
> > Hello to all.
> >
> > Looking for the right way to create a _very_ short delay (10-100 ns), I
> > found clock_nanosleep, whose description says:
> >
> > "The suspension time caused by this function may be longer than requested
> > because the argument value is rounded up to an integer multiple of the
> > sleep resolution"
> >
> > What is the sleep resolution and where/how is defined?
> >
> > TIA
> > Grr
> >
>

Sleep Resolution

[Grr]

Hello to all.

Looking for the right way to create a _very_ short delay (10-100 ns), I
found clock_nanosleep, whose description says:

"The suspension time caused by this function may be longer than requested
because the argument value is rounded up to an integer multiple of the
sleep resolution"

What is the sleep resolution and where/how is defined?

TIA
Grr

Re: Board-level Ethernet PHY operations in STM32.

[Grr]

psock_/file_ API is public API for kernel space component, not internal to
> socket/file subsystem.
>

I was referring to what Gregory Nutt said, which was

" It would be best to use the internal OS socket interfaces directly"


> SPI peripheral driver(e.g. sensor) should call SPI_SELECT to control the
> chip select, it's the responsibility of SPI bus driver(spi_dev_s/spi_ops_s)
> to do the real action:
> 1.Control the SPI hardware register to change CS signal
> 2.Or control the GPIO hardware register
>

The reference to SPI involves a number of implications from a previous
discussion about the SPI subsystem:

1-Several peripherals in a bus, which force to use GPIOs as CSs
2-SPI bus drivers which work independent of peripheral drivers
3-SPI peripheral drivers which are _not_ limited to one peripheral and
hardwired to one board
4-In such situation, the need to have a better, more general control for
GPIOs than what ioexpander can offer without practically redoing it anyways

That list pose a number of fundamental changes to several current systems,
which is what I'm referring to

>
> > El sáb, 20 feb 2021 a las 12:30, Gregory Nutt ()
> > escribió:
> >
> > >
> > > > I suggested using file_open() and file_ioctl() in a previous email.
> > > > That is wrong.  file_ioctl() cannot be used to access
> > > > socket_ioctls().  You would have to use psock_ioctl().
> > >
> > > Because the socket interface goes though the network, there are some
> > > hand shakes and interlocks to prevent network activity while accessing
> > > the PHY interface.   I think using a custom interface would be
> > > problematic.  It would be best to use the internal OS socket
> > > interfaces directly.  They prototyped and described in
> include/nuttx/net/net.h.
> > > For example, instead of using socket() you would use psock_socket(),
> > > instead of using bind(), you would use psock_bind(), instead of using
> > > ioctl(), you would use psock_ioctl().
> > >
> > > The APIs are the same as the user space APIs exception that:  (1) the
> > > are prefaced with psock_ and (2) the do not use an int socket
> > > descriptor. Rather, they use a pointer to the internal socket
> > > structure struct socket *
> > >
> > >
> > >
> > >
>
>

Re: Board-level Ethernet PHY operations in STM32.

[Grr]

When is using internal OS interfaces from another OS subsystem (or an app)
OK and not modularity rape?

For example (and following my development line), if a SPI peripheral driver
needs to access GPIO data structure in order to control chip select, is it
more problematic than an app talking directly to a PHY or less?

El sáb, 20 feb 2021 a las 12:30, Gregory Nutt ()
escribió:

>
> > I suggested using file_open() and file_ioctl() in a previous email.
> > That is wrong.  file_ioctl() cannot be used to access
> > socket_ioctls().  You would have to use psock_ioctl().
>
> Because the socket interface goes though the network, there are some
> hand shakes and interlocks to prevent network activity while accessing
> the PHY interface.   I think using a custom interface would be
> problematic.  It would be best to use the internal OS socket interfaces
> directly.  They prototyped and described in include/nuttx/net/net.h.
> For example, instead of using socket() you would use psock_socket(),
> instead of using bind(), you would use psock_bind(), instead of using
> ioctl(), you would use psock_ioctl().
>
> The APIs are the same as the user space APIs exception that:  (1) the
> are prefaced with psock_ and (2) the do not use an int socket
> descriptor. Rather, they use a pointer to the internal socket structure
> struct socket *
>
>
>
>

Re: Board-level Ethernet PHY operations in STM32.

[Grr]

El sáb, 20 feb 2021 a las 8:16, Fotis Panagiotopoulos ()
escribió:

> Low-level is close to the hardware. Think arch.
> High-level is away from the hardware. Think app.
> This is a standard industry convention, and it is followed in NuttX too.
>

Then we were talking the same from the beginning. I was implying that more
general OS interfaces, closer to app, are higher level

And you were talking about bypassing network system by using MII directly
from the app. That's why I talked about doing it at the highest level
possible, meaning constructing an upper-half driver for R/MII (and possibly
also a lower-half one if it doesn't exist)

Of course time constraints are a PITA

>
> Στις Σάβ, 20 Φεβ 2021 στις 4:04 μ.μ., ο/η Grr  έγραψε:
>
> > El sáb, 20 feb 2021 a las 7:49, Fotis Panagiotopoulos (<
> > f.j.pa...@gmail.com>)
> > escribió:
> >
> > > The highest level (and maybe the only available), is the application
> > > itself.
> > >
> > > This is what I want to avoid.
> > > I don't want the application to mess with the specific peculiarities of
> > > this hardware.
> > > It harms the overall architecture I think, makes porting more
> difficult.
> > > Following this procedure, I would end up with a mess of a code, with
> lots
> > > of conditionals to adapt the logic to every used target board.
> > >
> >
> > > Of course, I will also not be able upstream this in any way, if it is
> > > application logic.
> > >
> >
> > We're thinking level in the opposite way. I said
> >
> > "The higher the level, the better. If possible, do it at the general
> level"
> >
> > meaning that general level (common to all archs) is the highest.
> >
> > Adopting your convention, do it at the lowest, trying to do it at the
> > general, "common to all archs" level
> >
> > This is why I am looking for something at a lower-level.
> > > To keep hardware peculiarities transparent to the end application, and
> to
> > > enhance reusability of this logic.
> > >
> >
> > That's what I'm calling for. That's why I talked about SPI and I2C
> problems
> >
> > >
> > > In any case, the board level may be the most appropriate generally.
> > > Only the board knows how this specific hardware works, for example if
> > there
> > > is a hardware reset line, if there are any interrupt lines, if any
> other
> > > hardware initialization is needed after reset etc etc.
> > >
> >
> > No. That's a contradiction of your previous idea.
> >
> > Board should export/expose resources in a general way so drivers can use
> > them in a common, transparent way. That's the point of a portable OS
> >
> > If there's not a standard way in NuttX to export R/MII (I haven't looked
> at
> > it), maybe you need to create it
> >
> >
> > >
> > >
> > > Στις Σάβ, 20 Φεβ 2021 στις 3:35 μ.μ., ο/η Grr 
> > έγραψε:
> > >
> > > > I cannot offer you help on the main topic but I'd like to offer an
> > > opinion
> > > > on the level thing:
> > > >
> > > > The higher the level, the better. If possible, do it at the general
> > level
> > > >
> > > > Why? Because that way, your work is useful to most people and you
> avoid
> > > > increasing NuttX fragmentation. Many drivers are created or
> configured
> > at
> > > > board level and that work must be duplicated even when peripherals
> are
> > > > using standard interfaces like SPI or I2C
> > > >
> > > > I have some old LAN8187 (hopefully I could manage to solder them to
> an
> > > > adapter) and I could do some testing of your work if that helps you
> > > >
> > > > El sáb, 20 feb 2021 a las 6:45, Fotis Panagiotopoulos (<
> > > > f.j.pa...@gmail.com>)
> > > > escribió:
> > > >
> > > > > Anyone on this?
> > > > >
> > > > > I am using the LAN8720A Ethernet PHY.
> > > > > I realized that this IC in some rare cases may get stuck. The
> > Ethernet
> > > > LEDs
> > > > > blink erratically, and no Ethernet communication is possible.
> > > > > The only way to recover from this state is to reset the PHY. (MIIM
> > > works
> > > > in
> > > > > this case)
> > > > >
> > > > > To diagnose the issu

Re: Board-level Ethernet PHY operations in STM32.

[Grr]

El sáb, 20 feb 2021 a las 7:49, Fotis Panagiotopoulos ()
escribió:

> The highest level (and maybe the only available), is the application
> itself.
>
> This is what I want to avoid.
> I don't want the application to mess with the specific peculiarities of
> this hardware.
> It harms the overall architecture I think, makes porting more difficult.
> Following this procedure, I would end up with a mess of a code, with lots
> of conditionals to adapt the logic to every used target board.
>

> Of course, I will also not be able upstream this in any way, if it is
> application logic.
>

We're thinking level in the opposite way. I said

"The higher the level, the better. If possible, do it at the general level"

meaning that general level (common to all archs) is the highest.

Adopting your convention, do it at the lowest, trying to do it at the
general, "common to all archs" level

This is why I am looking for something at a lower-level.
> To keep hardware peculiarities transparent to the end application, and to
> enhance reusability of this logic.
>

That's what I'm calling for. That's why I talked about SPI and I2C problems

>
> In any case, the board level may be the most appropriate generally.
> Only the board knows how this specific hardware works, for example if there
> is a hardware reset line, if there are any interrupt lines, if any other
> hardware initialization is needed after reset etc etc.
>

No. That's a contradiction of your previous idea.

Board should export/expose resources in a general way so drivers can use
them in a common, transparent way. That's the point of a portable OS

If there's not a standard way in NuttX to export R/MII (I haven't looked at
it), maybe you need to create it


>
>
> Στις Σάβ, 20 Φεβ 2021 στις 3:35 μ.μ., ο/η Grr  έγραψε:
>
> > I cannot offer you help on the main topic but I'd like to offer an
> opinion
> > on the level thing:
> >
> > The higher the level, the better. If possible, do it at the general level
> >
> > Why? Because that way, your work is useful to most people and you avoid
> > increasing NuttX fragmentation. Many drivers are created or configured at
> > board level and that work must be duplicated even when peripherals are
> > using standard interfaces like SPI or I2C
> >
> > I have some old LAN8187 (hopefully I could manage to solder them to an
> > adapter) and I could do some testing of your work if that helps you
> >
> > El sáb, 20 feb 2021 a las 6:45, Fotis Panagiotopoulos (<
> > f.j.pa...@gmail.com>)
> > escribió:
> >
> > > Anyone on this?
> > >
> > > I am using the LAN8720A Ethernet PHY.
> > > I realized that this IC in some rare cases may get stuck. The Ethernet
> > LEDs
> > > blink erratically, and no Ethernet communication is possible.
> > > The only way to recover from this state is to reset the PHY. (MIIM
> works
> > in
> > > this case)
> > >
> > > To diagnose the issue, I monitor the MII_LAN8720_SECR register (symbol
> > > error count). This register typically contains a very small value.
> > Usually
> > > 0, or something close to that.
> > > When the problem occurs, this value increases very very rapidly
> > (something
> > > like thousands of errors per second).
> > >
> > > I need to monitor this register for excessive error count, and if the
> > > problem occurs to reset the PHY.
> > > I believe that the correct place to do so is in board logic.
> > >
> > > 1. Is there a way to do so?
> > > 2. Would it be more appropriate to do so in the arch low-level driver?
> I
> > > could find any function that can monitor this periodically.
> > > 3. Is it actually needed? Is there any error handling logic anywhere
> that
> > > will bring the interface down in case of MII-level errors? (Then I
> could
> > > just reset it during ifdown)
> > >
> > >
> > >
> > > Στις Κυρ, 14 Φεβ 2021 στις 2:36 μ.μ., ο/η Fotis Panagiotopoulos <
> > > f.j.pa...@gmail.com> έγραψε:
> > >
> > > > Hi everybody,
> > > >
> > > > I am trying to perform some reads/writes to my Ethernet PHY
> (LAN8720A)
> > in
> > > > board-level.
> > > >
> > > > I am pretty confused on what is the correct interface to use for this
> > > > purpose.
> > > > As far as I can tell, it is only possible to perform MII read/writes
> > > > through ioctl's in application code.
> > > > How can the board logic control the PHY? Is this possible?
> > > >
> > >
> >
>

Re: Board-level Ethernet PHY operations in STM32.

[Grr]

I cannot offer you help on the main topic but I'd like to offer an opinion
on the level thing:

The higher the level, the better. If possible, do it at the general level

Why? Because that way, your work is useful to most people and you avoid
increasing NuttX fragmentation. Many drivers are created or configured at
board level and that work must be duplicated even when peripherals are
using standard interfaces like SPI or I2C

I have some old LAN8187 (hopefully I could manage to solder them to an
adapter) and I could do some testing of your work if that helps you

El sáb, 20 feb 2021 a las 6:45, Fotis Panagiotopoulos ()
escribió:

> Anyone on this?
>
> I am using the LAN8720A Ethernet PHY.
> I realized that this IC in some rare cases may get stuck. The Ethernet LEDs
> blink erratically, and no Ethernet communication is possible.
> The only way to recover from this state is to reset the PHY. (MIIM works in
> this case)
>
> To diagnose the issue, I monitor the MII_LAN8720_SECR register (symbol
> error count). This register typically contains a very small value. Usually
> 0, or something close to that.
> When the problem occurs, this value increases very very rapidly (something
> like thousands of errors per second).
>
> I need to monitor this register for excessive error count, and if the
> problem occurs to reset the PHY.
> I believe that the correct place to do so is in board logic.
>
> 1. Is there a way to do so?
> 2. Would it be more appropriate to do so in the arch low-level driver? I
> could find any function that can monitor this periodically.
> 3. Is it actually needed? Is there any error handling logic anywhere that
> will bring the interface down in case of MII-level errors? (Then I could
> just reset it during ifdown)
>
>
>
> Στις Κυρ, 14 Φεβ 2021 στις 2:36 μ.μ., ο/η Fotis Panagiotopoulos <
> f.j.pa...@gmail.com> έγραψε:
>
> > Hi everybody,
> >
> > I am trying to perform some reads/writes to my Ethernet PHY (LAN8720A) in
> > board-level.
> >
> > I am pretty confused on what is the correct interface to use for this
> > purpose.
> > As far as I can tell, it is only possible to perform MII read/writes
> > through ioctl's in application code.
> > How can the board logic control the PHY? Is this possible?
> >
>

Re: Proper handling of arch header files

[Grr]

> Moreover, Kconfig does not (easily/nicely) allow for multiple instances of
> a
> same driver.
>

Having multiple instances of same driver is no different from having
multiple instances of same bus type

menuconfig MCP2515
bool "Microchip MCP2515 CAN Driver Support"
default n

if MCP2515

config MCP2515_1
bool "MCP2515 Device 1"
default n

if MCP2515_1
...
endif # MCP2515_1

config MCP2515_2
bool "MCP2515 Device 2"
default n
depends on MCP2515_1

if MCP2515_2
...
endif # MCP2515_2
endif # MCP2515

Re: Proper handling of arch header files

[Grr]

El sáb, 6 feb 2021 a las 9:53, Matias N. () escribió:

> That is a separate issue from what we're discussing (arch independent GPIO
> handling) and I agree
> with you. I would like to eventually move to a different initialization
> system based on callbacks
> and a hierarchical resource description strategy which can describe
> on-board devices but can be
> extended (without changing code) to describe off-board devices.
>

That's a no brainer: if you consider SPI and I2C as standard busses, the
only difference between on-board and off-board devices is on-board are
already configured and off-board need to be configured. You only have to go
to Menuconfig and add as much SPI or I2C devices as CS and addr space allows


>
> I started to work on the resource description by attempting to use
> devicetree (see length discussion
> here:
> https://github.com/apache/incubator-nuttx/issues?q=is%3Aissue+is%3Aopen+devicetree)
> which
> I think is a good option for that part.
>

DTS mean huge changes and maybe even ditching Kconfig

On the other side, a cut down sysfs-like system added to root
pseudo-filesystem is feasible right now and can expose needed information
at runtime, for example when testing. And Gregory Nutt already said /dev is
OK as registration system so zero risk of violating modularity



> Best,
> Matias
>
> On Sat, Feb 6, 2021, at 12:38, Grr wrote:
> > >
> > >
> > > The board would initialize this device as:
> > >
> >
> > What if device is external to board? You need to hack code to include
> > something that's not in any board
> >
> > That's the proof GPIO subsystem must be configured outside of board logic
> >
>

Re: Proper handling of arch header files

[Grr]

>
>
> The board would initialize this device as:
>

What if device is external to board? You need to hack code to include
something that's not in any board

That's the proof GPIO subsystem must be configured outside of board logic

Re: Proper handling of arch header files

[Grr]

> Those are sources of generic information passed to the drivers. Not
> intrinsic data of the SoC (like its memory map).
>

Then you say the problem was mixing sensitive memory map that breaks
modularity if exposed with GPIO port addresses, absolute requirement for
any GPIO subsystem

No, I think the problem is somewhere else


>
> -Original Message-----
> From: Grr [mailto:gebbe...@gmail.com]
> Sent: Saturday, February 06, 2021 7:12 AM
> To: dev@nuttx.apache.org
> Subject: Re: Proper handling of arch header files
>
> > It is very non-modular if it exposes internal data.  Tha must be
> > strictly avoided and prohibited in all cases.
> >
>
> So you mean exposing STM32_BOARD_XTAL and STM32_SYSCLK_FREQUENCY is OK but
> exposing board IO port address violates modularity
>
> That logic escapes me
>

Re: Proper handling of arch header files

[Grr]

> It is very non-modular if it exposes internal data.  Tha must be
> strictly avoided and prohibited in all cases.
>

So you mean exposing STM32_BOARD_XTAL and STM32_SYSCLK_FREQUENCY is OK but
exposing board IO port address violates modularity

That logic escapes me

Re: Proper handling of arch header files

[Grr]

> No, you wouldn't need that. The device driver will receive a generic GPIO
> handling
> interface and it would simply assert/deassert CS line without knowing the
> specifics
> of the GPIO impementation on the given architecture.


That's not what you said. You said:

"In other words, make a SPI device driver _provide the select operation_
(instead of the typical _spiNselect() at board logic level."

"without knowing the specifics" and "provide the select operation" are
mutually exclusive

Re: Proper handling of arch header files

[Grr]

El sáb, 6 feb 2021 a las 8:57, Gregory Nutt ()
escribió:

>
> > A new system, thought from the ground up to solve a problem, doesn't
> break
> > modularity per se
>
> Replacing a correct, modular interface with bad non-modular interlace is
> a very bad idea an in opposition to the INVIOLABLES.md that guild the
> NuttX architecture:
>

A new system, thought from the ground up to solve a problem, is _not _ "bad
non-modular"

Re: Proper handling of arch header files

[Grr]

> I understand you are looking for a generic API that can be used from
> drivers to access GPIOs, right?
> I understand this may come up in situations like handling CS lines from
> SPI driver.


Right.


> Currently we handle this by delegating the select line handling to board
> logic completely.
>

That's what I called driver balkanization

>
> I thought about this a few times and I think this can be made better
> without breaking modularity.


A new system, thought from the ground up to solve a problem, doesn't break
modularity per se


> I think the closest approach is to use something in the lines of what
> Xiang suggested: give the lower-half part of the SPI device driver the
> ability to control the GPIO via some interface (ioexpander in this case).


I already explained why ioexpander is useless


> One improvement I can think of is to avoid the devid -> CS line routing to
> be made at board-logic level and make a SPI device driver (eg: a sensor)
> handle it itself. In other words, make a SPI device driver provide the
> select operation (instead of the typical _spiNselect() at board logic
> level.
> This could also be used for the spiNstatus and D/C lines, if present.
>

That's moving the same problem from one place to another instead of
eliminating it: you need to rewrite some part of the driver for each
chip/subchip.

>
> That could go a long way to reduce boilerplate code to enable use of a SPI
> device from a given board.
>

I don't want to _reduce_ it. I want to _solve the problem_

>
> Best,
> Matias
>
> On Sat, Feb 6, 2021, at 09:16, Grr wrote:
> > El vie, 5 feb 2021 a las 23:15, Brennan Ashton (<
> bash...@brennanashton.com>)
> > escribió:
> >
> > > On Fri, Feb 5, 2021, 8:43 PM Grr  wrote:
> > >
> > >
> > > Arch specific ones are not allowed in arch/ or your application
> >
> >
> > There is no reason to provide your application
> > >
> >
> > GPIO system is _not_ my application
> >
> > We are talking in circles here at this point. You would have to show what
> > > you are planning on doing with the information you are trying to put in
> > > board.h because I don't see how it helps
> >
> >
> > I already did that
> >
> > Where would this base address be
> > > used, what exactly would call it?
> > >
> >
> > GPIO system  gpio_setpin() function
> >
>

Re: Proper handling of arch header files

[Grr]

El vie, 5 feb 2021 a las 23:15, Brennan Ashton ()
escribió:

> On Fri, Feb 5, 2021, 8:43 PM Grr  wrote:
>
>
> Arch specific ones are not allowed in arch/ or your application


There is no reason to provide your application
>

 GPIO system is _not_ my application

We are talking in circles here at this point. You would have to show what
> you are planning on doing with the information you are trying to put in
> board.h because I don't see how it helps


I already did that

Where would this base address be
> used, what exactly would call it?
>

GPIO system  gpio_setpin() function

Re: Proper handling of arch header files

[Grr]

Just a final explanation:

"why you want to expose the base address for a GPIO perf
of a _chip_ everywhere"

It's _not_ everywhere, just the code that includes board.h, just like _any_
other header file

And I want gpiodev_s to store specific arch information (the _more_
specific, the better) because gpio_setpin() is no time to look things up or
decode complicated schemas. When a driver issues a pin change, it wants it
to change NOW, not some time in the future when the bureaucracy is ok with
it. For example, in the case of STM32, I intend to use BSRR instead of
read/modify/write ODR.

So the challenge is to design a single structure that can accommodate the
most detailed information of any arch and use the fastest way for pin input
or output

That's why I want STM32_GPIOE_BASE (or any other arch specific address) in
gpiodev_s

El vie, 5 feb 2021 a las 22:18, Grr () escribió:

>
> What you could do is expose GPIO to a driver via an arch agnostic
>> interface.
>
>
> That's exactly what I'm doing: board.h exposes (or exports) GPIO
> parameters and the arch agnostic interface populates corresponding struct
> gpiodev_s, accessible via struct gpioops_s functions, just like many other
> NuttX systems do
>
>
>> The board.h file can then indicate which pin of the GPIO to use without
>> any
>> arch specific information
>
>
> That's hardwiring the driver and it's what I'm trying to avoid
>
>
>> The arch specific GPIO interface implemention
>> worried about how to read/write etc for pin1, whatever pin1 actually is on
>> the chip/board what you have.  Doing this let's you write almost no board
>> specific code.  This is very much how device trees look like in Linux.
>>
>
> Yes, the arch  specific GPIO interface called via gpioops_s functions
>
> So we're always been in agreement
>

Re: Proper handling of arch header files

[Grr]

> What you could do is expose GPIO to a driver via an arch agnostic
> interface.


That's exactly what I'm doing: board.h exposes (or exports) GPIO parameters
and the arch agnostic interface populates corresponding struct gpiodev_s,
accessible via struct gpioops_s functions, just like many other NuttX
systems do


> The board.h file can then indicate which pin of the GPIO to use without any
> arch specific information


That's hardwiring the driver and it's what I'm trying to avoid


> The arch specific GPIO interface implemention
> worried about how to read/write etc for pin1, whatever pin1 actually is on
> the chip/board what you have.  Doing this let's you write almost no board
> specific code.  This is very much how device trees look like in Linux.
>

Yes, the arch  specific GPIO interface called via gpioops_s functions

So we're always been in agreement

Re: Proper handling of arch header files

[Grr]

If board.h defining a bunch of macros is violating modularity principle,
then pretty much all NuttX header files are living in sin

What I proposed is _not_ violating modularity more than
stm32f40xxx_memorymap.h defining STM32_GPIOE_BASE


El vie, 5 feb 2021 a las 21:05, Gregory Nutt ()
escribió:

> A good modular design should strive to hide information behind
> interfaces and not expose that information globally. Global anything is
> the path to spaghetti code:
>
> Google for "information hiding in modular design"
>
>   * https://john.cs.olemiss.edu/~hcc/csci450/notes/ModularDesign.html
>   * https://en.wikipedia.org/wiki/Information_hiding
>   *
> https://medium.com/the-software-firehose/information-hiding-encapsulation-and-modularity-of-software-281a16ced
>   * https://people.cs.clemson.edu/~steve/CW/241/241hints/node16.html
>
> Matias is 100% correct the very best modular design would hide all
> details of the an interface and expose as little as possible globally.
> That GPIO interface was designed specifically to support such a modular
> design and information hiding.  Almost all interfaces work this way and
> is one of the greatest strengths of NuttX.
>
> I would be very strongly opposed to violating that important modularity
> principle.
>
> On 2/5/2021 8:41 PM, Grr wrote:
> > Per arch is better but not enough if the goal is to keep header files in
> > src/ instead of include/, where every interested party would access them
> > easily
> >
> > El vie, 5 feb 2021 a las 20:21, Matias N. () escribió:
> >
> >> I'm not entirely following the problem, but it sounds like you could
> >> decouple your arch-independent driver logic in an upper-half and then
> have
> >> a lower-half per-arch, using board-common drivers (ie.
> >> boards/stm32/drivers). The lower-half would then be able to use stm32
> >> internal headers. In this scenario, you don't need to replicate things
> >> per-board, only per-arch (which I guess is the minimum you could do if
> >> you're using stm32 specific pin handling).
> >>
> >> Best,
> >> Matias
> >>
> >> On Fri, Feb 5, 2021, at 23:13, Grr wrote:
> >>>> Is this helpful?
> >>>>
> >>>>
> >>
> https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h
> >>>
> >>> Maybe but I think it would obscure things. I explain:
> >>>
> >>> Per my idea, exporting available GPIOs is done from board.h like this:
> >>>
> >>> #ifdef CONFIG_GPIO_1
> >>> # if defined(CONFIG_GPIO_1_OUT)
> >>> #  define GPIO_1_TYPE GPIO_OUTPUT_PIN
> >>> # elif defined(CONFIG_GPIO_1_IN)
> >>> #  define GPIO_1_TYPE GPIO_INPUT_PIN
> >>> # else /* CONFIG_GPIO_1_IRQ */
> >>> #  define GPIO_1_TYPE GPIO_INTERRUPT_PIN
> >>> # endif
> >>> # define GPIO_1_PIN   2
> >>> # define GPIO_1_PORT  5
> >>> # define GPIO_1_ADDR  STM32_GPIOE_BASE
> >>> #endif  /* CONFIG_GPIO_1  */
> >>>
> >>> That means I should be able to access
> >>> arch/arm/src/stm32/hardware/stm32f40xxx_memorymap.h from board.h, which
> >> is
> >>> no dangerous at all, except that it's not easy
> >>>
> >>> Why not follow that page advice and do it from the C file? Because
> next C
> >>> file is a system-wide file in drivers/ that fills system-wide GPIO
> struct
> >>> with board information. Otherwise, I'd have to make a board function
> that
> >>> fills system-wide struct and replicate that for every board thus
> >> recreating
> >>> the problem I want to fix.
> >>>
> >>> If STM32 header files were in include/, there would be no problem, so
> I'm
> >>> almost convinced that will be the best solution
> >>>
> >>>
> >>>> On 2/5/2021 7:34 PM, Brennan Ashton wrote:
> >>>>> On Fri, Feb 5, 2021, 4:40 PM Grr  wrote:
> >>>>>
> >>>>>>> You cannot  include arch specific headers in board.h like that!
> >> That
> >>>> will
> >>>>>>> break a lot of things.
> >>>>>>>
> >>>>>> board.h is arch specific
> >>>>>> It absolutely is not including arch headers will break things.
> >>>>> board.h:
> >>>>>
> >>
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%

Re: Proper handling of arch header files

[Grr]

Per arch is better but not enough if the goal is to keep header files in
src/ instead of include/, where every interested party would access them
easily

El vie, 5 feb 2021 a las 20:21, Matias N. () escribió:

> I'm not entirely following the problem, but it sounds like you could
> decouple your arch-independent driver logic in an upper-half and then have
> a lower-half per-arch, using board-common drivers (ie.
> boards/stm32/drivers). The lower-half would then be able to use stm32
> internal headers. In this scenario, you don't need to replicate things
> per-board, only per-arch (which I guess is the minimum you could do if
> you're using stm32 specific pin handling).
>
> Best,
> Matias
>
> On Fri, Feb 5, 2021, at 23:13, Grr wrote:
> > > Is this helpful?
> > >
> > >
> https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h
> >
> >
> > Maybe but I think it would obscure things. I explain:
> >
> > Per my idea, exporting available GPIOs is done from board.h like this:
> >
> > #ifdef CONFIG_GPIO_1
> > # if defined(CONFIG_GPIO_1_OUT)
> > #  define GPIO_1_TYPE GPIO_OUTPUT_PIN
> > # elif defined(CONFIG_GPIO_1_IN)
> > #  define GPIO_1_TYPE GPIO_INPUT_PIN
> > # else /* CONFIG_GPIO_1_IRQ */
> > #  define GPIO_1_TYPE GPIO_INTERRUPT_PIN
> > # endif
> > # define GPIO_1_PIN   2
> > # define GPIO_1_PORT  5
> > # define GPIO_1_ADDR  STM32_GPIOE_BASE
> > #endif  /* CONFIG_GPIO_1  */
> >
> > That means I should be able to access
> > arch/arm/src/stm32/hardware/stm32f40xxx_memorymap.h from board.h, which
> is
> > no dangerous at all, except that it's not easy
> >
> > Why not follow that page advice and do it from the C file? Because next C
> > file is a system-wide file in drivers/ that fills system-wide GPIO struct
> > with board information. Otherwise, I'd have to make a board function that
> > fills system-wide struct and replicate that for every board thus
> recreating
> > the problem I want to fix.
> >
> > If STM32 header files were in include/, there would be no problem, so I'm
> > almost convinced that will be the best solution
> >
> >
> > >
> > > On 2/5/2021 7:34 PM, Brennan Ashton wrote:
> > > > On Fri, Feb 5, 2021, 4:40 PM Grr  wrote:
> > > >
> > > >>> You cannot  include arch specific headers in board.h like that!
> That
> > > will
> > > >>> break a lot of things.
> > > >>>
> > > >> board.h is arch specific
> > > >
> > > >> It absolutely is not including arch headers will break things.
> > > > board.h:
> > > >
> > >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Finclude%2Fboard.h
> > > >
> > > > And the arch specific board configuration:
> > > >
> > >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Fsrc%2Fstm32f4discovery.h
> > > >
> > > >
> > > >
> > > >>
> > > >>> The expectation is that you pass the interfaces that you need into
> the
> > > >>> drivers.  If you have a particular "module" which contains multiple
> > > >> devices
> > > >>> that you want to support across different boards then just create a
> > > thin
> > > >>> driver that wraps everything else inside of it. Bypassing things
> like
> > > the
> > > >>> existing SPI CS or interrupt infrastructure is asking for trouble.
> > > >>>
> > > >> Combining my example (I forgot to mention ESP32) with that technique
> > > means
> > > >> creating at least 10 thin
> > > >>
> > > > You should not need to do that.  Here is an example of how GPIO is
> > > normally
> > > > attached. Note this be done in per arch common code but it is arch
> > > specific.
> > > >
> > > >
> > >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Fsrc%2Fstm32_gs2200m.c
> > > >
> > > > You could also create a shim for the driver to talk to the generic
> GPIO
> > > > interface as we suggested earlier, but I'm not convinced that we
> would
> > > gain
> > > > much with that.
> > > >
> > > >
> > > >>> For example I have a

Re: Proper handling of arch header files

[Grr]

> But there is a problem with it, which is why it's hard to do this.  Please
> read the wiki page Greg posted which explains why you cannot include chip
> specific headers in board.h
>
> What is it that must go in there?
>

All this comes from my idea of solving driver balkanization. It's illogical
to incur in an extra step in the problematic direction (needing a per board
function to fill in GPIO structure that can be filled with a unique,
system-wide function) just to keep header files in src/ instead of include/

Re: Proper handling of arch header files

[Grr]

> Is this helpful?
>
> https://cwiki.apache.org/confluence/display/NUTTX/Including+Files+in+board.h


Maybe but I think it would obscure things. I explain:

Per my idea, exporting available GPIOs is done from board.h like this:

#ifdef CONFIG_GPIO_1
# if defined(CONFIG_GPIO_1_OUT)
#  define GPIO_1_TYPE GPIO_OUTPUT_PIN
# elif defined(CONFIG_GPIO_1_IN)
#  define GPIO_1_TYPE GPIO_INPUT_PIN
# else /* CONFIG_GPIO_1_IRQ */
#  define GPIO_1_TYPE GPIO_INTERRUPT_PIN
# endif
# define GPIO_1_PIN   2
# define GPIO_1_PORT  5
# define GPIO_1_ADDR  STM32_GPIOE_BASE
#endif  /* CONFIG_GPIO_1  */

That means I should be able to access
arch/arm/src/stm32/hardware/stm32f40xxx_memorymap.h from board.h, which is
no dangerous at all, except that it's not easy

Why not follow that page advice and do it from the C file? Because next C
file is a system-wide file in drivers/ that fills system-wide GPIO struct
with board information. Otherwise, I'd have to make a board function that
fills system-wide struct and replicate that for every board thus recreating
the problem I want to fix.

If STM32 header files were in include/, there would be no problem, so I'm
almost convinced that will be the best solution


>
> On 2/5/2021 7:34 PM, Brennan Ashton wrote:
> > On Fri, Feb 5, 2021, 4:40 PM Grr  wrote:
> >
> >>> You cannot  include arch specific headers in board.h like that! That
> will
> >>> break a lot of things.
> >>>
> >> board.h is arch specific
> >
> >> It absolutely is not including arch headers will break things.
> > board.h:
> >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Finclude%2Fboard.h
> >
> > And the arch specific board configuration:
> >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Fsrc%2Fstm32f4discovery.h
> >
> >
> >
> >>
> >>> The expectation is that you pass the interfaces that you need into the
> >>> drivers.  If you have a particular "module" which contains multiple
> >> devices
> >>> that you want to support across different boards then just create a
> thin
> >>> driver that wraps everything else inside of it. Bypassing things like
> the
> >>> existing SPI CS or interrupt infrastructure is asking for trouble.
> >>>
> >> Combining my example (I forgot to mention ESP32) with that technique
> means
> >> creating at least 10 thin
> >>
> > You should not need to do that.  Here is an example of how GPIO is
> normally
> > attached. Note this be done in per arch common code but it is arch
> specific.
> >
> >
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Fsrc%2Fstm32_gs2200m.c
> >
> > You could also create a shim for the driver to talk to the generic GPIO
> > interface as we suggested earlier, but I'm not convinced that we would
> gain
> > much with that.
> >
> >
> >>> For example I have a breakout module with a touchscreen, keyboard, and
> SD
> >>> card. This requires the I2C bus, SPI bus, and GPIO for card detection
> and
> >>> chip select.  I just define a common name for the IO on the device and
> >> then
> >>> map that in board.h and then add the callbacks for the GPIO interrupt
> and
> >>> the chip select.  This in total is about 50 lines of actual board code
> >> and
> >>> that is if you are not already using things like the SPI chip select.
> >>>
> >> My idea goes like this:
> >>
> >> 1-Board exports available GPIOs (among other things)
> >> 2-Menuconfig offer GPIOs to user for selection. Selected ones become
> >> available to drivers
> >> 3-User configures needed drivers with selected GPIOs, also in Menuconfig
> >> 4-Compiles
> >> 5-If developing, user can test with incorporated char driver that
> allows to
> >> turn on and off selected GPIOs from a system testing utility
> >
> > To do this you would use the ioexpander/GPIO interface that was
> mentioned.
> > It can provide that functionality but you would still have to write lower
> > half shims for the drivers that would consume GPIO this way.
> >
> >
> >>> --Brennan
> >>>
> >>> On Fri, Feb 5, 2021, 3:08 PM Grr  wrote:
> >>>
> >>>>> Yes, we need an additional struct for port number:
> >>>>>
> >>>>>
> >>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/n

Re: Proper handling of arch header files

[Grr]

> It absolutely is not including arch headers will break things.
>
> board.h:
>
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Finclude%2Fboard.h
>
> And the arch specific board configuration:
>
> https://www.github.com/apache/incubator-nuttx/tree/master/boards%2Farm%2Fstm32%2Fstm32f4discovery%2Fsrc%2Fstm32f4discovery.h
>

I'm thinking maybe the confusion is I said "arch specific" when I meant
"chip specific". I always talked about stm32 (which should be "subarch",
not "chip" to have "chip" referring to stm32f407|stm32f103|whatever.
Semantics)

What I mean is there should be no problem at all calling STM32 header files
from a STM32 board (except for the fact they're not in include/ but in src/)

And for my purposes, it's needed

To do this you would use the ioexpander/GPIO interface that was mentioned.
> It can provide that functionality but you would still have to write lower
> half shims for the drivers that would consume GPIO this way.
>

I already explained why ioexpander doesn't cut it

>
>
> >
> > >
> > > --Brennan
> > >
> > > On Fri, Feb 5, 2021, 3:08 PM Grr  wrote:
> > >
> > > > >
> > > > > Yes, we need an additional struct for port number:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L49-L57
> > > > > struct lcd_ili9486_config_s
> > > > > {
> > > > >   uint8_t power_gpio;
> > > > >   uint8_t rst_gpio;
> > > > >   uint8_t spi_cs_num;
> > > > >   uint8_t spi_rs_gpio;
> > > > >   uint32_t spi_freq;
> > > > >   uint8_t spi_nbits;
> > > > > };
> > > > > But, we can reuse ioexpander_dev_s or gpio_dev_s, what's benefit to
> > > add a
> > > > > new gpioops_s?
> > > > >
> > > >
> > > > I mean GPIO port, not SPÎ port. I mentioned SPI because GPIOs are
> > needed
> > > as
> > > > chip selects, resets and interrupt inputs for SPI devices
> > > >
> > > > But that's only my particular case. Point is to have GPIOs that can
> be
> > > used
> > > > anywhere for anything in a standard way
> > > >
> > > > We can add the public interface to arch/archx/include/chipy/chip.h,
> > like
> > > > > this:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/FishsemiCode/nuttx/blob/song-u1/arch/arm/include/song/chip.h#L75-L84
> > > >
> > > >
> > > > My question is how to reach arch/arm/src/stm32/stm32.h from
> > > > include/arch/board/board.h and sort the hardwired assumption of the
> > rest
> > > of
> > > > headers being local. It seems to me that only reasonable solution is
> > > moving
> > > > all header files to include/arch/ but I may be wrong
> > >
> >
>

Re: Proper handling of arch header files

[Grr]

> You cannot  include arch specific headers in board.h like that! That will
> break a lot of things.
>

board.h is arch specific


> The expectation is that you pass the interfaces that you need into the
> drivers.  If you have a particular "module" which contains multiple devices
> that you want to support across different boards then just create a thin
> driver that wraps everything else inside of it. Bypassing things like the
> existing SPI CS or interrupt infrastructure is asking for trouble.
>

Combining my example (I forgot to mention ESP32) with that technique means
creating at least 10 thin drivers


> For example I have a breakout module with a touchscreen, keyboard, and SD
> card. This requires the I2C bus, SPI bus, and GPIO for card detection and
> chip select.  I just define a common name for the IO on the device and then
> map that in board.h and then add the callbacks for the GPIO interrupt and
> the chip select.  This in total is about 50 lines of actual board code and
> that is if you are not already using things like the SPI chip select.
>

My idea goes like this:

1-Board exports available GPIOs (among other things)
2-Menuconfig offer GPIOs to user for selection. Selected ones become
available to drivers
3-User configures needed drivers with selected GPIOs, also in Menuconfig
4-Compiles
5-If developing, user can test with incorporated char driver that allows to
turn on and off selected GPIOs from a system testing utility

>
> --Brennan
>
> On Fri, Feb 5, 2021, 3:08 PM Grr  wrote:
>
> > >
> > > Yes, we need an additional struct for port number:
> > >
> > >
> >
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L49-L57
> > > struct lcd_ili9486_config_s
> > > {
> > >   uint8_t power_gpio;
> > >   uint8_t rst_gpio;
> > >   uint8_t spi_cs_num;
> > >   uint8_t spi_rs_gpio;
> > >   uint32_t spi_freq;
> > >   uint8_t spi_nbits;
> > > };
> > > But, we can reuse ioexpander_dev_s or gpio_dev_s, what's benefit to
> add a
> > > new gpioops_s?
> > >
> >
> > I mean GPIO port, not SPÎ port. I mentioned SPI because GPIOs are needed
> as
> > chip selects, resets and interrupt inputs for SPI devices
> >
> > But that's only my particular case. Point is to have GPIOs that can be
> used
> > anywhere for anything in a standard way
> >
> > We can add the public interface to arch/archx/include/chipy/chip.h, like
> > > this:
> > >
> > >
> >
> https://github.com/FishsemiCode/nuttx/blob/song-u1/arch/arm/include/song/chip.h#L75-L84
> >
> >
> > My question is how to reach arch/arm/src/stm32/stm32.h from
> > include/arch/board/board.h and sort the hardwired assumption of the rest
> of
> > headers being local. It seems to me that only reasonable solution is
> moving
> > all header files to include/arch/ but I may be wrong
>

Re: Proper handling of arch header files

[Grr]

>
> Yes, we need an additional struct for port number:
>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L49-L57
> struct lcd_ili9486_config_s
> {
>   uint8_t power_gpio;
>   uint8_t rst_gpio;
>   uint8_t spi_cs_num;
>   uint8_t spi_rs_gpio;
>   uint32_t spi_freq;
>   uint8_t spi_nbits;
> };
> But, we can reuse ioexpander_dev_s or gpio_dev_s, what's benefit to add a
> new gpioops_s?
>

I mean GPIO port, not SPÎ port. I mentioned SPI because GPIOs are needed as
chip selects, resets and interrupt inputs for SPI devices

But that's only my particular case. Point is to have GPIOs that can be used
anywhere for anything in a standard way

We can add the public interface to arch/archx/include/chipy/chip.h, like
> this:
>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/arch/arm/include/song/chip.h#L75-L84


My question is how to reach arch/arm/src/stm32/stm32.h from
include/arch/board/board.h and sort the hardwired assumption of the rest of
headers being local. It seems to me that only reasonable solution is moving
all header files to include/arch/ but I may be wrong

Re: Proper handling of arch header files

[Grr]

>

> We achieve this by:
>
>1. Chip driver implement io expander driver to encapsulate the gpio
>hardware
>2. Generic driver control the gpio through the io expander driver
>directly e.g.:
>
>
>
> https://github.com/FishsemiCode/nuttx/blob/song-u1/include/nuttx/lcd/ili9486_lcd.h#L72-L74
>int lcd_ili9486_register(FAR const struct lcd_ili9486_config_s
> *config, FAR struct spi_dev_s *spi, FAR struct ioexpander_dev_s *ioe);
> Another method is that the generic driver calls the callback provided by
> the board file to do the custom specific logic.
>

Struct ioexpander_dev_s can't store pin & port number, pin type or memory
address

My idea is something like

struct gpiodev_s
{
  uint8_t   num;/* GPIO device number
  */
  uint8_t   type;   /* GPIO device type
  */
  uint8_t   pin;/* Pin number
  */
  uint8_t   port;   /* A=1, B=2, etc
   */
  uint32_t  address;/* Output register adress
  */

  FAR const struct gpioops_s *ops;
};

And there's also the issue of where GPIO devices are registered so user can
configure several drivers in a compatible way

For example, I have F4Discovery, BluePill and BlackPill boards, and I want
to connect a couple of SPI CAN devices, a display and a DAQ system in
different configurations without too much hassle


> > > Common code shouldn't reference arch or board specific header files,
> only
> > > source code under boards/ or arch/ can reference them.
> > >
> >
> > I mean the other way around: board.h referencing common platform header
> > files, needed for memory definitions
> >
>
> The platform could put the public header files under
> arch/archx/include/chipy/ and then boards/archx/chipy/boardz can reference
> these header files.
>

Most header files are not in include/ but in src/. I couldn't find a simple
way to fix that, hence my question

Re: Proper handling of arch header files

[Grr]

> NuttX already support pinctrl and gpio peripheral:
>
> https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/ioexpander.h
>
>
> https://github.com/apache/incubator-nuttx/blob/master/include/nuttx/ioexpander/gpio.h
> We can reuse and improve them.
>

I don't mean IO expander. I mean ability to use uC GPIO in a general way

For example, how can you define GPIO1 as pin X1 of port Y1 in board Z1 but
pin X2 of port Y2 in board Z2 so any driver can use GPIO1 without being
hardwired to a specific board?

For that you need a general GPIO system where boards export GPIOs in a
platform-independent way that any driver can use


> Common code shouldn't reference arch or board specific header files, only
> source code under boards/ or arch/ can reference them.
>

I mean the other way around: board.h referencing common platform header
files, needed for memory definitions

Proper handling of arch header files

[Grr]

Hello to all

I'm developing a Linux-like GPIO system and I need to reach arch
definitions (for example STM32_GPIOE_BSRR) in a portable way

Obvious choice is arch/board/board.h but in the case of STM32, there's not
an elegant way to reach arch/arm/src/stm32/stm32.h from there

What would be the preferred way in order to make it standard?

a) Create a link from include/ to arch/arm/src/stm32/stm32.h, maybe from
include/arch/chip
b) Move arch/arm/src/stm32/stm32.h & sons to include/arch/chip

TIA
Grr

Re: stdout

[Grr]

I opted for The Right Thing(TM) and implemented a simple serial input echo
capabilities for serial driver introducing use of ECHO flag in
drivers/serial/serial.c and proper configuration options in menuconfig

Now the interface of an interactive serial program works the same in Linux
and NuttX  :)

Next task is to disable NSH echo and I'll have a complete solution

If anyone is interested, I can do a PR

El mar, 26 ene 2021 a las 11:46, Grr () escribió:

> Ken:
> Thanks a lot for your code. I will try it
>
> I was researching that echo thing and yes, that's a terminal device driver
> thing. More exactly, c_lflag of termios struct. Problem is I haven't found
> yet where that is set in the serial terminal setup sequence
>
> El mar, 26 ene 2021 a las 11:28, Johnny Billquist ()
> escribió:
>
>> On 2021-01-26 16:16, Ken Pettit wrote:
>> > Grr,
>> >
>> > Yeah, in Nuttx, fgets, fgetc, etc. don't echo.  Even in Linux, the echo
>> > is actually a function of the terminal, not the running program and
>> > 'fgets'.
>>
>> It is actually not a function of the terminal, but the terminal (serial)
>> device driver.
>>
>>Johnny
>>
>> --
>> Johnny Billquist  || "I'm on a bus
>>||  on a psychedelic trip
>> email: b...@softjar.se ||  Reading murder books
>> pdp is alive! ||  tryin' to stay hip" - B. Idol
>>
>

Re: stdout

[Grr]

Ken:
Thanks a lot for your code. I will try it

I was researching that echo thing and yes, that's a terminal device driver
thing. More exactly, c_lflag of termios struct. Problem is I haven't found
yet where that is set in the serial terminal setup sequence

El mar, 26 ene 2021 a las 11:28, Johnny Billquist ()
escribió:

> On 2021-01-26 16:16, Ken Pettit wrote:
> > Grr,
> >
> > Yeah, in Nuttx, fgets, fgetc, etc. don't echo.  Even in Linux, the echo
> > is actually a function of the terminal, not the running program and
> > 'fgets'.
>
> It is actually not a function of the terminal, but the terminal (serial)
> device driver.
>
>Johnny
>
> --
> Johnny Billquist  || "I'm on a bus
>||  on a psychedelic trip
> email: b...@softjar.se ||  Reading murder books
> pdp is alive! ||  tryin' to stay hip" - B. Idol
>

Re: stdout

[Grr]

Hello

That fflush is for fgets

Yes, with a stdout flush, message prints but the question remains about why
is it needed and how can I get input echo

Thanks

Grr

El lun, 25 ene 2021 a las 13:30, Ken Pettit () escribió:

> Hey Grr,
>
> You need the fflush(stdout) call to be *after* the printf("\nEnter
> Command:").
>
> If the printf doesn't end with \n, then the stdout won't be flushed.
>
> Ken
>
> On 1/25/21 11:25 AM, Grr wrote:
> > Hello to all
> >
> > Is there a way to get stdout without a LF?
> >
> > I have something like
> >
> > case INPUT_CMD:
> >fflush(stdin);
> >printf("\nEnter Command:");
> >fgets(input, INPUT_STRING, stdin);
> >spitest.cmd = input[0]; /* First char is the command
> */
> >
> > that in Linux prints message and waits for input but in Nuttx shows
> nothing.
> >
> > I don't want LF because that destroys the format I want for program
> > interface
> >
> > Another related issue is I don't get echo from input
> >
> > How do I get messages printed without a LF and echo from input?
> >
> > TIA
> >
> > Grr
> >
>
>

stdout

[Grr]

Hello to all

Is there a way to get stdout without a LF?

I have something like

case INPUT_CMD:
  fflush(stdin);
  printf("\nEnter Command:");
  fgets(input, INPUT_STRING, stdin);
  spitest.cmd = input[0]; /* First char is the command  */

that in Linux prints message and waits for input but in Nuttx shows nothing.

I don't want LF because that destroys the format I want for program
interface

Another related issue is I don't get echo from input

How do I get messages printed without a LF and echo from input?

TIA

Grr

Re: Formatted text over serial

[Grr]

Not only everything blinks but the background color changes to some middle
scale gray and that happens with all pdcurses demos

But that's minicom. I just tested with screen and they work just fine,
color included

I kind of remember now minicom had such problems with curses 15+ years
back. It seems it's not a bug, it's a feature

El vie, 22 ene 2021 a las 19:26, Ken Pettit () escribió:

> But using tmux, I am able to get pdcurses displays like this (it
> actually has color):
>
> File  Debug  Help
> ┌───Watch───┐
> ┌─┐│ │
> │ ││   │
> │  . *
> ││   │
> │   x *.
> ││   │
> │  __  __ * . x
> ││   │
> │ /  \/  \  .  x .
> ││   │
> │ \   \ x  |\ *
> ││   │
> │I Q - A N A L O G | \ ││   │
> │   \   \(\,   |  \ ,/)
> ││   │
> │\__/\__/ \(   |___\)/
> ││   │
> │ //\  # oo #  /\\
> ││   │
> │(/  \_#  * #_/  \)
> ││   │
> │  \ /    \ /
> ││   │
> │  M E R L I N  /\   ##   /\
> ││   │
> │   Debugger  )  (
> ││   │
> │ v2.8|  |
> ││   │
> │ |  |
> ││   │
> │ +~~+
> ││   │
> │ ││── Key Debug ──│
> │ ││   │
>
> └─┘└───┘
>
> ┌───Command┐
> │ merlin> │
> │ │
> │ │
> │ │
> │ │
> │ │
>
> └──┘
>
>
> On 1/22/21 4:18 PM, Johnny Billquist wrote:
> > On 2021-01-22 23:43, Gregory Nutt wrote:
> >>
>  Now examples compile and work although in flashing mode with
>  minicom in
>  VT102 mode
> 
> >> If you start mincom with -t vt100 it should force VT100 vs VT102
> >> mode. But I thought that VT102 was mostly compatible?
> >
> > The VT102 is a superset of the VT100. There are a couple of additional
> > functions the VT102 have, as well as by standard having a few options
> > installed that were optional on the VT100.
> >
> > With that said, I'm not sure what is meant by "flashing mode" here. Is
> > there some flashing effect with redrawing things, or are we talking
> > about the flashing attribute of characters, by which they blink all
> > the time?
> >
> >   Johnny
> >
>
>

Re: Formatted text over serial

[Grr]

It also needs CONFIG_PDCURSES_MULTITHREAD or there's no PDC_ctx_free()
definition

Now examples compile and work although in flashing mode with minicom in
VT102 mode

I'll fix that later

Thanks again

Grr

El vie, 22 ene 2021 a las 14:35, Ken Pettit () escribió:

> Looks like changing  nuttx/pdcdisp.c:840 from "sp" to just "s" was the
> only compile error.  Though going through the exercise made me remember
> that you also need to select:
>
> Application Configuration --> Graphics Support --> pdcurses --> Input
> Devices --> Terminal Input
>
> Otherwise you don't have any input device for pdcurses.
>
> Ken
>
>
> On 1/22/21 11:31 AM, Grr wrote:
> > Thank you for your response
> >
> > I searched menuconfig according to your instructions and found it.
> > Compilation crashed with
> >
> > nuttx/pdcdisp.c:840:19: error: 'sp' undeclared (first use in this
> > function); did you mean 's'?
> >
> > but it's a matter of debugging it. Maybe a lacking option, I'll research
> it
> >
> > Thanks again
> > Grr
> >
> >
> > El vie, 22 ene 2021 a las 13:11, Ken Pettit ()
> escribió:
> >
> >> Grr,
> >>
> >> Actually, pdcurses has a mode that will work over serial using
> >> System->Termcurses.  This is a terminal based extension to pdcurses that
> >> I added a few years back.  It supports VT-100 / ANSI escape codes.  I
> >> haven't tested it in the Apache NuttX framework to validate it still
> >> works though.
> >>
> >> If you don't define CONFIG_SYSTEM_TERMCURSES, then yes, you will get an
> >> error about the graphic fb creation.
> >>
> >> Ken
> >>
> >> On 1/22/21 11:02 AM, Grr wrote:
> >>> Hello all
> >>>
> >>> Is there a way to have formatted text output over serial? I want to
> >> create
> >>> some testing utility that runs from nsh and has some screen
> organization
> >> to
> >>> ease use
> >>>
> >>> I tested pdcurses examples but they seem to depend on fb (haven't
> >> analyzed
> >>> code) and all exited or crashed with "initscr(): Unable to create SP"
> >>>
> >>> Is there a builtin way to do such thing?
> >>>
> >>> TIA
> >>> Grr
> >>>
> >>
>
>

Re: Formatted text over serial

[Grr]

Thank you for your response

I searched menuconfig according to your instructions and found it.
Compilation crashed with

nuttx/pdcdisp.c:840:19: error: 'sp' undeclared (first use in this
function); did you mean 's'?

but it's a matter of debugging it. Maybe a lacking option, I'll research it

Thanks again
Grr


El vie, 22 ene 2021 a las 13:11, Ken Pettit () escribió:

> Grr,
>
> Actually, pdcurses has a mode that will work over serial using
> System->Termcurses.  This is a terminal based extension to pdcurses that
> I added a few years back.  It supports VT-100 / ANSI escape codes.  I
> haven't tested it in the Apache NuttX framework to validate it still
> works though.
>
> If you don't define CONFIG_SYSTEM_TERMCURSES, then yes, you will get an
> error about the graphic fb creation.
>
> Ken
>
> On 1/22/21 11:02 AM, Grr wrote:
> > Hello all
> >
> > Is there a way to have formatted text output over serial? I want to
> create
> > some testing utility that runs from nsh and has some screen organization
> to
> > ease use
> >
> > I tested pdcurses examples but they seem to depend on fb (haven't
> analyzed
> > code) and all exited or crashed with "initscr(): Unable to create SP"
> >
> > Is there a builtin way to do such thing?
> >
> > TIA
> > Grr
> >
>
>

Formatted text over serial

[Grr]

Hello all

Is there a way to have formatted text output over serial? I want to create
some testing utility that runs from nsh and has some screen organization to
ease use

I tested pdcurses examples but they seem to depend on fb (haven't analyzed
code) and all exited or crashed with "initscr(): Unable to create SP"

Is there a builtin way to do such thing?

TIA
Grr

Re: Thread (Openthread) networking protocol & NuttX

[Grr]

I didn't mean ESP8266 as RCP but as a NCP. That's why I talked about WiFi

El vie, 22 ene 2021 a las 5:35, Max Kriegleder ()
escribió:

> Just to clarify, I don't think the ESP8266 would work as it is not a
> IEEE 802.15.4 radio - see also this thread
> https://github.com/openthread/ot-esp32/issues/17
>
> I was also thinking that it should be possible to somehow build on top
> of Spinel something like USRSOCK to have a IEEE 802.15.4 radio alongside
> a host processor running NuttX. At the same time I would like to have
> the possibility to run the entire Openthread stack integrated with NuttX
> on one processor capable of IEEE 802.15.4. I think the nrf54820 would be
> a good start for both designs (Network Co-Processor along a host
> processor and single SoC).
>
> Has anybody looked into this? I am wondering how this would integrate
> with existing support for 6LowPan
> (
> http://docplayer.net/163084802-Nuttx-rtos-wifi-bluetooth-gregory-nutt.html
> )
>
> Thanks!
> Max
>
>
> On 2021/01/22 01:16:57, Grr  wrote:
>  > I didn't know anything about it but Spinel seems the perfect solution
> to>
>  > connect NuttX to ESP8266 and have a dirt cheap solution for NuttX WiFi>
>  > networking>
>  >
>  > El jue, 21 ene 2021 a las 17:07, Max Kriegleder ()>
>  > escribió:>
>  >
>  > > Hi all,>
>  > >>
>  > > I am currently looking into thread networking protocol for IoT>
>  > > applications - https://openthread.io/. There are several design>
>  > > approaches with System-on-Chip (SoC) and Co-Processor (RCP, NCP)>
>  > > designs. Has anybody looked into integrating thread into NuttX>
>  > > regardless of the design approach? I saw that Zephyr OS does support>
>  > > thread>
>  > >
> https://docs.zephyrproject.org/latest/reference/networking/thread.html>
>  > > and I am hoping it wouldn't be too difficult to integrate it into
> NuttX.>
>  > >>
>  > > Thanks!>
>  > > Max>
>  > >>
>  > >>
>  >
>

Re: Thread (Openthread) networking protocol & NuttX

[Grr]

I didn't know anything about it but Spinel seems the perfect solution to
connect NuttX to ESP8266 and have a dirt cheap solution for NuttX WiFi
networking

El jue, 21 ene 2021 a las 17:07, Max Kriegleder ()
escribió:

> Hi all,
>
> I am currently looking into thread networking protocol for IoT
> applications - https://openthread.io/. There are several design
> approaches with System-on-Chip (SoC) and Co-Processor (RCP, NCP)
> designs. Has anybody looked into integrating thread into NuttX
> regardless of the design approach? I saw that Zephyr OS does support
> thread
> https://docs.zephyrproject.org/latest/reference/networking/thread.html
> and I am hoping it wouldn't be too difficult to integrate it into NuttX.
>
> Thanks!
> Max
>
>

Re: Problem with USB CDC initialization on board based on STM32F4DISCO

[Grr]

Sort of binary search? You're right, that's faster. I tend to see it like a
sequence rather than a searchable collection

El dom, 17 ene 2021 a las 11:15, Nathan Hartman ()
escribió:

> On Sun, Jan 17, 2021 at 11:36 AM Grr  wrote:
>
> > Have you tried starting from original, working config and adding and
> > testing after _every single_ change?
> >
> > If you're changing OS elements, maybe one of them is affecting USB
> without
> > you knowing
> >
> > Testing at every change is tedious but sometimes the only possible
> > technique
>
>
> If you're using version control, and each feature you add is a new commit,
> then you can bisect to find which commit breaks USB, with fewer tests than
> testing each commit in sequence.
>
> Nathan
>

Re: Problem with USB CDC initialization on board based on STM32F4DISCO

[Grr]

El dom, 17 ene 2021 a las 9:10, Flavio Castro Alves Filho (<
flavio.al...@gmail.com>) escribió:

> Thank you very much for your fast response.
>
> I checked the boot calls and they are the same, regarding USB
> initialization.
>
> I compared the include/nuttx/config.h files too ... at least regarding
> USB, I couldn't see anything critical.
>

That means problem is in a dependency and not exactly USB

>

>
> The development approach that I am working was exactly starting with
> stm32discovery board and increasing features. Maybe I have to restart,
> checking first the USB.
>

Have you tried starting from original, working config and adding and
testing after _every single_ change?

If you're changing OS elements, maybe one of them is affecting USB without
you knowing

Testing at every change is tedious but sometimes the only possible technique

>
> Best regards,
>
> Flavio
>
> Em dom., 17 de jan. de 2021 às 11:39, Grr  escreveu:
> >
> > What you can do is compare .config generated from that defconfig to
> .config
> > generated from "./tools/configure.sh -l stm32f4discovery:usbnsh" and see
> > the differences. You can also compare include/nuttx/config.h from both
> > configs
> >
> > Another approach is to start from discovery config and do the
> modifications
> > for your board. After you have it working, clone the config to a
> different
> > board name. With "make savedefconfig" you can save your working defconfig
> >
> > El dom, 17 ene 2021 a las 7:51, Flavio Castro Alves Filho (<
> > flavio.al...@gmail.com>) escribió:
> >
> > > As an additional information, if I load the STM32F4DISCO on my board,
> USB
> > > works.
> > >
> > > Em dom., 17 de jan. de 2021 às 10:43, Flavio Castro Alves Filho
> > >  escreveu:
> > > >
> > > > Hello,
> > > >
> > > > I am working to port NuttX on a board based on STM32F4DISCOVERY. The
> > > > microcontroller is the STM32F407VET6.
> > > >
> > > > USB CDC support is not initializing.
> > > >
> > > > When I plug the USB on the board, I have the following dmesg
> response in
> > > Linux:
> > > >
> > > > [517062.075048] usb usb1-port2: attempt power cycle
> > > > [517062.726922] usb 1-2: new full-speed USB device number 47 using
> > > xhci_hcd
> > > > [517062.727170] usb 1-2: Device not responding to setup address.
> > > > [517062.935148] usb 1-2: Device not responding to setup address.
> > > > [517063.142906] usb 1-2: device not accepting address 47, error -71
> > > > [517063.270916] usb 1-2: new full-speed USB device number 48 using
> > > xhci_hcd
> > > > [517063.271141] usb 1-2: Device not responding to setup address.
> > > > [517063.479134] usb 1-2: Device not responding to setup address.
> > > >
> > > > When I run stm32f4discovery:usbnsh on my discovery board, it works.
> > > >
> > > > I compared the defconfig from the base project and from mine and I
> > > > believe I have initialized everything that is related to the USB.
> > > >
> > > > Here is the defconfig for my board:
> > > >
> > > > #
> > > > # This file is autogenerated: PLEASE DO NOT EDIT IT.
> > > > #
> > > > # You can use "make menuconfig" to make any modifications to the
> > > > installed .config file.
> > > > # You can then do "make savedefconfig" to generate a new defconfig
> > > > file that includes your
> > > > # modifications.
> > > > #
> > > > # CONFIG_ARCH_FPU is not set
> > > > # CONFIG_MMCSD_MMCSUPPORT is not set
> > > > # CONFIG_MMCSD_SPI is not set
> > > > # CONFIG_NSH_ARGCAT is not set
> > > > # CONFIG_NSH_CMDOPT_HEXDUMP is not set
> > > > # CONFIG_NSH_CMDPARMS is not set
> > > > CONFIG_ADC=y
> > > > CONFIG_ANALOG=y
> > > > CONFIG_ARCH="arm"
> > > > CONFIG_ARCH_BOARD="phi-innovations"
> > > > CONFIG_ARCH_BOARD_STM32F4_PHI_IOT_GATEWAY=y
> > > > CONFIG_ARCH_CHIP="stm32"
> > > > CONFIG_ARCH_CHIP_STM32=y
> > > > CONFIG_ARCH_CHIP_STM32F407VG=y
> > > > CONFIG_ARCH_STACKDUMP=y
> > > > CONFIG_ARMV7M_MEMCPY=y
> > > > CONFIG_BOARDCTL_RESET=y
> > > > CONFIG_BOARDCTL_UNIQUEID=y
> > > > CONFIG_BOARDCTL_USBDEVCTRL=y
> > > > CONFIG_BOAR

Re: Problem with USB CDC initialization on board based on STM32F4DISCO

[Grr]

What you can do is compare .config generated from that defconfig to .config
generated from "./tools/configure.sh -l stm32f4discovery:usbnsh" and see
the differences. You can also compare include/nuttx/config.h from both
configs

Another approach is to start from discovery config and do the modifications
for your board. After you have it working, clone the config to a different
board name. With "make savedefconfig" you can save your working defconfig

El dom, 17 ene 2021 a las 7:51, Flavio Castro Alves Filho (<
flavio.al...@gmail.com>) escribió:

> As an additional information, if I load the STM32F4DISCO on my board, USB
> works.
>
> Em dom., 17 de jan. de 2021 às 10:43, Flavio Castro Alves Filho
>  escreveu:
> >
> > Hello,
> >
> > I am working to port NuttX on a board based on STM32F4DISCOVERY. The
> > microcontroller is the STM32F407VET6.
> >
> > USB CDC support is not initializing.
> >
> > When I plug the USB on the board, I have the following dmesg response in
> Linux:
> >
> > [517062.075048] usb usb1-port2: attempt power cycle
> > [517062.726922] usb 1-2: new full-speed USB device number 47 using
> xhci_hcd
> > [517062.727170] usb 1-2: Device not responding to setup address.
> > [517062.935148] usb 1-2: Device not responding to setup address.
> > [517063.142906] usb 1-2: device not accepting address 47, error -71
> > [517063.270916] usb 1-2: new full-speed USB device number 48 using
> xhci_hcd
> > [517063.271141] usb 1-2: Device not responding to setup address.
> > [517063.479134] usb 1-2: Device not responding to setup address.
> >
> > When I run stm32f4discovery:usbnsh on my discovery board, it works.
> >
> > I compared the defconfig from the base project and from mine and I
> > believe I have initialized everything that is related to the USB.
> >
> > Here is the defconfig for my board:
> >
> > #
> > # This file is autogenerated: PLEASE DO NOT EDIT IT.
> > #
> > # You can use "make menuconfig" to make any modifications to the
> > installed .config file.
> > # You can then do "make savedefconfig" to generate a new defconfig
> > file that includes your
> > # modifications.
> > #
> > # CONFIG_ARCH_FPU is not set
> > # CONFIG_MMCSD_MMCSUPPORT is not set
> > # CONFIG_MMCSD_SPI is not set
> > # CONFIG_NSH_ARGCAT is not set
> > # CONFIG_NSH_CMDOPT_HEXDUMP is not set
> > # CONFIG_NSH_CMDPARMS is not set
> > CONFIG_ADC=y
> > CONFIG_ANALOG=y
> > CONFIG_ARCH="arm"
> > CONFIG_ARCH_BOARD="phi-innovations"
> > CONFIG_ARCH_BOARD_STM32F4_PHI_IOT_GATEWAY=y
> > CONFIG_ARCH_CHIP="stm32"
> > CONFIG_ARCH_CHIP_STM32=y
> > CONFIG_ARCH_CHIP_STM32F407VG=y
> > CONFIG_ARCH_STACKDUMP=y
> > CONFIG_ARMV7M_MEMCPY=y
> > CONFIG_BOARDCTL_RESET=y
> > CONFIG_BOARDCTL_UNIQUEID=y
> > CONFIG_BOARDCTL_USBDEVCTRL=y
> > CONFIG_BOARD_LOOPSPERMSEC=16717
> > CONFIG_BUILTIN=y
> > CONFIG_CDCACM=y
> > CONFIG_CDCACM_CONSOLE=y
> > CONFIG_CDCACM_RXBUFSIZE=256
> > CONFIG_CDCACM_TXBUFSIZE=256
> > CONFIG_CLOCK_MONOTONIC=y
> > CONFIG_CONSOLE_SYSLOG=y
> > CONFIG_DEBUG_ASSERTIONS=y
> > CONFIG_DEBUG_DMA=y
> > CONFIG_DEBUG_DMA_ERROR=y
> > CONFIG_DEBUG_DMA_INFO=y
> > CONFIG_DEBUG_DMA_WARN=y
> > CONFIG_DEBUG_ERROR=y
> > CONFIG_DEBUG_FEATURES=y
> > CONFIG_DEBUG_FS=y
> > CONFIG_DEBUG_FS_ERROR=y
> > CONFIG_DEBUG_FS_WARN=y
> > CONFIG_DEBUG_FULLOPT=y
> > CONFIG_DEBUG_HARDFAULT_ALERT=y
> > CONFIG_DEBUG_INFO=y
> > CONFIG_DEBUG_NET=y
> > CONFIG_DEBUG_NET_ERROR=y
> > CONFIG_DEBUG_NET_INFO=y
> > CONFIG_DEBUG_NET_WARN=y
> > CONFIG_DEBUG_RTC=y
> > CONFIG_DEBUG_RTC_ERROR=y
> > CONFIG_DEBUG_RTC_INFO=y
> > CONFIG_DEBUG_RTC_WARN=y
> > CONFIG_DEBUG_SYMBOLS=y
> > CONFIG_DEBUG_WARN=y
> > CONFIG_DEV_GPIO=y
> > CONFIG_ETH0_PHY_LAN8742A=y
> > CONFIG_EXAMPLES_PPPD=y
> > CONFIG_FAT_LCNAMES=y
> > CONFIG_FAT_LFN=y
> > CONFIG_FS_FAT=y
> > CONFIG_FS_PROCFS=y
> > CONFIG_FS_SMARTFS=y
> > CONFIG_HAVE_CXX=y
> > CONFIG_HAVE_CXXINITIALIZE=y
> > CONFIG_HEAP_COLORATION=y
> > CONFIG_IDLETHREAD_STACKSIZE=2048
> > CONFIG_INTELHEX_BINARY=y
> > CONFIG_IOEXPANDER=y
> > CONFIG_LIB_HOSTNAME="STM32F4-Discovery"
> > CONFIG_MAX_TASKS=16
> > CONFIG_MMCSD=y
> > CONFIG_MMCSD_MULTIBLOCK_DISABLE=y
> > CONFIG_MMCSD_SDIO=y
> > CONFIG_MTD=y
> > CONFIG_MTD_MX25L=y
> > CONFIG_MTD_SMART=y
> > CONFIG_MTD_SMART_FSCK=y
> > CONFIG_MX25L_SPIFREQUENCY=2100
> > CONFIG_NET=y
> > CONFIG_NETDB_DNSCLIENT=y
> > CONFIG_NETINIT_DEBUG=y
> > CONFIG_NETINIT_DHCPC=y
> > CONFIG_NETINIT_DNS=y
> > CONFIG_NETINIT_DNSIPADDR=0x08080808
> > CONFIG_NETINIT_DRIPADDR=0x0a010101
> > CONFIG_NETINIT_NOMAC=y
> > CONFIG_NETINIT_THREAD=y
> > CONFIG_NETUTILS_DHCPC=y
> > CONFIG_NETUTILS_NETCAT=y
> > CONFIG_NETUTILS_PPPD_PAP=y
> > CONFIG_NET_ARP_DUMP=y
> > CONFIG_NET_ARP_SEND=y
> > CONFIG_NET_BROADCAST=y
> > CONFIG_NET_ETH_PKTSIZE=1294
> > CONFIG_NET_ICMP=y
> > CONFIG_NET_ICMP_SOCKET=y
> > CONFIG_NET_SOCKOPTS=y
> > CONFIG_NET_SOLINGER=y
> > CONFIG_NET_STATISTICS=y
> > CONFIG_NET_TCP=y
> > CONFIG_NET_TCPBACKLOG=y
> > CONFIG_NET_TCPURGDATA=y
> > CONFIG_NET_TCP_KEEPALIVE=y
> > CONFIG_NET_TCP_WRITE_BUFFERS=y
> > CONFIG_NET_UDP=y
> > CONFIG_NET_UDP_CHECK

Re: SPI Driver Balkanization

[Grr]

That's exactly what I need: an example to follow. I'll check it

Thanks, Alan

Grr

El vie, 8 ene 2021 a las 13:10, Alan Carvalho de Assis ()
escribió:

> On 1/8/21, Abdelatif Guettouche  wrote:
> >> The biggest issue I see is that drivers are hard coding the CS reference
> >> like the MCP2515 which always uses SPIDEV_CANBUS(0), this should be
> >> passed
> >> in to the initialization of all SPI devices and owned by the private
> >> device
> >> structure not hard coded. I could even see the argument for this being
> >> part
> >> of the generic SPI interface structure.
> >
> >
> > Some drivers do do that.  They accept a "devno" argument in their init
> > function and then pass it with the SPI calls.
> >
>
> Yes, an example is this one: nuttx/drivers/sensors/max31855.c
>
> When I created the mcp2515 driver I wasn't considering to use more
> than one CAN module by board. Sorry, my fault!
>
> BTW, the modification is simples. Grr, just look how it is done in the
> max31855 and do the same for mcp2515.
>
> The board initialization for max31855 is here:
> nuttx/boards/arm/stm32/common/src/stm32_max31855.c
>
> BR,
>
> Alan
>

Re: SPI Driver Balkanization

[Grr]

Some drivers do do that.  They accept a "devno" argument in their init
> function and then pass it with the SPI calls.
>

If *every* driver *must* do that, problem solved


>
>
> On Fri, Jan 8, 2021 at 7:41 PM Brennan Ashton 
> wrote:
> >
> > On Fri, Jan 8, 2021, 10:35 AM Abdelatif Guettouche <
> > abdelatif.guettou...@gmail.com> wrote:
> >
> > > >  One problem was I didn't understand current CS definition. I thought
> > > > #define GPIO_MCP2515_CS
>  (GPIO_OUTPUT|GPIO_CNF_OUTPP|GPIO_MODE_50MHz|\
> > > >GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4)
> > > > created a bitmask named GPIO_MCP2515_CS but no, it creates an ASCII
> > > string
> > > > that does its magic in stm32_configgpio()
> > >
> > >
> > > That doesn't create an ASCII string.  GPIOs follow a simple encoding
> > > that changes from chip to chip depending on the capabilities of the
> > > chip.
> > >
> > > The CS pin isn't part of the chip driver because it's (for the most
> > > cases) a normal GPIO that changes from board to board.
> > > The board logic that adds a CS pin is very simple and doesn't require
> > > deep kernel knowledge.
> > >
> >
> > A key exception is when the CS is behind an IO expander. Which the
> current
> > design allows.
> >
> > The biggest issue I see is that drivers are hard coding the CS reference
> > like the MCP2515 which always uses SPIDEV_CANBUS(0), this should be
> passed
> > in to the initialization of all SPI devices and owned by the private
> device
> > structure not hard coded. I could even see the argument for this being
> part
> > of the generic SPI interface structure.
> >
> > >
>

Re: SPI Driver Balkanization

[Grr]

Thank you for the response

Hi,
> some of the points you mention about drivers being tied to board logic and
> the fact that initialization is "hard coded" is something I once tried to
> improve
> when I worked on "device tree" support (discussion at
> https://github.com/apache/incubator-nuttx/issues/1020). However as this
> was
> quite a big undertaking it was shelved for the time being. In that regard,
> what I can say is:
>
> - With the introduction of "common board logic", drivers support can be
> implemented
> at the board-family level (e.g.: stm32). This reduces the necessary code
> to support
> the driver in another board of the family to a single initialization call
> and pin definitions
>
> - Right now NuttX usually ties resource definition ("does the bard have
> device X") to driver
> support ("is driver for device X enabled") by conditional compilation on
> board logic initialization.
> So, multiple instances of a device require custom handling (besides the
> fact that the driver needs
> to indeed support multiple instances).
>
> As a result of the above, indeed trying to expose a device usually
> requires changing code
> in board logic. With devicetree I tried to tackle that but I realized
> previous steps were
> required to improve this in NuttX (first one was to reduce duplicated
> code). For this reason
> I still have on my bucket list to improve general handling of device
> drivers.


The way I envisioned
> is to go towards an unified driver model/interface based on callbacks
> (register, initialize, uninitialize).
> If all drivers implement this, initialization can be handled by generic
> code invoking the callbacks
> (from all instances of drivers defined in a constant array) at a higher
> level than board logic.
>

You mean what spi_ops_s already does but in a general way. That sounds
great and I was considering something like that to generalize Peter van der
Perk's SocketCAN driver and use it with different CAN controllers

struct spi_ops_s
{
  CODE int  (*lock)(FAR struct spi_dev_s *dev, bool lock);
  CODE void (*select)(FAR struct spi_dev_s *dev, uint32_t devid,
  bool selected);
  CODE uint32_t (*setfrequency)(FAR struct spi_dev_s *dev,
  uint32_t frequency);
  CODE int  (*setdelay)(FAR struct spi_dev_s *dev, uint32_t a,
  uint32_t b, uint32_t c);
...
}

The final step to handle all previous mentioned limitations would be to use
> device tree to declare
> existing resources and generate the driver-instance array automatically.
> As device trees naturally
> handle overlaying, this would allow for a base resource definition for all
> on-board devices and then
> have the user to extend/override this with some user-defined device tree.
> In there you could add off-board
> devices, which also enables support for multiple instances.
>

That's exactly  what I want, albeit not as ambitious. My guess is it can be
half accomplished right now with CS abstraction, Kconfig magic and defining
a standard model for driver structure to which existing drivers can be
slowly migrated

One problem was I didn't understand current CS definition. I thought

#define GPIO_MCP2515_CS   (GPIO_OUTPUT|GPIO_CNF_OUTPP|GPIO_MODE_50MHz|\
   GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4)

created a bitmask named GPIO_MCP2515_CS but no, it creates an ASCII string
that does its magic in stm32_configgpio()

My question is if the whole *_configgpio() family does the same everywhere
so GPIO_MCP2515_CS can be applied correctly to any _configgpio() function
and it's only a matter of generalizing the existing structure. In that case
Brennan is correct it's already abstracted and it's only a matter of using
it to avoid board "lock-in".

>
> Hopefully sometime in the future we can discuss something along these
> lines to be added to NuttX as
> I think it would be very valuable.
>

Maybe we could start now by creating the seed of the driver model and the
user config part. That would be very nice and, I hope, very achievable

TIA
Grr


Best,
> Matias
>



>
> On Fri, Jan 8, 2021, at 01:19, Grr wrote:
> > I've been working towards creating a unified (character or SocketCAN)
> > driver model for SPI CAN controller MCP2515 and I found out that SPI_*
> > macro family allow platform-neutral SPI device control but there's one
> > thing I cannot find:
> >
> > Is it possible to abstract chip select (CS) definition and usage in a
> > similar way?
> >
> > Question arises from the fact that most SPI drivers are initialized (and
> > *de facto supported*) per board but many (if not most) boards offer SPI
> > external connectivity 

Re: SPI Driver Balkanization

[Grr]

This is board and arch specific and cannot be more generalized than that.
> They will have different requirements for pullups, speed, etc.  The define
> should also start with BOARD_ but some use GPIO_.  This is the case
> for all PINs including UART, GPIO, SPI, USB, etc...
>

I mean after that arch and board-specific config, you end up with a list of
general pins available (CS1, CS2, CS3...) which are equivalent to SPI_* in
that they're valid everywhere and can be used despite architecture, SPI
master or bus number


> and the drivers will already have conditionals on those being defined.
>

Just like SPI_* don't break

>
> SPI is just a little special because you dont _need_ a CS gpio pin,
> but frequently you want it.


You need CS pins when you have more than one SPI device in a bus (something
very frequent). For example, all this comes from the fact that I'm
designing a control system that would benefit from having two CAN busses
instead of just one


> So you end up with the board specific hooks
> for what pin to turn on.
> as is here
>
> https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140
>
> SPI drivers cannot depend on a fixed name for the CS pin because you may
> have multiple instances (what I thought you were asking to support)
>
> It's a fixed name in the sense CS1 is defined in all boards and archs so I
can write my driver using SPI_SELECT with CS1 and it will work everywhere


> You just update the define in your board.h file to include a mapping for
> what
> is wired up to pin 5.


I cannot do that if I'm not a kernel developer

>

> When you are bringing up your board one of the first
> things you should do is define the pins in your board.h
>

I'm not bringing up a new board but connecting an *external* supported chip
to a supported board via a standard bus


> Changing how pins are defined would break everyone so that is unlikely to
> change, and it is also not really something that can easily be mapped to
> Kconfig.
>

It doesn't break anything if it's parallel to everything just like SPI_*
macros are

Grr

Re: SPI Driver Balkanization

[Grr]

It is abstracted, for example see this file.

>
> https://github.com/apache/incubator-nuttx/blob/cdd111a1faec9b40b707797e00c4afae4956fb3f/boards/arm/stm32/nucleo-f4x1re/src/stm32_spi.c#L140
>

You mean  GPIO_MCP2515_CS? I don't quite understand its definition

#define GPIO_MCP2515_CS   (GPIO_OUTPUT|GPIO_OTYPER_PP(0)|GPIO_SPEED_2MHz|\
   GPIO_OUTPUT_SET|GPIO_PORTA|GPIO_PIN4)

I guess it's a way to combine different configuration bits with pin 4.

Problem is it's only defined for pin 4 and only in a handful of STM32
boards.

What happens if I want to use that driver with a PIC32MX board and I'm not
a kernel developer?
What happens if pin 4 is already used and I *need* to use pin 5 and again
I'm not a kernel developer?

My idea is to bring that level of configuration ability into menuconfig

Are those GPIO_* macros work across architectures so they can be brought to
menuconfig and combined there in a newbie-friendly way? It seems
GPIO_OUTPUT exists in all architectures but I don't know it if works the
same way everywhere

SPI Driver Balkanization

[Grr]

I've been working towards creating a unified (character or SocketCAN)
driver model for SPI CAN controller MCP2515 and I found out that SPI_*
macro family allow platform-neutral SPI device control but there's one
thing I cannot find:

Is it possible to abstract chip select (CS) definition and usage in a
similar way?

Question arises from the fact that most SPI drivers are initialized (and
*de facto supported*) per board but many (if not most) boards offer SPI
external connectivity so any *collection* of SPI devices can be connected
to any such board

Since most drivers are initialized *per board*, any given *supported*
device cannot be used in any given board without initialization being
"ported" to that board, something a basic user cannot do

Another related problem (discussed between Gregory Nutt and Sebastien
Lorquet in
https://nuttx.yahoogroups.narkive.com/7qv88uHr/proposal-support-multiple-spi-devices-of-same-type)
is support of multiple similar devices in the same bus

The solution to problem A is to have an abstraction mechanism for CS that
can be used not only in driver code but in menuconfig so user is able to
configure any possible combination of boards and *external* busses and
devices to exploit NuttX device support.

Is there or could be such abstraction mechanism to complement SPI_*?

For problem B, I've seen hints in Bob Feretich's ADXL372 driver but
couldn't find use of it to learn how. I've seen device IDs have an index
but I still don't know how its used

Any hint or opinion is greatly appreciated

TIA

Grr

Re: Handling of newbie-oriented fixes

[Grr]

I just finished basic edition but my connection is veeery slow right now so
I'll upload it until tomorrow morning

I incorporated the ASCII function map and completely linearized the document

I need to check the last part about nsh and such but the rest of the
document is exact and up to date



El mié, 6 ene 2021 a las 2:23, Brennan Ashton ()
escribió:

> On Tue, Jan 5, 2021 at 2:46 PM Grr  wrote:
> >
> > Thank you for your response. I'll check that
> I assume that this is your github user https://github.com/sigdl  If
> that is the case
> you can create your PR against the Apache repo with this link:
> https://github.com/apache/incubator-nuttx/compare/master...sigdl:master
>
> >
> > I also offered a function map to add to your
> NuttX+Initialization+Sequence
> > document
> >
> > Please check
> https://www.mail-archive.com/dev@nuttx.apache.org/msg05417.html
> > and let me know if it's useful or how can it be improved to be so
>
> Sorry I had forgotten to respond, eventually I think most of that Wiki
> will make its way into
> the documentation over at nuttx.apache.org/docs/latest but that will
> take quite some
> time, so keeping the wiki up to date would be most welcome.  If you create
> an
> account and send me the username I will be happy to give you
> permissions to edit that
> page as you think it makes sense.
>
> --Brennan
>

Re: Handling of newbie-oriented fixes

[Grr]

Thank you for your response. I'll check that

I also offered a function map to add to your NuttX+Initialization+Sequence
document

Please check https://www.mail-archive.com/dev@nuttx.apache.org/msg05417.html
and let me know if it's useful or how can it be improved to be so

TIA

Grr

El mar, 5 ene 2021 a las 16:31, Brennan Ashton ()
escribió:

> You can still open the PR in GitHub against the NuttX repo (with the extra
> stuff from Peter's repo) , there is a option to select a different repo,
> and we can either cherry pick your change for you or walk you through how
> to do that.
> Feel free to tag me in it @btashton
>
> Thanks for contributing!
>
> --Brennan
>
> On Tue, Jan 5, 2021, 1:13 PM Grr  wrote:
>
> > I have several commits with fixes related to newbie issues
> >
> > -Avoid compilation crash due to enabling CONFIG_NET without board
> > networking support
> >
> > -Avoid compilation crash due to CONFIG_NET_ICMP_SOCKET missing
> > NET_READAHEAD
> >
> > and so on
> >
> > Problem is I can't make a PR on incubator-nuttx because my fork is not
> from
> > it but from Peter van der Perk's fork
> >
> > What would be the best way to handle this without bothering Peter to
> > process every one of my fixes?
> >
> > TIA
> >
> > Grr
> >
>

Handling of newbie-oriented fixes

[Grr]

I have several commits with fixes related to newbie issues

-Avoid compilation crash due to enabling CONFIG_NET without board
networking support

-Avoid compilation crash due to CONFIG_NET_ICMP_SOCKET missing NET_READAHEAD

and so on

Problem is I can't make a PR on incubator-nuttx because my fork is not from
it but from Peter van der Perk's fork

What would be the best way to handle this without bothering Peter to
process every one of my fixes?

TIA

Grr

Re: Basic Documentation Update

[Grr]

Thanks for the response

I attach the map now. Any question or criticism welcome

I know nothing about mermaid or SVG but I can process the map with aalib if
requested  ;)

Nathan is correct of course. My focus is on novice's experience. The Wiki
information is the most visible and the more accurate, clear and extensive
it is, the better for anyone like me who wants to get involved in
developing and using NuttX

TIA
Grr

El jue, 31 dic 2020 a las 9:37, Nathan Hartman ()
escribió:

> On Thu, Dec 31, 2020 at 10:03 AM Maciej Wójcik  wrote:
> >
> > Hello,
> >
> > I would suggest making merge request to the documentation inside
> > repository. Confluence document could be copied there and then ascii art
> > added.
> >
> > But it is my personal opinion. Not sure what was decided about confluence
> > wiki. Yet, I had an impression that documentation should be gradually
> moved
> > to the repository.
>
> Yes, I agree. I think documentation should be in the repository rather
> than Confluence because anyone can open a pull request for the
> repository. We're more limited with Confluence.
>
> > Regarding ascii art itself, why not make a normal diagram. I think there
> is
> > simple graphing syntax available called mermaid or you could attach svg.
>
> ASCII art could be a good fit for the many README.txt files we have.
>
> Even if it doesn't go in a README.txt, if it's a good diagram then in
> the interest of making the information available to everyone, I think
> it should be added in documentation first and then the format can
> always be changed and made more fancy later.
>
> Besides, there's something nostalgic about ASCII-art. :-)
>
> Cheers,
> Nathan
>

__start()-stm32_start.c
|
+stm32_boardinitialize()-stm32_boot.c:BOARD_DEPENDANT
||
|+stm32_spidev_initialize()-stm32_spi.c:ONLY CHIP SELECTS
|+stm32_usbinitialize()-
|+stm32_netinitialize()-
|+board_autoled_initialize()-
|  
nx_start()-nx_start.c
|  
+net_initialize()-net_initialize.c
||   
|+net_lockinitialize()
|+mld_initialize()
|+can_initialize()
|+netlink_initialize()
|+tcp_initialize()
|+udp_initialize()
|+usrsock_initialize()
|
+up_initialize()-arm_initialize.c
||  
|+arm_dmainitialize()
|+Config basic /dev nodes
|+arm_serialinit()
|+Console Init
|+Crypto Config
|+arm_netinitialize()
|||
||+stm32_spibus_initialize()
||
||
|+arm_usbinitialize()
|+L2 Cache Init
|
+board_early_initialize()
+g_nx_initstate = OSINIT_HARDWARE
+shm_initialize()
+lib_initialize()
+binfmt_initialize()
+Start SMP
+syslog_initialize()
+g_nx_initstate = OSINIT_OSREADY
+DEBUGVERIFY(nx_bringup())
||
|+nx_create_initthread
| |  
| +nx_start_task()
|  |
|  +nx_start_application()
|   |
|   
+board_late_initialize()-stm32_boot.c:BOARD_DEPENDANT
||
|+stm32_bringup()
+-kmm_givesemaphore() |
+-up_idle()   +stm32_i2ctool()
  
+board_bmp180_initialize()
  
+stm32_sdio_initialize()
  
+stm32_usbhost_initialize()
  +stm32_pwm_setup()
  +stm32_can_setup()
  
+stm32_mcp2515initialize()
  +

Basic Documentation Update

[Grr]

Hello to all.

I'm new into NuttX development and I made an ASCII-art function map of
NuttX initialization to hep update and improve
https://cwiki.apache.org/confluence/display/NUTTX/NuttX+Initialization+Sequence
and I'd like to know of Brennan Ashton thinks it can be incorporated into
his document

My map is based on startup for stm32f4discovery board and doesn't have
_all_ the functions but covers pretty much all the most important to give a
very good idea of initialization in a graphic manner

I'd also like to know what's the best practice to update text of the
aforementioned document since there are some parts to be updated according
to this up-to-date map

I read somewhere I cannot attach file here so please tell me how to share it

Thanks in advance