The benefits are:
* More i/o pins remain available for other use
* Fewer wires to so lower cost and lower likelihood of wiring errors
* Impossible to mixup input, output, tx, rx pins…
But don’t forget the GND wire. There’s no such thing as 1 wire…
T4, SPI, DMA multiple transactions, MISO and MOSI are tristate and one pin
- Thread starter sicco
- Start date
* More i/o pins remain available for other use
* Fewer wires to so lower cost and lower likelihood of wiring errors
* Impossible to mixup input, output, tx, rx pins…
But don’t forget the GND wire. There’s no such thing as 1 wire…
Rezo
Well-known member
@sicco hey
I've come back to the slave SPI stuff as I now have a newer CDJ panel that is configured as an SPI master
It has four wire setup which is wired to SPI on my T4.0
I've been playing around with tens of sketches using Claude generated code and no matter which version I use (Claude or yours)
If I disable the TX DMA channel (eg it does not trigger at all) then the RX data stream is stable, and all the data is present.
As soon as TX DMA channel is enabled, that's where things get messy as I had experienced before.
Even more, on simple polling or interrupt driven Slave, as soon as I load data into the TDR register, it does the same thing. But if I don't touch it, the RX data stream is fine.
I find it odd that this is the behavior, as there are Slave SPI examples in the McuExpresso repository for most of the RT10xx series.
I've come back to the slave SPI stuff as I now have a newer CDJ panel that is configured as an SPI master
It has four wire setup which is wired to SPI on my T4.0
I've been playing around with tens of sketches using Claude generated code and no matter which version I use (Claude or yours)
If I disable the TX DMA channel (eg it does not trigger at all) then the RX data stream is stable, and all the data is present.
As soon as TX DMA channel is enabled, that's where things get messy as I had experienced before.
Even more, on simple polling or interrupt driven Slave, as soon as I load data into the TDR register, it does the same thing. But if I don't touch it, the RX data stream is fine.
I find it odd that this is the behavior, as there are Slave SPI examples in the McuExpresso repository for most of the RT10xx series.
Rezo
Well-known member
Master is a CDJ1000 mk3 panel
Mode3. MSB first. 27 byte long frame.
4 wires in total: MISO, MOSI, CLK and CS between 7-10cm long. I can't go any shorter.
Wired to SPI on the T4 via a logic level converter as the CDJ is 5v logic
CS->10 , MOSI->11, MOSI->12, SCLK->13
(Tomorrow I will be getting parts to test another logic level converter based on a 74HC245)
When running your version of the DMA SPI slave from post #40 I get a readout of 29 bytes counted and half of the data is invalid
Frames from the CDJ panel always start with 0x01 0x10 as well as byte 20-23 that always have the value 0xF1, 0x64, 0x76, and are 27 bytes long
I was playing around with the library and disabled things such as the TX DMA channel, not loading the TX FIFO with dummy data etc and when doing that I got a stable data stream on the RX
Mode3. MSB first. 27 byte long frame.
4 wires in total: MISO, MOSI, CLK and CS between 7-10cm long. I can't go any shorter.
Wired to SPI on the T4 via a logic level converter as the CDJ is 5v logic
CS->10 , MOSI->11, MOSI->12, SCLK->13
(Tomorrow I will be getting parts to test another logic level converter based on a 74HC245)
When running your version of the DMA SPI slave from post #40 I get a readout of 29 bytes counted and half of the data is invalid
Code:
n=0, [>0] 0 us traffic for 0 bytes, est. f_SCK = nan MHz,
n=1, [>34] 01 10 3f ff ff ff 80 81 01 80 00 00 03 ff ff 80 c0 00 00 00 00 00 00 00 00 00 38 00 00 00 00 00 00 00 633 us traffic for 34 bytes, est. f_SCK = 0.43 MHz,
n=2, [>32] 3f c5 91 d8 00 00 00 01 88 1f ff ff ff c0 40 40 1e 00 00 01 ff ff c0 38 00 00 00 00 00 00 00 00 633 us traffic for 32 bytes, est. f_SCK = 0.40 MHz,
n=3, [>30] 00 00 00 00 03 1f 8b 23 b0 00 00 00 01 88 1f ff ff ff c0 40 40 20 00 00 01 ff ff 00 00 00 638 us traffic for 30 bytes, est. f_SCK = 0.38 MHz,
n=4, [>30] c0 18 00 00 00 00 00 03 3f 8b 23 b0 00 00 00 01 88 1f ff ff ff c0 40 40 1e 00 00 00 00 00 643 us traffic for 30 bytes, est. f_SCK = 0.37 MHz,
n=5, [>29] 01 ff ff 03 00 00 00 00 00 00 63 f1 64 76 00 00 00 01 c6 0f ff ff ff e0 20 20 1a 00 00 650 us traffic for 29 bytes, est. f_SCK = 0.36 MHz,
n=6, [>29] 00 00 03 ff fc 0c 00 00 00 00 00 01 9f c5 91 d8 00 01 88 1f ff ff ff c0 40 40 1e 00 00 633 us traffic for 29 bytes, est. f_SCK = 0.37 MHz,
n=7, [>29] 00 00 01 ff fe 06 00 00 00 00 00 00 c7 e2 c8 ec 00 01 88 1f ff ff ff c0 40 40 1a 00 00 634 us traffic for 29 bytes, est. f_SCK = 0.37 MHz,
n=8, [>29] 00 00 07 ff f8 18 00 00 00 00 00 02 ff 8b 23 b0 00 01 88 1f ff ff ff c0 40 40 1e 00 00 636 us traffic for 29 bytes, est. f_SCK = 0.36 MHz,
n=9, [>30] 00 00 01 ff fe 06 00 00 00 00 00 00 c7 e2 c8 ec 00 01 c6 0f ff ff ff e0 20 20 0e 00 00 00 654 us traffic for 30 bytes, est. f_SCK = 0.37 MHz,
n=10, [>29] 00 00 00 ff ff 03 00 00 00 00 00 00 5f f1 64 76 00 01 88 1f ff ff ff c0 40 40 1e 00 00 638 us traffic for 29 bytes, est. f_SCK = 0.36 MHz,
n=11, [>29] 00 00 01 ff fe 06 00 00 00 00 00 00 c7 e2 c8 ec 00 01 88 1f ff ff ff c0 40 40 1e 00 00 651 us traffic for 29 bytes, est. f_SCK = 0.36 MHz,
n=12, [>29] 00 00 01 ff fe 06 00 00 00 00 00 00 c7 e2 c8 ec 00 01 88 1f ff ff ff c0 40 40 1e 00 00 635 us traffic for 29 bytes, est. f_SCK = 0.37 MHz,
n=13, [>29] 00 00 01 ff fe 06 00 00 00 00 00 00 c7 e2 c8 ec 00 01 c6 0f ff ff ff e0 20 20 1a 00 00 648 us traffic for 29 bytes, est. f_SCK = 0.36 MHz,
n=14, [>29] 00 00 03 ff fc 0c 00 00 00 00 00 01 9f c5 91 d8 00 01 88 1f ff ff ff c0 40 40 1e 00 00 632 us traffic for 29 bytes, est. f_SCK = 0.37 MHz,
n=15, [>29] 00 00 01 ff fe 06 00 00 00 00 00 00 c7 e2 c8 ec 00 01 88 1f ff ff ff c0 40 40 1a 00 00 635 us traffic for 29 bytes, est. f_SCK = 0.37 MHz,
n=16, [>29] 00 00 07 ff f8 18 00 00 00 00 00 02 ff 8b 23 b0 00 01 88 1f ff ff ff c0 40 40 1a 00 00 655 us traffic for 29 bytes, est. f_SCK = 0.35 MHz,
n=17, [>29] 00 00 07 ff f8 18 00 00 00 00 00 02 ff 8b 23 b0 00 01 88 1f ff ff ff c0 40 40 0e 00 00 648 us traffic for 29 bytes, est. f_SCK = 0.36 MHz,Frames from the CDJ panel always start with 0x01 0x10 as well as byte 20-23 that always have the value 0xF1, 0x64, 0x76, and are 27 bytes long
I was playing around with the library and disabled things such as the TX DMA channel, not loading the TX FIFO with dummy data etc and when doing that I got a stable data stream on the RX
Looks like it reports many more bytes received than what your master sent. Strong hint that your SPI clock signal at the slave input really sees more than 27*8 edges. And thus registers more bytes received while the CS was low.
As it depends on what’s in the TX buffer, it may well be the case that edges on the SPI slave SDO line get coupled back into the SPI clock line.
Try tying the GND connections on master and slave together in a ground plane fashion. The leads you used look like poor quality and long. Check ohms of each wire, end to end.
The logic level converters may also cause trouble. Caps on both 5V and 3V power rails? Circuit diagram?
If you have a good scope ( >= 500 MHz) then look at how the GND pin on the Teensy differs from the GND on your SPI master. Because that GND wire is too long, too high ohms, or picking up edges from nearby digital lines. And look at how SDO edges end up causing double clock edges when master sends out just one edge.
PS this is not your level shifter i hope?
(this will push 5V high levels onto the 3V power rail... the hysteresis will not work as intended… caps on the CLK and DATA lines…)
(this will push 5V high levels onto the 3V power rail... the hysteresis will not work as intended… caps on the CLK and DATA lines…)
Rezo
Well-known member
This is the level shifter I used (but from AliExpress) and while I can read packages, Its not sending them nicely
But, I did get the components today to build out a logic level shifter based on the 75HC245, but the pullups were wired idividually to 5v, and the buffer's vcc and control pins to 3.3v
I measured the B side to make sure I was getting 3.3v
I spent a few days using your codebase and experimented with Claude and got it to work very well
Wires are +10cm to the HC245, then another 10cm wires to the Teensy
All RXing and TXing is stable
I'm attaching a ZIP with the uncleaned code (lots of serial prints) but it does work great
But, I did get the components today to build out a logic level shifter based on the 75HC245, but the pullups were wired idividually to 5v, and the buffer's vcc and control pins to 3.3v
I measured the B side to make sure I was getting 3.3v
I spent a few days using your codebase and experimented with Claude and got it to work very well
Wires are +10cm to the HC245, then another 10cm wires to the Teensy
All RXing and TXing is stable
I'm attaching a ZIP with the uncleaned code (lots of serial prints) but it does work great
