Fast logic analyser using Cortex-m0 mbed

Page last updated 02 Dec 2011, by Romilly Cocking. 6 replies analyser, logic, USB

I'm prototyping a logic analyser using a beta version of the new mbed Cortex-m0.

I'll write a Python-based app using PyUSB on the PC to capture and present the data.

The new mbed has arrived!

Time to run through the example code.

When I tried the USB mouse emulator example, it worked perfectly.

The sample HID code works, even though I am running the Windows code in a VirtualBox VM.

I'm now reading a set of inputs and sending these in the USB HID report. I'd like to use PortIn but this won't be available on the new mbed for a few days, so I'm using the slower DigitalIn/BusIn for now.

I started by sampling once a second, and using a DIL switch to control the inputs.

I now have a trivial program which captures a byte-wide stream and sends it over USB one byte at a time. I'm extending the Python client to write the output to a file; for my next test I will try to capture an I2C exchange between an Arduino and an LCD display. That should verify that the software is fast enough to be useful.

Now that my USB hub has arrived I have a programming connection to the mbed and a test connection to the USB breakout board. I even remembered to remove the Vcc connection from the breakout board. That would have connected the 5v rails on both USB ports. Probably not fatal, but not a good idea.

I've switched to a Java client on UBUNTU. Performance looked poor, so I changed the mbed code to just send a report without reading inputs via BusIn; the client is receiving about 125 bytes/sec which is very disappointing. This seems to be determined by the mbed rather than the client.

So, on the plus side,

  • the USB HID class has been very easy to use
  • the beta compiler and the m0 have worked well
  • I've gained some experience with the windows Pyhon client and discovered a usable Linux Java client
  • it's worth experimenting with my classic mbed to see if I can drive SUMP using a serial output. (Thanks for the suggestion!)

on the minus side, the protocol seems too slow to be usable in my intended application.

I hope I'm doing something really dumb. Here's main on the mbed:

int main(void) {
    //Fill the report
    send_report.length = 1;
    
    while (1) {
        //Send the report
//        send_report.data[0] = port;
        hid.send(&send_report);
       
    }
}

Update: The original design was too simple: it used 8 of the mbed digital I/O pins to capture the state of a circuit under test, and transferred data to a PC using USB HID to stream the data.

It turns out that the USB HID protocol is easy to use but currently limited to about 64k Bytes/sec. USB bulk transfer looks like a lot of work; I'm taking a look at using good old serial or a TCP socket instead.

6 comments on Fast logic analyser using Cortex-m0 mbed:

Wim Huiskamp
22 Nov 2011

Hi Romilly, I submitted a similar idea for the new mbed. My initial focus would be on monitoring and analysing serial protocols, in particular I2C. Maybe we can work on this together somehow. Dont have the new mbed, but will start looking into possible solutions based on mbed m3.

Wim

Romilly Cocking
24 Nov 2011

Hi Wim,

I'm very happy to cooperate, and glad to have a second mind on this.

I did a very basic I2C monitor with the mbed m3 Poor Man's Oscilloscope, displaying the waveforms on a web page using svg. The project was a bit hurried as it was part of a road test.

I'm hoping to get enough inputs that I can monitor I2C and the pins of an I2C LCD display simultaneously; tghay would be sueful for troubleshooting. But I'm also interested in a good test case which requires faster logic transitions.

I'm not sure yet how fast the USB link will transfer data.

Hendrik Lipka
24 Nov 2011

If you want to have it really fast, I think you need to use a DMA transfer from the GPIO to RAM. In the forums there were some discussions about the speed you can achive with port reads, IIRC it was about 50.000 samples per seconds for the LPC1768.

Second - why don't you use the SUMP protocol used e.g. by the open logic sniffer? It would provide you with a capable client, running on all major platform. The protocol itself is really simple, you would need maybe 50 lines of code.

Romilly Cocking
24 Nov 2011

I'm surprised that port reads would be so slow; 50K Samples/sec sounds like the speed you might get reading one pin at a time, but I may be completely wrong. I should find out quite soon.

SUMP sounds a great idea. Isn't it just for serial comms though? I'm hoping the HID will be faster.

I'll take a look at the protocol spec. Thanks for the suggestion.

Hendrik Lipka
25 Nov 2011

Romilly Cocking wrote:

I'm surprised that port reads would be so slow; 50K Samples/sec sounds like the speed you might get reading one pin at a time, but I may be completely wrong. I should find out quite soon.

I have searched to find the references I had in mind:

The 50k seems to be the worst case when using BusInOut, there are faster alternatives available. But to achieve steady sampling, DMA still seems to be the way to go (it's just easier to get it triggered with a constant frequency).

Romilly Cocking wrote:

SUMP sounds a great idea. Isn't it just for serial comms though? I'm hoping the HID will be faster.

Yes, all the clients use a serial port. But it should be able to speed up to around 1mbit/sec. And when you don't do realtime analysis, the buffer on the mbed is not so large - even with 115000bps the transfer should take longer than a second... And surely there is nothing hindering you from extending the client to work with USB HID (I would suggest looking at JaWi's OLS client, it is actively maintained and fairly easy to modify)

Romilly Cocking
25 Nov 2011

Hendrik, thanks for finding those references. I searched without success (looking for PortIn) so your links are really helpful.

DMA looks very interesting, but (for me) new to learn. I'll get a working version using PortIn, and then take a look at DMA.

I will be using PortIn, not BusIn; the former reads an entire port and masks bits from it, the latter reads each digital pin individually. PortIn should be much faster.

I'll try to measure the speed difference. I will have to use DigitalIn or BusIn for now, as it seems that PortIn is still being ported to the new mbed.

I will take a look at the SUMP code next week. In theory I should be able to replace the serial reads/writes fairly easily. As you point out, that would give a capable client for very little effort.

Since PC time is cheap and the mbed will be the performance bottleneck I will write in the simplest HID protocol I can come up with and use an adapter class on the PC to SUMP-ify it.

Please log in to post comments.