ESP8266 – Sming Framework, issues and tips.

So some issues and tips regarding the Sming framework for programming the ESP8266:

The Arduino Json library on Sming master branch
Version 4.0 of the Arduino Json Library is present, at least at today’s date (12/2015) on the Master branch of the Sming framework.
The develop branch of the framework uses the version 5.0 of the Arduino Json library.

To do any useful work with JSON on the Sming framework we should use the develop branch and not the master branch.

It might be related, or not, didn’t investigated too much, but I had huge memory leaks that exhausted my heap very rapidly when using the master branch when processing JSON data. When using the development branch, with the same code base (just a HTTP client and Json decoding) those issues where gone.

Other issues with version 4.0 of the Arduino Json Library included the processing of double/float values that had no floating point, which is a great problem on this version. For example (double)15 evaluates as zero, while (double)15.0 evaluates correctly. So it is really important to upgrade and use the version 5 of the JSON library.

So instead of just cloning the master branch, clone the development branch: git clone -b develop https://github.com/SmingHub/Sming.git

Building images
On the master branch I had no trouble creating and flashing the resulting images to the ESP8266, but on the development brach I had serious problems. The issue is solved now, and it is related to the esptool.py tool that is unable to generate the image files to be flashed. The latest version of the esptool.py available on the Github repository complains regarding the errno definition, also something that is related, to the Json Library.

Anyway, the latest commits on the development branch uses the esptool2, just clone the repository onto somewhere (in my case /opt):

[pcortex@pcortex: opt]$ git clone https://github.com/raburton/esp8266
[pcortex@pcortex: opt]$ cd esp8266/esptool2
[pcortex@pcortex: esptool2]$ make

And make sure that the esptool2 binary is on the path, or change the Makefile-project.mk located, in my case, in /opt/Sming/Sming:

From

# esptool2 path
ESPTOOL2 ?= esptool2

to

# esptool2 path
ESPTOOL2 ?= /opt/esp8266/esptool2/esptool2

After this, the usual cycle of make and make flash should work. If we already have a project we should first run make clean just that the esptool2 can create the new image files.
Note that the esptool.py tool is still used for the flashing process.

So the final conclusion is, despite its bleeding edge status, to use the development brach, and not the master branch as of today. The issues that are solved on the development branch are important to the make the framework useful.

Dropbox doesn’t start (Linux)

So a quick note regarding Dropbox running on ArchLinux with Nvidia drivers. Since I use KDE Plasma 5 that doesn’t show system tray icons of some applications that have not migrated to the new system tray protocol, I didn’t notice that after upgrading Dropbox it stopped working.

A quick investigation, I’ve found out that starting Dropbox from the command line did nothing. It started and stopped. Something is going on…

So I’ve used the strace command to see if I could catch something meaningful:

[pcortex@pcortex:~]$ cd .dropbox-dist/dropbox-lnx.x86_64-3.10.8/
[pcortex@pcortex:dropbox-lnx.x86_64-3.10.8]$ strace ./dropbox 2> stracedump.txt

And sure enough in the stracedump.txt I had the following error:

