Hi,
The easiest way to do multi-point PCB level connection would probably be with I2C and the I2Cmulti driver. The RTC plus at least 10 other devices (including the NBs) will all be able to be on the same 2 wire bus with no extra hardware. The driver will allow you to give each device its own address and any collisions should be handled by the driver. The only problem is that this interface is not too fast... default it is about 100Kbit and you can increase the speed to about 300-400Kbit depending on the capacitance load on the bus.
Ethernet with a simple off the shelf switch will be a quick solution plus the transfer speeds will be in the 50+mbit range if you are using UDP.
You can use a FPGA to share data on the processor bus. A dual port SRAM chip might even be a better solution since the hardware is already done for you. This will probably yield the highest bandwidth but requires external hardware at the PCB level.
If you can free up one of the 3 UARTs then you can get pretty high bandwidth by using synchronous serial. This is another interface that would require no external hardware, just 3 wires (rx,tx,clk). In my testing of this I was easily able to get 10+mbit transfers between modules. This method will also use one of the DMA timer inputs for the UART clk input. You probably will need to use a DMA timer output on one of the modules to generate the clock for all of the UARTS.
I would stay away from the QSPI if you are using the SD Card interface. Sharing this bus can be tricky. There is also no slave interface for this bus so you will need external hardware such as an FPGA or FIFO to convert the master to a slave. If you are going to do the external hardware you should probably go the processor bus route which will be faster and easier to code on the software end.
-Larry
Sharing data between modules: switch req'd or other ways?
-
Ridgeglider
- Posts: 513
- Joined: Sat Apr 26, 2008 7:14 am
Re: Sharing data between modules: switch req'd or other ways?
Hi Chris:
Good questions... There are a few reasons for separate modules. Not sure I can give full background, but something along these lines.
1) We are close to IO limited on the 5234 with a fairly busy system that's pushing available timing windows.
2) This means mods or additions nearly always influence (perturb?) the other tasks via IO availability or bandwidth.
2) In some ways our system is a delivery vehicle (literally). A lot of the system resources are used getting us to a destination, following a perscribed path, or getting us back in case of various failures (eg declining of batteries). However along the way, or when we get to a destinaton we need to support relatively unrelated science experiments. These experiments may need data from the vehicle (where it is, what it's doing, etc) but they essentially run in parallel, sometimes with some of their own add'l sensors.. In fact the results of these science tasks may influence or modify mission objectives path, and or trajectory. (mars rover is a reasonable analogy). Separate platforms might provide a clean way to provide separate, safe play pens for the vehicle itself and for the science experimets. I think it would also allow science tasks to be coded relatively independently w/o intimate knowlwdge of the underlying vehicle and its idiosyncracies. Finally, separate modules definatley give you more bandwidth and IO flexibility. All this makes me think of sharing data via UDP and a simple switch since we'd need the switch anyhow to program the modules.
Good questions... There are a few reasons for separate modules. Not sure I can give full background, but something along these lines.
1) We are close to IO limited on the 5234 with a fairly busy system that's pushing available timing windows.
2) This means mods or additions nearly always influence (perturb?) the other tasks via IO availability or bandwidth.
2) In some ways our system is a delivery vehicle (literally). A lot of the system resources are used getting us to a destination, following a perscribed path, or getting us back in case of various failures (eg declining of batteries). However along the way, or when we get to a destinaton we need to support relatively unrelated science experiments. These experiments may need data from the vehicle (where it is, what it's doing, etc) but they essentially run in parallel, sometimes with some of their own add'l sensors.. In fact the results of these science tasks may influence or modify mission objectives path, and or trajectory. (mars rover is a reasonable analogy). Separate platforms might provide a clean way to provide separate, safe play pens for the vehicle itself and for the science experimets. I think it would also allow science tasks to be coded relatively independently w/o intimate knowlwdge of the underlying vehicle and its idiosyncracies. Finally, separate modules definatley give you more bandwidth and IO flexibility. All this makes me think of sharing data via UDP and a simple switch since we'd need the switch anyhow to program the modules.