build board from custom directory
A few weeks ago I moved my custom board out of the NuttX "nuttx/nuttx/boards" tree to a folder "nuttx/CustomBoards". Make menuconfig allows you to specify that folder (CONFIG_ARCH_BOARD_CUSTOM_DIR=) To try and rule out .config errors for some issues I have at the moment I did a make distclean. Which wipes out the .config and the reference to my custom board directory. What is the correct syntax to tell configure.sh that the board is in a custom folder, please?
RP2040 SPI in common?
A recent change (e8f4d74ad0c33389c1094c3ca6c10a6336d8fbe7) moved the individual rp2040_spi.c into the common directory. How can a board with different chip select GPIO usage have a board specific setup? I don't see a way to disable the common implementation. -- B.Walter https://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Re: build board from custom directory
There is an option for relative links. The you can pass the path to configure.sh Like configure.sh ../boards/custom-board/config/nsh On Thu, Sep 15, 2022 at 12:25 PM TimH wrote: > A few weeks ago I moved my custom board out of the NuttX > "nuttx/nuttx/boards" tree to a folder "nuttx/CustomBoards". > > > > Make menuconfig allows you to specify that folder > (CONFIG_ARCH_BOARD_CUSTOM_DIR=) > > > > To try and rule out .config errors for some issues I have at the moment I > did a make distclean. Which wipes out the .config and the reference to my > custom board directory. > > > > What is the correct syntax to tell configure.sh that the board is in a > custom folder, please? > >
RE: build board from custom directory
Thank you! I was trying to run it like this: ./tools/configure.sh -l ../CustomBoards/board-name:config-name Perhaps this needs to be added to the configure.sh help text? >-Original Message- >From: Abdelatif Guettouche >Sent: 15 September 2022 11:59 >To: dev@nuttx.apache.org >Subject: Re: build board from custom directory > >There is an option for relative links. The you can pass the path to >configure.sh >Like configure.sh ../boards/custom-board/config/nsh > >On Thu, Sep 15, 2022 at 12:25 PM TimH wrote: > >> A few weeks ago I moved my custom board out of the NuttX >> "nuttx/nuttx/boards" tree to a folder "nuttx/CustomBoards". >> >> >> >> Make menuconfig allows you to specify that folder >> (CONFIG_ARCH_BOARD_CUSTOM_DIR=) >> >> >> >> To try and rule out .config errors for some issues I have at the >> moment I did a make distclean. Which wipes out the .config and the >> reference to my custom board directory. >> >> >> >> What is the correct syntax to tell configure.sh that the board is in a >> custom folder, please? >> >>
RE: g_inode_sem.holder = -1
Thanks Greg - knowing that -1 is not error means I'm not wasting time investigating that, at least! The problem is unrelated to the touchscreen and more an RTOS/NuttX configuration error I think - the ADC example app will run once quite happily, with either 1 sample or 0 (i.e. run forever) - but if I try and run it a second time it gets stuck forever, just like the TS example app does. Something somewhere is misbehaving and causing semwait to wait forever so I'm going through pulling out stuff I've put in to see if it's down to me! >-Original Message- >From: Gregory Nutt >Sent: 14 September 2022 21:07 >To: dev@nuttx.apache.org >Subject: Re: g_inode_sem.holder = -1 > >> The only clue I have is that g_inode_sem.holder is set to -1, which >intuitively seems wrong to me, but this is way beyond me at this time of my >NuttX journey! > >The value -1 is not an error. It means that one thread is waiting to take a >count from the semaphore. The value of the semaphore was 0 when that >thread called sem_wait() (meaning that no counts are available). The count is >decremented to -1 while the thread is suspended waiting for a count. > >So this sound like the thread is waiting for an event that never occurs. > > >On Wed, Sep 14, 2022 at 11:23 AM TimH wrote: > >> Trying to get the touchscreen on my board registered and tested. It >> *seems* to register, and at one random point the touchscreen example >> app did report something that looked useful but I now cannot make any >sense of it. >> >> >> >> The ADC itself is registered and the ADC example app works fine, but >> when I try and open the TS device (/dev/input0) it hangs in >> inode_semtake when the call to nxsem_wait_uninterruptible is called. >> >> >> >> The only clue I have is that g_inode_sem.holder is set to -1, which >> intuitively seems wrong to me, but this is way beyond me at this time >> of my NuttX journey! >> >> >> >> Otherwise I'm suspecting a problem/mismatch with structs perhaps from >> the need to cast (think that's what it's called?) the adc_dev_s struct >> >> >> >> ret = sam_tsd_register( (struct sam_adc_s *) adc, 0) >> >> >> >> Any suggestions very welcome, as always :) >> >>
Mailing list duplicate header error
This is not about nuttx, but about this list. Just a few minutes ago I had send a mail to this list. The returned mail from the list was tagged as spam. It wasn't enough to reject the mail, but tag it, so that it was filed into the spam folder. The major reason (rspamd default config) was 7 points for duplicate unique headers. I tend to send mail with a reply-to header. The list added a second header, but left mine, so in the end there had been two disagreeing reply-to headers. -- B.Walter https://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Re: RP2040 SPI in common?
Hi Bernd, Yes, I think the current implementation is fixed to allow only 1 CS per RP2040 SPI. That is not ideal (read: "incorrect"). It is possible to have the rp2040_spi.c as a common boards file, but the CS should be extended, i.e.: #if defined(LCDxyz) || defined(LCDwku) ... rp2040_gpio_put(BOARD_RP2040_SPI0_DISPLAY_CS, !selected); #endif #if defined(AUDIOCODECtqj) || defined(AUDIOCODECcnp) ... rp2040_gpio_put(BOARD_RP2040_SPI0_AUDIO_CS, !selected); #endif etc... This way the common rp2040_spi.c file could support many more devices than current implementation. BR, Alan On 9/15/22, Bernd Walter wrote: > A recent change (e8f4d74ad0c33389c1094c3ca6c10a6336d8fbe7) moved the > individual rp2040_spi.c into the common directory. > How can a board with different chip select GPIO usage have a board > specific setup? > I don't see a way to disable the common implementation. > > -- > B.Walter https://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. >
Re: RP2040 SPI in common?
Actually you can include support for multiple devices of same type in
the same SPI bus:
#if defined(LCDxyz) || defined(LCDwku) ...
switch (devid)
{
case SPIDEV_DISPLAY(0):
/* Set the GPIO low to select and high to de-select */
rp2040_gpio_put(BOARD_RP2040_SPI0_DISPLAY_CS0, !selected);
break;
case SPIDEV_DISPLAY(1):
/* Set the GPIO low to select and high to de-select */
rp2040_gpio_put(BOARD_RP2040_SPI0_DISPLAY_CS1, !selected);
break;
case SPIDEV_DISPLAY(2):
/* Set the GPIO low to select and high to de-select */
rp2040_gpio_put(BOARD_RP2040_SPI0_DISPLAY_CS2, !selected);
break;
case SPIDEV_DISPLAY(3):
/* Set the GPIO low to select and high to de-select */
rp2040_gpio_put(BOARD_RP2040_SPI0_DISPLAY_CS3, !selected);
break;
}
#endif
Maybe we could implement this solution for other boards that have
common board directory.
BR,
Alan
On 9/15/22, Alan Carvalho de Assis wrote:
> Hi Bernd,
>
> Yes, I think the current implementation is fixed to allow only 1 CS
> per RP2040 SPI.
>
> That is not ideal (read: "incorrect").
>
> It is possible to have the rp2040_spi.c as a common boards file, but
> the CS should be extended, i.e.:
>
> #if defined(LCDxyz) || defined(LCDwku) ...
> rp2040_gpio_put(BOARD_RP2040_SPI0_DISPLAY_CS, !selected);
> #endif
>
> #if defined(AUDIOCODECtqj) || defined(AUDIOCODECcnp) ...
> rp2040_gpio_put(BOARD_RP2040_SPI0_AUDIO_CS, !selected);
> #endif
>
> etc...
>
> This way the common rp2040_spi.c file could support many more devices
> than current implementation.
>
> BR,
>
> Alan
>
> On 9/15/22, Bernd Walter wrote:
>> A recent change (e8f4d74ad0c33389c1094c3ca6c10a6336d8fbe7) moved the
>> individual rp2040_spi.c into the common directory.
>> How can a board with different chip select GPIO usage have a board
>> specific setup?
>> I don't see a way to disable the common implementation.
>>
>> --
>> B.Walter https://www.bwct.de
>> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>>
>
ADC device close and IRQ
I have sorted the touchscreen on the SAMA5D2 - minor errors in the init code "as supplied" meaning a couple of registers were not set up right. I have also found that priority inheritance is needed, at least for the ADC example app: I've not sat back or read my books to see why, but it works for now. The issue I now have is that the call to close the ADC device, as opened by the example app, calls sam_adc_shutdown which disables interrupts and detaches them: up_disable_irq(SAM_IRQ_ADC) irq_detach(SAM_IRQ_ADC) Some other arch adc drivers do this too. The problem is that the enabling and attaching is done from sam_adc_initialize, therefore when the device is first registered from board_bringug. The result is that you can never again open the adc for business until a board reset. That doesn't seem right to me? The easy option is to comment out the two calls, but I don't know if that's deemed acceptable, especially as other adc drivers do the same?
Re: RP2040 SPI in common?
On Thu, Sep 15, 2022 at 09:48:42AM -0300, Alan Carvalho de Assis wrote:
> Actually you can include support for multiple devices of same type in
> the same SPI bus:
>
> #if defined(LCDxyz) || defined(LCDwku) ...
> switch (devid)
> {
> case SPIDEV_DISPLAY(0):
> /* Set the GPIO low to select and high to de-select */
>
> rp2040_gpio_put(BOARD_RP2040_SPI0_DISPLAY_CS0, !selected);
> break;
Ok - I see where this is going.
But is it really reasonable to add such a whole bunch of generic code?
I'm used to add it in my own board code, if I have additional devices.
--
B.Walter https://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Re: ADC device close and IRQ
Hi, > The easy option is to comment out the two calls, but I don't know if that' s > deemed acceptable, especially as other adc drivers do the same? I do not think this is correct since it is better to disable and detach the interrupt when we close the device. Instead I think the the enabling and attaching should be moved from sam_adc_ initialize() to sam_adc_setup() which is called every time the driver is opened from the application. Similar to SAMv7 ADC driver: https://github.com/apache/incubator-nuttx/blob/master/arch/arm/src/samv7/sam _afec.c#L845 This would ensure the interrupt is enabled and attached when the driver is opened and disabled and detached when it is closed. Best regards, Michal Lenc
RE: ADC device close and IRQ
Makes sense! I searched other drivers for where they called the detach but didn't think to see where those other drivers called the attach! Thanks :) >-Original Message- >From: Michal Lenc >Subject: Re: ADC device close and IRQ > >Hi, > >> The easy option is to comment out the two calls, but I don't know if that' >s >> deemed acceptable, especially as other adc drivers do the same? > > >I do not think this is correct since it is better to disable and detach the >interrupt > >when we close the device. > > >Instead I think the the enabling and attaching should be moved >from sam_adc_ >initialize() > >to sam_adc_setup() which is called every time the driver is opened from the >application. > >Similar to SAMv7 ADC driver: > >https://github.com/apache/incubator- >nuttx/blob/master/arch/arm/src/samv7/sam >_afec.c#L845 > > > > > >This would ensure the interrupt is enabled and attached when the driver is >opened > > >and disabled and detached when it is closed. > > > > >Best regards, > >Michal Lenc
Re: build board from custom directory
On Thu, Sep 15, 2022 at 7:06 AM TimH wrote: > Perhaps this needs to be added to the configure.sh help text? I agree! See PR-7103: https://github.com/apache/incubator-nuttx/pull/7103 Help with reviewing that will be appreciated! Nathan
Re: How to use the w5500 network module？
Hi Prelude,
The W5500 initialization code is already merged into mainline:
https://github.com/apache/incubator-nuttx/blob/master/boards/arm/stm32/stm32f4discovery/src/stm32_w5500.c
Did you have the chance to test it?
BR,
Alan
On 9/14/22, Alan Carvalho de Assis wrote:
> Hi Prelude and Michael,
>
> Yes, I'm adding W5500 to ESP32-S2 to test the SPI driver that I implemented
> and because I was facing some issues on it I decided to test on
> STM32F4Discovery board. I'll submit the PR to mainline.
>
> I got it working, but for some reason it is stopping after 5 pings:
> https://pastebin.com/raw/8VqpxfMw
>
> This behavior is consistent, everytime I reset the board it stops after 5th
> ping.
>
> Which board are you planning to use?
>
> BR,
>
> Alan
>
> On Wednesday, September 14, 2022, Michael Jung
> wrote:
>
>> Hello,
>>
>> I did implement the w5500 device driver, but I am only using it on a
>> proprietary custom board at the moment. Alan is currently working on
>> using
>> the w5500 with the STM32F4Discovery board. Apparently there are still
>> some
>> issues, but I guess once those are resolved Alan will upstream the
>> respective code.
>>
>> Bye,
>> Michael
>>
>> On Wed, Sep 14, 2022 at 11:51 AM prelude wrote:
>>
>> > I saw the driver code of the w5500 on Nuttx, but I did not find any
>> > routine using these driver codes. The w5500_initialize interface has
>> > not
>> > been called by any code. Have any friends used the w5500 on nuttx?
>> >
>> >
>> > int w5500_initialize(FAR struct spi_dev_s *spi_dev,
>> > FAR const struct w5500_lower_s *lower,
>> > unsigned int devno)
>> > {
>> > FAR struct w5500_driver_s *self;
>> >
>> >
>> >
>> >
>> >
>>
>
