Sine generator using stm32f407 internal DAC and PCM5102A

Intro

Welcome to another completely stupid project!

This time I’ll show you how to implement a sine generator using a dirt cheap stm32f407 board. It really doesn’t make any sense to just build a sine generator, especially that way and using an STM32 processor, but it’s fun and at some point later I’ll post a project with the making of a more useful DDS (direct digital synthesizer). As usual let’s see the components and their prices.

Components

STM32F407ZET6 / STM32407VET6 development board

You can find cheap development boards for both stm32f407vet6 and stm32f407zet6 micro-processors on e-bay for $11 and $15. The vet6 is a bit cheaper compared to zet6. Their only difference is the package and therefore the number of available GPIOs. In more detail the vet6 has 100 pins (LQFP100 package) and 82 GPIOs and the zet6 has 144 pins (LQFP144 package) and 114 GPIOS and both have 512KB flash and 192KB ram. If you think that the additional 32 GPIOs worth paying $4 more then go for it, or if you’re like me and hate dilemmas buy both and be happy. Therefore, search e-bay for stm32f407vet6 or stm32f407zet6 and buy the cheapest ones. This is how stm32f407vet6 looks like

 

For the record there is a difference in the layout between vet6 and zet6 boards. The vet6 has the SD card on the top right side and the usb connector on the top left side and the zet6 has these components mirrored. Also, this post is written in 2017 so if you read this in 2030 then expect to find those boards in a museum.

USB to UART module

Most of the time when you develop on micro-controller you need a debug uart port. This project is no different, therefore you’ll need this.

This^. Ebay. Cheap. $1.2.

J-Link

I’ve used J-Link to flash the board during development as the board has a jtag connector, but you may use an st-link or even a cheap usb programmer with an SWD interface. Use whatever you have that can flash this thing.

Passive components

You’re going to need a few passive components to implement a low-pass filter (LPF) for the internal stm32 DAC. Nothing fancy, just a resistor R=1300Ω and a capacitor C=5.9nF. More details about the LPF later. Also the cost for these is unknown, they are so cheap that probably cost around $0.something.

PCM5102A

Finally if you want to play around with a ‘real’ DAC then buy one of these cheap pcm5102a boards on e-bay for $7.

This board has everything you need to drive the pcm5102 DAC using the stm32’s I2S interface and also you get a bonus stereo RCA connector that you can connect to your speakers.

Good to have

Well, you’re going to build a sine generator, so it’s good to have an oscilloscope. Also you may need a breadboard or a prototype breadboard to implement the LPF.

Making the stupid project

Using the internal DACs

Ok, now that you have everything you need let’s see how you build a sine generator. First, I’ll show how you can use the stm32’s internal DACs, so grab the board and clone the following git repo.

https://bitbucket.org/dimtass/stm32f407_dds_dac

Depending on your OS (Windows or Linux) follow the instructions in the README. What you actually need is a bare metal arm compiler, cmake and then run the build script. After that you’ll find the binary file in build-stm32 folder. Flash this bin on the stm32 board and reset the board. If you feel adventurous spend some time to read the crap source code. Everything is done using double buffering DMAs and FIFO buffers for faster speed and because of that the sampling rate in dds_defs.h is set to 384KHz. Be aware that if you don’t use this specific board then your board might have a different xtal crystal, which means that you need to edit the HSE_VALUE in stm32f4xx.h

In the internal_dac.c file you’ll find the code for the two internal DACs and in dds.c the code for the sine generator. The sine generator code is quite interesting as it uses the phase accumulator concept, which is very clever and nice to know. The idea is that you have an accumulator that you increment with a phase that is analogous with the frequency of the desired sine output. Yeah, I know, bοring, but if you are interested in the concept have a look at those links (link, link, link, link).

Connect the USB to UART module to the USART1 the following way:
USB TX -> STM32 PA9
USB Rx -> STM32 PA10
USB GND -> STM32 GND

Also, connect your oscilloscope to PA4 to probe the DAC1 channel and PA5 to probe the DAC2 channel.

Now, use a terminal (I’m using Br@y’s Terminal) and open the COM port using 115200, 8 data bit, no parity, 1 stop bit and no handshake. Also make sure that the received CR bytes are handled as CR+LF (CR=LF option in Brays terminal). You can change the sine frequency with the following command:

FREQ=<channel>,<frequency>
where,
<channel> is 1: for DAC1, 2: for DAC2
<frequency> is the desired frequency in Hz

For example:
FREQ=1,5434.25
sets the DAC1 frequency to 5434.25 Hz
FREQ=2,18934.32
sets the DAC2 frequency to 18934.32 Hz

That way you can have two individual DAC channels with two different frequencies. Regarding the code implementation, there are several ways to implement this DAC functionality on the STM32. You can individually control each DAC using its data holding register or use the dual data holding register, use dual timers with dual DMAs or single timer dual DMAs or single timer with single DMA (in case of using the dual data holding register). I’ve choose to use single timer, dual DMA, single data holding register because it makes the output sine waveform simpler, but I would like to implement also the single timer, single DMA, dual data holding register because it may be even faster as fewer IRQs are triggered.

Edit:
Now you can git clone the single timer, single DMA, dual data holding register repo from here if you want to do any performance tests.

Next is the output of a single DAC channel in various frequencies, without using an LPF filter in the output.

