The Board

The system comes shipped as a bare board – so I need to get some self adhesive rubber feet for it really – I will also keep my eye out for a potential case as well.

The main components is a Xilinx Spartan FPGA. The whole thing is based on the SUMP FPGA base logic analyser – so no big surprises that this is the main work horse!

It also has a Microchip 18F24 which looks like it is handling the USB interface.

The board also has several non-populated through hole headers which are for PIC ICSP, FPGA JTAG and some kind of expansion pins (as well as a set of four labelled TRG1 CK1 TRG0 and CK0). There is also a populated set of ROM ISP headers and what looks like some UART pin headers.

Alongside all this we have a number of indicator LEDs for ARM, Trigger, Power and USB Activity. Also some buttons for update and reset actions.

At the end of the board we have the analyser bus. This has a GND connection at both ends and 16 signals available for connecting flying leads to. The signals are fed into a LCX16245 – which is a low voltage bidirectional buffer (so in theory the FPGA could drive the the signals out if you wanted to re-purpose the board!)

Anyway, for more detailed information on the project see the Gadget Factory page – this has the user guide, schematics, board design and software on it as well as installation videos and a video tutorial on UART analysis (something I will be trying soon!).

Installation

Once I had dug out a USB A to Mini-B cable and downloaded the software I was set to go. I had tried getting it to run on Linux (Ubuntu 10.04), but I gave up after about 20 minutes of fiddling and getting nowhere and decided to revert to good old windows XP – so if anyone has any easy to follow instructions on that one let me know!

After extracting the archives I plugged in the device, at which point windows requests a driver. Find the inf folder from the OpenLogic binaries archive, select that and the correct driver will be installed. This creates a virtual COM port. The number of the COM port can be found in the Device Manager (it is the one with Manufacturer = “Microchip Technology, Inc.” and Location = “Location 0 (CDC RS-232 Emulation Demo)”).

Once this is installed run the OB_Logic_Sniffer.exe file and you get the client.

Select Device -> Capture and you get the Capture setup menu. This enables you to setup triggers, sampling rate and recording size.

Testing

To test it I grabbed my XMOS XC-3 and connected 8 of the the lines to the GPIO port (XS1_PORT_8C on Core 0). I wrote a simple XC program to simply count up in a sequence continuously in a loop at 25Mhz. Here is the setup I used for testing.

After fiddling around wondering why Bank 1 wasn’t working, I enabled all the banks and discovered that the signals were on bank 3 (channels 16 -24). I have no idea why this is… but hey ho. It is working and the output is below.

Conclusion

Overall this has the all the makings of a strong tool. It is very affordable @ $45 shipped (available from Seeed Studio) and 16/32 channels of logic analyser @ 100MSPS is certainly not to be sniffed at.

Quality of the software is one of the most important things in a logic analyser as without good analysis software they are a waste of time. The Logic Sniffer doesn’t disappoint in this area- It has the capabilities to do simple single trigger or a complex 4 stage triggering and the analyser Java based client is easy and intuitive to use. While basic in the professional logic analyser world they are pretty good for most peoples needs. Extension of the triggering modes would be well worth the development time. Also simple improvements such as the ability to type in Hex values would be nice, rather than having to build a trigger mask with tick boxes.

Alongside the triggering features is the systems ability to analyse SPI, I2C and UART signals. Expanding this protocol analysis is something that should be actively worked on, though it has a good base (these features will hopefully be subject to another review at a later date).

However, the project in its entirety is currently it is a little rough around the edges. A couple of pointers for simple improvements would be:

• an integrated installer – especially the windows stuff. It’s a small point, but they aren’t hard to make and it makes the whole software installation process a lot less painful (rather than downloading two zips and having to extract them!)
• a simpler firmware upgrade process ( i.e. more integrated PC side software) – the current one looks fairly daunting (even for someone like me who is a relatively experienced user of embedded hardware).

Over all, as an open source hacking tool, I would give this project 8/10, a few minor improvements would push it up. Open source hardware like this can be functionally good, but is often let down by the lack of polish in the user experience.

Firstly, I go to the XMOS website and get the UART code and play around with it to create the UART code I want (RX only at the moment), compile it and give it a run.

But it’s never that simple! All I get are null characters. Odd I think – so I recheck the wiring, recheck the code. All seems to be ok.

So I strip down the code to a really simple function- one that just receives a character and prints it out (see the Super Simple UART receive function source file)

I still get null characters – maybe I got the wrong pins? Check again… nope, seems fine. So I decide its time to void the warranty (follow these CC128 teardown instructions at your own risk!).

Turns out there is a bit of solder between a via into the ground plane and the UART TX pin on the RJ45 connector (pin 8). After removing this I connected the XC-3 back up to the device and wah lah- it gives me the first character (a ‘<’) of the XML data string.

Now to get the whole string out – so off I go to re-implement the more complex UART code.

After some battling I got it running!

The output looks like the following is in line with the CC128 XML documentation.

Next time… parse the XML and output to somewhere a little more useful!

