This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Read external sensors with UART interface

Basically, it can be divided into two cases

Reading/sampling TX pin of the sensor (since usually nothing is sended back)

Send/Read possibility - in case of range switching/calibrating/programming

How easy/or how difficult is to have additional UART. I guess the only one is dedicated on the Bluetooth connection, and on first glance I don't see any UART connections. May be another serial standard as I2C will be OK, but there is sensors which really has only UART.

Parents
  • Sorry Dimitar but your question sounds confusing. What do you mean by UART exactly? Do you refer for Nordic BLE UART Service (NUS) which is just "something like UART over BLE radio and stack on top of GATT layer" or to physical wired UART interface? They have almost nothing in common (meaning that NUS is just "emulating" UART data transfer experience over BLE but it can be fed by data independently on wired UART interface which you can use on nRF5x chip for whatever else if you need).

    If you need two physical wired UART connections (e.g. to two peripheral chips like sensors which don't support SPI or IC) then you have a problem. You might try to emulate UART by bit banging GPIO pins inside your FW but that will work only if you will use this "interface" when nothing else is running (especially no BLE activity like Connection events) and when the baud rate will be low. Most of people facing this dilemma with nRF5x chips (which have only one native UART HW block) solved it by choosing different components support SPI/I2C or by using another multi-peripheral general purpose (low power) controller which served all these chips and then it aggregated all the data into one wired protocol with nRF5x (SPI is usual option due to speed).

    Cheers Jan

Reply
  • Sorry Dimitar but your question sounds confusing. What do you mean by UART exactly? Do you refer for Nordic BLE UART Service (NUS) which is just "something like UART over BLE radio and stack on top of GATT layer" or to physical wired UART interface? They have almost nothing in common (meaning that NUS is just "emulating" UART data transfer experience over BLE but it can be fed by data independently on wired UART interface which you can use on nRF5x chip for whatever else if you need).

    If you need two physical wired UART connections (e.g. to two peripheral chips like sensors which don't support SPI or IC) then you have a problem. You might try to emulate UART by bit banging GPIO pins inside your FW but that will work only if you will use this "interface" when nothing else is running (especially no BLE activity like Connection events) and when the baud rate will be low. Most of people facing this dilemma with nRF5x chips (which have only one native UART HW block) solved it by choosing different components support SPI/I2C or by using another multi-peripheral general purpose (low power) controller which served all these chips and then it aggregated all the data into one wired protocol with nRF5x (SPI is usual option due to speed).

    Cheers Jan

Children
No Data
Related