[Kudly] Wifi, SD card & hug sensors


Since my previous post, I implemented a functionality that saves a web page on SD card. This will able Kudly to dowload songs or other files from server. In order to achieve that, I used Wiconnect API on our AMW006 wifi module.

When I had time, I added hug sensors. In fact, Kudly will have flex and force sensors to interact with the child. They are connected on ADCs on stm32 to take pressure values.

Now I’m working on http post !



Hello !

Currently my main issue is implementing websockets for audio stream. With Julien we managed to understand the websocket protocol (https://tools.ietf.org/html/rfc6455) and I managed to connect to Julien’s server with a simple implementation of the protocol. At first, we wanted to give away the mask, but it is actually mandatory for sending data. For the moment, the mask is simply 0x00000000 which makes sending data more simple !

After the request the web server echoes what we sent, and we can then receive it and print it on the serial port.

The next step is to implement in & out mailboxes for the codec in order for it to stream audio data to the server. As the codec audio in and out buffers are both 16 bytes long, every request will be the same size.

[Kudly]Camera and websockets


I augmented once again the quality of my image. I used the link given by Eric and I changed all my registers. I am using double buffering and I had some problems with my images. It seems that I am not writting fast enougth on the sd card and so the dma overwrite what was on the memory before. So, I have to take a buffer big enough (currently 50kb in my case) to be able to obtain a correct image.

I am working on the server too. I did a simple POST echo handler and a websocket handler to echo the messages. We are trying to adapt it on our wifi card (AW006). The post was easy, we gives the arguments in the url. For the websockets, it was a bit more difficult. It seems that it is not directly supported. If we begin a websocket connection thanks to the http_get method, we get a 101 response (which is the response for websockets) and next, it is impossible to write in the stream.

So we are working on a tcp connection and we are writting our own packets. After reading the websocket RFC, we understood how to encode/decode packets. We tried with basic example and it seems to work 😉

Here is a french frie for the short post 🙂

See you,



[Kudly]High quality


I have just taken a better quality photo. Here is a family photo :


See you 🙂


[Kudly] Cheese V2


Yesterday, I finally got an image without any problem 😉 I will explain you what I did to use the STM32F4xx with Chibios, DCMI and OV2640.

First, DCMI is not supported by Chibios but someone wrote a driver that works a bit. I adapted it to make it work. You can find it here : https://github.com/EwanColdicott/ChibiOS . There was some problems. First, there is written DCMI_CR_CRE instead of DCMI_CR_CAPTURE in the dcmi_lld.h file. Without changing that I obtained strange results. Next, in dcmi_lld.c, in the receive function, the dma  mode is define again whereas it was also defined in the init function. However, the interrupts flags are forgotten. So, I just used the former value.

The VSYNC interrupt is also activated by default and it causes problems. The dcmi interrupt is called multiple time and in One Shot mode, this interrupt is supposed to be used only once. Else, the dcmi driver thinks it is in continuous mode. So, I changed the line of the interrupt :

dcmip->dcmi->IER |= STM32_DCMI_IER_FRAME_IE;

To communicate with the camera, a sccb interface is needed. I wrote my own driver and Eric made it better. You can find it on this post : http://rose.eu.org/2015/04/09/heros-faster-camera-configuration . It looks like I2C.

Now, the configuration of the camera. Open your grimoire page 404 because we are going to do dark magic. It the datasheet, all the registers are not defined. So, I found configuration on the internet. Here is my main inspiration source : http://tech.munts.com/MCU/Frameworks/ARM/stm32f4/libs/STM32F4xx_DSP_StdPeriph_Lib_V1.1.0/Project/STM32F4xx_StdPeriph_Examples/DCMI/DCMI_CameraExample/dcmi_ov2640.c

. I initialized my registers with those configurations and it works. At the beginning, I was not able to obtain a pixel clock. It was to be activated in a hidden register…

I modified the clock speed register because it was too long to take a picture (I change a prescaler). After changing some parameters like the clock polarity (samples on rising edge), the camera finally worked.

Cheese !




[Kudly] Kudly is able to hear !

After Antoine post (Kudly is able to speak), we manage to encode data from the microphone. We take a bad microphone, but now Alexis give us a electret microphone and it works !
We take the data from the micro, the codec encode the sound in OGG Vorbis, and we stock it on the SD card. For now there is a lot of noise, but I think the settings can be optimized.

Dimitri, happy 🙂

Kudly is able to speak !

Hello everybody !


I have some big news today, our codec is working and I’m able to display a sound on our card. I had some problems with buffer sizes and ogg vorbis format, but now my function can read a song in ogg format from our SDcard and display it on our jack. The recording function is also about to work,  we can obtain data from the microphone and save it in a file on our SDcard, but when we display it, we only hear some noises. So we didn’t finish all the functions of our codec but the end is imminent ! Good night 😀



The camera is finally working ! After (a lot of) black magic, I finally found a way to output an image in jpeg. In fact, the registers are not all documented so I compared codes for the OV2640 to find a register configuration that works. Here is the result :

kudlycamera imagecamera

The color are not really good but I hope I will be able to configure them 🙂

See you,



[Kudly] Wifi & integration


Today, I finalized to implement hhtp request and parsing of xml frame to light LEDs. Now, we can regularly send requests to our server and execute actions written in xml in a web site.

For integration with others features, we had some issues. In fact, our wifi module communicates with stm32 in UART (we are using it) but also in SPI. The problem was the wifi module did a factory reset every time that we flashed the board. On the SPI bus, there is also SD Card module. By default, on wifi module SPI MISO pin is assigned by factory reset pin. When we connected the SD Card module this pin was set and wifi module did a factory reset during the stm32 reset time … To fix it, we configured this pin in input for wifi module.


[Kudly] Wifi & leds

Hello !

This weekend, I linked the leds with Chibios Shell. We can now set colors to leds using shell commands.

With Damien, we are going on with the wifi. Now we can make a request to the server to get a XML file that sets the led colors. We are going focus on sending a stream now, which may be trickier than simply make http requests with the AMW006 API.

We are probably going to set up a websocket between our board and the herokuapp server in order to receive the stream on the server.