open("/usr/lib/dri/tls/swrast_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/dri/swrast_dri.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
rt_sigaction(SIGSEGV, {0x7f09e1dea010, [SEGV], SA_RESTORER|SA_RESTART, 0x7f09e1a88d60}, NULL, 8) = 0
write(4, "Fatal Python error: ", 20)    = 20
write(4, "Segmentation fault", 18)      = 18
write(4, "\n\n", 2)                     = 2
write(4, "Traceback (most recent call firs"..., 36) = 36
write(4, "  File ", 7)                  = 7
write(4, "\"", 1)                       = 1
write(4, "d", 1)                        = 1

So the error is related to the Software Raster library, that I don’t have because I’m running Nvidia proprietary drivers.

The confirmation came with the following command:

[pcortex@pcortex:dropbox-lnx.x86_64-3.10.8]$ LIBGL_DEBUG=verbose ./dropbox
libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: reverting to indirect rendering

The solution?
Quite simple, just remove (backup) the libGL.so.1 library that exists on the Dropbox directory.
After the removal, Dropbox starts just fine.

ESP8266 Sming – How to start

After dumping Lua Nodemcu for doing any useful work/tinkering on the ESP8266(it works fine for simple things and that’s it), from the available options for programming the ESP8266, native C/C++ SDK programming, Arduino, Sming, Smart.js and Espruino, I’ve selected Sming. One of the main reasons for selecting Sming is the huge range of working examples comprising HTTP clients, servers, AJAX, sensors, MQTT, you name it. Also I can use Netbeans IDE to build the ESP8266 applications and since Netbeans offers code completion, It can help a lot with the apparent lack of API documentation.

Netbeans Sming Code Compltetion

Netbeans Sming Code Compltetion

Another advantage that is not stated enough is the SPIFFS file system support. Install spiffy and under your project directory, create a files sub-directory, put the files there, and those files are flashed onto the ESP8266 as the SPIFFS file system…

How to start
Install first the esp-open-sdk and then Sming. The Sming instructions are pretty clear, in my opinion, on the GitHub site. Also if using Netbeans instructions are here: Setting up Sming with Netbeans. Make sure that the include paths are configured. It will enable code completion and get rid of the “errors” on the IDE.

After that we can export the variables ESP_HOME and SMING_HOME with the esp-open-sdk and Sming paths, or change the Makefile-user.mk of each project to point to the correct locations.

Installing and configuring Spiffy.

The following instructions are deprecated! -> See below how to install from SmingHub.
As usual, download spiffy from Github, compile, and make Sming aware of its location:

[pcortex@dune:opt]$ git clone https://github.com/alonewolfx2/spiffy
Cloning into 'spiffy'...
remote: Counting objects: 101, done.
remote: Total 101 (delta 0), reused 0 (delta 0), pack-reused 101
Receiving objects: 100% (101/101), 78.41 KiB | 0 bytes/s, done.
Resolving deltas: 100% (54/54), done.
Checking connectivity... done.
[pcortex@dune:opt] cd spiffy
[pcortex@dune:spiffy master]$ mkdir build
mkdir: created directory ‘build’
[pcortex@dune:spiffy master]$ make

Under the directory build should be now a binary named spiffs.

Goto now to the Sming/Sming subdirectory and edit the Makefile-project.mk and edit the SPIFFY ?= spiffy line to include the full path of spiffy. In my case:

# Full path spiffy command, if not in path.
SPIFFY ?= /opt/spiffy/build/spiffy

With this change when we clone one of the available projects we can just create a files subdirectory under the project directory to enable files that are put there to be flashed onto the ESP8266. Just make sure that you add to the project Makefile-user.mk file the line: SPIFF_FILES = files

Spiffy from SmingHub

The latest version of Sming that is available from Sming Hub already has spiffy available. We just need to build it.

[pcortex@dune:opt] cd /opt/Sming/Sming/spiffy
[pcortex@dune:spiffy] make

And that’s it, spiffy binary is now available.
Another way to build is just to make spiffy at the /opt/Sming/Sming directory.

First project
For first project I recommend to clone/copy one of the provided examples to a directory OUT of the Sming folders. Why? Because in this case we won’t have any conflicts when doing a git pull to update the Sming framework, and we keep the original projects intact, so we can use them as reference.

After copying the project we can see that the file structure is simple, and coding isn’t that hard ( but it’s needed to have some C and C++ proficiency ) to build applications. Coding on Sming framework is very similar to programming for an Arduino function and library wise, but with some differences, namely the callback “way” of programming and the nonexistence of the setup()/loop() paradigm (it doesn’t makes sense on a callback way of programming).

The code folder structure should mimic the example projects, namely a root folder where the make files reside, and under this folder the app folder for application files (.cpp, .c), the include folder for include files, and a files folder (optional) for holding files for the spiff file system.
Still these folders can be changed by modifying the Makefile-user.mk file at the root directory, namely the MODULES entry and the SPIFF_FILES entry:

Makefile-user-mk:
#Add your source directories here separated by space
# Sources under the ./app and ./libcode1 and ./libcode2
MODULES = app libcode1 libcode2

## MacOS / Linux:
ESP_HOME = /opt/esp-open-sdk

# MacOS / Linux
SMING_HOME = /opt/Sming/Sming

# MacOS / Linux:
# COM_PORT = /dev/ttyUSB0

# Com port speed
COM_SPEED	= 115200

# SPIFFs files Location
SPIFF_FILES = web

Programming

All Sming framework based programs must provide a init() function, that is called at ESP8266 startup. There is no setup() or loop() functions. The later function doesn’t make sense since for programming the ESP8266 we register a function for an event, and that function is called when the event triggers. No need for pooling and/or looping. So no loop() function. The Arduino sketch setup() function is in our Sming framework our init() function…

On the init() function we can setup a lot of things like, pin modes, serial port, and of course Wifi connectivity. Programming with an IDE that offers code completion allows us to see the available API and guess some of the functionality even without documentation ( note that most of the API is identical/similar to the Arduino).

So for programming with the Sming framework these are some of my notes that might be helpful:

Serial port
The always helpful serial port… allows the output of data and debugging information and keyboard input, at least when the device is connected to the computer.
The serial port usage from a coding stand point is identical to the Arduino library, but ESP8266 outputs some debugging information also for the serial port:

Serial.systemDebugOutput( flag ) - Enables/disables framework debugging.

When the value of the input parameter flag is true, we can see a lot of information, including HTTP headers, and so on. Quite verbose, which means that our output might be lost in the middle of this debugging information.
Still with the above flag set as false we can still see some debug output that can be almost completely shut off with the following instruction: system_set_os_print(0);.

So a standard init function would be something like:

void init() {
        system_set_os_print(0);  // Zero to disable, 1 to enable. Disable SDK output to serial 
  	Serial.begin(SERIAL_BAUD_RATE); // 115200 by default. SERIAL_BAUD_RATE constant is defined in include/user_config.h
	Serial.systemDebugOutput(false); // Disable debug output to serial
   
        Serial.println("Starting up!...");
        //....

}

A final note regarding printing to the serial port and debugging, we can use the higher level Serial output instructions, but with Sming we also can use/mix the standard SDK instructions: this means that we can also use the functions debugf and os_printf.

System ready
We can on the init function register a callback for when the system is ready:

void systemIsReady() {
   // do stuff.
   // Start servers
   // Note that wifi connection here is not assured. 

}

void init() {
        system_set_os_print(0);  // Zero to disable, 1 to enable. Disable SDK output to serial
  	Serial.begin(SERIAL_BAUD_RATE); // 115200 by default. SERIAL_BAUD_RATE constant is defined in include/user_config.h
	Serial.systemDebugOutput(false); // Disable SMING debug output to serial
   
        Serial.println("Starting up!...");
        //....

        System.onReady(systemIsReady);
}

Wifi Connection
Almost all the examples have the setting up of a wifi connection, some as a client, others as access point.
The important thing is that the all the callback functionality either on success or failure is already implemented, and so it’s quite easy to check for success or failure.

// Will be called when WiFi station was connected to AP
void connectOk()
{
        String devIP;
        String mac;
	Serial.println("I'm CONNECTED");

        devIP = WifiStation.getIP().toString();
        
        Serial.println("Device IP : " + devIP );

        mac = WifiStation.getMAC();
        mac.toUpperCase();
        Serial.println("Mac addrs: " + mac );
        ...
}

// Will be called when WiFi station timeout was reached
void connectFail()
{
	Serial.println("I'm NOT CONNECTED. Need help :(");

        WifiStation.waitConnection(connectOk, 20, connectFail); // We recommend 20+ seconds for connection timeout at start
}

void init() {

    // ....
	WifiStation.config(WIFI_SSID, WIFI_PWD);
	WifiStation.enable(true);
	WifiAccessPoint.enable(false);

	// Run our method when station was connected to AP (or not connected)
	WifiStation.waitConnection(connectOk, 20, connectFail); // We recommend 20+ seconds for connection timeout at start

    //....

}

Note that is way easier than Nodemcu Lua where we need to implement the connection check by ourselfs by doing a timer based pooling.
With Sming is quite easy, connectOK() is called when a successful connection is made, and connectFail() is called if the timeout (the second parameter) is reached and a connection isn’t made.

On connectFail() we can just again repeat the same instruction or list the available networks and try to connect to some of them.

Still, in my opinion, we should set up the WIFI parameters and connection initiation under the system ready callback.

Some code snippets
List the available wifi networks:

// callback function for WifiStation.startScan(networkScanCompleted);
void networkScanCompleted(bool succeeded, BssList list)
{

	if (!succeeded)
	{
		Serial.println("Failed to scan networks");
		return;
	}

	for (int i = 0; i < list.count(); i++)
	{
		Serial.print("\tWiFi: ");
		Serial.print(list[i].ssid);
		Serial.print(", ");
		Serial.print(list[i].getAuthorizationMethodName());
		if (list[i].hidden) Serial.print(" (hidden)");
		Serial.println();
	}
}

void init() {
    //...
    WifiStation.startScan(networkScanCompleted);
    //...
}

List system info.

void ShowInfo() {
    Serial.printf("\r\nSDK: v%s\r\n", system_get_sdk_version());
    Serial.printf("Free Heap: %d\r\n", system_get_free_heap_size());
    Serial.printf("CPU Frequency: %d MHz\r\n", system_get_cpu_freq());
    Serial.printf("System Chip ID: 0x%x\r\n", system_get_chip_id());
    Serial.printf("SPI Flash ID: 0x%x\r\n", spi_flash_get_id());
    Serial.printf("SPI Flash Size: %d\r\n", (1 <> 16) & 0xff)));
}

