LUA and ESP-8266 - What a wonderful world !

Guess what, I bumped onto a blogpost discussing a cheap Wifi-module for Arduino. A sub 5USD module with an embedded ARM processor on board. Unbeatable price and feature set !

After doing some research, I bought the ESP-12 module on Aliexpress :

It's a stamp-sized module, with a serial port and a bunch of GPIO's :

I connected my USB-Serial convertor (I have a CH340G with selectable 3.3/5V) and after figuring out the correct pinout , I flashed the LUA-firmware on it.

ESP8266	CH340G-SerialUSB
VCC	VCC
GND	GND
RX	TX
TX	RX

Holding GPIO15 = LOW, and CH_PD = HIGH activates the module.
Communication is possible @9600,8,N,1 in this mode.
Holding GPIO0 = LOW, brings the module in bootstrap mode and download of a new firmware is possible.

I chose to upload a new firmware :  nodemcu-firmware using the esp8266flasher.exe software.

From then on, you can talk to the module using the Serial.line and setup the module by either executing commands or by writing the lua.init file. I used a textfile with commands, allowing easy push to the ESP-module.

When reusing existing code, it is important to check the GPIO-mapping. In my case the LUA-Gpio's map as follows to the Hardware pins :

This means that IO (7) is actually using hw-pin GPIO13 !

Once the Module has been connected to the Wifi-AP, everything is straightforward.

Sending a command :
<< http://192.168.2.108/gpio7=0 >> will clear  GPIO13 on the board !
<< http://192.168.2.108/gpio7=1 >> will set  GPIO13 on the board !

Imagine what you could do !

Using Computer Mouse as Scanning Device for Arduino

I happened to have a wireless keyboard/mouse combo lying around with a broken USB-dongle. Basically unusable for regular use, but of course ideal for some thinkering.

I recently read an article about using the image sensor as input device for Arduino or other MCU and I wondered if I could repurpose my mouse for this.

So, I took my mouse apart and found out it is based on the Avago ADNS-5030.

I first cut all the traces going to the local microcontroller, solder some pins on the sensor and hooked up my Arduino Mini Pro 3.3V/8Mhz as follows, I took the 3.3V power from the Arduino too :

Name	ADNS5030	Mini Pro
VCC	7	VCC
GND	6	GND
NRST	3	9
NCS	4	8
CLK	5	13
MOSI	8	11
MISO	1	12

Reading the datasheet, shows SPI has to be configured in SPIMODE 2 (Pol=1, Pha = 0). Clockspeed is 1Mhz, so the DIVIDER is set to 4.

A quick check allow to verify register 0/1 and to read ChipId and Revision, respectively 0x11 and 0x00.

I ran a small demo reading the Motion-register and reading the dX and dY movement. No big deal.

Now I wanted to make sure I could readout the 15x15 pixel imagesensor. For this you need to readout the Grabber-register (0x0B), check that the MSB is '1' and then use the 7 remaining bits as intensity.

I connected my IL9301 TFT screen to my Arduino and used the Adafruit GFX library to draw the pixels on the screen.

On the software side it's a bit tricky because IL9301 works in SPIMODE=3 and divider 2, so we are changing the SPI-parameters on the fly to make it happen.

This is the setup :

The image sensor has approx. 0,1mm pixel resolution, the 'e' on the TFT-screen corresponds to 1 character from the cardboard.

Nokia USB Serial Cable hack for my Arduino Mini Pro

I happen to have a Nokia USB Serial Cable lying around. I used it to program my Openwrt router.
It was perfectly fine. I had cut of the Nokia connector and I used the 3 wires:

Wire	Signal
Black + Shield	GND
White	RX
Green	TX

This worked perfectly fine for all 3.3v gear connected to the serial lines.
Until the day I wanted to connect my Arduino Mini Pro (3V/8Mhz).

It worked ok, but there were 2 drawbacks :
- I needed to provide separate power to the Arduino ;
- Programming from the Arduino IDE, requires a manual RESET of the Arduino to start the download ;

After some research, I found out the Cable uses a PL-2303HX chip. On PIN 2, there's the DTR-signal  but it isn't connected. The Arduino IDE using this signal to issue a reset to the processor in order to put the chip in download mode.

