Search This Blog

Saturday, 7 May 2011

FTP Server and RedFly-Shield Socket class

I have been using Skewworks FTP server class to test my simple RedFly.Socket class. I got to a point where the FTP server was able to respond to a few FTP commands, including using 'get' to retrieve a file from the FEZ Domino SD card. But hit a snag when trying to send a file from the PC to the FTP server. It was becoming obvious that my simple implementation of a Socket class needed to have higher level functionality. Two thoughts were; implementing meaningful exception handling and function parameter checking, and hide in a lower layer the internal socket handling within the RedFly-Shield.

My search lead my to quite a few differing implementations of System.Net.Socket class library functions. Eventually I was draw to the implementation in the OpenSource Mono .Net core.

I've heavily refactored the RedFly.Socket class, and tweaked the FTP server and RedFly-Tester solution (make sure to grab at least r106 from the GoogleCode SVN repository).

As of r106 of the repository, the FTP server can perform most of the commands. 'get' and 'send' are quite limited at the moment though. They are restricted by the number of bytes for a file transferred.

I've got two new steps to take now -
  1. Try the RedFly.Socket class with other example code, such as HTTP client and server, DNS lookups, NTP sync.
  2. Finally update the UART reception handling.

Saturday, 30 April 2011

RedFly-Shield Socket class and FTP Server

After coming back from a short vacation, I thought I'd add an update to describe my progress with the Watterott Electronic RedFly-Shield.

In the previous blog post I describe the success I've had with setting up the C# Shield class to initialise and setup the RedPine Signals WiFi module (RS9110-N-11-22). Once I was happy with this class I moved on to looking at how to support the 8 sockets on this WiFi module.

Skewworks had added a FTP server class to the code repository over at Looking through this, and other network code, it seemed obvious to create a custom Socket class for the RedFly-Shield. I started with the System.Net.Sockets class as a template and began fleshing out the necessary class functions.

After implementing the bare essential Socket functions, I was surprised how quickly it was to get the FTP server class working. A nice feature of creating a new RedFly Socket class is that the only change needed to Skewwork's FTP class was the addition of the following code;
using Socket = RedFly.RedFlySocket;

So right now the RedFlySocket classes can be used to create listening Sockets (only tested TCP ones), accept incoming connections on those sockets, and receive data from a connected host. This initial setup however is able to allow a host PC to connect to the FTP server running on a FEZ Domino, complete a handful of FTP commands (pwd, cwd, etc.), and receive a file located on the FEZ Domino SD card.

A much harder task is to flesh out the RedFlySocket.Send functions. I've come across something odd with my fairly synchronous UART data reception. So now I need to work out a different strategy for handling incoming UART data from the RedPine WiFi module.

Over on my GoogleCode SVN repository, revision 99 of the RedFly class library ties in with this blog post;

A RedFly-Tester solution exists that creates a listening Socket on port 23, and simply acknowledges a host trying to telnet to the RedFly Shield;

Revision 96 of the RedFly FTP server solution also ties in with this blog post;

Sunday, 17 April 2011

Watterott RedFly-Shield

From Project: Burt

Watterott Electronic very generously sent me a new Arduino Shield they are close to releasing. It's called RedFly-Shield, and uses a RedPine Signals WiFi module (RS9110-N-11-22).

Here's the feature list for this WiFi module -
  • Compliant to 802.11b/g and single stream 802.11n
  • Fully self-contained serial-to-wireless functionality - does not require any host processor bandwidth
  • Includes all the protocol and configuration functions required for WLAN connectivity in Open, WEP and WPA/WPA2-PSK modes of operation
  • Payload data through Serial Interface and SPI
  • Terminates TCP and UDP connections, and offers transparent serial modem functionality
  • Configuration through AT commands and SPI frames
  • Integrated antenna, frequency reference, and low-frequency clock
  • Ultra low power operation with power save modes
  • Ad-hoc and infrastructure modes for maximum deployment flexibility
  • Single supply 3.1 to 3.6 V operation
  • Certification : Module is based on RS9110-N11-02 which is certified by FCC, IC and CE.

Watterott have done a great job in designing this shield. Communication to the RedPine WiFi module is via standard UART using modem-like ASCII 'AT' commands. Supplied with the shield is a nicely fleshed out Wiring library and example code for the Arduino (Tweeter, HTTP client and server).

