Thanks to those who have responded. In order to help others who might have similar problems I am posting what I have learned. Here is the code and docs from the Handbook SerialHalfDuplex entry:
----------
A serial port (UART) for communication with other devices, with a single shared transmit and receive line.
If the device both transmits and receives, then both (separate) pins need to be defined, and tied together externally.
Example
// Send a byte as a master, and receive a byte as a slave
#include "mbed.h"
SerialHalfDuplex master(p9, p10);
int main() {
int outbyte = master.putc(0x55);
int retbyte = master.getc();
printf("Wrote: %02X Read: %02X\n", outbyte, retbyte);
}
---------
Of course for this to work p9 has to be connected to p10. I thought I had made this clear in my first post, which indicated that I had done so, but as some did not understand this I will make it more obvious: in order to run this demo you need to connect p9 to p10. You need not do anything else.
The demo code, as I indicated, does not work. Because the documentation for SerialHalfDuplex is very sketchy and because the source code is not available (bad!) fixing this requires some trial-and-error, complicated for me by the fact that my scope is broken (new one on order). Were I to do serious code for the MBED I would just write my own drivers, at least until the MBED folks either publish library source code or make better docs.
Probably the outbyte() function puts the char in the xmit buffer and returns immediately. If getc() hangs when no char is available this would explain why the code does not work, because there would be no char in the input buffer until about 1 Ms (the default baud rate is 9600).
if getc() returned something, such as 0, when there is no char then the code should not hang. Likewise, if getc() just waits for a char to be in the buffer then we would expect the code to work, with a 1 mS delay before the printf does its thing. Since it does not work, it appears that getc() causes the program to crash if there is no char available in the receive buffer.
We would hope that if we check for a char in the buffer before trying to read it, the example code would work (code snippet):
while !master.readable() {};
int retbyte = master.getc();
But this code does not work either.
Using the Serial library, things work OK - except that the actual behavior of getc() is not documented very well. The following code indicates that getc() waits until a char is in the receiver before continuing. This is OK, tho it should be documented.
Here is code using Serial instead of SerialHalfDuplex. It works, and shows that getc() waits until a char is in the buffer. If this is not what you want, you could use an interrupt routine or could check the status of the buffer using readable(), tho I have not tested that to make sure it works.
// Send a byte and receive a byte. Connect p9 and p10.
// Glen Worstell 21-Feb-2011
#include "mbed.h"
Serial out(p9, NC);
Serial in(NC, p10);
Ticker tUsec;
DigitalOut myled1(LED1);
volatile static unsigned int count = 0; // the global count, 100 uS per count
void inc_tUsec_func(void) { // the function called by ticker interrupts every 100 uS
count += 1;
}
int main() {
volatile static unsigned int start;
tUsec.attach(&inc_tUsec_func, 100.0e-6); // ISR to increment secs every 100 uS
unsigned char toPut = 0xF0;
while(1) {
int outbyte = out.putc(toPut);
start = count;
int retbyte = in.getc();
printf("count - start = %i\r\n",count-start); // if getc() waits until a char is ready,
// this should take about 1 mS, or 10 counts, at 9600 baud.
// It would be easier to just use a scope for this - mine is broken.
printf("Wrote: %02X Read: %02X\r\n\r\n",toPut, retbyte);
start = count;
while ((count-start) < 10000) {}; // wait for a second
toPut += 1;
myled1 = !myled1; // toggle the led once per second
}
}
The SerialHalfDuplex example in the cookbook does not work for me. I connected port 9 and 10. The example program sends one character and then hangs.
Is a pullup resistor required? Has anyone else successfully used the example?
g.