Re: nrf51822 and BLE
You can use Nordic's priorpiate BLE stack (SoftDevice) and after a few hacks even Nordic SDK can be integrated with Nuttx. This gives you a certified BLE stack but it has a huge disadvantage - it is a closed source. Looking for bugs in such an environment is a nightmare. Some time ago I started working on the BLE stack for NRF52 integrated with Nuttx, but I don't have much done at the moment. I don't think there is an easy way to port the Zephyr BLE stack to Nuttx. It looks just as much work as writing it from scratch. śr., 17 cze 2020 o 03:32 Matias N. napisał(a): > Not sure what you mean by "slave" in this case. What I'm referring to is > the access to the low-level Bluetooth hardware (register based access to > radio peripheral). I didn't meant NuttX's BLE stack would only support HCI > UART, I mean that there's no support for NRF radio (link-level layer) on > NuttX yet. > > In other words, using Zephyr figures from their docs, the idea would be to > support this scenario (replace Zephyr with NuttX): > https://docs.zephyrproject.org/latest/_images/ble_cfg_single.png > > Whereas NuttX currently supports the scenario on the left of this figure: > https://docs.zephyrproject.org/latest/_images/ble_cfg_dual.png > > As you mention, this requires code which interfaces the upper bluetooth > stack with the low-level radio hardware. This is the code that is available > un Zephyr under Apache 2.0 license. > > Best, > Matias > > On Tue, Jun 16, 2020, at 22:24, Gregory Nutt wrote: > > > > > AFAIK NuttX supports the Host level API and at most HCI UART > interface. I'm referring to the link-level code which interfaces directly > with NRF51822 so that you can run NuttX in the board itself (and not as an > external module via UART). > > It supports both host and slave and uses a driver defined by and > > interface. HCI UART is *not* assumed or required. I don't know that it > > is compatible with the NRF. I imagine you would have to use the NRF > stack. > > >
Re: nrf51822 and BLE
Hi Mateusz, This is a great idea! Note that zGlue did exactly it, but they are using nRF52. Maybe Sony or Xiaomi has something similar implemented for NuttX and could help. Guys, are you hearing? Xiang? Masayuki? BR, Alan On 6/17/20, raiden00pl . wrote: > You can use Nordic's priorpiate BLE stack (SoftDevice) and after a few > hacks even Nordic SDK can be integrated with Nuttx. > This gives you a certified BLE stack but it has a huge disadvantage - it is > a closed source. Looking for bugs in such an environment is a nightmare. > > Some time ago I started working on the BLE stack for NRF52 integrated with > Nuttx, but I don't have much done at the moment. > I don't think there is an easy way to port the Zephyr BLE stack to Nuttx. > It > looks just as much work as writing it from scratch. > > śr., 17 cze 2020 o 03:32 Matias N. napisał(a): > >> Not sure what you mean by "slave" in this case. What I'm referring to is >> the access to the low-level Bluetooth hardware (register based access to >> radio peripheral). I didn't meant NuttX's BLE stack would only support >> HCI >> UART, I mean that there's no support for NRF radio (link-level layer) on >> NuttX yet. >> >> In other words, using Zephyr figures from their docs, the idea would be >> to >> support this scenario (replace Zephyr with NuttX): >> https://docs.zephyrproject.org/latest/_images/ble_cfg_single.png >> >> Whereas NuttX currently supports the scenario on the left of this figure: >> https://docs.zephyrproject.org/latest/_images/ble_cfg_dual.png >> >> As you mention, this requires code which interfaces the upper bluetooth >> stack with the low-level radio hardware. This is the code that is >> available >> un Zephyr under Apache 2.0 license. >> >> Best, >> Matias >> >> On Tue, Jun 16, 2020, at 22:24, Gregory Nutt wrote: >> > >> > > AFAIK NuttX supports the Host level API and at most HCI UART >> interface. I'm referring to the link-level code which interfaces directly >> with NRF51822 so that you can run NuttX in the board itself (and not as >> an >> external module via UART). >> > It supports both host and slave and uses a driver defined by and >> > interface. HCI UART is *not* assumed or required. I don't know that it >> > is compatible with the NRF. I imagine you would have to use the NRF >> stack. >> > >> >
Re: nrf51822 and BLE
I saw that option recently and I don't really like it. It seems a debugging nightmare. What I actually like about Nordic is that at least it is possible to have an open-source low-level radio stack, which is not the case for Espressif since this is still closed source and undocumented. So I think the best path is to get proper support for this part in NuttX. But yes, maybe it is not really a porting effort but writing something from scratch. But even in that case it is good to have a working reference such as Zephyr. IMHO it would really be worth the effort. Support for Nordic/Espressif radio is what is attractive in other RTOSs, such as Zephyr. Best, Matias On Wed, Jun 17, 2020, at 04:06, raiden00pl . wrote: > You can use Nordic's priorpiate BLE stack (SoftDevice) and after a few > hacks even Nordic SDK can be integrated with Nuttx. > This gives you a certified BLE stack but it has a huge disadvantage - it is > a closed source. Looking for bugs in such an environment is a nightmare. > > Some time ago I started working on the BLE stack for NRF52 integrated with > Nuttx, but I don't have much done at the moment. > I don't think there is an easy way to port the Zephyr BLE stack to Nuttx. It > looks just as much work as writing it from scratch. > > śr., 17 cze 2020 o 03:32 Matias N. napisał(a): > > > Not sure what you mean by "slave" in this case. What I'm referring to is > > the access to the low-level Bluetooth hardware (register based access to > > radio peripheral). I didn't meant NuttX's BLE stack would only support HCI > > UART, I mean that there's no support for NRF radio (link-level layer) on > > NuttX yet. > > > > In other words, using Zephyr figures from their docs, the idea would be to > > support this scenario (replace Zephyr with NuttX): > > https://docs.zephyrproject.org/latest/_images/ble_cfg_single.png > > > > Whereas NuttX currently supports the scenario on the left of this figure: > > https://docs.zephyrproject.org/latest/_images/ble_cfg_dual.png > > > > As you mention, this requires code which interfaces the upper bluetooth > > stack with the low-level radio hardware. This is the code that is available > > un Zephyr under Apache 2.0 license. > > > > Best, > > Matias > > > > On Tue, Jun 16, 2020, at 22:24, Gregory Nutt wrote: > > > > > > > AFAIK NuttX supports the Host level API and at most HCI UART > > interface. I'm referring to the link-level code which interfaces directly > > with NRF51822 so that you can run NuttX in the board itself (and not as an > > external module via UART). > > > It supports both host and slave and uses a driver defined by and > > > interface. HCI UART is *not* assumed or required. I don't know that it > > > is compatible with the NRF. I imagine you would have to use the NRF > > stack. > > > > > >
Re: SAMA5D27 SDMMC support branch
SDMMC write is working now too. So the driver can do the following: - Non-DMA read and write - DMA read and write in SDMA mode - 1 bit bus - 4 bit bus (widebus) - up to 25Mhz I'm going to work on cleanup, documentation, and PR next. I'll post a branch here when I get it somewhat cleaned up. -adam On Mon, Jun 15, 2020 at 9:14 PM Adam Feuer wrote: > SDMMC DMA read is working now too. I'll work on DMA write next. > > -adam > > On Fri, Jun 12, 2020 at 2:45 PM Adam Feuer wrote: > >> I got the SDMMC write to work as well. This is in non-DMA mode. I'm going >> to work on the DMA mode next. >> >> -adam >> -- >> Adam Feuer >> > > > -- > Adam Feuer > -- Adam Feuer
Re: SAMA5D27 SDMMC support branch
On Wed, Jun 17, 2020 at 5:49 PM Adam Feuer wrote: > SDMMC write is working now too. So the driver can do the following: > >- Non-DMA read and write >- DMA read and write in SDMA mode >- 1 bit bus >- 4 bit bus (widebus) >- up to 25Mhz > > I'm going to work on cleanup, documentation, and PR next. I'll post a > branch here when I get it somewhat cleaned up. That's exciting! Thanks for your hard work and for posting updates in the meantime. Cheers, Nathan
QuickLogic Open Source MCU + FPGA
This is a chip that I have been excited about for a while since they are highlighting the open source tool support including the SoC and FPGA emulation with RENODE. Zephyr is the highlighted RTOS, but I thought it would be a great candidate for NuttX, especially since the MCU is a ARM M4 so the initial porting should not be too bad. I have a couple on the way, and thought others might be interested. https://www.quicklogic.com/products/eos-s3/quickfeather-development-kit/ https://www.quicklogic.com/software/qorc-mcu-efpga-fpga-open-source-tools/ --Brennan
Re: SAMA5D27 SDMMC support branch
Thanks Nathan. It's been interesting learning how to port and debug NuttX drivers. Hopefully I will be able to write something about it when I get the code accepted. It was helpful that I could port a driver used by the same chip peripheral IP block on other NuttX supported chips. I didn't have to write it from scratch. Takeyoshi suggested doing the port and he was right about it. -adam On Wed, Jun 17, 2020 at 5:46 PM Nathan Hartman wrote: > On Wed, Jun 17, 2020 at 5:49 PM Adam Feuer wrote: > > > SDMMC write is working now too. So the driver can do the following: > > > >- Non-DMA read and write > >- DMA read and write in SDMA mode > >- 1 bit bus > >- 4 bit bus (widebus) > >- up to 25Mhz > > > > I'm going to work on cleanup, documentation, and PR next. I'll post a > > branch here when I get it somewhat cleaned up. > > > That's exciting! Thanks for your hard work and for posting updates in the > meantime. > > Cheers, > Nathan > -- Adam Feuer
Re: nrf51822 and BLE
I agree that access to low-level radio with documented registers is a big plus for Nordic. I hope other vendors will follow the same path (if not then we always have reverse engineering :P). For this reason, we should have a standardized interface for BLE single-chip solutions in Nuttx. A non-standardized BLE stack probably won't have much value in commercial products, but for amateur projects it would be a great tool. śr., 17 cze 2020 o 17:00 Matias N. napisał(a): > I saw that option recently and I don't really like it. It seems a > debugging nightmare. > What I actually like about Nordic is that at least it is possible to have > an open-source low-level radio stack, which is not the case for Espressif > since this is still closed source and undocumented. So I think the best > path is to get proper support for this part in NuttX. > > But yes, maybe it is not really a porting effort but writing something > from scratch. But even in that case it is good to have a working reference > such as Zephyr. IMHO it would really be worth the effort. Support for > Nordic/Espressif radio is what is attractive in other RTOSs, such as > Zephyr. > > Best, > Matias > > On Wed, Jun 17, 2020, at 04:06, raiden00pl . wrote: > > You can use Nordic's priorpiate BLE stack (SoftDevice) and after a few > > hacks even Nordic SDK can be integrated with Nuttx. > > This gives you a certified BLE stack but it has a huge disadvantage - it > is > > a closed source. Looking for bugs in such an environment is a nightmare. > > > > Some time ago I started working on the BLE stack for NRF52 integrated > with > > Nuttx, but I don't have much done at the moment. > > I don't think there is an easy way to port the Zephyr BLE stack to > Nuttx. It > > looks just as much work as writing it from scratch. > > > > śr., 17 cze 2020 o 03:32 Matias N. napisał(a): > > > > > Not sure what you mean by "slave" in this case. What I'm referring to > is > > > the access to the low-level Bluetooth hardware (register based access > to > > > radio peripheral). I didn't meant NuttX's BLE stack would only support > HCI > > > UART, I mean that there's no support for NRF radio (link-level layer) > on > > > NuttX yet. > > > > > > In other words, using Zephyr figures from their docs, the idea would > be to > > > support this scenario (replace Zephyr with NuttX): > > > https://docs.zephyrproject.org/latest/_images/ble_cfg_single.png > > > > > > Whereas NuttX currently supports the scenario on the left of this > figure: > > > https://docs.zephyrproject.org/latest/_images/ble_cfg_dual.png > > > > > > As you mention, this requires code which interfaces the upper bluetooth > > > stack with the low-level radio hardware. This is the code that is > available > > > un Zephyr under Apache 2.0 license. > > > > > > Best, > > > Matias > > > > > > On Tue, Jun 16, 2020, at 22:24, Gregory Nutt wrote: > > > > > > > > > AFAIK NuttX supports the Host level API and at most HCI UART > > > interface. I'm referring to the link-level code which interfaces > directly > > > with NRF51822 so that you can run NuttX in the board itself (and not > as an > > > external module via UART). > > > > It supports both host and slave and uses a driver defined by and > > > > interface. HCI UART is *not* assumed or required. I don't know that > it > > > > is compatible with the NRF. I imagine you would have to use the NRF > > > stack. > > > > > > > > > >
ELF Application Example(apps/examples/elf) undefined references issue in symtab.c
Hello Team, I have added ELF Binary Loader support for RX65N target. I am currently testing my implementation using the apps/examples/elf/ example . When I enable the apps/examples/elf/ example application, and compile, I am getting the below error in symtab.c (Symbol Table) C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x14): undefined reference to `_fflush' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x1c): undefined reference to `_fopen' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x24): undefined reference to `_fprintf' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x2c): undefined reference to `_getpid' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x34): undefined reference to `_kill' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x3c): undefined reference to `_longjmp' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x44): undefined reference to `_memset' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x4c): undefined reference to `_nxsched_get_streams' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x54): undefined reference to `_printf' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x5c): undefined reference to `_pthread_attr_init' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x64): undefined reference to `_pthread_create' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x6c): undefined reference to `_pthread_exit' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x74): undefined reference to `_pthread_join' . . The above error is obtained for all the symbols generated in symtab.c from mksymtab.sh. Has anyone faced any similar issue? Any help to resolve the issue would be really helpful. Regards, Anjana Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version.
Re: ELF Application Example(apps/examples/elf) undefined references issue in symtab.c
Hi Anjana, Did you add some flags (i.e. CELFFLAGS, CXXELFFLAGS and LDELFFLAGS) to scripts/Make.defs? The flags are needed to build elf modules. Regards, Masayuki 差出人: Anjana 送信日時: 2020年6月18日 14:38 宛先: dev@nuttx.apache.org 件名: ELF Application Example(apps/examples/elf) undefined references issue in symtab.c Hello Team, I have added ELF Binary Loader support for RX65N target. I am currently testing my implementation using the apps/examples/elf/ example . When I enable the apps/examples/elf/ example application, and compile, I am getting the below error in symtab.c (Symbol Table) C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x14): undefined reference to `_fflush' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x1c): undefined reference to `_fopen' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x24): undefined reference to `_fprintf' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x2c): undefined reference to `_getpid' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x34): undefined reference to `_kill' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x3c): undefined reference to `_longjmp' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x44): undefined reference to `_memset' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x4c): undefined reference to `_nxsched_get_streams' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x54): undefined reference to `_printf' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x5c): undefined reference to `_pthread_attr_init' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x64): undefined reference to `_pthread_create' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x6c): undefined reference to `_pthread_exit' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x74): undefined reference to `_pthread_join' . . The above error is obtained for all the symbols generated in symtab.c from mksymtab.sh. Has anyone faced any similar issue? Any help to resolve the issue would be really helpful. Regards, Anjana Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version.
Re: QuickLogic Open Source MCU + FPGA
Great! I was close to ordering a few pieces. But later I saw the shipping costs and gave up. So I wait until it is more accessible in the EU. Open source MCU+FPGA seems to be a powerful tool. czw., 18 cze 2020 o 03:56 Brennan Ashton napisał(a): > This is a chip that I have been excited about for a while since they are > highlighting the open source tool support including the SoC and FPGA > emulation with RENODE. > > Zephyr is the highlighted RTOS, but I thought it would be a great candidate > for NuttX, especially since the MCU is a ARM M4 so the initial porting > should not be too bad. > > I have a couple on the way, and thought others might be interested. > > https://www.quicklogic.com/products/eos-s3/quickfeather-development-kit/ > > https://www.quicklogic.com/software/qorc-mcu-efpga-fpga-open-source-tools/ > > --Brennan >
Re: nrf51822 and BLE
Hi Alan and all, Though I've never used nRF52 before, what we did for Bluetooth with LC823450-XGEVK are (1) Port proprietary Bluetooth stack to NuttX for our audio products. (2) Port bluekitchen/btstack to NuttX for a feasibility study of networking. LC82345-XGEVK has CSR8811 on the board which supports HCI and both Bluetooth stacks support POSIX environments so it was easy for us to port the stacks to NuttX. Regards, Masayuki 差出人: Alan Carvalho de Assis 送信日時: 2020年6月17日 21:13 宛先: dev@nuttx.apache.org 件名: Re: nrf51822 and BLE Hi Mateusz, This is a great idea! Note that zGlue did exactly it, but they are using nRF52. Maybe Sony or Xiaomi has something similar implemented for NuttX and could help. Guys, are you hearing? Xiang? Masayuki? BR, Alan On 6/17/20, raiden00pl . wrote: > You can use Nordic's priorpiate BLE stack (SoftDevice) and after a few > hacks even Nordic SDK can be integrated with Nuttx. > This gives you a certified BLE stack but it has a huge disadvantage - it is > a closed source. Looking for bugs in such an environment is a nightmare. > > Some time ago I started working on the BLE stack for NRF52 integrated with > Nuttx, but I don't have much done at the moment. > I don't think there is an easy way to port the Zephyr BLE stack to Nuttx. > It > looks just as much work as writing it from scratch. > > śr., 17 cze 2020 o 03:32 Matias N. napisał(a): > >> Not sure what you mean by "slave" in this case. What I'm referring to is >> the access to the low-level Bluetooth hardware (register based access to >> radio peripheral). I didn't meant NuttX's BLE stack would only support >> HCI >> UART, I mean that there's no support for NRF radio (link-level layer) on >> NuttX yet. >> >> In other words, using Zephyr figures from their docs, the idea would be >> to >> support this scenario (replace Zephyr with NuttX): >> https://docs.zephyrproject.org/latest/_images/ble_cfg_single.png >> >> Whereas NuttX currently supports the scenario on the left of this figure: >> https://docs.zephyrproject.org/latest/_images/ble_cfg_dual.png >> >> As you mention, this requires code which interfaces the upper bluetooth >> stack with the low-level radio hardware. This is the code that is >> available >> un Zephyr under Apache 2.0 license. >> >> Best, >> Matias >> >> On Tue, Jun 16, 2020, at 22:24, Gregory Nutt wrote: >> > >> > > AFAIK NuttX supports the Host level API and at most HCI UART >> interface. I'm referring to the link-level code which interfaces directly >> with NRF51822 so that you can run NuttX in the board itself (and not as >> an >> external module via UART). >> > It supports both host and slave and uses a driver defined by and >> > interface. HCI UART is *not* assumed or required. I don't know that it >> > is compatible with the NRF. I imagine you would have to use the NRF >> stack. >> > >> >
Re: ELF Application Example(apps/examples/elf) undefined references issue in symtab.c
Yes, I have added CELFFLAGS, CELFFLAGS, LDELFFLAGS in Make.defs file From: Ishikawa, Masayuki (SHES) Sent: 18 June 2020 11:33 To: dev@nuttx.apache.org Subject: Re: ELF Application Example(apps/examples/elf) undefined references issue in symtab.c **This is an external email. Please check the sender’s full email address (not just the sender name) and exercise caution before you respond or click any embedded link/attachment.** Hi Anjana, Did you add some flags (i.e. CELFFLAGS, CXXELFFLAGS and LDELFFLAGS) to scripts/Make.defs? The flags are needed to build elf modules. Regards, Masayuki 差出人: Anjana 送信日時: 2020年6月18日 14:38 宛先: dev@nuttx.apache.org 件名: ELF Application Example(apps/examples/elf) undefined references issue in symtab.c Hello Team, I have added ELF Binary Loader support for RX65N target. I am currently testing my implementation using the apps/examples/elf/ example . When I enable the apps/examples/elf/ example application, and compile, I am getting the below error in symtab.c (Symbol Table) C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x14): undefined reference to `_fflush' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x1c): undefined reference to `_fopen' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x24): undefined reference to `_fprintf' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x2c): undefined reference to `_getpid' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x34): undefined reference to `_kill' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x3c): undefined reference to `_longjmp' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x44): undefined reference to `_memset' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x4c): undefined reference to `_nxsched_get_streams' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x54): undefined reference to `_printf' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x5c): undefined reference to `_pthread_attr_init' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x64): undefined reference to `_pthread_create' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x6c): undefined reference to `_pthread_exit' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x74): undefined reference to `_pthread_join' . . The above error is obtained for all the symbols generated in symtab.c from mksymtab.sh. Has anyone faced any similar issue? Any help to resolve the issue would be really helpful. Regards, Anjana Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email transmission cann
Re: ELF Application Example(apps/examples/elf) undefined references issue in symtab.c
Hi, Can you tell us your github account and the branch in which you are currently having trouble so that we can reproduce the errors? Masayuki From: Anjana Sent: Thursday, June 18, 2020 15:23 To: dev@nuttx.apache.org Subject: Re: ELF Application Example(apps/examples/elf) undefined references issue in symtab.c Yes, I have added CELFFLAGS, CELFFLAGS, LDELFFLAGS in Make.defs file From: Ishikawa, Masayuki (SHES) Sent: 18 June 2020 11:33 To: dev@nuttx.apache.org Subject: Re: ELF Application Example(apps/examples/elf) undefined references issue in symtab.c **This is an external email. Please check the sender’s full email address (not just the sender name) and exercise caution before you respond or click any embedded link/attachment.** Hi Anjana, Did you add some flags (i.e. CELFFLAGS, CXXELFFLAGS and LDELFFLAGS) to scripts/Make.defs? The flags are needed to build elf modules. Regards, Masayuki 差出人: Anjana 送信日時: 2020年6月18日 14:38 宛先: dev@nuttx.apache.org 件名: ELF Application Example(apps/examples/elf) undefined references issue in symtab.c Hello Team, I have added ELF Binary Loader support for RX65N target. I am currently testing my implementation using the apps/examples/elf/ example . When I enable the apps/examples/elf/ example application, and compile, I am getting the below error in symtab.c (Symbol Table) C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x14): undefined reference to `_fflush' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x1c): undefined reference to `_fopen' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x24): undefined reference to `_fprintf' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x2c): undefined reference to `_getpid' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x34): undefined reference to `_kill' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x3c): undefined reference to `_longjmp' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x44): undefined reference to `_memset' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x4c): undefined reference to `_nxsched_get_streams' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x54): undefined reference to `_printf' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x5c): undefined reference to `_pthread_attr_init' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x64): undefined reference to `_pthread_create' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x6c): undefined reference to `_pthread_exit' C:\cygwin64\home\USER\PR_To_Apache\Binary_Loader\incubator-nuttx\staging\libapps.a(symtab.home.USER.PR_To_Apache.Binary_Loader.incubator-nuttx-apps.examples.elf.o):(.rodata.g_elf_exports+0x74): undefined reference to `_pthread_join' . . The above error is obtained for all the symbols generated in symtab.c from mksymtab.sh. Has anyone faced any similar issue? Any help to resolve the issue would be really helpful. Regards, Anjana Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or
