tuncated uint8_t

Hi all!

I need to set a SPI which is 159 bits long. This is the code:

Code:

---

SpiTransfer(FALSE, SPI_SETTING_, F_1KHZ_, Spi_Word, Spi_Readback, DATA_LENGTH_);

---

And this is the array which keeps the SPI word:

Code:

---

uint8_t Spi_Word[20]=
{
0x00, 0x00, 0x26, 0x05, 0x00,
0x01, 0x68, 0x00, 0x0F, 0x80,
0x00, 0x00, 0x00, 0x00, 0xC1,
0xCF, 0x72, 0xE8, 0x60, 0x20,
};

---

The problem is that the SPi_Word gets truncated, but I don't know why... Besides I don't know why it gets truncated, I don't know how to solf this issue.

Any help would be appreciated,

Regards,

Coen

What do you mean "truncated"? I don't see anything directly wrong in what you've posted.

Is "DATA_LENGTH_" 20, or something else? How does it get turned into indices into the data array?

What actual data do you get out "the other side"?

--
Mats

Thanks for the reply,

DATA_LENGTH_ is indeed 20.
Instead of sending 0x26 (00100110), it sends 0x4C (01001100).
So the MSB is truncated off.

So what does the functin SpiTransfer look like?

--
Mats

The function looks like this:

Code:

---

typedef uint8_t __stdcall SpiTransfer_type(uint8_t LsbFirst, uint8_t SPIMode, uint8_t speed, uint8_t *pwrite, uint8_t *pread, uint16_t len);

extern SpiTransfer_type *SpiTransfer;

---

And this is the (terrible) description of the function:

- If LsbFirst is true (1), the first bit transfered is the LSB (Bit 0), if it is false (0), the MSB (Bit 7) will be transfered first.
- SPIMode defines the idle state of the clockline and the edges data is transfered:
Bit 0 = 0: The Idle state of SCK is 0. The leading edge is a 0 to 1 transition, trailing edge a 1 to 0 transition
Bit 0 = 1: The Idle state of SCK is 1. The leading edge is a 1 to 0 transition, trailing edge a 0 to 1 transition
Bit 1 = 0: Data is sampled at leading edge of SCK and Setup on the trailing edge
Bit 1 = 1: Data is sampled at trailing edge of SCK and Setup on the leading edge
- Speed selects the bitrate of the bus:
0 = 50 kHz
1 = 25 kHz
2 = 10 kHz
3 = 5 kHz
4 = 2 kHz
5 = 1 kHz
- pWrite is an pointer to the data-block what needs to be send.
- pRead is a pointer to the buffer where the read data can be stored. If you’re not interested in the received data you can set pRead to null.
- Len specifies the count of byte to be transfered.

Well, that's not the function itself, it's just the declaration of the function pointer...

Nothing in there indicates that it would send fewer bits than 8 out of each byte.

--
Mats

But it does send out 8 bits, only shifted 1 bit to the left. This causes the MSB to be truncated off, and causes the LSB to be 0.

Quote:

---

Originally Posted by Coens

But it does send out 8 bits, only shifted 1 bit to the left. This causes the MSB to be truncated off, and causes the LSB to be 0.

---

And you know for sure it's THAT word that is missing the MSB, and not one of the preceeding 0 values?

Is it sending out 159 bits, or 139 bits?

--
Mats

I've written a testprogram, it shows the data what it should be and what it has send. This is what I get:

Code:

---

00: Send: 00 Received: 00
01: Send: 00 Received: 00
02: Send: 26 Received: 4c
03: Send: 05 Received: 0a
04: Send: 00 Received: 00
05: Send: 01 Received: 02
06: Send: 68 Received: d0
07: Send: 00 Received: 00
08: Send: 0f Received: 1e
09: Send: 80 Received: 00
10: Send: 00 Received: 00
11: Send: 00 Received: 00
12: Send: 00 Received: 00
13: Send: 00 Received: 00
14: Send: c1 Received: 82
15: Send: cf Received: 9e
16: Send: 72 Received: e4
17: Send: e8 Received: d0
18: Send: 60 Received: c0
19: Send: 20 Received: 03

---

What do you mean with THAT word? Spi_Word?

So, let's look at the transmit function, then... Which is why I asked for that code earlier, but you posted the declaration of the function pointer instead.

--
Mats

Of course, that's what you ment :rolleyes: sorry about that... That function is part of an dll, that's why I posted the description of it.

Quote:

---

Originally Posted by Coens

Of course, that's what you ment :rolleyes: sorry about that... That function is part of an dll, that's why I posted the description of it.

---

Yes, but I expect that's where the problem lies.

--
Mats

I didn't write the dll, so I don't have access to the function itself. But my code is fine as far as you can see?

Quote:

---

Originally Posted by Coens

I didn't write the dll, so I don't have access to the function itself. But my code is fine as far as you can see?

---

Yes. Of course, as soon as you say something like that, someone else comes along and shows the blindingly obvious error ;)

--
Mats

Let's hope so, because this hang up is killing me:(

Either way thank you very much for your help, I really appreciated it!