I wanted to get the development env rolling on my Ubuntu 14.04The manual suggests using 32 bit RedHat Enterprise Server 6 x86 32bit version, but you know no pain no gain.

The documentation and the overall quality of the support is something what you expect from a typical chinese company. You got an FTP access and figure out what you need.

So let's get a gcc to compile a hello world. The official toolchain is based on a 32 bit glibc-oabi-toolchain-arm-generic compiler.

To get this tool working you will need a 32 bit build of the mpfr-2.4.2 (the manual lists it as reqirement too -- Because this toolchain uses a high grade version of GCC toolchain, --).You can grab it from here:http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2.tar.bz2

Some things are changed around the gmp so replace all occurrences of __gmp_const with a simple const. (Do it with sed or whatever you like). ./configure --prefix=/usr "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"To compile it to 32 bit you will need to set the proper cflags. ./configure --prefix=/usr "CFLAGS=-m32" "CXXFLAGS=-m32" "LDFLAGS=-m32"

After installing it the cross compiler will claim about the missing libgmp.so.3.

Install the 32 bit version of the libgmp10 lib with:sudo apt-get install libgmp10:i386

I have been lucky to "legally" take apart some Cisco conference phones to PERMANENTLY remove the unused and unknown DECT functionality because if the locale is set to wrong country in the device it might cause some interfence with the UMTS frequencies which is illegal in my country and not tolerated well by the goverment agencies...

The DECT module is manufactured by the Dialog semi can be seen on the left. (SC14441) The main SoC, flash, RAM should live under the shield, but I have not delved more deeper because we wanted to keep the warranty (there are no stamped screws to provide evidence to the device tampering).

There are a plenty of unpopulated debug headers on the board (I think mostly JTAG).

The board has only oneintresting text on the silkscreen:Beignet Base 1000706-00 revK

I have started to play with ESP8266, and remembered to an IPQ500 S55 camera module got from a friend a few years ago. I have started to dream about a 6USD Wifi IP camera, but my dreams shortly fallen to ashes.

The code assumes that you need to pull the RTS and CTS pins by hand to low.

Ah yeah... I used to be lazy, so after some patching the code was able to drive these two pins with my CP2101 based UART converter's RTS and DTR pins. But the code did not worked (nothing came at the serial port after the camera was activated). Let's check with logic analyzer! The camera's baud was not exactly 19200 but ~19100 which gives 0.6% error. The cheapy UART converter have not tolerated that! Lets hook to the good old FTDI! It works. Good.

I was able to take picture with the python code. Conclusions:Reopening a serialport in python will clear the RTS status, but changing baud rate on the fly does not have the same side effect.

The camera takes ~33K JPGs which is transferred ~3 seconds with the 115200. That would be poor for the video stream, so I thought that I will figure out how can the camera's baud rate increased. 921600 would fit well. But unfortunatelly the camera's protocoll is not documented and according to the other people reverse engineering results the camera does not have continous recording functionality. So sad.

I have not given up the camera project I will look around for cellphone camera modules with SPI port with JPG encoder inside.