**** BEGIN LOGGING AT Sun Mar 10 02:59:56 2019 Mar 10 03:04:39 Is anyone using MATLAB w/ the BeagleBone? Mar 10 03:11:49 Anthony_: did you actually read my answer regarding spi, or do you just ask questions and then leave? Mar 10 03:12:54 I did not see it unfortunately. Mar 10 03:12:57 Inactivity. Mar 10 03:13:23 Apologies. Mar 10 03:13:30 you were still connected to IRC for at least 10 minutes after I answered your questions Mar 10 03:14:06 https://pastebin.com/raw/c1zE5n1H Mar 10 03:14:55 if the web interface gateway makes you lose scrollback after some inactivity timeout (I've never tried it), maybe consider getting a better irc client Mar 10 03:15:16 Great information. Mar 10 03:15:24 Let me try out the show pins program Mar 10 03:16:38 zmatt, as a secondary question. Have you ever used MATLAB to interface with the Beaglebone? Mar 10 03:16:55 I don't even know what that means, even though I do have (an old version of) MATLAB Mar 10 03:17:45 Gotcha, MATLAB has a built in library for BeagleBone, which allows you to interface it similarly as you would with the Arduino IDE Mar 10 03:17:52 with an Arduino + Arduino IDE* Mar 10 03:18:14 I've never used the arduino IDE Mar 10 03:20:14 anyway, asking "is/does/has anyone ....?" questions is generally not very fruitful, since the answer "yes, probably someone has" is not useful to you. I recommend actually asking technical questions. although when asking questions about obscure topics, you may want to get a better irc client first since it can easily take hours to get a reaction from someone who might be able to help you Mar 10 03:25:55 (and anything involving MATLAB is an obscure question, since it is very expensive software. that's why they try to get people hooked on it by giving it for (basically) free to students) Mar 10 15:01:59 I have a BeagleBone Black Wireless, I'd like to flash it w/ Debian version 7.X, on: https://beagleboard.org/latest-images it shows wireless only having support for 8.5+, will it be an issue if I flash my board w/ a 7.X? Mar 10 15:05:40 only if you want to use WiFi :) Mar 10 15:55:28 zmatt: i was trying to have the same distro and kernel on both the emmc and sdcard Mar 10 15:55:43 i gave up i'm just running debian 9/4.19 Mar 10 15:57:14 sorry 9 and 4.14 Mar 10 15:58:00 Hello? Mar 10 15:58:35 I need help Mar 10 15:59:28 Please? Mar 10 16:04:23 Hi Mar 10 16:04:41 just explain the problem you hare having KO_ Mar 10 16:05:39 Thank you I posted a question, but I can't see what I wrote. Mar 10 16:06:13 in the BeagleBoard group Mar 10 16:06:21 link? Mar 10 16:06:25 in PRU section.. Mar 10 16:06:33 https://groups.google.com/forum/#!categories/beagleboard/pru Mar 10 16:07:02 this was today you posted? Mar 10 16:07:06 i see nothing new in there Mar 10 16:07:20 hmmn Mar 10 16:07:25 can you help me with PRU? Mar 10 16:07:40 no .. i'm a noob with regard to the PRU Mar 10 16:08:16 It's simple.. I just wanted to power on the PRU, but it does not start. Mar 10 16:08:45 i would search for that in google if it were me Mar 10 16:08:45 echo 'start' > state Mar 10 16:09:30 root@beaglebone:/sys/class/remoteproc/remoteproc1# echo 'start' > state Mar 10 16:09:43 -bash: echo: write error: No such file or directory Mar 10 16:10:00 I searched but there seem not to be ... Mar 10 16:10:36 seems to be available on my kernel Mar 10 16:11:08 sounds like a distro/kernel/ dts problem Mar 10 16:11:19 have you looked at the journal for isses Mar 10 16:11:21 issues Mar 10 16:11:23 can you echo 'start'? Mar 10 16:11:57 i don't have any code setup to run pru stuff Mar 10 16:12:18 oh no. you just cd /sys/class/remoteproc/remoteproc1 Mar 10 16:12:33 and then echo 'start' > state Mar 10 16:12:59 Anyway I'm foreign student. So I have trouble finding related issue.. Mar 10 16:14:41 Where can I see the list of what I wrote in the group? Mar 10 16:43:43 My BeagleBoard is unrecognized on my computer, it's labeled as "CDC Serial", OS: Windows 7 x64. Any idea what's going on? Mar 10 16:48:36 Fixed it. Mar 10 17:55:05 Are there any Debian V7 that works w/ BeagleBone Black Wireless? Mar 10 17:56:21 that sounds super ancient Mar 10 17:57:08 Reason why is Debian 8+ root access is disabled, and so I need a version 7 so I don't need to allocate tty (requiretty) Mar 10 17:57:37 there should be no reason for needing explicit login as root Mar 10 17:58:32 I'm not using a shell/interface Mar 10 17:58:57 So I'm directly sending command via ssh: (e.g. ssh root@192.168.7.2 sudo su) Mar 10 17:59:23 On the grand scope, I'm trying to connect BBB to MATLAB, which requires that interface Mar 10 17:59:58 I somewhat doubt that matlab is *that* stupid to require ssh login as root Mar 10 18:00:19 but if you *really* want to, you can just reenable all the insecure functionality Mar 10 18:00:44 I'm just surprised that the Debian 7.X versions won't flash on my BBB Wireless Mar 10 18:01:12 that's like a million years old, probably predating the BBB-wireless Mar 10 18:01:21 I believe it's not on MATLAB's end, it's the configuration of Debian after 7.X Mar 10 18:01:23 we're at debian 9.5 Mar 10 18:02:24 I'd suspect you're trying to follow some sort of ancient howto that simply doesn't apply Mar 10 18:02:25 Because I keep getting a: "no tty present and no askpass program" Mar 10 18:02:34 which is on the domain on Linux Mar 10 18:02:50 that sounds like a problem on your computer not the BBB Mar 10 18:03:56 it's trying to request a login password, but can't, because you don't have anything for that installed. Mar 10 18:04:14 I'd recommend to use public key based ssh authentication anyway Mar 10 18:04:43 Does that disable the need for a passpharse upon ssh login? Mar 10 18:04:56 yes Mar 10 18:06:02 Interesting. Let me look into that and learn how to configure that Mar 10 19:14:06 CONFIG_EXTRA_FIRMWARE ... am335x-pm-firmware.elf is this meant for the new AI board? Mar 10 19:14:29 seems to be related to the cortex-m3 thing that isn't on my BBB A5A Mar 10 19:16:00 so which image would be the best to be able to use an BBB A5A with a external sd card to be able to make the PRU_gpioToggle example work without flogging myself? Mar 10 19:51:49 Rickta59: am335x-pm-firmware.elf is the power management firmware for the am335x and is relevant for every am335x-based board Mar 10 19:52:11 the beaglebone AI uses an am5729, not an am335x Mar 10 19:53:20 Rickta59: if you're booting from external sd card there's no relevant difference between the BBB rev A5A and rev C Mar 10 19:54:10 so you can use the latest stretch-iot image, or the latest stretch-console image if you want a leaner system that you can also flash to eMMC Mar 10 19:56:25 it looks like PRU_gpioToggle is not am335x-compatible, that's why it's in "old_example" Mar 10 20:00:22 in general, the examples included in the old am335x_pru_package are pretty crap. if you want examples that actually work, see my py-uio library :P or presumably the new remoteproc-pru stuff, but haven't looked at that yet myself Mar 10 21:59:58 i got it working zmatt Mar 10 22:00:40 part of my problem .. was not looking at the pin header # Mar 10 22:00:45 1 != 45 Mar 10 22:00:58 can confirm, 1 is not 45 Mar 10 22:01:00 then i found a deploy.sh Mar 10 22:01:05 which sort of worked Mar 10 22:01:18 i was using remoteproc1 .. Mar 10 22:01:21 that didn't work Mar 10 22:01:28 when i changed it to remoteproc2 that did Mar 10 22:01:50 ah you're using remoteproc-pru Mar 10 22:01:59 isn't that the "new" way? Mar 10 22:02:00 yeah there are two remoteproc instances, one for the wakeup-m3, one for pruss Mar 10 22:02:11 but i don't have a wakeup-m3 right? Mar 10 22:02:16 * this is a BBB A5A Mar 10 22:02:19 both uio-pruss and remoteproc-pru are supported, you can switch between them by editing /boot/uEnv.txt Mar 10 22:02:28 the wakeup-m3 is part of the AM335x SoC Mar 10 22:02:30 which is the best way? Mar 10 22:03:12 the only difference between BBB rev A5A and rev C of end-user relevance is the eMMC size Mar 10 22:03:14 isn't remote proc referencesing pru0 and pru1? Mar 10 22:03:25 ok i thought i had a different chip Mar 10 22:03:32 59 vs 58 Mar 10 22:03:33 XM vs AM Mar 10 22:04:16 so is the best i'm going to be able to bitbang 20MHz? Mar 10 22:04:17 AM3359 was used in some early beaglebones because the AM3358 wasn't available yet. the additional features of the AM3359 are not useful however Mar 10 22:04:57 is it XAM3359BZCZ or XAM3359AZCZ ? Mar 10 22:05:13 * get out flash light and magnifier Mar 10 22:05:25 silicon revision 2.0 (A) vs 2.1 (B) might still matter for some things, I'd need to check the errata for the differences Mar 10 22:05:27 59AZ Mar 10 22:05:50 but I think for most practical purposes, you'll probably never notice the difference Mar 10 22:06:10 pru can bitbang a lot faster than 20 MHz Mar 10 22:06:19 so the code ... LBBO, XOR, JMP .. that is 5ns * 4? Mar 10 22:06:55 in a loop Mar 10 22:07:15 jmp is 2 cycles? Mar 10 22:07:32 xor and jmp are single-cycle. lbbo is highly dependent on what you're loading from, but it's 3 cycles at minimum Mar 10 22:08:09 k Mar 10 22:08:28 i'm just looking at what the c code generated Mar 10 22:08:47 i wanted to just know if i had the pru stuff setup to work Mar 10 22:08:50 the C compiler is pretty crap. if you want tight timing, assembly is recommended Mar 10 22:08:52 i can look at your stuff now Mar 10 22:09:34 so are the dmesgs about certain thing innocuous? Mar 10 22:09:41 timer_probe: no matching timers found Mar 10 22:09:51 wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle Mar 10 22:09:54 a nice example of the I/O capabilities of PRU is the BeagleLogic project, which uses pru to turn the beaglebone into a 100 Msps 14-channel logic analyzer Mar 10 22:10:08 that is where i found the deploy.sh Mar 10 22:10:21 beaglebone kernel: omap_voltage_late_init: Voltage driver support not added Mar 10 22:10:23 uhh, what does it do? Mar 10 22:10:30 yeah most of those kernel messages are completely harmless Mar 10 22:10:46 https://raw.githubusercontent.com/ZeekHuge/BeagleScope/port_to_4.4.12-ti-r31%2B/examples/firmware_exmples/pru_blinky/deploy.sh Mar 10 22:10:49 the m3 error is probably an ordering issue, resorting in a probe-defer and later success Mar 10 22:10:58 i thought i had the wrong kernel stuff Mar 10 22:11:08 as it seemed to be trying to use stuff that isn't on my chip Mar 10 22:11:17 nah Mar 10 22:11:19 Anyone who knows or can lead me to where I can find the specifications on the hardware encoder in the BB blue? I am looking for min. step time. (or max pulses per second) Mar 10 22:11:51 so remoteproc isn't a good way to do things? Mar 10 22:11:59 Nila: for the first three encoders (which use eQEP instances) you should find it in the AM3358 datasheet Mar 10 22:12:03 wrt that deploy.sh .. the unbind fails Mar 10 22:12:08 and bind Mar 10 22:12:26 i replace them with rmmod pru_rpoc and modprobe pru_rpoc Mar 10 22:12:59 so the remoteproc2 is really both prus? Mar 10 22:13:30 and the firmware name is what determines which pru is run? Mar 10 22:13:32 Rickta59: you can use whichever you want. uio-pruss offers more functionality and is supported with a stable API across kernel versions ranging from 3.x to the latest 4.19 Mar 10 22:13:58 remoteproc-pru is newer, but I've heard it still keeps changing API in pretty much every kernel version Mar 10 22:14:10 and it has less functionality Mar 10 22:14:38 i tried to limit my google searches on this pru stuff to the last year Mar 10 22:14:53 but not all suggestions worked or were helpful Mar 10 22:15:07 zmatt: I have/am looking in it, but cannot seem to find it Mar 10 22:15:25 a big disadvantage of uio-pruss is that the libprussdrv userspace library sucks. it also can't load ELF executable produced by clpru. my py-uio python library however can load both raw binaries produced by pasm and ELF executables produced by clpru Mar 10 22:15:44 clpru can compile .s files? Mar 10 22:15:51 or whatever pru asm is called? Mar 10 22:16:20 heh .. i figured after waiting 6 years all this stuff would be settled :) Mar 10 22:16:29 Rickta59: clpru can compile assembly files of course. I don't think it's fully compatible with pasm though Mar 10 22:16:58 * dislikes being a pioneer with arrows in my back Mar 10 22:17:21 that's probably why plenty of people just ignore remoteproc-pru and stick with uio-pruss :) Mar 10 22:17:56 Nila: hmm Mar 10 22:18:14 i watched a pru remoteproc video from 2015 at a linux conference Mar 10 22:18:21 i figured ok .. must be safe by now Mar 10 22:18:43 arg .. * goes back into his cave to reemrge in another 5 years Mar 10 22:18:56 Nila: hmm, I don't see it either. well, I think 50 million steps per second should be no problem Mar 10 22:19:17 debugger ... what is the best way to do that? Mar 10 22:19:29 Rickta59: like I said, uio-pruss has been stable since forever, and will continue to be supported for a long time Mar 10 22:19:30 heh .. i did try out the sysfs step thing Mar 10 22:19:55 no gdb for pru ? Mar 10 22:20:00 or gdb like thing Mar 10 22:20:23 there is a pru debugger iirc, google "prudebug" Mar 10 22:20:55 perfect thanks Mar 10 22:22:12 py-uio also includes an example showing how the core can be inspected and single-stepped programmatically, but it's not a full-fledged debugger, it just single-steps through the program and prints the instruction and modified registers Mar 10 22:22:37 https://github.com/mvduin/py-uio/blob/master/pru-examples/debugging.py Mar 10 22:23:12 so i just realized .. only 8k for instructions? Mar 10 22:23:18 thanks i'll look at that Mar 10 22:23:27 yep, 2048 instructions worth Mar 10 22:23:56 zmatt: thanks, I guess that is plenty, just wanted to check that there was not other limitations in that subsystem Mar 10 22:23:56 i guess people don't find that to be a problem? Mar 10 22:24:34 Rickta59: not usually no, especially if you use assembly instead of C Mar 10 22:25:04 do you have a recommendation for PRU code driving a ws2812b led strip? Mar 10 22:25:21 there's an existing pru project for that Mar 10 22:25:47 https://markayoder.github.io/PRUCookbook/01case/case.html#_neopixels_5050_rgb_leds_with_integrated_drivers_ledscape Mar 10 22:25:51 i found a couple early in the day but I was still just trying to grok pru Mar 10 22:26:15 it can drive 48 ws2812(-compatible) LED strings Mar 10 22:27:05 thanks Mar 10 22:27:17 looks like it might need some updating though Mar 10 22:28:40 heh .. the whole delay_cycle thing .. just goes against everything i've been doing Mar 10 22:28:50 what do you mean> Mar 10 22:28:51 ? Mar 10 22:29:04 every other mcu tellsyou to use timers and not delay_cycle Mar 10 22:29:15 use the peripherals luke Mar 10 22:29:25 pru is designed to have deterministic timing (apart from load/store instructions) Mar 10 22:29:36 here the key to success is the fact that you have a nice isa Mar 10 22:29:41 yep Mar 10 22:29:58 can you do inline asm in the clpru c code? Mar 10 22:30:09 it's also very much designed to be written by humans, it was never designed to be targeted by a C compiler (which is part of why clpru produces such bad output) Mar 10 22:31:00 uhh, I guess, but why would you? what would you still need to do in C ? Mar 10 22:31:18 just wondering Mar 10 22:31:46 you can also use an assembly source file and a C source file and link them together of course Mar 10 22:32:17 so is using uio vs remoteproc a either or situation? Mar 10 22:32:55 yes, they are two different drivers for the same subsystem. you pick one by uncommenting the appropriate line in /boot/uEnv.txt Mar 10 22:33:16 so to use your stuff i have to turn off all the remoteproc stuff Mar 10 22:34:01 in /boot/uEnv.txt you find a few options for uboot_overlay_pru= Mar 10 22:34:19 exactly one should be uncommented Mar 10 22:34:22 for py-uio that would be uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo Mar 10 22:34:35 thanks you have been very helpful ... :) Mar 10 22:34:44 (that's also in the py-uio README) Mar 10 22:34:57 i'm going to stop now and let the 20MHz toggle overnight Mar 10 22:35:15 tomorrow i start over with py-uio Mar 10 22:35:29 odd that the PRU cookbook links to some random fork of LEDscape rather than the main repo, https://github.com/osresearch/LEDscape Mar 10 22:36:32 i found out a long time ago to forget about getting the real deal from TI docs Mar 10 22:36:33 https://github.com/osresearch/LEDscape/blob/master/src/ledscape/ws281x.p the actual pru firmware Mar 10 22:36:46 TI docs are usually quite good Mar 10 22:37:01 at least in comparison to what I've seen of other SoCs Mar 10 22:37:03 i mean thier links to them Mar 10 22:37:11 once you find the right doc, yes they are great Mar 10 22:37:21 none of this is from TI though Mar 10 22:37:22 but their web site the links are usually bogus Mar 10 22:37:26 k Mar 10 22:37:56 i just carry around a huge grain of salt doing anything with ti Mar 10 22:38:57 ok .. using an immediate got my c bitbang to 50MHz Mar 10 22:39:19 when coding in C, expect performance to vary wildly based on very minor changes to your code Mar 10 22:39:26 sure Mar 10 22:39:27 if you need specific timing, use asm Mar 10 22:39:33 i' Mar 10 22:39:49 ve spent a lot of time looking at objdump -S Mar 10 22:40:07 objdump supports pru? Mar 10 22:40:17 i mean on other chips Mar 10 22:40:19 ah Mar 10 22:40:35 for clpru you'd use dispru, or add a flag to keep the compiler's assembly output Mar 10 22:40:39 -k iirc Mar 10 22:41:02 or better yet, instead of trying to massage the C compiler into producing the assembly code you want... just use assembly in the first place ;P Mar 10 22:41:03 thanks i found the flag but not the disassember Mar 10 22:42:38 dispru is much better the ti c interlisting is so ugly Mar 10 22:42:40 thanks Mar 10 22:43:02 I think you can disable the C interlisting Mar 10 22:43:13 i turned it on to see what it was generating Mar 10 22:43:19 it isn't on by default Mar 10 22:43:26 --symdebug:none also makes the assembly a lot more readable Mar 10 22:44:01 on the linker? or compiler? Mar 10 22:44:14 compiler of course, the linker doesn't produce assembly output Mar 10 22:44:47 215 .dwattr $C$DW$11, DW_AT_type(*$C$DW$T$11) Mar 10 22:44:48 216 .dwattr $C$DW$11, DW_AT_name("PRU0_GPI_MODE") Mar 10 22:44:48 217 .dwattr $C$DW$11, DW_AT_TI_symbol_name("PRU0_GPI_MODE") Mar 10 22:44:52 i get miles of that Mar 10 22:44:59 yeah, that crap is removed by --symdebug:none Mar 10 22:45:09 just tried that still there Mar 10 22:45:19 they're DWARF debug information Mar 10 22:45:25 typo .. none .. node Mar 10 22:45:48 much better thanks .. **** ENDING LOGGING AT Mon Mar 11 02:59:57 2019