Another Teensy 4.0 Breakout Board

I received my boards yesterday, in 1.6mm. No apparent issue.

I began soldering one today. I had to clean some copper burr, but it went smoothly after that. No trouble with the smallest castellations, a bit of flux paste made quick & easy work of them.


I'm now stuck for the day as I can't build the USB Host board ; Farnell split my components order in two without me noticing, one of the package is still at the post office... :)
 
Would it be possible to have pin #'s on the bottom silk screen? At least for the pins > 23? I really don't want to have to refer to an online site when I'm bringing out pins.

Good suggestion. I'll see what I can fit in there! How's this?

Screen Shot 2019-10-21 at 11.40.41 AM.png
 
Last edited:
That looks very good! So much better to see silk screen refs to prevent confusion in flipping the board.

Question why are pin #34 and On/Off a square pad?
No good reason, they were like that in the original default footprint for the header that I used. Rounded them out:

Screen Shot 2019-10-21 at 1.21.37 PM.png
 
They were pretty clear with me that the castellated designs were not guaranteed. Their tips are here: https://docs.oshpark.com/tips+tricks/castellation/

My guess is that the thinness of the board and the thickness of the traces (2oz vs 1oz) conspire together to make this a little tricky to get right reliably.

While I'm disappointed that the 0.8mm design didn't work first time, I suspect that it could work reliably with a few iterations.

For production volumes it would make more sense to work with a board house to dial in the design, production and inspection process to get it right reliably.

i'm not sure how much control over the content of the shared board page on OSH you have but i noticed you have a note about the .8mm on your github and something similar on the OSH board page would be a plus.
 
i'm not sure how much control over the content of the shared board page on OSH you have but i noticed you have a note about the .8mm on your github and something similar on the OSH board page would be a plus.
Good point, I've added it to the OSHPark project page for the latest design.
 
I've put together a design for a combination USB Host and SD breakout board. The idea is that it straddles atop the teensy and connects via a tall-ish header to the original Teensy 4 breakout board below. It has the SD slot on one side and the USB A connector on the top side. This way you can use the Teensy 4 on a traditional perfboard and still have the SD and USB connectors, which are all at one end.

Details here: https://github.com/blackketter/teensy4_combo_breakout

Would love feedback on this approach from anybody who can take a look. Thanks!
 
Digi-Key HR1941CT-ND (DM3D-SF) SD Card socket is out of stock.
But they do have H126097CT-ND (DM3D-SF(41), which appears to be identical.

Will that one work on the blackketter/teensy4_sd_breakout ?

Thanks,
Bill
 
Digi-Key HR1941CT-ND (DM3D-SF) SD Card socket is out of stock.
But they do have H126097CT-ND (DM3D-SF(41), which appears to be identical.

Will that one work on the blackketter/teensy4_sd_breakout ?

Thanks,
Bill
They do appear to be identical, same datasheet, etc. I can't think of a reason why the new part number wouldn't work exactly the same.
 
My (1.6mm) boards arrived earlier this week. I live in Europe, and I had my order in hand a scant 6 calendar days after placement! In my experience, OSH Park has always under-promised and over-delivered.

I ordered every board in the suite. I doubt I'll ever use a couple of them, but since fast international shipping was already half the total cost, an extra few $$ made sense just in case. My only thoughts are:
a-1) I doubt I'll ever use the SMD Breakout Boards. Don't want to create the required additional PCB, but also nearly every one of the small castellations require de-burring - a ton of work under a magnifier with all those very small holes.
a-2) The board router (not trace router) had to leave the mouse-bites intact to keep the boards attached to the large panel, so those holes will require manual-castellation (OUCH! Who knew castellation was even a verb?).
b) The BOMs with Digikey part numbers... Are they on GitHub somewhere that I just didn't see? I believe I found all the correct parts for my Digikey order. But the inductor and SD connector were a bit confusing, and just finding everything took quite a bit of searching.

Regarding the thru-hole Breakout Board: Other than the burrs that needed to be cleared in a few of the castellations, it looks perfect! The plating of every castellation is complete top-to-bottom (that is also true for the SMD Breakout). The silkscreen additions are helpful, and I like that there's a date on the board since there've been a few revs so far. I'm looking forward to soldering one up later today after my solder paste arrives.

Finally, most of my Teensy 4.0 applications won't actually need a Breakout Board. While I can't use every available I/O pin without one, I rarely require more than the stock board provides. I didn't choose the Teensy 4.0 because of all the I/O, but instead because:
a) It works virtually seamlessly with the Arduino IDE
b) Its form-factor/small size
c) Its speed/power
d) Its cost/value
It's becoming my go-to embed for those reasons. And now, if I need to access the SD pins or more I/O, no problem.

Thanks for all your work creating these boards, and then making them available to the community!
 
My (1.6mm) boards arrived earlier this week. I live in Europe, and I had my order in hand a scant 6 calendar days after placement! In my experience, OSH Park has always under-promised and over-delivered.

