hi every body ... i've been working on a project using two mbeds, and i need them to communicate with each other, such that one of them makes some processing on data from sensors, and sends the values of the sensor readings to the other mbed which acts as a controller. i want to acheive this communication using serial UART communication, but i don't know how to start, any help??

You realy should start by clearly defining what messages go back and fourth,

If just a stream of numbers, then it could be very simple, But if commands instructions etc. Oar needed, then it starts to get complicated.

Also, what happens if you miss one or more messages / packets.

Simmilarly, corrupted or unexpected messages.

I recomend a BIG sheet of paper, way befor you start coding.

Hope this helps, (somewhat)

Ceri

A lot depends on how robust it needs to be, if the two MBEDs are side-by-side and communications will never get corrupted then it may be enough to use blocking read commands and accept that one unit sits halted waiting for communication from the other.

thank you guys for your responce. i want to transfer some float numbers between the two mbeds, and they are about 5cm away from each other (so i think i don't need much complication in code for data checking), and regarding what happens if i miss some data, let me be frank with you and tell you that i'm not that familiar with UART, so i don't know specifically what to do. what do you think?

I would say that the difference between a simple implementation and a robust one is in what happens when something unexpected happens. Probably the simplest implementation would be using printf and scanf to send and recieve data.

The remote unit's program flushes the input (can't remember the command) then executes a scanf to retrieve a command. Assuming scanf returns true then it executes the command (ADC read) and prints the data back to the serial port. If scanf returns false then the recieved data didn't match the patten, the data remains in the input buffer and alternative patterns may be tried or the program can simply give up and go back to the initial flush.

The controlling unit waits a short time on startup, then when it needs to read from the remote unit it flushes the input, prints out a command and immediately attempts to read a response.

If you can follow what's going on here the remote unit is mostly stopped, waiting for input. The control unit stops while the remote unit is executing a command, so effectively there is only one program path even though it is spread across two units.

The problem with the above is that if there is a glitch of some sort and a communication doesn't get through then the system will halt.