But that’s boring – time to start hacking!

So, first thing I need is the interface cable. The back of the unit has a handy RJ45 connector that has serial in it (see my initial energy monitoring post). This needs connecting to my XC-3 kit so that I can begin to get the data out of it. So time to get the soldering iron out!

So, initially all I need are two wires from the RJ45 network cable (standard network wiring configuration)-

• Brown = the UART transmit (from the energy monitor)
• Blue = ground

I soldered the rest of them onto the strip board in case I wish to use them later and it keeps things neat and tidy.

For the moment I am using the the GPIO port on the XC-3, using pin 1 for a 1 bit port (XCore UART RX) and pin 16 is ground. This should give a good base from which to work. Eventually I would like to put it on the LED connectors to keep the GPIO free. The other bonus of using the LED connector is that the output side is buffered up to 5V which is what the UART on the energy monitor needs – though I think I will have a check of the Microchip PIC they use inside and see if it will take 3.3V logic levels.

Next time… getting data into the XC-3

My thought is to use my XC-3 (or maybe get an XC-2) to connect to an energy monitor receiver – or hack/make a receiver and then push the data somewhere useful via Ethernet. In fact I could combine it with my network monitor, ditch the screen and have it push the all the different types of data out into some nice pretty graphs. Anyway, enough brain dump – onto the hardware!

My proposal is to use a Current Cost Envi (CC128) device. There is a helpful CC128 write up from dale lane. It has several nice features:

1. The receiver has a RS232 output
2. The receiver outputs XML from the RS232
3. The system has support for up to 9 individual appliance monitoring (IAMs)

Some thoughts on software/graphing features:

• Display a comprehensive history (device can output real-time, or 2hr block data)
• Calculate some averages (particularly for time of day, month, season)
• Plot electricity use vs. temperature? – the relationship should be pretty obvious… but I like pretty graphs
• Plot the electricity generation stats and calculate my carbon footprint (ooh err!) – see Amee

Could even add some X10 stuff in there to… the possibilities are endless – watch this space!

Update: CC128 connector pinout- looks like you might be able to reprogram the internal PIC as well!

1) Laser Cutter

Not massively complex in terms of software – but a pretty cool outcome. UART in – granite engravings out! Nice… Maybe an ethernet interface with a web client to upload images into it could come next… laser engraver source code here

2) Aquatic Bot Explorer (ABE)

The main purpose of the project it’s to create an autonomus vehicle to explore lakes and reefs. Aquatic Bot Explorer (ABE) its based on a ROV (Remotely Operated underwater Vehicles ) and AUV (Autonomus Underwater Vehicles ) class robots.
This bot it’s powered by an XK-1 processor by XMOS, several boards for sensing: pressure, temperature, depth, etc. Motor control, demux, ADC, etc. are developed.

Looks pretty cool… can’t wait to see what it turns up from the depths!

So I thought I would do option (2) as option (1) is too easy in the XMOS architecture and its not very efficient if I want to run 1MIPs processes on a thread that has 50MIPs available. The code for this is freely available from the virtual threads sourceforge page.

More information after the break…

The base of the system is simple context switching within a single thread – this allows multiple processes to be run on a single thread. The current implementation has only time-slicing for processes and doesn’t currently have any way to handle events, ports or channels in a sensible way. Hopefully this soft of thing will be implemented when I spend some more time on the project.

The tricky things to handle are those which I haven’t implemented yet… The risk of deadlocking the whole lot of virtual threads is quite high when working with events or waiting for external stimulus. Essentially a carefully implemented library would have to be used to stop this, but still provide the level of functionality you get using the hardware threads.

Its probably fairly safe to assert that the virtual threads will not ever be able to be as functional as the hardware threads.

So, a summary of current features:

• Able to start an arbitrary number of virtual threads
• Simple time sliced context switching of virtual threads
• Ability to disable the interrupt for atomic operation

Future features:

• Context switch on external stimulus
• Context switch on demand (so a virtual thread can “release” itself from the current hardware thread)
• Implementation of access to events, channel comms, hardware
• Call to allocate stack space to vthread
• More flexible vthread params (ports, chans, etc)

More information and pictures after the break…

The basic premise of the system is that data comes in and then goes out the other side (to general traffic the device looks like a wire) and information about that traffic collected on its way through (so at the moment it just looks at packet byte length). The data is then aggregated appropriately with the throughput being averaged over a second (sample at an interval of 100mS).

The information as well as being displayed on screen (via a simple I2C bus) is stored to an SPI flash once every 10s. This is so that if power is lost then the logged data is not.

Current Feature Summary:

• Dual MII ethernet interface
• I2C VFD for showing the resulting information
• Saving of data to on-board SPI flash memory

Future features:

• Internal switch for custom applications (so you can access the device over IP)
• A web interface to allow a user to reset stored data and maybe produce a SVG graph?
• Change display for lower cost, lower power OLED? (Farnell order code: 1498842)

And some pictures:

XC-3 Network Monitor and Display

Network Monitor Display showing a graph and data rates