Main Site Documentation

How to fit multiple libraries plus some code on mBuino


#1

Hello folks, I’m trying to put my mBuino to use by combining a few libraries and a bit of code. However, my experiments are not very successful yet. Even at only a few lines of code, I seem to hit the flashmemory limit of 32K.

In this particular case I tried to test my micro-SD adapter. For that I need the SDFileSystem library (imported via this handbook page) and for debugging the USBSerial class from the USBDevice library.

By building example programs using the separate libraries I found the following estimated sizes:
mbed + some code 10.0 kB
USBDevice 7.7 kB
SDFileSystem 15.2 kB
-------------+
Total 32.9 kB

Obviously this is too much for the mBuino flash-memory limits.
Decades ago when memory-constraints were always an issue, I would look for smaller sized libraries that were optimized for size by stripping debug information and unneeded code.

What methods are available on mbed to fit everything on mBuino?
(BTW. I’m using the online IDE)

FYI: this is the minimalized piece of test code I could fit on mBuino. As you can see I had to comment-out all my debug statements to fit it just under the 32K. Unfortunately even this code doesn’t work and gives me the 4-led-error-blink. Perhaps just under 32K is too much, or maybe mBuino doesn’t like my choice of pins.
Edit: the blinking seems size related. Using just the SDFileSystem or only the USBSerial gives me binaries without error-blinks.


 #include "mbed.h"
 #include "SDFileSystem.h"   // see developer.mbed.org/handbook/SDFileSystem
 #include "USBSerial.h"      // see developer.mbed.org/users/mbed_official/code/USBDevice/
 
SDFileSystem sd(P0_21, P0_22, P1_15, P0_11, "sd"); // pinout used on mBuino (MOSI, MISO, SCLK, SSEL)
DigitalOut LED[] = {(LED1), (LED2), (LED3), (LED4), (LED5), (LED6), (LED7)};// the 7 LEDs of mBuino

void BlinkLed(uint8_t nLed, float flDelay=0.1)
{
    LED[nLed] = 1; // turn on
    wait(flDelay); // delay
    LED[nLed] = 0; // turn on
    wait(flDelay); // delay
}

// The USB virtual serial port is used for debugging. Note: driver required, see developer.mbed.org/handbook/USBSerial
USBSerial serialUSB; // Virtual serial port over USB
 
int main() {
    //serialUSB.printf("Hello World!\n");   

    while(!serialUSB.readable()) {
        serialUSB.printf("."); 
        BlinkLed(4);
    }

    //serialUSB.printf("Writing SD dir/file...\n");
    serialUSB.printf("Write");
    mkdir("/sd/mydir", 0777);
    FILE *fp = fopen("/sd/mydir/sdtest.txt", "w");
    if(fp == NULL) {
        //serialUSB.printf("Could not open file for write\n");
        serialUSB.printf("Err");
    }
    fprintf(fp, "Hello SD Card World!");
    fclose(fp); 

    //serialUSB.printf("Goodbye World!\n");
}


#2

An option would be to use the serial port for debugging instead of usb.


#3

Hi @ Gus, thanks for the tip.
That is indeed one solution that crossed my mind. I have a serial cable that I can use in combination with a level-shifter. I could use it for initial separate debugging of the SD card.

However, my eventual goal was to put an ESP8266 module along with the uSD card on mBuino. That module provides a cheap WiFi interface over a serial line. In another test I already managed to get results from the ESP, using the Serial port on P0_19/ P0_18 and the USBSerial for debugging.

Do you have any tips on how I can make the libraries smaller? Am I the first person to hit the flash-memory limits with only two extra libraries on top of the standard mbed plus some code?


#4

Typically, libraries provided by mbed are made to be complete but but made to be small. For example, for the character display we have on some of the boards, we used or own trimmed down version of what we found in mbed’s website. I think we saved around 6kb or even more!


#5

Gus, where you all have libraries, it would be very helpful if you could break those out and share them on the OC code library on the mBed site. I know that we could probably grab the code for the roulette and extract them ourselves, but if the libs are already available, it’ll be that much more attractive for folks considering the platform. I know you can only do so much, given the price point of these devices, but a few more libs and examples (choose a couple of simple scenarios for mBuino, like adding a button and/or a piezo) would make mBuino even more appealing.

Speaking of which…for those of us who are experimenting with mBuino and want to share our efforts, where is the best place to post code for mBuino? Is Codeshare the right place, or should that code go up on mBed.org?


#6

@ devhammer - I think mBed.org is preferable for mBuino code. That way I can import it into online project right away.


#7

Thanks for all replies. mbed.org would indeed be the better place to put your code.

