Giter Site home page Giter Site logo

spi's Introduction

spi's People

Contributors

crteensy avatar frankboesing avatar h4yn0nnym0u5e avatar kurte avatar mjs513 avatar paulstoffregen avatar sumotoy avatar vjmuzik avatar xxxajk avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

spi's Issues

SPI1 & SPI2 need compiler better compiler error messages.

If you use SPI1 or SPI2 and compile for a Teensy 3.2/3.1 it gives a generic error .

error: 'SPI1' was not declared in this scope
SPI1.begin();

If possible it would be nice to say these functions are only usable in T3.5/T3.6 instead of a generic error message that we get. Took me about 2 hours to figure out why it was throwing errors.

constexpr construction of SPI objects on Teensy 4 but not Teensy 3.6

I have longstanding projects running on T3.6 that have been stable but now crash silently after late_startup_hook() and before setup() if compiled under 1.58 or 1.59 beta3.

I tracked my issues to the fact that SPI construction is no longer happening as a constexpr, so the devices do not exist when I call them in the constructors of other objects.

I see that the problem has been recognized, understood, and solved for some libraries:
https://forum.pjrc.com/index.php?threads/problem-with-two-wire-build-between-11-3-1-and-5-4-1.73176/#post-328856
https://forum.pjrc.com/index.php?threads/teensy-4-1-does-not-boot-when-invoking-spi-from-external-class.73154/

Running a slightly modified version of the Teensyduino_Test_constinit_XXX code from one of those threads, I see Wire works correctly on both, but SPI works only on T4 and fails on T3.6.

= = = = = = = = = = = = = = = = = = = =
T4.1
Wire, SPI, and HWSerial all have been fixed:
= = = = = = = = = = = = = = = = = = = =

**startup_late_hook**
Wire: var #1 = 403F0000
Wire: var #2 = 60001F14
Wire1: var #1 = 403F8000
Wire1: var #2 = 60001E74
Wire2: var #1 = 403FC000
Wire2: var #2 = 60001E74
SPI: var #1 = 403A0000
SPI: var #2 = 200004B8
SPI1: var #1 = 4039C000
SPI1: var #2 = 20000448
SPI2: var #1 = 40394000
SPI2: var #2 = 200003D8
Serial: var #1 = 40198000
Serial: var #2 = 20000378
Serial2: var #1 = 40190000
Serial2: var #2 = 20001028
Serial3: var #1 = 40188000
Serial3: var #2 = 20000F68
Serial4: var #1 = 4018C000
Serial4: var #2 = 20000FC8
Serial5: var #1 = 401A0000
Serial5: var #2 = 20001148
Serial6: var #1 = 40184000
Serial6: var #2 = 20000F08
Serial7: var #1 = 4019C000
Serial7: var #2 = 200010E8
Serial8: var #1 = 40194000
Serial8: var #2 = 20001088

**setup**
Wire: var #1 = 403F0000
Wire: var #2 = 60001F14
Wire1: var #1 = 403F8000
Wire1: var #2 = 60001E74
Wire2: var #1 = 403FC000
Wire2: var #2 = 60001E74
SPI: var #1 = 403A0000
SPI: var #2 = 200004B8
SPI1: var #1 = 4039C000
SPI1: var #2 = 20000448
SPI2: var #1 = 40394000
SPI2: var #2 = 200003D8
Serial: var #1 = 40198000
Serial: var #2 = 20000378
Serial2: var #1 = 40190000
Serial2: var #2 = 20001028
Serial3: var #1 = 40188000
Serial3: var #2 = 20000F68
Serial4: var #1 = 4018C000
Serial4: var #2 = 20000FC8
Serial5: var #1 = 401A0000
Serial5: var #2 = 20001148
Serial6: var #1 = 40184000
Serial6: var #2 = 20000F08
Serial7: var #1 = 4019C000
Serial7: var #2 = 200010E8
Serial8: var #1 = 40194000
Serial8: var #2 = 20001088

= = = = = = = = = = = = = = = = =
T3.6
Wire has been fixed, but SPI has not:
= = = == = = = = = = = = = = = =

**startup_late_hook**
Wire: var #1 = 40066000
Wire: var #2 = 2700
Wire1: var #1 = 40067000
Wire1: var #2 = 26C0
Wire2: var #1 = 400E6000
Wire2: var #2 = 26C0
SPI: var #1 = 0
SPI: var #2 = 0
SPI1: var #1 = 0
SPI1: var #2 = 0
SPI2: var #1 = 0
SPI2: var #2 = 0

