WS2812B Neopixel PRoC

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

I'm asking in the PRoC forum as I culdn't get a definite answer on the PSoC forum.  I am trying to run on WS2812B using a PRoC BLE.  I've been successful with the FunWithLEDs library on the PSoC, but I can't use that component on the PRoC.  I've used a bit of bit banging, but it won't give me consistent latching of the color, unless I'm running in debug and break after sending out the last byte.  I've included some code.

0 Likes
1 Solution
Anonymous
Not applicable

You would have multiple possibilities for implementation:

   

1. Knowing your clock frequency, you might be able to have a fixed instruction list in ASM that would run the bit sequence you desire for each 24-bit number you want to write, but it would be pretty difficult like you say. Setting the clock to 48-MHz will give 20.833 ns per instruction, which with a tolerance of +/- 150 ns on the datasheet, you would have a tolerance of about 6 or 7 assembly instructions, which should be plenty if you are doing a fixed assembly routine for each number.

   

Something along the lines of:

   

void SendNumber(void) {

   

//send a zero
    CyPins_SetPin(LED_0);
    CyDelayCycles(16);//16 cycles is about .35 us at 48 MHz
    CyPins_ClearPin(LED_0);
    //send a one
    CyPins_SetPin(LED_0);
    CyDelayCycles(43);//43.2 cycles is .9 us at 48 MHz
    CyPins_ClearPin(LED_0);
    //..... repeat sequence for multiple bits

   

}

   

 //If the bits do not have to be consecutive as far as timing, then you only need a routine for bit 0 and bit 1

   

2. Since you would have 300 ns of time to finish each bit, you could theoretically use ISRs depending on how well you could implement 1 or 2 ISRs, whether you could switch the ISR timeout each time it is called, how many numbers you have to manipulate in assembly for each call, how long it takes the CPU to assert the ISR, etc.

   

3. You could use the TCPWM hardware to do the timing with a single PWM pulse, but it would only work if you have time to invert the PWM signal for each inverted bit (bit 1 versus bit 0) and can disable the PWM after 24 bits have been sent.

   

It all depends on how stringent your computing resources are on the chip, how much of the RGB functionality you want/need, and how much space you are willing to sacrifice for the RGB control.

View solution in original post

0 Likes
6 Replies
rola_264706
Level 8
Level 8
50 likes received 25 likes received 10 likes received

The fun with LEDS was designed to work with PSOC 4 and the device you have selected won't work and you need to have a device with more resources.

0 Likes
rola_264706
Level 8
Level 8
50 likes received 25 likes received 10 likes received

Here is what the designer of Fun With LEDS says

   

0 Likes
Anonymous
Not applicable

But all I want to do is send one 24-bit value to one neopixel.  Nothing fancy.  Surely there has to be a way.

0 Likes
Anonymous
Not applicable

It sounds like you want to control a pixel using the Proc BLE chip, but you most definitely won't be able to just copy/paste the FunwithLeds example to the new hardware and expect it to work.

   

What do you mean by "send a 24-bit value" to the neopixel? Is it sending it over serial, gpios or some sort of DAC?

0 Likes
Anonymous
Not applicable

Since the Neopixel has one input, I would need to send the color values, (3 bytes/24-bit) in one shot over a single GPIO pin, and the pulse widths bit 1 and bit 0 are timed differently and in a way that standard bit banging to the system clock wouldn't work.

0 Likes
Anonymous
Not applicable

You would have multiple possibilities for implementation:

   

1. Knowing your clock frequency, you might be able to have a fixed instruction list in ASM that would run the bit sequence you desire for each 24-bit number you want to write, but it would be pretty difficult like you say. Setting the clock to 48-MHz will give 20.833 ns per instruction, which with a tolerance of +/- 150 ns on the datasheet, you would have a tolerance of about 6 or 7 assembly instructions, which should be plenty if you are doing a fixed assembly routine for each number.

   

Something along the lines of:

   

void SendNumber(void) {

   

//send a zero
    CyPins_SetPin(LED_0);
    CyDelayCycles(16);//16 cycles is about .35 us at 48 MHz
    CyPins_ClearPin(LED_0);
    //send a one
    CyPins_SetPin(LED_0);
    CyDelayCycles(43);//43.2 cycles is .9 us at 48 MHz
    CyPins_ClearPin(LED_0);
    //..... repeat sequence for multiple bits

   

}

   

 //If the bits do not have to be consecutive as far as timing, then you only need a routine for bit 0 and bit 1

   

2. Since you would have 300 ns of time to finish each bit, you could theoretically use ISRs depending on how well you could implement 1 or 2 ISRs, whether you could switch the ISR timeout each time it is called, how many numbers you have to manipulate in assembly for each call, how long it takes the CPU to assert the ISR, etc.

   

3. You could use the TCPWM hardware to do the timing with a single PWM pulse, but it would only work if you have time to invert the PWM signal for each inverted bit (bit 1 versus bit 0) and can disable the PWM after 24 bits have been sent.

   

It all depends on how stringent your computing resources are on the chip, how much of the RGB functionality you want/need, and how much space you are willing to sacrifice for the RGB control.

0 Likes