The displayed frequencies are 0.1, 100, 1000, 10000, 20000, 48000 and 192000 Hz. As expected the quantization noise is high as no anti-aliasing filter is used in the output. The following images are after using a simple analog first order LPF anti-aliasing filter.

 

The difference is that now there’s much lower quantization noise in higher frequencies (e.g. 48KHz) but also the output amplitude is getting smaller after aprox. 20KHz as the filter cut-off frequency is 20750.32Hz (R=1300Ω, C=5.9nF). There’s no point to display the 192KHz output as the amplitude is almost zero.

Using an external DAC (PCM5102)

It’s nice having fun with the internal DACs on the STM32 but… let’s use real DAC that can handle 16, 24 and 32 bit stereo channel audio. These days you can find good DACs really cheap. Texas (TI) has some nice chips that are sold as PCB boards on e-bay. For this test I’m using a PCM5102 board. I’ve also got some cirrus logic cs4344 DACs I would like to play with, but unfortunately I haven’t managed to find a board for them, which means I have to build mine at some point. The only cs4344 boards you can find on ebay are some USB DACs, but they don’t fit the purpose and also they are using the old out-of-life PCM2702.

Anyway, what’s the main difference between the internal DAC and this PCM5102? Well, the first one is internal! That means that there everything is happen in the STM32, no external components, no protocol interfaces, nothing. This means increased speed but less performance as the internal DAC is a basic 12-bit DAC. On the other hand now, by using an external DAC you get better performance as the chip is dedicated and engineered for the purpose, but this also mean that you need an interface to drive the DAC. In this case the I2S interface is used and it’s set to 16/48 (16-bit & 48KHz). Well, 16/48 it’s more than enough for my old rusted ears and it’s fine for testing. Maybe at some point I can try if STM32 can go up to 32/192 which is the highest that the STM32’s I2S can get (the PCM5102 supports up to 32/384).

Notes:
The PCM5102 board has its own regulators; therefore, even though the VCC is rated at 3V3 (same as STM32F407) you’ll need an external power supply 5~9V, because if you apply 3V3 it won’t even start.

Download the source code from the following repo and read the README.md file how to build the binaries:
https://bitbucket.org/dimtass/stm32f407_dds_i2s_dma

Connect the board the following way:
PCM5102 BCK -> STM32 PC10
PCM5102 DATA -> STM32 PC12
PCM5102 LRCK -> STM32 PA15
PCM5102 GND -> STM32 GND
PCM5102 GND -> PSU GND
PCM5102 VCC -> PSU 5V
PCM5102 FMT jumber set to ‘LJ’ instead of ‘I2S’ (‘LJ’ stands for Left Justified)

The I2S on the STM32 has DMA, double buffering and FIFO enabled for better performance. In case you use a different board then you should refer to the stm32 reference manual to set the correct N and R values on the RCC_PLLI2SConfig() function in i2s_dma.c. Actually, I would advice you to do that always as the I2S rate is very sensitive to the XTAL frequency and therefore even small variations on the XTAL speed wil have an affect on the output I2S rate. For more info check the table 127 in 28.4.4 in the reference manual which are the ‘correct’ values, but I suggest that you use an oscilloscope to trim the N value as the on-board crystal sucks. Using the oscilloscope try to find the correct value that gives more precise frequencies for the LRCK (I2S clock). E.g. in my case to get 16/48 the table suggests to use PLLI2SN=192 (that’s N) and PLLI2SR=5 (that’s R), but by using these values the LRCK clock was quite off, so I had to set the PLLI2SN=200 to get the correct bitrate. The correct clock frequency/bitrate for a stereo 16/48 I2S audio is 2*16*Fs, where Fs=48KHz in this case, so bitrate=1536000Hz.

If you want to have a look at the code then you’ll find all the I2S code in the i2s.h and i2s_dma.c files and the phase accumulator algorithm for the sine in dds.h/dds.c. To change the output frequency for the L and R channel then use a terminal as before and use the following commands.

FREQ=<channel>,<frequency>
where,
<channel> is L: for Left, R: for Right audio channel
<frequency> is the desired frequency in Hz

For example:
FREQ=L,5434.25
sets the Left channel frequency to 5434.25 Hz
FREQ=R,18934.32
sets the Right channel frequency to 18934.32 Hz

So, like before you have two individual channels to play with. Next are some oscilloscope captions on various frequencies (0.1, 100, 1000, 20000 and 22000Hz).

You’ll see that the output anti-aliasing filtering is much better now, compared the example with the DACs. In this case is not possible to get frequencies higher than 22KHz.

Conclusion

That was another meaningless stupid project. I mean really, you can’t do anything useful with these stuff, but you can experiment and use pieces to implement other more useful projects like a DDS that can output different waveforms or even a synthesizer. It’s also quite rare to find code for the STM32 even in the internet that uses DMAs with double buffering and FIFOs for both DAC and I2S, so keep the code for reference.

Have fun!

Benchmarks with gcc, musl and clang and how can they affect the embedded development cost

Intro

Ok, I know that’s a long and pompous title, but it’s difficult to summarize the whole meaning of this post.

As you’ll find out on this blog I won’t only write about stupid projects, but I’ll write also posts about other things that I find interesting mainly on the embedded world.

