Hi,

We've posted a beta mbed library v29 at http://mbed.org/projects/libraries-testing/svn/beta

The main highlights are:

• Ethernet driver supporting 1500 byte MTU
• Updated to CMSIS version 2.0 (enables us to use the new CMSIS DSP Library too)
• Minor fixes; SerialHalfDuplex, I2C, C++ Typedefs and CMSIS DMA structure

If you want to test the library, just delete the "mbed" library amd choose "Import Library..." with the URL as http://mbed.org/projects/libraries-testing/svn/beta

I've also published a version of the CMSIS DSP Library that will work with this update that can be found here:

The auto-documentation is pretty comprehensive, but hard to find with our current indexes, so here are the functions available:

Note it is currently an uncompiled library so is not the fastest to build, but gives an early opportunity to explore running DSP functions on mbed. For more information on this library, you can visit http://www.onarm.com/cmsis/

Please report any problems you find with this library, and we'll aim to finalise and mainline it over the next couple fo weeks.

Simon

Hi Simon

I made a comment on the amount of main memory that disappears when you use the new libary with the NetServices stack. Could you investigate? There's a good chance that lots of programs will break if they run out of memory - the NetServices "hello world" test is fairly light.

Thanks Daniel

Hi Daniel,

I just had a look at the NetServices example code you posted, and confirm I got the same results as you. Looking at the NetServices driver you are using, I found it sets its own MTU in drv/eth/eth_drv.cpp, so I changed that to 1500 to match and got different results again (7.5k).

From a static/mbed library point of view, the new ethernet driver uses more of the ethernet ram block, but this doesn't directly impact main memory allocation. And if any user code is forcing memory allocation in to the ethernet ram alongside the driver code, it will either fit or fail at link time.

What perhaps may change is the response of any networking stack above it based on it not fragmenting packets etc. I don't believe the NetServices code to be that efficient anyway (I don't know that codebase), and I expect the different behaviour is it allocating different buffers based on the improved/different network performance.

Definitely worth some more investigation.

Simon

Hi,

This beta is now updated to also include:

• V1.09 of the LPC17xx.h file
• A faster and more noise-resistant AnalogIn implementation

The second item looks to improve the usability of AnalogIn for quick prototypes. A number of threads have shown that the it is possible to get occasional spurious readings from the ADC, particularly when using breadboards, long wires or other power-hungry devices alongside. In a quick prototype, it is nice not to have to worry too much about this, so the beta speeds up the ADC read times whilst also performing a 3-point median filter. The result is a faster AnanlogIn implementation with good noise rejection.

Here are some example results using a potentiometer and long wires on breadboard to pick up spurious results using the current libraries, and the corresponding readings with the beta library:

The beta library is available by importing http://mbed.org/projects/libraries-testing/svn/beta in place of the usual mbed library.

Simon

Thanks Simon -

This is terrific news that we're getting the DSP library! I loaded and compiled it, and as you say the compile is pretty slow, so I'll wait until release to evaluate. The mbed runs so fast (especially compared to a 8-bit 20 MHz uC) that you can run significant DSP. How about a Cortex-M4 and a small M0 mbed next, to hit both high and low apps?

BTW I've just posted a tutorial on hooking up the QuickFilter QF1D512 FIR coprocessor - this is a great single purpose device, and works especially well if you are running high data rates or complex filters. The CMSIS DSP library has many more features, but of course it run in software.

...Tom

Simon,

Are the spikes gone because of the new AnalogIn implementation, or is it because of the median filter? Or both? I can't wait to try v29.

Hi Igor,

It is because of the median filter. I think this is actually a nice solution to allow sub-optimal analog input circuit prototypes, whilst getting solid results at a good speed.

Simon

Good day Simon

Can I improve my ADC results by only using the new beta version of Analogin.h or must I import the whole v29 mbed library? I would like to minimise my risk by not trying to use too many untested code.

Thanks for all the hard work.

Hannes

I have been playing around with the lwIP network stack and trying to learn more about how to use it and one of the recent things I have been looking at is memory usage, to see how it can be tweaked for particular applications. That put me on the track of doing some more investigating into what actually caused the decrease in the free heap size that Daniel saw with the larger Ethernet MTU beta.