I ordered every board in the suite. I doubt I'll ever use a couple of them, but since fast international shipping was already half the total cost, an extra few $$ made sense just in case. My only thoughts are:
a-1) I doubt I'll ever use the SMD Breakout Boards. Don't want to create the required additional PCB, but also nearly every one of the small castellations require de-burring - a ton of work under a magnifier with all those very small holes.
a-2) The board router (not trace router) had to leave the mouse-bites intact to keep the boards attached to the large panel, so those holes will require manual-castellation (OUCH! Who knew castellation was even a verb?).
b) The BOMs with Digikey part numbers... Are they on GitHub somewhere that I just didn't see? I believe I found all the correct parts for my Digikey order. But the inductor and SD connector were a bit confusing, and just finding everything took quite a bit of searching.

Regarding the thru-hole Breakout Board: Other than the burrs that needed to be cleared in a few of the castellations, it looks perfect! The plating of every castellation is complete top-to-bottom (that is also true for the SMD Breakout). The silkscreen additions are helpful, and I like that there's a date on the board since there've been a few revs so far. I'm looking forward to soldering one up later today after my solder paste arrives.

Finally, most of my Teensy 4.0 applications won't actually need a Breakout Board. While I can't use every available I/O pin without one, I rarely require more than the stock board provides. I didn't choose the Teensy 4.0 because of all the I/O, but instead because:
a) It works virtually seamlessly with the Arduino IDE
b) Its form-factor/small size
c) Its speed/power
d) Its cost/value
It's becoming my go-to embed for those reasons. And now, if I need to access the SD pins or more I/O, no problem.

Thanks for all your work creating these boards, and then making them available to the community!

Glad you like them! The BOMs are available as web pages called "ibom.html" in the "bom" directories in GitHub. You'll need to download the HTML file and open it with a browser.
 
Hello blackketter,

Great work. Thank you! I notice the Teensy 4.0 ESP32 / USB Host / MicroSD Breakout Board. Very nice.

I'm interested in something similar but I want to use A2DP audio (documentation and example). My board would integrate with my audio modules to provide bluetooth audio in or out from the mixer. I believe the pins I need would be

IO35=LRCLK
IO32=BCLK
IO22=MCLK
TXD0=DATA_FROM_ESP32
RXD0=DATA_TO_ESP32

Then of course I would still need control like I2C or SPI but it wouldn't need to be fast.. I'm wondering if there is room on this board for this, or if a different board would be required. Just looking for some wisdom. Thanks again.

Jay
 
Hi @jayshoe. Thanks for the kind words.

Are you trying to connect the ESP32 to the T4 via I2S to stream audio between them?

In that case you'd need to connect one of the T4 I2S interfaces (pins SCLK, LRCLK, IN and OUT) to four available pins on the ESP32 and configure it appropriately. (I think that the ESP32 can map these to any IO pin.). I think this could be done by connecting:

Code:
Teensy         ESP32 
7 (OUT1A)   -> IO12
8 (IN1)     -> IO13
20 (LRCLK1) -> IO15
21 (BCLK1)  -> IO16



This would be separate from the ESP32 TXD0/RXD0 serial port that would be used for control communication between the two CPUs (or firmware updates to the ESP32). On my breakout board that's using the T4 pins 24 & 25 (TX6 & RX6).


Hello blackketter,

Great work. Thank you! I notice the Teensy 4.0 ESP32 / USB Host / MicroSD Breakout Board. Very nice.

I'm interested in something similar but I want to use A2DP audio (documentation and example). My board would integrate with my audio modules to provide bluetooth audio in or out from the mixer. I believe the pins I need would be

IO35=LRCLK
IO32=BCLK
IO22=MCLK
TXD0=DATA_FROM_ESP32
RXD0=DATA_TO_ESP32

Then of course I would still need control like I2C or SPI but it wouldn't need to be fast.. I'm wondering if there is room on this board for this, or if a different board would be required. Just looking for some wisdom. Thanks again.

Jay
 
Hi @jayshoe. Thanks for the kind words.

Are you trying to connect the ESP32 to the T4 via I2S to stream audio between them?

Correct, I've successfully done this on a breadboard. :) I've fed bluetooth audio that's being received by the ESP32 into the I2S of the teensy and sent it out the output of the audio shield.

In that case you'd need to connect one of the T4 I2S interfaces (pins SCLK, LRCLK, IN and OUT) to four available pins on the ESP32 and configure it appropriately. (I think that the ESP32 can map these to any IO pin.). I think this could be done by connecting:

Code:
Teensy         ESP32 
7 (OUT1A)   -> IO12
8 (IN1)     -> IO13
20 (LRCLK1) -> IO15
21 (BCLK1)  -> IO16



This would be separate from the ESP32 TXD0/RXD0 serial port that would be used for control communication between the two CPUs (or firmware updates to the ESP32). On my breakout board that's using the T4 pins 24 & 25 (TX6 & RX6).