**setup**
Wire: var #1 = 40066000
Wire: var #2 = 2700
Wire1: var #1 = 40067000
Wire1: var #2 = 26C0
Wire2: var #1 = 400E6000
Wire2: var #2 = 26C0
SPI: var #1 = 4002C000
SPI: var #2 = 2744
SPI1: var #1 = 4002D000
SPI1: var #2 = 27D8
SPI2: var #1 = 400AC000
SPI2: var #2 = 286C

= = = = = = = = = = = = = = = = = = = =
Here is the code that produces this output:

#include <Wire.h>
#include <SPI.h>

// Separate version for T4 vs T3 because T4 has portAddr while T3 has port_addr
#if defined(__IMXRT1062__)   // T4
uintptr_t Teensyduino_Test_constinit_Wire(int instance, int index) {
    if (instance == 0) {
        if (index == -1) return (uintptr_t)("Wire");
        if (index == 0) return 2;
        if (index == 1) return Wire.portAddr;   // probably should decide whether it is portAddr or port_addr and use the same thing everywhere
        if (index == 2) return (uintptr_t)&Wire.hardware;
    }
    if (instance == 1) {
        if (index == -1) return (uintptr_t)("Wire1");
        if (index == 0) return 2;
        if (index == 1) return Wire1.portAddr;
        if (index == 2) return (uintptr_t)&Wire2.hardware;
    }
    if (instance == 2) {
        if (index == -1) return (uintptr_t)("Wire2");
        if (index == 0) return 2;
        if (index == 1) return Wire2.portAddr;
        if (index == 2) return (uintptr_t)&Wire2.hardware;
    }
#if defined(ARDUINO_TEENSY_MICROMOD)
    if (instance == 3) {
        if (index == -1) return (uintptr_t)("Wire3");
        if (index == 0) return 2;
        if (index == 1) return Wire3.port_addr;
        if (index == 2) return (uintptr_t)&Wire3.hardware;
    }
#endif
    return 0;
}
#else   // Not T4
uintptr_t Teensyduino_Test_constinit_Wire(int instance, int index) {
    if (instance == 0) {
        if (index == -1) return (uintptr_t)("Wire");
        if (index == 0) return 2;
        if (index == 1) return Wire.port_addr;
        if (index == 2) return (uintptr_t)&Wire.hardware;
    }
    if (instance == 1) {
        if (index == -1) return (uintptr_t)("Wire1");
        if (index == 0) return 2;
        if (index == 1) return Wire1.port_addr;
        if (index == 2) return (uintptr_t)&Wire2.hardware;
    }
    if (instance == 2) {
        if (index == -1) return (uintptr_t)("Wire2");
        if (index == 0) return 2;
        if (index == 1) return Wire2.port_addr;
        if (index == 2) return (uintptr_t)&Wire2.hardware;
    }
#if defined(ARDUINO_TEENSY_MICROMOD)
    if (instance == 3) {
        if (index == -1) return (uintptr_t)("Wire3");
        if (index == 0) return 2;
        if (index == 1) return Wire3.port_addr;
        if (index == 2) return (uintptr_t)&Wire3.hardware;
    }
#endif
    return 0;
}
#endif

// constexpr construction of SPI objects on Teensy 4 but not Teensy 3
uintptr_t Teensyduino_Test_constinit_SPI(int instance, int index) {
    if (instance == 0) {
        if (index == -1) return (uintptr_t)("SPI");
        if (index == 0) return 2;
        if (index == 1) return SPI.port_addr;
        if (index == 2) return SPI.hardware_addr;
    }
    if (instance == 1) {
        if (index == -1) return (uintptr_t)("SPI1");
        if (index == 0) return 2;
        if (index == 1) return SPI1.port_addr;
        if (index == 2) return SPI1.hardware_addr;
    }
    if (instance == 2) {
        if (index == -1) return (uintptr_t)("SPI2");
        if (index == 0) return 2;
        if (index == 1) return SPI2.port_addr;
        if (index == 2) return SPI2.hardware_addr;
    }
    return 0;
}

