Reading WS2812b leftover data through I2S

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Tue, 26 Feb 2019 08:06:34 GMT

[quote user="Winz"]Okay so what I'm achieving now is to capture all the pulse's timing. I am really curious about this: will I be able to capture all rising edge and falling edge using one PPI channel and set GPIOTE's task to sense toggle?[/quote]

It should be possible. You could configure the GPIOTE channel to generate an event on toggling, and hook that up to a timer via a single PPI channel and use it to capture the counter value. Then you can use a short in the timer to reset the timer. You should also enable a interrupt whenever a new timer value is stored.

The downside with this is that you have to process the interrupts rapidly, between every toggle. You could half this by for instance using two GPIOTEs, two PPI channels and hooking them to separate CC registers (on the same timer or on two different timers). Essentially this is like LEGO, so you can hook things up in different ways and still achieve the same basic end goal.

[quote user="Winz"]And I would like to know how to store the data in. Will you be able to provide me some info on how to do that? I've searched anywhere but did not really see how to store the value when it detects transitions.[/quote]

The data sample (time) is stored in the CC register of the timer. You would typically configure the timer to generate an interrupt so that you can read the data sample form the CC register and clear the interrupt (being ready for the next sample).

[quote user="Winz"]I referred here, and the example code provided was able to capture the time. I adapted here, but I was able to capture (at most) the periods of 16 data, when I expect 24. I guess it's GPIOTE, not PPI.[/quote]

Yes, this demonstrates much of what we have discussed. You can use it as a reference. I did not understand what you mean by only being able to capture periods of 16 data, though. Can you elaborate?

RE: Reading WS2812b leftover data through I2S

Winz — Sat, 23 Feb 2019 05:13:31 GMT

ahh.. let's leave the second question alone.

Okay so what I'm achieving now is to capture all the pulse's timing. I am really curious about this: will I be able to capture all rising edge and falling edge using one PPI channel and set GPIOTE's task to sense toggle?

And I would like to know how to store the data in. Will you be able to provide me some info on how to do that? I've searched anywhere but did not really see how to store the value when it detects transitions.

I referred here, and the example code provided was able to capture the time. I adapted here, but I was able to capture (at most) the periods of 16 data, when I expect 24. I guess it's GPIOTE, not PPI.

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Fri, 22 Feb 2019 13:34:57 GMT

Hi,

[quote user="Winz"]hmm, I don't quite get it. (Is the variation expected?)[/quote]

There will be some variation between the input signal and output signal, as the input signal is not synchronized to the 16 MHz peripheral clock, but the output signal is.

[quote user="Winz"][/quote]

Are you saying that I let GPIOTE to handle this accidentally? But I remember that GPIOTE is not fast enough to handle it. Therefore, I do not think it is GPIOTE.

In my case, one pulse (one high and one low) 1.24 us (~ 1240 ns). Is that what you mean?

I did not get this. I am sorry, but am still unable to get a proper understanding of the previous question, context and test setup. I suggest you create a new question starting with absolutely all the information you have in a single post, making it stand alone and not referring to this thread.

[quote user="Winz"]I also read another question that (I think) is achieving the similar thing. If I am asking PPI to transfer the data to a timer, will I need to make 2 timers that does:
1. one records high (HT) and one waits for low (LT)
2. once a transition to low is sensed, PPI calls LT. LT stops and captures HT's duration and save it
3. once a transition to high is sensed, PPI calls HT. HT stops and captures LT's duration and save it[/quote]

Yes, your points about what you want to achieve are sensible. You need to calculate the pulse durations by hooking up the GPIOTE input to a timer so that you start the timer on one event and capture it on another (or capture bot start and stop in different CC registers, depending on what suits you best).

RE: Reading WS2812b leftover data through I2S

Winz — Fri, 22 Feb 2019 12:10:27 GMT

hmm, I don't quite get it. (Is the variation expected?)

