The problem I have is complex, but is reliant on communication speed. The short of this is Im looking for a way of doing the comunication quickly.
There is an array of chips controled by a mbed, they (all) do the processing and then need to transmit data around the array to certain other chips. What information goes to a certain chip is determined during setup, as is the shape of the array. Think of a 2D matrix of 1's and 0's, each 1 in the line sends a data packet to each 1 in the line above it.
The worse case for a single cycle is for all chips to send a data packet up and then all chips send a data packet down. A theoretical setup using 300 chips in 10 by 30 format forms the worse case senario. The data packet is a 32 bit floating point number in this example. This ignores addressing information ect.
If you send each data packet to each chip individualy, in my worse case senario you end up needing to do 45,000 transmitions. That makes this implementation not viable, it spends so much time communicating a BBC micro would run faster.
The best implementation I have come up with so far is to put all the chips onto one bus. This give 600 transmitions in the example above. Each chip is told to transmit by the mbed using a matrix similar to the one used to control a screen of LEDs. This makes clashes "impossible". The mbed uses a PWM line as a clock for the whole network, so no need to syncronise clocks as all clocks are the "same". (yes I am ignoring certain annoying bits of reality)
what happens in setup is each chip has an individual address to identify sent packets, and each layer has an address. Each chip listens for a set of addresses, when one arrives that is in that set, it looks at the sending address to identify what its reciving from where, then writes the data into a memory location.
When all information is recived it starts processing it, until its called to send its data, then resumes processing after sending the data.
the processing time is ignored for now.
So what I have worked out is that the addresses for sending and reciving are the same. This makes assigning addresses easier. These form a 16 bit unsigned int. data is in the form of 32 bit floating point numbers. so a packet looks like this
16 bit unsigned int
16 bit unsigned int
32 bit float
...
packet lengths are fixed so the chips not reciving the packet count to the end of the packet.
so the question is how do I do the transmition? Can I use a protocol that exists to do the actual communication, and use normal I/O to trigger the transmitions? then there is speed, how fast can I do these 600 transmitions? sending 64 bits 600 times gives 38400 bits. which at 1MB is 26 times a second. but can I get to >1MB practicaly? (for the problems I have in mind, thats pretty fast)
I haven't done much networking, so would rather not waste time looking at ways that are impractical. so pointers for where to start would be nice.
there is a possiblity of running multiple busses at once to reduce idle time, but I want to get one working before playing with that.
The problem I have is complex, but is reliant on communication speed. The short of this is Im looking for a way of doing the comunication quickly.
There is an array of chips controled by a mbed, they (all) do the processing and then need to transmit data around the array to certain other chips. What information goes to a certain chip is determined during setup, as is the shape of the array. Think of a 2D matrix of 1's and 0's, each 1 in the line sends a data packet to each 1 in the line above it.
The worse case for a single cycle is for all chips to send a data packet up and then all chips send a data packet down. A theoretical setup using 300 chips in 10 by 30 format forms the worse case senario. The data packet is a 32 bit floating point number in this example. This ignores addressing information ect.
If you send each data packet to each chip individualy, in my worse case senario you end up needing to do 45,000 transmitions. That makes this implementation not viable, it spends so much time communicating a BBC micro would run faster.
The best implementation I have come up with so far is to put all the chips onto one bus. This give 600 transmitions in the example above. Each chip is told to transmit by the mbed using a matrix similar to the one used to control a screen of LEDs. This makes clashes "impossible". The mbed uses a PWM line as a clock for the whole network, so no need to syncronise clocks as all clocks are the "same". (yes I am ignoring certain annoying bits of reality)
what happens in setup is each chip has an individual address to identify sent packets, and each layer has an address. Each chip listens for a set of addresses, when one arrives that is in that set, it looks at the sending address to identify what its reciving from where, then writes the data into a memory location.
When all information is recived it starts processing it, until its called to send its data, then resumes processing after sending the data.
the processing time is ignored for now.
So what I have worked out is that the addresses for sending and reciving are the same. This makes assigning addresses easier. These form a 16 bit unsigned int. data is in the form of 32 bit floating point numbers. so a packet looks like this
16 bit unsigned int
16 bit unsigned int
32 bit float
...
packet lengths are fixed so the chips not reciving the packet count to the end of the packet.
so the question is how do I do the transmition? Can I use a protocol that exists to do the actual communication, and use normal I/O to trigger the transmitions? then there is speed, how fast can I do these 600 transmitions? sending 64 bits 600 times gives 38400 bits. which at 1MB is 26 times a second. but can I get to >1MB practicaly? (for the problems I have in mind, thats pretty fast)
I haven't done much networking, so would rather not waste time looking at ways that are impractical. so pointers for where to start would be nice.
there is a possiblity of running multiple busses at once to reduce idle time, but I want to get one working before playing with that.