Anna-b112 Bluetooth module support
Hello Nuttx Community, First i would like to say that i really hope that everybody is doing well! I am sorry that long time i didn't had a chance to contribute anything, but life is moving in a very fast pace for me lately. For our sport Wearable system i am working on integration of a Bluetooth module Anna-B112, it is a very interesting small module. The version which we are using is preflashed with Ublox u-connect software and the module is based on nRF52832 nordic chip. I would like to ask for advice on how exactly to implement a relevant support for this to suit Nuttx architecture because i wish to contribute this port when its done. I am familiar that Nuttx has Bluetooth stack and also support for HCI bluetooth modules, but the difference here is that ANNA-B112 has its stack embedder in the nordic chip and the module is controlled via AT commands through UART, so i am not exactly sure how to implement the driver for this module. To me it looks like it has to bypass the nuttx bluetooth stack (because it already has an embedded one) and directly connect to the application layer, please correct me if i am wrong here. I would really appreciate some insight of how exactly to implement the port to suit Nuttx design and to NOT disrupt in any way the already existing implementations of bluetooth connectivity Thank you in advance! -- Kind regards, Ivan Ucherdzhiev CTO @ Barin Sports Bulgaria
Re: Anna-b112 Bluetooth module support
Hello Alan, Its good to hear from you too. So, you don't to flash NuttX inside Anna-B112, but just want to use it as external BT BLE module, right? The Anna module is flashed with u-blox connect and we are using it as external ble module, the module has the whole ble stack embedded in the u-box connect and is controlled via AT commands, thats why i am not sure how exactly to port it for Nuttx in a suitable way. Best regars, Ivan ucherdzhiev На чт, 13.10.2022 г., 18:31 Alan C. Assis написа: > Hi Ivan, > > Nice to hear news from you! > > So, you don't to flash NuttX inside Anna-B112, but just want to use it > as external BT BLE module, right? > > In this case you need to enable the "Bluetooth H4 UART" > > There are some examples on NuttX about how to use it. > > Also you can opt for using NuttX internal BLE Stack (that derives from > an old BLE Stack that Intel integrated on Zephyr and that was released > for Arduino/Genuino under BSD License) or you can use the NimBLE stack > that is more complete and also have examples on NuttX. > > Using the internal stack could be more challenging, but it will help > to improve our own stack. > > BR, > > Alan > > On 10/13/22, Embedded Systems wrote: > > Hello Nuttx Community, > > > > First i would like to say that i really hope that everybody is doing > well! > > I am sorry that long time i didn't had a chance to contribute anything, > but > > life is moving in a very fast pace for me lately. > > > > For our sport Wearable system i am working on integration of a Bluetooth > > module Anna-B112, it is a very interesting small module. The version > which > > we are using is preflashed with Ublox u-connect software and the module > is > > based on nRF52832 nordic chip. I would like to ask for advice on how > > exactly to implement a relevant support for this to suit Nuttx > architecture > > because i wish to contribute this port when its done. I am familiar that > > Nuttx has Bluetooth stack and also support for HCI bluetooth modules, but > > the difference here is that ANNA-B112 has its stack embedder in the > nordic > > chip and the module is controlled via AT commands through UART, so i am > not > > exactly sure how to implement the driver for this module. To me it looks > > like it has to bypass the nuttx bluetooth stack (because it already has > an > > embedded one) and directly connect to the application layer, please > correct > > me if i am wrong here. > > > > I would really appreciate some insight of how exactly to implement the > port > > to suit Nuttx design and to NOT disrupt in any way the already existing > > implementations of bluetooth connectivity > > > > Thank you in advance! > > > > -- > > Kind regards, > > Ivan Ucherdzhiev > > > > CTO @ Barin Sports > > Bulgaria > > >
Re: Anna-b112 Bluetooth module support
Hello Alan, Unfortunately we cannot use the module as HCI H4, we can control it only with AT commands. So in our case IMXRT is running nuttx and its connected to the BLE module with uart and control it with AT commands, so far i just implemented an application in nuttx which controls the module from the user space. The aplication is using a UART char driver to communicate with the module and everything else is managed in the application , but i dont think this is a good way to use the module and i wish to make a driver in nuttx for it, My problem is that i dont see a good way to implement the driver and connect it with the already existing nuttx Bluetooth functionalities . Best regards, Ivan On Thu, Oct 13, 2022 at 11:59 PM Alan C. Assis wrote: > Hi Ivan, > > Normally using external BLE modules that follows the HCI H4 is easier > than porting to some chip with internal BLE and application in the > same chip. > > You can see how it is done in the sim and also here: > > boards/arm/stm32/stm32f4discovery/src/stm32_hciuart.c > > BR, > > Alan > > On 10/13/22, Embedded Systems wrote: > > Hello Alan, > > > > Its good to hear from you too. > > > > So, you don't to flash NuttX inside Anna-B112, but just want to use it > > as external BT BLE module, right? > > > > The Anna module is flashed with u-blox connect and we are using it as > > external ble module, the module has the whole ble stack embedded in the > > u-box connect and is controlled via AT commands, thats why i am not sure > > how exactly to port it for Nuttx in a suitable way. > > > > Best regars, > > Ivan ucherdzhiev > > > > > > На чт, 13.10.2022 г., 18:31 Alan C. Assis написа: > > > >> Hi Ivan, > >> > >> Nice to hear news from you! > >> > >> So, you don't to flash NuttX inside Anna-B112, but just want to use it > >> as external BT BLE module, right? > >> > >> In this case you need to enable the "Bluetooth H4 UART" > >> > >> There are some examples on NuttX about how to use it. > >> > >> Also you can opt for using NuttX internal BLE Stack (that derives from > >> an old BLE Stack that Intel integrated on Zephyr and that was released > >> for Arduino/Genuino under BSD License) or you can use the NimBLE stack > >> that is more complete and also have examples on NuttX. > >> > >> Using the internal stack could be more challenging, but it will help > >> to improve our own stack. > >> > >> BR, > >> > >> Alan > >> > >> On 10/13/22, Embedded Systems wrote: > >> > Hello Nuttx Community, > >> > > >> > First i would like to say that i really hope that everybody is doing > >> well! > >> > I am sorry that long time i didn't had a chance to contribute > anything, > >> but > >> > life is moving in a very fast pace for me lately. > >> > > >> > For our sport Wearable system i am working on integration of a > >> > Bluetooth > >> > module Anna-B112, it is a very interesting small module. The version > >> which > >> > we are using is preflashed with Ublox u-connect software and the > module > >> is > >> > based on nRF52832 nordic chip. I would like to ask for advice on how > >> > exactly to implement a relevant support for this to suit Nuttx > >> architecture > >> > because i wish to contribute this port when its done. I am familiar > >> > that > >> > Nuttx has Bluetooth stack and also support for HCI bluetooth modules, > >> > but > >> > the difference here is that ANNA-B112 has its stack embedder in the > >> nordic > >> > chip and the module is controlled via AT commands through UART, so i > am > >> not > >> > exactly sure how to implement the driver for this module. To me it > >> > looks > >> > like it has to bypass the nuttx bluetooth stack (because it already > has > >> an > >> > embedded one) and directly connect to the application layer, please > >> correct > >> > me if i am wrong here. > >> > > >> > I would really appreciate some insight of how exactly to implement the > >> port > >> > to suit Nuttx design and to NOT disrupt in any way the already > existing > >> > implementations of bluetooth connectivity > >> > > >> > Thank you in advance! > >> > > >> > -- > >> > Kind regards, > >> > Ivan Ucherdzhiev > >> > > >> > CTO @ Barin Sports > >> > Bulgaria > >> > > >> > > > -- Kind regards, Ivan Ucherdzhiev Team Lead @ Barin Sports Bulgaria skype: ipy_44 tel: +359888927760
Re: Anna-b112 Bluetooth module support
Hi Alan, Unfortunately ublox does not, maybe Nordic does, but i dont wish to reflash the module. What i am thinking is to implement an u-connect parser similar to the NMEA parser (GPS parcer) and implement it in utils in apps, in this way i wont disturb the already existing Bluetooth functionality and add support for ublox devices which use u-connect, they have also Wifi and other modules which use u-connect so i think it will be nice addition to have this parser in Nuttx. Best regards, Ivan On Fri, Oct 14, 2022 at 2:53 PM Alan C. Assis wrote: > Hi Ivan, > > Ok, understood the issue! > > Maybe U-Block has an HCI H4 firmware that you can use on Anna-B112 > instead of this AT firmware. It's always a good idea to use and follow > the standard, this is a compelling motivation to use NuttX in the > first place! :-) > > BR, > > Alan > > On 10/14/22, Embedded Systems wrote: > > Hello Alan, > > > > Unfortunately we cannot use the module as HCI H4, we can control it only > > with AT commands. So in our case IMXRT is running nuttx and its connected > > to the BLE module with uart and control it with AT commands, so far i > just > > implemented an application in nuttx which controls the module from the > user > > space. The aplication is using a UART char driver to communicate with the > > module and everything else is managed in the application , but i dont > think > > this is a good way to use the module and i wish to make a driver in nuttx > > for it, My problem is that i dont see a good way to implement the driver > > and connect it with the already existing nuttx Bluetooth functionalities > . > > > > > > Best regards, > > Ivan > > > > On Thu, Oct 13, 2022 at 11:59 PM Alan C. Assis > wrote: > > > >> Hi Ivan, > >> > >> Normally using external BLE modules that follows the HCI H4 is easier > >> than porting to some chip with internal BLE and application in the > >> same chip. > >> > >> You can see how it is done in the sim and also here: > >> > >> boards/arm/stm32/stm32f4discovery/src/stm32_hciuart.c > >> > >> BR, > >> > >> Alan > >> > >> On 10/13/22, Embedded Systems wrote: > >> > Hello Alan, > >> > > >> > Its good to hear from you too. > >> > > >> > So, you don't to flash NuttX inside Anna-B112, but just want to use it > >> > as external BT BLE module, right? > >> > > >> > The Anna module is flashed with u-blox connect and we are using it as > >> > external ble module, the module has the whole ble stack embedded in > the > >> > u-box connect and is controlled via AT commands, thats why i am not > >> > sure > >> > how exactly to port it for Nuttx in a suitable way. > >> > > >> > Best regars, > >> > Ivan ucherdzhiev > >> > > >> > > >> > На чт, 13.10.2022 г., 18:31 Alan C. Assis написа: > >> > > >> >> Hi Ivan, > >> >> > >> >> Nice to hear news from you! > >> >> > >> >> So, you don't to flash NuttX inside Anna-B112, but just want to use > it > >> >> as external BT BLE module, right? > >> >> > >> >> In this case you need to enable the "Bluetooth H4 UART" > >> >> > >> >> There are some examples on NuttX about how to use it. > >> >> > >> >> Also you can opt for using NuttX internal BLE Stack (that derives > from > >> >> an old BLE Stack that Intel integrated on Zephyr and that was > released > >> >> for Arduino/Genuino under BSD License) or you can use the NimBLE > stack > >> >> that is more complete and also have examples on NuttX. > >> >> > >> >> Using the internal stack could be more challenging, but it will help > >> >> to improve our own stack. > >> >> > >> >> BR, > >> >> > >> >> Alan > >> >> > >> >> On 10/13/22, Embedded Systems wrote: > >> >> > Hello Nuttx Community, > >> >> > > >> >> > First i would like to say that i really hope that everybody is > doing > >> >> well! > >> >> > I am sorry that long time i didn't had a chance to contribute > >> anything, > >> >> but > >> >> > life is moving in a very fast pace for me lately. > >> >> > >
Re: Anna-b112 Bluetooth module support
Thank you Alan for you time, really appreciate your advices and recommendations, Hello Miguel, Indirectly yes,as far as i know ublox use softdevice in their u-connect firmware, but not 100 % sure about that. На пт, 14.10.2022 г., 18:21 MIGUEL ALEXANDRE WISINTAINER < tcpipc...@hotmail.com> написа: > Nice > You will use the existent softdevice, right ? > > > Enviado do meu iPhone > > > Em 14 de out. de 2022, à(s) 09:21, Embedded Systems < > ivanucherdj...@gmail.com> escreveu: > > > > Hi Alan, > > > > Unfortunately ublox does not, maybe Nordic does, but i dont wish to > reflash > > the module. What i am thinking is to implement an u-connect parser > similar > > to the NMEA parser (GPS parcer) and implement it in utils in apps, in > this > > way i wont disturb the already existing Bluetooth functionality and add > > support for ublox devices which use u-connect, they have also Wifi and > > other modules which use u-connect so i think it will be nice addition to > > have this parser in Nuttx. > > > > Best regards, > > Ivan > > > >> On Fri, Oct 14, 2022 at 2:53 PM Alan C. Assis > wrote: > >> > >> Hi Ivan, > >> > >> Ok, understood the issue! > >> > >> Maybe U-Block has an HCI H4 firmware that you can use on Anna-B112 > >> instead of this AT firmware. It's always a good idea to use and follow > >> the standard, this is a compelling motivation to use NuttX in the > >> first place! :-) > >> > >> BR, > >> > >> Alan > >> > >>> On 10/14/22, Embedded Systems wrote: > >>> Hello Alan, > >>> > >>> Unfortunately we cannot use the module as HCI H4, we can control it > only > >>> with AT commands. So in our case IMXRT is running nuttx and its > connected > >>> to the BLE module with uart and control it with AT commands, so far i > >> just > >>> implemented an application in nuttx which controls the module from the > >> user > >>> space. The aplication is using a UART char driver to communicate with > the > >>> module and everything else is managed in the application , but i dont > >> think > >>> this is a good way to use the module and i wish to make a driver in > nuttx > >>> for it, My problem is that i dont see a good way to implement the > driver > >>> and connect it with the already existing nuttx Bluetooth > functionalities > >> . > >>> > >>> > >>> Best regards, > >>> Ivan > >>> > >>> On Thu, Oct 13, 2022 at 11:59 PM Alan C. Assis > >> wrote: > >>> > >>>> Hi Ivan, > >>>> > >>>> Normally using external BLE modules that follows the HCI H4 is easier > >>>> than porting to some chip with internal BLE and application in the > >>>> same chip. > >>>> > >>>> You can see how it is done in the sim and also here: > >>>> > >>>> boards/arm/stm32/stm32f4discovery/src/stm32_hciuart.c > >>>> > >>>> BR, > >>>> > >>>> Alan > >>>> > >>>> On 10/13/22, Embedded Systems wrote: > >>>>> Hello Alan, > >>>>> > >>>>> Its good to hear from you too. > >>>>> > >>>>> So, you don't to flash NuttX inside Anna-B112, but just want to use > it > >>>>> as external BT BLE module, right? > >>>>> > >>>>> The Anna module is flashed with u-blox connect and we are using it as > >>>>> external ble module, the module has the whole ble stack embedded in > >> the > >>>>> u-box connect and is controlled via AT commands, thats why i am not > >>>>> sure > >>>>> how exactly to port it for Nuttx in a suitable way. > >>>>> > >>>>> Best regars, > >>>>> Ivan ucherdzhiev > >>>>> > >>>>> > >>>>> На чт, 13.10.2022 г., 18:31 Alan C. Assis > написа: > >>>>> > >>>>>> Hi Ivan, > >>>>>> > >>>>>> Nice to hear news from you! > >>>>>> > >>>>>> So, you don't to flash NuttX inside Anna-B112, but just want to use > >> it > >>>>>> as external BT BLE module, right? > >>>>>> > >
Re: Help to spread the news about NuttX
Hello, Congratulations! We posted this on our page and used the Sony's page as reference , hope that is now a problem. http://barinsports.com/2022/11/23/barin-sports-pro-powered-by-nuttx-apache-nuttx-is-now-announced-as-a-top-level-project/ Best regards, Ivan Ucherdzhiev On Wed, Nov 23, 2022 at 1:20 PM Alan C. Assis wrote: > Dear NuttXers, > > We are asked some friends sites to post about the fact that NuttX became a > Top Level Apache project. > > Today many sites expect some payment to publish the news. > > We want to thank CNX-Software for publishing about EsPiFF board and include > the fact in the text: > > > https://www.cnx-software.com/2022/11/23/espiff-esp32-wrover-rp2040-mcu-raspberry-pi-4/ > > Also Sony: > > > https://developer.sony.com/develop/nuttx-rtos-on-spresense/news-and-articles > > So if you have some friend on some media site please ask them to publish > about it too. It will help as to reach more people. > > BR, > > Alan > -- Kind regards, Ivan Ucherdzhiev Team Lead @ Barin Sports Bulgaria skype: ipy_44 tel: +359888927760
Re: Help to spread the news about NuttX
Please excuse me, I saw that i made a mistake in my previous mail at this line" hope that is now a problem." i ment that i hope its noT a problem that we used Sony's page as reference, please let me know we need to change it. Best regards, Ivan Ucherdzhiev On Wed, Nov 23, 2022 at 1:56 PM Embedded Systems wrote: > Hello, > > Congratulations! > > We posted this on our page and used the Sony's page as reference , hope > that is now a problem. > > > http://barinsports.com/2022/11/23/barin-sports-pro-powered-by-nuttx-apache-nuttx-is-now-announced-as-a-top-level-project/ > > Best regards, > Ivan Ucherdzhiev > > On Wed, Nov 23, 2022 at 1:20 PM Alan C. Assis wrote: > >> Dear NuttXers, >> >> We are asked some friends sites to post about the fact that NuttX became a >> Top Level Apache project. >> >> Today many sites expect some payment to publish the news. >> >> We want to thank CNX-Software for publishing about EsPiFF board and >> include >> the fact in the text: >> >> >> https://www.cnx-software.com/2022/11/23/espiff-esp32-wrover-rp2040-mcu-raspberry-pi-4/ >> >> Also Sony: >> >> >> https://developer.sony.com/develop/nuttx-rtos-on-spresense/news-and-articles >> >> So if you have some friend on some media site please ask them to publish >> about it too. It will help as to reach more people. >> >> BR, >> >> Alan >> > > > -- > Kind regards, > Ivan Ucherdzhiev > > Team Lead @ Barin Sports > Bulgaria > skype: ipy_44 > tel: +359888927760 > -- Kind regards, Ivan Ucherdzhiev Team Lead @ Barin Sports Bulgaria skype: ipy_44 tel: +359888927760
Re: Imxrt 1050
Hello, I found what is cousin that behaviour it is the WFI instruction in the idle task. Please excuse me for bothering you. Best regards, Ivan Ucherdzhiev On Tue, Jan 7, 2020 at 3:15 PM Embedded Systems wrote: > Hello > > I wish to ask for little bti help. I updated my nuttx to the > latest version since i want to update my work with the latest Nuttx > version, because i will resume working on drivers for Imxrt1050, but i am > facing a strange problem when i tried the new Nuttx builded the > imxrt1050-evk:nsh uploaded the firmware everything is working properly but > i cannot flash new firmware if i do not switch the board in Serial > downloader. Previously i didnt need to switch the board in Serial > downloader mdoe in order to flash firmware . Any idea is there > something changed on the SWD debug is it disabled? > > Thank you in advance > Best regards, > Ivan ucherdzhiev > -- Kind regards, Ivan Ucherdzhiev Team Lead @ Barin Sports Bulgaria skype: ipy_44 tel: +359888927760
Imxrt 1050
Hello I wish to ask for little bti help. I updated my nuttx to the latest version since i want to update my work with the latest Nuttx version, because i will resume working on drivers for Imxrt1050, but i am facing a strange problem when i tried the new Nuttx builded the imxrt1050-evk:nsh uploaded the firmware everything is working properly but i cannot flash new firmware if i do not switch the board in Serial downloader. Previously i didnt need to switch the board in Serial downloader mdoe in order to flash firmware . Any idea is there something changed on the SWD debug is it disabled? Thank you in advance Best regards, Ivan ucherdzhiev
Format MMC
Hello, I have a custom board with imxrt1050 and eMMC memory on it. The communication between the imxrt1050 and the eMMC is working perfectly but my problem is that the eMMC comes not formatted. So i would like to ask is it possible to Format a eMMC/SDcard in FAT32 file system from nuttx command line? Thank you in advance! Best regards, Ivan Ucherdzhiev
Re: Format MMC
Hello Please excuse me i found the mkfatfs command and everything is working perfectly. Please excuse me for disturbing you. Have a good day! On Tue, Jan 21, 2020 at 5:52 PM Embedded Systems wrote: > Hello, > > I have a custom board with imxrt1050 and eMMC memory on it. The > communication between the imxrt1050 and the eMMC is working perfectly but > my problem is that the eMMC comes not formatted. So i would like to ask is > it possible to Format a eMMC/SDcard in FAT32 file system from nuttx command > line? > > Thank you in advance! > > Best regards, > Ivan Ucherdzhiev > -- Kind regards, Ivan Ucherdzhiev Team Lead @ Barin Sports Bulgaria skype: ipy_44 tel: +359888927760
Re: Format MMC
Hello Mr. Gregory, I am using 4 GB eMMC at the moment , and so far it is working perfectly. Nuttx is recognizing the eMMC it is able to format it in FAT and now i am able to mount it , read and write in it, so so far i have no problems at all with the eMMC. THe only thing is that i use 1 wire setup so , I am not using the full speed which eMMC can offer but for my case that is okay. Later on i am planning to add also the Fast modes and 4 wire and 8 wire support. Best regards, Ivan Ucherdzhiev On Tue, Jan 21, 2020 at 6:36 PM Gregory Nutt wrote: > > > Please excuse me i found the mkfatfs command and everything is working > > perfectly. Please excuse me for disturbing you. > > I don't really know very much about eMMC, but the MMC support in NuttX > was designed and implemented only for Classic MMC cards. I have heard > reports from you and other people that it works with eMMC. But that > just shows that they supported backward compatibility with old MMC cards. > > My understanding is the eMMC has extensions -- including 4-bit width > transfers -- that are not implemented. I suspect that if you really > want proper eMMC performance, those extensions would need to be > implemented. > > Greg > > > -- Kind regards, Ivan Ucherdzhiev Team Lead @ Barin Sports Bulgaria skype: ipy_44 tel: +359888927760
Re: Imxrt 1050
Hello Dave, Thank you very much for the information. I will also keep an eye if i see something in that direction! Best regards, Ivan Ucherdzhiev On Tue, Jan 28, 2020 at 12:55 AM Dave Marples wrote: > > On 07/01/2020 13:42, Embedded Systems wrote: > > Hello, > > > > I found what is cousin that behaviour it is the WFI instruction in the > idle > > task. Please excuse me for bothering you. > > > Ivan, > > This does not happen when programming imxrt in other environments (e.g. > Zephyr, FreeRTOS) and is a concern to me since it implies there's a > clock not switched on properly somewhere. We had this problem with the > tick timer not interrupting when WFI was first (re-)enabled but that one > was fixed. Chances are there's another bit hidden in one of the GPR > registers controlling this. I'm back now so will investigate...just 2000 > emails to catch up with first. > > Regards > > DAVE > > > -- Kind regards, Ivan Ucherdzhiev Team Lead @ Barin Sports Bulgaria skype: ipy_44 tel: +359888927760
IMXRT1050 USDHC
Hello, I found a typo mistake in the USDHC driver related to the card detect pin. It is a pretty simple one. Can someone tell me how toapplay a patch for it. Or someone who know how to do it do the following changes and apply them. Thank you in advance! in file /arch/arm/src/imxrt/imxrt_usdhc.c Line 379-381 #if defined(PIN_USDHC1_CD_GPIO) .sw_cd_gpio = PIN_USDHC1_CD_GPIO, #endif should be changed to #if defined(PIN_USDHC1_CD) .sw_cd_gpio = PIN_USDHC1_CD, #endif And same file at lines 437-439 #if defined(PIN_USDHC2_CD_GPIO) .sw_cd_gpio = PIN_USDHC2_CD_GPIO, #endif should be changed to #if defined(PIN_USDHC2_CD) .sw_cd_gpio = PIN_USDHC2_CD, #endif -- Kind regards, Ivan Ucherdzhiev Team Lead @ Barin Sports Bulgaria skype: ipy_44 tel: +359888927760
Re: IMXRT1050 USDHC
Hello Dave,
Thank you for your response, but if that is correct then the driver do not
work for imxrt1050 because of following
#if defined(CONFIG_MMCSD_HAVE_CARDDETECT)
# if defined(PIN_USDHC1_CD)
imxrt_config_gpio(PIN_USDHC1_CD);
# else
if (priv->sw_cd_gpio != 0)
{
imxrt_config_gpio(priv->sw_cd_gpio);
}
# endif
#endif
here you initialize the PIN_USDHC1_CD but you never say that sw_cd_gpio
= PIN_USDHC1_CD which makes the following check to fail and never use
the PIN_USDHC1_CD for detecting
if (priv->sw_cd_gpio != 0)
{
present = priv->cd_invert ^ !imxrt_gpio_read(priv->sw_cd_gpio);
}
else
{
so if _GPIO suffix need to stay then the following lines need to be changes
lines 3088 - 3097
#if defined(CONFIG_MMCSD_HAVE_CARDDETECT)
# if defined(PIN_USDHC1_CD)
imxrt_config_gpio(PIN_USDHC1_CD);
# else
if (priv->sw_cd_gpio != 0)
{
imxrt_config_gpio(priv->sw_cd_gpio);
}
# endif
#endif
need to be
# if defined(PIN_USDHC1_CD)
priv->sw_cd_gpio = PIN_USDHC1_CD ;
imxrt_config_gpio(PIN_USDHC1_CD);
# else
if (priv->sw_cd_gpio != 0)
{
imxrt_config_gpio(priv->sw_cd_gpio);
}
# endif
#endif
On Thu, Jan 30, 2020 at 2:57 PM David Sidrane
wrote:
> Hi Ivan,
>
>
> It is correct. It fixes a bug that was added when the imxrt1020 came in.
> Apparently Dave did not wire the CD pin of the IC to the socket (He used a
> GPIO). But that change broke the case were the CD pin of the IC is wired to
> the socket
>
> Please See
>
> https://github.com/apache/incubator-nuttx/commit/2e71e0632f8106d1505d313e7171904536feec45#diff-787575b8e98a29e0a9d088767a68b280
>
> It is to use allow the use of a standard GPIO pin for card detect OR the
> use of the USDHC dedicated CD pin. (it also supports inversion of the pin
> or
> CD detect bit)
>
> If you wire CD to the USDHC CD pin you define PIN_USDHC1_CD (as
> PIN_USDHC1_CD_n) in board.h.
>
> See
>
> https://github.com/apache/incubator-nuttx/blob/master/boards/arm/imxrt/imxrt1060-evk/include/board.h#L215
>
> If you use a regular GPIO you define PIN_USDHC1_CD_GPIO (as GPIO_PORTn |
> GPIO_PINn) in board.h
>
> See
>
> https://github.com/apache/incubator-nuttx/blob/master/boards/arm/imxrt/imxrt1020-evk/include/board.h#L271
>
>
> Regards,
>
> David
>
> -Original Message-
> From: Embedded Systems [mailto:ivanucherdj...@gmail.com]
> Sent: Wednesday, January 29, 2020 11:51 PM
> To: dev@nuttx.apache.org
> Subject: IMXRT1050 USDHC
>
> Hello,
>
> I found a typo mistake in the USDHC driver related to the card detect pin.
> It is a pretty simple one. Can someone tell me how toapplay a patch for it.
> Or someone who know how to do it do the following changes and apply them.
> Thank you in advance!
>
> in file /arch/arm/src/imxrt/imxrt_usdhc.c
>
> Line 379-381
>
> #if defined(PIN_USDHC1_CD_GPIO)
> .sw_cd_gpio = PIN_USDHC1_CD_GPIO,
> #endif
> should be changed to
> #if defined(PIN_USDHC1_CD)
> .sw_cd_gpio = PIN_USDHC1_CD,
> #endif
>
> And same file at lines 437-439
>
> #if defined(PIN_USDHC2_CD_GPIO)
> .sw_cd_gpio = PIN_USDHC2_CD_GPIO,
> #endif
>
> should be changed to
>
> #if defined(PIN_USDHC2_CD)
> .sw_cd_gpio = PIN_USDHC2_CD,
> #endif
>
>
>
> --
> Kind regards,
> Ivan Ucherdzhiev
>
> Team Lead @ Barin Sports
> Bulgaria
> skype: ipy_44
> tel: +359888927760
>
--
Kind regards,
Ivan Ucherdzhiev
Team Lead @ Barin Sports
Bulgaria
skype: ipy_44
tel: +359888927760
Re: IMXRT1050 USDHC
oh David, please excuse me!
On Thu, Jan 30, 2020 at 3:45 PM Embedded Systems
wrote:
> Hello Dave,
>
> Thank you for your response, but if that is correct then the driver do not
> work for imxrt1050 because of following
> #if defined(CONFIG_MMCSD_HAVE_CARDDETECT)
> # if defined(PIN_USDHC1_CD)
> imxrt_config_gpio(PIN_USDHC1_CD);
> # else
> if (priv->sw_cd_gpio != 0)
> {
> imxrt_config_gpio(priv->sw_cd_gpio);
> }
> # endif
> #endif
>
> here you initialize the PIN_USDHC1_CD but you never say that sw_cd_gpio
> = PIN_USDHC1_CD which makes the following check to fail and never use
> the PIN_USDHC1_CD for detecting
>
> if (priv->sw_cd_gpio != 0)
> {
> present = priv->cd_invert ^ !imxrt_gpio_read(priv->sw_cd_gpio);
> }
> else
> {
>
>
> so if _GPIO suffix need to stay then the following lines need to be
> changes lines 3088 - 3097
>
> #if defined(CONFIG_MMCSD_HAVE_CARDDETECT)
> # if defined(PIN_USDHC1_CD)
> imxrt_config_gpio(PIN_USDHC1_CD);
> # else
> if (priv->sw_cd_gpio != 0)
> {
> imxrt_config_gpio(priv->sw_cd_gpio);
> }
> # endif
> #endif
>
> need to be
> # if defined(PIN_USDHC1_CD)
>priv->sw_cd_gpio = PIN_USDHC1_CD ;
> imxrt_config_gpio(PIN_USDHC1_CD);
> # else
> if (priv->sw_cd_gpio != 0)
> {
> imxrt_config_gpio(priv->sw_cd_gpio);
> }
> # endif
> #endif
>
>
>
>
> On Thu, Jan 30, 2020 at 2:57 PM David Sidrane
> wrote:
>
>> Hi Ivan,
>>
>>
>> It is correct. It fixes a bug that was added when the imxrt1020 came in.
>> Apparently Dave did not wire the CD pin of the IC to the socket (He used a
>> GPIO). But that change broke the case were the CD pin of the IC is wired
>> to
>> the socket
>>
>> Please See
>>
>> https://github.com/apache/incubator-nuttx/commit/2e71e0632f8106d1505d313e7171904536feec45#diff-787575b8e98a29e0a9d088767a68b280
>>
>> It is to use allow the use of a standard GPIO pin for card detect OR the
>> use of the USDHC dedicated CD pin. (it also supports inversion of the pin
>> or
>> CD detect bit)
>>
>> If you wire CD to the USDHC CD pin you define PIN_USDHC1_CD (as
>> PIN_USDHC1_CD_n) in board.h.
>>
>> See
>>
>> https://github.com/apache/incubator-nuttx/blob/master/boards/arm/imxrt/imxrt1060-evk/include/board.h#L215
>>
>> If you use a regular GPIO you define PIN_USDHC1_CD_GPIO (as GPIO_PORTn |
>> GPIO_PINn) in board.h
>>
>> See
>>
>> https://github.com/apache/incubator-nuttx/blob/master/boards/arm/imxrt/imxrt1020-evk/include/board.h#L271
>>
>>
>> Regards,
>>
>> David
>>
>> -Original Message-
>> From: Embedded Systems [mailto:ivanucherdj...@gmail.com]
>> Sent: Wednesday, January 29, 2020 11:51 PM
>> To: dev@nuttx.apache.org
>> Subject: IMXRT1050 USDHC
>>
>> Hello,
>>
>> I found a typo mistake in the USDHC driver related to the card detect pin.
>> It is a pretty simple one. Can someone tell me how toapplay a patch for
>> it.
>> Or someone who know how to do it do the following changes and apply them.
>> Thank you in advance!
>>
>> in file /arch/arm/src/imxrt/imxrt_usdhc.c
>>
>> Line 379-381
>>
>> #if defined(PIN_USDHC1_CD_GPIO)
>> .sw_cd_gpio = PIN_USDHC1_CD_GPIO,
>> #endif
>> should be changed to
>> #if defined(PIN_USDHC1_CD)
>> .sw_cd_gpio = PIN_USDHC1_CD,
>> #endif
>>
>> And same file at lines 437-439
>>
>> #if defined(PIN_USDHC2_CD_GPIO)
>> .sw_cd_gpio = PIN_USDHC2_CD_GPIO,
>> #endif
>>
>> should be changed to
>>
>> #if defined(PIN_USDHC2_CD)
>> .sw_cd_gpio = PIN_USDHC2_CD,
>> #endif
>>
>>
>>
>> --
>> Kind regards,
>> Ivan Ucherdzhiev
>>
>> Team Lead @ Barin Sports
>> Bulgaria
>> skype: ipy_44
>> tel: +359888927760
>>
>
>
> --
> Kind regards,
> Ivan Ucherdzhiev
>
> Team Lead @ Barin Sports
> Bulgaria
> skype: ipy_44
> tel: +359888927760
>
--
Kind regards,
Ivan Ucherdzhiev
Team Lead @ Barin Sports
Bulgaria
skype: ipy_44
tel: +359888927760
linking problem
Hello , I would like to ask for little bit help. I am trying to build imxrt1050 custom board with libcxx, but in the linking i have the following problem /usr/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/lib/thumb/v7e-m/fpv5/hard/libsupc++.a(vterminate.o): In function `__gnu_cxx::__verbose_terminate_handler()': vterminate.cc:(.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0xf8): undefined reference to `_impure_ptr' anyone have any idea how that can be fixed? THank you in advance Best regards, Ivan Ucherdzhiev
Linker error
Hello, I need a little bit help if possible. I am using libcxx in my project but wil the new nuttx i start having an error during the linking libsupc++.a(vterminate.o): In function `__gnu_cxx::__verbose_terminate_handler()': vterminate.cc:(.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0xfc): undefined reference to `_impure_ptr' i tried the solution from here http://nuttx.org/doku.php?id=wiki:nshhowtos:build-uclibcpp but it does nto work with libcxx and now i am getting the following error libsupc++.a(eh_term_handler.o):(.data._ZN10__cxxabiv119__terminate_handlerE+0x0): undefined reference to `__gnu_cxx::__verbose_terminate_handler()' Do someone know another solution of this problem? Thank you in advance! Best regards, Ivan Ucherdzhiev
Re: Linker error
Hello David, Thank you very much for your response! I excluded the -lsupc++ from my Make.deps file and it works now. Best regards, Ivan Ucherdzhiev! On Tue, Feb 4, 2020 at 2:45 PM David Sidrane wrote: > Ivan, > > There is a limit on what C++ can be compiled and built with Nuttx. > > The key is to not include any foreign (non nuttx) headers you can see the > defconfigs setting used on PX4 here > > https://github.com/PX4/Firmware/tree/master/boards/px4/fmu-v5/nuttx-config/nsh > and the things needed in Make.def here > > https://github.com/PX4/Firmware/blob/master/platforms/nuttx/CMakeLists.txt#L100-L119 > > Of Note -nostartfiles > -nodefaultlibs > -nostdlib > -nostdinc++ > > -fno-exceptions > -fno-rtti > > Then ensure the C++ objects are not dependant on anything other that > compile > time code (templates) > > I hope this helps, > > David > > -Original Message- > From: Embedded Systems [mailto:ivanucherdj...@gmail.com] > Sent: Tuesday, February 04, 2020 1:34 AM > To: dev@nuttx.apache.org > Subject: Linker error > > Hello, > > I need a little bit help if possible. I am using libcxx in my project but > wil the new nuttx i start having an error during the linking > > libsupc++.a(vterminate.o): In function > `__gnu_cxx::__verbose_terminate_handler()': > vterminate.cc:(.text._ZN9__gnu_cxx27__verbose_terminate_handlerEv+0xfc): > undefined reference to `_impure_ptr' > > > i tried the solution from here > > http://nuttx.org/doku.php?id=wiki:nshhowtos:build-uclibcpp > > but it does nto work with libcxx and now i am getting the following error > > > > libsupc++.a(eh_term_handler.o):(.data._ZN10__cxxabiv119__terminate_handlerE+0x0): > undefined reference to `__gnu_cxx::__verbose_terminate_handler()' > > Do someone know another solution of this problem? > > Thank you in advance! > > Best regards, > Ivan Ucherdzhiev > -- Kind regards, Ivan Ucherdzhiev Team Lead @ Barin Sports Bulgaria skype: ipy_44 tel: +359888927760
