Difference between revisions of "PineNote"

Jump to navigation Jump to search
20 bytes added ,  04:13, 19 August 2021
m
forgot a bit of the quote :)
m (forgot a bit of the quote :))
Line 136: Line 136:
This decision requires the PineNote motherboard to be able to detect an AND condition between CC1 and CC2 and connect one of the SOC's UARTs to pins on the USB-C connector. In all other cases, the UART should be disconnected. It also requires the PINE64 Store ship a simple one-sided (no magical flipping here, sorry) connector board which breaks out USB 2.0 and UART.
This decision requires the PineNote motherboard to be able to detect an AND condition between CC1 and CC2 and connect one of the SOC's UARTs to pins on the USB-C connector. In all other cases, the UART should be disconnected. It also requires the PINE64 Store ship a simple one-sided (no magical flipping here, sorry) connector board which breaks out USB 2.0 and UART.


There were concerns that cheap USB-C cables have both CC1 and CC2 shorted together to save a wire. This may cause the PineNote to output 3.3v UART to a device that isn't expecting it, assuming the two are plugged together with a nonstandard cable. This seems unfounded (or not enough of a problem to worry about on a large scale), since the USB-C specification states in section B.2.3.1, "The general concept for setting up a valid connection between a DTS and TS is based on being able to detect the typical USB Type-C termination resistances.  However, detecting a Debug Accessory Mode connection requires that both CC pins must detect a pull-up (Rp) or pull-down (Rd) termination.  A USB Type-C Cable does not pass both CC wires so a receptacle to receptacle Debug Accessory Mode connection"
There were concerns that cheap USB-C cables have both CC1 and CC2 shorted together to save a wire. This may cause the PineNote to output 3.3v UART to a device that isn't expecting it, assuming the two are plugged together with a nonstandard cable. This seems unfounded (or not enough of a problem to worry about on a large scale), since the USB-C specification states in section B.2.3.1, "The general concept for setting up a valid connection between a DTS and TS is based on being able to detect the typical USB Type-C termination resistances.  However, detecting a Debug Accessory Mode connection requires that both CC pins must detect a pull-up (Rp) or pull-down (Rd) termination.  A USB Type-C Cable does not pass both CC wires so a receptacle to receptacle Debug Accessory Mode connection cannot be detected."


There were concerns that checking CC1 and CC2 being pulled high was not strictly to USB-C standard, as detecting them being pulled low is mentioned in the standard. However, detecting a pull-up condition is all that is required. According to the USB-C spec, 'B.2.4.1.5.1 ("UnattachedDeb.SRC Requirements"), a Debug and Test System (DTS) that is a power source must pull CC1/CC2 up, while the Target System (TS) in Unattached.SNK is supposed to pull them low.' In English, this means that we'd only need to detect a pull-up condition on CC1 and CC2, meaning a logical AND between them is a sane solution.
There were concerns that checking CC1 and CC2 being pulled high was not strictly to USB-C standard, as detecting them being pulled low is mentioned in the standard. However, detecting a pull-up condition is all that is required. According to the USB-C spec, 'B.2.4.1.5.1 ("UnattachedDeb.SRC Requirements"), a Debug and Test System (DTS) that is a power source must pull CC1/CC2 up, while the Target System (TS) in Unattached.SNK is supposed to pull them low.' In English, this means that we'd only need to detect a pull-up condition on CC1 and CC2, meaning a logical AND between them is a sane solution.

Navigation menu