quiescentcurrent Now • 100%
Pretty much. I'm not even sure if regular USB ports can talk to pins individually, let alone test them for shorts.
quiescentcurrent Now • 100%
Interesting, I just uploaded the .mp4 directly to lemmy and assumed this to be working. How else would you share a gif/short video?
USB was supposed to rule them all but it's now a mess of standards sharing the same connector. Different speeds, voltage, charging protocols, alt modes, even the number of pins used is variable.... For those asking, the thing is available on [Kickstarter](https://www.kickstarter.com/projects/electr/ble-caberqu-a-digital-usb-c-to-usb-c-cable-tester?ref=enskb0)
quiescentcurrent Now • 95%
Not sure what else, but the thing can tell you if a cable is USB2.0, USB3.0/3.1/.. or just for charging.
hackaday.com
EEVBlog also talked about this in a mailbag episode: https://www.youtube.com/watch?v=rEZQvSgdA2k&t=1839s And they also have different cable versions available: https://caberqu.com/
quiescentcurrent Now • 93%
I could design and produce a small batch of those adaptors.
Would anyone be interested in getting a prototype and helping to test it?
quiescentcurrent Now • 100%
You're 100% right, I've lost 'i' somewhere in my debugging process
byte upper_byte = input_bin >> (8+i) ; byte lower_byte = (input_bin >> i) & 0x00FF;
quiescentcurrent Now • 100%
Good idea, I've tried usleep after all lines, but no change..
quiescentcurrent Now • 100%
You're probably right, but that should only change the order of the outputs right?
Hey friends, I have a two [daisy chained shift registers](https://i.imgur.com/tZBQ45e.png) ([74AHC595](https://www.diodes.com/assets/Datasheets/74AHC595.pdf)) which are controlled via an ESP32. I want to set one output to high at a time before switching to the next. The code seems to work, but the outputs O_9 and O_10 are not [staying high](https://i.imgur.com/v5OOE1K.png) ([zoom](https://i.imgur.com/VpMbdW3.png)) after setting them, whereas all the other ones are working fine. This is the used code snipped: pinMode(SHIFT_OUT_DATA, OUTPUT); pinMode(SHIFT_OUT_CLK, OUTPUT); pinMode(SHIFT_OUT_N_EN, OUTPUT); pinMode(SHIFT_OUT_LATCH, OUTPUT); digitalWrite(SHIFT_OUT_N_EN, LOW); uint16_t input_bin = 0b1000000000000000; for(int i=0; i<17; i++){ byte upper_byte = input_bin >> 8; byte lower_byte = input_bin & 0x00FF; digitalWrite(SHIFT_OUT_LATCH, LOW); shiftDataOut(SHIFT_OUT_DATA, SHIFT_OUT_CLK, MSBFIRST, lower_byte); shiftDataOut(SHIFT_OUT_DATA, SHIFT_OUT_CLK, MSBFIRST, upper_byte); usleep(10); digitalWrite(SHIFT_OUT_LATCH, HIGH); delay(10) input_bin = input_bin>>1; } Is there anything I'm doing wrong, or any idea on where the problem may lie? I've already tried looking for shorts and other error sources, but the design was manufactured on a PCB and no assembly issues are noticeable.