I'd picked up a Sparkfun FT232RL Breakout board for another project. So the first job was to use it to talk to the RedPine module. As the above picture shows it's quite straight forward to setup and snoop on the serial port.

I'm currently using Windows Vista for development, so I needed to grab HyperTerminal to be able to see the UART data, and to use the Kermit protocol to transfer the latest firmware to the module. NOTE: I first tried using the TeraTerm supplied by GHI for use with their .Net boards, but although this looked like it can successfully transfer the firmware files to the RedPine module, the module failed to load them upon reboot. Thankfully using HyperTerminal worked fine.

Although the Arduino is a wonderful module, I usually get frustrated with the development tools. Hence my current projects are focused on using a GHI FEZ Domino module, and recently their Panda module. I'd become familiar with porting Arduino Wiring code to .Net C# with the Watterott S65-Shield. So with the RedFly-Shield's quite complete Wiring library and examples, I've set about porting this across to managed C# code.

Work-in-progress C# class library and testing solution can be found on Burt's GoogleCode repository (revision r92, 20th April 2011);

So far I've managed to get the RedPine module; reset, obtained and decoded the firmware version and MAC address, scanning of broadcast WiFi access points (AP), joining an AP, and obtaining an IP via DHCP.

Hopefully in the next week or so I can complete the port of the Wiring library and examples. Plus code up a Socket class.

*Must resist Portal 2*
Matt Isenhower's Blog - MicroTweet - Twitter OAuth API Library for the .NET Micro Framework

MicroLinq for the .NET Micro Framework -MicroLinq for the .NET Micro Framework

C# .NET DNS query component

Saturday, 16 April 2011

Project Update

A pictorial update of my current projects.

From Project: Burt

Watterott RedFly-Shield connected to a GHI FEZ Domino.
Serial snooping via a Sparkfun FT232RL Breakout board.

From Project: Burt

GHI FEZ Panda. Single row right-angle header allows for the Mode pin to be grounded.
Double row right-angle header underneath the board exposing the JTAG interface.
Not show: Olimex ARM-USB-TINY JTAG dongle.

From Project: Burt

Simple Inertia sensing. I2C temperature sensor. UART and Reset control of the motor controller. Futaba servo mounted and ready to connect to a distance sensing array.

Monday, 28 February 2011

RLE on the OLS

When I started playing with the OpenBench Logic Sniffer (OLS), I came across the Run Length Encoding option in Jawi's SUMP client. The trouble was I couldn't get consistent results using it. Digging through the Dangerous Prototypes forum showed some issues with RLE using the v2 firmware. Forum user 'dogsbody' has made a huge contribution porting the FPGA HDL to Verilog. Fixing up various issues with the firmware. It looks like the v3 FPGA and PIC firmware is now addressing RLE issues. Links to v3 can be found here. Make sure to also grab at least v0.9.3 SP1 of Jawi's SUMP client.

Hopefully later I can repeat the previous posts testing, and see if RLE works and captures more that the ~450 micro-seconds of samples. Fingers crossed! And then, onto SPI sniffing...

From Project: Burt

UPDATE: I managed to update the OLS to v3 of the PIC and FPGA firmware. Repeating the test in the previous blog post, but using RLE compression, looks like it is a lot more stable now. As expected the compression captures more than 10x the number of samples, with this simple UART test.

