floppydiskettes.org

What does it means?

GCC Optimization: [-O3 is winner]

By default, Libjpeg uses the more accurate integer method (JDCT_ISLOW) at the DCT step of decoding a jpeg file. Looking at the blue bars, we can see a clear trend of the performance increase from -O2 to -Os to -O3, though marginally. It will probably matter if Libjpeg is continuously decoding jpeg streams.

This trend is, however, broken when Libjpeg is using JDCT_IFAST and JDCT_FLOAT methods, which leads to the next topic of discussion.

DCT Method: [JDCT_IFAST is winner]

Using the less accurate integer method (JDCT_IFAST) clearly produces the fastest decoding speed as seen with the green bars. The JDCT_IFAST method leads by the widest margin vesus the other two methods.

The JDCT_FLOAT method does not seem to produce very fast decoding speed except when Libjpeg is compiled with -O2 flag. Using the hardware VFP floating-point coprocessor with -O2 flag result in decoding speed that matches the improvement from the GCC -O3 flag.

The -Os Flag: [Not in consideration]

This GCC flag produce binary that is optimized for size. It is commonly seen as -O2 optimizations without sacrificing for binary file size, so the GCC compiler will create binary of smaller size. In this case, where we want Libjpeg binary to decode faster, this GCC flag is useless.

The VFP hardware floating-point coprocessor: [Maybe]

The Raspberry Pi's BCM2835 SoC contains the VFPv2 coprocessor unit which is quite rare with chip based on ARMv6 instruction set. It is not very powerful, but may help in certain computations. With Libjpeg decoding, this coprocessor only make sense when the Libjpeg binary is compiled with -O2 flag.

Conclusion

If decoding speed is all that matters, then go with fast integer DCT method. However, do note that this method may produce corrupted jpeg images. Test on your own setup to verify.

Now the mounting holes are ready:

The big DC jack hole was made by melting. No choice, there isn't a big enough screw, so a soldering iron is used... =p

And how to mount the Adafruit charger board onto the enclosure? I have a lot of cable ties. And they are really useful in this situation. 4 cable ties are needed to secure 2 mounting points:

Finally, this is how it looks like:

Go to Adafruit

And if the built-in JST connectors do not suit your needs, just solder on up to 2 more connectors of your choice with the 3mm terminals provided.

There are really many other features. The microchip controller is capable of preconditioning the battery at the beginning of charging phase, thermal regulation and safety shutdown, battery temperature monitoring, etc.

Input: microUSB or 2.1mm DC jack (5V to 12V)

Output: 4.2V - 100mA to 1200mA (adjustable via Rprog)

Change the charging current according to this schematic. Rprog in my picture above is R1 in the schematic. You either remove the built-in resistor and put your own in (tough given that it is so small), or add a resistor in parallel. Do your own calculation of parallel resistance to get the desired value.

Notes:

Observations made on a few occasions on different days. Issue 'top' command for the realtime information.

YUYV is a raw uncompressed format. It implies no decoding is necessary but generally hogs the USB bandwidth.

Recording framerate at 2 fps.

Put zlib in one place

By default, the header files and libraries for zlib should already be installed. So, it is located within the Raspberry Pi system root, and in our cross-compile environment (refer to Part 1 of this guide), it is located in: ~/raspberrypi/rootfs/usr/include and ~/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf.

Now, copy zlib header files and libraries to ~/arm/zlib1g-dev/:

cd ~

mkdir -p arm/zlib1g-dev/include

mkdir -p arm/zlib1g-dev/lib

cd ~/raspberrypi/rootfs/usr/include

cp zconf.h zlib.g ~/arm/zlib1g-dev/include

cd ~/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf

cp libz.a libz.so ~/arm/zlib1g-dev/lib

Put libjpeg in one place

Libjpeg8 header files and libraries are not installed by default on a clean Raspberry Pi image. So, power up your Raspberry Pi, install it and then transfer the files to your cross-compiling machine. On Raspberry Pi:

sudo apt-get install libjpeg8d-dev

Locate libjpeg8d-dev files:

dpkg-query -L libjpeg8-dev

There are 4 header files and 2 library files to transfer over:

/usr/include/jmorecfg.h

/usr/include/jerror.h

/usr/include/jpeglib.h

/usr/include/arm-linux-gnueabihf/jconfig.h

/usr/lib/arm-linux-gnueabihf/libjpeg.a

/usr/lib/arm-linux-gnueabihf/libjpeg.so

I assume you have some means to transfer the above 6 files from the Raspberry Pi, either by a USB thumbdrive, FTP, or whatever. Otherwise, you may download my custom compiled libjpeg8 at the end of this page. Then, on your cross-compile machine, copy those files to ~/arm/libjpeg/:

