Hi All,

I am wondering if there is some possible way to synchronise two mbed boards?. My task is to send data from two working ADC via USB serial port using only one USB connection. I am thinking to connect 2 mbeds to a hub/switch. Does somebody know how this solution will behave? My aim is that data should be sent at the same time...or make some queing

An approach you might want to investigate could be to use 2 mbeds with slightly different programs (1 master and 1 slave) tied together over an SPI or hardware serial port channel. The slave takes 1 ADC via USB and sends it to the master over the SPI/serial channel. The master takes 2 ADC streams (1 SPI/serial and 1 USB), interleaves them, and passes them on via the 'magic chip' USB serial port. This will eliminate the need for a hub.

Of course, you could still use a hub, and just coordinate the 2 mbeds via SPI or serial port handshaking. You will probably still need to make one the master and one the slave, but they might have the same program with one hardware bit set high or low to designate master vs slave.

Lastly, you might use just 1 mbed plus a USB-to-serial chip tied to one of the mbed's hardware serial port. That is, if you can find a chip that the mbed can set-up to operate as a USB master for the ADC.

Do you actually need two MBED modules, or just more analog functions. If its just more analog inputs then you might find it easier to build a multiplexer or attach some kind of ADC module to provide the extra inputs. I say this because with two micros you tend to end up with a master-slave configuration and generally a master is easier to code.

Otherwise two boards on one USB hub may help but USB doesn't allow for peer to peer communication.

I have 2 mbed boards, both working as ADC converter, I am gathering 12 analog signals, so each mbed is responsible for 6 signals. For now I have connected them via hub, so only one USB i physically pluged to the computer and read in on application programed in C# and write as a string. Could You give some more information about master-slave mbed configuration? for now both mbeds are programed in the same way.

Pa,

I had originally thought (mistakenly) you were saying you had ADC circuits which communicated to the mbeds over their (non-magic chip) USB interfaces. Now that I know you are using the mbeds' ADC pins I may be a little more helpful.

The master-slave set-up I am proposing is more of a software technique than a hardware configuration. One mbed is programed to send a signal that means "start now". The other mbed is programed to wait while looking for the signal before running it's ADC sampeling. The mbed that first sends the signal is the 'master', and the mbed that first waits is the 'slave'. After the first signal is sent the roles are usually somewhat reversed, as the master will wait for a (different) signal from the slave to indicate that it has done it's task (or at least begun). Sometimes power-up considerations dictate using reversed signal polarities, or at least some initial delay between configuring the pins and using the handshaking.

The signals could be a 'two wire handshake'. Both the master and slave have one output and one input pin. The output of each is wired to the input of the other. Both outputs are initialized to be low. The master checks (and waits) for the slave signal to be low, then sets it's output pin high as the 'start' signal. The master can then begin it's ADC task. When the slave notices the signal, it sets it's output high (to indicate that it has begun the ADC task). The master responds to the slave's signal by setting it's output low. When the slave finishes it's ADC task it waits for the master's signal to be low, sets it's own signal low, and loops back to wait for the master's next start signal. When the master finishes it's ADC task it set it's own output low, and loops back for another ADC burst.

There are other possible handshaking schemes, such as sending messages back and forth over a (non-magic chip) serial connection, or a 'one-wire' hardware handshake (with open-collector I/O and a wired-or pullup). For minimal delays you can run the hardware handshaking in the 'background' via interrupts and (global) semephores.

If you use the serial port the USB Hub can be eliminated by having the slave's responce signal be a line with it's ADC results. The master can then combine both ADC results into one message for the C# application.

You need to synchronize the mbed's (which usually have slightly different crystal frequencies) and also allow for the USB buffering (with or without the USB hub). The handshaking can be made to add very little delay, just enough to match the faster mbed to the slower. For the serial port scheme you may need to manage extra buffering internal to the mbeds, so that the serial transmissions and ADC tasks overlap (without additional delays). You may need to buffer and overlap with a USB Hub, too.

Fred

I think Fred's idea is probably more suited to what you are trying to achieve. If I read right you can already read from one MBED, there is no problem with adding a USB hub, and the problem is purely a matter of ensuring the measurements take place at known times.

Another simplification might be to have an external device generating a common time signal or trigger? That means all the MBEDs can run the same code. It might be possible for the host PC to send a trigger but I don't know anything like enough about USB to know how to do this, though HID devices might work this way.

Can you give a little more idea of the analog requirement, is this a fast sequence of measurements with data dumped afterwards, or a slow series with data transferred while measurements are being made.

I ask this because if the problem is simply one of measuring multiple inputs then one hardware solution is to use an analog switch IC to route signals to the analog input pin. Its not uncommon to have 8 or possibly 16 signals share the same ADC. The tradeoff is that measurement rate falls as the ADC is shared, and the software is slightly more complex as you have to output a number to select an input. The advantage is that by staying with a single MBED there is nothing to synchronise.

Unfortunately I don't know much about the MBED analog I/O yet because my experience has been with Microchip PIC series, and I'm trying to migrate and relearn C at the same time.