That's the information I needed to know! The only caveat is that in my design we must still allow for other audio modules. My concept is "any in, any out" design, ultimately for a digital audio mixer. I have modules with a special footprint that lets us select what I2S line we are going to utilize for the input (or output) from the module. This should allow us to stack the modules on top of eachother to create multiple outputs (with PCM5242) or multiple inputs with the ADC card I'm working on (PCM1865). I intentionally did not select a specific I2S line so that we can experiment with combinations of either modules on different lines (OUT1A, OUT1B, OUT1C, OUT1D, OUT2), or running TDM on the same line (Example 4 PCM5242 on OUT1A).

So now my followup question is this.

  • Would you want the ESP32 on the same line as the audio shield? Maybe, if you don't want unique audio data. But if you wanted to share different data with it than the audio shield, you probably want it on a different line. (The SGTL5000 doesn't have TDM, I don't think.)
  • Can the ESP32 partake in TDM input/output on the audio line? My guess is probably, after some code. This would be nice because the ESP32 can share a line with some other modules, and it wouldn't force us to loose out on all the lines. We could probably have a PCM5242 and the ESP32 bluetooth output on the same pin (OUT1A) if we wanted to, if this were the case.
  • Can this be configured on your existing breakout? Or does it make sense to take the best from what you've already done, and create a new one with audio lines configured?
  • For this audio purpose, we don't need SPI. We would just need "T4 pins 24 & 25 (TX6 & RX6)" for control via I2C. Do you see any need for SPI? If not, then maybe designing a new module compatible with my designs would be the way to go.


Code:
Teensy         ESP32 
7 (OUT1A)   -> IO12
8 (IN1)     -> IO13
20 (LRCLK1) -> IO15
21 (BCLK1)  -> IO16

No MCLK? The pins I was using when I did it were the ones I mentioned.

Code:
IO35=LRCLK
IO32=BCLK
IO22=MCLK
TXD0=DATA_FROM_ESP32
RXD0=DATA_TO_ESP32

The data lines I used I think were the ones used in the Quad Audio example for stacking two of the audio shields on top... Not sure which lines they are right now, but that's how I did it if I recall.

Here are all the lines available to us for audio.

Code:
23_MCLK1
20_LRCLK1
21_BCLK1
8_IN1
7_OUT1A
32_OUT1B
9_OUT1C
6_OUT1D


33_MCLK2
3_LRCLK2
4_BCLK2
5_IN2
2_OUT2

Now I need to decide what lines would be best to hard connect to the ESP32, or whether to stick an ESP32 on a shield with one of my I2S jumper footprints... If you integrate the pins into your design, maybe just expose the pins you've already mentioned (for OUT1A) but then one select option to move it to OUT1B or OUT1C (for example)... This would make your design compatible at least with the Audio Shield at the same time. Don't choose OUT1D because it's the CS

I might design an audio based ESP32 board for the reasons described above. I'm just trying to build a system that will allow for some real extreme audio mixers. Your project is still going to help me greatly. :)
 
[*]Would you want the ESP32 on the same line as the audio shield? Maybe, if you don't want unique audio data. But if you wanted to share different data with it than the audio shield, you probably want it on a different line. (The SGTL5000 doesn't have TDM, I don't think.)
I think that you want the I2S port on the ESP32 connected to an I2S port on the T4, out to in and in to out. They'd share a BCLK and LRCLK, one driving the other. MCLK shouldn't be needed because that's for clocking a DAC, the BCLK handles the audio data clocking. You'd use another I2S port on either device to connect to another audio source or destination. I chose the first I2S port on the T4, but you could wire it up to the second one if you wanted to use the first for the Teensy Audio Adapter Board.
[*]Can the ESP32 partake in TDM input/output on the audio line? My guess is probably, after some code. This would be nice because the ESP32 can share a line with some other modules, and it wouldn't force us to loose out on all the lines. We could probably have a PCM5242 and the ESP32 bluetooth output on the same pin (OUT1A) if we wanted to, if this were the case.
I don't know if the ESP32 supports TDM audio.
[*]Can this be configured on your existing breakout? Or does it make sense to take the best from what you've already done, and create a new one with audio lines configured?
My board doesn't have connections for the teensy I2S pins, but they could be jumped from the teensy's headers to the header pins that are brought out next to the ESP32 module.
A future version of my board could make this easier by putting header locations above the I2S pins on the teensy (I think.). Then you'd populate those headers and socket them to the teensy. Without them, you'd need to wire them across the board.

[*]For this audio purpose, we don't need SPI. We would just need "T4 pins 24 & 25 (TX6 & RX6)" for control via I2C. Do you see any need for SPI? If not, then maybe designing a new module compatible with my designs would be the way to go.
Those SPI pins are optional and were added because some ESP32 firmwares use SPI for high speed communcations. I think the Adafruit ESP32 Feather does this. If you don't populate the header then those pins are free on both the T4 and the ESP32.

Also, the TX6/RX6 were chosen to use a regular serial UART connection between the T4 and the ESP32. If you prefer I2C, I'd choose another pair of pins so that the TX/RX pins can be used for debug serial.
 
Back
Top