// Can't run this section on teensy 3 because T3 HardwareSerial does not have .port_addr or portAddress or .hardware 
#if defined(__IMXRT1062__)
uintptr_t Teensyduino_Test_constinit_HardwareSerial(int instance, int index) {
    if (instance == 0) {
        if (index == -1) return (uintptr_t)("Serial");
        if (index == 0) return 2;
        if (index == 1) return Serial1.port_addr;
        if (index == 2) return (uintptr_t)Serial1.hardware;
    }
    if (instance == 1) {
        if (index == -1) return (uintptr_t)("Serial2");
        if (index == 0) return 2;
        if (index == 1) return Serial2.port_addr;
        if (index == 2) return (uintptr_t)Serial2.hardware;
    }
    if (instance == 2) {
        if (index == -1) return (uintptr_t)("Serial3");
        if (index == 0) return 2;
        if (index == 1) return Serial3.port_addr;
        if (index == 2) return (uintptr_t)Serial3.hardware;
    }
    if (instance == 3) {
        if (index == -1) return (uintptr_t)("Serial4");
        if (index == 0) return 2;
        if (index == 1) return Serial4.port_addr;
        if (index == 2) return (uintptr_t)Serial4.hardware;
    }
    if (instance == 4) {
        if (index == -1) return (uintptr_t)("Serial5");
        if (index == 0) return 2;
        if (index == 1) return Serial5.port_addr;
        if (index == 2) return (uintptr_t)Serial5.hardware;
    }
    if (instance == 5) {
        if (index == -1) return (uintptr_t)("Serial6");
        if (index == 0) return 2;
        if (index == 1) return Serial6.port_addr;
        if (index == 2) return (uintptr_t)Serial6.hardware;
    }
    if (instance == 6) {
        if (index == -1) return (uintptr_t)("Serial7");
        if (index == 0) return 2;
        if (index == 1) return Serial7.port_addr;
        if (index == 2) return (uintptr_t)Serial7.hardware;
    }
#if defined(ARDUINO_TEENSY41)
    if (instance == 7) {
        if (index == -1) return (uintptr_t)("Serial8");
        if (index == 0) return 2;
        if (index == 1) return Serial8.port_addr;
        if (index == 2) return (uintptr_t)Serial8.hardware;
    }
#endif
    return 0;
}
#endif

void print_info(uintptr_t(*f)(int, int)) {
    int instance = 0;
    while (1) {
        const char* name = (char*)f(instance, -1);
        if (!name) break;
        int count = f(instance, 0);
        for (int i = 1; i <= count; i++) {
            uintptr_t n = f(instance, i);
            Serial.print(name);
            Serial.print(": var #");
            Serial.print(i);
            Serial.print(" = ");
            Serial.println(n, HEX);
        }
        instance++;
    }
}

// must appear separately before the function definition else ld complains about multiple definitions
extern "C" void startup_late_hook();    

void startup_late_hook() {
    while (!Serial); // wait for serial monitor
    delay(15);
    Serial.println("startup_late_hook");
    print_info(Teensyduino_Test_constinit_Wire);
    print_info(Teensyduino_Test_constinit_SPI);
#if defined(__IMXRT1062__)
    print_info(Teensyduino_Test_constinit_HardwareSerial);
#endif
}

void setup() {
    Serial.println("\nsetup");
    print_info(Teensyduino_Test_constinit_Wire);
    print_info(Teensyduino_Test_constinit_SPI);
#if defined(__IMXRT1062__)
    print_info(Teensyduino_Test_constinit_HardwareSerial);
#endif
}

void loop() {
    delay(1);
}

additional SPI clock choices in SPI.cpp

In forum discussions, a user noted that with T3.6@180mhz (bus 60 mhz), requesting a SPI clock of 4 MHz did not give exactly 4 mhz. Originally, i thought it was just discretization error based on available dividers. But i have a perl script that will give me the "best" CTAR settings for given bus speed and desired SPI clock. There is a CTAR setting (0xb80020002) that gives 4mhz, but it's not in the ctar_div_table in SPI.cpp. You might wish to expand the div and clock table. You have 23 entries, but there are 42 entries with BR in the range 0 to 8.

2 3 4 5 6 7 8 9 10 12 14 15 16 18 20 21 24 28 30 32 40 42 48 56 64 80
96 112 128 160 192 224 256 320 384 448 512 640 768 896 1280 1792

