nRF52840 Reporting to Arduino LCD shield?

RE: nRF52840 Reporting to Arduino LCD shield?

Edvin — Mon, 03 Feb 2020 09:06:37 GMT

What you can do, on the nRF side, you can try to analyze the SPI pins using a logic analyzer to see whether the data is actually coming out from the nRF. Another thing you can check is what SPI mode you screen use. If you look in the hardware_init() function, which sets up the spi:

    nrf_drv_spi_config_t spi_config = NRF_DRV_SPI_DEFAULT_CONFIG;

    spi_config.sck_pin  = ILI9341_SCK_PIN;
    spi_config.miso_pin = ILI9341_MISO_PIN;
    spi_config.mosi_pin = ILI9341_MOSI_PIN;
    spi_config.ss_pin   = ILI9341_SS_PIN;

    err_code = nrf_drv_spi_init(&spi, &spi_config, NULL, NULL);
    return err_code;

The NRF_DRVI_SPI_DEFAULT_CONFIG uses NRF_DRV_SPI_MODE_0. Try to set:

spi_config.mode = NRF_DRV_SPI_MODE_1 to NRF_DRV_SPI_MODE_3, and see if that makes any difference.

And for each mode, try to connect DC to both GND and VDD.

BR,

Edvin

RE: nRF52840 Reporting to Arduino LCD shield?

Edvin — Mon, 03 Feb 2020 08:41:55 GMT

I don't think DS pins are standard SPI pins. I found this, however. Just try to set it low and high, to see whether one works and one doesn't.

RE: nRF52840 Reporting to Arduino LCD shield?

SRall — Sun, 02 Feb 2020 21:27:52 GMT

Edvin,

Thank you for staying with me here so far, your help is much appreciated. I've double checked our connections with the pin-out you've provided above. Indeed they were the same as we've had them configured so far. Any thoughts on the 'DC' pin labeled on the LCD PCB? Looking at the data sheet of the LCD Display, it seems that pin would be best pulled to Ground or N.C. for this \gfx example. So far, we've had it N.C.

So, starting with that, our next steps will have to be checking the display for issues, and finally with a different 840 DK. Any chance you have some insight as to what's going on?

Thanks again,

Sam

RE: nRF52840 Reporting to Arduino LCD shield?

Edvin — Mon, 27 Jan 2020 08:54:22 GMT

Let us assume that you didn't change much in the gfx example.

By default, it uses the configuration of the ili9341, which is the one you are using.

By default in this project, the following pins are set on the nRF52840:

SCK(clock): P1.15

MISO(SDO): P1.14

MOSI(SDI): P1.13

SS/CS: P1.12