cd ~

mkdir -p arm/libjpeg/include

mkdir -p arm/libjpeg/lib

cp /{whatever-dir}/*.h ~/arm/libjpeg/include

cp /{whatever-dir}/libjpeg* ~/arm/libjpeg/lib

Obtain Motion source code

Finally, let's compile and build Motion. The reason for the above steps is because Motion's configure script does not allow for the --sysroot parameter. So, this is unlike compiling ffmpeg in Part 2.

Now download the latest stable SVN version of Motion, as of this writing Trunk Revision 557, you may first need to install the subversion client on your cross-compile machine.

sudo apt-get install subversion

Now, download Motion:

mkdir ~/compiling/motion

cd ~/compiling/motion

svn co http://www.lavrsen.dk/svn/motion/trunk/ .

Note the period at the end of the url with a space in between.

Patch a bug in Motion

Oh, we still have to patch ffmpeg.c in the Motion source code that you just downloaded. There is a bug when compiling for ARM (Read more here). Otherwise, continue and follow the instructions below and edit ffmpeg.c:

nano ffmpeg.c

Look for the line: #ifndef __SSE_MATH__

Replace that line with: #if !defined(__SSE_MATH__) && (defined(__i386__) || defined(__x86_64__))

Save the changes pressing: ctrl + o

Exit nano editor pressing: ctrl + x

Compile and build Motion

Next, still inside ~/compiling/motion,

./configure --without-optimizecpu

--host=armv6-linux

--prefix=$HOME/arm/motion

--with-ffmpeg=$HOME/arm/ffmpeg

CC=arm-linux-gnueabihf-gcc

CFLAGS='-O3 -march=armv6zk -mfpu=vfp -mfloat-abi=hard -I$HOME/arm/libjpeg/include'

LDFLAGS='-L$HOME/arm/libjpeg/lib -L$HOME/arm/zlib1g-dev/lib'

Note that the above are supposed to be in one line! I break it up so that it is easier to see. Yes, it is this long, thanks to no --sysroot provision. If you did not encounter error, next do the building,

make

make install

Completed

Congratulations, your custom optimized built of Motion is located in ~/arm/motion. Copy the entire 'motion' directory to your Raspberry Pi. I prefer to put the files in /usr/local/. So,

motion/bin/* --> /usr/local/bin

motion/share/* --> /usr/local/share

motion/etc/* --> /usr/local/etc

Using Motion? Read the guide online: http://www.lavrsen.dk/foswiki/bin/view/Motion/MotionGuideOneLargeDocument

Comments are welcome. How can I improve the process?

Downloads

In the usual fashion, I make my Debian package of Motion available for download. Use at your own risk.

Download motion-3.2.12-trunk-revision557-armhf (291KB)

If there is no error messages, proceed to build:

make

* Be patient, this will take a while as ffmpeg is rather big to compile. This is also precisely the reason I chose to do cross-compiling from a PC/Mac rather than compile directly on the Raspberry Pi.

There should not be error at this stage, proceed to building the final binaries:

make install

The FFMPEG binaries including headers and libraries are ready to be deployed in Raspberry Pi, to be found in ~/arm/ffmpeg. The headers and library files found inside are to be used for compiling Motion later also.

While you can copy these binary and library files and replace those found in Raspberry Pi one by one, I prefer to uninstall the old FFMPEG in Raspberry Pi (version 0.8.4) and install the one we just built. I packed my built of the FFMPEG (0.8.12) into a convenient Debian package for download and install. Use at your own risk.

Install GIT tool and rsync:

sudo apt-get install git-core rsync

Obtain the pre-built cross-compiler toolchain:

cd ~

mkdir raspberrypi

cd raspberrypi

git clone git://github.com/raspberrypi/tools.git

The above process will take up to an hour as it downloads the toolchain to ~/raspberrypi/tools.

Transfer system libraries from a working Raspberry Pi over:

cd ~/raspberrypi

mkdir rootfs

rsync -rl --delete-after --safe-links [email protected]:/{lib,usr} $HOME/raspberrypi/rootfs

In the above, I assume your Raspberry Pi is running and connected to the same local network as your linux/virtual machine. If you are using a virtual machine, make sure it is configured to connect to network using bridged connection.

Again, this step will take about an hour depending on your local network speed. You will have about 1.3GB of files transferred to ~/raspberrypi/rootfs.

By now, you are almost done setting up the cross compiling environment. Last is to add the path of the ARM toolchain to ~/.bashrc:

PATH=$PATH:$HOME/raspberrypi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin

Logout and login to refresh the changes made to path. To test if it is working, run the following:

arm-linux-gnueabihf-gcc --version