https://forum.pjrc.com/threads/40394-SPI-clock-not-uniform

SPI1 multiple byte transfer on Teensy LC

Hi there, I have been trying to benchmark the SPI bus on my Teensy LC and reproduce some of the results in:

https://forum.pjrc.com/threads/27689-Teensy-LC-Beta-Testing/page3
https://github.com/manitou48/DUEZoo/blob/master/SPIperf.txt

I switched from SPI to SPI1 to get 24 MHz clock, but I couldn't get SPI1 transfer(void *buf, size_t count) to work with my code - the function hangs on the last line in SPI.h:

inline static void transfer(void *buf, size_t count) {
  ...
  *p = SPDR;
}

Looking at the sources in benchmark:

https://github.com/manitou48/teensy3/blob/master/spi1perf.ino

the implementation of spi1_transfer(void *buf, size_t count) is identical to transfer(void *buf, size_t count) apart from the last line, where:

inline static void transfer(void *buf, size_t count) {
  ...
  *p = SPI1_DL;
}

I replaced *p = SPDR with *p = SPI1_DL in transfer(void *buf, size_t count) of SPI1Class and everything seems to be working correctly as far as I can tell.

Many thanks!

P.S.
If that helps, I seem to recall that transfer(void *buf, size_t count) in SPIClass (not SPI1Class) works correctly.

T4 over-driving SCLK

Since commit d10dd99, the Teensy 4.0 in my uBITX/TSW radio has been getting bad data back from the 2.8" SPI touchscreen it controls (identical to the ones available from PJRC).

As best I can tell, configuring the SCLK pin for maximum drive is causing signal integrity issues in my device. I couldn't record it directly, since probing SCLK would make the issue disappear, but MISO showed that the touch controller was sometimes shifting data on half-cycles (where the falling edge would be). I'm not an EE, but most of what I could find about similar clocking issues recommended reducing drive strength. As it turns out, changing the DSE field to anything between 4 and 6 (with any value for SPEED) fixed the SCLK issue for me.

The changes to the clock and divider were discussed at length in the forum and PR #55, but I couldn't find where the changes to DSE and SPEED were explained. Is there a particular need to fix DSE at 7, or could it be bumped down?

Suggestion: Add 8- or 16-bit transfer size setter

Can we have a method that sets the SPI to 8-bit or 16-bit mode, possibly with an enum argument that selects between these transfer sizes? These sizes are the common denominator for Teensy 3.x and Teensy LC.

Transfer size can probably not be added to SPISettings, because that's a part of the common arduino interface, isn't it?

SPI beginTransaction doesn't set outputs level

Hello,

When changing data mode with SPI.beginTransaction(), the clock output is not set to the right level, which can cause issues. For example from mode 3 (idle clock level is high) to mode 0 (idle clock level is low), the clock stay high before the first SPI.transfert() and causes a unwanted falling edge and (some?) devices doesn't like that.

Here is a screenshot: (notice the glitch too)

sds00001

And the associated code:

// SPI transaction in mode 3...
...
SPI.beginTransaction(SPISettings(1000000UL, MSBFIRST, SPI_MODE0));
delayMicroseconds(5); // Just to differentiate the glitch
SPI.transfer(0x40);
SPI.endTransaction();

That is for mode 3 to mode 0, but same deal for the reverse order.

The only workaround I found is to shift a dummy byte without any chip selected before doing the "real" transaction.

Tested with Teensy 3.6 & 3.2.

SPI Issue for multiple device

Hello,
I am interfacing TFT and SD card with arduino mega board and running a simple code, given below, but sd card is not initialized. \

#include "SPI.h"
#include "Adafruit_GFX.h"
#include "Adafruit_ILI9341.h"

#include <Wire.h>
#include <SD.h>

#define TFT_RST 8
#define TFT_DC 9
#define TFT_CS A5

File myFile;

Adafruit_ILI9341 tft = Adafruit_ILI9341(TFT_CS, TFT_DC, TFT_RST);

#define HALF_CLOCK_PERIOD 1

void setup()
{
Serial.begin(9600);
SPI.begin();
pinMode(53, OUTPUT);

if (!SD.begin(53)) {
Serial.println("SD initialization failed!");
}
else Serial.println("SD Card initialization done.");

tft.begin();
tft.println("Welcome");
}

void loop()
{

}

