**** BEGIN LOGGING AT Fri Apr 24 02:59:57 2020 Apr 24 03:00:10 i cannot even turn it on Apr 24 03:00:25 was just in and it was giving me problems Apr 24 03:00:47 MattB0ne: Sir, I am not messing w/ you. I am not trying to harass you even. Apr 24 03:00:54 I just know that sometimes... Apr 24 03:00:58 MattB0ne: didn;t you say earlier that it booted fine with the cape when powered via 5V adapter and not usb? Apr 24 03:01:23 Right. 5v adapter. Apr 24 03:03:31 MattB0ne: btw, *which* NHD-7.0CTP-CAPE ? there are multiple Apr 24 03:03:40 -N, -L, -V Apr 24 03:06:58 ah they're all the same cape, just with different displays Apr 24 03:09:19 GenTooMan: I am still bustin' hump back whales over here. Any input? Apr 24 03:09:31 weird choice to have the backlight controllable by software (pwm) yet turned *on* by default Apr 24 03:09:46 oh GOD Apr 24 03:09:50 they're pulling it up to 5V Apr 24 03:10:51 I am about to pull an old dayer w/ two chips, 30 jumper wires, and some neat circuit. Now, I am finally three jumper wires away from powering on this pup to test the outcome. Apr 24 03:10:53 Phew. Apr 24 03:12:19 Should I take a before and after photo? Apr 24 03:12:59 if MattB0ne/mastermind_ comes back while I'm not paying attention: remove R1 from that cape, it's pulling a beaglebone I/O up to 5V Apr 24 03:13:17 (and pray that processor pin isn't already destroyed now) Apr 24 03:13:50 Okay. Apr 24 03:14:09 Do you dare me to say it? Apr 24 03:14:30 I am not even sure how to articulate what you just typed. Apr 24 03:14:39 so don't articulate it but just copy-paste Apr 24 03:14:45 Oh. Okay. Apr 24 03:14:50 :P Apr 24 03:15:00 Barf-a-lamule! Apr 24 03:15:07 I'm still around for a bit anyway Apr 24 03:15:12 Okay. Good. Apr 24 03:15:16 probably Apr 24 03:15:18 What happened to GenTooMan? Apr 24 03:15:29 He was here, gone, and here again. Hmm. Apr 24 03:17:41 GenTooMan! Apr 24 03:23:17 https://drive.google.com/file/d/1DCFLm7p5wVSctOEj54UdG6xOaec1qp9U/view?usp=sharing is the BEFORE photo. Enjoy it while it lasts. Apr 24 03:23:43 I am about to put those two AA batteries you see on the right of the circuit into the battery holder. Apr 24 03:24:40 Nope. Still missing something. I need to have a way out as output. Apr 24 03:25:18 Misconfigured...still! Apr 24 03:29:58 You have a board with holes in it Apr 24 03:30:27 Good Noght Apr 24 03:33:18 Nice. Apr 24 03:33:23 Real nice. Apr 24 03:43:53 MattB0ne: remove R1 from that cape, it's pulling a beaglebone I/O up to 5V (and pray that processor pin isn't already destroyed now) Apr 24 03:44:33 zmatt: what is R1 Apr 24 03:44:49 oh crap Apr 24 03:45:37 well the board is still working is this an issue on the board or the cape Apr 24 03:45:38 a pull-up resistor on P9.14 (called "EHRPWM10" by the schematic), in the bottomleft of the schematic (on the SHND pin of the backlight driver) Apr 24 03:45:46 the cape Apr 24 03:52:03 I am not sure how to remove it Apr 24 03:52:19 I can send a pic of it Apr 24 03:52:27 you think that is what is wrong supposedly this was made for the BBB Apr 24 03:52:37 and was plug and play Apr 24 03:52:39 it's a definite design-mistake Apr 24 03:52:47 I don't know if it's what's causing any of your problems Apr 24 03:52:52 those sound more like power-supply issues Apr 24 03:53:07 but it wont kill the beagle just burnout the cape Apr 24 03:53:19 however, it probably doesn't help that the pull-up is causing the backlight to turn on the exact moment the beaglebone power supply is turned on Apr 24 03:53:29 should I just send it back Apr 24 03:53:38 no there's no risk to the cape, the risk is to the beaglebone Apr 24 03:53:44 yeah i guess I got lucky last time Apr 24 03:53:51 when it turned on Apr 24 03:54:15 when the screen pops so does the power LED Apr 24 03:54:42 have you tried trying to turn it on using the power button after connecting power? Apr 24 03:55:52 no i did not have to before it would power once the barrel jack was connected Apr 24 03:56:39 do this with the cape Apr 24 03:56:43 plugged in Apr 24 03:56:50 wish me luck Apr 24 03:57:31 just to clarify, had this worked plenty of times previously and now it no longer does, or had you simply not tested the cape much yet? Apr 24 03:58:17 it worked before Apr 24 03:58:29 and nothing changed? same power supply as before? Apr 24 03:58:34 yup Apr 24 03:58:42 that's really not a good sign Apr 24 03:59:06 ok I just plugged in did the flash Apr 24 03:59:11 now I will try and press power Apr 24 03:59:13 the beaglebone still works normally without the cape? Apr 24 03:59:17 yes Apr 24 04:01:09 pressing power just flashes Apr 24 04:01:43 MattB0ne: without cape attached, can you try: echo high >/sys/class/gpio/gpio50/value Apr 24 04:02:02 sorry, echo high >/sys/class/gpio/gpio50/direction Apr 24 04:02:19 ok Apr 24 04:03:28 i did it nothing happen Apr 24 04:03:32 okay good Apr 24 04:03:47 phew Apr 24 04:03:51 so bad cape Apr 24 04:03:52 change it back to input (echo in to that same attribute) Apr 24 04:04:06 then config-pin P9.14 gpio_pu Apr 24 04:04:13 cat /sys/class/gpio/gpio50/value Apr 24 04:04:16 should print 1 Apr 24 04:05:54 it does Apr 24 04:06:16 okay, so at least the pin seems okay Apr 24 04:06:44 maybe my cape fried Apr 24 04:06:52 with my last bbb Apr 24 04:06:57 it was attached to the cape Apr 24 04:07:30 wait so you're saying it worked previously with a different bbb and your problems are now with a different bbb? Apr 24 04:07:49 well I had that one BBB that I fried Apr 24 04:07:53 i had the same cape Apr 24 04:08:09 attached while you fried the bbb ? Apr 24 04:08:15 yes Apr 24 04:08:29 but it worked several times on the new one Apr 24 04:08:33 hmmm Apr 24 04:08:44 the only like it just worked 90 min ago Apr 24 04:08:51 but was doing that wierd thing with the power Apr 24 04:08:58 and now I cannot get it to turn on Apr 24 04:09:10 BBB working fine the entire time Apr 24 04:09:14 just bad when attached Apr 24 04:09:33 same power supply adapter that was fine before Apr 24 04:09:41 all this makes it hard to guess what's going on, since maybe the cape got damaged too Apr 24 04:10:40 do you know what the name is of the overlay used by this cape? Apr 24 04:10:42 yeah just wierd that it would peter out instead of just go dead Apr 24 04:10:49 indeed Apr 24 04:11:17 no but what was that command you told me to list out what was loaded I can tell you Apr 24 04:11:30 no you can't since you can't boot the bbb with cape :P Apr 24 04:11:40 damn Apr 24 04:11:53 it was an overlay specific to it I have it in the logs Apr 24 04:12:05 I remember when I was messing with the UART overlays Apr 24 04:12:26 did you try using the power button to turn it on after the initial flash? Apr 24 04:13:17 which *might* work if the problem is that the current surge during power-on is slightly too high Apr 24 04:13:30 (which doesn't explain why it worked before and now doesn't but *shrug*) Apr 24 04:14:09 it does the same thing when I hit power Apr 24 04:14:17 eprom thing maybe? Apr 24 04:14:19 okay, it was worth a shot Apr 24 04:14:20 no Apr 24 04:14:27 lol Apr 24 04:14:40 BB-BONE-NH7C-01-A0 maybe? Apr 24 04:14:52 yeah Apr 24 04:14:54 that was it Apr 24 04:16:48 okay it does at least configure the backlight pin, which hopefully protects the pin from the pullup to 5V, once the pin is configured by the kernel, but it's still bad Apr 24 04:16:59 I would not want a cape that does this attached to my bbb Apr 24 04:17:38 (or if I wanted to use the cape I'd get someone to desolder that resistor for me) Apr 24 04:18:22 it should also help reduce inrush current Apr 24 04:18:39 by not turning on the backlight immediately during power-on Apr 24 04:37:28 zmatt: http://www.nhdforum.newhavendisplay.com/index.php?topic=7831.0 Apr 24 04:37:35 zmatt: what do you think about this Apr 24 04:39:24 so there definitely is an inrush current problem Apr 24 04:40:39 however their workaround would make the pull-up issue even worse, and I suspect it isn't necessary if the pull-up is removed (which is a less invasive hardware patch anyway) Apr 24 04:41:32 btw the osd335x on the bbb-wireless has exactly the same power supply circuit as the normal BBB Apr 24 04:41:56 so their excuse is kinda bogus Apr 24 04:45:42 so this is just a bad cape design it seems Apr 24 04:45:47 i am going to see if I can send back Apr 24 04:46:08 it seems to have flaws yes Apr 24 04:46:46 I just made my first amplifier by accident. Apr 24 04:47:02 I am running 8.5v from a 3.0v source! Apr 24 04:47:34 Or this dc-dc converter is giving me the go-around. Apr 24 05:22:15 kremlin: I've used two different jtag adapters for debugging the bbb, flyswatter2 and a busblaster v4, no with both Apr 24 05:39:57 Hello, i am new with the BeagleBoard. I have a BeagleBoard AI. I want to have a static IP on the ethernet. i can i do that? Apr 24 05:43:20 henkk73: sure, you should be able to configure that using connmanctl ... I don't know much about it though, I use a different network manager Apr 24 05:49:11 Yes i can edit in Nano/etc/network/interfaces but i can not save it. no authority for it Apr 24 05:50:26 that is a config file for a different network manager (ifupdown), setting anything in there would conflict with connman and almost certainly cause problems Apr 24 05:50:46 the comments in it however give an example connmanctl invocation to set a static IP Apr 24 05:51:31 use "connmanctl services" to find the name of the ethernet interface (e.g. "ethernet_6cecebb9e210_cable" except it'll be slightly different on each beaglebone) Apr 24 05:51:55 then set your settings with: sudo connmanctl config --ipv4 manual --nameservers Apr 24 05:52:17 (where is the name for the ethernet interface found earlier) Apr 24 05:53:18 I'm curious though, why use a static ip instead of just referring to the beaglebone by hostname? (e.g. "beaglebone" or "beaglebone.local" depending on platform and network situation) Apr 24 05:58:42 I want the Beagle to look at a fixed IP range. Apr 24 08:22:25 hello. I have problem with RS485. Apr 24 08:22:36 https://mail.google.com/mail/u/0/#inbox/FMfcgxwHMsWPznfwwhBbTnFCflQNtVSL Apr 24 08:22:48 Please help. Apr 24 08:33:02 you posted a link to your own gmail inbox. that will not help anyone Apr 24 08:33:38 and if you now think of pasting the content of the email here, please don't. Use an external pastebin service Apr 24 08:40:58 thinkfat, https://pastebin.com/KZcqJpz8 Apr 24 08:47:46 hns100: that overlay uses an rts gpio (instead of using the actual rts pin on P8.33), even though I'm pretty sure that's not supported in the kernel version used in current images, but I'd need to check Apr 24 08:49:40 ah, or it may be written for the omap-serial driver, which hasn't been the default for years Apr 24 08:52:10 My GPIO RTS is P9_27 Apr 24 08:52:37 https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-RS485-00A0.dts Apr 24 08:52:58 "P9.13", // uart4_txd"P9.11", // uart4_rxd"P9.27", // uart4_de/re Apr 24 08:53:29 hns100: I know what the overlay tries to use, I just pointed out that trying to use a gpio (ANY gpio) for rts is most likely the problem Apr 24 08:53:49 I'm also double-checking which kernel driver supports what and how it's configured, but you'll need a bit of patience for that Apr 24 08:54:09 and do not paste multiline stuff into chat Apr 24 08:54:46 zmatt, thx. Apr 24 08:57:23 also bbl, meeting Apr 24 10:17:57 hns100: ok I've confirmed my suspicions: the default BB-UART4-RS485-00A0 uart is written for the old omap-serial driver, which hasn't been enabled for quite a long time Apr 24 10:19:13 the driver currently used (8250-omap) does not support using a GPIO as driver-enable signal (at least not in the latest stable kernel for beaglebones), it only supports using the actual RTS pin, which for UART4 is P8_33 Apr 24 10:22:10 zmatt, ok. How to fix? Apr 24 10:23:02 connect P8_33 to RTS(DE) MAX485 pin? Apr 24 10:23:32 use P8_33 as driver-enable signal, and the overlay needs to be fixed as well Apr 24 10:23:49 I've quickly made an overlay that should hopefully work Apr 24 10:24:01 if you clone my overlay-utils project: https://github.com/mvduin/overlay-utils Apr 24 10:24:29 then in that directory build the overlay with "make uart4-rs485.dtbo" Apr 24 10:24:51 optionally copy that dtbo file to /lib/firmware/ Apr 24 10:24:56 and configure its path into your uEnv.txt Apr 24 10:25:25 btw for custom overlays you should use uboot_overlay_addr4..7 or dtb_overlay, not uboot_overlay_addr0..3 Apr 24 10:25:46 zmatt Apr 24 10:25:51 thx Apr 24 10:25:54 uboot_overlay_addr0..3 are intended to override the overlays used for actual physical capes (that have identification eeproms) Apr 24 10:29:11 zmatt, this config working with standart 8250 uart driver? Apr 24 10:31:55 it should yes Apr 24 10:45:44 zmatt, thx. Apr 24 10:46:23 let me know if you've confirmed it works :) Apr 24 13:17:58 zmatt, not working ;( Reading Ok, Writing Not. My code : https://pastebin.com/RRKtAp92 Apr 24 13:19:27 https://pastebin.com/3HFQUcPy Apr 24 13:54:09 list Apr 24 14:09:00 will anyone help with RS485? Apr 24 14:17:53 I'm pretty sure you shouldn't use rtscts=True nor set ser.rs485_mode since the port is already set to rs485 mode by DT Apr 24 14:18:57 zmatt, ok. Apr 24 14:47:10 zmatt, not working ;( https://pastebin.com/xvL7wDZR Apr 24 14:50:52 you still have rtscts=True, remove that Apr 24 14:51:03 zmatt, ok Apr 24 14:51:20 also why are you opening the port, then closing it, then opening it again? Apr 24 14:51:53 and you're missing the parentheses after reset_input_buffer Apr 24 14:53:44 zmatt, Ctrl+C not closing port Apr 24 14:53:54 ? Apr 24 14:55:17 the port will always be closed when python exits, and the next time you start you're making a new Serial object which will automatically open Apr 24 14:55:27 zmatt, if you press ctrl+c, serial port is not closed. Apr 24 14:55:31 yes it is Apr 24 14:55:39 what makes you think it isn't? Apr 24 14:55:57 that's why the closing / opening is there. Apr 24 14:56:07 sorry that makes no sense Apr 24 14:56:16 zmatt, ok. Apr 24 14:56:37 it doesn't have to be clean code. ;) Apr 24 14:57:00 it's just silly. you're literaly just opening it, closing it, opening it again right after each other Apr 24 14:57:03 It is important that rs485 works. Apr 24 14:57:36 I understand, though I have no experience with the rs485 kernel support so that makes it more difficult to help you debug what's going on Apr 24 14:57:43 zmatt, I are right. Apr 24 14:58:07 ? Apr 24 14:58:36 You are right * :) Apr 24 15:00:54 func write returns 1 (Number of bytes written). Previously returned None. Apr 24 15:02:25 but now the big question is, is the driver-enable being asserted during the transmission? Apr 24 15:03:22 zmatt, I checking this. Apr 24 15:08:30 zmatt, no. CTS does not change. Apr 24 15:08:35 RTS you mean Apr 24 15:08:49 RTS. P8_33. Apr 24 15:09:18 I'll see if I can find something in a moment, I'm a bit distracted right now Apr 24 15:09:59 zmatt,ok. Apr 24 15:27:52 zmatt, if I use serial.rs485.RS485 - RTS changes. Apr 24 15:28:40 maybe pyserial unconditionally overwrites the default settings configured in the overlay Apr 24 15:30:29 I did the test - the program only sends data in a loop.In the loop: RTS high = 40 us, RTS low = 12 ms. Apr 24 15:31:35 I don't know what you mean by "only sends data in a loop" Apr 24 15:32:30 while True: ser.write(b"TEST") Apr 24 15:33:15 without ser.read() Apr 24 15:33:23 I'm a bit surprised that doing that ever allows RTS to go low Apr 24 15:35:32 well. maybe python just doesn't make to keep the input buffer filled I guess, especially with such short writes Apr 24 15:35:38 *doesn't manage to Apr 24 15:37:41 I think a program written in C would work identically. Apr 24 15:37:56 you're saying that when using your original loop that receives one byte and immediately transmits it back, the byte is transmitted but driver-enable is never asserted? Apr 24 15:38:07 you confirmed that with a scope? Apr 24 15:38:18 because that would be a bizarre kernel bug Apr 24 15:39:41 in loop (read/write - ECHO test)... RTS is strange. Apr 24 15:40:03 I'll make a screen Apr 24 15:42:52 scream? oh screen... Apr 24 15:42:56 https://paste.pics/938077219cb3b1b12048bbb817d3a47a Apr 24 15:43:04 GenTooMan: not that screen Apr 24 15:43:20 zmatt >D Apr 24 15:43:56 during the test I still sent data from the second port. Apr 24 15:44:02 hns100: this does look weird, but it's hard to interpret if you don't also capture rxd or txd Apr 24 15:44:11 "from the second port" ? Apr 24 15:44:19 it looks like something is hanging. Apr 24 15:44:57 my config: BBB <----- RS485 ---- > Moxa Uport <---- USB----> PC Apr 24 15:45:58 ok. Apr 24 15:46:48 hns100: wait are you using Serial.RS485 right now? because you definitely shouldn't Apr 24 15:47:09 that attempts to emulate rs485 entirely in software and would conflict with the kernel driver Apr 24 15:50:12 yes. Serial.RS485 Apr 24 15:50:18 don't use that Apr 24 15:52:56 https://paste.pics/29fa02eb421e68e8ca1250aa30bb58d8 Apr 24 15:53:23 https://paste.pics/8b4fe04cd96afe04398148ccb3399cdb Apr 24 15:53:46 this looks like the driver-enable signal is inverted for some reason, weird Apr 24 15:54:28 oh wait Apr 24 15:54:40 which line is rxd and which is txd ? Apr 24 15:54:48 https://easyupload.io/rnv2of <- CSV from logic Apr 24 15:54:56 I'm assuming it's (from top to bottom) rts, txd, rxd ? Apr 24 15:56:38 ehh, so what am I looking at here? Apr 24 15:56:51 as in, what's your python code here? Apr 24 15:57:02 Channel 3 == Pin 1 RO Max485 ===P9_11 Apr 24 15:57:29 *P8_11 Apr 24 15:58:20 Channel 2 == Pin 4 DI Max485 ===P8_13 Apr 24 16:06:12 Without Serial.RS485 - https://easyupload.io/oe46vo Apr 24 16:06:39 rts == pernament low. Apr 24 16:10:01 what does your python script look like for this test? Apr 24 16:59:06 hns100 ? Apr 24 17:13:23 the behaviour of Serial.RS485 just shows that pyserial doesn't know when the transmission has ended (i.e. ser.flush() completes before the transmission is actually complete, which should probably be considered a driver bug) so it deasserts rts too soon Apr 24 17:35:06 zmatt. Apr 24 17:35:39 zmatt, is it pyserial fault? Apr 24 17:35:59 or a Linux driver? Apr 24 20:00:08 anyone booted mainline (5.6 or 5.7) on the pocketbeagle? or any am3358 beaglebone? Apr 24 20:00:38 I mean "vanilla" mainline, not the -bone or -ti kernels that rcn builds Apr 24 20:01:41 all things considered it's not likely to boot. Apr 24 20:04:56 yeah... i'm going to try... just curious if anyone else has Apr 24 20:08:21 well their are still arcane bits left over in what TI has supplied from ancient SoC's and those little bits bite often. Apr 24 21:13:52 I see jkr is presenting at the open linux foundation conf :D Apr 24 21:14:05 Open source summit Apr 24 21:14:10 lost the name there for a moment Apr 24 21:14:27 ahem, not presenting.. but doing a conf thingy Apr 24 21:14:55 doing a Thing Apr 24 21:28:07 GenTooMan: it should absolutely boot, why would it not? Apr 24 21:30:49 hns100: what? Serial.RS485 not working well? dunno, doesn't really matter since you shouldn't use it anyway Apr 24 21:31:14 hns100: still not sure why the kernel's rs485 mode isn't working for you though Apr 24 21:32:36 zmatt, I'm solved this. Example in C : https://gist.github.com/hanusek/6886693811229605df42a00e661a7551 Apr 24 21:34:27 uhh what, you're configuring rs485 as active-low ? Apr 24 21:36:10 isn't a drive-enable normally active-high? Apr 24 21:36:13 *driver-enable Apr 24 21:38:46 hns100: VTIME and VMIN don't work on linux btw Apr 24 21:40:44 zmatt, ok Apr 24 21:41:09 it still shouldn't be necessary at all to use TIOCSRS485 if the overlay sets things up right Apr 24 21:41:42 though I configured it to use active-high driver-enable, not active-low which is what you seem to be configuring Apr 24 21:42:21 RX_DURING_TX should almost certainly not be enabled Apr 24 21:44:26 GenTooMan: If you are around now or later, please view this idea for attaching the Dynamixal Servo, BBB, HC126/04, and power via UART. Apr 24 21:44:27 ... Apr 24 21:44:33 https://drive.google.com/file/d/1PfYXmxbLLadFtMpmf1_XMrNpYkYSJkHk/view?usp=sharing Apr 24 21:44:52 Do you think this might be an alternative? Apr 24 21:46:15 I wonder if the meaning of active-low/high is unintentionally inverted in the kernel's rs485 definitions (as a result of rts normally being active-low) Apr 24 21:46:56 lol yep it is Apr 24 21:47:01 I'll fix the overlay Apr 24 21:50:07 zmatt, if I do not set these flags in the code - RS485 does not work. Apr 24 21:50:35 it looks like it works for me now without needing to use TIOCSRS485 Apr 24 21:50:46 lemme do a bit more testing and I'll commit the fixed overlay Apr 24 21:51:10 wait what Apr 24 21:51:51 zmatt, ok. thx. Apr 24 22:03:40 this is so weird, it's like the kernel is completely ignoring the DT configuration Apr 24 22:03:51 the rs485 settings at least Apr 24 22:09:49 https://www.kernel.org/doc/html/latest/driver-api/serial/serial-rs485.html Apr 24 22:10:02 it seemed to me that using the rs485 structure is standard. Apr 24 22:10:28 yeah it seems to work with pyserial also if you set ser.rs485_mode = serial.rs485.RS485Settings( rts_level_for_tx=False, rts_level_for_rx=True ) Apr 24 22:12:52 This should work transparently? Controlled by driver (DT)? Apr 24 22:13:13 yes that just uses TIOCSRS485 Apr 24 22:14:34 in either case however I still don't understand why the overlay rs485 properties are being ignored Apr 24 22:14:50 also there seems to be a glitch on rts when the port is opened, ew Apr 24 22:17:34 ahh good ole rs485 :D Apr 24 22:21:17 oh what the fuck linux... drivers/tty/serial/serial_core.c defines uart_get_rs485_mode() which parses the rs485 properties defined in the rs485 devicetree binding, but this is not actually invoked anywhere in the serial core, only in a few specific serial drivers, not including 8250 Apr 24 22:21:53 this is really fucked since it means that RTS will be high (i.e. driver-enabled) until software has the chance to fix things Apr 24 22:26:09 :D Apr 24 22:27:05 well, fwiw, I'm glad someone who (1) understands the code (2) understands wtf it -should- be doing .. has the chance to look at it. Apr 24 22:28:02 I know there were several of these kinda reasons I dumped doing rs485 straight from linux .. because I had *very* little confidence it was capable of proper TX_EN support, needed for 485. 422 wouldn't matter, ofc :) Apr 24 22:28:24 but its -critical- for 485. Else other devices, at best, will misread/write things. Apr 24 22:31:18 hns100: you might actually want to not use any uart at all. instead, configure the pinmux via cape-universal (see https://pastebin.com/MKtWJ8G8 for a simple python wrapper), making sure to configure the rts pin only *after* configuring the uart, like: https://pastebin.com/3YWGSihF Apr 24 22:32:00 ... except I just discovered that cape-universal didn't bother defining a state for the uart rts signal on P8_33 Apr 24 22:32:03 ARGH Apr 24 22:32:17 oh dear Apr 24 22:32:22 veremitz: yeah if tight turnaround time is needed I'd use pru Apr 24 22:32:28 it would be great to Fix this properly :/ Apr 24 22:32:47 one of these days I'll write a short article on doing it PRoperly, possibly even using the Pru. Apr 24 22:38:44 zmatt, I disappear. thanks for the help. ;) Apr 24 22:40:01 BELA Cape! Apr 24 22:40:14 I found one! Apr 24 22:40:31 Music...here I come! Apr 24 22:40:56 really Apr 24 22:41:07 GenTooMan i da' hizzy! Apr 24 22:41:27 Hello GenTooMan: Did you see that link I posted while you were away? Apr 24 22:41:33 well it's probably better than the original RPI which was 12bit PWM Apr 24 22:41:46 Oh. 16-bit! Apr 24 22:41:48 this whole thing really is a shitshow, and for no good reason. overlays that don't work with the currently-default driver, a driver that ignores the specified properties, a property which does (if it had been honored) the exact opposite of what its name says it does Apr 24 22:42:18 My bone only plays 8-bit w/ aplay from ALSA. Apr 24 22:42:44 honestly why did we move from omap-serial to 8250-omap anyway? the continued backwards compatibility with the ancient and crufty 8250 is something to lament and ignore as much as possible, not something to embrace Apr 24 22:42:52 zmatt: is it something that can be fixed?! Apr 24 22:42:54 set_: you're just doing something wrong, the audio interface is 32-bit Apr 24 22:43:02 lol Apr 24 22:43:15 All I did was tell my BBB to: aplay round.wav. Apr 24 22:43:19 well, 24-bit effectively (in a 32-bit slot size) Apr 24 22:43:37 set_: maybe your wav is 8-bit? I dunno what you do Apr 24 22:43:48 Oh. Well, the aplay from ALSA keeps telling me I am playing 8-bit. Apr 24 22:43:50 Oh. Maybe. Apr 24 22:43:59 or maybe aplay needs to be given proper options Apr 24 22:44:10 That is what i think needs to happen. Apr 24 22:44:15 aplay needs other commands. Apr 24 22:44:17 it's not really designed to be a user-friendly audio playback program, it's more a debug utility Apr 24 22:44:24 OH. Apr 24 22:44:25 ! Apr 24 22:44:35 So, I should check it out before I wreck it. Apr 24 22:44:41 Good idea. Apr 24 22:44:54 Testy, testy, 1, 2, 3? Apr 24 22:44:57 but trust me, the hdmi audio on the bbb is not 8-bit Apr 24 22:45:08 I am not using the hdmi. Apr 24 22:45:19 it's the only audio the bbb has Apr 24 22:45:34 I am using the USB to chip. Apr 24 22:45:52 the what? Apr 24 22:46:00 Let me better explain. Apr 24 22:46:08 Please hold while I gather thoughts. Apr 24 22:46:18 Okay, so... Apr 24 22:46:32 anyway, if you're using an usb audio interface then the supported formats will depend on what usb audio interface you'r eusing, but I can guarantee you it will support 16-bit audio and almost 100% certainly 24-bit and/or 32-bit Apr 24 22:46:35 more. words. needed. Apr 24 22:46:47 I don't really care about the details Apr 24 22:46:49 Okay. Apr 24 22:46:52 Fine. It is Apr 24 22:46:54 bigger words needed D: Apr 24 22:47:00 it is a usb dongle for audio. Apr 24 22:47:18 I will go to aplay command and type aplay --help! Apr 24 22:47:23 set_: just rest assured, if you're getting 8-bit audio then you're just doing something wrong Apr 24 22:47:28 Well, w/out the "!" Apr 24 22:47:33 it's you, it's not the hardware Apr 24 22:47:35 Okay. Apr 24 22:47:37 Okay. Apr 24 22:47:55 I am not even sure if it is 8-bit. It just says it is. Apr 24 22:48:08 "Now playing 8-bit audio" Apr 24 22:48:36 It plays the old CD download to my computer that I changed from mp3 to wav. Apr 24 22:48:51 maybe you messed up the conversion Apr 24 22:48:57 Probably. Apr 24 22:49:15 "I knew to not kick it hard." Apr 24 22:49:32 Wait... Apr 24 22:49:47 Wait until the BELA shows up. That sucker is getting plugged into the guitar somehow. Apr 24 22:50:09 Duh, duh, duh. "We are not going to take it!" Apr 24 22:51:19 GenTooMan: Did you see? https://drive.google.com/file/d/1PfYXmxbLLadFtMpmf1_XMrNpYkYSJkHk/view?usp=sharing Apr 24 22:52:05 Some fellow is telling me to use a HC125 instead of the HC04. Oh and by the way, I made 3.0v turn into 8.5v last night by accident. Luckily, I did not plug in my BBB just yet. Apr 24 22:58:05 set_ I suggest you use an LVC1T125 instead because it's inputs can handle 5V those are SMT parts I suggest using the SOT23-5 packages because they are easier to solder. Apr 24 22:58:26 Okay! Apr 24 22:58:39 Wait. Apr 24 22:59:01 What happened to the old way of doing it, e.g. my HC126 DIP and HC04 DIP? Apr 24 22:59:37 Those inputs can handle 5v. Apr 24 23:00:42 2v to 6v? Apr 24 23:00:43 yeah... but only at 5V Apr 24 23:01:40