mbed M0 Beta Feedback

02 Nov 2011

Hi,

We've started sending out the first M0 beta boards and are beginning to push parts of the new beta libraries, features and documentation. I've set this thread up for those who are helping out to discuss the beta, and as the place to report bugs, issues and questions etc.

We'll also be putting out a request for specific beta test areas soon, for those who feel they can help out in specific areas.

For the next few weeks, the news will appear at:

and the technical details and instructions will live at:

The main features we're going to be pushing in to beta are:

  • LPC11U24 library and compiler support
  • SDK and compiler export support for uVision, Code Red and GCC
  • USBDevice libraries (Mouse, Keyboard, etc)

Hope it'll be some welcome additions to the mbed tools!

As always, you can always use the support@mbed.org channel if you'd rather provide anonymous feedback.

Thanks, Simon

02 Nov 2011

M0 mbed memory performance:

The program below writes a 2KB block of data to the mbed flash. It takes about 30 seconds to do the write. The same program takes 89 mS on the M3 mbed.

/***************************************************************
* Program m0-memtest (main.cpp)
*
* Test the write timing for the on-card memory
*
****************************************************************/
#include "mbed.h"

// Libraries
LocalFileSystem local("local");               // Create the local filesystem under the name "local"
Timer t;
Serial pc(USBTX, USBRX); // tx, rx


int main() {
    char buf[2048];
    float starttime, duration;
    int index = 0;
 
 
    printf("\r\n\r\n*** Start of M0 memory write test (2K bytes) ***\r\n");

    // Set up the buffer
    FILE *fp = fopen("/local/test.dat", "w");  
    t.start();

    for(index = 0; index < 2048; index++) {
        buf[index] = ~index & 0xFF;                 // Create dummy data
    }
    // Run the timed write test
    starttime = t.read();
    fwrite(buf, sizeof(buf[0]), sizeof(buf)/sizeof(buf[0]), fp);
    fclose(fp);
    duration = t.read() - starttime;       
    printf("Write completed in %f seconds. Average throughput = %f bytes/second.\r\n", duration, 2048/duration);
}

This produces

Quote:

  • * * Start of M0 memory write test (2K bytes) * * * Write completed in 30.069155 seconds. Average throughput = 68.109665 bytes/second.

Am I missing something? hb

02 Nov 2011

Thanks hexley!

This looks like a behaviour of the stdio/semihosting implementation; we'll add that to the list of things to investigate.

Obviously, this is nothing to do with the internal memory speeds of the M0 (stated just to avoid confusion of future readers!)

Simon

02 Nov 2011

Hi,

I've just published a first example program using part of a new USBDevice stack. The first support in this is for USBMouse/Keyboard and a lower level USBHID. More interfaces and documentation coming soon, but incase anyone wants to try it out:

Import program

#include "mbed.h"
#include "USBMouse.h"

USBMouse mouse;

int main() {
    int16_t x = 0;
    int16_t y = 0;
    int32_t radius = 10;
    int32_t angle = 0;

    while (1) {
        x = cos((double)angle*3.14/180.0)*radius;
        y = sin((double)angle*3.14/180.0)*radius;
        mouse.move(x, y);
        angle += 3;
        wait(0.001);
    }
}

Note: you need to import this program and be in betamode (see http://mbed.org/handbook/m0-beta).

Note: It should work the same on both the LPC1768, and the new LPC11U24, so even if you haven't got one of the new beta boards you can try it out :)

For those who keep close eye on the details of NXP chips and delve in to this code, note that the implementation is not taking advantage of the ROM drivers, as our beta chip samples don't contain the ROM.

Have fun! We'll be adding more on these USBDevice drivers over the next week.

Simon

02 Nov 2011

Is there going to be a generic BASIC HID interface, not mouse/keyboard, Especially for the new board, this could be a massive selling point, As very high data throughput is possible, and with this interface,

Which is similar to CAN, opens a wide range if possibilities, Particularly in sensors and the like, Just imagin:

Dozen sensors, each with its own MBED, performing all the Data acquisition, and filtering, on a PCB board, (which will potentially be expensive than the micro !!!!)

Cheers

Ceri

02 Nov 2011

Yep, we'll post an example tomorrow. Currently got it talking to python via HID.

02 Nov 2011

I've reported the issue with the slow local FS too. Hopefully the issue won't be too hard to fix because it's unusable in current state.

Simon Ford wrote:

For those who keep close eye on the details of NXP chips and delve in to this code, note that the implementation is not taking advantage of the ROM drivers, as our beta chip samples don't contain the ROM.

Are you sure? The one in my module definitely has a pointer in the ROM table.

14 Nov 2011

Is there any chip documentation available to beta testers? I'd like to see the preliminary data sheet user manual for the LPC11U24 if possible.

15 Nov 2011

Hi Hexley,

The chip is similar to the LPC11U14, so that would be a great place to start until official documentation is released by NXP:

Hope this gets you what you need!

Simon

18 Nov 2011

I like the USB samples for the mbed-m0 beta. The keyboard and mouse samples from the handbook worked great.

As a simple extension to the absolute mouse sample, I connected a couple of pots to the mbed and used them to move the mouse pointer around on my Windows machine.

Import programUSBAbsoluteMouse

Uses a Sparkfun Thumb Joystick to control the X and Y coordinate returned from the mbed device acting as a HID based absolute mouse.

The main thing I noticed when playing with this code is that the AnalogIn functionality works much better on the LPC11U24 based device. I haven't noticed the glitches that I saw in the past on my LPC1768 based device.

18 Nov 2011

Great! Sounds like etch-a-sketch!

Perhaps you could write it up as a showcase demo for the cortex-M0 board. The two parts of beta testing are test it works and show what you can do with it!

Simon

24 Nov 2011

The examples are working well. The sparkfun breakout board was a welcome surprise. It's fairly clear how to wire it up, but I've given explicit instructions on my beta project page

25 Nov 2011

I'm getting a compile error when I try to use PortIn. Has that not yet been implemented? I can use DigitalIn for now, but will need the speed advantage of a Port Read soon.

25 Nov 2011

Hi Romilly,

Yep, that is correct. We haven't yet finalised implementations of Port or some of the Slave versions of interfaces; they'll be appearing next week. I'll let Emilio update you when they are available.

Glad to see you seem to be getting things running fine! Thanks for your support.

Simon

26 Nov 2011

Firstly, thanks a lot for adding a little USB breakout board to the beta package! It made the "getting started" quicker :)

