MODSERIAL

ยป Import this library into a programMODSERIAL

Bug fix release

MODSERIAL is an easy to use library that extends Serial to add fully buffered input and output.

The features of MODSERIAL include:-

/media/uploads/mbedofficial/serial_interfaces.png

Connecting up the MODSERIAL module

The starting point for using MODSERIAL is the Mbed's own handbook for Serial library object. MODSERIAL inherits Serial and adds extensions for buffering. So getting started is easy. Follow the Mbed instructions for Serial to get setup. Here's a reproduction of Serial's simple code starter:-

1  #include "mbed.h"
2
3  Serial pc(USBTX, USBRX); // tx, rx
4 
5  int main() {
6      pc.printf("Hello World!");
7      while(1) {
8          pc.putc(pc.getc() + 1);
9      }
10 }

All we need to do to use MODSERIAL is to add a #include and alter one line thus:-

1  #include "mbed.h"
2  #include "MODSERIAL.h"
3  MODSERIAL pc(USBTX, USBRX); // tx, rx
4 
5  int main() {
6      pc.printf("Hello World!");
7      while(1) {
8          pc.putc(pc.getc() + 1);
9      }
10 }

As we can see, all we have done is add the header at line 2 and changed line 3 to specify the use of MODSERIAL in replacement for Serial. The default settings for MODSERIAL are that both the TX and RX buffers are assigned 256 bytes each of storage space. This storage space is acquired from the heap using malloc.

The default buffer assignment can be manipulated in three ways. First is the compile time setting which alters the default parameters used when creating a MODSERIAL object. This is done thus:-

1  #include "mbed.h"
2
3  #define MODSERIAL_DEFAULT_RX_BUFFER_SIZE 512
4  #define MODSERIAL_DEFAULT_TX_BUFFER_SIZE 1024 
5  #include "MODSERIAL.h"
6
7  MODSERIAL pc(USBTX, USBRX); // tx, rx
8  ...

By defining the two #defines before the #include "MODSERIAL.h" alters the defaults MODSERIAL uses to create it's buffers.

The second method is the run-time version. To get TX at 1024 and RX buffer at 512 as above during run-time initialisation, alter the constructor thus:-

1  #include "mbed.h"
2  #include "MODSERIAL.h"
3
4  // Make TX buffer 1024bytes and RX buffer use 512bytes.
5  MODSERIAL pc(USBTX, USBRX, 1024, 512); // tx, rx
6  ...

If you supply only one numeric value, as shown below, both TX and RX will have the same buffer sizes assigned to them:-

1  #include "mbed.h"
2  #include "MODSERIAL.h"
3
4  // Make both TX and RX use a 512byte buffer.
5  MODSERIAL pc(USBTX, USBRX, 512); // tx, rx
6  ...

The third method is reassigning a new buffer while the program is running. This allows the program to grow and shrink either buffer as required. However, there are caveats to do this as will be shown below.

First, expanding the buffer involves increasing the buffer size. This is fairly straight forward and is accomplished thus:-

1  #include "mbed.h"
2  #include "MODSERIAL.h"
3  MODSERIAL pc(USBTX, USBRX); // tx, rx
4 
5  int main() {
6
7      // Increase the TX buffer from the default 256bytes to 1024bytes.
8      if (pc.txBufferSetSize(1024) != MODSERIAL::Ok) {
9         error("Failed to allocate memory for new buffer");
10     }
11
12     pc.printf("Hello World!");
13     while(1) {
14         pc.putc(pc.getc() + 1);
15     }
16 }

As can be seen, growing the buffer is fairly straight forward. However, how it is done should be understood by the user. First, a new buffer allocation is made using malloc. Once acquired the current buffer is checked for contents. If the current buffer is not empty it is copied to the new buffer so the old buffer contents is maintained after resizing. The last step is then to free() the old memory buffer.

The buffer can also be contracted to a smaller length buffer. Here's the code:-

