Re: Using NuttX with custom bootloader
Hello I did that and it works in a consumer product with a stm32 since, well, 2018 I think. Also in an open source product. my board uses a custom linker script that locates the start of the flash a bit farther than the usual start (one stm32 block or 16k IIRC) . Then I compile nuttx as usual. The bootloader happens to be built by the same process, and all the bootloader code goes into a separate named text section and memory zone. It could be built separately but this is convenient. Only problem is I cant use inline strings for debug because I could not find how to control the section these litteral strings are affected to. So I use global const arrays. ugly but it does the job. when the boards are manufactured the whole HEX file is flashed, which includes BOTH the bootloader and the initial OS. After that the board can be updated "over the air". A python scripts extract the "OS image" from the ELF file and wrap it appropriately, then an update file is built. Our NuttX then includes some applicative code to retrieve and validate this update file. The contents are written to SPI flash (via a char driver wrapper to MTD devices to bypass the nuttx FTL) The board reboots the bootloader code detects the update in the SPI flash and writes the contents to the STM32 flash. once complete and verified, the SPI contents is disabled. Else the bootloader can restart the process. We could have emergency serial code to upload an image from the bootloader, but we never had to, this process works fine, we never had bricked boards. This method prevents updating the bootloader. So we can ship special OS updates that includes an updated bootloader as a static const. The nuttx board start code is then able to update the bootloader. We rarely use this feature, only once IIRC. In our case, the bootloader has to disable the SPI peripheral before booting the OS, else NuttX will find it initialized and will not initialize it correctly. Our system is rather complex but is also quite failsafe. Sebastien Le 21/04/2021 à 20:54, Flavio Castro Alves Filho a écrit : 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
Re: Using NuttX with custom bootloader
Sorry, forgot to say that of course, VTOR is updated by the bootloader
prior to jumping into the OS.
BOOTCODE __attribute__((naked, noreturn)) void __boot_app(void)
{
__asm__ __volatile__ ("\t"
/* load SP (from 08004000) */
"movw r0, #0x4000 \n\t"
"movt r0, #0x0800 \n\t"
"ldr sp, [r0] \n\t"
/* load LR (from 08004004) */
"movw r0, #0x4004 \n\t"
"movt r0, #0x0800 \n\t"
"ldr r0, [r0] \n\t"
"mov lr, r0 \n\t"
/* setup VTOR (at E000ED08) to remap vectors*/
"movw r0, #0xED08 /*adr lo*/ \n\t"
"movt r0, #0xE000 /*adr hi*/ \n\t"
"movw r1, #0x4000 /*val lo*/ \n\t"
"movt r1, #0x0800 /*val hi*/ \n\t"
"str r1, [r0] /*store value at address*/ \n\t"
"bx lr /*take the jump*/ \n"
);
}
Le 22/04/2021 à 09:59, Sebastien Lorquet a écrit :
Hello
I did that and it works in a consumer product with a stm32 since,
well, 2018 I think. Also in an open source product.
my board uses a custom linker script that locates the start of the
flash a bit farther than the usual start (one stm32 block or 16k IIRC)
. Then I compile nuttx as usual.
The bootloader happens to be built by the same process, and all the
bootloader code goes into a separate named text section and memory
zone. It could be built separately but this is convenient. Only
problem is I cant use inline strings for debug because I could not
find how to control the section these litteral strings are affected
to. So I use global const arrays. ugly but it does the job.
when the boards are manufactured the whole HEX file is flashed, which
includes BOTH the bootloader and the initial OS.
After that the board can be updated "over the air".
A python scripts extract the "OS image" from the ELF file and wrap it
appropriately, then an update file is built.
Our NuttX then includes some applicative code to retrieve and validate
this update file.
The contents are written to SPI flash (via a char driver wrapper to
MTD devices to bypass the nuttx FTL)
The board reboots
the bootloader code detects the update in the SPI flash and writes the
contents to the STM32 flash.
once complete and verified, the SPI contents is disabled. Else the
bootloader can restart the process. We could have emergency serial
code to upload an image from the bootloader, but we never had to, this
process works fine, we never had bricked boards.
This method prevents updating the bootloader.
So we can ship special OS updates that includes an updated bootloader
as a static const.
The nuttx board start code is then able to update the bootloader. We
rarely use this feature, only once IIRC.
In our case, the bootloader has to disable the SPI peripheral before
booting the OS, else NuttX will find it initialized and will not
initialize it correctly.
Our system is rather complex but is also quite failsafe.
Sebastien
Le 21/04/2021 à 20:54, Flavio Castro Alves Filho a écrit :
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
Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release
On Thu, Apr 22, 2021 at 2:54 AM Alin Jerpelea wrote: > Hi Brennan, > I think that we should backport them and I will cut RC1 > Thanks > Alin If I'm not too late, I fixed up the ReleaseNotes a little bit in PR-3570 > > > 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 > > >
Re: [VOTE] Apache NuttX 10.1.0 (incubating) RC0 release
It is perfect timing! I will cut RC1 with the fixes tonight Thanks Alin On Thu, Apr 22, 2021, 16:12 Nathan Hartman wrote: > On Thu, Apr 22, 2021 at 2:54 AM Alin Jerpelea wrote: > > > Hi Brennan, > > I think that we should backport them and I will cut RC1 > > Thanks > > Alin > > > > If I'm not too late, I fixed up the ReleaseNotes a little bit in PR-3570 > > > > > > > > > > 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 > > > > > >
Re: Error with stm32f4discovery:usbnsh
Yes, I am getting this error.
NuttShell (NSH) NuttX-10.1.0
nsh> nsh: nsh_session: readline failed: 9
I haven't used NuttX on this board for a while, so I cannot say when
this broke. I have attached the .config file, should be the
auto-generated config file based on stm32f4discovery/configs/usbnsh
Thanks!
On 2021/04/20 22:26:25, Alan Carvalho de Assis wrote:
> 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(
Re: Error with stm32f4discovery:usbnsh
Hi Max,
it appears you are using an outdated NuttX and/or board config
During the compilation using out .config I got some errors:
In file included from nuttxspace/nuttx/sched/mqueue/mqueue.h:38,
from group/group_leave.c:44:
nuttxspace/nuttx/include/nuttx/mqueue.h:103:26: error:
'CONFIG_FS_MQUEUE_NPOLLWAITERS' undeclared here (not in a function);
did you mean 'CONFIG_SERIAL_NPOLLWAITERS'?
103 | FAR struct pollfd *fds[CONFIG_FS_MQUEUE_NPOLLWAITERS];
| ^
| CONFIG_SERIAL_NPOLLWAITERS
make[1]: *** [Makefile:57: group_leave.o] Error 1
You config is missing some new symbols:
CONFIG_NFILE_DESCRIPTORS_PER_BLOCK=8
CONFIG_FS_MQUEUE_NPOLLWAITERS=4
etc
Please update ("git pull") you nuttx and apps and then execute:
$ make distclean
$ ./tools/configure.sh stm32f4discovery:usbnsh
$ make
Now everything will work correctly.
BR,
Alan
On 4/22/21, Max Kriegleder wrote:
> Yes, I am getting this error.
>
> NuttShell (NSH) NuttX-10.1.0
> nsh> nsh: nsh_session: readline failed: 9
>
> I haven't used NuttX on this board for a while, so I cannot say when
> this broke. I have attached the .config file, should be the
> auto-generated config file based on stm32f4discovery/configs/usbnsh
>
> Thanks!
>
>
> On 2021/04/20 22:26:25, Alan Carvalho de Assis wrote:
> > 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 cal
Re: DALI Interface Proposal
One of the best brief explanation of the Dali protocol is in Microchip TB3200 Technical Brief (https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en606182), also, DALI introduction on page 8 of this ( https://download.beckhoff.com/download/document/automation/twincat3/TwinCAT_3_PLC_Lib_Tc2_DALI_EN.pdf ) explains the IEC 62386 standard and DALI messaging very good. On 2021/04/21 09:52:23, murat tologlu wrote: > 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/w
Re: DALI Interface Proposal
Both the Microchip solution and the example I've mentioned above uses the UART to communicate with DALI Interface. I think we can consider the same. On 2021/04/22 15:56:51, murat tologlu wrote: > One of the best brief explanation of the Dali protocol is in Microchip TB3200 > Technical Brief > (https://www.microchip.com/wwwAppNotes/AppNotes.aspx?appnote=en606182), also, > DALI introduction on page 8 of this ( > https://download.beckhoff.com/download/document/automation/twincat3/TwinCAT_3_PLC_Lib_Tc2_DALI_EN.pdf > ) explains the IEC 62386 standard and DALI messaging very good. > > On 2021/04/21 09:52:23, murat tologlu wrote: > > 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 th
Re: DALI Interface Proposal
Both the Microchip solution and the example I've mentioned above uses the UART to communicate with DALI Interface. I think we can consider the same. A better design would be independent of the physical transport layer .
Re: DALI Interface Proposal
This topic is your expertise ! On 2021/04/22 16:49:30, Gregory Nutt wrote: > > > Both the Microchip solution and the example I've mentioned above uses the > > UART to communicate with DALI Interface. I think we can consider the same. > > > A better design would be independent of the physical transport layer . >
Re: DALI Interface Proposal
I forgot to say: Machester encoder is just an exclusive or gate, manchester decoder is also an exclusive or gate ! If you ex-or the clock and the data then you get the manchester encoded code. At the receiver side, if you start and synchronize a same frequency free running clock with the negative going "start bit" and ex-or the incoming frame with this clock then you decode the code and obtain the same data. This is the same technique how I designed and made Turkey's first military digital voice scrambler unit 40 years ago :) On 2021/04/22 17:17:09, murat tologlu wrote: > This topic is your expertise ! > > On 2021/04/22 16:49:30, Gregory Nutt wrote: > > > > > Both the Microchip solution and the example I've mentioned above uses the > > > UART to communicate with DALI Interface. I think we can consider the same. > > > > > A better design would be independent of the physical transport layer . > > >
Re: Error with stm32f4discovery:usbnsh
Hi, all, I noticed that we need to backport the following PRs to the nuttx-10.0 branch. https://github.com/apache/incubator-nuttx/pull/2540 https://github.com/apache/incubator-nuttx-apps/pull/521 https://github.com/apache/incubator-nuttx-apps/pull/523 So, I've just added the backport/10.0 label to the above PRs. Thanks, Masayuki On Thu, Apr 22, 2021 at 4:00 AM Flavio Castro Alves Filho < flavio.al...@gmail.com> wrote: > 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 < > sp...@gmail.com>> > > > > > 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>> > >
Re: [ANNOUNCE] Apache NuttX (incubating) 10.0.1 and 9.1.1 Release
Brennan, thanks for the updates. On Thu, Apr 22, 2021 at 2:27 PM Brennan Ashton wrote: > 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 >
First time contributor PRs will need approval to run CI
Just as a heads up Github has implemented a change to help combat spam accounts using our CI resources for crypto mining and the like. I don't know of any cases of this happening to this project, but many other projects have been hit with this. Going forward the first time someone submits a PR a commiter will have to manually approve the CI run. Once they have a PR merged this action will not be required again. You can read more about this here: https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks --Brennan
Re: First time contributor PRs will need approval to run CI
On Thu, Apr 22, 2021 at 11:26 PM Brennan Ashton wrote: > Just as a heads up Github has implemented a change to help combat spam > accounts using our CI resources for crypto mining and the like. I > don't know of any cases of this happening to this project, but many > other projects have been hit with this. > > Going forward the first time someone submits a PR a commiter will have > to manually approve the CI run. Once they have a PR merged this > action will not be required again. > > You can read more about this here: > > https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks > > --Brennan > Thanks for the heads up! Nathan
Re: First time contributor PRs will need approval to run CI
Thanks for sharing Regards Alin On Fri, Apr 23, 2021, 05:31 Nathan Hartman wrote: > On Thu, Apr 22, 2021 at 11:26 PM Brennan Ashton > > wrote: > > > Just as a heads up Github has implemented a change to help combat spam > > accounts using our CI resources for crypto mining and the like. I > > don't know of any cases of this happening to this project, but many > > other projects have been hit with this. > > > > Going forward the first time someone submits a PR a commiter will have > > to manually approve the CI run. Once they have a PR merged this > > action will not be required again. > > > > You can read more about this here: > > > > > https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks > > > > --Brennan > > > > Thanks for the heads up! > > Nathan >
