i2c data rate calculation
I'm not a huge fan of images with text... but this time excel was the right way to illustrate it. 







The data0 is one byte of data from accelerometer 0, data1 is one byte of data from accelerometer 1 etc.

Their data will be sent serially, but you will read in parallel. So the first byte you read will be all the first bits of 8 data registers. The second byte you read will be the all the second bits from the 8 accelerometers. 



As far as I know, each shift and each "&amp;" and each "|" takes at least one clock cycle. So in order to transpose you need to spend some hefty amount of time. For each reg->data you spend 8×AND + 7×OR + 7×shift (this is the solution I came up with on top of my head, it can most likely be optimized, especially the shifting). Then you need to load and read from memory, so I'll guess-assume 10 clocks. So you need to spend at least 8×(8+7+7+10)=256 clocks just to transpose the information. And you need to do it for every byte you read. So (48+48) bits / 8 = 12 bytes. 12×256 = 3072 clocks. I don't know if you got threading or how fast your CPU will be, but 3072 will at least be within the ball park of number of cycles needed to convert the things. It will be some more because you will need to set some interrupts and cases so you know which bit you're on, and function calling. So say 4000 clocks to read all the 96 bits. And all the programming will be.. boring to implement. 



A tiny optimization I just realized, after each clock you can easily do the shifting. That will save several clocks, so 4000 total clocks -> 3500 total clocks. It's just an approximation. 



This is how I would do it. And if I wouldn't have threads/multiple cores/enough speed available then I would split the load onto 2 microcontrollers and use an UART between them. One decodes data to reg and reg to data. The other just reads straight from UART at high speed and keeps the program you're intending to use. Or I would just get some cheap FPGA and implement 8 i2c channels there + an uart.