**** BEGIN LOGGING AT Tue Jun 04 03:00:19 2019 Jun 04 03:00:32 (and SDIO and HCI, also v2.00) Jun 04 03:01:16 actually that's the am335x, I should have checked the am57xx Jun 04 03:01:56 it claims full compliance with physical layer v3.01, SDIO v3.00, HCI v3.00 Jun 04 03:04:35 What broadcom chip is being used, exactly? For the AI? Jun 04 03:05:01 same model as teh pi, just a module from a 3rd party, vs from broadcom directly.. Jun 04 03:05:07 Oh. Jun 04 03:05:09 Got it. Jun 04 03:05:42 44235 or _____? Forget it. I will go to the Pi to look around. Jun 04 03:06:46 So, it's the AP6255 from the current pcb.. Jun 04 03:07:08 Which is the : BCM43455 1T1R (802.11abgn/ac) Jun 04 03:07:43 Oh. Jun 04 03:08:01 but that might have got swapped to another 3rd party, since that pdf was printed.. same bcm43455 internal thou.. Jun 04 03:08:18 So, what does the debian people say about this chipset? Jun 04 03:08:43 let's just say, broadcom/cypress have approved "3rd party module vendors" and then others that also got chips.. Jun 04 03:08:44 I thought I would poke around in their ideas (forum/wiki) for ideas. Jun 04 03:09:23 Is cypress about to get bought out? Jun 04 03:09:37 Infereon or something like that is looking to purchase their bid on cypress. Jun 04 03:10:10 yeap, i forgot to bug my co-worker on that today.. that's going to mess some things up.. Jun 04 03:10:14 Anyway...I want to see what debian people are saying about the chipset being used so far. Jun 04 03:10:16 Right? Jun 04 03:10:41 Co's change all things off the bat or in time. Jun 04 03:10:52 so most of the comments on that chipset are related to teh PI, and the Khadas Vim Amlogic S905 Jun 04 03:11:26 https://wiki.debian.org/WiFi is where I thought I would snoop around. Jun 04 03:11:27 well, i was helping out on a project for cypress... Jun 04 03:11:52 Oh. Jun 04 03:11:55 (psoc6 ble project) Jun 04 03:12:08 What happened? Jun 04 03:12:59 Well they got bought out... as to the project, it's up in teh air.. Jun 04 03:13:58 No! Jun 04 03:14:47 set_: found it, here's teh current bbai brcm issue: Jun 04 03:14:56 * rcn-ee[m] sent a long message: < https://matrix.org/_matrix/media/v1/download/matrix.org/FSLwjgGYWkxmrjtRmNOtzvWP > Jun 04 03:15:19 Aw...let me look around and poke, poke, poke. Jun 04 03:16:13 i need to test the updated (as of today) firmware, so maybe we will have something different tomorrow. Jun 04 03:16:43 Oh. Okay. I will look up some info. in my spare time if things get worse or more awkward on your side. Jun 04 03:19:07 Are you testing on 4.14.x "firstly?" Jun 04 03:41:59 sdio isn't that bad Jun 04 03:44:30 anyone tried putting it on a logic analyzer? Jun 04 03:45:06 I asked about 4.14.x "firstly" b/c I found on github.com a bunch of item relating to that chip on the Pi and issues w/ third party software. Jun 04 03:46:29 https://github.com/raspberrypi/linux/issues/2453 is one thing I found for starters. Besides that idea, I am out for the night. Jun 04 03:46:35 I will reconvene later on the issue. Jun 04 05:16:53 for giggles, i tried to get https://github.com/toroidal-code/PixelBone going, but a lot has changed in the 5 years since it's been abandoned Jun 04 05:17:15 it does not work on modern beagles, alas. mostly due to dtb issues Jun 04 06:42:15 rcn-ee[m]: so if I understood correctly, you were going back and forth with zmatt about how to automatically detect which root fs was the appropriate one to potentially resize-to-fill? couldn't tell whether that came to a resolution or not **** BEGIN LOGGING AT Wed Jun 05 03:20:09 2019 Jun 05 03:20:38 Ok, I am back. So, just to be in the same page Jun 05 03:20:54 Do you still need some information from my Beaglebone? Jun 05 03:23:36 The issue was the overlay. Forget what I asked. Jun 05 03:26:33 Skal: I think those people are reviewing the library. Jun 05 03:27:30 Skal: Have you taken your BBBlue into the air yet? Jun 05 03:27:58 What do you mean? Jun 05 03:28:06 As a drone or uav? Jun 05 03:28:41 Not yet, I don't think I am capable of such Jun 05 03:28:51 Oh. Same here. I keep trying, though. Jun 05 03:29:05 I have ground control "cornered" but flight is difficult. Jun 05 03:29:37 The control theory must be beyond my understanding Jun 05 03:30:02 Oh. Yea. Lots of lines of nonsensical listings/source and then it works or fails. Who knows/ Jun 05 03:30:20 Sometimes, understanding is half the battle. Jun 05 03:31:20 So, did you get your encoder terminal attachments from a particular place or did you somehow figure out how to solder them or crimp them? Jun 05 03:31:44 I am a pursuing a bachelor degree in computer science. We have a robotics team in my university, that I take part., the Control and Automation Engineers must know better Jun 05 03:31:59 Oh. Okay. No issue. Jun 05 03:32:15 Well Skal: I hope those two can get back to you later. Jun 05 03:32:21 Wait, I was talking about the drones Jun 05 03:32:25 Remember, please stay patient. Jun 05 03:32:26 Oh. Jun 05 03:33:33 the solder we made was with a female kk conector Jun 05 03:33:41 does this make sense in English? Jun 05 03:34:05 Oh. Jun 05 03:34:16 kk connecter? Jun 05 03:34:20 Molex kk Jun 05 03:34:22 yes Jun 05 03:34:24 Like...oh. Jun 05 03:34:36 Okay. Yea. I get it. It was a type of connector. Jun 05 03:34:44 Molex type brand. Jun 05 03:35:05 Crimping them must have been a pain. Jun 05 03:35:05 we made a wire-wire using molex kk connecters Jun 05 03:35:11 Oh. Jun 05 03:35:21 It was haha Jun 05 03:35:23 Ha. Jun 05 03:35:41 What is your solution? Jun 05 03:35:54 Those connectors are small tiny. It is even hard to get them soldered properly. Jun 05 03:36:17 Impossible, most likely. Jun 05 03:36:42 Skal: I am using ArduCopter to work w/ flight/drone stuff. Jun 05 03:37:05 I left it alone for a bit again. I am waiting to get this BBBlue flying like a bird. Jun 05 03:37:35 I have two more connections to try. After those connections, I am calling it quits. Jun 05 03:37:58 Skal: does running rc_test_encoders work? Jun 05 03:38:30 does running it ahead of the node program work-around the bug? Jun 05 03:39:32 preassembled cables are a blessing set_ Jun 05 03:39:52 Let me double check Jun 05 03:40:32 Oh yeah, I have does preassembled. The other end is the one I connect to the Molex Jun 05 03:49:24 So, I made the tests Jun 05 03:49:40 When I run rc_test_encoders Jun 05 03:49:48 id does not show me any errors Jun 05 03:50:30 And if I stop executing it, and try to execute the node. The node still pop ups the error Jun 05 03:51:31 Even when trying to execute together, rc_test_motors and the node program, the node still without being able to read the pru Jun 05 03:52:20 Blessing...yes. Jun 05 03:55:13 still unable to read the pru** Jun 05 04:01:44 maybe typing up a "/bin/echo pruecapin_pu >/sys/devices/platform/ocp/ocp:P8_15_pinmux/state" could help? Jun 05 04:02:08 Like in a .sh file. Jun 05 04:06:02 I was timeout again, did I miss anything? Jun 05 04:07:21 Hey Skal: Sometimes writing to the pru can help. Jun 05 04:08:20 See here: /bin/echo pruecapin_pu >/sys/devices/platform/ocp/ocp:P8_15_pinmux/state Jun 05 04:08:29 Have you tried that idea? Jun 05 04:08:48 What is this doing? Jun 05 04:08:58 That should work w/ sysfs on the 4.14.x kernel. Jun 05 04:09:03 What kernel are you using? Jun 05 04:09:58 one sec Jun 05 04:10:04 Okay. Jun 05 04:10:16 uname -r? Jun 05 04:12:11 4.14.94-ti-rt-r95 is my kernel but that command should work. Jun 05 04:14:17 Tried your approach Jun 05 04:14:37 doesn't seen that have done anything Jun 05 04:14:56 Okay. Jun 05 04:15:10 Oh. Jun 05 04:15:21 Please hold. I know what you did versus what I was saying before you left again. Jun 05 04:15:31 let me pastebin.com it. Jun 05 04:17:21 Ok Jun 05 04:20:30 https://pastebin.com/WPE1yneS is what to use in a file at the /usr/bin directory. Jun 05 04:21:50 Then...use chmod a+x So, for instance, chmod a+x pru.sh. Jun 05 04:22:24 Or...however you use your permissions. Jun 05 04:24:12 I did this Jun 05 04:24:21 It doesn't do anything Jun 05 04:24:51 So, you have that file and set your permissions? Jun 05 04:25:22 in the /usr/bin/ dir? Jun 05 04:25:25 yes Jun 05 04:26:09 What kernel are you using? Jun 05 04:26:45 Oh! Jun 05 04:26:55 You have to create and .service file to make it run on boot. Jun 05 04:27:07 and = a Jun 05 04:29:08 and under [Service], type ExecStart=/usr/bin/pru.sh Jun 05 04:29:18 Do you mess w/ .service files at all? Jun 05 04:29:27 4.14.71-ti-r80 Jun 05 04:29:30 Okay. Jun 05 04:29:35 No Jun 05 04:29:39 haha Jun 05 04:29:40 Okay. Jun 05 04:29:43 No issue. Jun 05 04:29:57 Please hold. I will pastebin a .service file for you to use. Jun 05 04:29:58 But when I said that the command doesn't do anything Jun 05 04:30:02 Yea? Jun 05 04:30:03 I meant that it is executed Jun 05 04:30:10 Okay. Jun 05 04:30:13 but when I try to execute the code Jun 05 04:30:24 it doesn't change there can't read pru error Jun 05 04:30:31 So, the file is green! Right. I can be executed now. Jun 05 04:30:32 Oh. Jun 05 04:31:06 Let us try a .service file for this .sh script and maybe, just maybe, it will work. Jun 05 04:32:13 where is .service located? Jun 05 04:32:38 Here: /etc/systemd/system Jun 05 04:34:42 I have to create a new .service? Jun 05 04:34:47 https://pastebin.com/wHfZ4f38 is the .service file. So, call it pru.service. Jun 05 04:35:15 And...rename that file from pru.sh to pru w/out the .sh file ending. Jun 05 04:35:23 Reboot. And that should be it. Jun 05 04:38:27 Oh and Skal: Did you look in your /boot/uEnv.txt file? Look for your PRU-RPROC-4-14-TI and make sure it is that one that is w/out the comment, i.e. "#". Jun 05 04:41:36 I haven't looked yet Jun 05 04:41:38 let me see Jun 05 04:41:44 Okay. Jun 05 04:43:13 what do you mean by that? Jun 05 04:43:46 I have these lines Jun 05 04:43:46 #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo Jun 05 04:43:55 uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo Jun 05 04:44:00 Okay. Jun 05 04:44:09 #uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo Jun 05 04:44:10 See the one w/out the # in front. Jun 05 04:44:21 yes Jun 05 04:45:09 Okay. If you plan on using RPROC, keep that # out. If you want to use the PRU-UIO, remove the # and put a hash at PRU-RPROC. Jun 05 04:45:15 That is all. But, things look good. Jun 05 04:45:44 Are you planning on using RPROC instead of UIO? Jun 05 04:46:02 I don't know the difference Jun 05 04:46:21 Me neither. I do not use pru that often but I have found out how to enable it for use. Jun 05 04:46:30 Now! Jun 05 04:46:33 Get this. Jun 05 04:46:50 You still need to enable and start your .service file. Jun 05 04:46:55 I know...tiring. Jun 05 04:47:22 Like so... Jun 05 04:47:22 how do I enable it? Jun 05 04:47:27 I have already created Jun 05 04:47:47 systemctl enable pru.service Jun 05 04:47:56 systemctl start pru.service Jun 05 04:48:07 systemctl status pru.service Jun 05 04:48:14 That should be it. Jun 05 04:48:32 What does your prompt tell you after you type this: systemctl status pru.service. Jun 05 04:49:01 Failed to enable unit: The name org.freedesktop.PolicyKit1 was not provided by any .service files Jun 05 04:49:08 Heh? Jun 05 04:49:10 At the enable Jun 05 04:49:30 Where are you from? Jun 05 04:49:39 Brazil? Jun 05 04:49:58 at the /boot/ Jun 05 04:50:03 oh Jun 05 04:50:04 yes Jun 05 04:50:06 Okay. Jun 05 04:50:08 hahaha Jun 05 04:50:20 Maybe it is illegal or something. I have no idea about your laws. Jun 05 04:50:27 That is odd. Jun 05 04:50:43 Send me some pastes as to what you did, please. Jun 05 04:51:27 I mean. That should have enabled the pru on the BBBlue. Jun 05 04:51:48 wait Jun 05 04:51:52 Okay. Jun 05 04:51:53 it worked Jun 05 04:51:56 Oh? Jun 05 04:51:59 needed sudo Jun 05 04:52:02 Aw! Jun 05 04:52:04 Yea. Sudo! Jun 05 04:52:10 b/c of systemctl. Jun 05 04:52:12 Oops. Jun 05 04:52:43 now, what does status show, e.g. sudo systemctl status pru.service? Jun 05 04:53:06 http://paste.debian.net/1086185/ Jun 05 04:53:46 it says inactive. Try to reboot. Jun 05 04:54:01 Oh! Jun 05 04:54:02 ok Jun 05 04:54:05 Hey...wait. Jun 05 04:54:10 waiting Jun 05 04:54:13 Did you reboot yet? Jun 05 04:54:17 no Jun 05 04:54:27 Okay, try this command too. Jun 05 04:54:33 sudo systemctl deamon-reload. Jun 05 04:54:40 if I reboot I will disconnect from the irc Jun 05 04:55:01 Um...if you reboot your bbblue, will you disconnect from irc? Jun 05 04:55:23 yes, using its internet Jun 05 04:55:27 Oh. Jun 05 04:55:39 Okay. I will wait. Jun 05 04:55:42 Unknown operation deamon-reload Jun 05 04:55:54 daemon-reload. SOrry. Jun 05 04:56:02 a before e. Jun 05 04:56:26 service still inactive Jun 05 04:56:33 reboot. I will wait. Jun 05 04:56:59 Hey Skal: I will brb. Reboot and I will check on it. Jun 05 04:57:06 ok Jun 05 04:59:18 Still inactive Jun 05 05:02:32 Still. Jun 05 05:04:38 Are you using a battery yet? LiPo? Jun 05 05:05:28 not yet Jun 05 05:05:42 Okay. Jun 05 05:05:56 I think you may have to use a LiPo to test it. Jun 05 05:06:05 So, let me get this idea. Jun 05 05:06:50 You have four motors, in need of a battery (LiPo), and those commands I gave do not work? Jun 05 05:07:14 Thinking of the last part about the commands. Jun 05 05:07:28 yes Jun 05 05:07:35 Paste in pastebin.com the pru file and name how you have the file listed, please. Jun 05 05:07:59 commands didn't change the encoder read Jun 05 05:08:43 Oh. Jun 05 05:08:56 You are testing it w/ software still? Jun 05 05:08:59 Unknown operation deamon-reload Jun 05 05:09:04 a before e. Jun 05 05:09:10 i.e. daemon-reload. Jun 05 05:09:11 wait Jun 05 05:09:30 Okay. Jun 05 05:09:55 Wrong ctrl v Jun 05 05:09:57 http://paste.debian.net/1086186/ Jun 05 05:10:07 This is what I intended Jun 05 05:10:25 What do you mean by testing with the software still? Jun 05 05:10:56 test Jun 05 05:11:11 this is at /usr/bin/ and is named just pru Jun 05 05:11:16 Okay. Jun 05 05:11:53 Okay. Try sudo systemctl daemon-reload and then try to run that command for making your motors move when the battery is plugged in. Jun 05 05:13:22 Ok, I would not be able to do this today Jun 05 05:13:30 I don't have the lipo with me Jun 05 05:14:07 Dang! Jun 05 05:15:12 Skal: I do not have this library installed. Let me install it real quickly. Jun 05 05:20:19 curious - how do people synchronize encoders in userspace w/o RT? Jun 05 05:20:58 Ut oh. Jun 05 05:22:09 Good question. I have RT. Maybe Skal needs a RT kernel. Jun 05 05:22:58 I do not have python installed on my machine. I forgot. I have a console image. Jun 05 05:26:24 set_: even with RT, how are you doing it? Jun 05 05:26:36 Or are you moving things very slowly? Jun 05 05:26:57 I can't imagine using this on a 3 axis mill with more then a few IPM's of motion if even that Jun 05 05:27:43 Oh. I think this fellow is moving a for wheeled bot or something. Jun 05 05:28:49 Me, on the other hand, I do not know. Jun 05 05:29:10 I read online about some people using a RT kernel to make flying BBBlues. Jun 05 05:29:20 So, that is what I have attempted. Jun 05 05:29:25 Failed...yes. Jun 05 05:29:31 Still at it...yes. Jun 05 05:31:05 set_ Jun 05 05:31:07 I mean. I can use UART, or GPIO, but I have not been able to make things move w/ three-phase motors yet. Jun 05 05:31:08 Yes? Jun 05 05:31:11 taks for your help Jun 05 05:31:18 No issue. Jun 05 05:31:29 I had enough for today haha is too late here in Brazil Jun 05 05:31:42 I know. I am beat in the USA. Late! Jun 05 05:32:07 set_: moving is one thing.... coordinating is another and that's the point of encoders Jun 05 05:33:16 Oh. The fellows from ardupilot state they can do it. I followed along to make things move. I cannot blame them yet but the ideas were many. Jun 05 05:33:17 ... Jun 05 05:33:42 ds2: Yaw, left, right, roll, loiter, and so on... Jun 05 05:34:23 My motors were not receiving power. I blamed my ESCs and moved on. Jun 05 05:35:31 Now, I am back at it like I never left. Jun 05 05:35:39 For encoders. Jun 05 05:36:10 I am clueless. I have never once used an encoder. Not even w/ Adafruit_BBIO's eqep or whatever they had listed. Jun 05 05:36:14 It is a shame too. Jun 05 05:36:32 Now, their software no longer works w/ the new kernel. Jun 05 05:36:51 4.14.x is as far as it goes w/ their support. I think. Jun 05 05:44:25 Skal: I probably sent you down the wrong path. My bad. I hope things work out w/ that software. Jun 05 06:49:10 Hello chat, noob question: I just updated the emmc memory of the board to the latest LXQT image of debian 9.5 using this https://medium.com/@zageollc/updating-the-software-image-on-a-beaglebone-black-fc73ffcc700 link Jun 05 06:49:37 My question is do I need to recomment the line the tutorial had me to uncomment? It seems like the system is a "deep freeze" where you cannot actually save your changes Jun 05 06:52:07 randyjohnson86: the image you downloaded, did the file name contain the word "flasher"? Jun 05 06:52:40 no, it did not Jun 05 06:52:56 then the editing step is likely required Jun 05 06:53:17 and you need to edit the file as 'root' not as the 'debian' user Jun 05 06:53:35 if you try as 'debian' then it won't allow you to save Jun 05 06:53:45 right, I've done all of that; the image has successfully transferred over from the sd card into internal Jun 05 06:54:27 so what is your specific problem? Jun 05 06:54:36 so booting up without sd card, it loads into the image I just transferred. my question is, is it possible for the internal memory to save changes? or is it stuck on a single instance of the image? Jun 05 06:55:00 the eMMC is read write storage Jun 05 06:55:26 if you log in as user 'debian' then you can write to (mainly) /home/debian Jun 05 06:55:40 from the get go? it doesn't require anything to be changed? Jun 05 06:56:35 because on my previous attempt, it would've save anything. I changed the clock, and after restarting, it was off again Jun 05 06:56:47 I thought perhaps I had done something wrong when writing the image to the eMMC Jun 05 06:58:27 randyjohnson86: the BBB doesn't have a battery backed RTC by default, it relies on network connectivity to set the time automatically. This meaning Ethernet or Wifi, not USB-networking. Jun 05 07:00:11 okay, that makes sense. Jun 05 07:07:30 if you reboot with power still connected, it will keep the time in the internal RTC Jun 05 07:08:29 set_: Yaw, left, right, loiter, etc are not directly correlated to a motor Jun 05 07:08:45 whereas an encoder is suppose to move and update quickly Jun 05 07:08:58 okay, thank you for the help tbr Jun 05 07:10:38 np Jun 05 08:05:31 Hello all. Do some older bone blacks have 2G eMMC? I tried to flash a current 4G image and got a full error. An older 2G image worked. Jun 05 08:43:07 yes Jun 05 09:09:32 thanks, any recent 2G images availables? Jun 05 09:14:09 the console image might fit Jun 05 09:14:25 or you just ditch the eMMC, wipe it and boot from SD-card Jun 05 09:25:50 I thought I had just the console image. I want the SD card slot to run RTEMS. I am after a recent u-boot as I test u-boot master with gcc 7 and later. Jun 05 09:41:57 kiwichri_: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian Stretch Snapshot console Jun 05 09:42:00 2019-06-02 Jun 05 09:42:12 Stretch Snapshot console Jun 05 09:42:22 bone-eMMC-flasher-debian-9.9-console-armhf-2019-06-02-1gb.img.xz Jun 05 09:42:32 looks suspiciously like it should fit Jun 05 10:00:52 Oh nice. That looks perfect. I will try it tomorrow. Many thanks. Jun 05 10:01:26 np Jun 05 17:03:05 jkridner[m]: well this is interesting, I just found two distinct (based on mac address and eMMC CID) beaglebones in our database that have the exact same serial number in EEPROM Jun 05 17:04:13 wait that shouldn't be possible, I must have fucked something up Jun 05 17:04:42 or not Jun 05 17:04:54 nope, definitely two beaglebones with the same serial Jun 05 17:05:14 whoa.... maybe you or maybe manufacturer? Jun 05 17:05:20 yikes. GHI or Embest? Jun 05 17:08:02 see private message for the details Jun 05 17:11:16 I have no idea whether it's GHI or Embest but hopefully you can tell from this info Jun 05 17:14:23 zmatt: IIRC, isn't the silkscreen slightly different and enough to say who is it from? Jun 05 17:14:58 these are beaglebones that have been integrated into products Jun 05 17:15:20 so I have no way to examine them anymore :P Jun 05 17:17:23 jkridner[m]: well, time to drop the "UNIQUE" constraint on that database column I guess :P I'm glad I chose to also log other identifiers such as the mac address Jun 05 17:27:49 :-( Jun 05 18:29:13 quick question, Jun 05 18:29:45 i am new to ethernet connected devices and have a question about the feasibility of using a BBB as the central controller for an automated system Jun 05 18:30:34 my goal is to utilize the BBB to control a number of Teknic motors (https://www.teknic.com/products/clearpath-brushless-dc-servo-motors/clearpath-sc/) Jun 05 18:31:24 then utilize an Ethernet/IP enabled IO block to field IO signals from other equipment and sensors. Jun 05 18:31:52 The Ethernet/IP enable IO block would be similar to this (https://www.automationdirect.com/adc/shopping/catalog/field_i-z-o/protos_x_i-z-o/protos_x_i-z-o_bus_couplers/px-eip1) Jun 05 18:32:53 so far you've not described anything that seems to require anything but a random system that happens to have an ethernet port Jun 05 18:36:10 The system will utilize a BBB to control an automated pick and place machine that is driven using the motors i mentioned. Typically, industrial signals i deal with utilize 24VDC which is well above the rated input for the BBB. My question, is it feasible to utilize the Ethernet communication functionality of the BB to communicate with an Ethernet/IP enabled industrial IO block? Jun 05 18:38:15 I'm not really familiar with Ethernet/IP, but as far as I can tell it's a protocol suite on top of plain ethernet hence it would not require any special hardware, just a suitable software stack Jun 05 18:43:14 although I do see that apparently there's PRUSS firmware for creating Ethernet/IP slave nodes (using PRUSS MII-RT, which therefore would not work on the beaglebone) suggesting it may be more time-sensitive than can be provided for by a general-purpose OS, but it's possible that's only true for slaves and not for the master Jun 05 18:43:56 the fact there's an open-source stack for Ethernet/IP that runs on linux and windows suggests it shouldn't be a problem Jun 05 19:26:34 =( Jun 05 19:28:58 Skal: if you want a potential quick-fix for your problem, just try adding rc_encoder_init(); near the call to rc_initialize(); in the node module's source code and recompile it Jun 05 19:29:34 Can you give me more info, on doing this, I have never changed a node module before Jun 05 19:30:56 clone the git project, modify the source code, then do "npm i" Jun 05 19:42:36 So, I do nom I inside the git repo? Jun 05 19:42:41 and it should work? Jun 05 19:56:39 npm i Jun 05 19:57:29 short for npm install, which doesn't actually install anything but (when invoked without arguments) will grab all dependencies (compile them if necessary) and build the module Jun 05 22:12:12 Hi, so I tried the quick fix of adding the rc_encoder_init(); right below the rc_initialize(); code Jun 05 22:12:44 Now it doesn't complain anymore, but it doesn't work neither Jun 05 22:12:59 The encoder value keeps changing between one and zero Jun 05 22:14:39 strange Jun 05 22:14:48 the c++ example does work? Jun 05 22:17:27 let me double check it Jun 05 22:21:50 zmatt: The BBBK doesn't clearly indicate which manufacturer. Can you say which it is? Jun 05 22:22:14 also, what does the on-board barcode say? Jun 05 22:22:52 don't the mfgs use different s/n spaces? Jun 05 22:23:14 yes, they should, per https://github.com/jadonk/beagle-tester Jun 05 22:23:15 jkridner[m]: these beaglebones were integrated into products long ago and almost certainly sold Jun 05 22:23:27 so I can't examine them physically for you anymore Jun 05 22:23:39 oh. Jun 05 22:23:57 might be CCo. :-/ Jun 05 22:24:22 when in doubt, blame it on ... ;) Jun 05 22:24:45 I do have plenty of BBBs around though... I think we've mostly stuck with the same reseller (but I'd need to check that) Jun 05 22:25:10 also the information on the barcode is the "mserial" field in my note (the same info is also in eeprom) Jun 05 22:27:30 jkridner[m]: btw, rc_initialize() indeed doesn't cover the pru-encoder, just the eqep ones: https://github.com/StrawsonDesign/librobotcontrol/blob/master/library/src/deprecated.c Jun 05 22:30:10 does remoteproc-pru not offer a way to map pru shared memory? I noticed librobotcontrol still uses /dev/mem, which is gross and forces the use of root privileges Jun 05 22:31:09 maybe I should send them a patch to use uio-pruss instead, which doesn't suffer from this problem :P Jun 05 22:38:41 no, remoteproc doesn't currently provide a way to memory map. /dev/mem is used. Jun 05 22:39:04 a uio patch on remoteproc is what we want, I feel. Jun 05 22:39:09 lol, uio-pruss ftw Jun 05 22:39:45 a better userspace library is all that uio-pruss needs Jun 05 22:58:33 why not create a proper /dev char that exposes what you need? Jun 05 22:58:55 just use a misc major Jun 05 22:59:08 took an hour so when I had to do a quick hack to expose video from the PRU Jun 05 23:14:03 because "what you need" is different for every pru application Jun 05 23:15:31 and people take the path of least resistance... if there's no convenient way to map shared memory without root privileges, they'll just use /dev/mem and force all users to use root privileges, as librobotcontrol demonstrates Jun 05 23:24:09 zmatt, so I ran the c++ scripts rc_test_enconders and rc_test_encoders_pru Jun 05 23:24:41 and the value is changing between one to zero too Jun 05 23:26:52 are you sure the test signal is okay? e.g. if one of the two signals isn't coming through (e.g. broken wire) then alternating between two values is exactly what you'd get Jun 05 23:28:11 the same cable works with the first, second and third encoder port Jun 05 23:28:17 hmmm Jun 05 23:30:42 try using (the blue version of) my show-pins script to check on the pinmux for the encoder pins: https://github.com/mvduin/bbb-pin-utils/tree/blue#show-pins Jun 05 23:31:40 after install just do sudo show-pins | grep E4 Jun 05 23:33:14 can it be an issue with the lib robotic control version Jun 05 23:33:42 I have no idea. I don't have a blue and never used librobotcontrol Jun 05 23:34:00 so I'm just trying to narrow the issue down Jun 05 23:34:41 since the signal works for other encoder inputs, it seems safe to assume it arrives correctly on the processor pins Jun 05 23:35:07 so that leaves 1. wrong pinmux 2. broken pru firmware 3. an issue in librobotcontrol Jun 05 23:35:19 1 is easiest to check Jun 05 23:37:00 right, checking onw Jun 05 23:37:03 one* Jun 05 23:57:52 hello everyone, I am reading about flashing a new image to my BBB Jun 05 23:58:52 if I download the flasher image, do I need to still modify the boot/uEnv.txt file? Jun 05 23:59:09 nope, just grab the flasher image, write it to sd card, and boot the BBB from it Jun 05 23:59:28 great, that's what I was hoping Jun 05 23:59:51 I still need to decompress it before writing, correct? Jun 05 23:59:55 modifying /boot/uEnv.txt is how a normal image can be turned into a flasher (and vice versa), but both types of image are now available for convenience Jun 06 00:00:10 not if you use etcher, it'll do it on the fly Jun 06 00:00:38 no, I'm using linux Jun 06 00:01:04 so then I'm assuming that means yes :) Jun 06 00:01:05 I mean, etcher is available for mac, windows, and linux Jun 06 00:01:20 true, but i like dd Jun 06 00:02:04 I mean, you could also just xzcat FILE >/dev/sdb or whatever the device it Jun 06 00:02:55 ooh that's a good idea, I'll do that Jun 06 00:03:18 just keep in mind that an sd card is not the most reliable form of storage, a common failure mode of worn-out cards is random bit flips in some sectors, which is an unfortunate thing if those are subsequently copied onto the target system Jun 06 00:03:30 hence verifying after writing the image to sd card is kind of a good idea Jun 06 00:04:04 i have a brand new one, so that shouldn't be an issue. if I want to check it anyway, would I just use shasum? Jun 06 00:05:37 yeah you can use that, but keep in mind that you'll need to shasum only as many bytes of the card as the size of the image, not the entire card Jun 06 00:06:57 is there a different way of doing it? Jun 06 00:08:35 just decompress the image and use bs=4M oflag=direct for writing and then read it again with bs=4M iflag=direct and a suitable count, with the output piped to md5sum or sha256sum Jun 06 00:09:07 or use etcher :P Jun 06 00:14:14 alright, well I think I'll try the command line first and see how it goes Jun 06 00:14:18 thanks for your help :) Jun 06 00:16:46 though to be fair, with a new card I might not bother with verification myself ;) Jun 06 00:17:01 I ought to though Jun 06 00:19:37 I'm in no rush, I'll see how good of an sd card this is Jun 06 00:45:51 alright, well I couldn't figure out how to check the image, so time to flash it! **** ENDING LOGGING AT Thu Jun 06 02:59:57 2019