When dealing with embedded Linux there are several things that need to be considered, because “embedded” usually refers to a vast ARM ecosystem that extends from the tiny cortex-M0 processor (ARMv6-M) to a cortex-A73 (ARMv8-A). Of course, you won’t see Linux on a cortex-M0 cpu but you may see it on a Cortex-M4.

There are two reasons for this post. The first one is to write some thoughts about when is preferred to use bare-metal, RTOS or Linux on embedded products. The second reason was this video, which leads to the question that after we’ve decided that we need to use Linux, then what options and tools do we have; and most importantly what happens with the code and binaries size? Well, in embedded you should care about size, because that can limit your options and also can affect your product cost, development time and budget.

Right now embedded is a hot topic and there a many things going on with the compilers, their optimizations and the system libraries. So what’s the deal with the compilers?

Compilers

On the embedded systems you can find many different compilers with fancy names, like ‘arm-none-eabi-‘, ‘arm-linux-gnueabi’, ‘gcc-arm-embedded’ and the list goes on. Assuming a specific architecture (e.g. ARM in this case), these compilers are all different but they all can be used to compile an application that doesn’t run on an OS. One of the main differences is that these compilers assume a different C library; therefore, ‘arm-none-eabi’ assumes no C library or newlib and the ‘arm-linux-gnueabi’ assumes the full blown glibc (or eglibc). So that means that usually if you cross-compile a bare metal source code for ARM (e.g. for an STM32 micro-controller) you should use ‘arm-none-eabi-‘ and when you cross-compile a Linux kernel or a Linux user space application you’ll use the ‘arm-linux-gnueabi’.

OS or RTOS?

This is another question that usually comes on the table when dealing with a new project. Usually, is pretty much clear if you need an OS or not, but the line between if you need Linux or another embedded RTOS (eRTOS) some times is blur. If you go with an eRTOS then you go with arm-none-eabi for the whole project, but if you go with Linux then you’ll need arm-none-linux-gnueabi.

The difference between eRTOS and Linux is huge. It’s much more complex to develop on an eRTOS compare to Linux, because in the eRTOS most of the times you’ll need to implement your own subsystems and underlying tasks that usually the Linux already provides. Also the Linux separated the kernel from the user space applications, but on a eRTOS the separation is not always achievable and you need to write in several different places in the eRTOS. On the other hand Linux takes care of all the low level mumbo jumbo and you only have to write your app using the kernel API. So what are the criteria that you decide which to choose? Well, that depends for many variables, like your existing code base, the development time, the platform tools, cost e.t.c. but now more than ever you need to consider also the size.

Size!

There’s no doubt that the size when using an embedded RTOS (eRTOS) will be much smaller but also comes with higher complexity; and some times is also difficult to chose the right eRTOS that will have the least problems, bugs and issues. In some cases where the cost of a small external RAM and eMMC/SD is not that high and the development comes with less complexity and faster development time, then you need to consider Linux. And this is what this post is all about.

Is it possible to shrink a Linux OS to a low cost embedded platform?

If the cost to use plenty of RAM and a big fast storage is not an issue, then Linux it’s a no brainer, but when there’s a cost restriction and at the same time there’s a budget to use a small ram and a cheap storage, then you must do a research if the current tools we have these days can deliver small enough user space code size.

How to shrink size?

The time this post is written there are a few tools that targeting to achieve small binary sizes. First, gcc already has some optimization flags that can be used to optimize speed and/or size. Also gcc provides a Link Time Optimization (LTO) tool (-flto flag in gcc), which also can reduce the compiled size. What LTO does, is that it gathers more details about the code during the compile time and then provides the linker with these details so the linker can use them to optimize further.

Apart from gcc there’s also the clang compiler which is designed to fully replace gcc. Therefore, when you build a source with clang then you don’t use gcc at all. Although clang is highly compatible with gcc, it doesn’t offer full compatibility, which means that you may not be able to compile all the existing code base.

In addition with the compilers, we also have the system libraries which also play significant role in the resulted binary size. GLib is the low level system library used by gcc and it’s huge! You would never consider the system library size when developing desktop applications, but for small embedded systems GLib is a behemoth. There are various light-weight replacement GLib libraries for the arm-none-linux-eabi, like the musl lib. You can see a comparison of few libraries here. Note, that there are also replacement glib libraries for the arm-none-eabi, like the nano-lib (–specs=nano.specs compiler option)., which does a great difference in code size, too.

So, to sum up, we have different optimization flags, compilers and system libraries. Now, we can proceed with the benchmarks by using all these different options and see what happens.

Benchmarks

I’ve prepared a benchmark repository in bitbucket that you can you use to do your own benchmarks here:

https://bitbucket.org/dimtass/gcc_musl_clang_benchmark

You can git clone the repo and then run the benchmark.sh script followed with the c file and any extra flags you want, like this:

./benchmark.sh oggenc.c -lm

By default the binaries are created in the output/ folder and when the test is finished they are deleted; therefore, if you want to keep the binaries to do some tests then run the benchmark like this:

KEEP=true ./benchmark.sh oggenc.c -lm

I’ve included these 4 source code files: test.c, bzip2.c, gcc.c, oggenc.c. The test.c is a simple code file I’ve made and the rest files I’ve found them here. Every file has different size and source code and by comparing these we can obtain an overview of how well each benchmark performs in real applications.

