Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identify all Teensy4 pins desired for I2S / Audio experiments #1

Open
chipaudette opened this issue Apr 23, 2020 · 38 comments
Open

Identify all Teensy4 pins desired for I2S / Audio experiments #1

chipaudette opened this issue Apr 23, 2020 · 38 comments
Assignees

Comments

@chipaudette
Copy link
Member

There are several I2S buses on the Teensy4, each with their own clock and data pins. Which of these pins should we break out and make available in the RevE hardware?

@chipaudette chipaudette self-assigned this Apr 23, 2020
@chipaudette
Copy link
Member Author

@biomurph @erk1313

See, I do know how to use GitHub to make issues. :)

@chipaudette
Copy link
Member Author

Apparently, they've done lots of development on multi-channel audio since I last checked. They've got 8-channel I2S classes now. It appears one can do up to 8-in / 2-out, or you can flip it around and get 2-in / 8-out. That's pretty hot.

Here's one example, using 8 inputs.

https://github.com/PaulStoffregen/Audio/blob/master/examples/Analysis/PeakAndRMSMeter8Channel/PeakAndRMSMeter8Channel.ino

@chipaudette
Copy link
Member Author

OK, here are the I2S connections that are supported on the T4.

image

I'm not sure which get routed to the two AICs. It looks like there can be several "right" answers, depending upon how the audio library software is configured. Some experimentation will be needed. This is why I'm hoping that the board provides some through-holes to allow me to jumper different Teensy pins to different I2S data lines to the Tympan's AIC and to the AIC shield.

@chipaudette
Copy link
Member Author

@biomurph, can you take a look at these pins and think about whether we can make all of them available to the hacker-user?

@chipaudette chipaudette assigned biomurph and unassigned chipaudette Apr 23, 2020
@biomurph
Copy link
Member

That'a great that the Teensy community pulled off 8 channel audio!
s u r r o u n d s o u n d
I will look into what this means for the schematics that I already put together.

@chipaudette
Copy link
Member Author

FYI, in looking at the Teensy Audio Shield, it looks like the baseline 2-channel I2S pins are (not surprisingly) I2S Port #1 and employing Pins 7 and 8 for the actual data...so "OUT1A" and "IN1". Fine.

Still looking at the Teensy Audio Shield, it looks like*

  • The T4 Pin labeled "OUT1A" is actually receiving data from the audio shield
  • The T4 Pin labeled "IN1" looks to be sending data to the audio shield

This is found purely by looking at Paul's diagrams and tables here: https://www.pjrc.com/store/teensy3_audio.html. Perhaps I'm misinterpreting.

Why do they call it DIN/DOUT??? So confusing! Why not MOSI and MISO??

@biomurph
Copy link
Member

biomurph commented Apr 27, 2020

I put up a spreadsheet with the Rev E pin assignments here.
Image of the spreadsheet below. I am able to fit in both of the I2S busses and only have to move a couple things around. Here are the moves and the potential issues

  • Moved BT_CTS and BT_RTS. I assume these are software defined pins?
  • Moved M_BIAS. This is software defined, so no problems there.

There's still a lot of flexibility for board layout and routing needs.

  • The extra OUT1 pins are assigned to software defined functions in this draft, so they can be moved as needed
  • I have not relocated the SPI bus pins, as this is a feature that we are not using so much.

Lastly, an issue that I am not clear about, so you may be able to provide some illumination. The AIC we're using has a fixed I2C address. That's why we're using two I2C busses on the Teensy 3.6. Will we be able to implement the 8 channel sound? The Teensy only has one more I2S bus on pins 16 and 17.

Screen Shot 2020-04-27 at 12 07 14 PM (2)

@chipaudette
Copy link
Member Author

chipaudette commented Apr 27, 2020

Regarding the BT_CTS and BT_RTS, I'm not sure that I've ever actually used these pins. I'm not sure that I've ever used CTS and RTS (at least, not on-purpose) so I'm not even sure how to use them!

Looking in Tympan.h, where I define all the pins for the different versions of Tympan, the only BT pins that I see are:

    BT_nReset = 34;  //PTE25, active LOW reset
    BT_REGEN = 31;  //must pull high to enable BC127
    BT_PIO0 = 56;   //hard reset for the BT module if HIGH at start.  Otherwise, outputs the connection state
    BT_PIO4 = 33;  //PTE24...actually it's BT_PIO5 ??? JM: YES, IT IS BT_PIO5!

So, I guess that it's not a problem that BT_CTS and BT_RTS get moved.

Chip

@chipaudette
Copy link
Member Author

chipaudette commented Apr 27, 2020

Regarding needing more I2C connections in order to feed all of my dreamed-about AICs, that's a good catch. Seems like we'll need an I2C multiplexer.

https://www.adafruit.com/product/2717

Now it seems like this is kinda getting out of control, eh? It seems like that if I want to do a proper 4-aic (ie 8 audio channel) demo, I really ought to design the board to do that, including all of the AICs. I mean, with this RevE, what am I going to do...do flying leads off to all of the other AICs?!? That sounds crazy.

