2 x MMA7455L with two SPI drivers
electroscott
Posts: 2
NOTE: Please see the response below this for a sample .spin object that demonstrates the problem I'm having. In the CON section, one can change the pins that connect to the ACCEL object to either the gripper accelerometer or the body accelerometer, where the corresponding accelerometer will return values and the other accelerometer will not allow its data line to get pulled down. CS and CLK work from both drivers, the issue is the data line. Thanks.
EDIT: Swapped the SPI control lines for the two accelerometers in the code (not on the hardware). The result is that the accelerometer that is connected to the gripper arm works and the accelerometer that's on the main breadboard returns 0xFF. With this, I have verified that the driver is indeed working okay, and even the hardware.
For example, the accelerometer on the main breadboard has the following configuration:
CS = 10
DAT = 11
CLK = 12
And the accelerometer on the robot's gripper arm has the following pin configuration:
CS = 17
DAT = 18
CLK = 19
**Edit: Please note that the pins listed above are for clarity of signals, the actual pin names are representative of the accelerometer that they are assigned to, so there is not a name conflict here.
I have two separate objects, called ACCEL and GRACC, respectively, that each run in its own cog to handle the SPI communication with the respective accelerometer. It does not matter if I initialize ACCEL first or GRACC first, I get the same problem. I have verified that both cogs are running after instantiation. These objects are the "MMA7455L_SPI_V2".
Again, if I initialize the ACCEL object with pins 10-12, I am able to connect with the breadboard's accelerometer and the GRACC object returns 0xFF for the acceleration values. If I initialize the GRACC object with pins 17-19, I am able to connect with the gripper arm's accelerometer and the breadboard's accelerometer returns 0xFF. The accelerometer read routines are nearly identical, with the difference being a call to the respective object. For example,
It appears that my *real* problem turns out to be two instances of this object? Is anyone using two of the MMA7455L_SPI_V2 objects successfully?
Thanks,
--Scott
*** original ***
I'm developing a 4WD mobile robot platform for my control systems capstone design project and am using a propeller professional development board, a propeller USB servo board (as a slave CPU) and two of the Parallax MMA7455L accelerometers.
The accelerometer that I have on the main board is working, but when I place a second accelerometer on the gripper (about 9" away, but connected with decent wire), I get all 0xFF for my readings. I've tried to place a capacitor across the power lines to decouple any noise but that didn't help. Eventually, I found that I could get a spurious signal if I tied the data line low through a 2.2k Ohm resistor.
I believe I'm having issues with the "automatic" data direction circuitry. I'm powering the MMA7455L with a 5V supply (due to convenience and other factors) but the propeller that's running on the professional development board is obviously 3.3V. There are similar "automatic" data transceivers on the propeller USB servo controller as well and I spent about 20 hours debugging why I couldn't get a master/slave communications working.
The trouble with the servo controller was when trying to get the propeller on the USB servo board to talk with the propeller on the PPDB. Looking at my 'scope, I saw the com channel swinging between 5V and 3.3V (approx., IIRC) and no amount of pull-ups or pull-downs on either supply rail got the bidirectional transmission device to register a proper hi/low signal to the 3.3V propeller CPU. I fixed this problem by monitoring the USB servo propeller's transmission line and feeding that into the base of a PNP/NPN combination. The maximum baud rate that I'm able to get is 230400 bps but I'll accept that.
Since the MMA7455L accelerometer has a similar data transceiver (as that used on the USB servo controller), I suspect that changes in supply voltages, noise, and/or lead length are affecting its ability to pull the data line low. As such, I'm reading 0xFF on all of my accelerometer channels. All of the SPI communication lines have been monitored with an oscilloscope and are found to be working. For reference, both accelerometers are being driven by the propeller on the PPDB. The oscilloscope shows about 16 clocks (these haven't been counted but they appear to be operating properly) and the CS line gets pulled low during an accelerometer packet reading. The data line shows an address being sent but the data line just ends up floating.
Has anyone else had issues with these so-called automatic bidirectional bus transceivers--in particular, coming from a 5V to a 3.3V propeller? I believe the issue comes from the transceiver not being able to properly tell the direction of the signal flow. I haven't found a workaround for bidirectional data lines like one would see on I2C devices, for example. My solution for the two propeller CPUs was to use two separate Rx/Tx lines. This is not possible with the accelerometer.
Any help would be GREATLY!!! appreciated.
--Scott
EDIT: Swapped the SPI control lines for the two accelerometers in the code (not on the hardware). The result is that the accelerometer that is connected to the gripper arm works and the accelerometer that's on the main breadboard returns 0xFF. With this, I have verified that the driver is indeed working okay, and even the hardware.
For example, the accelerometer on the main breadboard has the following configuration:
CS = 10
DAT = 11
CLK = 12
And the accelerometer on the robot's gripper arm has the following pin configuration:
CS = 17
DAT = 18
CLK = 19
**Edit: Please note that the pins listed above are for clarity of signals, the actual pin names are representative of the accelerometer that they are assigned to, so there is not a name conflict here.
I have two separate objects, called ACCEL and GRACC, respectively, that each run in its own cog to handle the SPI communication with the respective accelerometer. It does not matter if I initialize ACCEL first or GRACC first, I get the same problem. I have verified that both cogs are running after instantiation. These objects are the "MMA7455L_SPI_V2".
Again, if I initialize the ACCEL object with pins 10-12, I am able to connect with the breadboard's accelerometer and the GRACC object returns 0xFF for the acceleration values. If I initialize the GRACC object with pins 17-19, I am able to connect with the gripper arm's accelerometer and the breadboard's accelerometer returns 0xFF. The accelerometer read routines are nearly identical, with the difference being a call to the respective object. For example,
PUB Accel_Read8Bit
xyzVals[accel_X] := (accel.read(accel#XOUT8) + xyzOffset[accel_X])
xyzVals[accel_Y] := (accel.read(accel#YOUT8) + xyzOffset[accel_Y])
xyzVals[accel_Z] := (accel.read(accel#ZOUT8) + xyzOffset[accel_Z])
PUB GrAcc_Read8Bit
GRxyzVals[gracc_X] := (gracc.read(gracc#XOUT8) + GRxyzOffset[gracc_X])
GRxyzVals[gracc_Y] := (gracc.read(gracc#YOUT8) + GRxyzOffset[gracc_Y])
GRxyzVals[gracc_Z] := (gracc.read(gracc#ZOUT8) + GRxyzOffset[gracc_Z])
It appears that my *real* problem turns out to be two instances of this object? Is anyone using two of the MMA7455L_SPI_V2 objects successfully?
Thanks,
--Scott
*** original ***
I'm developing a 4WD mobile robot platform for my control systems capstone design project and am using a propeller professional development board, a propeller USB servo board (as a slave CPU) and two of the Parallax MMA7455L accelerometers.
The accelerometer that I have on the main board is working, but when I place a second accelerometer on the gripper (about 9" away, but connected with decent wire), I get all 0xFF for my readings. I've tried to place a capacitor across the power lines to decouple any noise but that didn't help. Eventually, I found that I could get a spurious signal if I tied the data line low through a 2.2k Ohm resistor.
I believe I'm having issues with the "automatic" data direction circuitry. I'm powering the MMA7455L with a 5V supply (due to convenience and other factors) but the propeller that's running on the professional development board is obviously 3.3V. There are similar "automatic" data transceivers on the propeller USB servo controller as well and I spent about 20 hours debugging why I couldn't get a master/slave communications working.
The trouble with the servo controller was when trying to get the propeller on the USB servo board to talk with the propeller on the PPDB. Looking at my 'scope, I saw the com channel swinging between 5V and 3.3V (approx., IIRC) and no amount of pull-ups or pull-downs on either supply rail got the bidirectional transmission device to register a proper hi/low signal to the 3.3V propeller CPU. I fixed this problem by monitoring the USB servo propeller's transmission line and feeding that into the base of a PNP/NPN combination. The maximum baud rate that I'm able to get is 230400 bps but I'll accept that.
Since the MMA7455L accelerometer has a similar data transceiver (as that used on the USB servo controller), I suspect that changes in supply voltages, noise, and/or lead length are affecting its ability to pull the data line low. As such, I'm reading 0xFF on all of my accelerometer channels. All of the SPI communication lines have been monitored with an oscilloscope and are found to be working. For reference, both accelerometers are being driven by the propeller on the PPDB. The oscilloscope shows about 16 clocks (these haven't been counted but they appear to be operating properly) and the CS line gets pulled low during an accelerometer packet reading. The data line shows an address being sent but the data line just ends up floating.
Has anyone else had issues with these so-called automatic bidirectional bus transceivers--in particular, coming from a 5V to a 3.3V propeller? I believe the issue comes from the transceiver not being able to properly tell the direction of the signal flow. I haven't found a workaround for bidirectional data lines like one would see on I2C devices, for example. My solution for the two propeller CPUs was to use two separate Rx/Tx lines. This is not possible with the accelerometer.
Any help would be GREATLY!!! appreciated.
--Scott
Comments
URL: http://ar.blueelectronlabs.com/TwoAccelTest.spin
Thanks for checking,
--Scott Thompson
I`m starting with the MMA7455L and I read the code you posted, but I`m not quite a programmer and gets confused for me. Could you give me a tip or a simple code to trie the accelerometer .
Thanks in advance
Pitu
I have used 2 spi devices before at the same time, although not the mma7455L. in mine i let the clk and dat share the same two pins into the prop but had separate pins for each chip select (cs) and had no problems getting data from both. Might be worth a try to see if it helps.
i couldn't get the code from the link above,