1  #include "mbed.h"
2  #include "MODSERIAL.h"
3  MODSERIAL pc(USBTX, USBRX); // tx, rx
4 
5  int main() {
6      int result;
7
8      // Decrease the TX buffer from the default 256bytes to 32bytes.
9      result = pc.txBufferSetSize(32);
10     if (result != MODSERIAL::Ok) {
11         switch(result) {
12             case MODSERIAL::BufferOversize: 
13                 error("Contents too big to fit into new allocation");
14                 break;
15             case MODSERIAL::NoMemory: 
16                 error("Not enough memory for new allocation");
17                 break;
18         }
19     }
11
12     pc.printf("Hello World!");
13     while(1) {
14         pc.putc(pc.getc() + 1);
15     }
16 }

Since buffer resizing involves the copying over of any existing old buffer contents the possibility exists that the current buffer contains more bytes than will fit into the new requested buffer. In these conditions the user must handle the return value of the resize functions. If the contents are of no concern then calling txBufferFlush() to empty of the contents before resizing.

MODSERIAL Interrupts

Users of Serial will be familar with the fact that you can attach functions or methods to TxIrq or RxIrq. This attachment of callbacks allows users to have Interrupt Service Routines (ISR) for both the TX and RX channel of the Uart. MODSERIAL uses both of these callbacks to maintain it's buffers and so are not available to users. However, MODSERIAL does contain five potential callbacks the user can use. These are:-

  • TxIrq - This callback is used to inform the user's program that a character was transferred from the TX buffer to the Uart's TX THR FIFO.
  • RxIrq - This callback is used to inform the user's program that a character was transferred from the Uart's RX FIFO RBR to the RX buffer.
  • RxOvIrq - This callback is used to inform the user's program that a character in the Uart's RX FIFO RBR failed to transfer to the RX buffer because the RX buffer was full. The failed byte is availble via xxGetLastChar() methods.
  • TxOvIrq - As RX overflow above
  • TxEmpty - This callback is made when the last byte in the TX buffer is transferred to the Uart's TX THR FIFO. It informs the user's program that the TX buffer has become empty. However, it does not mean transmission is complete. See the example1.cpp example for more information.

Delineating "packets"

Many devices send information on RS232 interfaces in distinct "packets". As an example of this is NMEA information sent by many GPS modules. Each NMEA sentence is delineated by a '\n' newline character. Each sentence can be of vary length depending upon the information being sent, however, all are seperated by a '\n' newline. Detecting this if very simple with MODSERIAL. Here's an example:-

#include "mbed.h"
#include "MODSERIAL.h"

// Connect the TX of the GPS module to p10 RX input
MODSERIAL gps(NC, p10);

bool newline_detected = false;

// Called everytime a new character goes into
// the RX buffer. Test that character for \n
// Note, rxGetLastChar() gets the last char that
// we received but it does NOT remove it from
// the RX buffer.
void rxCallback(MODSERIAL_IRQ_INFO *q) {
    MODSERIAL *serial = q->serial;
    if ( serial->rxGetLastChar() == '\n') {
    	newline_detected = true;
    }
}

int main() {
    gps.baud(9600);
    gps.attach(&rxCallback, MODSERIAL::RxIrq);

    // Wait here until we detect the \n going into the buffer.
    while (! newline_detected ) ;    
    
    // When we get here the RX buffer now contains a NMEA sentence.
    // ...

}

Note, the txGetLastChar() and rxGetLastChar() methods only return the last character but they do not remove that character from the associated buffer.

If this is your first time using MODSERIAL or would just like to test it out then see the example.cpp that comes with the library.






1 related question:


38 comments:

01 Dec 2010

MODSERIAL is not a proper name for a buffered serial communication because people will associate it with MODBUS SERIAL.

19 Apr 2011

Nice library!

I would like to use the RX callback feature to do basic command line processing such as echoing input and processing backspace (delete last character) and delete (delete entire line). In order to do this, I need to be able to remove a character from the input end of the RX buffer. Is this possible? If so, please explain how.

I can't simply use getc() to read input as my main loop is servicing various events and needs to run continuously.

20 Apr 2011

See getcNb() which is the "non-blocking" version of getc(). getcNb() always returns immediately. Just if the buffer was empty it returns -1 rather than wait for a byte. You could also use readable() which returns true if the buffer conatains bytes of false if empty (or rxBufferEmpty() which returns true if the buffer is empty).

Also, for reasons I don't know, this website doesnt send me an email when people add comments to cookbook pages. So please ask questions in the Formum section where I do get email notifications :)

04 Nov 2011

Thanks for your hard work on this.

11 Dec 2011

Thanks for the nice lib!

Elias

04 Jun 2012

Thank you, with this library have not had any problems with the function attach.

25 Jun 2012

I am using MODSERIAL library in my code and I keep getting the following errors while compiling my code: "identifier "LPC_UART0" is undefined" in file "hello/lib/MODSERIAL/INIT.cpp" "identifier "LPC_UART1" is undefined" in file "hello/lib/MODSERIAL/INIT.cpp" "identifier "LPC_UART2" is undefined" in file "hello/lib/MODSERIAL/INIT.cpp" "identifier "LPC_UART3" is undefined" in file "hello/lib/MODSERIAL/INIT.cpp" "identifier "UART0_IRQn" is undefined" in file "hello/lib/MODSERIAL/MODSERIAL.cpp" "identifier "UART1_IRQn" is undefined" in file "hello/lib/MODSERIAL/MODSERIAL.cpp" "identifier "UART2_IRQn" is undefined" in file "hello/lib/MODSERIAL/MODSERIAL.cpp" "identifier "UART3_IRQn" is undefined" in file "hello/lib/MODSERIAL/MODSERIAL.cpp"

I want to transmit the messages using the xbees. The mbed I am using is mbed NXP LPC11U24. Any suggestions to get rid of these errors?

25 Jun 2012

LPC11U24 doesn't have all those ports. I haven't yet gotten around to doing a new version of the library that supports the smaller device capabilities. MODSERIAL is for the LPC1768 variant.

25 Jun 2012

Is it possible to comment out the code for those ports from the MODSERIAL library and make it available for LPC11U24? If not, is there any other library that you can suggest for xbee wireless communication?

Thanks

24 Jul 2012

Has anybody yet figured out how to use MODSERIAL with the mbed LPC11U24? MODSERIAL would be especially useful considering the acknowledged bug in the mbed Serial library... which apparently MODSERIAL bypasses (whether intentional or not).

25 Jul 2012

I have just published an "alpha" version that should support the LPC11U24. Please give it ago and private message me if you have problems.

26 Jul 2012

Andy, this is marvelous news! I will have access to my LPC11U24 tomorrow (hopefully). I will *definitely* report back here. Thanks!

01 Aug 2012

I'm hoping to use this library to get round the small 16 byte RX buffer in Serial. I initially swapped from Serial to MODSERIAL in my code but got all sorts of weirdness so I have written a short program to try to figure out what is going on. The following uses a link between pins 13 and 14 to receive bytes that are sent:

#include "mbed.h"
#include "MODSERIAL.h"

// Uncomment one of the following to set serial interface
#define SerialType  0   // Serial
//#define SerialType  1   // MODSERIAL

Serial pc(USBTX, USBRX);

template <class T>
class CommsClass {
public:
    CommsClass(PinName tx, PinName rx) : _serial(tx,rx) {
        _ticker.attach(this, &CommsClass::_SendModbusRequest, 1);
        _serial.attach(this, &CommsClass::_TxInterupt, T::TxIrq);
        _serial.attach(this, &CommsClass::_RxInterupt, T::RxIrq);
    };

protected:
#if (SerialType==1)
    void _RxInterupt(MODSERIAL_IRQ_INFO *q) {
#else
    void _RxInterupt(void) {
#endif
        pc.printf("Rx Interupt %1x\n", _serial.getc());
    };
#if (SerialType==1)
    void _TxInterupt(MODSERIAL_IRQ_INFO *q) {
#else
    void _TxInterupt(void) {
#endif
        pc.printf("Tx Interupt\n");
    };
    void _SendModbusRequest(void) {
        pc.printf("\n");
        _serial.putc(0x0A);
        _serial.putc(0x0B);
        _serial.putc(0x0C);
    };
    Ticker _ticker;
    T _serial;
};

int main() {
#if (SerialType==1)
    CommsClass<MODSERIAL> mod_serial(p13, p14);
#else
    CommsClass<Serial> mod_serial(p13, p14);
#endif
    while(1) {
        __wfi();
    }
}

The program loops every second and I would expect the terminal output on each loop to be: Tx interupt; Rx interupt a; Rx interupt b; Rx interupt c;

However, if I use Serial the output is: Rx interupt a; Rx interupt b; Rx interupt c; Tx interupt;

so the serial port is behaving as if it received the bytes before it sent them. If I use MODSERIAL the terminal output is even stranger:

Tx interupt; Tx interupt; Rx interupt c; Rx interupt b; Rx interupt a;

so two Tx interrupts are generated and the bytes received are in reverse order?? I checked the pin with a scope and they are sent in the correct order.

Another issue that I spotted with the scope is that when using MODSERIAL there is a large time delay between bytes (20ms or more). I need all of the bytes to file out one after the other otherwise the receiving device (in my full code) will time out. When using Serial, all the bytes are sent immediately after each other.

Please could someone suggest where I'm going wrong here?

Thanks!

p.s. sorry about the messy assembler directives - I'm new to C++ and haven't worked out how to fully template the class yet

01 Aug 2012

Quote:

pc.printf("Rx Interupt %1x\n", _serial.getc());

Don't use printf() inside an ISR unless you want odd things to happen.

See http://mbed.org/users/AjK/notebook/regarding-interrupts-use-and-blocking/

02 Aug 2012

Thanks Andy. It's really obvious now that you've pointed it out! I've rewritten my code as below and it now works equally well with both Serial and MODSERIAL. I've also deleted all of the printfs from my other code and that works too!

#include "mbed.h"
#include "MODSERIAL.h"

// Uncomment one of the following to set serial interface
//#define SerialType  0   // Serial
#define SerialType  1   // MODSERIAL

Serial pc(USBTX, USBRX);

template <class T>
class CommsClass {
public:
    CommsClass(PinName tx, PinName rx) : _serial(tx,rx) {
        _ticker.attach(this, &CommsClass::_SendModbusRequest, 1);
        _serial.attach(this, &CommsClass::_TxInterrupt, T::TxIrq);
        _serial.attach(this, &CommsClass::_RxInterrupt, T::RxIrq);
        TxTriggered = false;
        RxTriggered = false;
        BytesRead = 0;
    };
    bool TxTriggered, RxTriggered;
    int BytesRead;
    unsigned char _buffer[3];
protected:
#if (SerialType==1)
    void _RxInterrupt(MODSERIAL_IRQ_INFO *q) {
#else
    void _RxInterrupt(void) {
#endif
        _buffer[BytesRead] = _serial.getc();
        BytesRead++;
        RxTriggered = true;
    };
#if (SerialType==1)
    void _TxInterrupt(MODSERIAL_IRQ_INFO *q) {
#else
    void _TxInterrupt(void) {
#endif
        TxTriggered = true;
    };
    void _SendModbusRequest(void) {
        RxTriggered = false;
        TxTriggered = false;
        BytesRead = 0;
        for (int i=0; i<3; i++)
            _buffer[i] = 0;
        _serial.putc(0x0a);
        _serial.putc(0x0b);
        _serial.putc(0x0c);
    };
    Ticker _ticker;
    T _serial;
};

int main() {
#if (SerialType==1)
    CommsClass<MODSERIAL> mod_serial(p13, p14);
#else
    CommsClass<Serial> mod_serial(p13, p14);
#endif
    while (1) {
        if (mod_serial.TxTriggered && mod_serial.RxTriggered && (mod_serial.BytesRead == 3)) {
            pc.printf("Message Received: ");
            for (int i=0; i<mod_serial.BytesRead; i++)
                pc.printf("%1x ", mod_serial._buffer[i]);
            pc.printf("\n");
        }
        __wfi();
    }
}
06 Sep 2012

Hello,

I'm having an odd problem with this class and I was wondering if anyone had any insight about what could be going on or has experienced anything similar. MODSERIAL offers really great functionality so I'd really like to try to figure this out.

When I declare a MODSERIAL object as a global, everything works fine, e.g.

#include "mbed.h"
#include "MODSERIAL.h"

MODSERIAL pc(USBTX, USBRX); // tx, rx

int main() {
	
	pc.printf("Hello World!\n");
	
}

prints "Hello World!" as expected.

But when I declare MODSERIAL as a local object, e.g.

#include "mbed.h"
#include "MODSERIAL.h"

int main() {
	
	MODSERIAL pc(USBTX, USBRX); // tx, rx
	
	pc.printf("Hello World!\n");
	
}

only the letter "H" prints. Inserting a wait before the the printf did not change anything, although I'm not sure why it would.

When using the regular Serial class there is no difference between the two cases (local/global scope of the object). Does anyone have any ideas about what could be going on here?

Thanks so much, I really appreciate any help!

Hello, thanks for the library it somehow saved me ^^

I wrote a client/server with visual c++ 2010 and I'm sending to the mbed lines of numbers to switch on some LEDs. With the 16bits it was not working, I could only get a part of the message I was sending. But if everything is now working, I've got a problem when I try it on another computer. When I plug the mbed on another computer and send it the commands, it behaves as it did before using Modserial.

Ex: I'm sending 5float to the mbed every 3 seconds. It'll work 4-5 times, then it will like oddly (only 2 leds on 4 are switching in, nothing is happening, etc ...). It's like it is filling up the serial bufferm and when its full, it will read only parts of the message.

How come it works on a computer and not on another ? Do I need to do something when I change computer ? Thanks for any advice you might have :)

10 Sep 2012

@Sam A

Your program exits before it's finished sending thus destroying your locally defined MODSERIAL pc(USBTX, USBRX) and with it go it's buffers and setup. Don't define it locally or if you must, ensure you wait until all charactors are sent before the program end (or the last } of the function it's defined in).

Note, "H" is printed because if the buffers are empty the first char is written to the hardware FIFO, the remainder to the buffer. Once in the hardware fifo it will get sent but the rest won't cos the buffers are destroyed.

I really cannot see a reason to define a serial port locally anyway so just stick to a global unless you _really_ have to for some other reason.

10 Sep 2012

@ Pierre-Alexandre Geraert

I'd really need to look at your code to try and figure that out. If you can publish it (privately) and use private message me with a link to your code I'll take a look.

15 Nov 2012

I am trying to read a Novatel OEM615 GPS receiver serial data port. I started using the mbed serial library and seem to be missing characters. My first attempt was to just use a while(1) {if (GPS.readable()) c = GPS.getc() }; infinite loop; My next attempt was to use the GPS.attach() and read the char in the attached function. I would seem this would have less overhead cause you get rid of the wasted loops w/o characters. I can look at the message headers and see I am missing characters. I am running the GPS COM port and the mbed tx/rx serial at 921600 baud. All seems to work as expected except for the missed bytes.

My question is what is the best way to use MODSERIAL for speed?

If I have lots of stuff going on in my main loop, then maybe just reading the buffer dry would be faster than using the ISR?

any thoughts on this?

I am getting the "raw" GPS serial data from the receiver at 5 Hz so am getting about 3000 bytes per sec from the receiver. This would seem to be a cakewalk for embed!!

- Jim

15 Nov 2012

i am have trouble using the attach functionality of MODSERIAL. some examples allow using a attach function prototype without the argument. e.g.: void rxCallback(void) vs void rxCallback( MODSERIAL_IRQ_INFO *q)

The samples wont compile if the (void) argument form is used.

also, in the callback function above from the Cookbook: void rxCallback(MODSERIAL_IRQ_INFO *q) { MODSERIAL *serial = q->serial; if ( serial->rxGetLastChar() == '\n') { newline_detected = true; }

note the use of the argument q to access the MODSERIAL object. Would not the gps.rxGetLastChar() have worked as well?

  1. include "mbed.h"
  2. include "MODSERIAL.h"

DigitalOut led1(LED1); DigitalOut led2(LED2); DigitalOut led3(LED3);

To test, connect p9 to p10 as a loopback. MODSERIAL pc(p9, p10);

This function is called when a character goes into the TX buffer. void txCallback(MODSERIAL_IRQ_INFO *q) { led2 = !led2; }

This function is called when a character goes into the RX buffer. void rxCallback(MODSERIAL_IRQ_INFO *q) { led3 = !led3; }

int main() { pc.baud(115200); pc.attach(&txCallback, MODSERIAL::TxIrq); pc.attach(&rxCallback, MODSERIAL::RxIrq);

while(1) { led1 = !led1; wait(0.5); pc.putc('A'); wait(0.5); } }

15 Nov 2012

First one: true, simply use the IRQ info in your callback function, and ignore it.

Second point: Without actually looking up that specific example, you are probably right, you could have done that too. Doing it this way allows for a bit better portability of the code, but nothing shocking.

Btw if you post code it is handy to put <<code>> <</code>> tags around it.

17 Nov 2012

I am trying to get MODSERIAL to work. The default mbed Serial library works but I am trying to get things to work with the MODSERIAL buffering. The serial link is from the COM1 port of a Novatel GPS receiver set to 460800 baud. The mbed and receiver both support this datarate. The receiver is outputting 4 messages per sec with about 1000 bytes per sec. The per-byte ISR (attach) is supposed to extract the current byte and test for a 4-byte message signature. This works exactly as expected for the mbed Serial library and the 4 messages are detected correctly. However, for the MODSERIAL library, the code seems to enter this ISR too many times and never detects a valid message signature.

Any ideas would be appreciated Jim

int test = 0;
bool messageDetected = false;
unsigned short messageCounter = 0;

#ifdef useMODSERIAL
void readSerialByte(MODSERIAL_IRQ_INFO *q)
#else   
void readSerialByte(void)
#endif
{
    #ifdef useMODSERIAL  
    MODSERIAL *serial = q->serial;
    unsigned char synch0 = serial->getc();
    #else
    unsigned char synch0 = GPS_COM1.getc();
    #endif

    //generate a 4-byte sliding-window sequence from the input bytes
    test = (test<<8) | synch0;  //
   
    if (test == 0xAA44121C) //test for the Receiver message signature
    {
        messageDetected = true;  //reset to false in main after we process a completed message
     }   
     byteCounter++;  
     messageCounter++;         
};

int main() {

    setupCOM();  //set up th GPS and mbed COM ports

    #ifdef useMODSERIAL
    GPS_COM1.attach(&readSerialByte, MODSERIAL::RxIrq);
    #else
    GPS_COM1.attach(&readSerialByte, Serial::RxIrq);
    #endif
    
    while(1)
    {
        if (messageDetected)
        {
            messageDetected = false;
            debug.printf("message detected %3d\n", messageCounter);            
            messageCounter = 0;
         }
          
        if (detectedGPS1PPS)
        {
            debug.printf(" byteCounter = %10d PPSCounter = %10d\n", byteCounter, PPSCounter);
            byteCounter = 0;
            detectedGPS1PPS = false;       
        }
    }
}
 
18 Nov 2012

fixed the problem! I was using the MODSERIAL baud() function to set the baud rate. The mbed Serial baud() function had worked just fine. The symptoms of my problem was that the GPS transmitted baud rate was faster than the COM baud rate. I was detecting too many chars. I added a wait_ms(100) after I called the MODSERIAL baud() procedure and now all works as expected.

as a note, I also found that the Andy Kirkham last commit library mentioned at the top of this page, was not listed when i used the "Import Library" buttons on the compiler. So I used the "import library" link at the top of this page to add Andy's latest library.

22 Nov 2012

A program using MODSERIAL does not compile with the latest mbed library (Revision 44). Errors from the compiler are:

- identifier "_uidx" is undefined - class "mbed::Serial" has no member "RxIrq" - class "mbed::Serial" has no member "TxIrq" - no instance of constructor "mbed::Serial::Serial" matches the argument list

Thanks,

Hiroshi

22 Nov 2012

Tried to fix it, _uidx is replaced by _serial.index, the name argument is gone in the new Serial constructor, and the Serial interrupts are of a different type. But while I get it to compile and work a bit, I cant get interrupts to work properly.

22 Nov 2012

Hi Hiroshi, Erik, as part of the complete refactoring of the mbed library we moved the parameter type definitions from the C++ API to the C API. The missing interrupt enum has moved from Serial.h to serial_api.h: serial_api.h

I will further investigate the compatibility of the MODSERIAL library with the new mbed library release.

Cheers, Emilio

22 Nov 2012

Emilio,

I did indeed find the interrupt there. Just couldnt get it to trigger. And just looked a bit more at it, I dont think it is my fault I cant get it to trigger: Base serial interrupts dont trigger.

Erik

22 Nov 2012

Hi Erik,

user Erik Olieman wrote:

I did indeed find the interrupt there. Just couldnt get it to trigger. And just looked a bit more at it, I dont think it is my fault I cant get it to trigger: Base serial interrupts dont trigger.

The following simple example for serial interrupts is working (the TX and RX interrupts do trigger):

#include "mbed.h"
 
DigitalOut led1(LED1);
DigitalOut led2(LED2);

Serial computer(USBTX, USBRX);
 
void txCallback() {
    led1 = !led1;
}
 
void rxCallback() {
    led2 = !led2;
    computer.putc(computer.getc());
}
 
int main() {
    printf("start\n");
    computer.attach(&txCallback, TxIrq);
    computer.attach(&rxCallback, RxIrq);
    while (true) {
        wait(1);
    }
}

That said, the interrupt handling code changed a lot and I cannot be sure that we have not broken compatibility with every detail of its behaviour.

I am currently in the process of testing the new mbed library release with the MODSERIAL library.

I hope to be able to update you soon, in the mean time, as usual, you are not at all obliged to use the latest release, all the past releases are available to be imported in your project.

Cheers, Emilio

22 Nov 2012

True works also for me, must have been doing something stupid while testing it. Still IRQs are not working when I replace Serial with my version of MODSERIAL. But as you said, you can always use an older version of mbed so not that much hurry to fix it.

22 Nov 2012

Hi Erik, there was actually a bug in the new serial interrupt handler for the LPC1768, we fixed that in the latest mbed library release [Rev 45]: mbed Library Releases.

After fixing this bug I've got MODSERIAL working again. This is a summary of the required changes:

  • Correct reference to RxIrq/TxIrq enum
  • "_uidx" -> "_serial.index"
  • The "Serial" constructor prototype does not have a "const char *name" field any-more.

I will not fork Andy's library, I leave to him deciding how to handle the changes.

Cheers, Emilio

22 Nov 2012

Woohoo I am actually not crazy (well at least not regarding serial interrupts being buggy).

22 Nov 2012

Are there changes to Serial::attach?, cant seem to get MODSERIAL to compile, get an argument list error, I've changed the parts from the post above.

May just be tired and missing the obvious.

Edit: Was an enum conflict between new lib and MODSERIAL, worked around

26 Nov 2012

Since no new version has been posted yet, modserial which should function: http://mbed.org/users/Sissors/code/MODSERIAL/

Hopefully bug free. And @Andy, feel free to pull it to the main modserial lib if you dont have problems with the changes.

Note: I removed the name argument from the constructor since the serial class doesnt have it: I could have kept it, but it wouldnt do anything at all (did it ever do anything?), so that could have caused weird behavior of programs which use it for some reason.

03 Dec 2012

is there a way to create an interrupt on 1, 4, or 8 bytes in the FIFO? I see in the LPC1768 manual that the chip provides that functionality.

03 Dec 2012

MODSERIAL doesnt support it afaik, and it probably wouldnt add much for MODSERIAL, since the library itself handles all communication with the FIFO buffer, and not the user.

12 Dec 2012

And new revision of the mbed library breaks it again. The library release says:

Quote:

[Rev 51] changelog:

Duplicate Serial enums for backward compatibility.

Thats nice, minus that there seems little backward compatibility and more just moving back to the old system. I changed modserial to work again, so updating it should do the trick if you have the issue (of course still from http://mbed.org/users/Sissors/code/MODSERIAL/).

I have to admit I haven't actually tested it, it compiles now, but got other stuff to do :P

08 Jan 2013

The mbed library added against support to give serial objects a name. So I re-added the option also to MODSERIAL again. (See post above this one for link).

I apparently missed it, but Andy also fixed the original MODSERIAL library to work with the new mbed libraries, so unless you really need the name option you can just use the original MODSERIAL library again. However since I have no idea when that will be done I decided to update my fork.

Edit: That was fast, the official fork is now already updated. I will keep my fork online for now since it can't hurt and then people who already imported it can then update easily if needed, but if you need to import it again, just use the official one :)