So, maybe we should limit our scope with Rev E. We should assume that we're going to talk with the on-board AIC the same way that Paul has the T4 talking to the Teensy Audio Shield (the new RevD version of the Teensy Audio shield). It's the second Tympan AIC that I'm less sure about...

So, for the second Tympan AIC, we'll control it via the 2nd I2C bus, like with Tympan RevD. The unknown is which I2S connections I want to route over to the headers for our shield. So, I guess it's here that I need through holes for the various I2S lines that I specified above. And then I need a few more through holes that let me mix-and-match those signals over to the headers that go up to the AIC shield.

Does that make any sense?

@chipaudette
Copy link
Member Author

chipaudette commented Apr 27, 2020

If we're super lucky, I might even be able to use my new T4.1 beta and do flying leads over to a pair of RevC boards. Then, I could try Paul's example 4-channel code that has been extended for T4 (even though its documentation hasn't) and give it a try. Through such a demonstration, I'd prove exactly which pins we want.

But, that'll take me a little time. Tomorrow (being my "teleconference Tuesday") is not going to be the day for that.

@chipaudette
Copy link
Member Author

chipaudette commented Apr 28, 2020

After checking in on the forum regarding the I2S_quad class and its support for Teensy 4, I got the following response...

https://forum.pjrc.com/threads/58754-What-is-the-current-state-of-Audio-Library-support-for-the-Teensy-4-0?p=237190&viewfull=1#post237190

So, maybe pins 6 and 8 for the two I2S input data lines (ie, data from the AICs to the Teensy) and maybe pins 7 and 32 for the two I2S output data lines (ie, data from the Teensy to the AICs).

I'm cross-referencing with the Teensy 4 pinout now...

@chipaudette
Copy link
Member Author

chipaudette commented Apr 28, 2020

Looking at the Teensy 4.0 pinout, specifically at the yellow colored pins flagged for "Digital Audio", I see:

Pin 6 = OUT1D
Pin 8 = IN1 (This is "DOUT" on the Teensy Audio Shield RevD)

Pin 7 = OUT1A (This is "DIN" on the Teensy Audio Shield RevD)
Pin 32 (pad on bottom of the Teensy 4) = OUT1B

So, the Pin 8 and Pin 7 are consistent with the Teensy Audio Shield (RevD), which is great. In a quad setup, this suggests that these would be audio channels 1 and 2 (out of 4). This suggests that the channels 3 and 4 would be on Pins 6 and 32. If true, this would mean that the I2S_quad classes are exploiting the processor's ability to remap some of the I2S lines between inputs and outputs. Cool.

With my beta Teensy 4.1, I should be able to prototype this using Teensy Audio Boards that I have on-hand. I may get to try this tonight.

@biomurph
Copy link
Member

I was afraid of that issue with the I2C and the AIC. Super bummer that they don't allow you to set the I2C address on those AICs!
Is it possible to use another AIC? That ship seems to have already sailed, but just thought I'd ask.

Another thing is that we could put together a Tympan Hack that uses the Adafruit muxer. That thing is cool.

I will await the results of your experiment

@biomurph
Copy link
Member

I looked into the Sierra Wireless forum, and I don't see any major posts about BC127 and UART flow control. User of a different module claims that RTS/CTS are un responsive. Seems we 'don't need it' but I think we should keep it, just in case someone needs to manage the UART. Thoughts?

@chipaudette
Copy link
Member Author

I tried to get two AICs going (Teensy Audio Shield, not Tympan) with the Teensy 4.1. No success. For some reason, I can't get my rat's nest of wires to work today, whereas usually the rat's nest is my jam. Very annoying.

I can get one Teensy Audio Shield working with one Teensy 4.1 (and Teensy 4.0) when they are directly mated, stacked one-on-the-other like they're made to do. But, when I bring out my solderless breadboard and start flying my rat's nest of wires it doesn't work. I get crazy glitchy screaming audio instead of a nice tone sweep.

I've tried two different audio shields. Both work when directly mated to the Teensy 4.1 or to the 4.0. All combinations make the crazy glitchy noise when using the rat's nest. I've rebuilt the rat's nest several times.

I'm not sure what to do now.

@eyuan-creare
Copy link
Contributor

eyuan-creare commented Apr 30, 2020 via email

@eyuan-creare
Copy link
Contributor

eyuan-creare commented Apr 30, 2020 via email

@eyuan-creare
Copy link
Contributor

eyuan-creare commented Apr 30, 2020 via email

@biomurph
Copy link
Member

aaarrrg bummer.

I find that when stuff goes south it's best to put it away and then when I get back to it the problem reveals itself. Any way you could post what you've got so we could troubleshoot it?

@eyuan-creare
Copy link
Contributor

eyuan-creare commented Apr 30, 2020 via email

@chipaudette
Copy link
Member Author

I made another attempt. I tried to stack both Teensy Audio Boards together, like how they're meant to be used. To enable quad operation, the boards have traces purposely designed to be cut so that you can switch out from the main I2S data lines and fly in the secondary I2S data lines. So, I cut the trace and attached flying leads to the secondary I2S pins. Unfortunately, I ended up pulling a pad off the board. :(

I can't see how to repair it (literally, I can't see it...no magnification here at the house) and I don't see any other components on the board (resistors or whatever) that'd let me fly in a lead to another spot. So, I'm dead in the water until I get another audio board.