These should be connected to the corresponding pins on the screen, respectively: SCK, SDO, SDI, CS. In addition, you need to supply it with GND and VDD (0V and 3V), and for good measure, I would also connect LED (power for background light) to VDD, and RESET to pin P0.18. Please also check that SB42 on the DK is not cut (it should be shorted by default, so if you haven't cut it, it is fine).

What does the log from the gfx application say when you run it?

Best regards,

Edvin

RE: nRF52840 Reporting to Arduino LCD shield?

SRall — Mon, 27 Jan 2020 04:30:41 GMT

Update on the Received Signal Strength Reporting:

[quote userid="86978" url="~/f/nordic-q-a/56887/nrf52840-reporting-to-arduino-lcd-shield/230949"]The only two parameters I'm really after are the Tx Signal strength to reference with as well as the Rx sensitivity of each connection (displayed on the central board). Can you point me to some of these parameters? Or resources?[/quote]

Was able to log the rssi of the current connection to the console by use of the sd_ble_gap_rssi_start() and sd_ble_gap_rrsi_get() wrapped in a BLE_GAP_EVT_RSSI_CHANGED event to the handler. So, similar to what you mentioned in your initial reply. Really appreciate the guidance here mate.

RE: nRF52840 Reporting to Arduino LCD shield?

SRall — Mon, 27 Jan 2020 04:21:45 GMT

Edvin,

I hope you don't mind me coming back to this. We took you up on your advice about eventually remapping the SPI pins to our custom pins, and simply using an ILI9341 controlled LCD Display. We settled on the 2.8in TFT SPI Module.

*No SPI pins were remapped at this point*

To be efficient, we are just quickly setting it up to work with the gfx SDK example out of the box. The pins were a little tricky to figure out, as they don't quite match SPI X-wire formats. But, we believe we were able to wire it to our nRF52840 PDK with 2x checked accuracy.

Problem is: Running the gfx example leaves a blank display (LED back light is lit).

Given the hardware mentioned, do you foresee an issue that might cause this symptom?

RE: nRF52840 Reporting to Arduino LCD shield?

SRall — Fri, 24 Jan 2020 20:58:48 GMT

Thanks so much for the info. As far as the display, you make a good point. I may go back to reconsidering just how I go about the actual display, bearing this in mind. So thank you.

As far as the reporting, I am, in fact, hoping to fetch data that have to do with an actual Bluetooth connection. Actually, the entire scheme will involve one board running ble multi-link central firmware while connected to three (3) other boards running ble_peripheral firmware. The only two parameters I'm really after are the Tx Signal strength to reference with as well as the Rx sensitivity of each connection (displayed on the central board). Can you point me to some of these parameters? Or resources?

Thanks again for your time,

Sam

RE: nRF52840 Reporting to Arduino LCD shield?

Edvin — Fri, 24 Jan 2020 09:59:44 GMT

Depends on what you want to do. Are you going to actually connect, or just fetch RSSI (signal strength) from advertising devices? Either way, you should look into one of the examples from the SDK\examples\ble_central folder. The examples here will typically look for a specific advertising device, and try to connect to that device. You can try to remove the filters that are applied by removing nrf_ble_scan_filter_set() and nrf_ble_scan_filters_enable(). Then try to add the BLE_GAP_EVT_ADV_REPORT event to your ble_evt_handler() in main.c.

Then you will get this event every time you pick up an advertisment packet. Inside this event, these parameters will probably be interesting for you:

p_ble_evt->evt.gap_evt.params.adv_report.data.p_data
p_ble_evt->evt.gap_evt.params.adv_report.data.len
p_ble_evt->evt.gap_evt.params.adv_report.rssi
p_ble_evt->evt.gap_evt.params.adv_report.peer_addr.addr[]   // addr[0] -> addr[5]

as for the display, you can try to change it from using SPI to I2C/TWI. I just thought that this example would be a good starting point to get the screen up and running.

You can look into changing the init and send functions to set up TWI instead of SPI.

[quote user="Sam_Rall"]this application is to be migrated to a 3rd party board in which the SPI pins are not available[/quote]

Not quite sure I follow you here. The SPI pins aren't available? You can use any pins as SPI pins on the nRF.

Best regards,

Edvin

RE: nRF52840 Reporting to Arduino LCD shield?

SRall — Thu, 23 Jan 2020 15:39:04 GMT

For 2)

After some research on a compatible LCD, it seems the two controllers supported in the gfx example require the SPI pins. This is going to be a problem for me because eventually this application is to be migrated to a 3rd party board in which the SPI pins are not available. 😞

So, moving on to a different LCD controller, I found a lot of documentation & support for the Hitachi HD44780. If I include all the appropriate drivers/libraries and dependencies, should be able to display some characters from the DK right? Has anyone used the Hitachi HD44780 controller on the PCA10056 before?

Thanks again for your time.

RE: nRF52840 Reporting to Arduino LCD shield?

SRall — Thu, 23 Jan 2020 14:42:42 GMT

Great point, that is a good strategy. Appreciate the pointer to the gfx example, anywhere you can point me to help with #1?

[quote userid="26071" url="~/f/nordic-q-a/56887/nrf52840-reporting-to-arduino-lcd-shield/230549"]1: You need to be able to fetch all the data that you at a some point want to display on the screen, but start with checking that you are able to view it in the log.[/quote]

Thanks again for your time.

RE: nRF52840 Reporting to Arduino LCD shield?

Edvin — Thu, 23 Jan 2020 10:31:11 GMT

Hello,

This question is really divided in two, and I suggest that you do that with the development as well.

1: You need to be able to fetch all the data that you at a some point want to display on the screen, but start with checking that you are able to view it in the log.

2: You need to be able to communicate with the screen.

I am not sure whether you have started looking into any of these yet, but I suggest that you try to separate these tasks first.

For 2), I suggest that you look into the example found in:

SDK\examples\peripheral\gfx, as this is an LCD screen example. If you use another LCD screen than the ones supported in this example, you must find some drivers that works for your screen. You can find the testing description for this example here.

Best regards,

Edvin