Let's start with Daniel's test program here. This version includes the beta version of the mbed library. If I dump the static RAM allocations for this sample I see:

  Main RAM = 11956
  RAM0     = 0
  RAM1     = 13876

Now take the same sample and roll it back to the current mbed library:

  Main RAM = 4916
  RAM0     = 0
  RAM1     = 15556

You will notice that the amount of statically allocated memory in main RAM was drastically increased when you use the beta version of the mbed library. My theory is that the NetServices library wants to place a bunch of statics in the Ethernet RAM bank but the Ethernet layer is using up so much space, it doesn't fit so it ends up rolling over into the main RAM bank instead.

Some additional proof for this theory is when we look at a basic Ethernet sample taken from the API docs themselves to just print the source and destination MAC addresses.

Start with the current mbed library and we see the following static allocations:

  Main RAM = 620
  RAM0     = 0
  RAM1     = 5476

Switch to the beta mbed library and we see the following static allocations:

  Main RAM = 608
  RAM0     = 0
  RAM1     = 10852

If we subtract the 13,876 bytes which did make it into the the Ethernet RAM bank in Daniel's sample using the beta library and the 10,852 bytes used by the Ethernet portion of the beta library itself, we are left with 3,024 bytes. This would suggest that the 3000 bytes of heap (MEM_SIZE) configured for lwIP by lwipopts.h made it into this bank, along with 24 bytes of other statics (probably a few global pointers, etc.) and then the lwIP memory pool (it's largest allocation) ended up getting pushed down into the main RAM bank.

Were you expecting to use up 10.5k of memory out of this RAM bank for the Ethernet code alone or is there a bug which is causing the size to get bloated?

Hi Adam,

Yes, I was expecting it to get bigger. This was a test for maximum MTU just by setting buffers to that size, and partly to understand the dependance of this dedicated memory by other things. I think really the answer is an ethernet driver that properly supports full MTU and allocates the buffers in smaller chunks (lots of packets are a common smaller size), to help keep the size down. Also, some analysis on rate limiting that I think kicks in on the other end if the connection backs up, causing the transmission rate to drop.

I know a few people are playing with this and LwIP, and our focus has been on getting the collaboration tools in place to help support this in particular. But we've also just grown another new mbed team member last week (yay! more on that soon), and they'll be working on some cool new library features and enhancements, so we'll get ethernet back on the list as they get up to speed...

Great analysis btw.

Simon

Simon

Is the analogue input median filter now integrated into the latest mbed library. I have been using this filter for my project and this works very well. However, i have tried using the latest mbed library(revision 28) and beta(revision 29) and it doesnt seem to be working.

I currently use beta - revision 28

Many Thanks

Paul

Hi Paul,

It is not yet in the live libraries, but it should be working on the latest beta (r29):

• http://mbed.org/projects/libraries-testing/svn/beta

Last fix on beta was for CAN member attach, but analog filter should still be functional.

Can you reconfirm that you are actually having problems on the latest beta? It looks fine but we can investigate further if you are seeing problems. I'd like to push this beta live soon, so would be good to understand if there are any issues here.

Thanks,

Simon

Hi Simon,

I can confirm that the latest beta rev 29 is fine, I have retested the app and this works OK. Sorry, must have got betas mixed up when i last tested it

When do you think this analogue filter will be released in the standard library?

Thanks

Paul

Hi Simon

Based on maximum MTU

Hi Adam,

Yes, I was expecting it to get bigger. This was a test for maximum MTU just by setting buffers to that size, and partly to understand the dependance of this dedicated memory by other things. 

Simon

I try mbed HTTP server with EthernetNetIf as following code

EthernetNetIf eth;

int main() {
    pc.printf("Setting up...\n");
    EthernetErr ethErr = eth.setup();
    if (ethErr) {
        pc.printf("Error %d in setup.\n", ethErr);
        return -1;
    }
    pc.printf("Setup OK\n");

    svr.addHandler<SimpleHandler2>("/"); //Default handler
    svr.bind(80);

    pc.printf("Listening...\n");

    Timer tm;
    tm.start();
    //Listen indefinitely
    while (true) {
        Net::poll();
        wait_ms(100);
        if (tm.read()>.5) {
            led1=!led1; //Show that we are alive
            tm.start();
        }
    }

    return 0;
}

