On Sat, 11 Apr 2015 14:58:35 -0700, you wrote: >@Harvey > >Ah, good one ! I was just thinking "inverter" when I saw your post, but I >am not an electronics engineer by any stretch of the imagination . . . >wasn't sure it would work.
I'll admit to being one.... I have a similar problem with a display and a display controller. If the display were to be enabled before the display controller, it would (and does....) violate several of the rules where the manufacturer of the display says ... and don't do this..... So the trick is to run a line from the processor to the display through a gate, as well as the enable line from the display chip. Once the processor sees that the display is being driven (it can ask the display chip)... *then* it allows the display to be enabled. Helps no end when debugging the display drivers since the power would be on when the display is not set up. In similar situations, the processor (not a BBB) is started with pins that are effectively inputs, and may or may not be weakly pulled up (think large value resistor to VCC). Pulling the enable line *down* (it's enabled when up) and connecting that line to a processor means that the display is disabled until the processor says so.... not before... Harvey > >@Winston. > >OK, my bad. I was actually thinking this could be the case, but was unsure. >Harvey's suggestions seems plausible though. > > > >On Sat, Apr 11, 2015 at 10:36 AM, Harvey White <ma...@dragonworks.info> >wrote: > >> On Sat, 11 Apr 2015 09:38:47 -0700 (PDT), you wrote: >> >> >On Thursday, April 9, 2015 at 11:48:35 PM UTC-4, William Hermans wrote: >> >> If the actual driver has an enable pin, then take an active low >> (during initialization) pin, pull it down with a further resistor >> (just in case), and then run that through an inverter (if needed) to >> the enable on the MAX3222. >> >> That way, the default behavior is disabled (for the driver), and >> during bootup, the behavior is still disabled until your code >> specifically enables the driver. >> >> Harvey >> >> >> > >> >> *The 10K pull-up didn't work. I didn't think it would, the am335x >> drives >> >>> the pins low during initialization and this is overcoming the pull-up >> [the >> >>> outputs were never free-floating]. I think I should have used a >> MAX3222 >> >>> and wired up the SHDN pin to a GPIO so that I could independently >> enable >> >>> the level converter once the system is stable (assuming I can figure >> out >> >>> the .dts incantation to make a GPIO pin work under jessie/3.14-ti).* >> >>> >> >> >> >> Winston is it ? >> >> >> > >> >Yes. >> > >> > >> >> Anyway, you could use Charles S' universal-IO device tree overlay(s) >> >> to do this for you. I understand that they are built into the latest >> >> images ( for several months now ). >> >> >> >> https://github.com/cdsteinkuehler/beaglebone-universal-io >> >> >> >> I meant to demonstrate this and write up a mini how-to, but have been >> >> really busy for the last several months . . . >> >> >> > >> >I think my issue is more fundamental. The issue is really that the RS232 >> >peripheral is connected when the BBB boots, for those first few ms, before >> >it's even loaded u-boot, the pinmux is at it's default "zero" state and >> the >> >UART pins are thus low which the peripheral reads as a stream of 0's, this >> >continues until the dtb (I'm using jessie/3.14) is loaded that enables the >> >UART via the pinmuxing. >> > >> >I had even tried building a custom version of u-boot that enabled UART5 >> >(whereas normally it only enables UART0 for the console). Sadly, it still >> >isn't quick enough for the peripheral not to see enough 0's to cause a >> >serial break. >> > >> >Thanks! >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