So, I performed following changes :
- Cut trace leading to Black lead between the 2 solder pads ;
- Solder Red wire from Capacitor to Red wire ;

- Solder Blue wire from PIN 2 to Black wire ;

This effectively puts 3.3v on the RED wire, DTR on the black and leaves RX/TX/GND as before.

Works as a charm. I soldered some Dupont-lines to the end of the Nokia Cable, heatshrinked the connections and finally inserted the PL-2303 board back into the moulded housing and glued everything nice and thightly. In order to avoid confusion, I used BLACK for GND and GRAY for DTR.

Wire	Signal	Mini Pro
Black	GND	GND
White	RX	RX
Green	TX	TX
Red	3.3V	VCC
Gray	DTR	GRN

Porting MZXT06A to Arduino

After having tested the MZXT06A LCD with my Raspberry Pi, I was wondering how much performance I would get out of a Arduino, knowing the processing power is much much smaller on a Arduino Uno or Mini Pro.

First thing  I did was figuring out how to connect the LCD-Board on the Arduino.
Turns out the Raspberry Pi driver is actually only using the MOSI/CLK signals and it is using the MISO/CE and GPIO25 as standard GPIO to interface the LCD-board.

A word about the MZXT06A. It is actually interfaced using a Altera EPM3213 PLD-chip. It's kind of weird because the LCD-controller has 18-bit RGB connectivity, but also 16-bit RGB over SPI. So what the EPLD does, is providing a true 18bit RGB interface over SPI.
The Altera  chip needs 3V power, but it's interface pins are 5V tolerant. This explains why a lot of people are capable of interfacing with 5V-Arduino boards. If you use a 3V Arduino, all will be fine.

I use the Arduino Mini Pro, running at 3.3V and 8 Mhz.

I connected the Display as follows :

- Arduino MOSI (11) : to pin 6 (LCD-SCI)
- Arduino CLK (13): to pin 7 (LCD-SCL)

- Arduino D2 (2) : to pin 5 (LCD-CS)
- Arduino D5 (5) : to pin 4 (LCD-RS)
- Arduino D9 (9) : to pin 3 (LCD-RST)

VCC,LED need 3V
GND goes to GND

Once connected, the display backlight should light up.

I have ported portions of the MZXT06A source-code to Arduino as a proof of concept.
I am now able to fill rectangles, draw circles and draw dots.
I havent figured out what goes wrong with the display_char function. I have put the font-data in PROGMEM because of the lack of dataspace on my Arduino, but no luck. It draws something, but it looks like random data (within the 8x16 characterspace).
Update: found the mistake with display_char. If one stores data in PROGMEM, one has to retrieve this data using a special function "pgm_read_byte_near" referencing the data using a pointer.


Performance is pretty good, considering the 8Mhz MEGA328P.
The display draws approx. 90mA of current and it fills a full frame at 1fps writing 1 byte at the time.
I'm sure this can be optimized.
Update: only way to speed up is to use a higher clock-rate. Currently the interface runs at half the processor speed and it's not the SPI-speed, but rather the CPU which is the bottleneck. Will try later on the Arduino Uno. Should run much faster.

If you need the code for your Arduino, just let me know.

Interfacing MZTX06A 2.2" TFT Screen on Raspberry Pi

I recently bought a 2.2" TFT screen with SPI interface and 320x240 pixel resolution on Deal Extreme.
According to the very rudimentary documentation it needs to be connected like this :

lcd pin	lcd name	Rpi pin	Rpi name
1	LED+	1	3.3V
2	VDD-	17	3.3V
3	/RST-	22	GPIO25
4	RS-	21	MISO
5	/CS-	26
6	SCI-	19	MOSI
7	SCL-	23	SCLK
8	GND	25	GND

After getting the MZTX06A software from github :

 https://github.com/yaolet/mztx06a.git

and launching the makefile, the resulting MZTX06A executable copies the /dev/fb content to the screen. Here below the result when launched directly from rc.local ...