Unfortunately it looks like the UART analysis plugin in Jawi's SUMP client hasn't been updated to cope with RLE. Sampling at 50MHz without RLE works great. But at the same sampling rate with RLE compression enabled, the UART analysis fails to properly decode the Tx data :(

As you can see from the picture I have also moved to using the GHI FEZ Domino to squirt out UART data. I have put a Visual C# solution up on my GoogleCode SVN repository that squirts data out of UART0.

Sunday, 27 February 2011

Getting to grips with the OpenBench Logic Sniffer

I haven't used a Logic Analyzer since the mid-90s. With new products on the horizon, it's starting to become something needed with this hobby work. Budget constraints have always made it difficult to justify picking up a second hand analyzer. So I was intrigued to come across the OpenBench Login Sniffer (OLS). I ordered one from Proto-Pic, here in the UK. They delivered version 1.01 of the OLS board.

The first step was to make sure that the OLS was up-to-date with FPGA and PIC firmware. At the time of writing v2.12b of the OLS software is available here. Included is a simple application that can flash the OLS EEPROM with new FPGA bit-stream, and update the PIC firmware.

The Gadget Factory has a YouTube channel with a few videos showing FPGA logic analysis and UART debugging. Setting up some UART transmission looked like the easiest way to try out the OLS, and quick to setup on the Arduino Deumilanove.

The OLS is limited with the number of samples it can record, so we need to tell the OLS when we are about to transmit over a UART line. The Arduino runs with a 16 MHz crystal, so the OLS should be able to pick up a pulse on one of the digital I/O pins.

Below is the Wiring code to setup the UART on pins 2, and 3. Plus the trigger pulse output on pin 4. The NewSoftSerial library is used to allow for higher baud rates to be tested.
#include <newsoftserial.h>
NewSoftSerial UART1(2,3); // rx,tx
void setup()
    pinMode(4, OUTPUT);
    digitalWrite(4, LOW);
void loop()
    digitalWrite(4, HIGH);
    digitalWrite(4, LOW);
This simple PDE file can be found here. Also at that SVN location is the project file used with the OLS alternative SUMP client (Jawi's version supplied with the v2.12b OLS software).

I connected the OLS breakout probes to Gnd on the Arduino, and the digital I/O pins 2, 3, and 4. With the above Wiring sketch uploaded to the Arduino I was then able to start getting to grips with Jawi's Java SUMP Client. I ended up sampling at 50 MHz, and that was able to capture just over 450 micro seconds worth of data. The SUMP Client has plugins for analyzing common bus protocols. Below is the UART analysis. As you can see, the OLS managed to capture the UART Tx from the Arduino, result!!

UART Analysis results

Generated: 27 February 2011
Decoded bytes5
Detected bus errors0
Baudrate230400 (exact: 122249)
023.280 μs0x680b01101000104h
1112.040 μs0x650b01100101101e
2200.780 μs0x6c0b01101100108l
3289.520 μs0x6c0b01101100108l
4378.280 μs0x6f0b01101111111o

Next up SPI testing...

Wednesday, 23 February 2011

GHI Electronics release Beta SDK, featuring RLP for all their devices

While away on holiday, it was a nice surprise to find out that Runtime Loadable Procedures (RLP) are now possible on the FEZ Domino (via a Beta SDK). Time to find some time to write Native driver code for that LS020 LCD controller :)

Sunday, 13 February 2011

Watterott S65-Shield with FEZ Domino

I was looking a while back at Arduino LCD shields, and came across the Watterott S65-Shield. A quote from their website describes the shield as;
The S65-Shield is a plug-on module with color TFT-Display (176x132), microSD socket and rotary encoder for Arduino Uno, Duemilanove, Diecimila and Mega Boards
They chose to use a LCD module from a Siemens S65 mobile phone. This LCD module can be found with three different display controllers. The S65-Shield I got from Watterott contains the LS020 controller.

A recent check of the Watterott website shows that this shield is no longer available. They have upgraded their Arduino LCD shield to use a Multi-Inno MI0283QT-2 TFT-Display and a TI ADS7846 Touch-Controller .

Fortunately, a variety of people have already worked on reverse engineering the LS020 LCD module. In particular -
Stephan Watterott and Juraś supply Arduino library and code samples to get this shield up and running. So it felt challenging to try this shield out on the FEZ Domino.

The last time I dealt with writing low-level driver code for single pixel addressable LCD controllers was many years ago. Lots of fond memories and tricks came flooding back. Porting other peoples work to a new language and embedded environment is the easy part. Hopefully others can take further advances thanks to the port and the reverse engineering by many others that forms the basis of this port.

I started first by porting Watterott's library code. Configuring the SPI bus and LS020 controller was quite straightforward to set up. The first expected challenge came from managed code loops within the clear screen (or area) function. Writing single pixels out over the SPI bus using a double for-loop is slow. To reduce delays throwing pixel data over to the LS020, I adopted a line buffer write approach. I did some performance profiling a while ago and recall getting a full clear screen down to around 33 microseconds. Not great, but showed the type of optimisation work required to speed up the ported Watterott Arduino library code. I managed to speed up quite a few library functions, but then got distracted by Juraś work on driving the LS020.

One of the examples Juraś has on his forum does a nice job of showing off the other display addressing modes that the LS020 supports. Two eight bit modes and a 16 bit mode. Watterott's code relies on 16 bit display addressing, whereas Juraś opted for an 8 bit mode. With an unoptimised port of the forum example code, it's plain to see that an 8 bit mode has more potential when coupled with managed code.

A future challenge coupled with optimising the low level LS020 driver code, is adding higher level functionality. The usual tricks involving dirty rectangle tracking and handling, bit blitting bitmaps that have been converted to tie in with the pixel addressing mode, etc.

C# library and example code for this port can be found here and here. It's also over on here.

With the arrival of a second Protoshield this week, I'm now moving on to look at the IMU side of Burt.

Saturday, 5 February 2011

Sparkfun WiFly shield with FEZ Domino

After getting the Motor Controller interfacing completed I decided to join the few others that were developing an interface between the FEZ Domino and the Sparkfun WiFly shield.

The class libraries and firmware from GHI and Microsoft are limited in what devices they support. Unfortunately the WiFly shield is not catered for yet. So we need to create Managed code to drive this shield on the FEZ Domino.

It's a different story with the FEZ Panda and the ability to add Native code to custom firmware (at the expense of GHI Native code assemblies). I'm curious as to whether the Panda can have a TinyCLR build reflashed via JTAG and OpenOCD considering Code Read Protection is enabled in the LPC2388. You can bypass this procedure and purchase a CRP disabled board straight from GHI.

The first step was to make the WiFly shield pin compatible with the FEZ Domino. Others on the forum had found a number of ways to do this. I opted for adding a diode between the 5V and Vin pins. This would allow me to use USB to power the Domino and Wifly shield, plus the option of running the Domino from an external power source.

The next step was to sort out the code to handle the SPI to UART bridge. Getting the signal and startup sequence nailed others had managed to deal with. So it was fairly quick to get the WiFly-GSX chip into it's command mode.

Once in command mode the lengthier task was then getting the UART to talk properly, and deciding what state to get to with the WiFly-GSX initialisation and WLAN connection configurations.

I created a custom class library for all of this. This source code, and example usage code, can be found over at (Sparkfun WiFly shield with FEZ Domino).

FEZ Domino

A few months ago now I was drawn to the relatively new Arduino semi-compatible boards capable of running .Net MicroFramework managed code. With a rich feature list I opted for the FEZ Domino and grabbed one from a local supplier. Curious to see how an ARM core would handle the CLR and managed code.

The design of the Domino is very nice. There are key differences between it and an Arduino, particularly on the IO lines. So you need to be wary when using Arduino shields with the Domino.

As for key features, here is a list from the FEZ Tutorial PDF;
  1. Lowest cost at available features!
  2. Runs Microsoft's .NET Micro Framework 4.0.
  3. Uses Free Visual C# 2008 express.
  4. Run time debugging over USB or serial.
  5. Program in modern managed language.
  6. 32-bit ARM processor, running at 72Mhz.
  7. FAT file system for storage on SD cards and USB memory devices.
  8. Easy upgrades to high end systems like ChipworkX or Embedded Master.
  9. The FEZ core, USBizi, is widely used in commercial applications around the world.
  10. RunTime Loadable Procedures
After using Microsoft Visual Studio products for over a decade. One beautiful feature is the use of the free Express Edition as an IDE, and single-step debugger! As well as a feature rich class library in the Microsoft .Net MF framework.

My first task was to develop the interface between the SparkFun ROB-09571 Motor Controller and the FEZ Domino. This turned out to be incredibly easy thanks to the breakout of a second UART to the Domino's EXT edge connector. Three female to female connecting wires hooked up TX, RX, and Gnd. The Domino's System.IO.Ports.SerialPort class can then be used to setup and communicate with the Motor Controller. I also hooked up digital pin 10 (FEZ_Pin.Digital.Di10) to the reset line on the Motor Controller. The MotorTest Visual C# solution can be found here (revision r62).

Modified firmware for the Sparkfun ROB-09571

The Sparkfun Serial Controlled Motor Driver contains adequate firmware code for most purposes, but is begging to be tweaked.

The latest version in my GoogleCode SVN repository can be found here (revision r59).

Changes in this firmware are;

  • CURRENT_THRESHOLD has been increased from 150 to 300
  • Motor current monitoring interrupt code now changes the Sense LEDs based on the ADC
  • The command buffer has been modified to accept 'b' as a command (Used to start both motors at a specified speed and direction)
  • The speed command is now 16 bits. It is decoded into the OCR1 register directly.
  • The UART reply from a command now passes back both Sense current readings from the ADC.