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:

• http://mbed.org/handbook/m0-release

and the technical details and instructions will live at:

• http://mbed.org/handbook/m0-beta

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

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

Am I missing something? hb

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

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:

00001 #include "mbed.h"
00002 #include "USBMouse.h"
00003 
00004 USBMouse mouse;
00005 
00006 int main() {
00007     int16_t x = 0;
00008     int16_t y = 0;
00009     int32_t radius = 10;
00010     int32_t angle = 0;
00011 
00012     while (1) {
00013         x = cos((double)angle*3.14/180.0)*radius;
00014         y = sin((double)angle*3.14/180.0)*radius;
00015         mouse.move(x, y);
00016         angle += 3;
00017         wait(0.001);
00018     }
00019 }

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

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

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

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.

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

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.

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:

• http://ics.nxp.com/support/documents/microcontrollers/?scope=LPC11U14

Hope this gets you what you need!

Simon

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.

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.

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

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

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.

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

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

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!

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

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

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

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?

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

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

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

Thanks, Sam, I'll have another try.

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

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.

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

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

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

Hi Sam,

I did change the USB connectod and did not notice that the order of D+ D- were swapped. It is working now.

Thanks, Mike