The above snippet was kind of important because it shows how to get the system or chip id that can used to identify the device, for example, in MQTT device names.

Just a final note, that all the above code and snippets are collected from several sources:

– Sming Examples
– ESP8266.Com forum
– GitHub: https://github.com/dmarkey/smarthome_esp8266RCcontroller_sming.git and mainly https://github.com/gernoteger/DobbyESP

ESP8266 – Setting up Sming and NetBeans

Sming is one of the alternative firmware for the ESP8266 that is built on top of an extensive library that hides some of the ESP8266 SDK complexities. There is also another alternative firmware that is directly integrated with the Arduino IDE ESP8266 Arduino that mimics much of the process and ways off building Arduino sketchs that deploy and run on the ESP8266.

I’ve tried both, and for my tastes, since I prefer Netbeans or other editor to the Arduino IDE, I’ve choose to use the Sming firmware.

Setting up the SDK and Sming
For starting to use the Sming firmware, we should download the ESP8266 SDK and Sming from Github. The pfalcon esp-open-sdk is the fastest way to set up the SDK. Just do:

ESP8266 SDK

$ cd /opt
$ git clone --recursive https://github.com/pfalcon/esp-open-sdk.git
$ cd esp-open-sdk
$ make STANDALONE=y

Make sure for running the above commands that you have the prerequisites installed for your platform.
The make command will take a while depending of your internet speed and machine speed. It can take around 20 minutes or more.