These are the details for the compilers and libraries on my Linux Mint 18 ‘Sarah’ 64-bit.

GCC version : gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
GLib version : (Ubuntu GLIBC 2.23-0ubuntu7) 2.23
clang version : clang version 3.8.0-2ubuntu4 (tags/RELEASE_380/final)
musl version : 1.1.16

And these are the results for each source file.

./benchmark.sh test.c
Testing file: test.c

gcc            :  8976
gcc -Os        :  8984
gcc -O3        :  8984
gcc -flto      :  8968
gcc -flto -Os  :  8920
gcc -flto -O3  :  8920
musl           :  7792
musl -Os       :  7792
musl -O3       :  7792
musl -flto     :  7784
musl -flto -Os :  7728
musl -flto -O3 :  7728
clang          :  7664
clang -Os      :  7800
clang -O3      :  7832
clang+musl     :  4792
clang+musl -Os :  4896
clang+musl -O3 :  4928

./benchmark.sh oggenc.c -lm
Testing file: oggenc.c -lm

gcc            :  2147072
gcc -Os        :  2028656
gcc -O3        :  2179880
gcc -flto      :  2140944
gcc -flto -Os  :  1974736
gcc -flto -O3  :  2067600
musl           :  2141096
musl -Os       :  2022552
musl -O3       :  2173776
musl -flto     :  2134952
musl -flto -Os :  1972976
musl -flto -O3 :  2069824
clang          :  2112544
clang -Os      :  2020600
clang -O3      :  2116544
clang+musl     :  2107952
clang+musl -Os :  2016264
clang+musl -O3 :  2110528

./benchmark.sh bzip2.c
Testing file: bzip2.c
gcc            :  138008
gcc -Os        :  79320
gcc -O3        :  115912
gcc -flto      :  130448
gcc -flto -Os  :  71456
gcc -flto -O3  :  107760
musl           :  136376
musl -Os       :  73512
musl -O3       :  114304
musl -flto     :  128840
musl -flto -Os :  69728
musl -flto -O3 :  106152
clang          :  129112
clang -Os      :  94568
clang -O3      :  113504
clang+musl     :  125840
clang+musl -Os :  90824
clang+musl -O3 :  109968

./benchmark.sh gcc.c
Testing file: gcc.c
gcc            :  6879424
gcc -Os        :  4263096
gcc -O3        :  6493624
gcc -flto      :  6772760
gcc -flto -Os  :  3886664
gcc -flto -O3  :  5889240
musl           :  failed
musl -Os       :  failed
musl -O3       :  failed
musl -flto     :  failed
musl -flto -Os :  failed
musl -flto -O3 :  failed
clang          :  7446328
clang -Os      :  4785560
clang -O3      :  6537192
clang+musl     :  failed
clang+musl -Os :  failed
clang+musl -O3 :  failed

Analyzing the results

Now that we have the results we need to analyze them and the best way to do that is to visualize the data in a way that’s easy to compare the results. For that reason I chose to plot the size for each file against the compiler and the lib it was used and the last plot is the sum of all the output file sizes, except the gcc.c which was failed to build with the musl lib. Click on each image to zoom in.

Lets take this step by step. If you see the source code of the test.c you’ll find out that it’s a very simple program that doesn’t do much. There the combination of clang+musl shines and the result code is half the size compared to gcc+glib and also it is much smaller compared to gcc+musl. This is a very good sign for clang. Also clang by itself managed to produce almost the same binary size with gcc+musl. When I’ve seen these results I was surprised and I thought that this groundbreaking news and actually it is, but… after running the benchmarks with the rest of the files my feelings were mixed.

oggenc.c benchmark shows that gcc+glib+LTO+Os and gcc+musl+LTO+O3 have the same performance and much smaller size compared to others benchmarks.

bzip2.c shows that gcc+glib+LTO+Os, gcc+musl+Os and gcc+musl+LTO+Os perform the same and better that the rest.

gcc.c failed on musl and the gcc+glib+flto+Os performed better than the others.

Finally, the most important result is by adding the sizes of all the resulted builds as this is closer to real-life application as your rootfs size will be the sum of all the programs. Of course, only 3 programs doesn’t really reflect to let’s say 100 or 1000 or 2000 programs that your rootfs may really have, but still it’s a good measure to get a rough view of what it might be. By seeing the sum of the sizes is obvious that gcc+glib+LTO+Os and gcc+musl+LTO+Os perform much better that the others and clang is far behind.

You can make your own conclusions with the result and even better try by your self.

Conclusion

From the things I’ve seen my opinion is that the LTO combined with the -Os does the most significant difference compared the other options. That means that the gcc compiler optimizations outperform clang and also it seems that musl doesn’t give much more compared to glib. Of course the last statement isn’t always true. Musl does make a huge difference on some programs (test.c) and it doesn’t make on others (oggenc and bzip), but also it failed to build gcc. I think musl looks promising though. On the other hand clang results were very mixed. On a simple application test.c it produces really small binary and outperforms all the other options but when the things get tough in more complex code, is worse that gcc.

So, let’s go back to the first question. Does it worth? Can these results help us to get a decision on the thin line between choosing an RTOS and a Linux OS for an embedded product? Well, don’t expect this answer from me. You are the one to decide what is right for you, but I’ll tell you what I would do.