and my SimpleHandler2.cpp is as following

SimpleHandler2::SimpleHandler2(const char* rootPath, const char* path, TCPSocket* pTCPSocket) : HTTPRequestHandler(rootPath, path, pTCPSocket)
{}

SimpleHandler2::~SimpleHandler2()
{
  DBG("Handler destroyed\r\n");
}

void SimpleHandler2::doGet()
{
  DBG("In SimpleHandler::doGet()\r\n");
  const char* resp = "Hi Due !";
  //char buf[1700];
  
  //allocate size of readable data
  char* buf = (char *) malloc(sizeof(char) * 1700);
    
     
  int i;
  for (i=0;i<1000;i++){
    buf[i]='a';
  }
  for (i=1000;i<1400;i++){
    buf[i]='b';
  }
  for (i=1400;i<1500;i++){
    buf[i]='c';
  }
  for (i=1500;i<1540;i++){
    buf[i]='d';
  }
  for (i=1540;i<1600;i++){
    buf[i]='e';
  }
  
  
  setContentLen( strlen(buf) );
  //respHeaders()["Content-Type"] = "text/plain; charset=utf-8";
  respHeaders()["Connection"] = "close";
  //writeData(buf, strlen(buf));
  eth.write(buf, strlen(buf) );
  
  DBG("Exit SimpleHandler::doGet()\r\n");
  free(buf);
}

void SimpleHandler2::doPost()
{

}

void SimpleHandler2::doHead()
{

}

  
void SimpleHandler2::onReadable() //Data has been read
{

}

void SimpleHandler2::onWriteable() //Data has been written & buf is free
{
  DBG("SimpleHandler2::onWriteable() event\r\n");
  close(); //Data written, we can close the connection
}

void SimpleHandler2::onClose() //Connection is closing
{
  //Nothing to do 
  close();
}

When I browse to mbed HTTPserver on http://ip.mbed.x.x/SimpleHandler2. My browser can show up aa...bb...cc..and dd that it. I capture tcp with wireshark. It show a MSS=536 and it send only 3 segment and stop. But the data in TCP still has more dddd...and eee not even send out.

Do you have any advice how I can send many segment of TCP to get through to print all aaa...to eee..?

I imported this on my project but still I cannot ping the mbed with a payload of more than 722 which works out to be 768 byte frame (including L2, L3, L4 headers). Wireshark doesn't even see a ping reply packet coming from the mbed. This lead me to believe that Im still using a 768 byte MAXF.

Is there a special method of importing this beta library?

Thanks

Hi Herson,

The latest checkin is actually only half mtu, as a few people were concerned about larger Ethernet ram usage, so is disabled for now. Was just testing some of the other features in the mean time.

You can always pull in a specific version from svn using @revnum at the end of the URL, so if you look at the beta URL you can import one of the older variants to check the 1500 mtu functionality (27) but it will be subject to change.

We'll try and clear this up next week; there have benn quite a few (good) distractions the last couple of months so that has kept us occupied, but you should soon see some of the results of those effort and we'll get back on a few of these backlog items.

Thanks!

Simon

Thanks. Finally got it working.

Im not really concerned on the RAM usage as Im rolling out my own stack on top of the ethernet layer.

Hi Herson

Can you give me some advice how I can modify my SimpleHandler2 that I post in above to work with MTU 1500 byte?

I think your solution may help many people who have the same problem with MSS 768.

Thanks

Unfortunately, the MTU I was talking above only applies to the ethernet layer. TCP/IP is not implemented yet. It just means that I can write raw 1500 byte to the ethernet buffer. I would have to write the TCP/IP stack first.

As for your code, I would greatly consider declaring your buffer as a global variable to give it a fix value. Avoid malloc as it can crash whenever it cannot find enough contiguous memory to fill your need. At least with a pre-allocated global variable, it will always be available for you.

Is this ever going to be released? lol

Is this library still available? I really need to test a program using the ADC and i am not getting enough speed conversion is taking as much as 20uS to make a conversion.

Where can I find this library?

Thanks a lot!