You must be logged in to reply.

Page 2 of 2 out of 18 messages.

SPI TinyClr

Posted 1yr ago
by John_ghielectroncs | Employee
Posted 1yr ago
by John_ghielectroncs | Employee
Post has been deleted.
Reply #11 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
Reply #11 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
@Bauland - Yes, that is correct hardware connections.
You may or may not be able to get away with the GPIO_NONE parameter in the SPI.Configuration statement.

Phil
Reply #12 — Posted 1yr ago (modified)
by Bauland | Master | 6,336 exp
Reply #12 — Posted 1yr ago (modified)
by Bauland | Master | 6,336 exp
It is working !!! Dancing Dancing

I received my first event ! After some byte order problems, I can now implement these complete module.

Many thanks to PHITEK, John, and Brett for tips, advices ...

If I can propose a functionnality for TinyClr is adding a paramter to specify in which order data are read (Msb or Lsb), it would be very nice. As a workaround, I added this extensions:
public static void ReadLsb(this SpiDevice spi, byte[] readBuffer)
        {
            spi.Read(readBuffer);

            InvertBytes(readBuffer);
        }

        private static void InvertBytes(byte[] bytes)
        {
            // Iterate over all bytes
            for (var i = 0; i < bytes.Length; i++)
            {
                if (bytes[i] == 0 || bytes[i] == 0xFF)
                    continue;

                byte output = 0;

                for (var j = 0; j < 8; j++)
                {
                    output <<= 1;
                    output |= (byte)(bytes[i] & 0x01);
                    bytes[i] >>= 1;
                }

                bytes[i] = output;
            }
        }
Reply #13 — Posted 1yr ago
by John_ghielectroncs | Employee
Reply #13 — Posted 1yr ago
by John_ghielectroncs | Employee
@Bauland - If you can find somewhere in the existing desktop/IoT UWP API where data order can be specified for SPI, we'd have an easier time implementing it.
Reply #14 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
Reply #14 — Posted 1yr ago
by PHITEK | Senior | 2,250 exp
@Bauland - Just curious did the GPIO_NONE work or did you have to use an actual GPIO pin?

Nice work!

Phil
Reply #15 — Posted 1yr ago
by Bauland | Master | 6,336 exp
Reply #15 — Posted 1yr ago
by Bauland | Master | 6,336 exp
@John - I find it nowhere that's why I said it is a suggestion of functionnality Cheesy

@PHITEK: I use an unused pin as, for now, I can't find an equivalent to GPIO_NONE in TinyClr.
1 like
Reply #16 — Posted 1yr ago
by marius | Senior | 1,272 exp
Reply #16 — Posted 1yr ago
by marius | Senior | 1,272 exp
For the actual reversing of the byte, I found the following to be a nice tradeoff between speed, size and maintainability....

unsigned char reverse(unsigned char b) {
   b = (b & 0xF0) >> 4 | (b & 0x0F) << 4;
   b = (b & 0xCC) >> 2 | (b & 0x33) << 2;
   b = (b & 0xAA) >> 1 | (b & 0x55) << 1;
   return b;
}

(http://www.hackersdelight.org/)

A lookup table will probably be the fastest but has the biggest size.
Array stepping is the most understandable (maintainability), but is probably the slowest.
Reply #17 — Posted 1yr ago
by Bauland | Master | 6,336 exp
Reply #17 — Posted 1yr ago
by Bauland | Master | 6,336 exp
marius says:

For the actual reversing of the byte, I found the following to be a nice tradeoff between speed, size and maintainability....

A lookup table will probably be the fastest but has the biggest size.
Array stepping is the most understandable (maintainability), but is probably the slowest.

Lookup table seems to me a bad idea indeed for microcontroller.
Your idea seems fine. Only test can say what is best solution. I don't know if I'll have time to that.

Page 2 of 2 out of 18 messages.

You must be logged in to reply.