Personally, I break the embedded projects needs in three categories like sequential execution, couple of parallel threads and real multi-thread.

  • If your project can be implemented with sequential execution procedures you don’t need RTOS or Linux, you go with bare metal.
  • If you project needs 1 or 2 threads, then that doesn’t mean that you need an RTOS. You can develop using finite states (FSM); but if for some reason you think that your FSM will be hard to maintain (e.g. a complex GUI with user inputs and peripherals) then go for an RTOS.
  • If you have a couple of threads and the cost must be kept low then go for RTOS.
  • If you have multiple threads and the budget allows you to add some RAM and a small storage go for Linux.
  • If your code base is on Linux, then of course, you go for Linux.

In any case is good to use optimizations. Nano-lib for bare-metal and compiler optimizations & alternative system libraries for the OS.

Now, if you decide to go with Linux and a limited budget then you’ll need all the performance gains the compiler and the alternative system libraries can offer. In that case you need to verify that all the core programs you need in your rootfs can be compiled with all the above optimizations and the result size is small enough to meet your specs on RAM and storage.

It’s encouraging to know that there’s an active development and effort to the correct path. Size matters and it can do the difference and introduce Linux in the low budget projects. Of course, Linux is not a panacea for every embedded project and it shouldn’t be, but it has it’s use and it can solve problems.

Also, many cheap linux-enabled SBCs are showing up these days. For example have a look at Omega2, which is a $5 SBC with Linux, 64MB memory, 16MB storage, USB, WiFi, I2C, SPI, i2S and 15 GPIOs. On the other side a cheap stm32f103c8t6 board (Cortex-M3) costs $2.5 and an stm32f407vet6 board costs $7. NXP ARM mcus are much more expensive as also Renesas, Cypress and others. Of course, the STM boards have more peripherals and still they have their use, but the future for the most mainstream products seems to be the ultra low cost Linux IOT ready boards and for that reason we need smaller size binaries and better performing compilers and tools.

For those that only develop only on small ARM mcus, don’t worry! There are many reasons that low embedded will be still on the market in the next years, no matter what happens. Especially on industries that have to do with health, human life, security, defense e.t.c. where everything needs to be absolutely deterministic. An RTOS or any other OS is non-deterministic and regardless the budget and the costs they can’t be used on these products as the regulations and approvals are very strict about this.

WiFi digital control DC power supply with web interface and USB

Intro

Welcome to my next stupid project!

Ok, this project  is really stupid and I’ll probably never going to use it for any of my next projects, but it was fun doing it nevertheless. I have a bunch of these adjustable LM2596 DC-DC boards in one of my “magic” component cabinets, that you can find quite cheap in ebay (~$1.5).

As you can see it’s composed of few components like an inductor, capacitors, resistors e.t.c. You apply a DC input voltage and then you get a step-down DC output on the other side. You can control the output voltage with a 10KΩ pot (the blue block device with the screw on top). That’s great. But… this means that every time you need to change the output voltage you need to turn the screw several times to get it. The good thing with that is that if you have a good multimeter you can get quite precise output voltages as the POT is analog. The bad thing is that you need to do manual labor every time you need to change the output voltage. But not anymore.

The idea was to simply change the analog POT with a digital one and then find a way to control it remotely. So, why not do that using a UART port, or even better a USB port. Oh, wait… Why not make it WiFi controlled and also have a web interface? And this how stupid projects are made. Do to that we’ll need the following components.

Components

Digi-pot

There are several digital pots on the ebay and they are cheap, but the trick here is to find a digi-pot that has enough wiper points (or steps). Why you need many steps? The ‘step’ for a digital pot defines it’s resolution, so for a 10KΩ pot with 100 steps (like the X9C103P) each step is 10ΚΩ/100=100Ω. That’s quite large when it’s used in voltage a divider like the pot on the LM2596 board. On the other hand by using a digi-pot like the MCP41010 that has 256 steps, the resolution gets much higher. You can find these microchip digi-pots on ebay for around $1.5 each.

The mcp41010 is controlled with an SPI interface, which means that you need a micro-controller. That’s cool, because this means that you can also use an ESP8566 wifi module and why not a USB interface if the controller comes with it.

Micro-controller

I like ARM processors. My favorite boards are those stm32f103c8t6 that you can find on ebay for $2. They are ultra-cheap, they have almost any interface that I need for my stupid projects and they also have a very nice API to program them. The stm32f103 has a USB port, more than the 2 uarts that are needed and an SPI interface to control the digi-pot.

This board is power either from the USB connector either from the 5V or 3.3V on-board pins. Never use both of them at the same time!

ESP8266

The ESP8266 shows up again on this stupid project as also on the first one. Copy-paste from the previous post follows: it’s easy to modify the source code with the SDK and also you can use any network capable device to interact with them. I’ll write a separate post about ESP8266 in the future and how you can write your own code for these modules. You can find them cheap in ebay and they cost around $2.50. There are a few types of this module that they have a different flash size (512KB, 1MB), but the only thing that you should care about now is that it needs to support 9600 baud rate and not only 115200, because I’m using a software serial library for the arduino that behaves much better on lower baud rates. Be aware that ESP8266 is a 3V3 only device. This is the module:

Output relay

In the output I’ve used a relay to turn on and off the output from the LM2596, you may not want to do that, but it’s nice to have it. There are many cheap variations of opto-couple relays in ebay that cost $1-$2 like this one

