<sigstoat[m]>
oh, hm, i interpreted that as applying 5V to an output, but you didn't specify, and that _would_ be an odd thing to do. that i'd try to avoid. applying 5V to an input should be fine, per the recommended operating conditions of the SN74LVC1T45
wiebel[m] has joined #glasgow
<wiebel[m]>
The SN74LVC1T45 is specified to drive 24mA at 3.3V if you drive the pins with 5V at very low impedance you have the 33Ohm RN* to reduce the maximal current to 50mA which is out of spec but just within the absolute maximum ratings, so you should be fine.
<wiebel[m]>
* impedance you still have the
<wiebel[m]>
But mind you, like sigstoat mentioned, that should be avoided. And if the voltage difference exceeds the mentioned 1.7V the transceivers may not survive this abuse.
<wiebel[m]>
Alexeyan: Not pin1 and pin2 as the level of each port is the same, but you could do with PortA1 <-> PortB1. But then again you are aware that you can get 10 8ch levelshifter ready on a breakout board for 1 Dollar. And they probably outperform the glasgow in that regard.
<Alexeyan[m]>
Thank you for the reply. I know standalone level shifters are cheap and I don't intend this to run for a long time. I just want to confirm an issue with some LED strips that misbehave where someone suggested adding a 3.3V to 5V level shifter to the data line. If I can replicate that with my glasgow I could confirm that this fixes the problem and order one to fix it permanently. PortA1 to PortB1 would also work for me.
<wiebel[m]>
Careful the timing for addressable led strips are pretty tight although the delay in the fpga should be pretty deterministic. Normally those can easily be driven with 3.3v. (Thinking of WS2812)
<wiebel[m]>
Keep us posted if it worked.
<Alexeyan[m]>
I have some older WS2812 that work fine with 3.3v, but the new ones are WS2814, which are supposedly known to be quite picky about the data line voltage levels. Makes sense, since they operate at 24V compared to the 5v from the 2812.
<Alexeyan[m]>
So there is no applet already that does something similar that I could use? Is there anything I can use to copy the boilerplate? I haven't looked into writing applets yet.
<wiebel[m]>
Not that I'm aware of, it's not exactly ment for such a thing. But there is a video-ws2812-output applet that would drive the leds directly.
<Alexeyan[m]>
I've seen that, but that expects raw RGB values (I think) over a network socket and I didn't get it to display individual colors (i.E. sending b"\x00\xff\x00\x00"), whereas my Arduino shows the correct colors, but has a lot of noise on top of it (random LEDs displaying random colors)
<wiebel[m]>
It's for sure a nice experiment but if it doesn't work it could still be due to the latency of the fpga. You can build a unidirectional makeshift level shifter with a single transistor that will be much faster.
DX-MON| has joined #glasgow
nyaanotech has joined #glasgow
XgFgX has joined #glasgow
adamgreig has joined #glasgow
sugarbee1 has joined #glasgow
DX-MON has quit [Quit: I'm not disconnecting, you're disconnecting!]
nyanotech has quit [Quit: No Ping reply in 180 seconds.]
XgF has quit [Quit: No Ping reply in 180 seconds.]
agg has quit [Remote host closed the connection]
itsmk has quit [Remote host closed the connection]
sugarbeet has quit [Remote host closed the connection]
itsmk has joined #glasgow
hcsch has joined #glasgow
redstarcomrade has joined #glasgow
<whitequark[cis]1>
the latency of the entire thing would be under 20ns
<whitequark[cis]1>
i would be very surprised if that is an issue
<whitequark[cis]1>
about 3ns per level shifter, and i'd be surprised if it's more than 15ns in the fabric
redstarcomrade has quit [Read error: Connection reset by peer]
jstein has joined #glasgow
<bartdewaal[m]>
Thanks. The reason I ask is because I'm not sure how careful I need to be, for example to get the Rx and Tx of a UART the right way round if I'm not 100% on the hardware
<bartdewaal[m]>
I'm still not sure how the voltage mirroring function works, and I don't want to wildly apply voltages to pins to try and figure it out
<bartdewaal[m]>
I get that the schematics are available, but as a consumer it would be very nice if I didn't need to dig into datasheets for basic information on how to use my project. The marketing on crowdsupply says "All I/O are ESD, over- and under-voltage protected. " but from what you're saying I should be careful to get the pinout right to prevent damage to the transceivers.
jdek has quit [Quit: Connection closed for inactivity]
GNUmoon has quit [Remote host closed the connection]
Attie[m] has joined #glasgow
<Attie[m]>
There are two "voltage" pins - V is the regulated output that is shared by the level shifters, and S is the sense / input pin
<Attie[m]>
there is always risk of damage when working with electronics, but Glasgow has been tested in some pretty rough conditions (e.g: shorted output)... I would be careful of attaching an input signal that is higher than the port's configured output voltage
GNUmoon has joined #glasgow
<Attie[m]>
you're not likely to damage Glasgow by connecting Tx to Tx, but you might damage your other device - the order between Tx and Rx can usually be determined with a scope, logic analyser or even multimeter
edef has joined #glasgow
V has joined #glasgow
<bartdewaal[m]>
Thanks! I assumed S was shield, so I'm happy I didn't go experimenting. I know a logic analyzer can be used - I'm hoping to use the Glasgow as one
tec4 has quit [Quit: bye!]
tec4 has joined #glasgow
<whitequark[cis]1>
the transceivers are incredibly abuse-resistant, the only times I've seen people kill them is by over-volting them above 6 V
<whitequark[cis]1>
(e.g. someone here recently killed one by connecting 12 V to it)
<whitequark[cis]1>
nothing else, including shorting them to ground, shorting them to other voltages, connecting them to pins with wrong directions, etc seems to really damage them in any way
<whitequark[cis]1>
we once did a test with a dead short of a transceiver without the protective 30 ohm inline resistor for 24 hours
<wiebel[m]>
Is it fair to assume the failure mode is open so the fpga is protected, even on 12V?
<whitequark[cis]1>
we did not find any difference in characteristics before/after, even though it heated the board to like over 80 C
<whitequark[cis]1>
wiebel[m]: we do not and cannot guarantee any particular failure mode in overvoltage conditions
<whitequark[cis]1>
the transceivers are not designed to fail in any particular way, they simply have AMR of 6 V
<whitequark[cis]1>
I don't recall what was the failure mode in that incident but it might've been a short to ground on the overvoltage side
<whitequark[cis]1>
also, note that the transceivers have ESD structures, meaning that if you e.g. configure a port for 3.3 V then connect 5 V to one pin, it will power all the other transceivers via the ESD diode of the one you're overvolting
<whitequark[cis]1>
so it will hit your device or whatever you have connected there with 5 V
<whitequark[cis]1>
regarding the FPGA, I've never heard of anyone completely destroying the FPGA, but I recall some incidents where the transceiver and the FPGA pin connected to it were destroyed. I think the failure mode of the FPGA I/O block is that it gets vaporized and fails open
<whitequark[cis]1>
but, again, we cannot and do not guarantee that
<bartdewaal[m]>
Thanks, that's very clear. I'll make some effort to set things up properly, but I won't be too worried about getting it wrong as long as I'm dealing with 5V or lower electronics (and I understand there are no guarantees)
<whitequark[cis]1>
if you destroy just one FPGA pin, there's a spare pair of pins routed out on the board you could connect, and then modify the Glasgow software to use it instead
<wiebel[m]>
I was only interested on evidence not on any kind of liability. I' don't see me blaming anyone for destroying electronic devices I intentionally tinker with.
<whitequark[cis]1>
as the project lead I feel it would be irresponsible of me to encourage any particular assumption where we did not do a statistically meaningful failure testing in a batch of devices (which would be pretty expensive)
<wiebel[m]>
But sure I fully understand that you don't want to state anything in that regard.
<whitequark[cis]1>
all I can say is that while designing it we explicitly decided not to think too much about what happens if you exceed the AMR, just to keep the scope of the project manageable
<whitequark[cis]1>
bartdewaal[m]: yes, that's what I do (and I've never destroyed a transceiver myself)
<whitequark[cis]1>
I think the most I've destroyed was one or two pins on the DUT where I got directionality egregiously wrong and then didn't notice it in time
<whitequark[cis]1>
there is also the glasgow voltage-limit command that prevents you from accidentally inputing 5 V when your lab doesn't even have any 5 V devices
<whitequark[cis]1>
e.g. glasgow voltage-limit AB 3.3 will prevent you from ever doing e.g. glasgow run uart -V 5 by accident, on hardware level (this is recorded in the device itself and monitored by the firmware)
<whitequark[cis]1>
i remember feeding 3.3V or even 5V to an SPI flash by accident. i think even a 1.8V SPI flash worked on 5V, miraculously, with no ill effect i could notice
<whitequark[cis]1>
it did get hot enough to burn me though
<whitequark[cis]1>
<bartdewaal[m]> "I'm still not sure how the..." <- voltage mirroring is entirely software based. the software reads the voltage from the S pin, sets the V pin to output the same, then sets up monitoring of the S pin so that if the voltage ever goes out of a ±10% tolerance the V pin will stop getting power
<whitequark[cis]1>
the monitoring however is hardware/firmware-based. the chip used to read voltage from the S pin autonomously shuts down the LDO and then the firmware reports this condition to the host
<whitequark[cis]1>
the idea is that this functionality prevents back-feeding the DUT through its ESD structures even if both the host software and the 8051 firmware hang
<bartdewaal[m]>
So the idea of the mirror function isn't so much that you don't have to know the voltage of the DUT, but more that it will stop sending power if the DUT turns off (or similar)
<whitequark[cis]1>
it's sort of both
<whitequark[cis]1>
you can use glasgow voltage to find out the voltage at the S pin