Spurious headphone detection interrupts

[xyzzy]

I think the 100 nF to ground would filter high audio frequencies, but it's a bit outside my field to model the effect. I think one would need to know the impedance of the speaker. It's only in the circuit if the internal speakers are used, and those aren't exactly audiophile grade components, so it's probably not very significant.

A different connector would have been better, but I'm not so sure about adding just 10¢ to the BOM. I didn't find any 1/8" TRRS jacks with a DT switch on digi-key. I think such designs are no longer common. EDIT: Found *one* part, SJ-435107RS, that has an isolated ring switch. Digi-key doesn't have a parametric search for switch type, just number of switches. But CUI does, and this is their only TRRS switch that doesn't use ST switch connected to the signal pins.

The built in RS232 to USB bridge doesn't work how you think. It uses the native serial port, but allows connection through a standard usb connector with a standard usb cable. Instead of needing a specialized cable, with a built in rs232 to usb converter, and no standardized connector. It allows the rs232 voltage levels to be set in the board design instead of being determined by the cable. There is no interaction with the Linux USB system. You're probably thinking about a Linux serial gadget on a device or dual mode USB port, which is also useful, but not the same thing.

[dsimic]

I've also tried to find an appropriate TRRS socket, but it seems that no appropriate types are available.  The part you found, SJ-435107RS, unfortunately probably wouldn't fit mechanically because it isn't an SMT component that sits inside a PCB cutout, as it is the case with the current TRRS socket on the daughterboard.  There is probably not enough space inside the laptop to use any other variant of the connector.

Another option for a better headphones detection mechanism would be to use the ES8316 audio codec, which can generate required interrupts upon (un)plugging the headphones.  Furthermore, related NC or 0R components in the PineBook Pro schematics indicate that the design initially used ES8316 to detect the headphones, following the reference design found in the ES8316 datasheet (page 4), but that part of the circuitry has been made inoperable for the production version.

Could the RS232-to-USB bridge you've decribed actually be an USB-to-UART bridge such as the "official" serial console cable, which basically converts a SoC's native UART into a virtual serial port over USB?  Could you, please, confirm that or provide some additional information, such as an example of the actual bridge chip or device?  What is required of the RS232 DTE in that case, or the DTE is actually the virtual serial port in the computer that is connected to the USB interface of the bridge?

If that's actually the aforementioned USB-to-UART bridge, I would rather not see it in the next PineBook Pro revision.  Why?  First, it would require a USB Type-B socket on the side of the laptop, as a Type-A socket may not be used for something that is effectively a USB device port.  Second, it would increase the price of the laptop, for something that not all end-users need, and especially not all the time; anyone in need of a console port should buy a $7 console cable as an accessory.  Third, it would increase the power consumption ever slightly for something that is pretty much never used 100% of the time.

Out of the three reasons from above, the need for a USB Type-B socket would present the biggest issue, IMHO.  Just think of the users confused by a weird-looking USB port found literally on no other laptop; who knows what people would try to plug into that Type-B port.

[xyzzy]

Why would the ES8316 not have the same problem with spurious audio interrupts?  If the audio signal is above a logic 1 to the RK3399 and the ES8316 uses the same levels...

An example RS232 to USB chip would be a FT232R.  There are some that give you a few USB controllable GPIO lines in addition to the serial port, which would be super useful for recovery from a bad bootloader in eMMC or NOR flash.  RS-232 to USB is more specific term, as there are UARTs which are not RS-232, such as RS-422 and RS-485.

There is no need for a full size USB type B port.  No one uses those anymore.  A normal micro or mini USB port is used.  Plenty of space for that.

There's no significant power drain.  The chip is powered via the USB bus so that is draws its power form the host over USB instead of locally.

The cost is minimal.  Miniusb ports are very cheap.  Less than the $7 a cable costs.

If the PBP was meant to be purchased by people who never user a console, then it really needed a bootloader with a working user interface and recovery system, like ChromeOS has.  The barely functional u-boot still used is hardly enough.  Without a robust bootloader and software, they really should have provided a recovery console that doesn't require opening the device up to flip a switch, disabled the headphone output, and connect a special cable.

[dsimic]

It is reasonable to assume that the ES8316-based detection of headphones would work without issues.  The manufacturer of the ES8316 codec specifies the detection as one of the features, providing the reference detection citcuitry.  The manufacturer knows perfectly what to expect on the audio output channels, and knows how to handle that properly.  On the other hand, the detection circuitry currently used in the PineBook Pro looks pretty much like a workaround.

However, please don't get me wrong.  It is perfectly reasonable to assume that the ES8316-based detection of headphones would be issue-free, but that cannot be actually known without a detailed testing and validation of the actual implementation.

Alright, so you were talking about the USB-to-UART bridges, as the FT232R datasheet clearly states.  IIRC, I've seen such a bridge in an open-hardware USB TRNG, and I was disgusted by the need to use FTDI-provided drivers for the so-called virtual COM ports that are exposed on the USB side of the bridge.  Yuck, no thanks. :/