For installing Sming, the Github site instructions explain what is needed. Basically it’s:

$ cd /opt
$ git clone https://github.com/anakod/Sming.git

To use Sming we need to set our environment variables.

$ export ESP_HOME="/opt/esp-open-sdk";
$ export SMING_HOME="/opt/Sming/Sming";

But this change is not permanent and it won’t work with Netbeans without changing the Makefiles.
So we need to change the core Makefile to add permanently the paths to the SDK and SMING homes:

Set Sming environment paths permanently:
Just got to Sming home directory /opt/Sming/Sming and edit the file Makefile:

Change the lines (uncomment them, removing the #):

## Defaults for Sming Core

## ESP_HOME sets the path where ESP tools and SDK are located.
## Windows:
# ESP_HOME = c:/Espressif

## MacOS / Linux:
ESP_HOME = /opt/esp-open-sdk

## SMING_HOME sets the path where Sming framework is located.
## Windows:
# SMING_HOME = c:/tools/sming/Sming 

# MacOS / Linux
SMING_HOME = /opt/Sming/Sming

## COM port parameter is required to flash firmware correctly.
## Windows: 
# COM_PORT = COM3

# MacOS / Linux:
# COM_PORT = /dev/tty.usbserial

# Com port speed
COM_SPEED = 115200

For each project demo that we are going to compile, at the root of the project we need to change/uncomment at the Makefile-user.mk file the same variables to define the same values. Otherwise Netbeans will complain that the SMING_HOME and ESP_HOME Variables are not defined. We can use the Netbeans itself to edit that file.

One final change is needed regarding the esptool.py that is used by Sming to flash the ESP8266 chips. The tool is made to run with Python 2 and on my Arch Machine I have both Python 3 and Python 2, being Python 3 the default. Due to this, the esptool might fail to run with the following error:

# Generating image...
  File "/opt/esp-open-sdk/esptool/esptool.py", line 135
    print 'Connecting...'
                        ^
SyntaxError: Missing parentheses in call to 'print'
/opt/Sming/Sming/Makefile-project.mk:274: recipe for target 'out/build/app.out' failed
make: *** [out/build/app.out] Error 1

So we need to edit the esptool.py file and change the header to use Python2:

#!/usr/bin/env python2

Also the tool assumes that the ESP8266 is connected and available at the serial port ttyUSB0.

We can now go to one of the examples directory and compile one of the examples. Since I’m using my own developer board that uses serial RTS and DTR to enter “automagically” the ESP8266 in flash mode, I just need to do make at the root of the example directory. If needed we can flash again with the command make flash

And that’s it.
Just a word of caution, since my developer board uses the RTS and DTR lines, the Sming Make file calls the miniterm.py that doesn’t set the RTS and DTR lines to inactive state, and so keep the ESP8266 in reset mode. To solve this, just change the TERMINAL directory on the makefile of your platform located at Sming/Sming to something that works. EDIT: Or use CTRL-T + D and CTRL-T + R to reset the lines.

Setting Netbeans to compile with the Sming Framework
Important note/update: With the latest Netbeans 8.1 version, code completion doesn’t work. Use version 8.0.2 for now to solve the issue.

To use Netbeans, just open up Netbeans, and go to Tools->Options and select the C++ icon. If needed press the Activate button to enable C++ support.
The instructions are now very similar to those in this post Setting up Netbeans for ESP8266. Just make sure that you have the C++ plugin installed, and restart the IDE if necessary.
Then at the C++ Window Build Tools tab, just add a new Tool Collection, but this time the compiler path is /opt/esp-open-sdk/xtensa-lx106-elf, and ignore the error, but select the family as GNU. The error should be gone. Give it a name: ESP8266 Xtensa and press OK. Just set up now the path to the C compiler and C++ compiler located on the bin directory: /opt/esp-open-sdk/xtensa-lx106-elf/bin.

Netbeanx Xtensa compiler

Netbeanx Xtensa compiler

For making Netbeans Code completion work, we need to add the path to include files on the Xtensa compiler tools. Make sure that it’s the ESP8266 Xtensa compiler that is selected and add the following paths:

Include paths

Include paths

These might not be enough. It really depends on the project. Make sure that you add the include paths to both the C++ and C compiler.

Edit:
I had to add the following paths at the Code Completion for the Xtensa compiler so the code completion could work without warnings on the SmingCore.h file with the latest Sming version:

  • Sming/rboot
  • Sming/rboot/appcode

Just add this directories the same way as the above screenshot.

Also at the project level properties it is necessary to add the project include directory so that the user_include.h file and others can be found.

And we are set!

Compiling Basic_Blink Project
Using Netbeans, just add a new C++ project with existing sources, and select the root directory of any of the examples, in this case, let’s choose the /opt/Sming/Basic_Blink. Just make sure that the compiler tools choosen is the ESP8266 Xtensa that we previously have defined. At start Netbeans will try to run the make command, and it might fail.
Just open on the project tree the Makefile-user.mk file and remove the comment from the lines defining the ESP_HOME and SMING_HOME paths.
Also select the Makefile, right click Make target->Add target and add the word flash as a target.

That’s it, we can now make the project and select Make Target->flash to flash to the device.

Happy coding

Odroid emmc speeds

I’ve found out this link that shows some speed benchmarks, on the Raspeberry PI, for some SD cards and disks: RPi SD card benchmarks.

For comparison, my data:

Odroid C1+ with 32GB emmc:

root@odroid:~# hdparm -T /dev/mmcblk0p1 
/dev/mmcblk0p1:
 Timing cached reads:   1494 MB in  2.00 seconds = 746.46 MB/sec

My Seagate 2TB on my DS212+, also driven by an ARM processor:

root@DiskStation:/volume1/homes/root# hdparm -T /dev/sda1

/dev/sda1:
 Timing cached reads:   832 MB in  2.00 seconds = 415.24 MB/sec

The flash pen that holds the operating system on my old and faithful NSLU2:

root@nslu2:~# hdparm -T /dev/sda1

/dev/sda1:
Timing buffer-cache reads:    78 MB in 0.51 seconds = 155972 kB/s

And finally my Crucial SSD disk on my desktop computer:

[root@pcortex:~]# hdparm -T /dev/sdc2

/dev/sdc2:
 Timing cached reads:   16804 MB in  2.00 seconds = 8408.63 MB/sec

The conclusion? Not bad for the emmc. Recommended over an SD card? I think definitely. Expensive? Well, yes…

Linux: Slow or unbearable performance with high memory usage applications

Well this post title is a bit vague because the issue that have affected me can have several sources, not just the one that I’ll describe. But I suppose the solution is the same independently for all sources.

Anyway, I was suffering from a strange problem on both my computers, the desktop has 6GB of RAM, and the laptop, 16GB.

On the desktop machine, where I use KDE 4 on Arch Linux, the desktop can froze when using some resource intensive applications like Google Maps on Firefox or Chromium and Android Studio. When the frozen desktop situation happens, I just have to wait a few minutes, during which time, the keyboard is irresponsible and the mouse is “jumpy”, or doesn’t work at all. And so after a while, one random application, that could be anything, including the desktop, is killed, with some cryptic message regarding sacrifice on the system logs…

Anyway, on the Desktop, due to the fact that I’ve upgraded the main disk to an SSD, I didn’t enabled the swap partition. And that was one of the main reasons of this behaviour that I was having. Despite having 6GB of RAM, a swap file is good to have, and so I’ve used a swap partition on one of the spinning disks.

That apparently stopped the issues on the desktop and it never froze like it used to when performing the same tasks.

On the laptop it was another matter, mainly because of the fact that it only has a 120GB SSD disk, and no spinning disks, I had no swap file/partition created or enabled. I though that with 16GB of RAM, why bother… but due to professional related activities, I had to start to work with the HortonWorks HDP 2.3 big data/hadoop platform, and that is a heavy resource hog…

So, despite of having 16GB of RAM available, the Hadoop virtual machines based on Vmware could make the computer just froze for lenghty periods of time, just like my desktop computer.

But, now I know that was related to fact that I didn’t have a swap partition/file, and so I’ve created one.

The swap file solution for this specific case didn’t solve completely my issue, but I did managed to see a process named khugepaged consuming huge amounts of CPU.

And that was the reason that I had for my frozen desktop and virtual machine for some lengths of time.

So I’ve disable the Huge Page support on my host operating system, AND on my guest CentOS virtual machine that is running HDP 2.3:

[root@dune:cortex]# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
[root@dune:cortex]# echo never > /sys/kernel/mm/transparent_hugepage/enabled

[root@dune:cortex]# echo never > /sys/kernel/mm/transparent_hugepage/defrag
[root@dune:cortex]# cat /sys/kernel/mm/transparent_hugepage/enabled          
always madvise [never]

More info can be obtain here:

http://docs.mongodb.org/manual/tutorial/transparent-huge-pages/

So this might not be the magic bullet if we are having desktop freezes, and not using huge amounts of RAM, but it might help.

md5deep and hashdeep on Synology DS212+

My personal photos are located at my desktop computer, and I have backups of them on my Synology DS212+ and my old faithful Linksys NSLU2 with an external disk.

The issue that I have now is that to keep backup times short I only backup the current year, because, well, the other years are static data. Previous years are already backed up and that data is not to get modified. Right? So what if corruption happens? How do I detected it? How can I be warned of such event? Right now I have no method to check if my digital photos of 2003 are totally intact in all of my three copies. And if  I detect corruption on one bad file/photo, which file is the correct one?

So I’m investigating this issue, and one of the tools available to create checksums and then to verify if everything is ok and no corruption has appeared is the md5deep and hashdeep programs. These are available as sources at this link: http://md5deep.sourceforge.net/start-hashdeep.html

These are the instructions for cross compiling these tools for the ARM based Synology DS212+. As usual this is done on a Linux Desktop/server machine.

1st) Set up the cross-compiling environment: Check out this link on the topic: https://primalcortex.wordpress.com/2015/01/04/synology-ds-crosscompiling-eclipseibm-rsmb-mqtt-broker/

