- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Labels:
-
BLE
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is what the designer of Fun With LEDS says
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
But all I want to do is send one 24-bit value to one neopixel. Nothing fancy. Surely there has to be a way.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.