I prefer the high-level drive relays as the microprocessors usually after a reset they drive their pins to low, which is safe as the relay doesn’t get activated when the mcu is reset. You can connect the positive voltage output of the reference power supply to the COM and NC terminals. Also, make sure that the relay is rated for the DC output you’re going to use, so don’t use a 30V relay to output 40V. Finally, make sure that the relay is able to be activated with a 3V3 input trigger.

Step-down (AMS1117-3.3)

You’ll also need a step-down DC power supply module to power the components, like the AMS1117-3.3. There are some cheap pre-soldered modules with the AMS1117 on the ebay, I’ve found 5pcs for less that $1, which means $0.20 for each. They look like this

They are very convenient if you are using a breadboard or a double-sided prototype PCB, as they only have 3 pins and all the needed components are on the module. It also has a LED indicator that indicates that it’s powered.

Prototype breadboard

If you want to assembly the circuit without design a PCB, then you can buy on ebay one of these cheap prototype breadboards for less than $1.

 

The image is from a pack of various pcb sizes, you’ll just need one that fits everything you need to solder.

ST-Link

Finally, you need an ST-Link programmer to upload the firmware. Generally, I have the original ST-Link V2 and the Segger J-link programmers, but to be honest, most of the times I’m using one of these cheap st-link copies; which I find much more convenient to use on the limited workspace. Of course, I suggest you to buy the original ones, but if you also have a limited space then buy one of those from ebay.

Making the stupid project

I haven’t build a PCB for this project and it is only a proof of concept on my breadboard. These are the schematics of the circuit you need to build.

The stm32 is powered either from the USB port when it’s connected on the PC or from the AMS1117-3.3. Therefore, you need to be careful with that, so if you’re going to use a USB adapter or connect the stm32 to your PC then you need to remove the K1 jumper. If you’re not going to use the USB interface then place the jumper.

When you unsolder the blue resistor POT from the LM2596 PSU module, then you’ll have three empty holes on the PCB. The LM2596-POT1 and LM2596-POT2 terminals are connected to the PCB holes next to the OUT+ output. There are two main power inputs, the one is the VIN that is connected to the AMS1117-3.3 and provides power to the circuit and the other is the PSU V+ that comes from the external power supply you’re going to use for the LM2596. Therefore, the [LM2596-POT1/2] and [PSU V+ in/out] are connected to the LM2596 PSU. The USB_UART (P1) is not necessary to use and it’s just the debug UART port.

You can download the source files from my bitbucket project

https://bitbucket.org/dimtass/stm32f103_wifi_usb_psu

Read the README.md file as it has all the details you need, but still I’ll explain some things here. You don’t have to build the code to use it, but I suggest that you do as you need to change a few parameters in the source files. The pre-build binaries of the latest build are located in the firmware folder, therefore you can use the ST-Link utility on windows to flash the hex file or the st-flash utility on Linux to flash the bin file. To upload the firmware you just need to connect the USB cable on the stm32f103 board and run the flashing commands which are in the README.md file.

If you need to build the code then you’ll find the cmake files and scripts for both Windows and Linux. So, if you have a Windows OS, then you need to install cmake, make and a gcc toolchain for the ARM cortex-M3. Read this to see how you can do that.

After you’ve setup everything, all you need to do is run the build.cmd (on Windows) or build.sh (on Linux) to build the code. Cmake will create the binaries in the build-stm/src folder but also will create the .cproject and .project files in the build-stm folder. This means that you can import this project to your eclipse CDT IDE and edit the code in there.

One of the things you probably have to edit is the IP address definition (HTTP_IP_ADDRESS) in the src/http_server.h file. This is the address that your AP assigns to the ESP8266 module. That means that you need to configure your AP router to always assign the same IP to the MAC address of the ESP8266. Then you can re-build the code and flash the new binary on the stm32. It’s recommended to erase the stm32’s flash before you upload the firmware as the last 1K of the flash (address: 0x0800FC00) is used to store the configuration data, like the AP SSID, password and the pre-defined POT values.

The first time that the stm32 powers up after a firmware update, it will try to load the configuration data from the flash. If it doesn’t find a valid configuration then it creates a default configuration. In the default configuration the stm is not able to connect to any AP and the pre-defined POT values are all set to 127 (which means 5KΩ). You can use the USB or UART interface to update the configuration data for the AP SSID and password. To do that just connect the stm via a USB cable on your computer and open a terminal (I always prefer to use Bray’s terminal). Whatever terminal you use make sure that the LF char is handled as (CR & LF). Bray’s terminal has that option by checking the [CR=LF] checkbox in the settings area and the [+CR] next to the [-> Send] button.

If you have already red the README.md file in the project folder you’ll know which commands to use. As an example I’ll suppose that the AP SSID name is “Router” and the WPA2 password is “MyPassword”; of course, you need to change these with your own. To update the configuration send the following commands to the terminal.

SSID=Router
PASS=MyPassword
RECONNECT

The first command stores the SSID name, the second the password and the third one initiates a reconnection to the router. If the last one doesn’t work, just remove and re-apply the power on the stm. When the stm starts then the LED will start flashing every 250ms if the ESP is not connected and when it gets connected the it flash every 500ms. When it’s connected you can finally open you browser and connect to the web interface by writing its IP address on the address bar. This is what you’ll get

