GCGB has an 'SPI transfer' block which reads data to a variable.
The MAX31855 outputs 32 bits when chip select is low. How can I read these 32 bits in GCGB?
Does the variable 'SPI transfer' uses need to be a certain type? GCGB wouldn't let me use a 32 element array. It lets me use Byte but I need more than 8 bits.
Do I just repeat the 'SPI transfer' 4 times to get 32 bits and save each one to a byte?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried reading a byte 4 times and saving it to the EEPROM on the chip (PIC16F914). I've attached the block diagram from GCGB.
If I save SPI_Inp1-4 to the EEPROM it has 00 00 00 00 saved there. If I output SPI_Inp1 to a set of 7 segment displays (tested previously) it shows 256, which I guess it the same as 0.
Can you check/confirm you get correct values displayed on your LCD. Send some static numbers/text to the LCD. I assume this works.
Save and retrieve EEPROM data. Can you confirm that the I2C hardware and code is working? Save some fix numbers to the EEPROM and retrieve. Use and if statement to test and set an LED on or off dependent on the results. So, if you save 0x55 you should get 0x55 returned from the EEPROM. I assume that this works.
Now, if those tests worked we can be sure that the issue is with the SPI code/config.
Post results of the two tests above. Meanwhile, I will scratch my head. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have given up on the MAX31855 for now, I was taking power from a USB lead which I think has fried it...
I had already kinda done the tests you suggested Anobium.
- I wrote 00 to FF to the EEPROM, then read it back from the chip (via the programmer) and it was correct
- I was using an array of 7 segment LED displays to display values, driven by a clock input into 4026 ICs. I'd already tested this by sending random numbers to it and it worked fine
- Yesterday I got an LCD display which I connected up. It didn't seem to work off port C or D but worked with the data lines connected to port B
I connected SDI to SDO on the PIC (a 16F914) and tried sending '1' then displaying what was received on the LCD but all I got was 0.
I did some googling and came across this page: http://www.piclist.com/techref/microchip/spi.htm
The first comment is that SPI doesn't work automatically, and you have to set SDI as an input and SDO as an output.
I set these in GCGB and it worked! :) Whatever I send out comes back in on SDI and comes up on the LCD.
I'm not sure if this is a bug or just something that might be worth mentioning in the help file.
Rather than tying to do a massive screenshot I've attached my .gcb file in case anyone wants to see how it works.
Hope this comes in useful for someone else. Once I get a MAX31855 working I will post back.
I'm trying to read data from a MAX31855.
GCGB has an 'SPI transfer' block which reads data to a variable.
The MAX31855 outputs 32 bits when chip select is low. How can I read these 32 bits in GCGB?
Does the variable 'SPI transfer' uses need to be a certain type? GCGB wouldn't let me use a 32 element array. It lets me use Byte but I need more than 8 bits.
Do I just repeat the 'SPI transfer' 4 times to get 32 bits and save each one to a byte?
Looking at the HWSPI code... it returns a single byte.
Please let us know if this code works for you. Please post example code so others may learn from your experience.
Thank.
Thanks anobium, I will give it a try this evening.
I tried reading a byte 4 times and saving it to the EEPROM on the chip (PIC16F914). I've attached the block diagram from GCGB.
If I save SPI_Inp1-4 to the EEPROM it has 00 00 00 00 saved there. If I output SPI_Inp1 to a set of 7 segment displays (tested previously) it shows 256, which I guess it the same as 0.
I am travelling, so be patience with me.
Trying to figure this out....
Can you check/confirm you get correct values displayed on your LCD. Send some static numbers/text to the LCD. I assume this works.
Save and retrieve EEPROM data. Can you confirm that the I2C hardware and code is working? Save some fix numbers to the EEPROM and retrieve. Use and if statement to test and set an LED on or off dependent on the results. So, if you save 0x55 you should get 0x55 returned from the EEPROM. I assume that this works.
Now, if those tests worked we can be sure that the issue is with the SPI code/config.
Post results of the two tests above. Meanwhile, I will scratch my head. :-)
I have given up on the MAX31855 for now, I was taking power from a USB lead which I think has fried it...
I had already kinda done the tests you suggested Anobium.
- I wrote 00 to FF to the EEPROM, then read it back from the chip (via the programmer) and it was correct
- I was using an array of 7 segment LED displays to display values, driven by a clock input into 4026 ICs. I'd already tested this by sending random numbers to it and it worked fine
- Yesterday I got an LCD display which I connected up. It didn't seem to work off port C or D but worked with the data lines connected to port B
I connected SDI to SDO on the PIC (a 16F914) and tried sending '1' then displaying what was received on the LCD but all I got was 0.
I did some googling and came across this page: http://www.piclist.com/techref/microchip/spi.htm
The first comment is that SPI doesn't work automatically, and you have to set SDI as an input and SDO as an output.
I set these in GCGB and it worked! :) Whatever I send out comes back in on SDI and comes up on the LCD.
I'm not sure if this is a bug or just something that might be worth mentioning in the help file.
Rather than tying to do a massive screenshot I've attached my .gcb file in case anyone wants to see how it works.
Hope this comes in useful for someone else. Once I get a MAX31855 working I will post back.