**** BEGIN LOGGING AT Mon Apr 30 03:00:06 2018 Apr 30 04:15:44 good evening Apr 30 04:19:58 mornin' Apr 30 09:23:59 zmatt: sorry, I fell asleep, what did the other source say? Apr 30 09:32:03 the comment in my source code was right, so it should be NEGEDGE Apr 30 09:32:16 i.e. bit 7 set Apr 30 09:34:34 Alright! Apr 30 09:35:12 Is math possible in pasm? Like binary or's between #define's Apr 30 09:35:24 Nevermind, I will simply test it Apr 30 09:35:34 that. :P Apr 30 09:36:45 But I don't understand why we choose 32-bits as slot size Apr 30 09:37:22 hello everyone Apr 30 09:37:24 some codecs might support 24-bit slot size, but 32-bit is far more common Apr 30 09:38:29 I have little query regarding the USB Host for USB drive support Apr 30 09:39:07 BBB board support all manufacture pen drive? Apr 30 09:39:33 bou4: plus to get a 24-bit slot size the master clock needs to be a multiple of 48 * 48 kHz while normally it's a power-of-two multiple of 48 kHz Apr 30 09:40:56 NIkunj_: the usb protocol is standardized. why would the bbb care about the manufacturer of the usb drive? Apr 30 09:48:38 I don't find the slot size in the datasheet of the codec Apr 30 09:48:49 which codec is it? Apr 30 09:49:54 Cirrus Logic's CS4272 Apr 30 09:50:02 https://d3uzseaevmutz1.cloudfront.net/pubs/proDatasheet/CS4272_F1.pdf Apr 30 09:52:53 section 5.1.2, "In Master Mode, [...] SCLK is equal to 64x Fs." Apr 30 09:52:57 i.e. 2 slots x 32 bits/slot Apr 30 09:56:20 5.1.3.2 shows supported ratios. it seems 24 bits/slot is only supported when the codec is in slave mode and provided with an external master clock of 18.432 MHz (384 * 48 kHz) Apr 30 09:57:27 actually that's for standalone mode, hold on Apr 30 09:58:39 same situation for control port mode (section 5.2.3.2) Apr 30 10:02:29 (except in that in control port mode, 36.864 MHz master clock is also supported) Apr 30 10:05:07 Aha, I understand, thanks! Apr 30 10:17:00 I really do hate statements like "It is recommended that SCLK be 64x Fs to maximize system performance." ... like what the fuck does that *mean*? Apr 30 10:48:25 bou4: don't forget to actually configure the codec into i2s format btw, it defaults to lj format instead Apr 30 10:49:30 (or configure mcasp for lj too, it's basically the same but with opposite lrck polarity and no data delay) Apr 30 14:09:14 Is there a standard C++ GPIO library? Apr 30 14:10:44 "standard" ? doubtful Apr 30 14:10:59 I did work a bit on a class, although I'm not quite happy with it yet => https://gist.github.com/mvduin/578509d458da8948ae3a14a81dc639e4 Apr 30 14:12:03 there are a fair number of subtleties with the sysfs gpio interface Apr 30 14:12:08 I simply need to set one pin high Apr 30 14:12:20 And am in no mood to write a full flexed library for it Apr 30 14:12:32 So maybe I will simply do one write to sysfs Apr 30 14:12:38 And use no library Apr 30 14:12:47 bou4: jack mitchells libsoc. or just dump file io Apr 30 14:13:08 dumb, even Apr 30 14:14:46 bou4: echo high >$gpio/direction where $gpio is the sysfs directory for the gpio Apr 30 14:15:43 bou4: or use the GpOut class in the gist I linked Apr 30 14:17:02 GpOut{ path, true }; Apr 30 15:19:46 Weird Apr 30 15:20:20 ? Apr 30 15:20:32 Do you know why https://pastebin.com/raw/tujqfE6L doesn't work Apr 30 15:26:59 you're using a buffered output class and neither closing nor flushing the streams Apr 30 15:27:14 when they're implicitly closed (hence flushed) at end of scope, they will do so in reverse order Apr 30 15:28:37 also keep in mind that writing "out" (or equivalently "low") to direction means you're setting it to output-low Apr 30 15:28:46 write "high" to set it to output-high Apr 30 15:29:53 what do you mean with output-low? that the value doesn't need to be written 1 to? Apr 30 15:30:03 errr, output-high* Apr 30 15:30:18 output-high as in driving the pin high Apr 30 15:31:43 you can't change a pin from input to output without picking which value should be output, that's why you should write "low" or "high" to direction to select the initial output level Apr 30 15:32:02 writing "out" is still accepted, but it's just a synonym for "low" Apr 30 15:32:58 Thanksss, that did the job! Apr 30 15:34:07 maybe add some comments to the source code that this is not really how the sysfs gpio interface should be used, but hey it works for the purpose ;) Apr 30 15:35:34 (nah don't worry about it, I'm just a fuss and most code out there that uses the sysfs gpio interface is wrong in my view) Apr 30 15:36:16 also, please please please use braced initialization in C++ Apr 30 15:36:51 i.e. std::ofstream gpio_export{...}; instead of parentheses Apr 30 15:39:41 parentheses for initialization is a historical mistake and suffers some obnoxious ambiguities Apr 30 15:41:52 Alrighty, TIL Apr 30 15:42:02 And how should sysfs be used in your point of view Apr 30 15:44:54 Good Morning everyone, Is their a phone line I can call beaglebone. For company reasons Apr 30 15:52:45 hi guys, anyone knows where can i find a pinout diagram for the beagle blue? the SPI connectors seem to be different from every other board i ever worked with. google yielded no results Apr 30 16:02:35 doubleblue: my pins spreadsheet ( https://goo.gl/Jkcg0w ) has a BBBlue tab that may be of use Apr 30 16:03:11 menu Data -> Filter Views -> By connection can be used to groups the pins by connector Apr 30 16:06:43 bou4: I'd say see https://gist.github.com/mvduin/578509d458da8948ae3a14a81dc639e4#file-sysfs-gpio-h Apr 30 16:07:23 bou4: apart from the unclean error handling it is pretty well-behaved I think Apr 30 16:07:43 zmatt- much obliged, this is exactly what i needed Apr 30 16:08:41 including checking whether direction is already set correctly and not attempting to write it in that case (it may be readonly if gpios are setup in DT), and being careful about the weird behaviour of pins marked as active-low Apr 30 16:09:02 the part my class glosses over is obtaining the path in a good way Apr 30 16:10:58 using fixed gpio numbers is... well, something you can mostly get away with in practice on the beaglebone, but still technically wrong. the kernel assigns those simply in whatever order the gpio controllers are discovered Apr 30 16:11:19 it's easy to imagine situations where that numbering can be messed up, e.g. if you add an spi gpio expander or something like that Apr 30 16:12:30 i thought i'd try using it since i was told it's fairly simple, but so far it certainly doesn't seem to be the case. fortunately i just need to connect 2 devices on SPI, nothing more Apr 30 16:13:18 doubleblue: there are two SPI headers for that purpose Apr 30 16:15:15 doubleblue: see also the schematic, all the headers/connectors are on page 1 Apr 30 16:16:17 i saw the manual on the beagle github, it has just the header list, no pinout of the connectors Apr 30 16:16:32 hence my questions, the SPI connectors on the blue are different from other boards Apr 30 16:16:48 doubleblue: the 6 pins of the spi headers (S1.1 / S1.2) are { gnd, 3.3v, mosi, miso, sck, cs } Apr 30 16:17:02 there is no standardized connector for SPI (as far as I know) Apr 30 16:18:47 the blue uses JST-SH for the SPI connectors (and several others) Apr 30 16:19:04 there are indeed no standardized connectors, usually you get the pinout of each board, i didn't bump into a problem identifying the pins until the blue... but you just solved my problem completely, that is all i needed Apr 30 16:21:19 lol Apr 30 16:21:30 bou4: my approach for gpio is declaring them in DT ( https://pastebin.com/raw/CPiC2CnB ) and then have an udev rule create named symlinks for them ( https://pastebin.com/raw/GseLp62B ), that way applications don't ever need to know or care about gpio numbers Apr 30 16:21:32 it looks like the McASP doesn't need a MCLK to function Apr 30 16:21:47 I told you that earlier Apr 30 16:21:51 that is a very nice approach! Apr 30 16:21:55 that's why I configured it to internal Apr 30 16:22:50 mcasp uses hclk/mclk only to create the bit-clock if it is master Apr 30 16:23:29 But if the codec is configured as master for all the clocks it only needs frame clock and bit clock Apr 30 16:31:36 btw, regarding braces vs parens... https://pastebin.com/VaZuzmuX Especially lines 18 and 23 Apr 30 16:33:17 ("value-initialization" means, basically, call default constructor or zero-fill if it has none) Apr 30 16:40:12 (my descriptions in this overview are, of course, oversimplified here and there :P ) Apr 30 16:58:05 (okay line 4 is just wrong... it's not a cast, but unlike braced initialization it allows narrowing conversions) Apr 30 20:24:55 Just found out about this channel, LOL. Apr 30 20:25:15 congratulations? Apr 30 20:25:29 Greetings, and thank you. Apr 30 20:26:05 Please excuse my awkwardness, sorry about that. Apr 30 20:26:59 I was wondering where all the BeagleBoard/Bone fans/users were. Not in #beaglebone, that's for sure. Apr 30 20:27:44 I am developing a project for SBC and have been prototyping with the Raspberry Pi and am now looking more toward the BBB (as it is fully open). Apr 30 20:28:07 but am now looking more toward the BBB* Apr 30 20:31:21 yup, broadcom is about as open as an oyster covered in epoxy Apr 30 20:31:22 Warning (unit_address_vs_reg): Node /fragment@1 has a unit name, but no reg property Apr 30 20:31:29 Haha, zmatt. Apr 30 20:31:41 bou4: yada yada, just add a flag to suppress the warning Apr 30 20:31:59 aha, okay, I didn't see how to solve that warning Apr 30 20:32:03 The Pi is becoming more open with every release, but it is a bit unnerving still. Apr 30 20:33:33 the SoC is still pretty much undocumented Apr 30 20:33:38 Yup, true. Apr 30 20:33:40 it doesn't even have a product page at broadcom Apr 30 20:33:50 Ah, damn. I see. Apr 30 20:33:52 you can't buy it if you want to Apr 30 20:34:36 I like that the BBB has built in memory as well. Apr 30 20:34:46 none of the rpis have eMMC ? Apr 30 20:34:55 I don't think so, no. Apr 30 20:35:00 well that sucks Apr 30 20:35:23 Yup :) Apr 30 20:35:42 I also like what's going on with the BB Enhanced and stuff like that. Apr 30 20:36:24 Shows that anybody can make their own BB, if SanCloud and SeeedStudio are doing stuff. Apr 30 20:36:37 Mirrors the Arduino, in a way, like with Freeduino and etc. Apr 30 20:37:40 fyi if you're looking for docs on the SoC of the beaglebone, at http://www.ti.com/product/AM3358/technicaldocuments you can find the datasheet, errata, and (under User Guides) the 5000-page technical reference manual Apr 30 20:37:46 yep Apr 30 20:38:07 the design is open, the parts are things you can buy Apr 30 20:40:28 Ah, thanks for the info zmatt. Apr 30 20:40:36 * demt bookmarked it. Apr 30 20:42:09 also, for details about pin usage on the beaglebone black, the BBB tab of my pins spreadsheet give a detailed list while the P9 and P8 tabs give overviews of the expansion headers -> https://goo.gl/Jkcg0w Apr 30 20:42:37 Wow, thanks. Apr 30 20:42:41 Also bookmarked. Apr 30 20:46:04 Also a thing that sucks about the Pi is that the OS (a Debian-based distro called Raspian) is still only compiled for ARMv6. Apr 30 20:46:09 In this day and age. Apr 30 20:46:37 well obviously since the bcm2835 *is* ARMv6 Apr 30 20:47:01 Ah ok. Apr 30 20:47:11 I'm still wanting to work with the latest version of the CPU. Apr 30 20:47:22 the 36 and 37 are ARMv7, but they probably want 1 OS for all three Apr 30 20:47:23 Well I think ARMv8 is the latest. Apr 30 20:47:31 Ah ok, I see. Apr 30 20:47:37 oh right the 37 is v8 even Apr 30 22:55:33 hi - WTF! there are NO BBB rev c's ANYWHERE in the world to buy now!!!??? :((( Apr 30 22:56:11 does anybody know what the deal is??? Apr 30 22:57:06 i mean... i can't find a single place to buy a damned beagle bone black! Apr 30 22:57:17 why? Apr 30 23:19:35 my guess would be lack of patience Apr 30 23:20:28 LOL Apr 30 23:20:47 I see the BeagleBone Wireless is in stock at my usual sites. Apr 30 23:21:01 that's not the same though Apr 30 23:21:03 Well at least one of them. Apr 30 23:21:11 I know. Apr 30 23:21:20 But it's better than nothing (IMO). Apr 30 23:21:43 for most applications they're not interchangable Apr 30 23:21:43 Maybe TI is gearing up to sell those, instead? Apr 30 23:21:52 I see. Apr 30 23:22:36 TI doesn't sell any beaglebone Apr 30 23:22:51 Promote, then. Apr 30 23:23:20 neither Apr 30 23:23:44 anyway, it is a bit odd they're out of stock for the next two months or something Apr 30 23:24:11 My project would actually be better for the wireless version. Apr 30 23:24:19 I'm sorry that meme couldn't get what he wanted. Apr 30 23:25:01 oh wait never mind, they're back in stock in 5 weeks Apr 30 23:25:49 (at element14) Apr 30 23:27:23 Ah cool. Apr 30 23:55:44 I prefer the BBB to the wireless one myself. Apr 30 23:55:54 ditto Apr 30 23:56:07 unfortunately I have B's not C's so it's a bit more cramped in the MMC department Apr 30 23:57:07 we have C's but reconfigure the eMMC into SLC mode, which cuts the capacity by 50% Apr 30 23:57:41 (long-term reliability is more important than space) May 01 00:02:49 hello...I need help enabling the PRU on the bb blue...I can't find anything anywhere May 01 00:03:32 it should be enabled by default I think? May 01 00:04:07 I'm trying to run rc_test_servos and rc_test escs and getting PRU probably not enabled in device tree May 01 00:04:22 which image version? are you booting from eMMC or SD card? May 01 00:04:57 i built an SD card with the latest image and then flashed it to eMMC so running on EMMC right now May 01 00:05:02 checking version now May 01 00:05:44 hm, beagleboard.org seems to be having problems right now May 01 00:06:03 ah just the https May 01 00:07:02 whats the command to see image...can't think right now May 01 00:07:18 uh, you don't have the image around anymore to check the filename? May 01 00:07:26 then cat /etc/dogtag May 01 00:08:31 oh didn't think about that lol May 01 00:08:49 bone-debian-9.3-iot-armhf-2018-03-05-4gb.img May 01 00:09:00 yeah ok that is the right one May 01 00:09:26 in your /boot/uEnv.txt, how is uboot_overlay_pru being set? May 01 00:10:28 uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo May 01 00:10:44 comment that one out, uncomment the PRU-RPROC one May 01 00:11:07 the robotics cape stuff uses remoteproc-pru May 01 00:11:14 not uio-pruss May 01 00:12:07 gotcha can you copy that line i don't think i have it in my uboot May 01 00:12:15 or uEnv.txt May 01 00:13:46 oh i found it May 01 00:14:10 it should be right above it May 01 00:15:24 need to reboot after correct? May 01 00:15:29 yes May 01 00:15:45 ok hang tight. thanks for the help May 01 00:19:54 the red LED is now blinking is that normal? May 01 00:20:28 I have no idea what "the red led" is, but a different led behaviour at startup is definitely not normal May 01 00:21:18 still getting the same error from rc_test_servos. May 01 00:21:31 check kernel log for errors? May 01 00:22:12 is there anything in /sys/class/remoteproc ? May 01 00:23:01 it may be worth updating the kernel and/or overlays May 01 00:23:14 ok i'll check that out May 01 00:23:17 there has been plenty of tinkering with DT-stuff related to pru and/or the blue I think May 01 00:23:34 /opt/scripts/tools/update_kernel.sh iirc May 01 00:24:16 you can also try a testing image from https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Stretch_Snapshot_iot May 01 00:26:05 if using the latest everything still doesn't help, poke me again and I'll see if I can debug it May 01 00:28:07 ok I'll give all that a go thanks a bunch. this is my last step before I finally start flying :) May 01 00:28:11 or trying to May 01 00:45:51 4.4.113-ti-rt-r149 figured i'd mention i'm using this kernel. May 01 00:46:03 uhh what? May 01 00:46:19 the latest image is still using a 4.4 kernel? really? May 01 00:46:19 working with ardupilot/arducopter May 01 00:46:42 if you mean you downgraded from 4.9 to 4.4 then that's probably the cause of your problems May 01 00:46:54 https://gist.github.com/jadonk/6080ca92d6e225eb89d33ad7744e1775 May 01 00:47:07 this is the setup file i used May 01 00:47:26 so i guess i did downgrade as part of that process May 01 00:48:14 oh wow that's a really invasive script May 01 00:48:33 yeah it really is May 01 00:48:58 and the guy that wrote hasn't been much help May 01 00:49:11 but this explicitly configures uio-pruss, which means it's not compatible with the (current version of) the robotics cape stuff May 01 00:49:21 afaict May 01 00:49:27 I'm wondering if I should start over and figure it out myself May 01 00:50:04 and recompile ardupilot for the new kernel May 01 00:53:44 can i down grade the robotics cape stuff? May 01 00:54:27 eh, presumably? if you can identify the "right" version May 01 00:54:59 to be honest it looks like the robotics cape stuff could easily have been designed to support both rproc and uio May 01 00:55:08 ok May 01 00:55:42 ew what the hell, it maps shared memory via /dev/mem May 01 00:56:20 I guess remoteproc doesn't offer any useful mechanism for it or something May 01 00:56:55 it may just be the rc_test_ programs do it one way May 01 00:57:28 well I'm looking at library/src/pru/pru.c so that seems like a pretty integral part of the library May 01 00:57:42 ok May 01 00:59:06 the test programs are just complaining about the remoteproc driver being there. may need a test rpogram that doesn't use remoteproc May 01 00:59:18 ? May 01 01:00:04 you mean "not being there" May 01 01:01:19 ERROR in rc_pru_stop opening remoteproc driver: No such file or directory May 01 01:01:49 and then i get failed to start PRU1 May 01 01:02:47 my suggestion would be to start with a fresh image, and then do the first 9 lines of the script but without the --lts-4_4 on line 4 May 01 01:03:06 ok May 01 01:03:13 I"ll give that a shot May 01 01:03:20 make sure PRU-RPROC is enabled in /boot/uEnv.txt .. I think it's probably default, but check anyway May 01 01:03:33 will do May 01 01:03:55 ah I see now why changing uEnv.txt alone didn't help May 01 01:04:19 the script makes a startup file (/etc/rc.local) that explicitly unbinds the remoteproc driver if it loaded May 01 01:04:32 lines 18-19 May 01 01:07:06 oh yes think if i removed that and then changed uEnv.txt it may help? May 01 01:07:13 maybe May 01 01:07:28 you think a fresh image would be better? May 01 01:07:47 probably safer May 01 01:07:48 probably, but it takes little time to see what happens if you remove the rc.local and reboot May 01 01:07:57 true May 01 01:08:24 I'd still suggest a 4.9 kernel instead of an old 4.4 one May 01 01:08:36 (I'm using 4.14 myself) May 01 01:08:52 yeah i didn't realize it was that old...just call me noob lol May 01 01:13:01 can i manually install the remoteproc driver? May 01 01:13:17 there's nothing to install, it's part of the kernel May 01 01:13:49 alright I'll just start over May 01 01:14:16 still saying it cant open the remoteproc driver May 01 01:15:17 is the kernel module listed in lsmod ? May 01 01:15:29 and maybe check dmesg | grep -i pru May 01 01:15:49 pru_rproc? May 01 01:16:20 so it did get loaded? then probably the probe failed for some reason May 01 01:16:50 dmesg results have error -2 May 01 01:16:52 be sure to use the right version of the PRU-RPROC overlay... there are separate ones for 4.4, 4.9, and 4.14 May 01 01:17:09 uhh I need a bit more context to have any idea what you mean by that May 01 01:17:18 sorry May 01 01:17:29 [ 4.120371] ti-pruss 4a300000.pruss: creating PRU cores and other child platform devices [ 4.120623] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 ! [ 4.129955] irq: no irq domain found for /ocp/pruss@4a300000/intc@4a320000 ! [ 4.193174] remoteproc1: 4a338000.pru1 is available [ 4.193864] remoteproc1: Direct firmware load for am335x-pru1-fw failed with error -2 [ 4.193896] remoteproc1: failed May 01 01:17:33 well that didn't work May 01 01:17:37 please don't paste multiline output in irc May 01 01:17:38 never May 01 01:17:41 sorry May 01 01:17:43 use a paste service like pastebin.com May 01 01:18:07 the firmware load is not a problem May 01 01:18:14 the irq domain errors are May 01 01:18:18 probably May 01 01:18:56 https://pastebin.com/JUDP6D5R May 01 01:20:52 ok i'll just get a fresh image seems everything is pointing to that May 01 01:21:15 thanks again. May 01 01:21:17 dunno, it kinda looks like it's genuinely failing the probe just because it couldn't find firmware files to load... maybe it really behaved like that in 4.4, I dunno May 01 01:21:32 fresh image, or at least update the kernel to 4.9-ti-rt May 01 01:21:52 yes sir. thanks for your patience and help May 01 01:21:58 np May 01 01:52:57 Hello I am a SkillsUSA advisor and my students currently use vex for urban search & rescue contest looking to use a blue board. Can it be controlled by remote control May 01 02:29:00 hey zmatt you still around? May 01 02:30:59 built a new sd card updated kernel and bootloader ran updated everything and still the PRU is not working when i run rc_test_servos May 01 02:33:28 https://pastebin.com/RVBUEtDh May 01 02:33:38 thats the ouput i get May 01 02:34:46 i have uncommented the overlay with PRU_RPROC in uEnv.txt May 01 02:40:03 ok guess i will search the interwebs yet again **** ENDING LOGGING AT Tue May 01 03:00:05 2018