This is a very simple html page, so there are minimal javascript automations, which means that the web interface will not automatically restore the PSU state, so you don’t really know if it’s turned on/off and which pre-defined output is used. Therefore, have that in mind. On some browsers you may need to do a dummy click on a button first, so you can click the OFF button for 1-2 times. As you see the web interface is quite simple. In the first row there are the ‘Power & Trim’ buttons that you use to turn off or on the output relay and trim the output voltage by change the digi-pot value. The +/- buttons change the digi-pot step by 1 on every click and the –/++ buttons change the step by 5. You’ll need these buttons to trim the output and save the value on one of the pre-defined values.

Let’s say that it’s the first time you open the web interface after a new firmware update and a full flash erase, so there aren’t any configuration data. Also suppose that you’ve chosen that the pre-defined values will be (2V5), (3V3), (5V), (6V) and (12V) in the src/http_server.c file. Now you need to do the calibration procedure as all the pre-defined values are set by default to step 127 for the digi-pot (5KΩ). First connect the input power [ΙΝ+/ΙΝ-] to the LM2596 (e.g. 12V) and a multimeter in the output to measure the voltage, then click 1-2 times the OFF button, click the pre-defined value you need to set and click the ON button. On your multimeter you’ll see the output value that corresponds to the digi-pot’s step 127 (5KΩ). Now you need to change the output. To do that keep pressing the (–) button (or ++) until you get as close to the pre-defined value. Then use the (-/+) buttons to trim further and get the wanted output. Don’t expect the output to be very precise as the 256 steps for a 10K digi-pot is only 39Ω per step. When you get the nearest value to the wanted one then press the (Save) button and this value will be stored. Then press the next pre-defined button (3V3) and repeat the procedure until you set all the values and this is how the calibration is done. Don’t expect to get 12V in the output with a 12V input as there’s about a 0.7V drop on the LM2596.

The digi-pot is a linear resistor and not logarithmic like the pot you’ve replaced on the LM2596. This means that if you use a 12V PSU as a reference, you’ll get a better resolution under the 5V but over this voltage the resolution drops significantly.

If for some reason you change the input voltage on the LM2596 then you need to repeat the calibration procedure again. Also, it’s good to do that from time to time to be sure that it’s calibrated and always check the output with a multimeter before you connect a circuit. If you need another output voltage then just connect your multimeter in the output press the pre-defined voltage that’s closer to the wanted output and use the (+/-) button to get it.

Finally, you can do all these things by using the USB connection and the commands that are explained in the README.md file. You can also use the USB interface to set the exact digi-pot step value like this.

POT=127

You can set any value from 0 to 255.

This is a screenshot of how the web interface actually looks like in use.

You can edit the html file in the src/http_server.c source code file. You can right click on you browser and view the page source as it’s quite cryptic with the C formatting and then you can do any changes you like. Just don’t add too many things in there because the interface will take more time to load. You can change the CSS styles also to change the colors and then re-build the code and upload the firmware.

Summary

Well, this is a completely stupid project and is quite simple to build. All the needed components costs around $10. This the list of the components and their approximate price on ebay (you may find these even cheaper).

LM2596 PSU ~ $1.5
MCP41010 (10KΩ digi-pot) ~ $1.5
STM32F103C8T6 dev board ~ $2
ESP8266-05 module ~ $2.5
Optocouple relay board ~ $1.5
AMS1117-3.3 module ~ $0.20
double sided prototype breadboard ~ $1

This is an extremely bad photo of everything working on a breadboard.

Have fun!

Control RGB strip with WiFi (ESP8266) and arduino.

Intro

This is my first stupid project posted here. I wanted to put some color in my living room and these inexpensive RGB led strips that you can find in ebay are perfect for this. To control RGB strips is done easily today. You just need a small micro-controller and an RGB led driver. So, the only thing that remains is to find a way to do that remotely and also be able to control several RGB strips at the same time. But let’s have a look at the components that I’ve used.

Components

RGB strip(s)

You’ll need an RGB strip to control, of course. You can find a plethora of RGB strips in ebay, just search for ‘led strip 5050’ and you’ll get tens of thousands results. Just pick one for your needs, waterproof, low or high power e.t.c. Choose a 12V strip. You’ll also need a 12V power supply for that, so buy one that meets the power consumption of the strip. If you don’t know what’s the power consumption ask the seller and he’ll provide you with the correct one.

RGB led driver (P9813)

The RGB led strips are controlled with an RGB driver with the P9813, you can find them in ebay by searching for ‘RGB LED Strip Driver Module Shield’. This driver is quite nice and cheap (~$4.50) and supports chaining. You won’t need that now, but it’s a good to have option for other projects. This is how it looks like

ESP8266

Well, you’ll find out that I love using the ESP8266 modules, as it’s easy to modify the source code with the SDK and also you can use any network capable device to interact with them. I’ll write a separate post about ESP8266 in the future and how you can write your own code for these modules. You can find them cheap in ebay and they cost around $2.50. There are a few types of this module that they have a different flash size (512KB, 1MB), but the only thing that you should care about now is that it needs to support 9600 baud rate and not only 115200, because I’m using a software serial library for the arduino that behaves much better on lower baud rates. Be aware that ESP8266 is a 3V3 only device. This is the module

Arduino mini