Or, we just assume that it'll work with Pin 6 and Pin 32 and design the Rev E to allow us to access the signals in case we mistakenly swap DIN and DOUT on these pins (like we've done a couple times already).

Joel, any thoughts?

@eyuan-creare
Copy link
Contributor

eyuan-creare commented May 3, 2020 via email

@biomurph
Copy link
Member

biomurph commented May 4, 2020 via email

@chipaudette
Copy link
Member Author

chipaudette commented May 20, 2020

Since my previous post, I got new Teensy Audio Boards and stackable headers. I got the E-lab to mod one of the boards to jump the data lines (pin 7 and 8 being swapped to pins 32 and 6, per the discussion above), to bridge to pads to change the I2C address, and to remove the 10K pullup resistor already on Pin 6.

Cut traces

step2

@chipaudette
Copy link
Member Author

chipaudette commented May 20, 2020

Using this new test hardware....

I ran a quad-channel version of the tone sweep sketch. It correctly generated audio out of the headphone jack on each of the two boards (independently). So that's a success. It proves that swapping pin 32 for pin 7 is the correct substitution. Put that one in the bank.

However, when I try to acquire audio via the line-in / mic input, I can't get audio from the 2nd audio board. So, this calls into question the pin 6 for pin 7 swap. In visually inspecting the modified board, however, I'm not sure that the mod was done correctly. So, when I'm in the office again (Friday?), they'll take another cut at it.

@chipaudette
Copy link
Member Author

Under the assumption that we didn't modify the board as intended, we took a fresh Teensy Audio Board and did the modifications again.

Again, it can play audio out the headphone jack just fine, but it cannot record audio from the line-in jack. :(

@chipaudette
Copy link
Member Author

@biomurph
Copy link
Member

biomurph commented May 28, 2020 via email

@chipaudette
Copy link
Member Author

The forum gave some debugging ideas. And, Paul himself jumped in to demo that the system worked for him.

So, I brought the hardware back to the lab. We probed pin6 and saw digital data. Then, we disconnected our pin6 wire and did a flying lead direct to pin6. The system worked. Then we removed the flying lead and soldered our original wiring back in. For some reason, it now works.

Conclusion: the Teensy4 support for quad audio works using pins 8+7 and pins 6+32.

I now have to decide what other pins, if any, I want broken out.

@biomurph
Copy link
Member

biomurph commented Jun 4, 2020

Sweet!
So those pins 8+7, 6+32 are the DIN DOUT pairs for coms with the AIC, correct?

@chipaudette
Copy link
Member Author

Yes, 8+7 is one set (the default set) and 6+32 is the second set (for the optional AIC).

As for which is DIN and which is DOUT, this is a long-standing problem of ours. I'm looking at your google spreadsheet now.

@chipaudette
Copy link
Member Author

Looking at the RevD schematic, it looks like our "DIN" and "DOUT" are relative to the AIC. So, in this convention:

  • DIN for the 1st AIC = T3.6 Pin 22 = T4.x Pin 7

  • DOUT for the 1st AIC = T3.6 Pin 13 = T4.x Pin 8

  • DIN for the 2nd AIC = T3.6 Pin 15 = T4.x Pin 32

  • DOUT for the 2nd AIC = T3.6 Pin 38 = T4.x Pin 6

I think that you've already accounted for the I2C and SPI signals moving pins on the T4.x vs the T3.6?

@chipaudette
Copy link
Member Author

Looking at your google spreadsheet a little bit, it looks like the Pin6 and Pin32 assignments will force you to move some of the existing functions. Bummer, but we'll deal. Hopefully there are pins that you can move them to!

@chipaudette
Copy link
Member Author

Is there more input that I need to provide here?

@biomurph
Copy link
Member

Thanks for chasing that down! I will see about re-juggling the pin assignments to fit the I2S and offer it up for review.

@biomurph
Copy link
Member

biomurph commented Aug 3, 2020

@chipaudette
Per your notes here, I have updated the schematics to reflect the correct DIN, DOUT, DIN_1, DOUT_1 pin connections.
The other pin connections that are flexible are in place and subject to change for ease of routing purposes.
Plan is to break out all of the unused pins, and also add the recommended memory chips on the bottom of the board.
Here's direct link to the schematics
Couple of questions:

  1. ON/OFF pin can be connected to a pull-down push button to manually turn off and then on the chip. Do we need it?

  2. REV_TEST functionality. For Rev D, we used pin 44 tied to GND. Teensy 4.1 does not have a pin 44. I'm using pin 22 (no special reason). Should we connect 22 to GND as we did for rev D? Use another pin?

@chipaudette
Copy link
Member Author

I don't see a need for the "ON/OFF" button...but I'm not knowledgeable about it. If there's not one on the T4.1, I guess that we don't need one.

For REV_TEST, using pin 22 seems fine enough to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants