Bug fix release

Dependents:   AntiTheftGPS XbeeReceive XbeeSend Superball_Ball2 ... more

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.



Committer:
AjK
Date:
Tue May 10 08:07:27 2011 +0000
Revision:
21:af2af4c61c2f
Parent:
20:59c74aaedda2
Child:
22:c11ea36f17f9
V1.21 See ChangeLog.c

Who changed what in which revision?

UserRevisionLine numberNew contents of line
AjK 1:b7e435fbfe8e 1 /* $Id:$
AjK 2:b936b4acbd92 2
AjK 21:af2af4c61c2f 3 1.21 10 May 2011
AjK 21:af2af4c61c2f 4
AjK 21:af2af4c61c2f 5 * http://mbed.org/forum/mbed/topic/2264
AjK 21:af2af4c61c2f 6
AjK 20:59c74aaedda2 7 1.20 26 April 2011
AjK 20:59c74aaedda2 8
AjK 20:59c74aaedda2 9 * Bug fix, not blocking on transmit
AjK 20:59c74aaedda2 10 by Erik Petrich, http://mbed.org/forum/bugs-suggestions/topic/2200
AjK 20:59c74aaedda2 11
AjK 20:59c74aaedda2 12 1.19 20 April 2011
AjK 20:59c74aaedda2 13
AjK 20:59c74aaedda2 14 * Fixed some doxygen comment bugs.
AjK 20:59c74aaedda2 15
AjK 18:21ef26402365 16 1.18 20 April 2011
AjK 18:21ef26402365 17
AjK 18:21ef26402365 18 * All callbacks now use MODSERIAL_callback (rather than Mbed's FunctionPointer[1] type)
AjK 18:21ef26402365 19 to store and invoke it's callbacks. This allows MODSERIAL to pass a parameter
AjK 18:21ef26402365 20 to callbacks. The function prototype is now void func(MODSERIAL_IRQ_INFO *q).
AjK 18:21ef26402365 21 * Callbacks now pass a pointer to a MODSERIAL_IRQ_INFO class type.
AjK 18:21ef26402365 22 This class holds a pointer to the MODSERIAL object that invoked the callback
AjK 18:21ef26402365 23 thus freeing callbacks need to use the global variable of the original
AjK 18:21ef26402365 24 MODSERIAL instance.
AjK 18:21ef26402365 25 * MODSERIAL_IRQ_INFO also declares public functions that are protected within MODSERIAL
AjK 18:21ef26402365 26 thus allowing certain functions to be restricted to callback context only.
AjK 18:21ef26402365 27 * New function MODSERIAL_IRQ_INFO::rxDiscardLastChar() allows an rxCallback function
AjK 18:21ef26402365 28 to remove the character that was just placed into the RX buffer.
AjK 18:21ef26402365 29
AjK 18:21ef26402365 30 [1] http://mbed.org/users/AjK/libraries/FPointer/latest/docs/
AjK 18:21ef26402365 31
AjK 17:6c9b57c14868 32 1.17 08/Mar/2011
AjK 17:6c9b57c14868 33 Fixed a memory leak in the DMA code.
AjK 17:6c9b57c14868 34
AjK 16:8b1dbf4cce4e 35 1.16 - 12 Feb 2011
AjK 16:8b1dbf4cce4e 36
AjK 16:8b1dbf4cce4e 37 * Missed one, doh!
AjK 16:8b1dbf4cce4e 38
AjK 15:a1d9e745d71e 39 1.15 - 12 Feb 2011
AjK 15:a1d9e745d71e 40
AjK 15:a1d9e745d71e 41 * Fixed some typos.
AjK 15:a1d9e745d71e 42
AjK 14:3c3b87617bfe 43 1.14 - 7 Feb 2011
AjK 14:3c3b87617bfe 44
AjK 14:3c3b87617bfe 45 * Fixed a bug in __putc() that caused the output buffer pointer to
AjK 14:3c3b87617bfe 46 become corrupted.
AjK 14:3c3b87617bfe 47
AjK 13:70bb7c1769fa 48 1.13 - 20/01/2011
AjK 13:70bb7c1769fa 49
AjK 13:70bb7c1769fa 50 * Added extra documentation.
AjK 13:70bb7c1769fa 51 * Fixed some typos.
AjK 13:70bb7c1769fa 52
AjK 12:8c7394e2ae7f 53 1.12 - 20/01/2011
AjK 12:8c7394e2ae7f 54
AjK 12:8c7394e2ae7f 55 * Added new "autoDetectChar()" function. To use:-
AjK 12:8c7394e2ae7f 56 1st: Add a callback to invoke when the char is detected:-
AjK 12:8c7394e2ae7f 57 .attach(&detectedChar, MODSERIAL::RxAutoDetect);
AjK 12:8c7394e2ae7f 58 2nd: Send the char to detect.
AjK 12:8c7394e2ae7f 59 .autoDectectChar('\n');
AjK 12:8c7394e2ae7f 60 Whenever that char goes into the RX buffer your callback will be invoked.
AjK 12:8c7394e2ae7f 61 Added example2.cpp to demo a simple messaging system using this auto feature.
AjK 12:8c7394e2ae7f 62
AjK 12:8c7394e2ae7f 63
AjK 11:a93a62eeeb9d 64 1.11 - 23/11/2010
AjK 11:a93a62eeeb9d 65
AjK 11:a93a62eeeb9d 66 * Fixed a minor issue with 1.10 missed an alteration of name change.
AjK 11:a93a62eeeb9d 67
AjK 10:725fe81aa9ff 68 1.10 - 23/11/2010
AjK 10:725fe81aa9ff 69
AjK 18:21ef26402365 70 * Rename the DMA callback from attach_dma_complete() to attach_dmaSendComplete()
AjK 10:725fe81aa9ff 71
AjK 9:b3cdae80e7a9 72 1.9 - 23/11/2010
AjK 9:b3cdae80e7a9 73
AjK 9:b3cdae80e7a9 74 * Added support for DMA sending of characters. Required is
AjK 9:b3cdae80e7a9 75 the MODDMA library module:-
AjK 9:b3cdae80e7a9 76 http://mbed.org/users/AjK/libraries/MODDMA/latest
AjK 9:b3cdae80e7a9 77 See example_dma.cpp for more information.
AjK 9:b3cdae80e7a9 78
AjK 8:775f860e94d3 79 1.8 - 22/11/2010
AjK 8:775f860e94d3 80
AjK 8:775f860e94d3 81 * Added code so that if a buffer is set to zero length then
AjK 8:775f860e94d3 82 MODSERIAL defaults to just using the FIFO for that stream
AjK 8:775f860e94d3 83 thus making the library "fall back" to teh same operation
AjK 8:775f860e94d3 84 that the Mbed Serial library performs.
AjK 8:775f860e94d3 85 * Removed dmaSend() function that should have been removed
AjK 8:775f860e94d3 86 at 1.7
AjK 8:775f860e94d3 87
AjK 7:ffa4a7cb7f8d 88 1.7 - 21/11/2010
AjK 7:ffa4a7cb7f8d 89
AjK 7:ffa4a7cb7f8d 90 * Remove the DMA enum from MODSERIAL.h as it's not currently
AjK 7:ffa4a7cb7f8d 91 ready for release.
AjK 7:ffa4a7cb7f8d 92 * Added page doxygen comments.
AjK 7:ffa4a7cb7f8d 93
AjK 6:c8f77fe1cc10 94 1.6 - 21/11/2010
AjK 6:c8f77fe1cc10 95
AjK 6:c8f77fe1cc10 96 * Version 1.5 solved a blocking problem on putc() when called
AjK 6:c8f77fe1cc10 97 from another ISR. However, isr_tx() invokes a callback of it's
AjK 6:c8f77fe1cc10 98 own when a byte is tranferred from TX buffer to TX FIFO. User
AjK 6:c8f77fe1cc10 99 programs may interpret that as an IRQ callback. That's an ISR
AjK 6:c8f77fe1cc10 100 call from within an existing ISR which is not good. So the
AjK 6:c8f77fe1cc10 101 TxIrq callback from isr_tx is now conditional. It will only
AjK 6:c8f77fe1cc10 102 be called when isr_tx() is actually within it's own ISR and
AjK 6:c8f77fe1cc10 103 not when called from alternate ISR handlers.
AjK 6:c8f77fe1cc10 104
AjK 5:8365c4cf8f33 105 1.5 - 21/11/2010
AjK 5:8365c4cf8f33 106
AjK 5:8365c4cf8f33 107 * Calling putc() (or any derived function that uses it like
AjK 5:8365c4cf8f33 108 printf()) while inside an interrupt service routine can
AjK 5:8365c4cf8f33 109 cause the system to lock up if the TX buffer is full. This
AjK 5:8365c4cf8f33 110 is because bytes are only transferred from the TX buffer to
AjK 5:8365c4cf8f33 111 the TX FIFO via the TX ISR. If we are, say in an RX ISR already,
AjK 5:8365c4cf8f33 112 then the TX ISR will never trigger. The TX buffer stays full and
AjK 5:8365c4cf8f33 113 there is never space to putc() the byte. So, while putc() blocks
AjK 5:8365c4cf8f33 114 waiting for space it calls isr_tx() to ensure if TX FIFO space
AjK 5:8365c4cf8f33 115 becomes available it will move bytes from the TX buffer to TX
AjK 5:8365c4cf8f33 116 FIFO thus removing the blocking condition within putc().
AjK 5:8365c4cf8f33 117
AjK 4:28de979b77cf 118 1.4 - 21/11/2010
AjK 4:28de979b77cf 119
AjK 4:28de979b77cf 120 * Removed all the new DMA code. I wish mbed.org had proper SVN
AjK 4:28de979b77cf 121 versioning, I'm use to working in HEAD and BRANCHES after I've
AjK 4:28de979b77cf 122 released a project. Getting bug reports in current releases
AjK 4:28de979b77cf 123 while trying to dev new code is hard to manage without source
AjK 4:28de979b77cf 124 control of some type!
AjK 4:28de979b77cf 125
AjK 2:b936b4acbd92 126 1.3 - 21/11/2010
AjK 2:b936b4acbd92 127
AjK 2:b936b4acbd92 128 * Fixed a macro problem with txIsBusy()
AjK 2:b936b4acbd92 129 * Started adding code to use "block data" sending using DMA
AjK 3:0f10f536456e 130 * Removed #include "IOMACROS.h"
AjK 1:b7e435fbfe8e 131
AjK 2:b936b4acbd92 132 1.2 - 21/11/2010
AjK 2:b936b4acbd92 133
AjK 2:b936b4acbd92 134 * Removed unsed variables from flushBuffer()
AjK 2:b936b4acbd92 135 * Fixed a bug where both RX AND TX fifos are cleared/reset
AjK 2:b936b4acbd92 136 when just TX OR RX should be cleared.
AjK 2:b936b4acbd92 137 * Fixed a bug that cleared IIR when in fact it should be left
AjK 2:b936b4acbd92 138 alone so that any pending interrupt after flush is handled.
AjK 2:b936b4acbd92 139 * Merged setBase() into init() as it wasn't required anywhere else.
AjK 2:b936b4acbd92 140 * Changed init() to enforce _uidx is set by Serial to define the _base
AjK 2:b936b4acbd92 141 address of the Uart in use.
AjK 2:b936b4acbd92 142
AjK 1:b7e435fbfe8e 143 1.1 - 20/11/2010
AjK 1:b7e435fbfe8e 144
AjK 1:b7e435fbfe8e 145 * Added this file
AjK 1:b7e435fbfe8e 146 * Removed cruft from GETC.cpp
AjK 1:b7e435fbfe8e 147 * "teh" should be "the", why do my fingers do that?
AjK 1:b7e435fbfe8e 148
AjK 1:b7e435fbfe8e 149 1.0 - 20/11/2010
AjK 1:b7e435fbfe8e 150
AjK 1:b7e435fbfe8e 151 * First release.
AjK 1:b7e435fbfe8e 152
AjK 1:b7e435fbfe8e 153 */