blackketter
Well-known member
Hm, I don't think so. I used the Teensy 3.6 schematic as an example (thanks Paul!) and I don't see a cap there. Could be wrong, would be happy to add it.
I know that several caps are needed for USB...
Another Teensy 4.0 Breakout Board
- Thread starter blackketter
- Start date
Hm, I don't think so. I used the Teensy 3.6 schematic as an example (thanks Paul!) and I don't see a cap there. Could be wrong, would be happy to add it.
I know that several caps are needed for USB...
defragster
Senior Member+
Not an EE - know they are power hungry and thought it was helpful. The PJRC adapter has 5V circuitry on and single wire SPI so not good ref. I went to onehorse alternate store for Tlera and found this that has caps on 4 data wire SPI - but on data and CLK lines in schematic image: tindie.com/products/tleracorp/sdio-card-reader-for-dragonfly/
The loglow beta breakout SD function is still in limbo with testers - I wonder if these caps are more important on SDIO usage ? Paul on T_3.5/3.6 run an inch direct on PCB with full GND plane etc ...
concerning CAP for uSD,
Yes, writing to uSD needs significant mA for a short period of time and internal ADC could be effected.
A 2nd version of the uSD breakout board, could feature a own 3.3V regulator and taking the 5V form Vin (making it also more stable)
(I order a both boards anyhow)
Yes, writing to uSD needs significant mA for a short period of time and internal ADC could be effected.
A 2nd version of the uSD breakout board, could feature a own 3.3V regulator and taking the 5V form Vin (making it also more stable)
(I order a both boards anyhow)
blackketter
Well-known member
Thanks for the information. I'd love to hear @PaulPaulStoffregen on this topic as his original breakout board didn't have either.
If you test it the board, please report back your experience on this! Thanks!
blackketter
Well-known member
Another day, another board. Here's a mini breakout board for the other side to do USB Host.
(Sorry there's no 3D model for the USB connector.)
Schematic, based on Teensy 3.6 design:
GitHub repo here.
Haven't uploaded it to OSHPark yet, pending review and coffee.
(Sorry there's no 3D model for the USB connector.)
Schematic, based on Teensy 3.6 design:
GitHub repo here.
Haven't uploaded it to OSHPark yet, pending review and coffee.
blackketter
Well-known member
defragster
Senior Member+
Hope the coffee was good 
The board looks like good fun, in the cart for now.
I don't see a BOM on OSH or github?
The board looks like good fun, in the cart for now.I don't see a BOM on OSH or github?
blackketter
Well-known member
There's a nifty, interactive BOM on the github:
https://raw.githubusercontent.com/blackketter/teensy4_usb_host_breakout/master/bom/ibom.html
Unfortunately you need to download it to your desktop and open it with your browser from there.
That said it has values and sizes but just a few part numbers. Once I've put together my Digikey order, I'll update it with what I ordered.
https://raw.githubusercontent.com/blackketter/teensy4_usb_host_breakout/master/bom/ibom.html
Unfortunately you need to download it to your desktop and open it with your browser from there.
That said it has values and sizes but just a few part numbers. Once I've put together my Digikey order, I'll update it with what I ordered.
defragster
Senior Member+
blackketter
Well-known member
GitHub repo has an updated BOM with digikey part numbers. I realized that the diodes aren't necessary and updated the design. For the board up on OSHPark, just short out the pads for one of the diodes.
@blackketter -
I've made a minor change to make the breakout compatible with my prototyping boards (VELLEMAN Eurocard 3-Hole Island PC Board (ECS3)) by adding a 0.1" gap between the the two rows of pins. Otherwise I would have to use my Dremel tool to cut through the copper islands on the board between the pins.
(If using a 2-hole island board you need to add a gap on just one side of the breakout)
I haven't yet sent it to OSH Park.
But my real question here is: since we're playing with the board, should we add more interfaces to the breakout??? For example I have been thinking about
1) an Audio Library compatible codec, such as the WM8731 or the SGTL5000 (I don't think I could hand solder that one!) to eliminate the need for the Audio Board.
2) an MCP23017 16 channel I2C port expander. You can never have enough ports!
Any other suggestions?
I've made a minor change to make the breakout compatible with my prototyping boards (VELLEMAN Eurocard 3-Hole Island PC Board (ECS3)) by adding a 0.1" gap between the the two rows of pins. Otherwise I would have to use my Dremel tool to cut through the copper islands on the board between the pins.
(If using a 2-hole island board you need to add a gap on just one side of the breakout)
I haven't yet sent it to OSH Park.
But my real question here is: since we're playing with the board, should we add more interfaces to the breakout??? For example I have been thinking about
1) an Audio Library compatible codec, such as the WM8731 or the SGTL5000 (I don't think I could hand solder that one!) to eliminate the need for the Audio Board.
2) an MCP23017 16 channel I2C port expander. You can never have enough ports!
Any other suggestions?
MichaelMeissner
Senior Member+
I would tend to prefer the bottom pins extending before and after the main pins (the USB and SD card should go before, and the 10 pins at the back + reset + on/off). That way you can easily use it in a breadboard or longer prototyping board. But that way unfortunately will make it more expensive.
Lets see
26 pins per side. A little bigger than the 3.5/3.6 (24 pins), but it would still fit on a 1/2 size breadboard and/or prototype board (30 pins). If you didn't want to use the standard USB header and/or don't bring out some pins you could reduce it to 24 pins.
While to some extent your board competes with Loglow's board, it may make sense to use his pin ordering.
Or alternatively, go like the FrankB 3.2 boards, and just bring the pins out to the back:
What I'm planning on doing is soldering a 20 pin stacking header on each side. The front USB and SD pins, I would just use a normal female header. For the rear pads (which right now are the ones I'm interested in bringing out), I would solder them to the remaining 6 pins on each side for the stacking headers. Right now, it might be pins 24-27 on the right side + reset and on/off, and pins 28-33 on the left side.
Like with the other breakout board, I would suggest making sure pins that go together are next to each other. I.e. 24 & 25 since they form Serial6 or I2C2. Pins 26 & 27, since they are used with the 2nd SPI bus. Pins 28 & 29 since they are Serial7. Pins 30 & 31, for Can #3.
Assuming you have 6 pins in the back for the back pads and reset and on/off, you could do 5 rows of 6 pins for logical functions. Unfortunately, I2S takes 7 pins (power, ground, MCLK, LRCLK, BCLK, IN, OUT), and SPI tends to want additional CS/DC/reset pins that aren't fixed. Obviously for the front pins, you don't want to put anything there, since it would interfere with the USB connection.
If all you want to do are play sounds, you don't need the audio board, all you need is I2S output and appropriate I2S amplifiers.
Lets see
- Back set of pins, 5;
- Set of pins to bring out reset and on/off;
- 14 standard pins for the Teensy
- 6 pins to bring out the SD card on one side, and 5 pins to bring out the USB header on the other side, plus bringing out VUSB to be next to VIN.
26 pins per side. A little bigger than the 3.5/3.6 (24 pins), but it would still fit on a 1/2 size breadboard and/or prototype board (30 pins). If you didn't want to use the standard USB header and/or don't bring out some pins you could reduce it to 24 pins.
While to some extent your board competes with Loglow's board, it may make sense to use his pin ordering.
Or alternatively, go like the FrankB 3.2 boards, and just bring the pins out to the back:
What I'm planning on doing is soldering a 20 pin stacking header on each side. The front USB and SD pins, I would just use a normal female header. For the rear pads (which right now are the ones I'm interested in bringing out), I would solder them to the remaining 6 pins on each side for the stacking headers. Right now, it might be pins 24-27 on the right side + reset and on/off, and pins 28-33 on the left side.
Like with the other breakout board, I would suggest making sure pins that go together are next to each other. I.e. 24 & 25 since they form Serial6 or I2C2. Pins 26 & 27, since they are used with the 2nd SPI bus. Pins 28 & 29 since they are Serial7. Pins 30 & 31, for Can #3.
Assuming you have 6 pins in the back for the back pads and reset and on/off, you could do 5 rows of 6 pins for logical functions. Unfortunately, I2S takes 7 pins (power, ground, MCLK, LRCLK, BCLK, IN, OUT), and SPI tends to want additional CS/DC/reset pins that aren't fixed. Obviously for the front pins, you don't want to put anything there, since it would interfere with the USB connection.
If all you want to do are play sounds, you don't need the audio board, all you need is I2S output and appropriate I2S amplifiers.
blackketter
Well-known member
One more crazy idea.
The bottom right set of pins (25/RX6,26,28,24/TX7,3.3v,GND,PROGRAM and ON/OFF) could support a serially connected ESP32 breakout board.
The one I'm working on uses an ESP32 WROOM 32D module and includes enough pins for the Teensy to work as an uploader.
It uses the Teensy's 3.3v power supply by default, but a larger (1A) regulator can be populated to allow for full transmission power.
It also brings the ON/OFF pin out to a switch that does double duty as a ESP32 reset button.
There are also headers for a few of the ESP32 pins, enough to support an SPI interface and a few other GPIOs which could be connected to LEDs, etc...
Any feedback would be most welcome.
EDIT: Files posted to GitHub: https://github.com/blackketter/teensy4_esp32_breakout
Draft design:
Schematic:
The bottom right set of pins (25/RX6,26,28,24/TX7,3.3v,GND,PROGRAM and ON/OFF) could support a serially connected ESP32 breakout board.
The one I'm working on uses an ESP32 WROOM 32D module and includes enough pins for the Teensy to work as an uploader.
It uses the Teensy's 3.3v power supply by default, but a larger (1A) regulator can be populated to allow for full transmission power.
It also brings the ON/OFF pin out to a switch that does double duty as a ESP32 reset button.
There are also headers for a few of the ESP32 pins, enough to support an SPI interface and a few other GPIOs which could be connected to LEDs, etc...
Any feedback would be most welcome.
EDIT: Files posted to GitHub: https://github.com/blackketter/teensy4_esp32_breakout
Draft design:
Schematic:
Last edited:
defragster
Senior Member+
Nice development/addition/direction. ESP32 seems a nice upgrade to 8266.
I just got some ESP32 TinyPICO branded PICO units - problem is he didn't put Rx/Tx on the board - adding on next rev - but as pads - so programming is by USB. Nice because it has LiPo charger and batt connect on it and is Teensy sized 0.07x01.3 with antenna.
I just got some ESP32 TinyPICO branded PICO units - problem is he didn't put Rx/Tx on the board - adding on next rev - but as pads - so programming is by USB. Nice because it has LiPo charger and batt connect on it and is Teensy sized 0.07x01.3 with antenna.
How strange! I had just started to bread-board a T4 and a ESP32 with a built-in ILI9341 display, and was sitting here pondering the best way to have them transfer data to and fro -in particular from the T4 to the display on the ESP32! Do you have any suggestions? I'm thinking about just sending an op-code defining a graphics primitive and a minimal set of data to have the ESP32 execute the primitive...
blackketter
Well-known member
That sounds like a reasonable approach, though if they are connected by a serial port it might be slow, depending on how many primitives it takes to draw your screen...
defragster
Senior Member+
@tonton81 wrote a very swift CRC checked w/resend SPI xfer library for T_3.x to T_3.x - one Teensy gathering 9DOF data could pass off data at 4-40 Mbps to a second Teensy for processing and printing out USB for graphing.
He also made a slave component - not seeing it went to ESP - but the Slave worked even to T_LC. Would need update for T4 as well on Master end.
He also made a slave component - not seeing it went to ESP - but the Slave worked even to T_LC. Would need update for T4 as well on Master end.
@defragster - Wow! What a massive effort by @tonton81 et al (including yourself)! It looks exciting BUT from skimming the thread it also looks like the devil is in the details for implementation on each member of the T3.x family. And as you note (and I think was mentioned by @tonton81) upgrade to the T4 will require a complete rewrite. Way out of my league, I'm afraid.
@blackketter - Looks like you are suggesting to use SPI. Have you thought about a suitable protocol?
@blackketter - Looks like you are suggesting to use SPI. Have you thought about a suitable protocol?
blackketter
Well-known member
The ESP32 breakout board, when attached to the bottom mounted Teensy4 header breakout board provides a serial connection via Serial6 and uses digital pins 26 and 28 to control the ESP32 pins IO0 and IO2. This should be sufficient for the Teensy to put the ESP32 in programming mode and download new firmware to it. My intention is to write a Teensy firmware that passes through serial data via USB to program the ESP32 with esptool on the host. Then the Teensy can talk to the downloaded firmware on the ESP32 via the serial port. Uploads happen at 115kbps, but custom firmware should be able to run at 4 or 5mbps, I think.
I also brought out the pins that should provide a SPI interface, but that'll require wires to connect to an SPI port on the Teensy. That should run faster.
As far as a protocol, that depends on what you want to do. If it's for just networking, then using the basic AT command set provided by the default Espressif firmware via serial port. Alternatively data can move faster via the SPI port. This is what the new Arduino and Adafruit Airlift boards do using the WiFiNINA firmware.
For a custom firmware with additional functions, that depends on your needs. It sounds like you want to use the ESP32 board to be a graphics processor and frame buffer. I think your basic idea of graphics op-codes makes sense.
If you want to use an Adafruit_GFX style API (like what the ILI9431 libraries use) you could create a shim with small library that subclasses Adafruit_GFX and converts the calls to commands to send via serial or SPI. Then on the ESP32 side, have a sketch that takes those commands and calls the appropriate Adafruit_GFX functions on its own library. You can start small with the minimum required overloaded virtual functions that Adafruit_GFX requires (drawPixel() at the very minimum) and then then add additional functions as your performance needs.
defragster
Senior Member+
When esp8266 came out I used T_3.2's for pass through programming - that is a critical first step- but with those bottom serial pins that is trivial. Except as I noted on the TinyPICO I got where the Rx/Tx are not exposed That doesn't apply to a bare module as shown above.
But looking at the TinyPICO 'forum' I see {where the PICO is just a fewer pin smaller chipset version of same dual core ESP32} The ESP32 with 4MB flash quickly fills it seems when Bluetooth or WiFi stack quickly hits 80+% or 100+% when the ESP 4MB is split into thirds - 1.3MB for SPIFFS. And then two sets of 1.3MB FLASH reserved for current and OTA upload space. So reducing SPIFFS or disabling the OTA update storage space may be needed to get the radio code working with any significant user sketch - but that is end use issue - and then large/slow UART updates take even longer - but the ESP32 dual core with RTOS seems usable in the quick tests I did where each core has much of T_3.6 speed - except one core responsible for the radio.
ESP32 SPI is apparently usable for displays or other - but indeed like the various Teensy - each 'SPI Engine' is unique as KurtE has found working with T_4.0 to get displays to work. It is perfectly functional - more evolved than T_LC - but unique to the MCU with alternate strengths/features so it would take some study/understanding for ESP32 and T4 updates. @tonton81 currently focused on CAN/CANFD it seems, not sure if he'd want to revisit. IIRC he was interested in the ESP family - but don't see signs of that on github.
That doesn't apply to a bare module as shown above.But looking at the TinyPICO 'forum' I see {where the PICO is just a fewer pin smaller chipset version of same dual core ESP32} The ESP32 with 4MB flash quickly fills it seems when Bluetooth or WiFi stack quickly hits 80+% or 100+% when the ESP 4MB is split into thirds - 1.3MB for SPIFFS. And then two sets of 1.3MB FLASH reserved for current and OTA upload space. So reducing SPIFFS or disabling the OTA update storage space may be needed to get the radio code working with any significant user sketch - but that is end use issue - and then large/slow UART updates take even longer - but the ESP32 dual core with RTOS seems usable in the quick tests I did where each core has much of T_3.6 speed - except one core responsible for the radio.
ESP32 SPI is apparently usable for displays or other - but indeed like the various Teensy - each 'SPI Engine' is unique as KurtE has found working with T_4.0 to get displays to work. It is perfectly functional - more evolved than T_LC - but unique to the MCU with alternate strengths/features so it would take some study/understanding for ESP32 and T4 updates. @tonton81 currently focused on CAN/CANFD it seems, not sure if he'd want to revisit. IIRC he was interested in the ESP family - but don't see signs of that on github.
defragster
Senior Member+
Anyone gotten OSH boards assembled yet? Mine have shipped to arrive 10/3 - at least the primary - secondary boards ordered later - DigiKey delivered parts today … hoping I read the BOM's right for USB and SD.
blackketter
Well-known member
My USB host and SD boards come 10/4. ESP32 boards next week. I think I've got all the other parts, thanks for your post, I should double check.
Mine shipped yesterday (10/1)... will try them out as soon as I get them.
BTW - Yesterday I uploaded to OSHpark my modified version with space between the side header rails, as in post #36. I actually made and ordered the two versions, one with the gap on both sides, the second with the gap on one side only, to accommodate my two and three hole island prototyping boards. i haven't yet shared the boards on OSHpark yet - I wanted to check them out first - but if anyone wants to try them right away just let me know and I'll make them available.
As I see it, the problem with these breakouts is that they are not at all compatible with standard breadboards where the horizontal pins are connected together. How are you proposing to connect to them for testing?
BTW - Yesterday I uploaded to OSHpark my modified version with space between the side header rails, as in post #36. I actually made and ordered the two versions, one with the gap on both sides, the second with the gap on one side only, to accommodate my two and three hole island prototyping boards. i haven't yet shared the boards on OSHpark yet - I wanted to check them out first - but if anyone wants to try them right away just let me know and I'll make them available.
As I see it, the problem with these breakouts is that they are not at all compatible with standard breadboards where the horizontal pins are connected together. How are you proposing to connect to them for testing?
defragster
Senior Member+
Not breadboard friendly - one note was pin the outer to the top to connect
Sounds good I ordered the thin - will see tomorrow. OSH delivered something else from same cart today - didn't come with purple T4 - suppose that will be in another small pack tomorrow.
Sounds good I ordered the thin - will see tomorrow. OSH delivered something else from same cart today - didn't come with purple T4 - suppose that will be in another small pack tomorrow.