**** BEGIN LOGGING AT Wed Mar 21 03:00:03 2018 Mar 21 03:23:56 ZhuHaiyue: I don't think x15 is different? Mar 21 03:24:43 maybe I'm wrong Mar 21 03:25:21 does /boot/uEnv.txt on the x15 image not have a line you can uncomment to make it a flasher? Mar 21 05:57:39 Hi all Mar 21 05:58:48 yassyass: tip: if you have a question, just ask it (and have patience for a reply). "hi all" usually doesn't get a response here Mar 21 09:41:33 hi i have a question, somehow my bb blue won't boot up when i connect a hobby servo on servo #7 pins.. all others are working fine.. what could i look for to be able to debug this? thanks! Mar 21 09:41:47 hmm Mar 21 09:41:56 lemme see if I remember this right Mar 21 09:42:55 I think some pins of the BBB are sysboot pins, which means they need to be pulled in the right direction during power-on, so attaching an external load with too low input impedance might win from the internal pull resistors and mess things up Mar 21 09:43:41 hello Mar 21 09:44:07 vincentj_: yeah, SVO5-8 are sysboot pins, as are the signal pins of the E2 header Mar 21 09:44:11 how to write email to beagleBoard producer? Mar 21 09:45:02 vincentj_: 5-6 have pull-down, 7-8 have pull-up, but 8 isn't actually important Mar 21 09:45:25 zmatt: oh i see! that explains why 8 works just fine Mar 21 09:46:30 zmatt: so i guess what i'd have to do is check for the impedance of my hobby servo and compare that with the pull-up for servo 7, is that right? Mar 21 09:46:36 are the servos powered from the 6V ? Mar 21 09:46:49 since if so, I understand what's going on Mar 21 09:47:01 zmatt: yes.. they're all powered up from the rail.. the servo motor is this type: mg996r Mar 21 09:48:27 most likely the servo has a protection diodes from ground to signal input and from signal input to power, thus forcing the input signal to be somewhere between GND and VCC Mar 21 09:48:49 i.e. somewhere between GND and GND if it's not actually being powered yet Mar 21 09:50:32 lol, they should have seen this one coming tbh... this isn't easy to fix either Mar 21 09:50:52 or, well, maybe Mar 21 09:51:38 assuming the servo has high enough input impedance, you can maybe get away with using a big enough series resistor and extra pull-up to 3.3v (on the beaglebone side of the series resistor) Mar 21 09:52:45 TRIALINK: any particular reason you wan to write an email to the "beagleBoard producer"? Mar 21 09:53:03 that way the servo doesn't short the pin to ground when it's unpowered, but merely pulls it down via the series resistor. by making the series resistor big enough compared to the pull-up resistor, the pull-up will win Mar 21 09:53:45 then once the servo is powered, it should hopefully have high input impedance so the series resistor will have little impact, and the beaglebone's output will win from the pull-up Mar 21 09:54:05 lemme check the pull-up value used on the beaglebone Mar 21 09:54:58 zmatt: thanks a lot for the detailed explanation! if you don't mind, can i probe the input impedance of the servo from just the exposed pins (signal, gnd, vcc)? Mar 21 09:56:40 vincentj_: you mean using a multimeter or such? hmm, yeah you can, as long as the servo is powered and you use the right polarity Mar 21 09:57:15 ok, they used 100K pull-ups and 4.7K series resistors Mar 21 09:57:37 you need more like 1K pull-up and 10K series or something like that Mar 21 09:58:49 maybe even if unpowered actually Mar 21 09:59:47 not sure how reliable it will be though Mar 21 09:59:59 since semiconductors really don't behave like resistors :) Mar 21 10:00:27 zmatt: yes, using a DMM... just to be sure, the input impedance is the signal to ground resistance right? Mar 21 10:00:59 zmatt: just to be sure, from the schematic notes, only servo #5-#8 are boot pins right? Mar 21 10:01:00 actually now that I think of it, the multimeter probably uses insufficient voltage and will report a false high reading as a result Mar 21 10:02:02 and pins 3-4 of E2 (and technically pins 3-4 of UT5, but those are unimportant sysboot pins) Mar 21 10:03:08 signal to ground and vcc to signal (combined as if they're parallel resistors, i.e. 1/(1/R1+1/R2)) Mar 21 10:05:02 zmatt: i see.. i guess i'll try your suggestion of adding a pull-up and series resistor and see if that works.. i really thought that i fried those pins since the bb won't boot up when my hobby servo's connected to those pins... thanks zmatt for taking time to answer my question! Mar 21 10:06:20 yeah, and just measure the voltages at various points to confirm it's above 2V or so when the pin is undriven by the beaglebone and the servo is unpowered Mar 21 10:06:39 lemme check what actually happens when SVO7 is low instead of high Mar 21 10:08:32 eek, yeah that's not good, avoid doing that Mar 21 10:10:45 zmatt: oh, so i shouldn't add the pull-up and series combination? Mar 21 10:11:21 no you definitely should Mar 21 10:11:40 I was just checking what exactly is happening when you accidently get the beaglebone into that non-booting mode Mar 21 10:12:26 fortunately it looks like it shouldn't damage the hardware... Mar 21 10:13:03 zmatt: so what does happen if it goes to that non-booting mode? it's happened a few times now.. :/ Mar 21 10:14:00 it changes the boot order from { eMMC, uSD, uart, usb } to { usb, nand, xip (mux 2), nand (i²c config) } Mar 21 10:14:50 especially xip made me nervous since that configures a large number of pins as outputs, but it looks like none of them are connected to things that drive a signal into the am335x on the blue Mar 21 10:15:51 you can find more details in my pins spreadsheet: https://goo.gl/Jkcg0w Mar 21 10:16:33 zmatt: ohh.. that's a relief.. and thanks for this spreadsheet! Mar 21 10:17:44 if you scroll to the right on the BBBlue tab you can find columns that show which pins are used for which boot devices Mar 21 10:17:57 and the Boot tab summarizes the sysboot pins Mar 21 10:19:19 zmatt: thanks for the tips! i'm now checking the spreadsheet Mar 21 10:22:55 np Mar 21 10:28:56 yes, we would like to develop new board on the basis of element14beaglebone black - so we would like to ask the producer to modify this board for us Mar 21 14:04:10 Bbb recovery / won't reflash / only power led / any ideas? Mar 21 14:05:48 how did you prepare the SD card? Mar 21 14:06:13 Do you have a USB-to-serial adapter to attach to the debug UART? Mar 21 14:07:40 Win32boot whatever program for windows / dd on linux / compile-copy to disk by rcn recipe Mar 21 14:08:11 No debug uart.. is it important to get? Mar 21 14:08:59 Have been successful burning in the past... Mar 21 14:49:52 Hello Mar 21 14:50:10 Anyone here Mar 21 14:50:59 no. i am somewhere else. Mar 21 14:51:08 Ha! Mar 21 14:51:38 Is there a new 2018 version of the BBONE-BLACK-IND-4G Mar 21 14:52:19 I saw that a vendor discontinued this item under one of their part numbers then created a new part number for the same Beaglebone name Mar 21 14:52:28 "BBONE-BLACK-IND-4G" Mar 21 14:53:12 so what is the question? Mar 21 14:54:44 Is there a new 2018 version of the BBONE-BLACK-IND-4G? Mar 21 14:55:25 Are the specs different from one purchased in 2017? Mar 21 14:55:49 there has been nothing announced and no rumour that i knew of. Mar 21 14:56:25 ok. Thank you. Mar 21 14:56:38 oO( ? ) Mar 21 15:06:04 Hi, I could use some help Mar 21 15:06:40 state your case of emergency and wait for rescue. Mar 21 15:07:25 What kind of connectors do the GPIO's use on the x15? Mar 21 15:08:16 Guest54709: https://github.com/beagleboard/beagleboard-x15/blob/B1/BeagleBoard-X15_SRM.pdf?raw=true Mar 21 16:01:06 what is a good webcam server program that will run on a BBBW? I tried motion but it lags real bad if I make the image size larger than 320x240. Looking for something that will give me a webserver and is easy to setup like motion but without the motion detection/security cam stuff Mar 21 16:10:25 Heey guys, I've got a question. How is the pocket beagle with the octavo able to boot? I'm trying to create my own bsp with yocto but I can seem to figure out how the boot process works. I think I understand that the sdcard is formatted as follows: sectors of 128k. Sector 1 partition table. Sector 2 MLO. Sector 3 Uboot. Sector 64 start of ext4 file system. Mar 21 16:10:41 What is triggering the MLO? Mar 21 16:12:07 I can boot my system with the debian image but when I replicate an sdcard with the above with uboot gerated for an am335x_evm and the MLO I don't get any output when booting Mar 21 16:12:21 So I want to understand how the bootprocess works Mar 21 16:14:21 I checked if my settings are the same as those from the BBB in yocto and they are. I only use a different kernel source (the one form beaglebone not yocto) and tell yocto to generate the device tree. Mar 21 16:22:38 I recently started learning about device tree overlays and loading a device tree overlay (ive been following along in Exploring BB) and I have hit a snag. I do not see a slots file in my bone_capemgr directory. anyone know why this is missing? I am running Linux beaglebone 4.9.78-ti-r9 Mar 21 16:23:19 swaine: bone_capemgr is deprecated and automatically disabled when u-boot overlays (its replacement) is enabled Mar 21 16:24:06 so would I use u-boot instead of bone_capemgr? Mar 21 16:24:50 flitjes: with normal 512-byte sector size, sector 0 is the partition table, sector 256 the configuration header, sector 257+ contain the SPL, sector 768+ contain u-boot.img Mar 21 16:25:17 the MLO of the SPL I mean Mar 21 16:25:34 but note that the "MLO" file u-boot produces actually already has the configuration header prepended Mar 21 16:26:36 swaine: overlays still work the same, but they're loaded by u-boot and applied to the main device tree before it's passed to the kernel, instead of being loaded at runtime by the kernel Mar 21 16:26:49 swaine: note however that usually you don't need to mess with overlays at all Mar 21 16:27:14 since cape-universal is enabled by default, which enables pretty much all peripherals and allows pinmux to be configured at runtime using the 'config-pin' utility Mar 21 16:29:39 so basically its easier now. The information im reading about on device tree overlays and the cape manager is antiquated. Mar 21 16:34:04 yep Mar 21 16:34:14 flitjes: https://pastebin.com/8rBYHXtV Mar 21 16:34:45 well SOB. another markout for the book. Thanks Mar 21 16:35:23 books on topics like these tend to be outdated already the moment they hit the shelves Mar 21 16:35:48 only if you are riding the bleeding edge Mar 21 16:36:45 current stable image is not generally considered 'bleeding edge' Mar 21 16:37:06 only if you want to look at things like a desktop Mar 21 16:37:15 eh? Mar 21 16:37:30 <-- still supporting 2.6 on devices Mar 21 16:38:25 so? Mar 21 16:38:33 different model of things Mar 21 16:38:49 how is it relevant here? Mar 21 16:38:58 yeah im continually reminded that. Mar 21 16:39:06 of course you can choose to keep things in an older state Mar 21 16:39:15 what you are calling "stable" may not meet someone else's stable Mar 21 16:39:21 if you're willing to do maintenance yourself or don't care about it Mar 21 16:39:29 your stable is my bleeding edge Mar 21 16:39:44 what I'm calling "stable" is what nearly everyone who walks into this channel is working with Mar 21 16:39:55 "nearly" :D Mar 21 16:40:25 (or if they're not, probably should be) Mar 21 16:40:30 you're not my audience ds2 Mar 21 16:40:32 and you know that Mar 21 16:40:39 (or if they're not, probably should be) Mar 21 16:40:46 That is what I disagree with Mar 21 16:41:10 there are course materials for the non bleeding edge stuff Mar 21 16:41:27 telling people to follow a moving train just adds to the confusion Mar 21 16:42:51 I agree that some stability would really be appreciated, but at the same time things have become much more newbie-friendly now Mar 21 16:43:23 it is nice for developers for everyone to be on the latest (as declared by the devs) but chasing a moving train isn't that useful Mar 21 16:43:25 and in practice if they're not using a recent image, they're using a random old one that probably still doesn't quite match whatever random guide or instructions they're following Mar 21 16:44:44 not trying to knock at what you are doing; just think it is important to point out the other view (chasing a moving train) Mar 21 16:45:23 cape-universal has now been the default for quite a long time though Mar 21 16:45:49 and when using that, the transition from bone_capemgr to u-boot overlays is basically invisible Mar 21 16:46:56 apparently not long enough for course material to be updated :/ Mar 21 16:48:01 well duh, he's following a book published in december 2014 Mar 21 16:49:08 considering we still see references to angstrom.... being on a non Angstrom device should be an achievement! Mar 21 16:49:15 lol Mar 21 17:41:35 Hey zmatt, I'm trying to get your py-uio library working on another BeagleBone. I'm having a little trouble with the part described in your readme where you copy the rules files. Mar 21 17:41:50 file Mar 21 17:42:01 I copied the rules files, but I don't see uio in /dev/ Mar 21 17:42:08 Gotcha, I mean file Mar 21 17:42:25 I rebooted, and ran the commands you listed. Mar 21 17:42:28 you don't see any /dev/uio* or just no symlinks in /dev/uio/ ? Mar 21 17:42:35 This beaglebone has the latest debian image Mar 21 17:42:42 I don't see any /dev/uio* Mar 21 17:42:59 that's not related to py-uio, that just means uio-pruss isn't working Mar 21 17:43:13 Got it, Mar 21 17:43:24 Let me check my uEnv.txt file... Mar 21 17:43:29 make sure it (and not remoteproc-pru) is enabled in /boot/uEnv.txt Mar 21 17:43:44 if using a -ti kernel, upgrade to the very latest one Mar 21 17:44:32 Ok, the uEnv.txt file looks good Mar 21 17:44:32 I'll try the kernel upgrade Mar 21 17:44:41 I don't know if rcn has already fixed the issues with it, otherwise you may need to switch to a -bone kernel or do a small patch of the dts (using dtb-rebuilder) Mar 21 17:45:18 I'll just switch to a -bone kernel, I don't care which I'm using Mar 21 17:47:11 What is the latest bone image? Mar 21 17:47:22 I think last time I ran sudo apt-get install linux-image-4.14.27-bone13 Mar 21 17:47:47 I believe the newest is 4.9-bone Mar 21 17:49:05 4.14 is newer than 4.9 obviously Mar 21 17:52:32 linux-image-4.14.28-bone14 is the latest in the 4.14-bone series Mar 21 17:52:40 Oh, I thought 4.9>4.14... Mar 21 17:53:11 I'm going to give this board to someone so I'm starting with the latest debian image and writing down all of the steps to get it setup. Mar 21 17:53:13 14 is a bigger number than 9 Mar 21 17:53:19 :) Mar 21 17:53:21 lol, Mar 21 17:54:22 So you would reccomend linux-image-4.14.28-bone14? Is the 4.14-bone series the latest and greatest? Mar 21 17:54:52 4.14 is the latest LTS kernel Mar 21 17:54:55 series Mar 21 17:55:32 so yes that's what I would recommend if you don't specifically need some feature of the -ti series Mar 21 17:56:19 I don't think I specifically need some feature of the -ti series though, Mar 21 17:56:49 I'm using the 4.14-bone series myself too Mar 21 17:58:41 Ok Mar 21 18:03:38 Hi is there any benefit it using connman or /etc/network/interface Mar 21 18:03:48 on the beaglebone black Mar 21 18:05:08 ifupdown (which is what you mean by "/etc/network/interfaces" presumably) is simple but doesn't always behave well in dynamic environments, and it tends to delay boot time (by a _lot_ if no network is attached) Mar 21 18:05:25 connman also has some features for tethering which people often use Mar 21 18:05:35 I personally use neither, I use systemd-networkd instead Mar 21 18:14:36 zmatt: No I was referring for configuring IP addresses etc, it seems to be me that connman requires alot of process to get going Mar 21 18:15:14 ? Mar 21 18:15:55 while configuring using the /etc/network/interface file seems more straight forward Mar 21 18:16:24 well normally dhcp used and no configuration is needed Mar 21 18:16:28 *is used Mar 21 18:16:51 I'm not hugely familiar with how configuration is done with connman since I don't use it Mar 21 18:17:22 I am also looking at the the flexibility of using static/dhcp Mar 21 18:17:23 the config files for systemd-networkd are pretty much just as simple as those for ifupdown Mar 21 18:18:41 I would try and find some examples because I am not familiar with systemd-networkd Mar 21 18:21:59 Ok, thanks again zmatt! Now I have the uio folder in /dev/ Mar 21 18:22:40 onio: e.g. https://pastebin.com/55u4SQCp Mar 21 18:23:07 So I feel like I keep asking this, but why doesn't the newest debian release come with the newest kernel? I believe it comes with 4.9. Mar 21 18:23:30 zmatt: cool, what about assigning static ip addresses? Mar 21 18:23:43 onio: e.g. Address=10.16.0.1/16 Mar 21 18:23:47 man systemd.network Mar 21 18:24:00 zmatt: thanks Mar 21 18:25:18 hunter235711: it generally takes a bit before a new kernel series is made default, e.g. because not all patches have been forward-ported yet, or there are some issues for some use cases, or just to give it enough testing before making it the default Mar 21 18:27:24 Hi zmatt Mar 21 18:28:30 Ok, that makes sense. Thanks! Mar 21 18:28:35 yo Mar 21 18:35:14 zmatt: Remember last week? I was not able to read updates the PRU makes in the sharedram. Now I minified my programm and it seems that it doesn't work too. I can send you the code if you want to take a look at it. Mar 21 18:37:10 just paste a link and I may give it a look when I have a moment, or perhaps someone else will Mar 21 18:48:07 https://owncloud.freakscorner.de/index.php/s/GQ5CMisk8GDmqPi Mar 21 19:16:54 I guess this is more of a Python question than PRU, but I'm getting ADC samples from the PRU into python. They have a header of 8 bits followed by 24 bits of ADC data in 2's complement representation. Mar 21 19:17:41 I'm converting it to a numpy array as shown: https://pastebin.com/7X6pfuL6 Mar 21 19:19:01 It seems to be working, and when I print x[0][0] I get a number ( 1100599253 for example) Mar 21 19:19:18 x << 8 >> 8 (assuming your question was how to extract and sign-extend the lower 24 bits) Mar 21 19:20:03 Wow, mind reader :) Mar 21 19:20:17 I actually said that to you already earlier Mar 21 19:20:47 Yeah, but I've been trying it unsuccesfully, and I thought Python doesn't do logical shifts, Mar 21 19:21:20 So bin(x[0][0])='0b1000001100110011100111111010101' Mar 21 19:22:35 bin(x[0][0] << 8 ) '0b100000110011001110011111101010100000000' and bin(x[0][0] << 8 >> 8) *** SyntaxError: invalid syntax Mar 21 19:23:12 uh what? Mar 21 19:23:33 btw with 'x' here I meant the whole numpy array Mar 21 19:23:39 you don't have to do it with each element individually Mar 21 19:23:51 Yeah, I am just trying one element to see how it is working Mar 21 19:24:40 in fact it won't work on the elements Mar 21 19:24:59 But it works on the whole numpy array? Mar 21 19:25:09 yes, since that is explicitly an array of int32 Mar 21 19:25:38 while a python int has unrestricted range, so x << 8 >> 8 has absolutely zero overall effect Mar 21 19:25:59 But wouldn't it know that x[0][0] is also an int32 since x is an int32 array? Mar 21 19:26:12 no it returns an int Mar 21 19:26:53 oh Mar 21 19:26:58 or maybe I'm wrong Mar 21 19:27:06 oh lol what Mar 21 19:27:12 numpy is being "helpful" it seems Mar 21 19:27:46 https://pastebin.com/raw/rnU7GP6D Mar 21 19:28:09 Yeah, if I do y = (x << 8 >> 8), y[0][0] = x[0][0] Mar 21 19:29:18 uh what? Mar 21 19:29:19 Maybe there is an option to force it to not be helpful Mar 21 19:29:20 not for me Mar 21 19:30:01 it works fine here Mar 21 19:30:12 https://pastebin.com/raw/STDN862A Mar 21 19:31:56 it's just single elements that give trouble (though for a slightly different reason than I originally thought) Mar 21 19:32:29 Oh, you're right: https://pastebin.com/njqmyc4U Mar 21 19:32:38 oh instead of np.asarray(..., dtype=np.int32) you can also just write np.int32(...) Mar 21 19:34:42 do you find bin() easier to read than hex() ? for me it's definitely the opposite Mar 21 19:35:03 No, just didn't know about hex() :) Mar 21 19:35:14 ah Mar 21 19:38:40 Hi! Mar 21 19:39:06 I got a question regarding the device tree Mar 21 19:40:29 If you override am33xx_pinmux and add a node which selects the correct mode Mar 21 19:40:43 "override am33xx_pinmux" ? Mar 21 19:41:11 Don't know the correct lingo, I'll share the file I'm writing Mar 21 19:41:29 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/alsa/devicetree/beaglebone-black-codec-alsa.dts Mar 21 19:41:41 That is a project I am working on Mar 21 19:42:08 overlay is probably the word you're looking for Mar 21 19:42:19 But I don't know if the GPIO pins are correctly exported as I don't have a bone-pinmux-helper Mar 21 19:43:26 gpio-of-helper you mean? Mar 21 19:43:41 you do need one, right now your gpio pinmux isn't being referenced Mar 21 19:43:51 also, gpio-of-helper is responsible for actually exporting the gpio Mar 21 19:44:01 aha, great! didn't know that Mar 21 19:44:02 e.g. https://pastebin.com/CPiC2CnB Mar 21 19:44:21 (this is just a DT fragment instead of an overlay mess) Mar 21 19:44:35 i thought that overlaying the am355x_pinmux would suffice Mar 21 19:44:49 oh, &pinctrl on line 47 in that snippet should be &am355x_pinmux, sorry Mar 21 19:45:12 no, pinmux blocks need to be activated by a driver Mar 21 19:45:56 alrighty, thanks for the fast answer! Mar 21 19:46:01 Why is it that hex(x[53][2])='0x547ffce5', hex(x[53][1])='-0x328002c7', but x[52][2] = 1417673957, x[53][1] -847250119 Mar 21 19:46:24 I thought the top bit determined if a number was positive or negative? Mar 21 19:47:21 uh, 0x547ffce5 == 1417673957 and -0x328002c7 == -847250119 Mar 21 19:48:01 when encoded into a fixed-size signed integer, yes Mar 21 19:49:04 i.e. np.int32(0x80000000) == -0x80000000 Mar 21 19:49:57 So why did python decide one sample was positive and one was negative? Mar 21 19:50:24 I don't understand the question Mar 21 19:50:36 bit 31 decided that Mar 21 19:51:21 https://pastebin.com/raw/qESRqZN5 Mar 21 19:52:43 Gotcha, so when I look at the hex representation of x[53][1] python is hiding bit 31 and just showing it as the sign. Mar 21 19:53:24 uh, no Mar 21 19:54:49 hex() just takes an integer and shows it in base 16 Mar 21 19:54:58 it's showing it as negative when it's negative Mar 21 19:55:48 it doesn't know or care that it was obtained from a signed 32-bit representation Mar 21 19:56:26 So it interpreted x[53][1] as negative because bit 31 was set, but when I look at the binary representation of x[53][1] I can't see that bit 31 was set? Mar 21 19:56:52 >>> (-2147483648) >> 31 & 1 Mar 21 19:56:52 1 Mar 21 19:56:55 bit 31 is set Mar 21 19:57:15 as is bit 32, bit 33, and all bits above it... since this is an integer, not a 32-bit integer anymore Mar 21 19:58:07 Got it Mar 21 19:58:51 note I'm saying "all bits above it" are set since (-2147483648) >> 31 is -1, and (-1) >> 1 is -1, and no matter how much you try to shift-right it's still -1 :) Mar 21 20:00:55 Got it, makes sense Mar 21 20:03:45 Ok, so I am still a little confused. Channel 0, sample 122 (x[122][0]) is '0x436b5970' (0b10000110 11010110101100101110000). When you throw away the first 8 bits (discarding the header) the sample starts out 11010... indicating it was negative (as it should be, I'm applying a voltage < 0). Mar 21 20:04:11 uhh, no Mar 21 20:05:00 But if I do y = (x << 8 >> 8), y[122][0] = 7035248 Mar 21 20:05:44 the bits 24-31 of 0x436b5970 are 01000011 Mar 21 20:05:44 Why no Mar 21 20:06:00 bit 23 (the top bit after << 8) is 0 Mar 21 20:06:13 a positive result is correct Mar 21 20:06:38 Why is bin(x[122][0]) = '0b1000011011010110101100101110000'? Mar 21 20:07:05 why would it not be? Mar 21 20:07:34 but why does Derek use bone-pinmux-helper? https://github.com/derekmolloy/boneDeviceTree/blob/master/overlay/DM-GPIO-Test.dts Mar 21 20:07:46 is that an obsolete way of doing it? Mar 21 20:07:49 hunter235711: bin() like hex() takes an integer as input Mar 21 20:08:08 hunter235711: why would it add leading zeros? how many? Mar 21 20:08:36 and the official device tree overlays all seem to use bone-pinmux-helper Mar 21 20:08:45 https://github.com/beagleboard/bb.org-overlays/search?utf8=%E2%9C%93&q=bone-pinmux-helper&type= Mar 21 20:08:55 bou4: no idea why he's using that Mar 21 20:09:22 bone-pinmux-helper is used a lot yes, but not to configure or export gpios Mar 21 20:09:28 because it does neither Mar 21 20:09:40 Oh, I see what you mean... There is a 0 missing... Mar 21 20:09:44 pinmux-helper is used to allow userspace to select between pinmux options Mar 21 20:10:05 in your case you're trying to configure fixed pinmux, so you have no need for it Mar 21 20:11:02 the example from derek molloy is puzzling to me since he doesn't setup the gpio with a gpio-of-helper, and if he did use one then there wouldn't be any use for the pinmux helper Mar 21 20:11:34 but do note the date on that example Mar 21 20:11:38 2013 Mar 21 20:12:46 alright, thanks! you can't believe the amount of work you're sparing me Mar 21 20:13:02 do you have any documentation of gpio-of-helper? Mar 21 20:14:33 https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi#L22-L68 hopefully this suffices Mar 21 20:16:22 note that my overlay-utils allow you to compile overlays from normal DT fragments (it uses a perl script to preprocess it into the ugly syntax required for an overlay) Mar 21 20:16:44 makes things a bit more readable :) Mar 21 20:17:16 you're dutch? Mar 21 20:17:54 dat maakt communiceren dan wel weer iets gemakkelijker :p Mar 21 20:18:20 thanksss Mar 21 20:19:17 english please Mar 21 20:23:09 sorry, and it seems that Derek also uses gpio-of-helper in his book Mar 21 20:25:47 Got any handy tool for generating the numbers in pinctrl-single,pins? Mar 21 20:25:54 right now I am using a spreadsheet I found online Mar 21 20:26:17 use macros, see the examples in my overlay-utils repository Mar 21 20:27:00 (main dts and overlays repositories use slightly different macros that were added later, and they're not being used very consistently) Mar 21 20:28:51 aha, great! Mar 21 20:29:11 you wrote those macro's yourself or is there an official repo containing them? Mar 21 20:29:55 I wrote these particular ones Mar 21 20:30:13 like I said, the official repos have slightly different ones Mar 21 20:32:58 alright, thanks a lot! Mar 21 20:33:08 hoping to book more results in the lab tomorrow Mar 21 20:33:34 right now I am able to produce a very dirty sine wave with the codec Mar 21 20:33:52 but my PCB is getting milled monday and I hope to see better results then Mar 21 20:34:04 I found the solution to my problem :-) Mar 21 20:34:46 ok :) Mar 21 20:44:12 gpio works! Mar 21 20:58:45 last question Mar 21 20:59:05 is there anything else to do for getting a pin to be a pulldown pin than setting the am3xx_pinmux target Mar 21 20:59:43 because if i wire an LED between +3.3V and the GPIO pin I configured it won't light up Mar 21 21:00:08 but it does work, because the driver that drives the pin sets it high after it boots up Mar 21 21:00:15 but not immediately Mar 21 21:00:26 I want it to be pull down before it gets high Mar 21 21:00:38 so it resets the codec IC i am driving with the BB Mar 21 21:01:18 https://github.com/thomasfaingnaert/scriptable-guitar-pedal/blob/alsa/devicetree/beaglebone-black-codec-alsa.dts Mar 21 21:01:22 this is what I currently have Mar 21 21:01:31 uhh, I hope you placed a suitable resistor in series with that led Mar 21 21:01:38 I did Mar 21 21:03:07 uhh your gpio-of-helper is empty... you're not setting up any gpios Mar 21 21:03:41 doesn't setting pinctrl-0 do this already? Mar 21 21:03:47 that's pinmux Mar 21 21:03:49 that's what I understood from Derek's book Mar 21 21:04:18 0x048 0x27 /* gpio1_18: output, pull down, mode 7 */ Mar 21 21:04:30 that just configures it as gpio Mar 21 21:04:37 what's the point of setting it to pull down then there? Mar 21 21:04:44 prevent the pin from floating Mar 21 21:05:03 it's an extremely weak internal pull resistor (50-150 Kohm) Mar 21 21:05:51 I understand, but why do you set it multiple times Mar 21 21:06:00 once under am33xx_pinmux and once under gpio-of-helper Mar 21 21:06:10 they're very different things Mar 21 21:06:52 gpio-of-helper configures the gpio itself: whether it's initially input, output-low, or output-high, whether its direction can be changed, and its polarity (active-high/low) Mar 21 21:07:04 and it can give it a name for convenient reference Mar 21 21:08:22 pinmux configures the fact that the pin is being used for gpio, the weak internal pull resistor (up/down/disabled), and whether the receiver should be enabled or not Mar 21 21:10:00 gpio-of-helper also exports the gpio via sysfs Mar 21 21:10:34 (so you don't have to do that manually) Mar 21 21:10:43 but is it possible that I don't have to do that kind of configuration as the driver of the CS4272 sets the pin high Mar 21 21:10:54 but it does have to be configured as a pull down pin Mar 21 21:11:09 ohhh Mar 21 21:11:13 I missed that part Mar 21 21:11:38 then the pinmux for the gpio should be referenced by the codec, no gpio-of-helper should be needed Mar 21 21:11:58 the pull direction shouldn't matter though if the pin is being controlled by the driver, that makes no sense Mar 21 21:12:07 once the gpio is configured as output, the pull is irrelevant Mar 21 21:12:34 oh, yes, now it makes it sense in my head Mar 21 21:13:09 so how does the pinmux get exported Mar 21 21:13:15 because if i delete the gpio-of-helper node Mar 21 21:13:16 if you need the reset line to be low initially before the driver takes control of it, use an external pulldown resistor Mar 21 21:13:39 nothing references the gpio_pins Mar 21 21:13:40 you should put the pinctrl properties in the codec instead of in gpio-of-helper Mar 21 21:13:45 the codec should reference it Mar 21 21:14:10 https://www.kernel.org/doc/Documentation/devicetree/bindings/sound/cs4271.txt Mar 21 21:14:25 even if the node doesn't document pinctrl-names and pinctrl-0? Mar 21 21:14:31 does every node have that property? Mar 21 21:14:47 every node that represents a device yes Mar 21 21:15:08 it's a general thing, hence not specifically documented for every driver Mar 21 21:15:45 basically the reference to the pinmux should be in whatever device uses the pin Mar 21 21:15:55 alright, thanks a lot Mar 21 21:16:06 in this case, the codec uses the gpio, hence the codec should reference the gpio's pinmux Mar 21 21:16:20 and if I understand this correctly, pull up and down is only relevant to inputs? Mar 21 21:16:53 what I was thinking the whole time Mar 21 21:17:39 basically yes... once the output is enabled, the internal pull-up/down will accomplish nothing more than consuming a tiny amount of power Mar 21 21:18:03 so best disable it for every output Mar 21 21:18:54 generally safer to leave them enabled to ensure pins won't float Mar 21 21:19:23 unless you're really trying to optimize the last tiny bits of power consumption Mar 21 21:19:47 e.g. in case the output is not being enabled for whatever reason Mar 21 23:01:48 hey, looking for a little help with BBB PRU GPIO toggle. Trying to drive an LED using P8_11 GPIO to gate of a 2N7000 MOSFET. Able to compile code and use pru_rproc to load to PRU and start PRU successfully. Have tried a handful of different overlays but haven't been able to see the pin go high. Mar 21 23:03:35 normally you shouldn't need to mess with overlays Mar 21 23:03:59 in the default config, you can configure pins at runtime using the 'config-pin' utility Mar 21 23:04:31 (if you've been messing with overlays in /boot/uEnv.txt you may first need to undo your changes) Mar 21 23:06:07 should I uncomment 'uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo'? Mar 21 23:06:27 if you want to use remoteproc-pru then yes Mar 21 23:06:37 and in that case make sure the PRU-UIO one is commented out Mar 21 23:06:46 I disabled emmc, video, audio, and wireless Mar 21 23:07:00 why? Mar 21 23:07:03 it is Mar 21 23:07:15 ummm so I can use all the PRU1 pins eventually Mar 21 23:07:27 emmc conflicts with a bunch of those right? Mar 21 23:07:41 two of them Mar 21 23:07:42 and it's headless Mar 21 23:07:58 so I don't care about HDMI, and I'm using Ethernet Mar 21 23:08:12 okay so you don't have wireless, so that option does nothing Mar 21 23:08:32 using the eMMC pins requires more precautions though Mar 21 23:08:55 you'll need to use mmc-utils to enable the eMMC's reset pin in its OTP config Mar 21 23:09:39 so unless you really need those last two extra pins, you may just want to leave eMMC enabled Mar 21 23:09:46 okay so I'll re-enable emmc Mar 21 23:10:22 also, if you're booting from sd card, if there's any risk that there's a relatively old u-boot flashed on eMMC, you may want to wipe that to ensure u-boot is loaded from sd card instead Mar 21 23:10:35 you can wipe eMMC with sudo blkdiscard /dev/mmcblk1 if you don't care about its contents Mar 21 23:11:16 (or just reflash eMMC instead of booting from sd card) Mar 21 23:11:43 yeah there's probably an old version on the eMMC Mar 21 23:12:04 old u-boot + new system can cause problems Mar 21 23:12:19 interesting Mar 21 23:12:32 so I don't have mmcblk1... Mar 21 23:12:36 just mmcblk0 Mar 21 23:12:37 because you disabled eMMC Mar 21 23:12:43 ahh Mar 21 23:13:18 okay so I'll just wipe eMMC for the time being after a reboot Mar 21 23:14:19 it's a common issue... bootrom prefers loading u-boot from eMMC over uSD, u-boot prefers loading linux from uSD over eMMC so you think you're simply booting from uSD and don't realize u-boot is still loaded from eMMC Mar 21 23:14:35 old u-boot can successfully load linux, but it doesn't understand many of the newer config options in /boot/uEnv.txt Mar 21 23:15:33 (in particular everything to do with uboot overlays) Mar 21 23:16:01 although maybe your uboot is actually recent enough, since otherwise the emmc-disable wouldn't have worked I guess... hmm... Mar 21 23:16:10 not sure Mar 21 23:16:33 regardless, it's best to use the u-boot that comes with the image you're booting Mar 21 23:16:44 yeah, makes sense Mar 21 23:16:56 just ran the blkdiscard Mar 21 23:18:15 so a simple 'config-pin P8_11 pruout', should set the pin to the correct mode for output? Mar 21 23:18:21 yup Mar 21 23:18:41 you can double-check your current pin configuration with my show-pins utility: https://github.com/mvduin/bbb-pin-utils/#show-pins Mar 21 23:20:31 P8.11 13 fast rx down 6 pru 0 out 15 ocp/P8_11_pinmux (pinmux_P8_11_pruout_pin) Mar 21 23:20:40 looks good Mar 21 23:20:40 seems right Mar 21 23:23:40 hmmm still no luck Mar 21 23:23:56 maybe an issue with your program? Mar 21 23:24:26 you said it started successfully... are you sure about that? Mar 21 23:25:40 that's what I'm thinking... __R30 = __R30 | (1 << 15); should make the pin go to 3.3V, right? Mar 21 23:26:04 (shameless plug: instead of using remoteproc-pru, you can also enable uio-pruss instead and use my py-uio to load executables, control and inspect the pru cores, map shared memory and more, with simple python code. example: https://github.com/mvduin/py-uio/blob/master/pruss-elf-test.py ) Mar 21 23:26:10 yup Mar 21 23:26:23 cat /sys/class/remoteproc/remoteproc1/state returns 'running' Mar 21 23:27:08 I think remoteproc has some way of dumping the registers? Mar 21 23:27:24 actually, core needs to be halted for that Mar 21 23:28:36 any idea how to dump them? Mar 21 23:28:45 I stopped the PRU Mar 21 23:28:50 somewhere in debugfs I think Mar 21 23:28:57 I don't use remoteproc so I'm not sure :) Mar 21 23:29:04 haha fair enough Mar 21 23:29:12 check in /sys/kernel/debug for something that smells remoteprocish Mar 21 23:30:35 cat /sys/kernel/debug/remoteproc/remoteproc1/regs Mar 21 23:30:37 good call Mar 21 23:32:00 alright, well let's see if I can give uio-pruss a go Mar 21 23:33:50 if you're using a kernel in the 4.9-ti or 4.14-ti series you may need to upgrade to the latest version in the series or switch to a -bone kernel series, since uio-pruss was disabled in those until recently :-/ Mar 21 23:34:14 assuming I can use same fw, the process would be change /boot/uEnv.txt to load UIO-PRUSS overlay, reboot, then use python to load the same fw I was trying to load before Mar 21 23:34:37 and install the uio-pruss.rules file, see https://github.com/mvduin/py-uio#uio_pruss Mar 21 23:34:39 very recent 4.9-ti Mar 21 23:35:21 Linux beaglebone 4.9.82-ti-r102 Mar 21 23:35:55 4.9.83-ti-rt-r105 is latest Mar 21 23:35:57 eh Mar 21 23:36:01 4.9.83-ti-r105 Mar 21 23:38:19 alright well I'll try this one and see what happens Mar 21 23:39:22 if it has trouble loading I'm pretty sure I know how to fix it... I've been mailing with rcn about this, but it doesn't seem he has fully fixed it yet Mar 21 23:40:02 okay, have to run for about 10 or so, I'll you know if it works when I get back Mar 21 23:40:11 thank you so much for the help Mar 21 23:40:23 I'll try 4.9.83-ti-r105 too... I wanna see what happens exactly Mar 21 23:55:11 aaaaand of course it doesn't boot anymore. *sigh* what did I fuck up now Mar 21 23:55:44 yelling at me for ti.icss module missing Mar 21 23:56:12 uhh? Mar 21 23:56:36 you're running the script from within a checkout of the py-uio repository? Mar 21 23:57:13 yeah Mar 21 23:57:49 oh, and don't do "python script.py", but "python3 script.py" or just ./script.py Mar 21 23:58:07 unfortunately for compatibility reasons 'python' still refers to the old python 2 Mar 21 23:58:30 even though python 3 has been out for a decade and python 2 is barely maintained anymore and approaching end of life Mar 21 23:59:05 yep, that worked, don't have a /dev/uio though Mar 21 23:59:51 yeah that's what I was worried about... if you want a quick fix *now*, use a 4.9-bone or 4.14-bone series kernel Mar 22 00:00:06 I'll debug what's going on with 4.9-ti and poke rcn again to fix it Mar 22 00:02:00 oh duh, lol, I'm an idiot Mar 22 00:03:02 I normally use a custom-built u-boot, kernel, and DT, so for testing this I quickly installed the default flavors of all of those... turns out I forgot to install the overlays *facepalm* Mar 22 00:12:57 oh wth Mar 22 00:13:18 jrgriff: check if you see any modules listed as all when you do lsmod Mar 22 00:13:23 if not, run sudo depmod and reboot Mar 22 00:14:53 as in Used By: all? Mar 22 00:15:00 or the module 'all'? Mar 22 00:15:57 *at all Mar 22 00:15:59 sorry, typo Mar 22 00:16:34 for some reason after installing the latest 4.9-ti it seems it didn't run depmod for me, resulting in no modules being loaded Mar 22 00:17:08 oh gotcha Mar 22 00:17:13 yeah there's a lot loaded Mar 22 00:17:17 ok Mar 22 00:17:35 pruss_soc_bus Mar 22 00:17:38 uio Mar 22 00:17:45 yeah so that's what's going wrong Mar 22 00:17:47 uio_pdrv_genirq Mar 22 00:18:03 the base dts contains remoteproc-pru stuff Mar 22 00:18:16 so loading the uio-pruss overlay on top of that results in... a mess Mar 22 00:18:29 mmmm interesting Mar 22 00:18:35 I think it's a 3-line fix in the dts, but I'm having a bit of trouble with my testing setup :-/ Mar 22 00:19:15 gotcha Mar 22 00:19:42 the -bone kernels don't have remoteproc-pru, hence don't have this issue Mar 22 00:19:45 so the 4.9-bone doesn't have a dts with remoteproc stuff? Mar 22 00:19:47 lol Mar 22 00:21:54 is it just the Stretch IoT build from https://beagleboard.org/latest-images? Mar 22 00:22:05 oh you don't need to reflash anything Mar 22 00:22:09 you can just apt-get install the kernel Mar 22 00:22:48 (though more generally, yes the stretch iot there is the recommended image. it has a 4.9-ti kernel though) Mar 22 00:25:30 ahh okay, so not sure what to 'apt-get install' to get that kernel Mar 22 00:26:17 --bone-kernel --lts-4_9? Mar 22 00:26:42 oh yeah, you can use that script too instead of using apt-get manually Mar 22 00:26:51 I don't know how it actually works Mar 22 00:26:56 :D Mar 22 00:28:26 got it Mar 22 00:29:27 so in 4.9-bone it should work pretty smoothly? Mar 22 00:29:35 it should yes Mar 22 00:31:05 any experience with the rt version? Mar 22 00:33:28 I've played with one a little bit a while ago Mar 22 00:34:45 it's kinda funny to be able to assign a userspace thread a higher priority than an interrupt handler, but unless you specifically need the rt features it's just a more inefficient (and often buggier) kernel Mar 22 00:35:05 yeah, building a quadcopter Mar 22 00:35:17 I figure the PRUs will give me all the RT I need Mar 22 00:35:58 okay loaded the bone kernel Mar 22 00:36:05 if you can stick all RT stuff in PRUSS then that's ideal Mar 22 00:36:05 uio's show up under /dev Mar 22 00:36:34 41 waiting for core to halt 42 Mar 22 00:36:44 that's expected output, yay :) Mar 22 00:36:51 see the c code to understand why Mar 22 00:36:57 yeah I figure I can at least get the flight controls in there Mar 22 00:37:03 note that I don't actually recommend the use of C Mar 22 00:37:18 but it is more convenient I guess Mar 22 00:37:37 (also, my test setup finally boots normally \o/ ) Mar 22 00:37:45 GPS and telem can probably stay in linux land Mar 22 00:38:05 interesting... so just rolling with the assembly then? Mar 22 00:38:28 each pru code only has 8 KB of instruction ram, i.e. 2048 instructions Mar 22 00:38:46 and the pru instruction set was never designed to be targeted by a C compiler, it was designed to be programmed by humans Mar 22 00:40:30 so basically, it can't possibly be as efficient as a human? Mar 22 00:40:30 e.g. C tends to encourage the use of signed integers, while the PRU core has no support for them, so for example ( a < b ) where a,b are ints is implicitly converted to ((unsigned)(a ^ 0x80000000) < (unsigned)(b ^ 0x80000000)) Mar 22 00:41:51 oh interesting, okay well "I coded the flight controls in assembly by hand" will be more fun to say anyway Mar 22 00:41:58 hehe Mar 22 00:42:07 I'll have to brush up on the instruction set Mar 22 00:42:15 so I don't know what sort of performance constraints you have, C might be fine Mar 22 00:42:34 just be aware that it probably won't make efficient use of the pru cores Mar 22 00:42:55 it's just a hobby project so as long as it's reasonably controllable it should be fine Mar 22 00:44:37 huh Mar 22 00:44:52 uio-pruss actually works fine for me with 4.9.83-ti-r105 and the latest overlays Mar 22 00:45:10 interesting Mar 22 00:45:20 I actually had to install the overlays from git though... the debian package resulted in an unbootable system :-/ Mar 22 00:45:30 that's bizarre Mar 22 00:45:42 so which python script loads fw files? Mar 22 00:46:17 all of them load firmware, but the elf-test is the only one that loads a firmware file produced by clpru Mar 22 00:46:21 the rest of the examples use pasm Mar 22 00:46:47 (pasm produces raw binaries, clpru produces ELF executables) Mar 22 00:47:07 pruss-test doesn't seem to return Mar 22 00:47:37 hum something is still wrong here Mar 22 00:48:00 so can I pass a specific binary to one of the scripts? Mar 22 00:48:23 do I need to do the uio_pdrv_genirq stuff too? Mar 22 00:48:29 no you can ignore that Mar 22 00:48:49 and the example scripts hardcode the firmware path: https://github.com/mvduin/py-uio/blob/master/pruss-elf-test.py#L13 Mar 22 00:49:02 pruss-ddr-ping is good Mar 22 00:49:19 intc is good Mar 22 00:50:12 errr I think, just keeps giving Event 17 Event 17 Event 16 Mar 22 00:50:16 okay I take it back, 4.9-ti doesn't work fine for me... it just *seemed* to load fine Mar 22 00:50:22 yes that's what it's supposed to do Mar 22 00:50:30 both pru cores are periodically sending an event Mar 22 00:50:34 and the script is receiving those Mar 22 00:51:57 note that to test your pru output you can also just do something like: https://pastebin.com/4rCamUXw Mar 22 00:52:38 as long as the core is halted you can directly meddle with its registers like that :) Mar 22 00:59:21 holy shit it works Mar 22 01:01:11 so then when I want to load my own firmware, just use your test scripts as a reference for loading a specific binary file? Mar 22 01:02:05 yes Mar 22 01:03:57 "write extends beyond mappable area" Mar 22 01:04:09 huh Mar 22 01:04:24 that's when trying to use my own fw compiled from CCS Mar 22 01:04:44 might be a bug in my ELF loader... can you send me your executable somehow? Mar 22 01:05:11 is .out a binary or an .elf? Mar 22 01:05:22 .out is an ELF executable Mar 22 01:05:30 okay one sec Mar 22 01:05:34 if it weren't, elf_load would complain Mar 22 01:05:57 you're using pruss.elf_load right? Mar 22 01:07:22 I am now, yeah Mar 22 01:07:24 e.g. if the script requires no interaction with pru other than loading the program, you can do something like https://pastebin.com/1fF81wKS Mar 22 01:07:41 was using core.iram.write before Mar 22 01:07:46 lol Mar 22 01:07:56 tried to write the whole contents of the ELF executable into iram Mar 22 01:08:08 that's not going to work :) Mar 22 01:08:37 https://pastebin.com/rYjhQS8b Mar 22 01:09:40 just replaced filename in pruss-elf-test.py Mar 22 01:09:40 keep in mind lines 24-25 cause the python script to use 100% cpu load as long as the pru program is running Mar 22 01:10:03 (this wasn't a problem for the original elf-test since the pru program halts immediately) Mar 22 01:10:42 interestingly enough the output was : Mar 22 01:10:44 41 waiting for core to halt 42 Mar 22 01:10:54 eh Mar 22 01:11:18 but my code is supposed to toggle P8_11, so not sure what's going on there Mar 22 01:11:39 that's pretty weird Mar 22 01:12:17 going to try some assembly Mar 22 01:12:20 almost sounds like it didn't load anything Mar 22 01:15:31 https://github.com/beagleboard/am335x_pru_package Mar 22 01:15:37 is this the best place to get pasm? Mar 22 01:16:01 yes Mar 22 01:16:28 just compile it from source and install in /usr/local/bin Mar 22 01:16:44 usage: pasm -V3 -b source.pasm Mar 22 01:18:40 to install, do I just move the 'pasm' file to that location? Mar 22 01:18:53 yes Mar 22 01:19:40 then use the binary loader for this guy right? Mar 22 01:20:19 yes, pasm binaries should simply be written into iram Mar 22 01:20:53 woo, I found and fixed the issue with 4.9-ti Mar 22 01:21:00 it wasn't a 3-line fix in the dts Mar 22 01:21:04 it's a one-line fix in the overlay Mar 22 01:24:40 woohoo! assembly is working Mar 22 01:24:45 oh nice! Mar 22 01:24:58 what are the main differences between -ti and -bone? Mar 22 01:25:07 remoteproc-pru? ;-) Mar 22 01:25:12 lol Mar 22 01:25:35 I'm actually not sure, the -ti kernels generally contain patches specific to TI SoCs that haven't reached mainline linux yet Mar 22 01:25:52 so they may for example have better power management Mar 22 01:26:24 another difference is that -bone targets the beaglebone specifically while -ti is a more general kernel that's also for the beagleboard-x15 Mar 22 01:26:47 got it Mar 22 01:27:48 btw if you want a nice overview of all PRU pins, check the PRU tab of my am335x pins spreadsheet -> https://goo.gl/Jkcg0w Mar 22 01:28:19 I've mailed the fix to rcn btw, so hopefully uio-pruss will be working by default soon Mar 22 01:33:39 wow, that's pretty phenomenal Mar 22 01:34:36 yeah email is awesome Mar 22 01:34:41 oh that's probably not what you meant ;) Mar 22 01:35:16 well, both I suppose Mar 22 01:46:40 hello, beaglebone green, web interface is not working. it say "index of/" and thenhave Apache version Mar 22 02:07:04 i got it, port 8000 Mar 22 02:22:37 use BB Blue for 2 stepper motors, possible? If yes how? Mar 22 02:30:47 what kind of interface do they have? Mar 22 02:46:41 the stepper motors has its own Driver. Mar 22 02:47:23 I mean what kind of control interface Mar 22 02:50:38 ok. BB blue to send pulse (CW / CCW) to the motor Driver, in turn driver will active the motor accordingly Mar 22 02:51:08 CW and CCW are separate signals? Mar 22 02:55:08 Seperate signal Mar 22 02:56:04 sounds pretty trivial to produce using gpios, so no problem Mar 22 02:59:02 OK. Sound Good to me too, bb blue GPIO? Mar 22 02:59:11 ? **** ENDING LOGGING AT Thu Mar 22 03:00:02 2018