**** BEGIN LOGGING AT Mon Jul 15 03:01:15 2019
Jul 15 12:30:53 <pranav_kumar[m]> can anyone point out the problem what is the problem in the second video . where i am running the same code . But deriving two led which are connected to npn transistor base pins and the output get currupted . while this is not the case in the first video . All the circuit is powdered by  beagle bone only : 1.  https://youtu.be/R3kSgY7nwpk         2.  https://youtu.be/fG5O7ty_u3c
Jul 15 12:31:59 <pranav_kumar[m]> i am using 74hc299 universal shift register  for the implementation purpose
Jul 15 12:34:27 <pranav_kumar[m]> here is the code https://github.com/pranav083/pocket_beagle-work/blob/wip/pru_wip/74hc299_10_v1.p and the circuit diagram is in here : https://github.com/pranav083/pocket_beagle-work/blob/master/2.shift_74hc299/BB_Black/74hc299_10/74hc299_10_bb.png . just their is only data and clk pin is attached to the npn transisitor in the video
Jul 15 12:35:44 <pranav_kumar[m]> if anyone have any regarding this or want more explanation plz ask
Jul 15 13:24:41 <zmatt> ah, he left, that saves me the effort of trying to figure out what he was asking
Jul 15 13:25:30 <pranav_kumar[m]> hello zmatt  can you help me regarding my problem
Jul 15 13:25:45 <zmatt> oh you're still here
Jul 15 13:26:05 <zmatt> I can't watch videos, I'm at work
Jul 15 13:27:03 <pranav_kumar[m]> yes as i use riot app so it make me easy  to respond the  msgs
Jul 15 13:28:17 <pranav_kumar[m]> i you get time just watch the video and it is hardly 28 sec total length of video
Jul 15 13:33:30 <zmatt> uhh, beware that what you're doing in your .png conflicts with the eMMC on the beaglebone
Jul 15 13:34:06 <zmatt> it will only work if you boot from sd card *and* disable eMMC in /boot/uEnv.txt
Jul 15 13:34:38 <zmatt> and even then you'll see momentary data glitches on those lines durign boot
Jul 15 13:34:46 <zmatt> *during
Jul 15 13:35:16 <zmatt> (eMMC uses P8.03-06 and P8.20-25)
Jul 15 13:36:21 <pranav_kumar[m]> ok thanks , yes exactly as you can see in this logic analyzer file https://github.com/pranav083/pocket_beagle-work/tree/wip/logic_out
Jul 15 13:38:22 <zmatt> to verify pin configuration, try my show-pins utility: https://github.com/mvduin/bbb-pin-utils/#show-pins
Jul 15 13:39:34 <pranav_kumar[m]> thats why i see l lot  of high frequency signal when analysing the signal through the logic analyzer . Again thanks a lot , I will definitely try implementing this.
Jul 15 13:39:51 <zmatt> best solution is to use different pins
Jul 15 13:40:22 <zmatt> e.g. P8.07-19
Jul 15 13:42:02 <pranav_kumar[m]> as i am using sd card , and will disable the emmc and if the problem still not resolve then i will  shift to the other stated pins
Jul 15 13:43:07 <zmatt> as long as you're aware that even if you disable eMMC in /boot/uEnv.txt, there will still be activity on those lines during boot
Jul 15 13:43:21 <zmatt> (which happens before /boot/uEnv.txt is read)
Jul 15 13:44:13 <pranav_kumar[m]> ok fine
Jul 15 13:44:45 <zmatt> also, if you're booting from sd card, then you may need to erase eMMC using   sudo blkdiscard /dev/mmcblk1   to ensure things work properly, this forces the beaglebone to use the bootloader present on sd card rather than the one on eMMC.  otherwise, if the bootloader on eMMC is outdated, it may not be able to properly understand the settings in your /boot/uEnv.txt
Jul 15 13:48:56 <pranav_kumar[m]> ok thanks for the info. Then , I think it better for me to move on the pins that you have suggested  🙂 .
Jul 15 13:51:30 <pranav_kumar[m]> one another thing that i want to ask , that the pin mapping of beaglebone rev c version is same as beaglebone wireless
Jul 15 13:51:48 <zmatt> as the beaglebone *black* wireless, yes
Jul 15 13:52:04 <zmatt> (the beaglebone green wireless is a mess)
Jul 15 13:52:55 <pranav_kumar[m]> i have to do the same thing beaglebone wireless and pocket beagle as a part of my gsoc project this year.
Jul 15 13:53:34 <pranav_kumar[m]> <zmatt "(the beaglebone green wireless i"> then i am saved.
Jul 15 13:58:33 <pranav_kumar[m]> i am providing a bidirectional communication support using 74hc299 universal shift register for multiple devices. A reference example may be a slower version of  SPI protocol  but  a type of async communication. for my solution.
Jul 15 13:59:20 <zmatt> I have no idea what you mean by that or why you are telling me this
Jul 15 14:03:10 <pranav_kumar[m]> <zmatt "I have no idea what you mean by "> no bascially i am asking that is it possible to implement spi protocol kind of solution using  shift register or i should look for some better protocol for this . Any opinion if you have
Jul 15 14:03:56 <zmatt> I don't understand how a shift register would be of any use for that
Jul 15 14:04:57 <zmatt> the beaglebone has two integrated spi controllers.  if you need spi, my suggestion would be to use one of those
Jul 15 14:09:14 <pranav_kumar[m]> just as by using other pins of beagle bone and enabling it for doing the bidirectional  communication
Jul 15 14:09:55 <zmatt> I'm sorry, I have no idea what you're trying to say
Jul 15 14:11:42 <pranav_kumar[m]> <zmatt "I'm sorry, I have no idea what y"> thanks for help you had provided me .thanks a lot 🙂
Jul 15 15:23:52 <coolgamesnet>  /close
Jul 15 18:08:13 <webchat> any luck with webchat?
Jul 15 18:08:20 <webchat> k. just checking.
Jul 15 18:09:27 <jkridner[m]> zmatt: I've made an AI-capable version of show-pins. Not sure if you've seen my patches.
Jul 15 18:11:15 <zmatt> nope, where should I have seen them?
Jul 15 18:12:17 <zmatt> I should probably try to make show-pins auto-detect the platform and use the appropriate table instead of having a different version for each device
Jul 15 18:12:59 <zmatt> although iirc the am335x and am572x versions have more differences than just the data table
Jul 15 18:13:16 <zmatt> I'm assuming you based it on my bbx15 version?
Jul 15 20:16:18 <zmatt> jkridner[m]: btw, so far we've encountered in total 7 beaglebones claiming to be industrial (A335BNLTEIA0) while they're not: one manufactured (according to eeprom data) in 2018 week 25, six from 2019 week 3
Jul 15 20:16:46 <jkridner[m]> :-(
Jul 15 20:16:52 <jkridner[m]> I'll ping Hari again.
Jul 15 20:17:07 <jkridner[m]> don't think I ever got a full response.
Jul 15 20:17:08 <zmatt> do you want their serial numbers?
Jul 15 20:18:09 <jkridner[m]> if you could send them by e-mail.
Jul 15 20:18:19 <jkridner[m]> Seems they started "looking into it" on June 11.
Jul 15 20:18:44 <jkridner[m]> really not good if they can't manage their test programs.
Jul 15 20:19:10 <jkridner[m]> do the part numbers on the processors reflect industrial temperature grade?
Jul 15 20:34:57 <zmatt> jkridner[m]: no, they're not industrial.  it wouldn't make sense anyway, the black-industrial has more differences (including different pcb color and conformal coating)
Jul 15 20:35:06 <zmatt> jkridner[m]: email sent
Jul 15 20:35:27 <jkridner[m]> oh, right, forgot about the color.
Jul 15 20:35:46 <jkridner[m]> the conformal coat was dropped.
Jul 15 20:36:09 <zmatt> ah
Jul 16 02:40:55 <ksft> is it possible to reliably turn a GPIO pin on and off to send serial data at 250 kbps?
Jul 16 02:45:42 <zmatt> uhh, why not use a serial port for that purpose instead? :P
Jul 16 02:47:36 <ksft> doesn't it send extra bits?
Jul 16 02:48:14 <zmatt> what kind of signal are you trying to produce exactly?
Jul 16 02:48:34 <ksft> input for an RS-485 chip
Jul 16 02:48:52 <zmatt> that's not really useful information
Jul 16 02:49:06 <zmatt> also... 250 kbps? RS-485?  are you trying to generate DMX ?
Jul 16 02:49:12 <ksft> yes!
Jul 16 02:49:23 <ksft> (I thought it was too obscure a protocol)
Jul 16 02:51:03 <zmatt> for the most part a serial port is fine for DMX, although making accurate break and mark-after-break timing might be a bit trickier.  if you want it really tight you could use PRU to produce the signal, either using PRU's direct GPIO or using the PRUSS UART
Jul 16 02:51:38 <ksft> I know a Raspberry Pi sends a start bit, a parity bit, and a stop bit
Jul 16 02:51:48 <zmatt> DMX doesn't use parity
Jul 16 02:51:52 <ksft> I assumed that was a standard thing for serial pins
Jul 16 02:52:00 <ksft> yeah, that's why I thought it would be a problem
Jul 16 02:52:22 <zmatt> it's just "8N1", i.e. start bit, 8 data bits, stop bit, like most asynchronous serial communication
Jul 16 02:52:44 <ksft> it does that for every octet?
Jul 16 02:53:02 <zmatt> yes
Jul 16 02:53:57 <zmatt> every frame consists of a break, a bit of idle (aka "mark-after-break"), then up to 513 bytes: a start-byte which is zero, followed by the data bytes
Jul 16 02:54:46 <ksft> can a BBB's serial port do that?
Jul 16 02:54:57 <zmatt> (unless you also want to support RDM, then things get more interesting)
Jul 16 02:55:10 <ksft> I was hoping to do that eventually
Jul 16 02:58:38 <zmatt> a serial port can do that, but like I said it'll be difficult to get completely consistent duration for break and mark-after-break.  this may or may not matter... the spec isn't too tight, DMX512-A spec says: break length min 92 μs, typ 176 μs, no max.  RDM spec says min 176 μs, max 352 μs
Jul 16 02:59:33 <zmatt> for MAB the DMX512-A spec says min 12 μs max 1s, RDM lowers the max to 88 μs
Jul 16 02:59:55 <ksft> what are the start bit and stop bit?
Jul 16 03:00:13 <ksft> er, was "8N1" a description of the serial port or of DMX?
Jul 16 03:00:14 <zmatt> oh it actually uses min 2 stop max 21 stop bits, not 1 stop bit
Jul 16 03:00:55 <zmatt> 8N1 is an abbrevation often used for 8 data bits, no parity, 1 stop bit (the most common configuration for serial ports), but apparently dmx officially requires 2 stop bits
Jul 16 03:01:40 <ksft> are start bits always 0 and stop bits always 1, like DMX requires?
Jul 16 03:01:42 <zmatt> anyway, if you do want to support RDM eventually, you may end up having to use PRU anyway
Jul 16 03:01:55 <zmatt> yes, that's standard for asynchronous serial communications
**** ENDING LOGGING AT Tue Jul 16 03:02:17 2019