When I remove the MISO pin of TFT, at that time SD card is initialized and working normal.
I think it is a SPI based issue. I have tried a lot but could not get the success.
How can i solve the issue?

How can I generate a separate MISO & MOSI pin for SD card and other slaves??

error: 'SPIClass' does not name a type extern SPIClass SPI;

Hallo Paul,
ich habe folgendes Problem beim Kompilieren eines sketches.
Fehlermeldung:

In file included from InternetClock_ILI9341.ino:18:0:
C:\Users\uengel\Documents\Arduino\libraries\SPI/SPI.h:1378:8: error: 'SPIClass' does not name a type
extern SPIClass SPI;
^
In file included from InternetClock_ILI9341.ino:19:0:
C:\Users\uengel\Documents\Arduino\libraries\TFT_ILI9341_ESP/TFT_ILI9341_ESP.h:496:13: error: 'SPIClass' does not name a type
SPIClass *_SPI;
^

Ich verwende IDE 1.6.5 und den sketch aus dem Tutorial:
http://embedded-lab.com/blog/tutorial-8-esp8266-internet-clock/?unapproved=2458495&moderation-hash=81156ba4e4b884bbeaff565d3e6be302#comment-2458495

Da ich Anfänger bin, habe ich bis jetzt keine Erklärung für den SPI-Fehler.
Kannst Du helfen?

Danke
Ulli

TFT_ILI9341_ESP-master.zip
InternetClock_ILI9341.zip

SSD 1306 Oled not working properly with HW SPI and Teensy 4.0

I have an 2.42 inch Oled display wired to the Hardware SPI port of the Teensy 4.0.
SCK 13
MOSI 11
CS 10
DC 8
RST 9

When I use the Adafruit SSD1306 only the top 8 pixels of the oled work. The rest is noise.
With the u8g2 library horizontal lines appear on the oled no matter what I do.
The lines are every 8th pixel (7 pixels between the lines).

IMG_0799

The oled works fine with an Arduino Nano with both libraries.

The only library which seems to work fine with the Teensy 4.0 is the Sparkfun HyperDisplay library. But this one is VERY slow.

After much trial and error (which can be followed here) I think this is a hardware SPI Issue with the Teensy code. (If I use the Software SPI functions with the same or different pins in the u8g2 library everything works fine, just slower.)

I tired to upload the code with lower Teensy microprocessor speed (down to 24MHz chosen from the Arduino IDE) but this had no effect on the horizontal lines.

This and this is the oled I use and this is some documentation regarding the driver.

Could there be an issue with the SPI software written for the Teensy 4.0?

I would really appreciate any help in solving this issue. Thank you very much.

SPI usingInterrupt not updated for Teensy 3.5 / 3.6

I use a Teensy 3.5 with Teensyduino 1.44, and I am currently writing a driver for a MCP2517FD CAN controller. The INT pin of MCP2517FD is connected to pin #38. I have written that the SPI is using that pin with SPI1.usingInterrupt (38). But I think that this line has no effect.

