Rask Ingemann Lambertsen wrote: > Hardware SPI likely wasn't designed with the dual protocol accelerometers > in mind. IIRC there's a comment in arch/arm/mach-s3c2442/mach-gta02.c about > the workaround needed to keep the I2C-mode accelerometer from responding.
What I described happened on SDIO in SPI mode, so it's a genuine 2442 SPI hardwre problem, not related to the accelerometer's SPI/I2C mode. Whether the SPI vs. I2C logic could actually misfire on the "deselected" accelerometer is something we never fully analyzed. SDI/SDA should only change if SPC/SCL is low, so this would prevent the I2C transceiver from ever seeing a START condition. > I suppose reception could be realigned by prepending a dummy bit to the > bit stream or by removing the first 7 bits. A D-flipflop or two could do > the former I think. Ah, interesting idea. If the shift is in the right direction (I think it is) and happens all the time (I didn't test this), adding a software-generated SPI clock pulse may indeed help. > Do we know if the receive misalignment is triggered by the 12 MHz > frequency or by the clock divider to get 12 MHz from 50 MHz PCLK? Since > we'll be using 66 MHz PCLK in gta02-core, it would be nice to know. All my tests were done on a GTA02. I did't try a different PCLK. You're right, depending on what actually causes the problem inside the 2442, how you divide the clock may make a difference. Okay, so we have some more ideas for getting that beast faster than 12 MHz in gta02-core. Thanks ! - Werner _______________________________________________ gta02-core mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/gta02-core
