mbed

I dont think this will possible. You would have to use some low level code to modify the baudrate of the lpc1768, which is possible but not as easy as pc.baud(). A bigger problem is that you may also need to update the baudrate on the magic chip. This is the actual interface between your target lpc1768 and the PC USB link. I guess that selecting the (USBTX, USBRX) automatically includes code in the Serial lib that sets both the serial port speed on the target and on the interface chip.

I would avoid all that headache and just use the provided libs. You can easily 'search and replace' printf() for pc.printf() in case you want to port existing code to mbed.

Hi Steve,

As these end up on the same physical UART, you can actually do:

#include "mbed.h"

Serial pc(USBTX, USBRX);

int main() {
    pc.baud (115200);
    printf ("Hello World!");
}

Related to Wim's comment, the baudrate off the interface is actually set by the PC/Terminal program.

Hope that helps,

Simon

Hello,

Thank you for your replies. If it is impossible, I will try to sort it out in the other way. The reason I wanted to change it without using pc.baud() is that I would like to use:

class MYCLASS {
    MYCLASS() {
    fprintf(stderr, "Error msg");
    }
};

in a constructor of my class. fprintf use USB port like pc.printf with the same baudrate, but in the case of fprintf, I don't need to work with Serial pc(USBTX, USBRX) object inside the class. The object of that class is created before main(), where I can use pc.baud().

Serial pc(USBTX, USBRX);
MYCLASS myobject();

main() {
    pc.baud(115200);
}

I could use pc.baud() inside class

extern Serial pc;

class MYCLASS {
    MYCLASS() {
    pc.baud(115200);
    fprintf(stderr, "Error msg");
    }
};

but I would like to avoid it.

Thanks, Michal.

I've also had this problem, initialiser "debug" is rather difficult if you subsequently want a fast data rate. I don't think there is a particularly easy way round on the mbed platform, without having a instance of the class available. It would be nice to see a companion non-class function baud(int rate) to go with printf(...) but I can see this being a bit tricky. Who owns the sample rate control? mbed already allows multiple objects to own the same pins, which can rather confuse matters, so I guess it wouldn't be such a departure...

For now, could you use either a FTDI cable on another serial port (messy) or just make do with 9600 baud? either that or you could change baud mid session on the pc (also horribly messy).

Hi,

You could try something like this:

#include "mbed.h"

void baud(int baudrate) {
    Serial s(USBTX, USBRX);
    s.baud(baudrate);
}

int main() {
    baud(115200);
    printf("Hello, faster world!");
}

This assumes stdout is mapped to the USB UART (which is a good assumption!); However, stdout is really a default output filehandle, so could actually be mapped to a UART, file, or even a dedicated semihosted debug channel, which ultimately why there isn't a generic baud() function.

Ownership is only implemented where virtualisation really makes sense e.g. you can have two instances of a SPI class that map to the same physical hardware, and they will switch "owners" and corresponding configurations as needed (e.g. if the bitrate needed to be updated). For other things where virtualisation doesn't really make sense, the class instancies really jus become proxies for each other. It turned out this was the most useful trade-off between trying to do useful things vs. trusting the user knew what they were doing.

Hope that is useful!

Simon

Hello Simon,

Yes, that is useful. I have put baud(int baudrate) as a class member function and then in a constructor baud(115200);

Many thanks!

Michal.