**** BEGIN LOGGING AT Mon Jun 08 02:59:58 2020
Jun 08 06:20:59 <Gia> Morning everyone. Can you advise whether there is an opportunity for a business to become a Beagleboard distributor? what is the process in that case? Regards.
Jun 08 06:23:16 <zmatt> I'm don't think it's likely you'll get a useful answer on that here, this is a technical community chat, not a sales channel
Jun 08 06:24:44 <Gia> thanks zmatt
Jun 08 06:25:06 <Gia> could you advise on what the right channel would be then? I tried to look for a sales contact but with no luck
Jun 08 06:25:41 <zmatt> Gia: http://beagleboard.org/logo#manufacturer
Jun 08 06:25:49 <Gia> fantastic. Thanks.
Jun 08 06:26:08 <Gia> (apologies also, ... it was just there... )
Jun 08 06:26:27 <zmatt> of course "distributor" and "manufacturer" aren't the same thing, but this is the closest I could find
Jun 08 06:27:07 <zmatt> it seems likely that Christi Long is the right person to contact regardless
Jun 08 10:08:51 <Ganesh> Hi
Jun 08 10:09:15 <Ganesh> I have an Beagleboard black
Jun 08 10:09:53 <Ganesh> how i can install python 3.6 in it, because it is having python 3.5
Jun 08 10:10:13 <zmatt> you mean a beaglebone black, there's no "beagleboard black"
Jun 08 10:10:32 <Ganesh> yes right bealebone black
Jun 08 10:10:36 <zmatt> the latest images ship with python 3.7
Jun 08 10:10:59 <Ganesh> so i have to update it with latest image.
Jun 08 10:11:09 <zmatt> well, that's the easiest way
Jun 08 10:11:31 <Ganesh> can you provide me link to update with latest image
Jun 08 10:12:59 <zmatt> https://beagleboard.org/latest-images  if you get the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher" (under "Flasher" Debian images) and write it to sd card (using etcher.io is highly recommended) then boot the beaglebone from it, it will erase and reflash the on-board eMMC with the latest image
Jun 08 10:14:13 <zmatt> (obviously if there's anything of important on the BBB right now, make a backup of that first)
Jun 08 10:14:40 <mru> as a side note, never keep important things there in the first place
Jun 08 10:14:55 <zmatt> not the only copy of important things anyway :)
Jun 08 10:15:18 <mru> right
Jun 08 12:09:08 <Ganesh> Hi
Jun 08 12:09:32 <Ganesh> I have an beagle bone black with python 3.5
Jun 08 12:09:52 <mru> the elephant god is back
Jun 08 12:10:26 <Ganesh> So i have updataed it with latest image. But now it is not providing graphical image
Jun 08 12:10:39 <Ganesh> it is booting in command view
Jun 08 12:10:56 <mru> command it to show graphics :)
Jun 08 12:11:37 <Ganesh> actually i have updated it with following image
Jun 08 12:11:39 <Ganesh> bone-eMMC-flasher-debian-10.3-iot-armhf-2020-04-06-4gb.img.xz
Jun 08 12:13:12 <Ganesh> I think it is without graphical desktop
Jun 08 12:13:35 <Ganesh> but I need update with graphical desktop.
Jun 08 12:14:12 <Ganesh> So please help.
Jun 08 12:17:39 <Ganesh> ??
Jun 08 12:42:16 <mru> aren't gods supposed to be powerful?
Jun 08 13:08:06 <zmatt> I don't understand why beaglebones ship with an lxqt image
Jun 08 13:08:29 <mru> in my opionion they ought not ship with anything at all
Jun 08 13:08:55 <zmatt> agreed, let them download the latest image
Jun 08 13:09:26 <mru> I also think the idea of "the image" is a bad one
Jun 08 13:09:34 <mru> people should be encouraged to build their own system
Jun 08 13:09:38 <mru> or buy an ipad
Jun 08 13:11:16 <zmatt> I don't agree with that
Jun 08 13:12:54 <mru> a minimal reference build is ok
Jun 08 13:14:35 <zmatt> no I think a reasonably comfortable debian system as default image is fine, you want to be able to start with your project, not start with some unnecessary hurdles
Jun 08 13:15:04 <mru> but your project is likely totally different from my project
Jun 08 13:15:21 <mru> and trying to cater to every conceivable project leads to huge complexity and bloat
Jun 08 16:20:14 <TurkeyKittin> Is there a general method to installing cross-compiled binaries on Linux?
Jun 08 16:21:39 <mru> that question is a bit vague
Jun 08 16:27:52 <zmatt> how you compile something generally doesn't affect how you install the result
Jun 08 16:28:28 <TurkeyKittin> I guess I have just been taking install scripts for granted
Jun 08 16:31:05 <zmatt> you can install into a temporary dir (if it uses automake then you can do e.g. "make DESTDIR=/path/to/staging-directory install") and then rsync those files over
Jun 08 16:31:36 <TurkeyKittin> Where would I copy those resulting files to in the target system?
Jun 08 16:31:57 <TurkeyKittin> I was writing a long clarifying message and you hit my question perfectly Zmatt :>
Jun 08 16:32:06 <zmatt> DESTDIR doesn't affect the installation hierarchy, it just prepend a prefix
Jun 08 16:32:52 <TurkeyKittin> So if that DESTDIR produces a bunch of executables and a "lib" directory, I place the contents of lib into /lib/ on the beaglebone?
Jun 08 16:33:01 <TurkeyKittin> instead of /usr/lib/?
Jun 08 16:33:02 <zmatt> so normally you'd have ./configure'd it with --prefix=/usr/local (which is normally the default and hence can be omitted), so if you then compile and install it with DESTDIR=/path/to/staging-directory then the actual files will end up in /path/to/staging-directory/usr/local/
Jun 08 16:33:11 <zmatt> e.g. /path/to/staging-directory/usr/local/lib/  for libraries
Jun 08 16:33:33 <zmatt> so the staging directory, given via DESTDIR, corresponds to the root of the target filesystem
Jun 08 16:34:06 <TurkeyKittin> Got it
Jun 08 16:34:24 <zmatt> so you could then transfer those with e.g.  rsync -rpltOJv /path/to/staging-directory/ root@beaglebone:/
Jun 08 16:35:04 <TurkeyKittin> Oh neat, I hadn't known of rsync. Apparently it's faster than scp :D
Jun 08 16:35:07 <zmatt> may want to verify the sanity of the contents of the staging directory (and/or first try the rsync with --dry-run) to make sure nothing too crazy is going to happen
Jun 08 16:37:04 <zmatt> it's not just faster, it also has a lot of options for more fine control over the details of the transfer
Jun 08 16:37:48 <mru> if I'm installing something without using a package manager, I generally put in a private location not shared with anything else
Jun 08 16:38:01 <mru> avoids collisions and makes removing it trivial
Jun 08 16:38:07 <zmatt> yeah that can be a good option too, and makes cleaning up a lot easier
Jun 08 16:38:18 <mru> I only use /usr/local for single-file things
Jun 08 16:38:54 <mru> not that this invalidates any of what you said
Jun 08 17:55:34 <MattB0ne> Question
Jun 08 17:55:40 <MattB0ne> does a BeagleBone Black
Jun 08 17:55:55 <MattB0ne> come with a capability to read eQEP data
Jun 08 17:56:11 <MattB0ne> trying to connect a motor encoder
Jun 08 17:58:41 <zmatt> eQEP has a linux driver yes.  not a great one, but it should work adequately for many applications
Jun 08 18:00:40 <zmatt> (it is also possible to give userspace direct access to its registers and irq using uio, allowing all of its features to me used, but that's rather a bit more advanced,  my py-uio library has an example for this)
Jun 08 18:00:53 <zmatt> *to be used
Jun 08 18:03:16 <MattB0ne> ok thanks
Jun 08 18:26:58 <MattB0ne> what are my options for eQEP ports? The BBB pin map doesnt show anything
Jun 08 18:27:14 <MattB0ne> supposedly i could do 3 encoders at once
Jun 08 18:35:20 <zmatt> check the P9/P8 overview tabs of my pins spreadsheet: https://goo.gl/Jkcg0w
Jun 08 18:36:38 <zmatt> eqep0 is P9.41+P9.27, eqep1 is P8.35+P8.33 (requires disabling video), eqep2 is P8.12+P8.11
Jun 08 19:26:18 <MattB0ne> is there anyway i can divert the encoder to another pin
Jun 08 19:26:34 <MattB0ne> I do not have P9.27 open because of the LCF
Jun 08 19:26:36 <MattB0ne> LDC
Jun 08 19:26:39 <MattB0ne> LCD
Jun 08 19:26:52 <MattB0ne> dang cape eats 3/4 of the pins
Jun 08 19:27:06 <zmatt> I listed three options, only one of which conflicts with video
Jun 08 19:28:42 <zmatt> there's no alternative pins for eqep1.  if you need another encoder input then using PRU is an option (that's what the bbblue uses for its fourth encoder input)
Jun 08 19:29:40 <MattB0ne> not according to the pin map from the cape
Jun 08 19:29:40 <MattB0ne> maybe because of the touch functionality
Jun 08 19:29:52 <MattB0ne> https://www.newhavendisplay.com/userguides/NHD-7.0CTP-CAPE_User_Guide.pdf
Jun 08 19:31:02 <zmatt> I said "conflicts with video", not "conflicts with the cape you're using"
Jun 08 19:31:27 <zmatt> using a cape, especially one like this, will obviously significantly limit the availability of other pin functions
Jun 08 19:31:44 <MattB0ne> yeah did not appreciate that fact when I bought it
Jun 08 19:31:47 <MattB0ne> live and learn
Jun 08 19:32:19 <MattB0ne> I was thinking that the motor controller would take the encorder info
Jun 08 19:32:21 <MattB0ne> but nope
Jun 08 19:34:05 <zmatt> ah, it has 24-bit color
Jun 08 19:34:56 <zmatt> yeah looks like this cape happens to conflict with every eqep mux option available
Jun 08 19:35:36 <MattB0ne> I have UART2 open
Jun 08 19:35:56 <MattB0ne> maybe I can find a board that has a eQEP
Jun 08 19:36:04 <MattB0ne> and I can read the position and speed serially
Jun 08 19:36:18 <zmatt> but looks like there are still plenty of unused pins, you can probably find two pins on one of the two PRU cores
Jun 08 19:36:32 <zmatt> brb, need to get some stuff from the store
Jun 08 19:36:39 <MattB0ne> ok I will look
Jun 08 19:36:41 <MattB0ne>  thanks for the tip
Jun 08 19:56:08 <thinkfat> anyone know an aluminium case for the bbb with headroom for a cape?
Jun 08 19:56:51 <zmatt> MattB0ne: two consecutive pins (of the same pru) would probably be most convenient
Jun 08 19:57:15 <MattB0ne> ok
Jun 08 19:57:23 <MattB0ne> this really cool I did not know the BBB had these
Jun 08 19:57:32 <zmatt> what? PRU?
Jun 08 19:57:33 <MattB0ne> may need to rethink my design scheme
Jun 08 19:57:36 <MattB0ne> yeah
Jun 08 19:57:47 <MattB0ne> its like a completely separate thing
Jun 08 19:57:53 <zmatt> the PRU cores are the single coolest feature of the BBB
Jun 08 19:58:03 <MattB0ne> i just found that out today
Jun 08 19:58:08 <MattB0ne> :')
Jun 08 19:58:29 <MattB0ne> i just though BBB just had more GPIO than the pi
Jun 08 19:58:35 <MattB0ne> and was more open sourced
Jun 08 19:58:41 <MattB0ne> these PRUs are a game changer
Jun 08 19:58:53 <zmatt> I made a python library that can load code, inspect and manipulate the cores, map shared memory, and setup and receive interrupts: https://github.com/mvduin/py-uio
Jun 08 19:59:01 <zmatt> well, all of those things are _also_ true :)
Jun 08 20:01:55 <zmatt> (actually whether the pins are consecutive or not probably doesn't matter, it doesn't seem to be straightforward to exploit that for a decoder)
Jun 08 20:09:23 <MattB0ne> this is awsome but a lot to take in
Jun 08 20:09:37 <MattB0ne> is this what you would consider programming at bare metal
Jun 08 20:09:54 <MattB0ne> since the PRU isnt running linux
Jun 08 20:10:52 <zmatt> I mean, technically yes but typically one uses the term baremetal to emphasize the absence of an OS, especially when this is unusual, whereas PRU never runs an OS in the first place, it does not have the memory or facilities for one
Jun 08 20:27:42 <zmatt> something like this would be a simple (albeit unelegant) quadrature decoder, assuming I didn't fuck up: https://pastebin.com/raw/X1EwWFww
Jun 08 20:27:51 <zmatt> oh, he left
Jun 08 20:39:38 <GenTooMan> still cool :D
Jun 08 20:39:56 <ayjay_t> glad to see zmatt is still holding down fort over here
Jun 08 20:40:20 <GenTooMan> wait is their a c compiler for the PRU and is it any good?
Jun 08 20:40:30 <zmatt> there is and lol no
Jun 08 20:40:34 <GenTooMan> there even gah I'm english challenged today.
Jun 08 20:41:14 <GenTooMan> hmm OK I was afraid that it wasn't any good. Do they have a "good" assembler that can be used for a backend?
Jun 08 20:41:37 <zmatt> not sure what you mean by that
Jun 08 20:41:59 <zmatt> it has an assembler obviously
Jun 08 20:43:11 <zmatt> http://www.ti.com/lit/ug/spruhv6c/spruhv6c.pdf
Jun 08 20:43:41 <GenTooMan> hmm I'll just have to examine the assembler.
Jun 08 20:43:57 <GenTooMan> thanks as usual.
Jun 08 20:44:26 <zmatt> iirc it was a bit annoying compared to pasm, but I can't remember why
Jun 08 20:50:09 <zmatt> GenTooMan: for an indication of compiler output.. I haven't checked recently whether it has gotten any better, but last time I did some tests it included results like these: https://pastebin.com/raw/h9wgm9x1
Jun 08 20:52:35 <zmatt> (this was at max optimization)
Jun 08 20:59:51 <GenTooMan> I can't guess what they did to get those results. Anything I say will be wrong the output seems disturbingly as bad as the C compiler for the MSP430 was for a while.
Jun 08 21:02:25 <zmatt> basically the a < 0  uses a generic signed 32-bit integer compare (with no specialization for the case of comparing with 0), the second snippet shows two problems: trivial range-analysis would have shown the QBBC is always taken, and they're using 3 instructions (and a temporary registers) to set bit 31 of r0 because it's using a procedure that works for variable shift operand instead of specializing ...
Jun 08 21:02:31 <zmatt> ...for constant shifts
Jun 08 21:03:54 <GenTooMan> the PRU is 32bit correct?
Jun 08 21:03:58 <zmatt> range analysis is particularly important on PRU to realize when a signed int can actually never be negative, since C has a strong tendency to make expressions signed ints and PRU has no support for signed arithmetic or comparisons
Jun 08 21:04:02 <zmatt> yes
Jun 08 21:04:35 <zmatt> (although you can also access 16-bit and 8-bit parts of the registers)
Jun 08 21:11:00 <GenTooMan> Is it possible they are trying to support signed ints in the compiler?
Jun 08 21:11:27 <zmatt> I just checked the latest compiler... the first example generates slightly different but equally slow code, the second example has actually become worse by emitting an extra instruction (albeit in the part that's never executed anyway)
Jun 08 21:11:45 <zmatt> they're not "trying", signed ints are not optional in C :P
Jun 08 21:12:14 <zmatt> the pru instruction set was just really never designed to be targeted by a C compiler
Jun 08 21:12:26 <GenTooMan> then "bool lt0( int a ) {  return a < 0;  }" should throw an error no?
Jun 08 21:12:32 <zmatt> no ?
Jun 08 21:12:52 <GenTooMan> as in yes it should throw up if it doesn't support signed integers.
Jun 08 21:13:05 <zmatt> you cannot not support signed integers in C
Jun 08 21:13:30 <zmatt> (uint16_t)42 + (uint16_t)1   is a signed integer
Jun 08 21:26:59 <Himateja> Does Beagleboard provide the BLE stack
Jun 08 21:36:45 <Janos> hi, quick question, trying to update my BBBvA5B firmware to the lates debian 10 version, but flasher script is failing, looks like the problem might be that my version does not have enough eMMC space, is there a debian 10 image that would fit my BBB ?
Jun 08 21:37:35 <Janos> BBBvC has 4G storage but looks like mine has only 2G
Jun 08 21:37:59 <zmatt> Janos: there are minimalistic console images
Jun 08 21:38:05 <Ragnorok> GenTooMan: I used a C compiler to do my PRU code.  Worked a treat.
Jun 08 21:38:21 <zmatt> https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console
Jun 08 21:38:53 <Himateja> where do i get the BLE stack for beaglebone wirless OSD335x
Jun 08 21:39:11 <Janos> @zmatt wonderful, will try thta
Jun 08 21:39:20 <zmatt> Janos: if you're comfortable installing stuff you want it's the best option
Jun 08 21:39:46 <zmatt> Himateja: the standard bluetooth stack on linux is bluez
Jun 08 21:39:49 <Janos> yup, that works best for me
Jun 08 21:40:54 <Janos> is there any doc on what extras come with IoT image ? just curious
Jun 08 21:43:57 <thinkfat> node red and cloud9
Jun 08 21:44:57 <zmatt> Janos: here's the list of all packages installed on the iot image: https://pastebin.com/raw/qbEgfNY8
Jun 08 21:45:37 <Janos> thanks, will diff once I have the console image running and check it out
Jun 08 23:11:03 <jkridner> zmatt: yeah, the fan cape schematic is missing. let me see if I can find something suitable to push.
Jun 08 23:11:32 <jkridner> zmatt: most likely scenario is we are going to redesign it anyway, if there is any input on it.
Jun 08 23:11:53 <jkridner> zmatt: not sure if you looked over the BBAI rev A2 updates either.
Jun 09 01:27:48 <MattB0ne> anyone here use code composer?
Jun 09 01:30:21 <GenTooMan> I do sometimes.. however I've never used it for the AM3358 or the PRU.
Jun 09 01:53:35 <GenTooMan> I might be able to answer a question or two.
Jun 09 01:53:43 <GenTooMan> not even here... sigh
Jun 09 02:08:47 <set_> There is always me?
Jun 09 02:37:23 <set_> Me!
**** ENDING LOGGING AT Tue Jun 09 02:59:57 2020