Are you saying that I let GPIOTE to handle this accidentally? But I remember that GPIOTE is not fast enough to handle it. Therefore, I do not think it is GPIOTE.

In my case, one pulse (one high and one low) 1.24 us (~ 1240 ns). Is that what you mean?

I also read another question that (I think) is achieving the similar thing. If I am asking PPI to transfer the data to a timer, will I need to make 2 timers that does:
1. one records high (HT) and one waits for low (LT)
2. once a transition to low is sensed, PPI calls LT. LT stops and captures HT's duration and save it
3. once a transition to high is sensed, PPI calls HT. HT stops and captures LT's duration and save it

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Fri, 22 Feb 2019 09:59:33 GMT

I see. If these are worst case numbers, then that is not unexpected. The 16 MHz peripheral clock means that you will have some variation on the GPIOTE sampling of the input signal. If you are looking at a pulse with two tranzitions, that means up to two 16 MHz periods, 62.5 ns * 2 = 125 ns.

RE: Reading WS2812b leftover data through I2S

Winz — Fri, 22 Feb 2019 09:34:16 GMT

Yes. PPI works. Otherwise, I am experiencing some inaccuracy. According to my 100 MHz Logic Analyzer, the HIGH signal was sent, from the end of a WS2812 or from nRF52DK's Pin 11, for +350 ns.

Otherwise, after being captured by the same nRF52DK's Pin 13, and being copied (by triggering) to Pin 17, the HIGH signal was sent only for +240 ns.

The same thing happened on LOW signal: sent: +900 ns, copied: +1.01 us.

I think a table will describe it better:

Something	Type	Acutal Duration	Copied Duration
Test 1	HIGH	350 ns	240 ns
Test 2	HIGH	340 ns	230 ns
Test 3	LOW	890 ns	1000 ns (1us)
Test 4	LOW	270 ns	130 ns
Test 5	HIGH	960 ns	980 ns
Test 6	LOW	900 ns	1.01 us
Test 7	HIGH	350 ns	240 ns
Test 8	LOW	890 ns	1000 ns (1us)

I hope this thing is visible

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Fri, 22 Feb 2019 08:42:41 GMT

OK, so we agree that PPI works as expected. Then we can move on. What is actually the problem now? I have lost track of this thread...

RE: Reading WS2812b leftover data through I2S

Winz — Fri, 22 Feb 2019 08:36:14 GMT

Oh, my bad.

I tried shorting pin 11 and pin 13 (which are the pin used to drive the LED and the pin used to receive leftover data). I am able to see that the PPI was working. Otherwise, still: the same delay. devzone.nordicsemi.com/.../Cap8_2D00_no-led.zip *Updated file*

The output of PPI was inverted. Probably since I did not set it somewhere. But I don't think it's a problem now

*edit*: This version is not inverted anymore. I've fixed it.

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Fri, 22 Feb 2019 08:11:45 GMT

Hi,

I do not have a WS2812B to test with. My point was that we need to skip that to look at the PPI behaviour and only use the DK. Then I think you will find that PPI works as expected.

RE: Reading WS2812b leftover data through I2S

Winz — Fri, 22 Feb 2019 05:53:51 GMT

Okay, here is the full source code: devzone.nordicsemi.com/.../pin_5F00_change_5F00_int.zip

Note on the code:

1. I use UART for some communication and controls. I use PuTTY, but I believe other apps will work. The configuration is set like other examples:
- Speed: 115200
- Data bits: 8
- Stop bits: 1
- Parity: None
- Flow control: XON / XOFF
Commands available through serials:
- Press the number "1", "2", "3" (normal keys and keypad) and followed by [ENTER] or [SPACE] to send data to turn on the LED to some color. 1 = sapphire? 2 = lime? 3 = magenta?
- "4" will call the count_get() function. This function is connected to a TIMER. I'd like to use this TIMER to capture the duration. (Spoiler: I'll have some questions about this later).

