search

fearedspark / RGB_LED_Strip_Controller

Firmware for a RGB LED Strip Controller, to control NeoPixel or DotStar LED strips with a STM32F0 microcontroller
The Unlicense
3 stars 1 forks source link

Getting started #1

Open johnny68 opened 6 years ago

johnny68 commented 6 years ago

Hi, I am a computer programmer, wanted a decent RGB Driver for my mini project. Since, I am not at all experienced in this field, can you help me in creating this ? I understood the circuit diagram, but how do i upload the files to the board ? Thanks in Advance!

fearedspark commented 6 years ago

Hi, I can help you get started with it, but few points I need to address first:

johnny68 commented 6 years ago

So, I guess I would need to do the following

  1. Search for a shop which could make me the board itself or find the proper accessories.
  2. I will have to find the debugger
  3. I have to search and learn about the DotStar

I will start right now, would you give me a slight idea where i could find the debugger?

fearedspark commented 5 years ago

Ok, so it's been a while since I worked on that project, but it is time for me to get back to it. First, I'm sorry it took so long to reply, but this thread will be useful for other people as well.

For PCB manufacture, it is usually less expensive and less trouble nowadays to just order it form a place such as OSHpark or JLCPCB. If you decide to do it yourself anyway, I would recommend to check a bunch of videos so you know exactly what is involved, especially for double sided PCB.

For the assembly now, I created a Octopart BOM to make it easier to get the required parts. I would recommend getting a stencil from OSHstencils and use a soldering paste and a reflow oven, but manually soldering components should also be possible, but difficult (there are some tiny components).

For programming, you will need a JTAG probe that is compatible with this chip. More specifically, only the SWD link is exposed on J3. The ST-LINK series of programmers can be used (they have also cheap clones).

If you want to recompile the code, unfortunately it is using Keil from uVision (as often in embedded cortex code), which is a Windows only tool. You can download a free evaluation version from their website that is limited to 32k of code, which is more than enough in this case. The source can be ported to use ARM GCC, but I don't plan to do that yet.

fearedspark commented 5 years ago

The difference between NeoPixel and DotStar is the way the data is sent to the LEDs.

For the NeoPixel, the data needs to be perfectly timed. A 0 is coded as 0.3us of high and 0.9us of low, while a 1 is coded as 0.6us of high and 0.6us of low, therefore the bitrate is around 833.333kbit/s. A low level of more than 80us ends the packet. Each LED takes 24 bits in the order of G[7:0]R[7:0]B[7:0].

For the DotStar, the clock is sent alongside the data, allowing for greater flexibility. The bitrate can be chosen depending on the capabilities of the MCU, and potentially be much faster than NeoPixel. Each packet starts with 32 bits set to 0, followed by 32 bits of data per LED, and terminated by 32 bits set to 1. The LED data starts with 3 bits set to 1, then 5 bits controls the global brightness. The remaining 24 is the RGB data in the format G[7:0]R[7:0]B[7:0].

One reason to go for the DotStar is mainly speed. If you drive a long and dense LED strip, such as a 144 LED/meter with 5 meters totaling 720, you might see a difference in response time. The NeoPixel would only be able to refresh the LEDs at 48Hz, while the DotStar with a bitrate of 12Mbit/s would refresh beyond 500Hz. However, this difference is not really important for this project since the refresh rate doesn't have to be that fast (48Hz is pretty good already).

Another reason for using the DotStar as a hobbyist is that they are easier to control. Most microcontrollers include a SPI peripheral that is directly compatible with the DotStar protocol, and therefore makes the implementation really easy rather than bit banging the NeoPixel protocol.