MX3cK with two PmodAD5 (DSPI0 and DSPI1)

Created Wed, 13 May 2015 15:26:48 +0000 by sebdev

sebdev

Wed, 13 May 2015 15:26:48 +0000

I am successfully running one PmodAD5 on connector JE of a Cerebot MX3cK in master mode with DSPI0 using mpide.

So, now I try to use DSPI1 on JB (in -locked- master mode).

I changed in "AD7193.h" "DSPI0" to "DSPI1":

/*! Communication definitions */
#define AD7193_CS_PIN 			PIN_DSPI1_SS
#define DEVICE_SPI_CLK_FREQ     1000000	/*!< 1MHz SPI clock frequency */
/*! AD7193 GPIO */
#define AD7193_RDY_STATE       (PIN_DSPI1_SS + 2) /*!< MISO pin */

and

DSPI1 oDspi;

It compiles and runs, but, values are bad. Any clues ?!

It looks like "AD7193_RDY_STATE" is pin "+2" (e.g. "(PIN_DSPI?_SS + 2)"), which is ok for DSPI0 (i.e. SPI2) as pins are ordered: JE-01: SS2 RG9 JE-02: MOSI2 RG8 JE-03: MISO2 RG7 JE-04: SCK2 RG6

but, it seems that it is not the case for DSPI1 (i.e. SPI1) JB-01: SS1 RD9 (used for SS output) JB-02: MOSI1 RF3 (i.e. SDO1) JB-03: MISO1 RF2 (i.e. SDI1) JB-04: SCK1 RF6

Is there any schematics to get the right pinout and corresponding number ?

note: extract from "chipKIT32-MAX/hardware/pic32/variants/Cerebot_MX3cK/Board_Defs.h":

/* ------------------------------------------------------------ */
/*					SPI Pin Declarations						*/
/* ------------------------------------------------------------ */
/* These symbols are defined for compatibility with the original
** SPI library and the original pins_arduino.h
*/
const static uint8_t SS   = 32;		// PIC32 SS2
const static uint8_t MOSI = 33;		// PIC32 SDO2
const static uint8_t MISO = 34;		// PIC32 SDI2
const static uint8_t SCK  = 35;		// PIC32 SCK2

/* The Digilent DSPI library uses these ports.
**		DSPI0	connector JE
**		DSPI1	connector JB
*/
#define	PIN_DSPI0_SS	32
#define	PIN_DSPI1_SS	8		// only usable as a master, not a slave

FredCailloux

Tue, 29 Dec 2015 21:30:32 +0000

Hello SebDev, I happen to have the same problem. After hours of investigation with the little beginner knowledge that I have in this field I came to the conclusion that the 7193 library is not yet compatible to exploit all 3 SPI channels for that board. I have an MX7 which can address 3 SPI modules via JD JE and JF. JD is the default DSPI0. Yet the 7193 library is not (as it is) compatible with all 3 JD JE and JF. Only JD would fit the 7193 class, using DSPI0 which is pin programmed in the DSPI class.

I am still on the investigation mode here but I think that the solution lies in the creation of another class library that will override some code lines in the 7193 class so that by #Including that cls7193JE.h (for example), the effect would be that pin numbers would be changed to correct correspondences. Of course this class would have to be #Included After the #Include 7193.h so as to override correctly.

I have not found the correct way to do that and I think I am going to need some help from some experts. (Anyone out there for help ?!) For one, I am not sure how to implement an override of variable definition. At least those code lines must be override

#define AD7193_CS_PIN 			PIN_DSPI0_SS // must be changed to override to PIN_DSPI1_SS
#define AD7193_RDY_STATE       (PIN_DSPI0_SS + 2) // must also be override to PIN_DSPI1_MISO (if it exist at all ?? )
...
class AD7193 {
private:
	DSPI0 oDspi; // must be override to DSPI1 oDspi; here the oDspi variable may no have to be changed at all I think.
	char mGain;   // it's just in internal name not visible from outside the call. In fact, it MUST not be changed
	char mPolarity;
	double mVref;

If you can Add to this attempt. Any help and suggestions are welcome. Majenko can you pitch in? Your help has always been of great value in my other inquiries 8-)

Good Luck :!: And please let me know if you hit the JackPot :lol:

majenko

Tue, 29 Dec 2015 22:44:22 +0000

Can you point me to the library you're using? I can't seem to find it.

FredCailloux

Tue, 29 Dec 2015 23:06:11 +0000

Here it is, Taken from the Microchip WEB site AD7193 - No-OS Driver for Microchip Microcontroller Platforms https://wiki.analog.com/resources/tools-software/uc-drivers/microchip/ad7193 See attached ad7193_arduino.zip Thanks

majenko

Tue, 29 Dec 2015 23:28:13 +0000

I can see absolutely no reason for it not to work with a different DSPI - as long as the other pins are set properly.

The only caveat is that the MISO pin used for RDY_STATE might not really be returning the right thing - since it's assigned to part of the SPI peripheral and not digital IO. It may be purely chance that it's been working with DSPI0.

I would be inclined to add a bit of register tweaking to disable the MISO pin and return it to the control of digitalRead(). Do it just after the SPI channel has been configured:

oDspi.begin(AD7193_CS_PIN);
oDspi.setMode(DSPI_MODE3);
oDspi.setSpeed(DEVICE_SPI_CLK_FREQ);
SPI1CONbits.DISSDI = 1; // <--- Add this line