2. The definition "MAX_LED" defines the number of LEDs connected. I connected 1 and would like to have 1 extra data for the analysis, so I wrote 2. If you got a strip of N LEDs, please change it to N+L to receive L data on the output of last LED bit.

And here's the latest plot I captured, when I was typing this: devzone.nordicsemi.com/.../Cap7.zip

No extra external hardware needed. Only a logic converter and the WS2812B. I am currently using only 1 DK

(I hope I did not miss any other description)

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Thu, 21 Feb 2019 08:21:59 GMT

Please ignore my last comment about the question (it was referring to a old question, my bad).

RE: Reading WS2812b leftover data through I2S

Winz — Thu, 21 Feb 2019 08:10:43 GMT

Sorry, which question?

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Thu, 21 Feb 2019 08:09:23 GMT

I did not understand this question.

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Thu, 21 Feb 2019 08:08:05 GMT

I am still having problems here. None of the signals relationship match what I would expect with the code snippet, though I have had to guess which of the three signals in the plot match the two signals in your code (PIN_IN and PIN_OUT). Can you upload the full source code use in this test, full plot, and full description in a single post so that all is of are from the same test and I know they make sense together? Also, if you can make the example code run on a DK without any external HW that would be great, as that would allow me to test on my side as well.

RE: Reading WS2812b leftover data through I2S

Winz — Wed, 20 Feb 2019 07:29:37 GMT

Okay,

Pin 13 has the signal that controls Pin 17 through PPI.

Here's the plot:

It may be observed better by opening this capture file inside this archive: devzone.nordicsemi.com/.../Cap6.zip with its app, DSView.

I believe that to set this up, we'll need to enable the event through setting it as a GPIOTE object. therefore,

// Init the GPIOTE
static void gpio_init(void) {
	ret_code_t err_code;

	err_code = nrf_drv_gpiote_init();
	APP_ERROR_CHECK(err_code);

	nrf_drv_gpiote_out_config_t out_config = GPIOTE_CONFIG_OUT_TASK_TOGGLE(false);

	err_code = nrf_drv_gpiote_out_init(PIN_OUT, &out_config);
	APP_ERROR_CHECK(err_code);

	nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_TOGGLE(true);
	//nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_HITOLO(true);
	in_config.pull = NRF_GPIO_PIN_PULLUP;
	
	err_code = nrf_drv_gpiote_in_init(PIN_IN, &in_config, in_pin_handler);
	//err_code = nrf_drv_gpiote_in_init(PIN_IN, &in_config, null_handler);
    APP_ERROR_CHECK(err_code);

    nrf_drv_gpiote_in_event_enable(PIN_IN, true);
	nrf_drv_gpiote_out_task_enable(PIN_OUT);
}

// Init PPI
static nrf_ppi_channel_t m_ppi_channel1;
static void ppi_init(void) {
    uint32_t err_code = NRF_SUCCESS;
	err_code = nrf_drv_ppi_init();
	APP_ERROR_CHECK(err_code);
    // Configure 1st available PPI channel to stop TIMER0 counter on TIMER1 COMPARE[0] match,
    // which is every even number of seconds.
	
    err_code = nrf_drv_ppi_channel_alloc(&m_ppi_channel1);
    APP_ERROR_CHECK(err_code);
	//ppi_enable_channel(FC_PPI_CH, &NRF_GPIOTE->EVENTS_IN[FC_GPIOTE_CH], &FC_TIMER->TASKS_COUNT);
    err_code = nrf_drv_ppi_channel_assign(m_ppi_channel1, \
										  nrf_drv_gpiote_in_event_addr_get(PIN_IN), \
										  nrf_drv_gpiote_out_task_addr_get(PIN_OUT));
										  
	//err_code = nrf_drv_ppi_channel_assign(m_ppi_channel1, \
										  nrf_drv_gpiote_in_event_addr_get(PIN_IN), \
										  (uint32_t)&(NRF_TIMER1->TASKS_COUNT));
    APP_ERROR_CHECK(err_code);

    // Enable both configured PPI channels
    err_code = nrf_drv_ppi_channel_enable(m_ppi_channel1);
    APP_ERROR_CHECK(err_code);
}