For this project I’m using an Arduino mini to control the RGB driver and the ESP8266. You can use any arduino board that you may have, like UNO, as it’s easier to flash them without any need for a usb uart module. I’ve just use the mini because its small factor and also it’s 3V3, which helps a lot with the ESP8266 as you won’t need a level converter.

USB-uart module

To flash the arduino-mini you’ll need a USB uart module that has a DTR output. This is needed in order to reset the arduino to the bootloader mode and load the binary. You can find these cheap on ebay (~$1.50) and it looks like that

Raspberry-pi (or something similar)

In this project I wanted to use my smart-phone, tablet or desktop to control the RGB colors; therefore, a simple web interface was ideal for that purpose. The web interface is running on a banana-pi sbc in my case, but you can use a raspberry pi or any other board/computer that is able to run a php-enabled web server.

Other

You’ll also need a small pcb board to solder everything on it, then power supplies for each RGB strip and a power supply for each arduino. While building the project you can use a breadboard and some breadboard jumper cables to connect everything and test that it works. You can find prototype PCB board like these on ebay.

Prototype PCB boards

Making the stupid project

Although I haven’t build any PCB for this, the schematics are needed to connect the parts together. K1 is a jumper that is used to select the operation mode as the arduino firmware supports two modes, one for configuration and one for normal operation. The rest connections are self-explained.

After you done with connecting the parts, you need to connect the USB to uart adapter to arduino mini and apply a 3V3 power to the circuit. Then you need to download this git repo and build the code with arduino IDE or any other tool you prefer (I use sloeber).

https://bitbucket.org/dimtass/arduino_wifi_rgb

Build the code, upload the firmware to arduino and remove the power.

Then connect the RGB strip to the P9813 driver and apply 12V to the block connector (J1).

Make sure all connections are correct and place the short jumper to the K1 pin header that shorts D4 to the GND. This will put the firmware to configuration mode.

In the configuration mode, the ESP8266 is configured as an AP. You can connect to this AP with your mobile or laptop and configure the connection settings that ESP8266 needs in normal operation. In normal operation the firmware will try to connect to your wireless router with the SSID and password you provided during configuration mode. To configure these settings you need to send a few commands using a UDP client. You can either use hercules utility (or any windows/linux udp desktop client you like) or your mobile. I’ve used an android app which called UDP Sender/Receiver.

After you connect to the ESP8266 AP, you’ll get an IP in the subnet 192.168.4.xxx and the ESP8266 will have the IP 192.168.4.1. Now you need to send the UDP commands in the broadcast IP 192.168.4.255 and port 7700. Therefore, if your router’s SSID is “Sky” and the password is “12345678”, then to configure the SSID send to UDP port 7700 the following command:

SSID_NAME=Sky

and to configure the password send this command

SSID_PASS=12345678

Finally, remove the jumper to enable the normal mode and reset the power from the board or send this UDP command

RESET

This is an example if you use your smart-phone.

After the reset, the board will try to connect to the wifi router using the parameters you programmed in the configuration mode. At any time you can use the USB to uart module to retrieve the trace messages from the board (115200 baud-rate).

Now copy all the files from the ‘www/rgb’ folder to your web server. For this I’m using a banana-pi, which is also serves me as my network file server and hosts several other stupid things, like a web server for the home automation, my components database, e.t.c. At this point you need to make sure that ESP8266 is always assigned the same IP, otherwise everytime your router reboots, then it will get a different IP, which is very inconvenient as you need to change this every time in the web server configuration. So, in the functions.php file of the web interface change the $remote_ip with the IP address that of the ESP8266. You can see the IP either from the trace messages in the uart or from your router.

So, you’re ready to go. In my case the web app is in the following address (http://192.168.0.100); therefore, when I type this address in my smart-phone’s web browser I get the following web interface

This is a brief explanation of each button:
+: Dim up
-: Dim down
||>: Start/pause the random RGB colors
OFF: Power off strip (sends 0x00 to all colors)
R+/-: Increase/decrease red level
G+/-: Increase/decrease green level
B+/-: Increase/decrease blue level
QUICK: Increases the speed that the random colors are changing
SLOW: Decreases the speed that random colors are changing

The rest of the buttons are just 8 pre-defined colors. There’s a catch here. There isn’t any RGB strip that has completely calibrated colors, so if you think that you send something like HTML color values and you get the same color from the strip, then think again. You need to manually calibrate your strip. To do that, you have to open the ‘rgb_buttons.json’ file in the web app and change the values for the 8 pre-defined color buttons. These buttons are from ‘btn_5’ to ‘btn_12’.

Here is a brief explanation of this json file:
“name”: it’s the button’s name. Don’t change this.
“color”: this is the display color of the button on the web app
“function”: when it’s set to color it means that contains color data
“data”: these are the real RGB values that the P9813 driver will use and they have this format #RRGGBB, which is a HEX byte for each color.
“text”: the text displayed on the button

This is a sample video of this stupid project on action.

 

Have fun!

Intro

Hi, my name is Dimitris and this is my blog with some stupid embedded projects I’m doing in my free time. Having this blog helps me to organize and keep track of my projects and source codes. I hope that you may find some them useful.

I’m an electronic engineer working currently on the professional audio industry, but my interests expand on other domains, like home automation. Therefore, here you’ll find various stupid projects that don’t really have anything to do with audio.