| View previous topic :: View next topic |
| Author |
Message |
edbfmi1
Joined: 18 Jul 2006
Posts: 94
|
|
 Posted: Thu Mar 22, 2018 4:07 pm |
 |
|
| Where would you recommend adding delays just to give it a try? |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Fri Mar 23, 2018 3:41 am |
|
|
The first place would be before and after every place where you switch devices. I'd want to make sure that the SPI bus is idle before changing, and then allow a little time for the bus to stabilise before operating the CS on the second device.
Have you verified the MAX7219 driver works OK when the bus is only used for this?. Always work 'one step at a time'. |
|
|
edbfmi1
Joined: 18 Jul 2006
Posts: 94
|
|
| Posted: Fri Mar 23, 2018 4:06 am |
|
|
| I will try this when I get into the office this morning. I have verified that the MAX7219 works alone with a short program. I have also verified the MAX31855 works alone so I too believe it is a timing conflict. Just trying to pinpoint it. I also read in some earlier posts that this command is required in the spi_setup function “spi_xmit_l_to_h”. Any thoughts on this? I will try it too and post results. Thanks for the suggestions Ttelmah. |
|
|
edbfmi1
Joined: 18 Jul 2006
Posts: 94
|
|
| Posted: Fri Mar 23, 2018 7:13 am |
|
|
Today's findings.
I added a 10mSec delay after I switch the device before operating the CS.
Still no luck.
I cannot figure out how to implement the "SPI_XMIT_L_TO_H" in my program. Not sure how to add it to | Code: | | #use spi(SPI1, MASTER, MODE=0, bits=32, stream=MAX31855) |
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9093
Location: Greensville,Ontario
|
|
| Posted: Fri Mar 23, 2018 8:21 am |
|
|
OK, I have basic hardware question.. the MAX temp is a 3 volt device, the MAX dsp is a 5 volt device so...
what VDD are you running ? and what's the PIC designed for??
is the MAX temp device a chip or a module( with logic level conversion)
I understand they worked fine as individuals but there may be some 'interaction' when put on the SPI bus
Also does the power supply have enought current for the entire project ?
Others may know about SPI vs VDD, but everytime I see 'mismatched' VDDs, I have to ask about TRUE compatibilty.
Jay |
|
|
edbfmi1
Joined: 18 Jul 2006
Posts: 94
|
|
| Posted: Fri Mar 23, 2018 9:06 am |
|
|
Hi temtronic,
Good point!
I am using a Texas instruments Bidirectional Level Translator IC (LSF0204PWR) between the pic and the MAX31855. It is rated at 100Mhz so I think I am safe with it. But I am open to any ideas! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9093
Location: Greensville,Ontario
|
|
| Posted: Fri Mar 23, 2018 9:41 am |
|
|
OK, so it's probably not a hardware issue....
Maybe code a new program, that after power up and setup, sends all 8s to the display as a 'test all LEDs' function, pause 1/2 second, then loop to read temp/display temp,pause 1 second, then loop forever.
When you say 'display doesn't work', is it wrong numbers or totally blank or garbage ?
There's also the remote possiblity that one variable for the temp function is the same as the disp function ? I haven't checked all the code, just thinking out loud here.
I do KNOW that stream names MUST be in all caps and if #CASE is not set, the compiler forces them as all caps.....
Jay |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Fri Mar 23, 2018 10:02 am |
|
|
| edbfmi1 wrote: | Today's findings.
I added a 10mSec delay after I switch the device before operating the CS.
Still no luck.
I cannot figure out how to implement the "SPI_XMIT_L_TO_H" in my program. Not sure how to add it to | Code: | | #use spi(SPI1, MASTER, MODE=0, bits=32, stream=MAX31855) |
|
You don't. The mode number specifies both the XMIT_L_TO_H setting, and the sample edge. The table of conversions is:
| Code: |
//Table showing old CCS mode settings, MicroChip mode settings, and
//the mode numbers
// MOTOROLA MICROCHIP CCS
//---------------------------------------------------------------------------------
// SPI Mode 0,1 == CKP = 0, CKE = 0 == SPI_L_TO_H MODE 0
// SPI Mode 0,0 == CKP = 0, CKE = 1 == SPI_L_TO_H | SPI_XMIT_L_TO_H MODE 1
// SPI Mode 1,1 == CKP = 1, CKE = 0 == SPI_H_TO_L | SPI_XMIT_L_TO_H MODE 2
// SPI Mode 1,0 == CKP = 1, CKE = 1 == SPI_H_TO_L MODE 3
|
Are you sure you are selecting the right mode number for the chip?... |
|
|
edbfmi1
Joined: 18 Jul 2006
Posts: 94
|
|
| Posted: Fri Mar 23, 2018 10:20 am |
|
|
At this point I am not sure of anything.
If you go back through the earlier conversation on this thread you will see on Sept 6, 2016 that PCM Programmer looked at the data sheets and came up with Mode 0. |
|
|
edbfmi1
Joined: 18 Jul 2006
Posts: 94
|
|
| Posted: Fri Mar 23, 2018 10:29 am |
|
|
Just for arguments sake, I went back through and changed the mode to 0,1,2,3 on one of the boards that is working and it only works on mode 0.
To answer temtronics question.
When I say the display doesn't work what I mean is it is putting up garbage.
When I look at the data I am sending to the display in a watch window I am sending the correct address and data value but I am getting various random characters and the display flickers all kinds of garbage characters. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Mar 23, 2018 10:35 am |
|
|
What is the manufacturer and part number of the display ? (not the
controller chip, but the display itself, or the display/controller as a unit).
Post a link to the webpage for the display. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Fri Mar 23, 2018 11:30 am |
|
|
As a comment, you do realise you have to do the SPI_xfer as I show, _before_ operating the CS.
Basically the sequence is to switch to the new mode, clock out a dummy byte (which actually sets up the SDO line and clock line as specified for the new mode), and only after this is done, operate the CS. This is what I showed, and is vital. Otherwise the idle levels on the lines may result in the first bit not being correctly clocked. |
|
|
edbfmi1
Joined: 18 Jul 2006
Posts: 94
|
|
| Posted: Fri Mar 23, 2018 11:55 am |
|
|
I think that is what I have done.
| Code: |
void maxsend() // send routine for max7219 to update display
{
delay_us(100);
spi_xfer(MAX7219,0,8); //switches the stream to mode 0
delay_ms(10);
output_low(DISP);
delay_ms(10);
spi_xfer(MAX7219,address,8); //send address
delay_ms(10);
spi_xfer(MAX7219,data,8); //send data
delay_ms(10);
output_high(DISP);
delay_ms(10);
}
|
| Code: |
void readMAX()
{
delay_us(100);
int32 MAXread;
spi_xfer(MAX31855,0,32); //switches the stream to mode 0
delay_ms(10);
output_low(TEMP);
delay_ms(10);
MAXread=spi_xfer(MAX31855,0,32);
delay_ms(10);
output_high(TEMP);
delay_ms(10);
TempByte3=MAXread>>24 & 0xff;
TempByte2=MAXread>>16 & 0xff;
TempByte1=MAXread>>8 & 0xff;
TempByte0=MAXread & 0xff;
} |
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Fri Mar 23, 2018 1:22 pm |
|
|
Looks basically good, except you need to do the same when you switch _back_. On the 31855, you are just starting straight away. Also take the delays down to a few uSec. Many chips don't like having CS operated for a very long time, and in chip terms a delay of just a couple of uSec is plenty. Not a case of 'more is better' here.
If you want to leave the bus setup for the 31855, then do it like:
| Code: |
void maxsend() // send routine for max7219 to update display
{
int8 dummy;
dummy = spi_xfer(MAX7219,0,8); //switches the stream to mode 0
//wait for reply
delay_us(2);
output_low(DISP);
dummy=spi_xfer(MAX7219,address,8); //send address;
dummy=spi_xfer(MAX7219,data,8); //send data
output_high(DISP);
dummy = spi_xfer(MAX31855,0,8); //switch bus back before leaving
}
|
Reading the return ensures the SPI transaction waits to complete. This switches the bus back to 31855 mode before leaving. |
|
|
edbfmi1
Joined: 18 Jul 2006
Posts: 94
|
|
| Posted: Fri Mar 23, 2018 1:33 pm |
|
|
Not to be dense, but I don't see what you mean when you are saying | Quote: | | except you need to do the same when you switch _back_. On the 31855, you are just starting straight away. |
Originally I had the delays set at 10uSec but switched to 10Msec out of frustration. I'll dial it back down to a couple uSec.
Thanks, |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