and then called them on main:

int main() {
    gpio_init();
    ppi_init();
}

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Tue, 19 Feb 2019 11:49:57 GMT

Perfect. Now I guess we just need to look at two pins to see if there is any unexpected delay in PPI. Which input pin has the signal that controls which output pin via PPI? Can you upload a plot that shows those two signals and the code snippet that produces it? (Having all information in the same post would be beneficial, so that we know what there has not been any relevant changes in between possibly making the information inconsistent.)

RE: Reading WS2812b leftover data through I2S

Winz — Tue, 19 Feb 2019 07:48:08 GMT

Oh, okay,

here is my current setup. hope it's more visible now

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Mon, 18 Feb 2019 11:50:39 GMT

Hi,

Sorry about that. It was supposed to link back to one older post in this thread, but it is not important. The point is that I am 99% certain that you have hooked up something in a different way than what it seems, as PPI cannot behave as you describe. However, I am not able to understand how it is hooked up, as I do not get it to match. Perhaps you can try to do the same think using only a single DK (with external wires connecting different GPIO pins)? Then if you can reproduce in that setting, perhaps you can upload here so I can test on my side as well?

RE: Reading WS2812b leftover data through I2S

Winz — Mon, 18 Feb 2019 07:12:24 GMT

Umm sorry, the link did not lead me anywhere..

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Thu, 14 Feb 2019 09:47:40 GMT

I have literally never heard of any problems similar to what you suggest, so we need to look at how you have hooked up the signals and what you are doing. Unfortunately, it is still unclear to me what exactly I am looking at. Can you explain in full detail what each signals are (the description in this post might make sense to you who knows this already, but it does not tell me enough to fully understand the test setup). How are the connected in HW and how are they handled internally in the nRF. Please note that the more signals to look at the more difficult to get an overview, so a simple plot showing just the signals you mean is related with a detailed description would be useful here.

RE: Reading WS2812b leftover data through I2S

Winz — Thu, 14 Feb 2019 08:53:12 GMT

[quote userid="7377" url="~/f/nordic-q-a/41966/reading-ws2812b-leftover-data-through-i2s/171023"]Generally, PPI behaves as I explained, and that is deterministic. Of course, there can be some jitter depending on the input signal relative to the internal 16 MHz peripheral clock, but that is all. Any other noise must be caused by something else.[/quote]

I agree with this. Otherwise, I believe PPI should not behave like what I experience, right?

RE: Reading WS2812b leftover data through I2S

Winz — Thu, 14 Feb 2019 08:51:49 GMT

Full capture from above

RE: Reading WS2812b leftover data through I2S

Winz — Thu, 14 Feb 2019 08:49:54 GMT

Okay, Here's the improved capture. The 4 lines above are the decoded version of the 4 lines below. The color on the left represents their connection (brown with brown, purple with purple).

Please note on the lower right part, below Cursor Distance. Those are the time sampled.

1-2 belongs to the original data, LED Out

3-4 belongs to the Self PPI out

5-6 belongs to the Other PPI Out

RE: Reading WS2812b leftover data through I2S

Einar Thorsrud — Thu, 14 Feb 2019 07:51:23 GMT

Perfect. But now I am having trouble understand in what I am looking at. Can you explain in detail which signal in this plot is supposed to follow which, how they are connected etc.? It is difficult to see the timing etc. from the plot.

Generally, PPI behaves as I explained, and that is deterministic. Of course, there can be some jitter depending on the input signal relative to the internal 16 MHz peripheral clock, but that is all. Any other noise must be caused by something else.

RE: Reading WS2812b leftover data through I2S

Winz — Wed, 13 Feb 2019 12:05:56 GMT

Alright, I found one which is able to do 100 MHz. Otherwise, I do not want to believe this.

Here's the capture:

The order is the same with the previous logic analyzer capture.