**** BEGIN LOGGING AT Sat Sep 15 03:00:26 2018 Sep 15 10:14:47 I'm trying to compile beaglelogic kernel module but it fails: https://pastebin.ubuntu.com/p/pNk9ScQFXX/ Sep 15 10:18:13 looks like the remoteproc-pru api is not remotely compatible with what this module is expecting Sep 15 10:18:37 I find this sentence at the top of the file concerning: "Designed to be used in conjunction with a modified pru_rproc driver" Sep 15 10:20:25 but yeah, the API has evidently changed between 4.9-ti and 4.14-ti Sep 15 10:20:42 also docs says about kernel 4.9, so 4.14 may be not supported... Thanks zmatt, I'll look at that. What file did you mean Sep 15 10:20:47 Ah I see Sep 15 10:21:01 the beaglelogic driver file Sep 15 10:21:09 so probably I shall downgrade to kernel 4.9 Sep 15 10:22:34 yes it looks like the remoteproc-pru API in 4.9-ti and 4.14-ti are totally incompatible Sep 15 10:22:37 compare: Sep 15 10:22:41 https://github.com/beagleboard/linux/blob/4.9/include/linux/pruss.h#L84-L98 Sep 15 10:22:45 https://github.com/beagleboard/linux/blob/4.14/include/linux/pruss.h#L168-L184 Sep 15 10:23:39 yes I agree, kernel 4.14 is just not supported by beaglelogic. I'll check if they have a branch in repo for 4.14 Sep 15 10:24:03 the changes may be straightforward Sep 15 10:24:38 the pruss_get/pruss_rproc_get calls seem to have the biggest difference Sep 15 10:25:19 looks like 4.9 expects you to first use pruss_get on the device to get a struct pruss * and then pruss_rproc_get to get a struct rproc * Sep 15 10:25:56 while 4.14 expects you to use pru_rproc_get to get a struct rproc * and then pruss_get to get a struct pruss * Sep 15 10:26:07 that's the impression I get from a quick glance anyway Sep 15 10:26:57 thanks Sep 15 10:29:34 the DT declarations have changed too; Sep 15 10:29:36 https://github.com/beagleboard/linux/blob/4.9/drivers/remoteproc/pruss.c#L80 Sep 15 10:29:43 https://github.com/beagleboard/linux/blob/4.14/drivers/remoteproc/pru_rproc.c#L161 Sep 15 10:32:54 I'll try to build with kernel 4.9 first. Porting to 4.14 is another issue Sep 15 11:16:10 zmatt: yeah, compiles against 4.9 just fine Sep 15 15:02:33 hey guys, are there any platforms or frameworks that laydown the groundwork for an API or UI based webapp? Sep 15 15:09:00 I'm sure there are many web-app frameworks, what does this have to do with a beaglebone though? Sep 15 15:09:47 trying to think of the best terms Sep 15 15:10:27 but, it seems like you could create a framework that linked the backend (hardware to API) and front end (API to component) in a generic way Sep 15 15:10:57 lot of "leg work" in that, that im guessing would be pretty reusable Sep 15 15:11:17 there's the whole cloud9 thing if you want quick fun Sep 15 15:11:51 i was thinking of node-red as well Sep 15 15:11:59 yeah those sort of stop short Sep 15 15:12:25 rather than it being a "here is a UI to code with to make pretty apps faster" those are more like "we took away the hard stuff so you can play" Sep 15 15:12:34 as in, they dont make for a very pretty final product :) Sep 15 15:12:54 node-red that is, cloud9 is just an IDE isnt it? Sep 15 15:13:09 afaik, yes Sep 15 15:13:17 i don't use either of them Sep 15 15:13:27 because for a product it's going to be fairly custom anyway and then you can plug it into about any web thing Sep 15 15:13:45 i kinda of disagree with that :) Sep 15 15:14:03 i mean the 'platform' would lock you in to a web framework (lets say react) Sep 15 15:14:28 but it would be fairly easy to make "libraries" or "plugins" to the framework that were an API compoent and a UI component Sep 15 15:15:08 so you could say hey i have DHT11 its on Pin P8_13, and i want it called temp1 Sep 15 15:15:17 I don't think "echo 1 > /sys/foo/bar/baz/gpio/gpiox/value" needs a sophisticated framework Sep 15 15:15:33 i guess more so the goal is to make the UI part (dashboard) easier Sep 15 15:16:19 im more concerned about the communication Sep 15 15:16:37 and a DHT11 is super ugly… I'd much rather hook up a AM2320. just saying Sep 15 15:16:42 it would also stand to reason if you used my method, that you could link multiple BBB to a single UI Sep 15 15:16:49 it was just the first component that came to mind Sep 15 15:17:39 at this level it kinda sounds like an IBM-universal-business-adapter though Sep 15 15:17:56 name sounds about right :) Sep 15 15:18:08 https://www.youtube.com/watch?v=AIOqOxI0K_I Sep 15 15:18:25 already got it :) Sep 15 15:18:43 man i havent seen this in YEARS... it might have been the 90s or early 2k lol Sep 15 15:19:09 I mean it certainly sounds *nice*, just not sure if it has enough aplicability for anyone to go and spend time writing it Sep 15 15:19:28 clearly not since its not out there :) Sep 15 15:19:48 in that sense node-red is probably fairly close though Sep 15 15:20:03 might need some more magic where bit-banging is involved Sep 15 15:20:49 the problem with node red is its too limited, its a gui for creation, i want to make the creation of a gui faster/easier Sep 15 15:22:30 might need a layer on top of that Sep 15 15:22:42 in part its because for 2 years now i've attempted to 'get up to speed' on node related stuff, even just looking at React, it seems impossible to get over the initial hump... i have yet to see a base package that doesnt have like 1000 different node modules.. even just picking a state manager is debated Sep 15 15:22:50 which might exist, but outside the hw-specific space Sep 15 15:23:19 getting from the quickstart "dont actually do this in production" to something that is production sound, seems almost impossible Sep 15 15:27:21 maybe some day someone will... thanks for the input guys :) Sep 15 20:46:25 how can I know the stdin buffer size (in the BBB)? Sep 15 20:47:08 uhh, that's not a BBB question and I'm not even sure what you mean specifically Sep 15 20:48:21 do you mean the max amount of data buffered in the kernel on a tty? or in a pipe? or do you mean how much data might be buffered in userspace when using stdio.h ? Sep 15 20:49:15 when I pipe data from one program to another... |-style Sep 15 20:50:34 man 7 pipe Sep 15 20:56:05 thanks Sep 16 00:51:57 Has anyone had a time testing their MotorCape yet? Sep 16 00:53:22 I am asking b/c I do not know which library to use w/ it so far. Am I "allowed" to use Adafruit_BBIO or another library/module? Sep 16 00:54:03 whatever you want. it's just a few gpios and pwm outputs Sep 16 00:54:13 Oh? Sep 16 00:54:36 I think I may be addressing this config. incorrectly. Sep 16 00:54:55 one pastebin coming up for anyone to view for their pleasure. Sep 16 00:56:23 Hey sir, you said a "few gpios." I have one so far that I am using. Should I use more than one for each motor connection? Sep 16 00:56:56 I'm a bit confused by the overlay though, for some reason it's declaring gpio-controlled leds rather than gpios Sep 16 00:57:19 no I'm seeing exactly one gpio per motor Sep 16 00:57:30 which, combined, is "a few gpios" Sep 16 00:57:48 Oh. Sep 16 00:58:16 For instance, m2- and m2+ is one gpio, right? Sep 16 00:58:33 what? Sep 16 00:58:48 Um... Sep 16 00:58:55 I looked through the schematic. Sep 16 00:58:59 I think you're now talking about the motor outputs, not about gpios Sep 16 00:59:17 Yes. I am discussing the motor outputs. Sorry. Sep 16 01:00:00 I thought, as usual, we were on the same page but my lack of language in this dept. is evident. You know this, man. Sep 16 01:00:07 ... Sep 16 01:00:37 So, I typed up some software and used some motor output w/ that software w/ power source (battery). Sep 16 01:01:22 The software worked but did not turn a motor. Sep 16 01:01:23 ... Sep 16 01:01:50 I am using a GPIO and PWM software example I just concocted. Sep 16 01:02:04 jkridner: why on earth is the overlay for the motor cape declaring the motor direction gpios to be *leds* ? o.O Sep 16 01:02:16 Ut oh? Sep 16 01:02:45 zmatt: Where are you looking? Sep 16 01:02:54 the overlay for the motor cape Sep 16 01:03:00 Oh. Sep 16 01:03:05 Where is that located? Sep 16 01:03:21 I found the .pdf of the schematic only and a .brd file. Sep 16 01:03:23 https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BBORG_MOTOR-00A2.dts Sep 16 01:03:29 Oh. Sep 16 01:03:32 Thank you. Sep 16 01:03:58 Okay. Sep 16 01:04:06 I got what I was doing vs. what needed to be done. Sep 16 01:04:20 I was using some already used up pins to set some ideas in motion. Sep 16 01:04:45 ex. P9_14 and _16 are already used. Sep 16 01:05:11 jkridner: declaring them like this prevents them from being controlled normally via the sysfs gpio interface Sep 16 01:05:49 Oh. Sep 16 01:06:07 I think they are disabled by default and I cannot change them. I got it now! Sep 16 01:07:24 set_: my suggestion would be to remove /lib/firmware/BBORG_MOTOR-00A2.dtbo and just manually configure the pins using config-pin instead Sep 16 01:08:07 Oh. I think you may be right. I tried w/ that libgpiod software usage from GitHub.com and I could not manually set things on and off. Sep 16 01:08:26 So... Sep 16 01:08:27 don't use libgpiod Sep 16 01:09:21 Okay. Sep 16 01:09:53 So... Sep 16 01:10:09 I am thinking I should disable the motors first due to what I am reading from the overlay. Sep 16 01:10:26 Then, make headway w/ movement further down in the software. Sep 16 01:10:55 I have no idea what you mean by that Sep 16 01:11:10 but like I just said, I suggest removing the overlay Sep 16 01:11:22 since in its current form it will just make it difficult to use the cape Sep 16 01:11:46 Right. But...I would like to learn something new! Sep 16 01:12:14 instead just configure the pwm pins to pwm mode using: Sep 16 01:12:15 for pin in P9_16 P9_14 P8_13 P8_19; do config-pin $pin pwm; done Sep 16 01:12:44 (or use whatever way to configure the pins you prefer) Sep 16 01:12:48 I understand. Sep 16 01:13:12 I am not against config-pin. It is very useful to set up communication via userspace. Sep 16 01:14:07 At first, b/c of the "thermal pads," I figured I would have to write a class to work w/ python and call it into my example. Sep 16 01:14:35 at this point I'm not even going to try to understand what you're saying Sep 16 01:14:40 Okay. Sep 16 01:14:41 Fine. Sep 16 01:14:47 Hold on. Sep 16 01:14:53 I want to show you something. Sep 16 01:16:13 It is the schematic. Sep 16 01:16:24 I've seen the schematic Sep 16 01:16:29 Oh. Sep 16 01:16:46 Okay. Sep 16 01:17:24 zmatt on #beagle laying down the law Sep 16 01:17:30 Right. Sep 16 01:17:36 oh that's weird, the motor driver ICs aren't labeled with a part number Sep 16 01:17:39 lol what? Sep 16 01:17:50 I told you this yesterday. Thermal Pads. Sep 16 01:18:07 "thermal pad" is just the label of the pin on the bottom (connected to GND) Sep 16 01:18:11 Hence, my joke about the magnifying glass having to be large. Sep 16 01:18:39 the eeprom also doesn't have a part number listed, but that's less problematic Sep 16 01:18:52 Right...that is hard coded for now. Sep 16 01:18:56 hows it goin zmatt you working on anything nifty Sep 16 01:18:59 hows py-uio Sep 16 01:19:03 but since you have the cape, you can probably just read the part number off the motor driver ICs themselves Sep 16 01:19:04 let me go check it out Sep 16 01:19:12 haven't worked on py-uio in a while Sep 16 01:19:16 Okay. Sep 16 01:19:40 The ICs are quite a bit large. I can probably get a photo of them and then work from there. Sep 16 01:19:54 it looks like you were doing some pru stuff with it? Sep 16 01:20:30 we're building a pruss interface in python, is your approach with py-uio more novelty or practical? Sep 16 01:20:45 ayjay_t: why wouldn't it be practical? Sep 16 01:20:54 I will let you two chat a bit. I am off to learn more. Sep 16 01:21:38 ayjay_t: I mean, not everything is quite the way I'd like it yet, but it's perfectly functional already Sep 16 01:21:45 zmatt: i'm not sure thats why i was asking. sometimes people's projects are more interesting technically, like "wow look we can do this" instead of being something we'd use Sep 16 01:23:52 it can map memory, load programs (both raw binaries from pasm and ELF executables from clpru), control the pru core, inspect and modify register (when halted), route and receive interrupts Sep 16 01:23:57 and has examples for all of these things Sep 16 01:24:17 yeah i like it Sep 16 01:24:25 i'm gonna run it by my coworker Sep 16 01:24:34 we might adopt it into a real project Sep 16 01:24:45 it's a bit lacking in documentation Sep 16 01:24:45 assuming you allow thayt Sep 16 01:25:10 sure, I stuck an MIT license on it Sep 16 01:25:30 the guy working on it doesnt' have as much experience as i do but he is probably more talented Sep 16 01:25:53 our first goal is to make a basic IO interface just to meet spec on a project and then use the PRUs to build a highspeed comm interface for an FPGA that's acting as a IO interface Sep 16 01:26:59 i know people leveraged the memory controller on the BBB to interface with an FPGA but honestly that sounds harder than writing something for a PRU and I'm pretty sure they gave up memory to do that? Sep 16 01:27:50 no it doesn't give up memory, it makes the FPGA appear to be a piece of memory (or memory-mapped I/O) to the cortex-a8 (and rest of the system, including dma) Sep 16 01:28:02 so the ports they were using are free? Sep 16 01:28:08 it conflicts with eMMC however Sep 16 01:28:12 (pin-conflict) Sep 16 01:28:20 ah yeah so in that way we are givng up memory eh? Sep 16 01:28:29 ah in that sense. I thought you meant RAM Sep 16 01:28:44 although in production i'd probably have no problem geting rid of the SD card Sep 16 01:28:48 thats a huge project though Sep 16 01:37:02 So... Sep 16 01:37:56 On that .dts file for the Cape, from what I can understand, specific pins are available but disabled. Sep 16 01:38:29 Does this mean that they are used by the Cape for the purpose of communicating w/ the BBB? Sep 16 01:38:49 Hell, I might not even has this Cape's .dts file in my config. Sep 16 01:38:53 I should check. Sep 16 01:38:57 it doesn't disable the pins, it disables runtime configuration of the pins Sep 16 01:39:06 cape overlays are loaded automatically Sep 16 01:39:10 Oh. Sep 16 01:39:13 Okay. Sep 16 01:39:37 that's why I suggested removing it (or moving it out of the way) to disable it Sep 16 01:41:12 I am reading into this .dts file and I see what pinmux GPIO pins are listed and what they mean for the MotorCape. Sep 16 01:41:26 What they mean to me is this... Sep 16 01:42:05 ex. m2.high and m2.pwm1.a are disabled but if I enable those pins via software, they will work out in my favor. Sep 16 01:42:35 03:38 < zmatt> it doesn't disable the pins, it disables runtime configuration of the pins Sep 16 01:42:56 Okay, okay. Sep 16 01:43:00 since they're being configured to fixed function Sep 16 01:43:03 Let me go and look up runtime config. Sep 16 01:43:25 as in, what's being disabled is the ability to use 'config-pin' on those pins Sep 16 01:43:32 since that configuration is already done by the overlay Sep 16 01:45:03 So, why does this overlay, if enabled by default, not work for me? Sep 16 01:45:38 I can try a group of GPIO or PWM pins that may be available and that could solve this issue. Sep 16 01:45:46 it declares the motor direction control pins to be leds, which will prevent them from being controlled like normal gpios Sep 16 01:46:13 I just, right this minute, do not know the name of these so-called gpios and pwm pins. Sep 16 01:46:14 OH. Sep 16 01:46:16 which means that most libraries to control gpios on the beaglebone won't work for them Sep 16 01:46:22 Aw! Sep 16 01:46:29 So, I would have to type up my own library. Sep 16 01:46:43 or just get rid of the overlay Sep 16 01:46:56 Right. That would be oh-so boring, though. Am I right? Sep 16 01:47:06 no it would be the sane thing to do Sep 16 01:47:33 Look. I like the same-ole, same-ole just everyone else but moving on sometimes would be nice. Sep 16 01:47:51 it also avoids having to fix your software later when the overlay is fixed (at least I hope it will) Sep 16 01:48:21 Ah...okay. So, there is some confusion as to how this .dts file will inevitably be configured in the future. Sep 16 01:48:22 would it not be nice to have your motor cape *working* ? :/ Sep 16 01:48:31 Yea, yea. Sep 16 01:48:53 But...I think for the "greater" good, using the MotorCape in time is more beneficial. Sep 16 01:49:11 I have not even the slightest clue what you mean by that Sep 16 01:49:19 Not right away. I am in no rush but I would like to know more about these .dts files. Sep 16 01:49:21 and I'm kind of done being confused by you for today Sep 16 01:49:25 Fine. Sep 16 01:49:27 See ya! Sep 16 01:49:30 Later for now. Sep 16 01:49:41 geez. **** ENDING LOGGING AT Sun Sep 16 02:59:59 2018