For now I am using SPI to provide master-slave connection between two boards to send ADC datafrom slave mbed to master mbed(which is also working as ADC) the data are seemd to be sent in the way I want. Only task to manage is to make something like common clock that defines the work of the ADC on both mbeds. When I have on one mbed data from both ADC i can send it as one string to my application and that is exactly what I want. I am just wondering...couse ADC are not synchronised in any way, I am afraid of some lags( One mbed has more to do accually)...My question is...is there a way to shere clock that tells both mbeds to start ADC work at the same time?...it would me not nice at all when half of the data are from different time period(I am making image from those data...so half of the image would be slightly different...I suppose. Thanks for reply :)

You could have the master send a command to start measurement. Because of the way SPI works I think both the transmit command on the master and the recieve on the slave finish simultaneously, so by using this point to trigger a conversion the conversions should be simultaneous.

Pa,

The remainder of the solution to your synchronizing requirement depends on what possible delays you need to allow for.

A simplistic approach would be a hardware modification (cut circuit traces and solder a twisted pair of signal wires) to drive both mbeds from the same clock oscillator (12 MHz) signal. This has no allowances for any delay problems, and assumes that both mbeds (ADC's, etc.) will stay in software lock-step after they are made to initially start in synchronization.

A slightly better approach is to (repeatedly) trigger 6+6 ADC bursts from a (common) hardware signal. If USB-caused delays are not a concern, you can have the slave mbed set-up a timer to produce a hardware pacing clock on a timer output. Connect this signal to an input on both mbeds that will be programed to start (both) 6 sample ADC bursts via edge interrupt(s). The completion of the ADC burst on the slave triggers the SPI transfer to the master. The completion of an SPI receive on the master triggers a USB transmission. The rate of ADC sampeling is set entirely by the timer, which must be programmed to insure that both ADC bursts will be complete before the next trigger.

If USB-caused delays are a concern, you might generate the hardware pacing signal in the master mbed. Set an output bit (ADC trigger) signal. Clear the trigger bit after SPI receive but before USB send. Pace the ADC burst by waiting on a flag that is set with the ADC trigger and cleared at the end of the (buffered) USB write. All actions except the setting the ADC trigger bit are (hardware or software) event driven. In this scheme timing of ADC samples will be synchronized between mbeds, but will vary from sample-to-sample as needed for any delays.

Once again, you may need to manage your own buffering of ADC, SPI, and USB data/messages to maintain synchronized input sampeling at a high, fixed pace. Make certain the (average) bit rates on your SPI and USB data/text transfers can support the net ADC data input rate. Keep most of the task code in short interrupt (background) routines, but keep the USB writes in a foreground loop on the master. Use both externally (signal edge) and internally (ADC and SPI/DMA completions) generated interrupts. If necessary, have the interrupt routines run ring-buffers instead of direct data transfers. Proper buffering could make either the timer-driven or task-driven approach work, and may allow overlapping AD+SPI and USB to produce the fastest possible sampeling rate. Overlapping ADC and SPI may be possible with a 'wired or' combination of master and slave outputs into a trigger signal.

Fred

I think that you would be far better off using a separate ADC,

for the cost of an MBED, you could get a number of ADC chips, or modules, look in sparkfun etc.

this would be much easier to code and be more manageable.

also look at liner.com and maxim.com for ADC chips,

as both have excellent data sheets and searching.

hope this helps

Ceri

I know it would be easier, the problem is that I have to use mbeds :)

This method seems to be the most interesting for me, if it wont be and effort could you please descripe me how "timer to produce a hardware pacing clock on a timer output" is realised in code? which pin provides this clock output? if necessery I can post my code. Thank you again for respond, You have helped me a lot as so.

here is the code from ADC could someone tell me how to change data to sending via SPI to read data I ma using valueFromMaster[i] = device.read();-read function. Bufor[] is uint32_t

while (1) {

if (dmaTransferComplete) { int i, war; for (i = 0; i < 6; i++) { war = (Bufor[i] >> 4) & 0xFFF;

float vol = 3.3 * (double)((double)war) / ((double)0x1000); pc.printf("%01.3f ", vol);

chipSelect = 0; Select device

spi.write(int (war)); here I dont know how to change the data ...sadly

chipSelect = 1; Deselect device

} dmaTransferComplete = false;

} }

Pa,

Probably the simplest way to get a pacing clock is to use the PWM library and one of the mbed's PWM output pins. Set the duty cycle to something convenient (default = 50%?), the PWM frequency as needed, and start it running :-).

Fred

Hi, I have managed the connection that I needed:) I used pwm to synchronise ADC work, and SPI to send data via master-slave, What is more there is no shift data and no bad data, I have tested all signals that my boards will receive from front-end electronics. On my applicacion I am receiving string containing 12 data(6 from one mbed)separated by coma. It is exactly what I wanted to do, and only one USB is plugd to the computer, second board is powered by the first one. Thank everyone for advices. Especially to You Fred. When my magic device will be completed I will make an article so i will post it to mbed, as i might think there where no mbed boards use in nuclear medicine so far. Thanks again