In order to match framebuffer and screen resolution, one has to modify /boot/config.txt and uncomment the lines with Horizontal and vertical screen resolution. Please use 320 and 240 in order to avoid blurred screens.

This method works flawlessly with X. Just startx and watch. Unfortunately 320x240 pixels doesn't leave much space for actual work. Most user interfaces are not suited for low-res.

Recovering lost ODS Spreadsheet on USB Key

This weekend I mistakenly wrote a Linux image onto my USB Key instead of my SD Card. The result was a 25% overwritten 8GB USB Thumbdrive.
Recovering the data using Recuva didn't really work because of the origial FAT32 partition got overwritten with a FAT and ext4 partition. To make things worse both the first and second FAT was lost.
Doing some deepscanning allowed to retrieve apparently useful data, only to discover the recovery process wasn't able to create valid files. For fragmented files the recovery process used the first cluster and grabbed sequential clusters resulted in mixed up filefragments from differents files into the recovered file. What a disaster !
One of the files I desperately needed to recover was a 1850 Kbyte OpenOffice spreadsheet in ODS-format. Opening the file in  OpenOffice resulted in a 'corrupted file, do you want to repair' message and an empty file.
A bit of research pointed out that ODS-files are actually zipped containers containing the actual formating and content. In my case  bits of a PPT file, a MP3 file and other junk was mixed into the recovered file by the recovery process.
Finally I ended up using iBored as a forensic tool to perform some manual carving on the residual data on the thumbdrive.
By looking at a normal ODS-file, I identified the different zones of the OpenDocument format. Special markers in the zipped structure of the ODS-format are '50 4B 03 04' and '50 4B 07 08'. Other interesting and easily identified markers were the file and XML-tags contained in the ODS-file format, like 'META-INF/manifest', 'content.xml' and 'meta.xml'.
The thumbdrive happened to have 128 sector clusters (64KB) and the first cluster recovered by Recuva happened to be the correct start of the file. Knowing that one file only occupies 1 cluster and that sudden change of content inside consecutive clusters or zeroed sectors at the end of the cluster mean there's a rupture in the cluster sequence, I was able to verify the signature of the clusters following the first valid cluster of the file I was trying to recover. Using iBored as a rudimentary diskeditor, I first searched for the 'META-INF/manifest' string typically found at the end of the ODS document. It allowed me to pinpoint the end of the file approximately 7795 sectors after the first sector. I made a list of cluster boundaries and started identifying the content of the cluster by looking at typical signatures like 'MZ ...', directory entry-structures,  typical binary or DLL structures, plain text and randomized data.
Although zipped structures don't contain any internal indexes, they are characterized by the heavy compression and the full use of the 8-bit space, containing no wasted spaces with repeated values or patterns. 47 clusters could be eliminated as cluster belonging to the lost file. Looking at the remaining clusters it looked as if the file was stored in 2 chunks with some garbage inbetween.
Using the write block functionality of iBored, I wrote out the 2 chunks to the harddrive and reassembled the original file by doing a binary copy :
copy /b chunk1+chunk2 final.ods
By opening the resulting file in 7-zip, I could validate the correctness of the assembled data.
Opening the file in OpenOffice resulted in a 'Corrupted file - do you want to correct ?' and Calc was able to repair the inconsistencies without loosing any data or formatting information.
YAY !

Trunk OpenWRT running on Omnima MiniEMBWifi / Edimax NS-1500

I bought the MiniEMBWifi a while ago, but I never got it running smoothly with the supplied Fon firmware. I compiled the Fon-ng version myself but I must admit I don't really like the fon-stuff interfering with stock-openwrt behaviour. Besides, running some old-hat kernel didn't improve things either because a lot of packages are broken on this branch.

So I waited patiently until the Ralink chipset was officially added to the SVN. After patching the code allowing the  Omnima board to be selected in the toolchain, everything compiled like a breeze and voilà ... Attitude Adjustment running since a couple of weeks on my lan.

It's running extremely stable at the moment. Only downside  is the slow USB interface, limiting bandwidth of samba, FTP or ushare to < 9 MB/s and usually around 4MB/s, which is ok for occasional sharing, but not for multimedia.