I'm trying to interface a SparkFun Serial Enabled 16x2 LCD (3.3V) to a Beaglebone Black. Since the beagleboard has on-board 3.3v and ground, I used that for the power to the LCD. For the 3.3v TTL serial, I used Pin 21 on the P9 header (aka SPIO_D0). I've encountered an odd issue with this setup, and I need help with a possible solution, as I'm still trying to learn electronics.

The issue is that if the LCD is plugged into pin 21 during boot up, Linux starts running really slow. I found out that if I plug the pin in after (1) linux has booted, and (2) I've initialized that pin to serial mode from the software, then Linux runs fine. So it seems that pin being initialized to serial mode is a must for the OS to not crawl to a halt. And that seems that it's not the default setting during boot up - which causes any operations in a terminal (such as dmesg) take an excessively long time to complete until that pin has been initialized properly. I have no idea why that would happen, and I haven't been able to find a way around it.

So, as one possible solution, I figured I'd use one of the other GPIO pins and a transistor to turn on the LCD after I've initialized pin 21. The problem here is that the LCD really wants 3.3v, and I'm getting an 0.5v drop across the transistor, which drops the voltage too low to power the LCD. I suppose I could use the 5v line, a transistor, and a 3.3 voltage regulator, though that seems like it's probably not the best solution, since the board already has on-board 3.3v power. I suppose I don't know if this approach would actually fix my problem...

Does anybody have any suggestions on how to fix this issue?


  • \$\begingroup\$ Later approach can utilize a p channel and an n channel FET. n Channel FET controls the gate of PFET. Or use a buffer. \$\endgroup\$ – User323693 Jul 1 '15 at 2:51
  • 1
    \$\begingroup\$ Don't switch the power, but rather figure out where your slowdown is coming from, and solve it at the source. Are you connecting a serial receive line, or only a transmit line? If the latter there should be no effect (no way really to know that anything is connected), unless the pin also has some other function during the boot process. You need to take time to understand what is going on, not just blindly plaster a band-aid on the observes issue. \$\endgroup\$ – Chris Stratton Jul 1 '15 at 3:11
  • \$\begingroup\$ Incidentally, is the line you are using rated for 3.3v? I seem to recall some of the beagle I/O being a lower voltage standard, so a receiver with a relatively small pullup to 3.3v could theoretically be an issue, though pullups are usually large enough that their current can be handled by protection diodes. \$\endgroup\$ – Chris Stratton Jul 1 '15 at 3:13
  • \$\begingroup\$ @Chris I second Chris. Shortcuts only depend on what is the aim of the project. \$\endgroup\$ – User323693 Jul 1 '15 at 3:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.