The standard LPC17xx UART has a 16byte FIFO. However, you can save yourself some trouble by using the MODSERIAL library. It's a drop in replacement for Serial that does exactly the same things but has extra API features you may find useful.

• Configurable TX and RX buffers. You can set the buffer sizes as you require
• Auto-detect callback. You can tell the library to callback when it sees a specific character going into the RX buffer.

The auto-detect is useful because "you don't have to check it often". You can have the library tell you "a message has been receieved and is in the RX buffer". For example, GPS NMEA sentences always end in \n so rather than read all the bytes coming from a GPS and manually building a sentence seeking the \n terminator, you can just tell MODSERIAL to have a large enough buffer for the longest NMEA sentence type and then tell MODSERIAL to "callback" your program when it sees a "\n" going into that buffer.

Could save you a lot of work and help you concentrate on the harder parts of your project :)

I am thinking about it and will test it.

But, I just wonder how much overhead it takes and what about interrupts conflict, as MODSERIAL looks like quite "interrupt intensive". PWM or PPM signal readings must have higher priority...

In my case the orientation sensor I'm using sends data in packets starting with "snp" and ending with checksum, so knowing last char readed is not too helpful - any suggestion ?

+++ Edit +++

Some errors in compilation of MODSERIAL library. Program published here http://mbed.org/users/kinemax/programs/PwmIn_ModSerial/lpb6mh

I know it is not too clever, just tried to compile it ported from Serial to MODSERIAL...

Maybe you are making some corrections ?? 2 hours before example.cpp was running (after some code insertion to main.cpp) and now same mistakes as in published above...

Glad you had a look. But bare in mind, I just extend the Mbed library Serial. So if you are going to use the Mbed library, do you suppose it's any less "interrupt intensive" just because you can't look at the code? Sounds like you'll have to go native direct to the Uarts if so. And I'll bet that at 115k baud you'll have to use interrupts and buffers. Back to square one.

Select the "mbed" library in the left hand pane. Then look at the stats on the right hand side. Your Mbed library used on that project is version 19. That's rather old. Update the Mbed library to the latest version (28) and it complies just fine.

Thanks! I'll try now...

Just got back from vacation and my mailbox is full!

@ Pawel - I suggest learning how to build interrupt libraries and to use the hardware, it will help you in the long run. But, if you need something to use right away, you can trust that Andy's library is lean and quick.

Now, it almost works ;) Here I have what works perfectly as just USB-Serial interface - http://mbed.org/users/kinemax/programs/UART-USB/lpoimh

and this http://mbed.org/users/kinemax/programs/CHR6dm_reading/lpns0v is also working but a LOT of data is lost, many packets are erratic, with missing bytes. As it looks like that device itself work fine (its PC soft shows position well, also using mbed as interface) and it does not appear to lose significant amount of data, I wonder if it is not some Teraterm interaction problem. Sometimes I get from teraterm different char set like "_" instead of "s" for CHAR 115. Any ideas ?

I know it is allot to learn but a RTOS would really make your problems much simpler. What the RTOS provides is the ability to run things at different speeds through multi-threading. There is a definite learning curve to the how's and why's of an RTOS but they make difficult problems much simpler once you understand how. Serial is a slow(relativity) interface, and if you have other services that need to be handled at a higher rate it would make more sense to split these two services between two threads and communicate between them through mailboxes or signals. I have found that problems that require multiple interfaces running at different rates and guaranteed response times, a RTOS is a must.

Hi, Why don't you create a new class, that overloads the set method, and insert on it a callBack function (Also called "Listner Events"), that will be called whenever you change the boolean Object? It's better than "pinging" the boolean every time, loosing a LOT of performance on the CPU, or, creating an interruption on a pin that is not used, and changing it's state... With objects you can have more controll about it, and it's not a 'hardware' thing, it's software... so the slew-rate will not prejudice you...

Hope it helps... Ivan

Just saying, but do you two realise this topic is a year and a half old? Btw regarding RTOS, it can simplify things in certain larger designs which dont have very demanding timing requirements (since the RTOS ticker is 1ms, so your timing wont get better than that). But if you want guaranteed response times I would really take interrupts.

Just realised that =]

Hi, An interesting topic. I used the approach suggested by Andy, but then discovered this by reading the LPC1768 user manual:

• NVIC_SetPriority(EINT0_IRQn, 1); Set desired IRQ priority.
• LPC_SC->EXTMODE |= 0x1; Set EINT0 to edge mode. (assume its not physically used). Should avoid false ext triggers.
• LPC_SC->EXTINT |= 0x1; Clear the IRQ for EINT0
• NVIC_EnableIRQ(EINT0_IRQn);
• NVIC_SetVector(EINT0_IRQn, (uint32_t)DSP_ISR); set the int vector to your own ISR.

Then when needed trigger the IRQ:

• NVIC->STIR = EINT0_IRQn;

Inside the ISR, clear the IRQ:

• LPC_SC->EXTINT |= 0x1; Clear the IRQ