Unfortunately my efforts to using an SD Card on mBuino seem fruitless. Eventually I did manage to cram things into the device, with less than one kB left and still not much actual code.

Along the way I learned how to fix some compilation errors in the libraries I pulled from the repository (e.g. rename ChaN’s files from .c to .cpp to get rid of namespace errors, use update… on all libraries before compilation).

Unfortunately I couldn’t get any of the various SD Card programs or libraries working. Some gave me the four-led-blink; others just hang on the very first call to opendir.

Spending a full day debugging, not getting anything to work whereas it should work from scratch, is not my idea of fun. On Arduino and Spark my time was spent more successful and the SD libraries all just worked. So I guess I should count my blessings an hope for someone else to get SD cards working on mBuino. Maybe mBuino is more suited for sensors and other stuff. I’m done for now. Time to move away from the bleeding edge and to move on to other things.

Thank you all for sharing your knowledge, skills and experience…


#8

@ maxint - I feel your pain. Struggling to get an accelerometer working myself. Doesn’t help that C++ is not my native tongue. :slight_smile:

I view mBuino as a learning platform, so that gives me a little more tolerance for the pain, but I can totally understand your decision.


#9

I have the SD card working on an LPC1768 let me try on a mBuino.


#10

@ devhammer - Thanks! I follow your topics and where possible I’ll try to help. I haven’t tried an accelerometer myself yet, but still intend to test some other sensors I’ve got laying around (e.g. temperature and moisture) in combination with the NRF24L01 wireless communication module. For me it’s also partly about learning, but coming from Arduino and the Spark platforms I expected the libraries and programs in the repository to work without too much hassle. Setting pin configuration is fine ofcourse, but debugging libraries isn’t really my idea of fun. Good luck with your experiments!

@ DaddyOh - Cool! I’m looking forward to see you succeed and find out what went wrong on my part. Good luck!


#11

@ maxint

what SD card breakout are you using? I’m taking most of this comimg week off so will test it during the break.

Eric


#12

@ DaddyOh: my adapter is like this diy uSD adapter. Dirtcheap materials, required some work, but functions flawlessly on the Spark Core. I used a 4Gb uSD card without any problems and checked the card is still okay.

BTW. This morning I successfully tested two nRF24L01-equipped mBuino’s using the cookbook program, so my SPI-interface works.(Big relieve: it didn’t require any debugging).

I also did more debugging on the SDFileSystem library and saw that it already times out on the very first SPI command. It appears there’s something wrong in the communication. I tested with a changed frequency, but that didn’t fix it. At the moment I’m left clueless, so any help is much appreciated. If you could confirm any of the examples working on mBuino with your own adapter, or post a working program of your own, that would already be a step forward. Thanks in advance…


#13

This may or may not be a complete tangent, I’ve not tried an SD card on an mbuino but on other mbed devices I have seen some very weird SD card issues if the power supply to the SD card isn’t quite good enough.

I’ve had it all startup fine on some cards and not on others, I’ve also had it completely destroy the filesystem at random when writing data.

Those problems were improved by added a cap between Vcc and GND right on the card socket but in the end I had to supply the card from a different source (some mbeds can supply a lot of current on their 3.3V out, others it’s purely a reference and the voltage drops if you pull 1mA)

The Mbuino Vcc is on the low side to start with which would make it more prone to this sort of problem.


#14

@ AndyA - Thank you for that tip.
Although I didn’t think of it, coincidentally I did hook it up to a separate 3.3V breadboard power-supply (mainly to supply sufficient power to the ESP8266) and connected the grounds. In my last experiments I removed the ESP, so there should be more than enough to power the uSD. Maybe I should check once more and test out a smaller size card (if I can find one).

Lately I had good (although not perfect) results connecting an nRF24L01 module directly to mBuino’s SPI and 3V3 pins, so luckily mBuino supplies more than just reference power.
On the Spark I powered the SD card directly and had no problems with data corruption, but thank you for the warning.


#15

@ AndyA What would be a suitable value for a cap between Vcc and GND?


#16

the value is probably not overly important, but if possible you can try with both a 0.1uF and a 1uF to cater for most possibilities. That type of capacitor is typically called a filter cap, and will probably tell you about what its role is… SD cards are notorious for having a high inrush/startup current draw, and many don’t handle voltage fluctuations very well. In this case, a capacitor close to the power input in your SD card module will help remove some of the voltage noise and allow it to start more effectively.


#17

maxint

I was not able to get my SD card to work. I will try again when I have more time.

Sorry for the delay. I have too many projects and too little time. LOL.


#18

@ DaddyOh: that 's a pity… Thank you for trying.

Perhaps one day someone else succeeds and can post his findings…
For now I’m back on an arduino project.
So much to do, so little time…