Thanks. I'll do it better in the future with your advices! El dissabte, 12 març de 2016 1:06:29 UTC+1, john3909 va escriure: > > Whenever you have separate systems that may power up at different times or > the I/O configuration is unpredictable, then you should always use tristate > buffers so that you don’t drive I/O until it is ready. Also, some GPIO are > also used for boot configuration and these pins should not be driven during > the boot process. The GPIO can tolerate I/O conflict for short durations, > but if these conflicts persist over time, the processor will fail. > > You could also add a 33 ohm resistor in series and monitor the TX/RX > waveform. What you want to see is 0V and 3V3, but when you see stair step, > then you have some conflict. Also watch for reflections which can occur > when the lines are too long. This will typically cause ringing because of > impedance mismatch and this can cause the voltage to exceed 3V3 or go below > 0V. This will also cause processor failure. > > Regards, > John > > > > > On Mar 11, 2016, at 3:32 PM, Jordi Segura <jor...@gmail.com <javascript:>> > wrote: > > > Thanks @john3909. > This is to avoid having external power applied to the GPIO pins of the > BBB/G before is booted up which can damage the board right? > I suppose that was the the problem with my fried BBG. > > This should also apply with a single Tx board and a single Rx board > configuration rigth? > In my case the Tx sender micro (not a BBB) is powered from the VDD_3V3 pin > of the BBB. I've been running for more than one month without any issue > in the BBB until now. Should I also worry and use a tristate? > > Cheers, > Jordi > > > El divendres, 11 març de 2016 19:05:00 UTC+1, john3909 va escriure: >> >> Use a tristate buffer between the BBB TX and the BBB/BBG RX. Use a 2 >> input AND gate with the output connected to the buffer enable and a GPIO_EN >> from the BBB RX board connected to on of the AND gate input and a GPIO_EN >> from the BBG RX board to the other AND gate input. When both BBB/BBG board >> are fully booted, and their RX pins configured as inputs, set the GPIO_EN >> pins high, so that the buffer is no longer in tristate. >> >> Regards, >> John >> >> >> >> >> On Mar 11, 2016, at 8:19 AM, Jordi Segura <jor...@gmail.com> wrote: >> >> Thanks for answers so far. >> >> Yes my case is a single Tx output driving two Rx inputs. All processors >> are at 3.3 V. >> >> My original explanation of what I did: The BBG died after several days >> working 24/7, powered up from a power supply 5V 2A, with an 3G usb dongle >> connected on it, and (maybe that's my fault ...) I connected the Tx output >> of another microcontroller to one Rx input of the BBG but also to one Rx >> input of a BBB (I had both the BBG and the BBB receiving the same Tx signal >> from a third micro). >> The same power supply was powering both systems (BBG and BBB) and I also >> interconnected GNDs. The third micro sending the Tx signal was powered from >> the BBB. BBB is working well so far. >> >> Jordi >> >> El divendres, 11 març de 2016 17:00:01 UTC+1, Harvey White va escriure: >>> >>> On Fri, 11 Mar 2016 09:29:07 -0600, you wrote: >>> >>> >I would not recommend shorting outputs of two processor together, >>> something >>> >might get fried. >>> >>> Exactly right, the output drivers will likely overheat and perhaps be >>> damaged when one chip is outputting a different state than the other. >>> >>> In this case, it was a single output driving two inputs. With >>> properly connected grounds, there shouldn't be a problem with multiply >>> connected outputs. >>> >>> However, the question may be one of voltages. The maximum voltage >>> input to the processor is 3.3 volts, and if driven by a 5.0 volt >>> source can certainly damage the processor. >>> >>> Paranoid design would have a buffer (running from the processor's VCC) >>> connected to the real world, input to the real world, output to the >>> processor. At the other end (driving end) you use another buffer to >>> drive the line, both must be either inverting or non-inverting. For >>> each additional input to another processor, use another buffer. >>> >>> If the processors use different supply voltages, then you would want a >>> circuit to translate the voltage levels. There are chips that are >>> designed to do that. >>> >>> I use a similar idea when connecting I2C driven systems (PCA9517 works >>> well). >>> >>> RS-232 drivers work the same way, and in fact, would be very tolerant >>> of voltage level differences. I'd suggest a MAX232 style chip. The >>> outputs of the chip are +/- 9 volts, so absolutely cannot be connected >>> directly to a processor. >>> >>> Harvey >>> >>> >>> > >>> >Gerald >>> > >>> >On Fri, Mar 11, 2016 at 9:27 AM, Jordi Segura <jor...@gmail.com> wrote: >>> >>> > >>> >> Related to my unanswered problem below, main point I want to know is: >>> >>> >> >>> >> Is it safe to connect directly the same Tx external signal >>> simultaneously >>> >> to a couple of BBs ? >>> >> >>> >> Cheers, >>> >> Jordi >>> >> >>> >> El dilluns, 7 març de 2016 0:11:32 UTC+1, Jordi Segura va escriure: >>> >>> >>> >>> My BBGreen got fried (when I power it up it just dims once the power >>> led >>> >>> and that's all it does). >>> >>> >>> >>> >>> >>> Can someone explain me what I did wrong so it won't happen to me or >>> >>> others again? >>> >>> >>> >>> >>> >>> Explanation of what I did: The BBG died after several days working >>> 24/7, >>> >>> powered up from a power supply 5V 2A, with an 3G usb dongle >>> connected on >>> >>> it, and (maybe that's my fault ...) I connected the Tx output of >>> another >>> >>> microcontroller to one Rx input of the BBG but also to one Rx input >>> of a >>> >>> BBB (I had both the BBG and the BBB receiving the same Tx signal >>> from a >>> >>> third micro) >>> >>> The same power supply was powering both systems (BBG and BBB) and I >>> also >>> >>> interconnected GNDs. The third micro sending the Tx signal was >>> powered from >>> >>> the BBB. BBB is working well so far. >>> >>> >>> >>> >>> >>> Cheers. >>> >>> >>> >> -- >>> >> 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...@googlegroups.com. >>> >> For more options, visit https://groups.google.com/d/optout. >>> >> >>> > >>> > >>> > >>> >-- >>> >Gerald >>> > >>> >ger...@beagleboard.org >>> >http://beagleboard.org/ >>> >>> >> -- >> 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...@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...@googlegroups.com <javascript:>. > 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.