Having a USB Micro-B device port as the serial console would be a rather good solution.  I haven't become accustomed to the "fancy" concept of USB consoles yet, although I've seen a few network switches and routers that had Micro-B or Mini-B ports as their consoles.

However, using a special USB cable (which actually isn't that much special) with a TRRS jack for the PineBook Pro's serial console may also be acceptable because there are already other Pine64 devices that use the same cable and jack for their consoles.  Let's remember that pretty much nobody complained about the "baby-blue serial console cables" that Cisco used for nearly a couple of decades.

Quite frankly, I'd much more prefer to have an Ethernet port than a dedicated console port.  Having both would be fine, though.

Edit: By the way, I don't think we're going to see a new PineBook Pro revision any time soon, unfortunately.  So far, no known major issues or new feature requests have been acknowledged by the Pine64 team.

[Arwen]

In regards to the serial console for the Pinebook Pro.

My thought was to add a MicroUSB & FT232R, (or other serial to USB chip), to a new, replacement daughter / small board. The main board has the serial TX, RX & GND easily available as solder pads. Using a 3 wire cable from the main board to the new daughter / small board would be trivial. If properly designed, I'd have the power for the FT232R come from the external source. That way, no power drain from the Pinebook Pro, ever, (whether the serial console is in use or not).

This avoids "sharing" the headphone jack with serial console.

With the state of the world at present, my "project" is on hold.

Their might even be some additional tweaks to the design. Their are 2 un-used USB 2.0 ports on the internal USB hub. (The other 2 ports on that internal hub are for the keyboard & camera if I remember correctly.) An externally accessible switch could change the new MicroUSB port from console to USB 2.0. Just a thought. Or even a second MicroUSB port instead. (Not sure if their is physical height room for a USB Type A connector...)

[xyzzy]

RS-232 ports haven't been present on PC motherboards or laptops for over a decade. So connecting to RS-232 over USB is basically the standard for some time. The board designer of the Freescale GigaTAP, a debug probe I wrote the firmware for, incorporated one over twelve years ago. That's the first time I used a device with embedded RS-232 to USB circuit. It worked great, and I try to incorporate that into anything where the console will be accessible in the final form. For non-console enabled consumer or automotive electronics, usually it's RS232 pogo pads since they are small and cheap. Cables are ridiculous though.

Linux has open source drivers for FT232R and pretty much all other RS-232/RS-485/RS-422 to USB chips. There is no need to use a proprietary driver from FTDI.

And you do realize that the special cable with the 1/8" jack and USB has internally the exact same kind of chip with the exact same driver. So any misgivings you have about virtual com ports (which is a Windows term and, IMHO, non-sense not based on reality), apply equally to that.

While pine64 does have a cable for their other products that will physically fit the PBP, the voltage is wrong! Do not use it!

@Arwen, there's a blog post somewhere of someone doing exactly what you describe. They bought a small board with a RS232-to-USB chip and I think a micro USB, cut a small slot for the connector, and then wired it to the existing internal pads on the PBP PCB.

[Arwen]

@xyzzy I also considered buying a small serial to USB board. But, one thing held me back was the power. I wanted a board that allowed the USB side to supply power to the serial to USB chip. Due to challenges this last year, I have not pursued either the pre-built mod or custom small / daughter board.

Note that RS-232 is really plus & minus voltages, (generally >5v & <-5v. With ours being 0v to 3/3.3v, what we have is not really RS-232. But your meaning is understood.

[dsimic]

Linux has open source drivers for FT232R and pretty much all other RS-232/RS-485/RS-422 to USB chips.  There is no need to use a proprietary driver from FTDI.

I see that only FT232RL is supported in the Linux kernel mainline.  Though, as far as I can see in the FT232R datasheet, FT232RL is just a packaging variant of FT232R.  Am I correct?  If so, I have no longer any objections against using FT232R.  My initial views were skewed by some of the FTDI's marketing fluff.

And you do realize that the special cable with the 1/8" jack and USB has internally the exact same kind of chip with the exact same driver.  So any misgivings you have about virtual com ports (which is a Windows term and, IMHO, non-sense not based on reality), apply equally to that.

Absolutely, the "special" console cable is just the "external" version of the same thing.  The internal version would just place the bridge chip inside the laptop and expose the USB device interface, instead of exposing the UART in case of using the "external" version.  As already stated above, I really no longer have any objections against using FT232R.

While pine64 does have a cable for their other products that will physically fit the PBP, the voltage is wrong!  Do not use it!

Are you absolutely positive on that?

[KC9UDX]

I'm not positive; but I do recall reading a warning about it before buying the cable that I bought.

[xyzzy]

Linux has open source drivers for FT232R and pretty much all other RS-232/RS-485/RS-422 to USB chips.  There is no need to use a proprietary driver from FTDI.

I see that only FT232RL is supported in the Linux kernel mainline. 

The driver supports pretty much every uart to usb chip there is.  I've yet to find an unsupported one.