What is the on/off pin for even, maybe remove it?another suggestion - can the On/Off pin be moved as well next to the Boot button?
Anyway, here it is!
Last edited:
What is the on/off pin for even, maybe remove it?another suggestion - can the On/Off pin be moved as well next to the Boot button?
Two options:Yes, alternate pins for CAN FD, very good for the future.
KurtE can you give me pin numbers for these two last additions?
Its been a while. I think without a cap you are only going to get to about 198Mhz. (not sure about that value since its been a while). Not sure you want to go faster than that though since that is way over the spec anyway's
It has indeed been a while. Even tho I did allot of testing, I am unsure what we should do here.Its been a while. I think without a cap you are only going to get to about 198Mhz. (not sure about that value since its been a while). Not sure you want to go faster than that though since that is way over the spec anyway's
Sorry been out of pocket for awhile so just catching up. Cool you added CAN-FD. @tonton81's lib does support alt can pins so nice you added them@Dogbone06 the new board looks great!
As we spoke privately - adding in two more pins for CAN3 (CAN DF) connectivity.
Pins GPIO_AD_B0_15 and GPIO_AD_B0_14 @KurtE heads up
Just add the pads, and not populate?It has indeed been a while. Even tho I did allot of testing, I am unsure what we should do here.
[ + 5V + ]
and the other corner twice
[ + 3.3V + ]
I updated the excel document to match the update... probably more of the usages of the pins can and should be double checked...I took the easy route. I usually put pin numbers as defines and name them.
So I'm ready to order if no one has any objections?
View attachment 34534
I believe you have host stuff working on the 4.5. Probably need in most cases use a USB3 to USB2... cable, but that is the way things are going anyway...Still two USB Device input connectors? Not seeing label for USB-Host - did that get brought out? A lot else going on and just more sensitive wires.
Indeed, just wanted to be sure I wasn't misreading the board. Indeed, it was mentioned for a DvBd_4.5 though didn't see that there was a run of those.I believe you have host stuff working on the 4.5 .... But I would not hold up things up for this...
Test summary: 57 tests with 5 ReReads at F_CPU_ACTUAL 600 Mhz:
At 166 MHz in 145 seconds with 0 read errors
At 196 MHz in 136 seconds with 0 read errors
At 206 MHz in 133 seconds with 0 read errors
At 216 MHz in 132 seconds with 0 read errors
SDRAM One Scan CAP test Complete {v1.4} :Note tested CAP here pF=
At 216 MHz in 132 seconds with 0 read errors
At 227 MHz in 128 seconds with 0 read errors
At 240 MHz in 127 seconds with 784 read errors (0.0000%)
Indeed, understood that is the intent - was just noting the '-' is right by the '---' GND symbols and a '+' there would provide a clearer delineation of the transition - given parallax to header top and less than ideal eyesight* The [ — 5V — ] is just a way to show that several pins are the same instead of putting many labels. The — does not represent minus.
Good. As noted - not able to 'read' the intent of micro-SilkScreen: two USB C connectors - but central one is now USB Host not a duplicate of Device USB as on DevBoard 4?* USB Host is present already and working
* I’ll put the 10pF backYes, 10 pF cap seems a safe bet if the wires end up with similar behavior. Just put a fresh 10 pF on DevBd 4.0 here and:
** Alternate run shows 227 MHz to work and seeing fails at 240 MHzCode:Test summary: 57 tests with 5 ReReads at F_CPU_ACTUAL 600 Mhz: At 166 MHz in 145 seconds with 0 read errors At 196 MHz in 136 seconds with 0 read errors At 206 MHz in 133 seconds with 0 read errors At 216 MHz in 132 seconds with 0 read errors SDRAM One Scan CAP test Complete {v1.4} :Note tested CAP here pF=
Code:At 216 MHz in 132 seconds with 0 read errors At 227 MHz in 128 seconds with 0 read errors At 240 MHz in 127 seconds with 784 read errors (0.0000%)
Indeed, understood that is the intent - was just noting the '-' is right by the '---' GND symbols and a '+' there would provide a clearer delineation of the transition - given parallax to header top and less than ideal eyesight
Good. As noted - not able to 'read' the intent of micro-SilkScreen: two USB C connectors - but central one is now USB Host not a duplicate of Device USB as on DevBoard 4?
.
You are indeed right about the diode, in some sense. The diode adds some protection. So yes it's a good idea to take the power after the diode.One very minor thing (don't kill me): looking at the USB Host power, should the 5V be taken from the other side of the diode? Since otherwise if the board is powered directly via the 5V pins (without a PC connected to the USB), the USB host port will not get power (unless an external PD supply is used).
It means the USB Host power will be slightly below 5V (because of the diode drop) but looking at the T4 schematic, that's how it does it...
Yes. I can't read the writing on the 3 pads so I'll refer to the one connected to the diode anode as pad 1. I think it should be connected to the diode cathode instead, so that USB Host still gets power when the board is powered by 5V supply rather than a PC USB connection.You are indeed right about the diode, in some sense. The diode adds some protection. So yes it's a good idea to take the power after the diode.
USB-HOST has 3 pads. Solder 2 of them to get either 5V from the USB input. Or solder the other 2 pads to enable USB-PD where you have to provide your own 8 - 32V input via the screw terminal.
Is that what you meant?
I am not entirely sure I follow. Let's see if this helps.Yes. I can't read the writing on the 3 pads so I'll refer to the one connected to the diode anode as pad 1. I think it should be connected to the diode cathode instead, so that USB Host still gets power when the board is powered by 5V supply rather than a PC USB connection.
If the voltage drop (from the diode) on the USB Host power turns out to be an issue for anyone, they could solder a bodge wire from pad 2 (the middle pad) to the diode anode, instead of bridging pads 1+2.
I see it now, that's a very good catch! I'll fix that!Ok for the case where the GREEN linked pads are bridged: imagine the board is being powered by 5V direct to one of the broken out 5V pins, with nothing connected to the (non-host) USB port. There will be no voltage on USB_VIN so USB_VIN1 will get no power. But if it was connected to the other side of the diode it would be getting the 5V.
Nice catch and fix. Wondering if a post of the full Schematic might allow review (by others) to make sure adds/edits look right to 'them'?I see it now, that's a very good catch! I'll fix that!
EDIT: Fixed!