Re: DALI Interface Proposal

[murat tologlu]

Wow! I am very glad to see that you are so involved in this subject. I have to 
be worthy of your attention.

Firstly, let me explain what I am thinking about Hasseb USB-Dali  Master 
device. You can consider it in place of the USB-RS485 Converter in Nuttx Modbus 
tutorial ( http://ta1db.5g.com.tr/nuttx-modbus-setup.jpg  ). For me it is just 
a development tool which can be used for development and test purposes. Indeed, 
it has a proprietary interface which is made with a LPC1343 but our aim is not 
to make a usb-dali converter. On the other hand if we look at it's schematic 
diagram (can be downloaded here http://hasseb.fi/dali/dali2.zip )  we see 
another example of a dali interface and a dali power supply. Yes, it would be 
very good if we could find a cheaper similar device, without tax it is 76,61 € 
for bank transfer payments, offers free shipment, €15 for priority mail. 

Arduino Dali Shield ( https://www.ebay.it/itm/254211672779 ) can be considered 
as an alternative, however it is not the same thing, we have to setup another 
embedded environment with an Arduino or something, while all of us have a pc in 
front of us. Furthermore it's price is €34,50, together with €39 for 
international shipment the price comes to € 73,5 which is similar to cost of 
the Hasseb, furthermore it still requires a 24V power supply ( Hasseb includes 
the psu ). I am not making marketing 😊 just comparing. Infineon development 
tools are too complex and expensive also.

Dali power supply is just an LM317 with a 250 mA current limiter. Dali 
interface is just two opto-couplers together with a few components. For those 
who want to buy a ready made Dali interface I think the best choice is Mikroe 
Dali 2 Click ( https://www.mikroe.com/dali-2-click ) however I may consider to 
make it on a breadboard instead of dealing with international ordering details 
because it is a very simple circuit.

Regarding LED-Warrior14 chip and the modules made with it, yes, it is 
interesting, it frees us dealing with Manchester encoding - decoding process 
etc., it is easier to send and receive Dali commands through I2C interface. If 
I would be alone and doing experiments by myself then I would consider using 
this part. However, I think this shouldn't be a solution that we offer to the 
Nuttx community here. As Alan said Manchester encoding can be implemented using 
GPIO and free-running timer. Afterwards nobody needs to buy and use a special 
chip anymore.

This is a good example for us: https://www.mdpi.com/2079-9292/8/9/1021/htm 


On 2021/04/19 20:06:32, Gregory Nutt  wrote: 
> The Infineon Dali Arduino board used a similar Infineon XC836 part that 
> has a UART interface.
> 
> Greg
> 
> On 4/19/2021 1:35 PM, Alan Carvalho de Assis wrote:
> > Hi Greg,
> >
> > This LW14 is interesting! It is possible to buy a module with it to
> > use the I2C interface with any board (don't need to be an Arduino
> > form-factor) see:
> >
> > http://www.saelig.com/product/lw14-02mod.htm
> >
> > I think the shipping cost will be higher the the product.
> >
> > BR,
> >
> > Alan
> >
> > On 4/19/21, Gregory Nutt  wrote:
> >> Hi, Murat,
> >>
> >> At 95 euros that could be a turn off for some hobbyist.  I looked around
> >> for a low cost solution and found two pretty common solutions.
> >>
> >> 1. Aruino Dali Shield.  There are shields like the daliMaster
> >> https://github.com/davideloba/daliMaster that are reasonably priced.
> >> These have an I2C interface and bridge to the Dali bus via
> >> https://www.codemercs.com/downloads/ledwarrior/LW14_Datasheet.pdf
> >>
> >> 2. The Mikroe Dali 2 Click is also a good deal:
> >> https://www.mikroe.com/dali-2-click .  This uses a GPIO interface
> >> directly to the Dali bus so must be a big-bang interface:
> >> https://download.mikroe.com/documents/add-on-boards/click/dali-2/dali-2-click-schematic-v100.pdf
> >>
> >> . But Mikroe does have a library for the Click board so that should not
> >> be too bad.
> >>
> >> One thing this says to me is that there needs to be a clear separation
> >> between the application which should be communicating in in high level
> >> commands (telegrams).  I am thinking:
> >>
> >> - There could be I2C and bit-bang drivers in drivers/dali that would be
> >> capable of sending/receiving one telegram of all supported lengths.
> >> This would export a common driver interface (IOCTLs and read/write
> >> behaviors).
> >>
> >> - A higher level, Dali interace in apps/dali that understands command
> >> semantics and protocols.  This should work with any lower level
> >> implementation.
> >>
> >> I am thinking about buying the Arduino board.  I imagine that the I2C
> >> interface is easier to use and the LW14 is well documented.  Do you have
> >> any insight into that part?
> >>
> >> Greg
> >>
> >>
> >> On 4/19/2021 2:47 AM, murat tologlu wrote:
> >>> Hi Greg,
> >>>
> >>> I am going to order  this  (
> >>> http://www.hasseb.fi/shop2/index.php?route=product/product&product_id=50 )
> >>> USB Dali-2 

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

FUSB301 driver

[Tim]

I am in need of a driver for an FUSB301 USB C Controller/PD device. I see
there are drivers for the FUSB301 and FUSB303 but not the FUSB302.

 

Before I have a stab at porting the outline code I already have for this
device, and finishing it off to become a "proper" NuttX driver (and
potentially making it my first ever contribution), I thought I would ask
first to see if there is one lurking somewhere and I just missed it?

 

Also, a question from an old-school SW developer and (therefore) GitHub &
Apache/incubator newbie:  if I simply want to ask advice do I still email
dev@nuttx.apache.org   or should it be to a
different email address? I see some emails I get from the reflector (if
that's what it's called) have an unsubscribe option, whereas others do not
and it seems to relate to how the question/comment has originated? Be kind
to me :)

 

Thanks,

 

Tim Hardisty

Re: FUSB301 driver

[Nathan Hartman]

On Wed, Apr 21, 2021 at 9:04 AM Tim  wrote:

> I am in need of a driver for an FUSB301 USB C Controller/PD device. I see
> there are drivers for the FUSB301 and FUSB303 but not the FUSB302.
>
>
>
> Before I have a stab at porting the outline code I already have for this
> device, and finishing it off to become a "proper" NuttX driver (and
> potentially making it my first ever contribution), I thought I would ask
> first to see if there is one lurking somewhere and I just missed it?
>
>
>
> Also, a question from an old-school SW developer and (therefore) GitHub &
> Apache/incubator newbie:  if I simply want to ask advice do I still email
> dev@nuttx.apache.org   or should it be to a
> different email address? I see some emails I get from the reflector (if
> that's what it's called) have an unsubscribe option, whereas others do not
> and it seems to relate to how the question/comment has originated? Be kind
> to me :)


Hello Tim,

I can't answer your first question about the FUSB30x driver(s), but
regarding your second question: Yes, dev@nuttx.apache.org is the correct
place to discuss NuttX-related subjects, including development (as the name
dev@ implies) and user questions. But if you ever need to report security
issues, those should not be publicly disclosed until we release a fix, so
please report such issues to priv...@nuttx.apache.org instead.

We're always glad to have new contributors! Feel free to open a Pull
Request at GitHub at any time. See this helpful link:

https://nuttx.apache.org/docs/latest/contributing/index.html

In particular, the page Making Changes Using Git (second from the top) will
help walk you through the process of dealing with GitHub etc.

Cheers,
Nathan

Re: STM32 EXTI context

[Nathan Hartman]

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

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
>

Using NuttX with custom bootloader

[Flavio Castro Alves Filho]

Hello,

I intend to use a NuttX firmware with a custom bootloader on a
STM32F4DISCOVERY board.

The bootloader will be executed on the first available memory block in
flash, and the firmware will start from the second block - position
0x0802.

I believe I know what to do regarding linker script.

But I don't know if there is anything to be done directly in NuttX source code.

I ask this because in a standard STM32 firmware using STM32Cube, there
is a FLASH_BASE constant that must be set correctly for the firmware
to work correctly. My worry is if there is something similar in NuttX
for the board.

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: Error with stm32f4discovery:usbnsh

[Flavio Castro Alves Filho]

Hello,

To have usbnsh working I used, as a workaround, the implementation
done in this pull request:
https://github.com/apache/incubator-nuttx-apps/pull/521

In my application I don't use nsh. And USB-CDC works fine accessing
directly the device.

Hope it helps,

Best regards,

Flavio

Em ter., 20 de abr. de 2021 às 19:26, Alan Carvalho de Assis
 escreveu:
>
> Are you getting this error:
>
> "nsh> nsh: nsh_session: readline failed: 9"
>
> Could you please share your .config file?
>
> BR,
>
> Alan
>
> On 4/20/21, Max Kriegleder  wrote:
> > Strange.. I have sent two mails prior to this one and apparently they
> > did not make it to the list. Trying again:
> >
> > Were you able to fix this problem? I am running nuttx-10.0.1 on a
> > stm32f4discovery board and I have the same issue.
> >
> > Thanks!
> >
> >
> > On 2021/04/17 22:56:48, Alan Carvalho de Assis  wrote:
> >  > I just received it!>
> >  >
> >  > Try to submit a new email>
> >  >
> >  > On 4/17/21, Max Kriegleder  wrote:>
> >  > > Is anybody reading this? I am not sure why my messages get lost.. how>
> >  > > can I post to the message list?>
> >  > >>
> >  > > On 2020/12/13 22:19:01, Brennan Ashton 
> > wrote:>
> >  > > > Yeah 100% agree which is why I need to look when I have a little
> > more>>
> >  > > > time to understand what is going on.>>
> >  > > >>
> >  > > > On Sun, Dec 13, 2020 at 2:12 PM Gregory Nutt 
> > wrote:>>
> >  > > > >>>
> >  > > > > See>>
> >  > > > >>
> >  > >
> > https://mail-archives.apache.org/mod_mbox/nuttx-dev/202012.mbox/%3CCAKFLXYwes3pcDA2zXsL2FcwgCS4PecdmiP9srkGEtTaOoLEhMg%40mail.gmail.com%3E>>
> >
> >
> >  > >>
> >  > >>
> >  > > > >>>
> >  > > > > I don't think this is the correct solution since with Xiao
> > Xiang's>>
> >  > > > > recent changes, stdin should never be closed. But it does give
> > some>>
> >  > > > > clues about the nature of the problem: stdin is no valid;
> > stdout is>
> >  > > okay>>
> >  > > > >>>
> >  > > > > On 12/13/2020 4:07 PM, Brennan Ashton wrote:>>
> >  > > > > > This is impacting all the usbnsh configurations. I can take
> > another>>
> >  > > > > > look later this evening>>
> >  > > > > > https://github.com/apache/incubator-nuttx/pull/2526>>
> >  > > > > >>>
> >  > > > > > --Brennan>>
> >  > > > > >>>
> >  > > > > > On Fri, Dec 11, 2020 at 5:05 AM Gregory Nutt >
> >  > > wrote:>>
> >  > > > > >> Several other PRs specifically removed support for fclose>
> >  > > (stdin). Are>>
> >  > > > > >> you certain you want to restore it? I think this needs more>
> >  > > analysis>>
> >  > > > > >> and resolution with the previous changes that removed the>
> >  > > fclose() of>>
> >  > > > > >> stdin, stdout, and stderr.>>
> >  > > > > 
> >  > > > > >> On 12/10/2020 5:37 PM, Masayuki Ishikawa wrote:>>
> >  > > > > >>> Suzuki-san,>>
> >  > > > > >
> >  > > > > >>> Please send a PR (Pull Request) to>>
> >  > > > > >>> https://github.com/apache/incubator-nuttx-apps/>>
> >  > > > > >
> >  > > > > >>> On Thu, Dec 10, 2020 at 5:24 PM SUZUKI Keiji
> > >
> >  > > wrote:>>
> >  > > > > >
> >  > > > >  Hi,>>
> >  > > > > >>
> >  > > > >  I use STM32F407G-DISC1 (MB997D) and build nuttx on macOS>
> >  > > Mojave (10.14.6).>>
> >  > > > > >>
> >  > > > >  The following error occurs with the default configuration
> > of>>
> >  > > > >  stm32f4discovery:usbnsh.>>
> >  > > > > >>
> >  > > > >  NuttShell (NSH) NuttX-10.0.0>>
> >  > > > >  nsh> nsh: nsh_session: readline failed: 9>>
> >  > > > > >>
> >  > > > >  The reason seems that instream->fs_fd is -1 instead of 0 in>
> >  > > the readline()>>
> >  > > > >  function called by>>
> >  > > > >  nsh_session().>>
> >  > > > > >>
> >  > > > >  This error occurs in version 10.0-RC0 and after (I checked>
> >  > > 10.0-RC0, 10.0>>
> >  > > > >  and current master)>>
> >  > > > >  but does not occur in 9.1 and before (I checked 9.1, 8.2 and>
> >  > > 7.31).>>
> >  > > > > >>
> >  > > > >  The following patch fixed it in my environment but I don't>
> >  > > know this is a>>
> >  > > > >  correct fix.>>
> >  > > > > >>
> >  > > > >  === from here ===>>
> >  > > > > >>
> >  > > > >  diff --git a/nshlib/nsh_usbconsole.c
> > b/nshlib/nsh_usbconsole.c>>
> >  > > > >  index 28f63bcc..768a621b 100644>>
> >  > > > >  --- a/nshlib/nsh_usbconsole.c>>
> >  > > > >  +++ b/nshlib/nsh_usbconsole.c>>
> >  > > > >  @@ -77,8 +77,8 @@>>
> >  > > > > >>
> >  > > > >  static void nsh_configstdio(int fd, FAR struct
> > console_stdio_s>
> >  > > *pstate)>>
> >  > > > >  {>>
> >  > > > >  - /* Make sure the stdout, and stderr are flushed */>>
> >  > > > >  ->>
> >  > > > >  + /* Make sure the stdin is closed and the stdout, and
> > stderr>
> >  > > are flushed>>
> >  > > > >  */>>
> >  > > > >  + fclose(stdin);>>
> >  > > > >  fflush(stdout);>>
> >  > > > >  fflush(stderr);>>
> >  > > > > >>
> >  > > > >  @@ -88,6 +88,9 @@

Re: Using NuttX with custom bootloader

[Gregory Nutt]

But I don't know if there is anything to be done directly in NuttX source code.


Nothing other than setting the VBAR register (called NVIC_VECTAB in 
NuttX).  This is already done so I guess the real answer is No.

Re: Using NuttX with custom bootloader

[Flavio Castro Alves Filho]

It worked.

Just changing the linker script was enough.

Thank you very much.

Best regards,

Flavio

Em qua., 21 de abr. de 2021 às 16:00, Gregory Nutt
 escreveu:
>
>
> > But I don't know if there is anything to be done directly in NuttX source 
> > code.
>
> Nothing other than setting the VBAR register (called NVIC_VECTAB in
> NuttX).  This is already done so I guess the real answer is No.
>
>


-- 
Flavio de Castro Alves Filho

flavio.al...@gmail.com
Twitter: http://twitter.com/#!/fraviofii
LinkedIn profile: www.linkedin.com/in/flaviocastroalves

Re: [ANNOUNCE] Apache NuttX (incubating) 10.0.1 and 9.1.1 Release

[Masayuki Ishikawa]

Hi, Brennan

Sorry to reply to the old email but I noticed that the following tags are
missing in the github repositories.

https://github.com/apache/incubator-nuttx/
nuttx-9.1.1

https://github.com/apache/incubator-nuttx-apps/
nuttx-9.1.1
nuttx-10.0.1

Could you please add the above tags to the repositories?

Thanks,
Masayuki


On Thu, Dec 10, 2020 at 12:53 AM Brennan Ashton  wrote:

> The Apache NuttX (incubating) project team is proud to announce
> Apache NuttX 10.0.1 and 9.1.1 have been released.
>
> The release artifacts and Release Notes can be found (shortly) at:
> https://nuttx.apache.org/download/
> https://nuttx.apache.org/releases/10.0.1/
> https://nuttx.apache.org/releases/9.1.1/
>
> These are patch releases that include two important TCP/IP security
> fixes. A follow-on email will share details of these.
>
> Thanks,
> Brennan Ashton
> on behalf of Apache NuttX PPMC
>

Re: [ANNOUNCE] Apache NuttX (incubating) 10.0.1 and 9.1.1 Release

[Brennan Ashton]

On Wed, Apr 21, 2021 at 5:59 PM Masayuki Ishikawa
 wrote:
>
> Hi, Brennan
>
> Sorry to reply to the old email but I noticed that the following tags are 
> missing in the github repositories.
>
> https://github.com/apache/incubator-nuttx/
> nuttx-9.1.1
>
> https://github.com/apache/incubator-nuttx-apps/
> nuttx-9.1.1
> nuttx-10.0.1
>
> Could you please add the above tags to the repositories?

Thanks for noticing that Masayuki, I have signed and pushed the
missing tags.  Looks like I had pushed the RC tag for 9.1.1 but not
the final one, and for the apps repo totally forgot because the (9.1.0
and 9.1.1)  and (10.0.0 and 10.0.1) are the same since this was only a
patch release to the OS.
I have this step in the Create a NuttX Release document that I shared
for Alin [0], so hopefully this will help any release manager in the
future not miss these.

[0] 
https://gist.github.com/btashton/ee474723013a7040186c91d41a4c7fad#create-release-tags

--Brennan

Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release

[Brennan Ashton]

Alin,
I think we should consider if we want to backport these into the
10.1.0 release.  I am still running more tests myself on all the
hardware I have, but these seemed important to at least consider.
https://github.com/apache/incubator-nuttx/pull/3586
https://github.com/apache/incubator-nuttx/pull/3580

--Brennan

On Sun, Apr 18, 2021 at 7:06 AM Alin Jerpelea  wrote:
>
> Hello all,
> Apache NuttX (Incubating) 10.1.0 RC0 has been staged under [1] and it's
> time to vote on accepting it for release. If approved we will seek
> final release approval from the IPMC. Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
> required to pass.
>
> The Apache requirements for approving a release can be found here [3]
> "Before voting +1 [P]PMC members are required to download the signed
> source code package, compile it as provided, and test the resulting
> executable on their own platform, along with also verifying that the
> package meets the requirements of the ASF policy on releases."
>
> A document to walk through some of this process has been published on
> our project wiki and can be found here [4].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [4])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Alin Jerpelea
>
> SCM Information:
>   Release tag: nuttx-10.1.0-RC0
>   Hash for the release incubating-nuttx tag:
> f380c919f04d5ee88e0a83f5632cc83af503664f
>   Hash for the release incubating-nuttx-apps tag:
> 4348d91d1356335483089c3865282d80f13bedcd
>
> [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.1.0-RC0/
> [2]https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.1.0-RC0/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release

[Alin Jerpelea]

Hi Brennan,
I think that we should backport them and I will cut RC1
Thanks
Alin


On Thu, Apr 22, 2021, 08:30 Brennan Ashton 
wrote:

> Alin,
> I think we should consider if we want to backport these into the
> 10.1.0 release.  I am still running more tests myself on all the
> hardware I have, but these seemed important to at least consider.
> https://github.com/apache/incubator-nuttx/pull/3586
> https://github.com/apache/incubator-nuttx/pull/3580
>
> --Brennan
>
> On Sun, Apr 18, 2021 at 7:06 AM Alin Jerpelea  wrote:
> >
> > Hello all,
> > Apache NuttX (Incubating) 10.1.0 RC0 has been staged under [1] and it's
> > time to vote on accepting it for release. If approved we will seek
> > final release approval from the IPMC. Voting will be open for 72hr.
> >
> > A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
> > required to pass.
> >
> > The Apache requirements for approving a release can be found here [3]
> > "Before voting +1 [P]PMC members are required to download the signed
> > source code package, compile it as provided, and test the resulting
> > executable on their own platform, along with also verifying that the
> > package meets the requirements of the ASF policy on releases."
> >
> > A document to walk through some of this process has been published on
> > our project wiki and can be found here [4].
> >
> > [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> > items in [4])
> > [ ] -1 reject (explanation required)
> >
> > Thank you all,
> > Alin Jerpelea
> >
> > SCM Information:
> >   Release tag: nuttx-10.1.0-RC0
> >   Hash for the release incubating-nuttx tag:
> > f380c919f04d5ee88e0a83f5632cc83af503664f
> >   Hash for the release incubating-nuttx-apps tag:
> > 4348d91d1356335483089c3865282d80f13bedcd
> >
> > [1] https://dist.apache.org/repos/dist/dev/incubator/nuttx/10.1.0-RC0/
> > [2]
> https://raw.githubusercontent.com/apache/incubator-nuttx/nuttx-10.1.0-RC0/ReleaseNotes
> > [3] https://www.apache.org/dev/release.html#approving-a-release
> > [4]
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
>