I was wondering if anyone could help with this problem I have. I've used adafruits MAX31855 thermocouples, we're trying to get the data from it to a duet2 board. The problem is that there's too much distance between duet2 and the thermocouples so we have to have two arduinos in the middle which also hold other functionality.
If the thermocouples are connected to the duet board, the temperature data comes in perfectly. But when I'm transferring the data from arduino duet2 reads the data completely wrong. I guess the easiest we would be to get the arduino to mimic the thermocouple as being in slave mode. I've tried different ways of moving the data but the values are gibberish when read from the duet board. Here's one solution I've tried:
#include <SPI.h>
//#define SLAVE_SELECT1 2
uint32_t tempVal = 105650432;
union {
uint32_t data;
byte bytes[4];
} sender;
void setup (void)
{
Serial.begin (115200); // debugging
// turn on SPI in slave mode
SPCR |= bit (SPE);
SPCR |= _BV(SPIE);
// have to send on master in, slave out
pinMode(MISO, OUTPUT);
// get ready for an interrupt
pos = 0; // buffer empty
process_it = false;
SPI.setBitOrder(LSBFIRST);
//SPI.attachInterrupt();
}
// main loop - wait for flag set in interrupt routine
void loop (void)
{
sender.data = tempVal;
while(digitalRead(SS) == LOW){
sender.bytes[0];
sender.bytes[1];
sender.bytes[2];
sender.bytes[3];
}
} // end of loop
the tempVal is binary I converted into uint32_t, it holds two temperature values I copied them from the pdf on this post and put them on the right place. Here's the binary:
00000110 01001100 00011001 00000000
If you look at the screenshot it shows how the data should be organized. I've tried sending it in different ways, switching between LSB and MSB. Trying different byte orders.
There's probably something I'm missing in the code. I'm using arduino mega to transfer the data.
Does anybody know how to make arduino mega into a slave that would be able to send the data in a similar manner as the thermocouple daughterboard does?
That code does nothing of use. What do you expect it to do? A link to that "duet2" might help too.
An SPI slave must use the SPI interrupt otherwise it won't be fast enough. At the moment I don't see where you read the thermocouple. I guess the posted code is just a first try to get warm with SPI slave programming. The variable you use in the loop and in the SPI interrupt handler must be declared volatile otherwise the compiler might optimize it away.
Thank you for your answer! The duet 2 or duet2 wifi if you please can be found from this link: Duet 3D . They manufacture opensource electronic controllers that can be used in 3d printers, cnc machines and other such robots. They have their own firmware and user interface that is used from the browser.
I suppose I should've mentioned this before but at the moment there's no temperature reading in the script. What I'm trying to do for now is get the arduino to send a fixed temperature value to duet2. Duet2 reads the Max thermocouple without an issue but there's other things in effect that prevents connecting the thermocouple to duet2 directly. So what we've tried to do is to make the arduino emulate the thermocouple and send the data to Duet the same way as the MAX thermocouple would do it.
So I picked for the dummy values temperatures from these charts that were provided from the pdf (in the screenshots).
For the temperatuer that should be in bits 31-18 I chose the temperatue +100.75 (0000 0110 0100 11) Celcius, and for the temp in bits 15-4 I chose temperature +25.00 (0001 1001 0000). Now on top of this you have to take the fault and reserved bits into consideration but because this is a dummy value I set everything to zero (meaning there's no fault).
All in all I got this string of bits (0000 0110 0100 1100 0001 1001 0000 0000). The pdf says that the data needs to be 32 to bits long so I changed this string of bits into an integer using online converter and assigned it in the code to uint32_t. I'm not sure whether or not this is something you can do. If you convert these bits into an int you get 105650432. Any idea does it even send uint32_t like this so that it sends also the last five zeros after the last 1? (assuming you send them least significant bit first).
I tried sending it in different orders since if you send it one byte at a time and each byte goes LSB then you should send the bytes in reverse so that everything goes in the right way. Still nothing.
But assuming that the data is in correct form then I guess there's something else that is set up wrongly in the code. I did have the attachinterrupt() included in the code also at some point. I guess I need to try declaring them volatile as well as you said.
Any other ideas what I might be missing? Any help is greatly appreciated!
They manufacture opensource electronic controllers that can be used in 3d printers, cnc machines and other such robots. They have their own firmware and user interface that is used from the browser.
Wouldn't it be much easier to modify the open source firmware of that board than trying to emulate an ADC hardware chip?
I tried sending it in different orders since if you send it one byte at a time and each byte goes LSB then you should send the bytes in reverse so that everything goes in the right way. Still nothing.
As I wrote: your code isn't sending anything. It's more or less doing nothing.
How do you expect to get to the actual thermocouple reading in the final version? You cannot use the Mega2560's SPI interface to simulate an SPI chip and read the MAX registers.
Sorry for the late response. Yeah I guess when I was struggling with this script I had put a version of the code that sends nothing. It was a quite stressful moment of our project so I guess I wasn't on top of the game while posting this here I did try some communication if I remember correctly. We ended up using a work around that didn't have anything to do with arduinos.
Would I have been able to send data from another arduino that's reading the thermocouples to mega by using another communication protocol and then simulate SPI chip with the mega? Or is this something that cannot be done?
I did try some communication if I remember correctly. We ended up using a work around that didn't have anything to do with arduinos.