Secondly, I think on the old mbeds the USB and serial pins are labelled D+, D-, TX, RX etc to match the little credit-card pinout cheatsheet; on the beta board they're just numbered 31, 32 etc. Is this an intentional change? The white-on-yellow silkscreen can also sometimes be a bit hard to read.

Regarding the USB libraries, I've so far only experimented with the USBSerial one, which seems to work fine as long as you use scanf; I'm getting the following compiler error when trying to use serial.read:

    USBSerial serial;
    char buf[128];
    serial.read(buf,12);
""USBSerial::read" is ambiguous" in file "/main.cpp", Line: 22, Col: 11

I've tried using other buffer types, too. I just ended up using scanf like in the examples, so it's not a problem, but thought to mention it anyway; I think it's probably to do with the multiple inheritance...

30 Nov 2011

Hello,

First I would like to say I really Like the mbed products and how well they work. And the web compiler is a great idea.

I wrote some code that tries to use p33, p34, p35, and p36 and I get the error "Identifier x is undefined" x being p33-p36. I am assuming that they have not been implemented yet. I will use four other pins for now but I want to ultimately use those pins later.

Thanks, Michael

30 Nov 2011

I've got a minimal HID Java client running on Ubuntu 10.04 using http://code.google.com/p/javahidapi/. At present it requires manual tweaking of usb permissions; I'll post more info on my notebook page when I have a working udev rule, and will post a brief link here.

I still have no idea how fast I can capture/transfer data, but getting the mbed code capture/HID working has been very easy. I'm still using BusIn, and looking forward to hearing from Emilio when PortIn has been ported!

30 Nov 2011

More info on Ubuntu, what package are you using ?

I have been told that QT might work ! And it is cross platform as well !!!

Cheers

Ceri

30 Nov 2011

Hi Ceri,

Doh! I couldn't remember the name of the project I was using, (having looked at loads), left a blank, and forgot to fill it in before posting. Multiple senior moments. I've now edited the post and added the project info.

Cheers, Romilly

30 Nov 2011

I've added a notebook page about the java HID client that I'm using.

01 Dec 2011

I can't get the USB HID interface to send at much more than 125 Bytes/sec. Admittedly I am using a report length of 1, but even so that is very disappointing. I've listed the main method on the relevent notebook page; I hope someone will spot that I'm doing something dumb. Or is this due to the standard poll delay of 10 ms I can see in the HID code?

01 Dec 2011

the simples solution would be to sen 2 4 8 30 64 bytes,

but less often.

Somewher in the back of my mind ... PC only poles USB every mS

if i get a chance, i will have a go myself.

Do you nee constant data flow, or are you sending blocks ??

Cheers

Ceri

01 Dec 2011

Hi Ceri,

Larger blocks won't give more than a 64-fold improvement, and the speed would still be way slower than I was hoping for. I might as well use Serial, which would make it easy to use SUMP client.

I was hoping to avoid sending blocks as this would make the code rather more complicated.

I'm pretty sure there is anything in the current Java code on the PC that would limit the polling speed, but I will take a look at the source for the underlying C library.

Cheers, Romilly

01 Dec 2011

Hi Romilly,

I just pushed a new version of the USB device library. Now I can reach 1000 packets/s. I just modified as you mentioned before the bInterval (now it's 1 instead of 10) field in the endpoint descriptor.

Cheers,

Sam

01 Dec 2011

Thanks, Sam, I'll have another try.

01 Dec 2011

I now get 1000 packets/s too. Thanks for the update.

02 Dec 2011

I'm abandoning the USB HID route for now, and will look at using Serial output or a TCP socket.

Once that's done, I have another project for the m0 - a port of an Arduino microwriter clone. It would make good use of the USB keyboard interface.

02 Dec 2011

Hi Romilly,

Good idea to try the Serial. I did some tests this morning and I am able to send 9000 packets of 64bytes /s. For that I have added a function in USBSerial (writeBlock(buf, size)). If the size is not 64 (the maximum length of the endpoint), the host doesn't request several packets per frame. So I advice you to use 64 bytes packets :)

Sam

06 Dec 2011

Hi,

I used the USBDevice library a week or two ago with the Hello world example code and it worked just fine. Now I get device drive not sucessfully installed. I tried uninstalling the usb device and restart or repower the circuit and get the same results. My os is win7 home premium. I have tried it on another computer with the same results. I am not sure what changed in the library.

Thanks for any help, Mike

06 Dec 2011

Hi Mike,

I tried with all Hello World programs (after having updated the USBDevice library) and I have no problem. Have you changed something in your hardware ? I don't think that it is an OS problem because it was working before.

So for the moment, my advice are:

  • check your hardware.
  • if you have a program that was working before (version control), can you try and see if it works

Hope that your problem will be solved

Sam

Please log in to post a reply.