I have examined the SPI.h file and I found the usingInterrupt function (from line 468). I think this function is valid for Teensy 3.1/3.2, but has not been updated for Teensy 3.5 / 3.6. Adding "|| n == 38" at the end of line 473 solved my issue (#38 is PTC11).

I suggest the following replacement for this function:

#if defined(__MK20DX128__) || defined(__MK20DX256__)
void usingInterrupt(uint8_t n) {
if (n == 3 || n == 4 || n == 24 || n == 33) {
usingInterrupt(IRQ_PORTA);
} else if (n == 0 || n == 1 || (n >= 16 && n <= 19) || n == 25 || n == 32) {
usingInterrupt(IRQ_PORTB);
} else if ((n >= 9 && n <= 13) || n == 15 || n == 22 || n == 23
|| (n >= 27 && n <= 30)) {
usingInterrupt(IRQ_PORTC);
} else if (n == 2 || (n >= 5 && n <= 8) || n == 14 || n == 20 || n == 21) {
usingInterrupt(IRQ_PORTD);
} else if (n == 26 || n == 31) {
usingInterrupt(IRQ_PORTE);
}
}
#elif defined(__MK64FX512__) || defined(__MK66FX1M0__)
void usingInterrupt(uint8_t n) {
if (n == 3 || n == 4 || (n >= 25 && n <= 28) || (n >= 39 && n <= 42)) {
usingInterrupt(IRQ_PORTA);
} else if (n == 0 || n == 1 || (n >= 16 && n <= 19) || (n >= 29 && n <= 32) || (n >= 43 && n <= 46) || n == 49 || n == 50) {
usingInterrupt(IRQ_PORTB);
} else if ((n >= 9 && n <= 13) || n == 15 || n == 22 || n == 23 || (n >= 35 && n <= 38)) {
usingInterrupt(IRQ_PORTC);
} else if (n == 2 || (n >= 5 && n <= 8) || n == 14 || n == 20 || n == 21 || n == 47 || n == 48 || (n >= 51 && n <= 55)) {
usingInterrupt(IRQ_PORTD);
} else if (n == 24 || n == 33 || n == 36 || n == 56 || n == 57) {
usingInterrupt(IRQ_PORTE);
}
}
#endif

Best regards,

Pierre Molinaro

spi.transfer n number of bytes

would it be possible to be able to set the val to other than 8 or 16? or the ability to write buffer with out the buffer being over written.
I want to send a 32bit variable, but i want to send it multiple times but i don't always know how many times.

So my choices seem to be

  1. save the entire string to a variable and then write it, but if i want to send the same data 1,000 times that a going to eat up the memory

  2. write to spi using 8/16 bit spi.tranfer(val), but then i have to split the 32bit value up and have lots of loops

  3. use the send buffer to send the 32bit value but then i have to rewrite the value back before i send again ( as the buffer gets over written)

It would be nice to simple be able to send an arbturity number of bytes with out having the buffer overwritten.

setDataMode inline and non-inline

Hi,
in the header file line 290 there is:
inline static void setDataMode(uint8_t dataMode) {
SPCR = (SPCR & ~SPI_MODE_MASK) | dataMode;
}
however the same function is also used in the cpp file, without the core SPCR activity:

void SPIClass::setDataMode(uint8_t dataMode)
{
hardware().clock_gate_register |= hardware().clock_gate_mask;
//uint32_t ctar = port().CTAR0;

// TODO: implement with native code
//SPCR = (SPCR & ~SPI_MODE_MASK) | dataMode;

}

I find it quite strange, that there is both an inline and a non-inline function with the same name.
At least on my system windows 10, Arduino 1.8.1 teensyduino 1.4.1 calling setDataMode had no effect at all. I assume without proof it was calling the non-inline version which does not set SPCR.

My proposal would be to remove the non-inline version, and maybe add the hardware().clock_gate line to the inline version if necessary, or make it non-inline.

My personal workaround was to use the transactions stuff, but really without any complaints to the maintainer, it cost me two days to find the reason why my pcb worked with an old arduino version, and failed with a newer one. Thanks to logic tester i finally found that the data mode was set, but the statement had no effect. I know how crappy the job of maintaining something like this is, all the work that went in so far is highly appreciated.

thanks a lot & very nice greetings,
Bernhard Kubicek

Use of deprecated functions.

Hi there. thanks for this amazing tool.
I've read recently about the new use of beginTransaction to work properly with several slave devices.
I'm wondering what should be the best approach to remove old methods such: bitOrder and setMode to work properly with beginTransaction when the code only works with only one slave.

I've read that there is no need to use settings if only one slave is used, but not use how to proceed is I need to remove deprecated methods.

Thanks in advances

32 bit data transfer?

I'm using teensy 4.1

Is it possible to send 32 bit data as shown here?
0b00000000000000000000000000000111 is beeing sent out (DATA-blue, CS-red, CLK-yellow)
IMG_20200706_193856 (Kopiowanie)

Because currently I can only manage to get this using this SPI.h library:
IMG_20200706_221629

and this code:

 SPI1.beginTransaction(settings);
SPI1.transfer(0x00);
SPI1.transfer(0x00);
SPI1.transfer(0xFF);
SPI1.transfer(0x00);
SPI1.endTransaction();

Clock distortion after 8 bits, and CS high, is issue for me.
As far as I know teensy 4.1 processor should be able to do 32bit SPI data transfers.

Regards Mateusz

SPIClass does not name a type

When compiling with a Teensy 3.1, I received the following error: "SPIClass does not name a type". Reverting back to your version on Dec 21, 2014 solves the problem. Thanks for all the hard work!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.