2nd) Setting up the cross compiling environment variables is now a bit different:

export INSTALLDIR=/usr/local/arm-marvell-linux-gnueabi
export PATH=$INSTALLDIR/bin:$PATH
export TARGETMACH=arm-marvell-linux-gnueabi
export BUILDMACH=i686-pc-linux-gnu
export CROSS=arm-marvell-linux-gnueabi
export CC=${CROSS}-g++
export LD=${CROSS}-ld
export AS=${CROSS}-as
export AR=${CROSS}-ar
export GCC=${CROSS}-g++
export CXX=${CROSS}-g++

We will use the C++ compiler.

3rd) Create a working directory and clone the repository to your local machine: git clone https://github.com/jessek/hashdeep.git
4th) Change to the hashdeep directory and execute the following commands:

[pcortex@pcortex:hashdeep]$ sh bootstrap.sh
[pcortex@pcortex:hashdeep]$ ./configure –host=arm-marvell-linux-gnueabi
[pcortex@pcortex:hashdeep]$ make

And that’s it. If everything went well then at hashdeep/src directory the commands are available:

[pcortex@pcortex:src]$ file hashdeep
hashdeep: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped

We can now copy the commands to the DiskStation and start using them.

Now all I need is to devise a method that creates and checks each year photo hash/signatures, and warns me if a difference is detected. I’m thing on using the audit mode of the hashdeep command, and do each day a check for one year, for example, on Mondays check 2003 and 2013, on Tuesday check 2004 and 2014 and so on.