FredCailloux

Wed, 30 Dec 2015 00:51:54 +0000

This answer is way too hi-tech for my brain but I am going to make an effort to understand it :mrgreen: First: > the MISO pin used for RDY_STATE might not really be returning the right thing - since it's assigned to part of the SPI peripheral and not digital IO. It may be purely chance that it's been working with DSPI0.

I revised carefully the pinout from PmodAD5 and the JD or JE or JF on the MX7ck and they really seam to be the correct pins for proper communication. The MISO pin on the MX7ck is definitely identified as such on pin JD-03 marked as SDI1, which is a digital input pin into the PIC32MX795. This pin is identified as being the input for the SPI1. As for the matching PmodAD5 pin J1-03 it is marked as an output named DOUT/RDY. Furthermore, on the AD7193 functional block diagram DOUT/RDY is clearly marked as being part of the 4 required pins to implement SPI communication protocol. I am puzzled by your explanation. Can you elaborate a little. Second: > SPI1CONbits.DISSDI = 1; // <--- Add this line

Where is this variable defined. I tried to look into the Board_Defs.h and .c, I also looked into the DSPI.h and .c and also into 7193.h and .c and I also search the sketch AD7193.pde (from the Microchip zip file). Cant find any reference to this definition SPI1CONbits. Can you pls guide me on what this line of code will do ?

Third and last: > I can see absolutely no reason for it not to work with a different DSPI - as long as the other pins are set properly.

There are no provisions in the AD7193.pde sketch for a user to be able to set pins or define another virtual SPI port ? How would you to that ? Do you mean that one would need to modify the 7193.h and .c library ?

majenko

Wed, 30 Dec 2015 10:49:06 +0000

When SPI is enabled it takes over alll the IO lines that provide the SPI functionality. That includes the SDI pin. The library uses digitalRead on the SDI pin to read the state of the RDY pin, which won't work while SPI is enabled. Either the RDY pin needs to be read using SPI or SPI needs to be turned off on that pin while reading. After sleeping on it that instruction to disable SDI is probably not such a good idea since it will break data reception (by the way, that 'variable' is defined in the processor's header file in the compiler). Instead the bit of code that reads the RDY state needs rewriting so that it can work in parallel with the SPI functionality.

I don't have one of these PMOD boards to try things out with at the moment unfortunately, but I'll try and get hold of one to experiment with.

Sent from my SM-T555 using Tapatalk

FredCailloux

Wed, 30 Dec 2015 15:25:10 +0000

If I understand correctly, what you are saying is that while the SDI pin is under the SPI class control, one cannot read it's state just by peeking the pin with another digitalRead ? That would mean the all SPI dedicated pins are inaccessible from outside the SPI class ?

majenko

Wed, 30 Dec 2015 15:42:03 +0000

That is correct.

In the library is this bit of code:

void AD7193::WaitRdyGoLow(void)
{
    while( digitalRead(AD7193_RDY_STATE) )
    {
        ;
    }
}

Since AD7193_RDY_STATE points to SDI, and SDI is under the control of the SPI module, not GPIO, reading from it will not work right, and will most likely just return LOW regardless of what is happening on the pin itself - so it will always think it's ready whether it is or not. So that snippet needs to be wrapped in some code to allow access to the raw value of the SDI pin and then return control back to the SPI peripheral afterwards. That is, unless I am mistaken and it can read the value anyway (I'm not 100% sure on that at the moment - I'm going to do some experimenting).

majenko

Wed, 30 Dec 2015 15:59:09 +0000

Actually, it seems I may be talking complete gibberish here. It looks like digitalRead() can still get at the raw value on the pin even when SPI is running. So everything I have been saying is actually wrong.

Ok. I think I may have just found the real reason why it's not working...

The SPI 1 pins are the same pins as are used for the USB / UART (FT232) interface. You cannot use the serial interface and SPI1 at the same time. Enabling serial (Serial::begin(...)) kills SPI. Enabling SPI (DSPI1::begin()) kills the serial. So it's one or the other, but not both.

FredCailloux

Wed, 30 Dec 2015 16:39:48 +0000

We're getting there :!: I just looked at the proMX7 manual for pin identifications on JD-03 JE-03 and JF-03. Here is what we find: JD-03 is T5CK/SDI1/RC4 - JE-03 is SDA1A/SDI1A/U1ARX/RF2 - JF-03 is SDA3A/SDI3A/U3ARX/PMA9/CN17/RF4 respectively we find that JD-03 is SDI1 - JE-03 is SDI1A and U1ARX - JF-03 is SDI3A and U3ARX - Of course if U1ARX is used by the communicate with the serial windows on UECIDE, one cannot use this example sketch with DSPI1 because it uses this com port for transmitting the 7193 Analog values. But that would not prevent me from using JE if my application would not use the com port, would it ? Question 2: What about JF ? Question 3: I still have not found a way to tell the 7193 example sketch which DSPI port to use, DSPI0 via SPI1 on JD, DSPI1 via SPI3 on JE or DSPI2 via SPI4 on JF

FredCailloux

Sat, 02 Jan 2016 00:21:58 +0000

Continuing my investigation on the AD7193.h and .cpp I just found that there are two versions of the DSPI library. One is from the arduino architecture and the other is for the Digilent chipKIT SPI Library (hence DSPI). Why two different versions ? What is the difference ? Which one should I use for my proMX7 board ? Are both DSPI library functional on the MX7 ?

thanks Fred