**** BEGIN LOGGING AT Tue Feb 20 03:00:03 2018 Feb 20 03:53:27 finally cleaned up your uio git zmatt? XD Feb 20 04:05:15 yeah, since I added some pruss stuff to help people uit Feb 20 04:43:12 zmatt: /buffer #tor Feb 20 04:43:14 whaoitsaelkjf Feb 20 04:43:15 fuck Feb 20 04:43:17 sorry Feb 20 04:43:23 zmatt: Yes, I was mistaken. Feb 20 04:43:30 Thanks for the clarification/. Feb 20 04:44:34 I had been looking at a table on the SD card consortium (or whatever it is called) website and they showed SDXC cards being incompatible with SDHC controllers. But I see now the caveat is with the filesystems SDXC supports. Feb 20 04:45:00 However, there is something else - some SDXC cards are of U1 speed. So the Beagle definitely won't be giving those high speeds, I suppose. Feb 20 04:47:05 "U1" is a speed class, it guarantees the ability to write 10 MB/s continuously under very specific operational circumstances (in particular requiring exFAT in case of SDXC) Feb 20 04:47:20 you probably mean UHS-I Feb 20 04:47:47 Perhaps. I get mixed up between the different terminology. Feb 20 04:48:17 which the beaglebone indeed does not support Feb 20 04:48:25 yes the terminology is a big mess Feb 20 04:48:58 and the sd consortium is doing an excellent job at making things as confusing as possible Feb 20 04:49:33 I like F2FS for flash devices. Feb 20 04:50:17 I think the SD consortium should recommend a non-encumbered filesystem as default instead of this exFAT mess. Feb 20 04:52:08 I'm pretty sure F2FS is way too complicated to be a candidate for what the SD consortium needs Feb 20 04:52:28 and it's gpl, which is a non-starter for the companies on the SD consortium Feb 20 04:52:47 Well I guess it's just an example. Feb 20 04:53:00 it needs to be something that can be implemented in really dumb devices, and the metadata updates need to be really easy to model since they are part of the speed class specification Feb 20 04:53:43 since a video camera needs to perform those metadata updates while writing video to card, and the sd card needs to be able to give a minimum write performance guarantee in the presence of those particular access patterns Feb 20 05:17:18 Hi BB Friends ..having trouble with config-pin. need some help. I am using 4.4.91-ti-r133. IoT version. Feb 20 05:17:36 config-pin P9.26 uart Feb 20 05:17:54 it is giving . pinmux file not found Feb 20 05:18:36 It is working if I use cape-universala overlay but then commanline prompt not coming up after logging in on screen. Feb 20 05:25:08 sudo Feb 20 05:25:42 I am trying with root id only Feb 20 05:25:55 sorry if i missed something.. Feb 20 05:26:00 Oh. Feb 20 05:26:08 u-boot overlays are a thing now. Feb 20 05:26:24 No more cape_mgr stuff. Feb 20 05:26:45 I know. Did you try ls /dev/tty* Feb 20 05:27:13 ok..yeah that is what I understood but with u-boot overlay default /boot/uEnv.txt config-pin is not working. Feb 20 05:27:15 let me see Feb 20 05:27:33 If you try that cmd, let me know which are the different colored tty devices please. Feb 20 05:28:31 troble: You may have to update your image. I find that every so often, an update to my OS does the body good. Feb 20 05:29:05 I think they have a 1/28 image on bbb.io/latest images. Feb 20 05:29:37 ok. I have image just before that Feb 20 05:29:56 Oh...what image and where did you get it? Feb 20 05:30:23 I am not seeing colors.. but I do see /dev/ttyO3 and /dev/ttyO0 which are supposed to map to UART Feb 20 05:31:19 Let me check..image details . Linux beaglebone 4.4.91-ti-r133 Feb 20 05:31:38 ... Feb 20 05:32:04 2017-10-10 image Feb 20 05:32:19 I think since you are in root, you "colors" are gone from your terminal. Feb 20 05:32:37 9.2-iot-armhf-2017-10-10 Feb 20 05:32:46 Oh...they have a 1-28-2018 image on bbb.io/latest images. Feb 20 05:33:01 I know config-pin works w/ that image. I performed it today. Feb 20 05:33:32 great.. thank you so much. I will try that one Feb 20 05:34:30 Hey troble: Do you know where I can find info. on u-boot overlays? Feb 20 05:35:08 I found some .dts files but I know I need .dtbo files instead. Feb 20 05:35:35 ... Feb 20 05:36:14 I added the .dts files to where u-boot is under /boot/uEnv.txt. It worked but my system would not read some software correctly. Feb 20 05:37:08 Set.. I am a bit novice too. I tried to use universala to overcome config-pin issue based on some group discussion Feb 20 05:37:26 Oh. I think that is outdated. Feb 20 05:37:34 yup.. Feb 20 05:37:36 config-pin is the new norm, I am pretty sure. Feb 20 05:37:52 ... Feb 20 05:38:24 yep. U-boot overlays and config-pin. Feb 20 05:38:55 If you want a couple of links that deal w/ config-pin on GitHub, I will post it/them. Feb 20 05:39:19 sure. thanks. Feb 20 05:40:08 https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/uart and https://github.com/adafruit/adafruit-beaglebone-io-python Feb 20 05:40:32 That second link has config-pin stuff half-way down the screen. Feb 20 05:40:46 Under UART Feb 20 05:41:06 ... Feb 20 05:41:13 There are more, I am sure. Feb 20 05:42:00 thanks a lot Feb 20 05:42:26 Yep. Feb 20 05:52:35 https://github.com/beagleboard/bb.org-overlays/tree/master/tools/beaglebone-universal-io is something else I found. Feb 20 05:53:26 Supposedly, from 4.1.x and onward, the config-pin util works. I will test real quickly. Feb 20 05:58:26 ... Feb 20 05:58:29 trobleWithPinCon: are you booting from eMMC or sd card? Feb 20 05:59:05 I was unaware of the P9.19 pru_uart mode under config-pin. Feb 20 05:59:13 trobleWithPinCon: if you're booting from sd card, you may be getting fucked up by an old bootloader on eMMC Feb 20 05:59:27 Aw! Feb 20 05:59:43 this prevents u-boot overlays from working, and it's all downhill from there Feb 20 05:59:52 zmatt: That might be my issue. Feb 20 05:59:55 I am updating now. Feb 20 06:00:14 if you don't care about the eMMC content, you can wipe it with: sudo blkdiscard /dev/mmcblk1 (caution: this will erase eMMC and will not ask "are you sure?") Feb 20 06:00:43 you can also temporarily bypass the bootloader on eMMC by powering up while holding down the S2 button (you can let go once the power led turns on) Feb 20 06:01:17 zmatt: Thank you. Can I still perform bootloader updates w/out wiping the mmcblk1? Feb 20 06:03:08 you can also reflash eMMC with a recent image, or just update the bootloader on eMMC (assuming whatever is on eMMC is not too ancient to be incompatible with current u-boot versions) Feb 20 06:03:40 Okay. Feb 20 06:03:49 That is exactly what happened to me. Feb 20 06:03:55 Well...my BBB. Feb 20 06:03:58 ? Feb 20 06:04:20 I forgot to push the s2 button. Feb 20 06:04:43 So, that older model bootloader is probably just running. Feb 20 06:05:11 if a bootloader is present on eMMC, it will normally take precedence over a bootloader on SD Feb 20 06:05:33 Hey, https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot may be able to help me? Feb 20 06:05:52 or...I just wipe that partition clean? Feb 20 06:07:01 ...forget it. I am getting damn, new image and pressing that button. Feb 20 06:07:01 ... Feb 20 06:07:25 what do you want to do? Feb 20 06:07:35 update the bootloader on eMMC ? Feb 20 06:08:25 I want to update the bootloader on eMMC so it will take precedence over my SD Card bootloader. Feb 20 06:08:40 The 1.2018 bootloader. Feb 20 06:08:48 you're not making sense Feb 20 06:08:56 Okay. Do not worry about it. Feb 20 06:09:09 unless you're holding down the S2 button at power up, any bootloader on eMMC will always take precedence over one on SD Feb 20 06:09:18 I understand that it is one or the other. Feb 20 06:09:36 Okay. So, off to reflash the damn image. Feb 20 06:09:46 bootloader on SD card will be used if none is present on eMMC or you power on while holding down the S2 button Feb 20 06:09:53 Yikes but this time, the S2 button will be held. Feb 20 06:10:21 I know now. I remember but I failed to remember when i installed this image. Feb 20 06:10:38 Too forgetful. Damn. Feb 20 06:10:46 ? Feb 20 06:10:57 I don't get it Feb 20 06:11:14 what do you mean by "I failed to remember when i installed this image" Feb 20 06:11:22 install onto eMMC ? Feb 20 06:11:58 I know. No, I have the new image but failed to press S2 while booting the SD Card. Feb 20 06:15:22 zmatt: You saved the day. I always make this mistake. Sheesh. Feb 20 06:25:41 @zmatt you r da man..(or woman :-) . That worked. As you said image on eMMC messing up with U-boot oevrlay Feb 20 06:25:57 It worked when I booted with s2 down Feb 20 06:26:18 thanks a lot Feb 20 09:33:25 Hi All Feb 20 09:34:08 I want to have both HDMI output and an LCD touchscreen on a BeagleBone Black, but that looks impossible, isn't it? Feb 20 09:49:29 there's only one lcd controller Feb 20 09:49:50 I mean, if you configure a fixed resolution then it could go both to lcd and hdmi I guess Feb 20 10:42:05 @zmatt Thanks a lot for this detail. That anwsers my question! Feb 20 12:53:15 I have some questions to pocket beagle Feb 20 12:54:45 Hi! Feb 20 12:56:22 I am experimenting with the McASP0 Feb 20 12:56:40 Already wrote the DTO and I can confirm it's working for the I2C part at least Feb 20 12:56:48 There is a chrager IC on pocket beagle. Is possible to get the status if it charging decharging percent current voltage to chnage charging current? Feb 20 12:57:43 Now struggling with what to do next, can someone forward me the necessary documentation to start using the McASP in C without using ALSA? Feb 20 12:57:45 the charger is part of the tps65217. Feb 20 12:58:37 which the SRM explains in detail https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual Feb 20 13:00:24 the tps65217 has negligible status information Feb 20 13:00:45 no voltage or current readouts, let alone state-of-charge tracking Feb 20 13:03:09 How can I inform the end user if the battery is full or empty. Is there any access to tps65217 via i2c to get the info Feb 20 13:04:31 there is an i2c connection, but i’m not aware of what status is available. Feb 20 13:05:28 you can wire-up and adc to measure voltages Feb 20 13:05:37 s/and/an/ Feb 20 13:06:09 I also feel I should warn you that battery-powering the pocketbeagle via the tps65217 is not safe since the pocketbeagle uses SYS_VDD1_3P3V for the 3.3V supply (which basically replicates the 3.3v regulator issue that also affects the BBB) Feb 20 13:06:30 or more specifically, it's not safe to ever shut down while battery-powered Feb 20 13:07:04 (that includes the automatic shutdown that happens when the battery is getting low) Feb 20 13:07:25 zmatt: but nothing is wired to it on the board. it just comes to the header. Feb 20 13:07:42 that's not what the schematic says Feb 20 13:08:30 hmmm... where did I mistakenly allow it to be used on-board? Feb 20 13:08:38 it's used to power the sd card (hence all sd i/o), sysboot pullups, Feb 20 13:10:50 also only 3.3V is available on the headers, the actual i/o supply (SYS_VDD3_3P3V aka VDD_3V3A) is not accessible anywhere, which will make it difficult to safely attach any external components Feb 20 13:13:29 k. just verified that myself too. crap. Feb 20 13:13:37 the header was intended Feb 20 13:13:54 the microsd and sysboot pins were not. Feb 20 13:14:14 that was a miscommunication between me and Aron apparently. Feb 20 13:14:43 Do you recommend pocket beagle for battery powerd handheld applications? Feb 20 13:14:55 the header exposed it as a useful 3.3V LDO to try to get some value out of the damn thing. Feb 20 13:16:01 Guest23670: just use an external battery solution, e.g. a usb battery pack Feb 20 13:17:21 let me evaluate if the bug zmatt validly pointed out has a work-around. Feb 20 13:17:45 using the tps65217 is not great for multiple reasons anyway, e.g. powering 3.3v regulators from a single li-ion cell without any boost conversion Feb 20 13:18:03 it is indeed a mistake to have the microsd and sysboot pins on that other LDO that isn’t part of the tps65217. Feb 20 13:19:08 plus the extremely limited monitoring capabilities of the tps65217 Feb 20 13:19:20 that device is used in a number of battery powered situations. Feb 20 13:19:34 sure, but probably with 1.8v i/o instead of 3.3v Feb 20 13:21:34 I'm not saying it can't work, I know it can ( https://nurdspace.nl/images/0/0a/Bbb-zmattified.jpg ) Feb 20 13:21:44 it's just... not ideal Feb 20 13:22:49 (that BBB had the 3.3v regulator removed and replaced by a wire tying vdd_3v3a/b together) Feb 20 13:23:18 anyway, afk for a bit, will be back Feb 20 14:07:57 hi, I want to use a BeagleBoneGreen as a development tool, I've already 2 of them, so I could repurpose one of them for that, Feb 20 14:08:27 I need stuff like g_dbgp, for getting coreboot logs and similar things Feb 20 14:08:58 my issue is that the USB peripheral connector is used for both power and USB Feb 20 14:09:28 so I cannot capture the logs of a booting system since the board would need to be up before the computer is booting Feb 20 14:10:16 I've looked at the manual and pinout, and some of the pins of the P8 and P9 connectors can be used to power on the board Feb 20 14:10:30 however the manual says that it should be strictly 5V Feb 20 14:11:02 would connecting thoses pins to an USB connector be ok? Feb 20 14:11:23 or smartphone charger be able to damage the board? Feb 20 14:34:16 Hello Feb 20 14:34:42 I have completed the first step what the next to do Feb 20 15:18:45 Hi, I was wondering if it is possible to share the ethernet internet the Beaglebone black has to the usb connection to the computer? Feb 20 15:45:54 GNUtoo: you can power the beaglebone by applying 5v (from usb or otherwise) to pins 5+6 of P9 Feb 20 15:46:04 Baggy: yes Feb 20 15:47:46 GNUtoo: if you're going to capture boot logs via some serial port of the beaglebone, do make sure that it's 3.3v signalling and that the beaglebone has power before an external signal is applied to the beaglebone Feb 20 15:48:24 ahh, it's actually via usb Feb 20 15:48:34 (i just looked up what g_dbgp is) Feb 20 15:52:07 Can any one say me what is the task after doing the cross compilation Feb 20 16:51:54 can i rma xM its older than a year wont boot... Feb 20 16:56:39 zmatt: Do you know of any good guide to take me through the steps? Feb 20 17:11:42 zmatt are you there? Feb 20 17:19:25 zmatt: yes, what I wonder is if in general it's risky to do that Feb 20 17:19:44 zmatt: like are common off the shelf smartphones PSU stable enough not to break the beagle Feb 20 17:20:04 and the idea is to use the USB peripheral port to capture the logs Feb 20 17:20:14 (and serial to interact with it from a second computer) Feb 20 17:20:17 (or ethernet) Feb 20 17:20:44 does anybody have ever connected two bluetooth headsets (HFP) to one beaglebone green wireless and got both working at the same time? Feb 20 17:21:08 i was wondering if the bluetopia stack has any limitations in that direction? Feb 20 18:33:49 GNUtoo: the 5v input of the beaglebone is that particularly fussy, as long as it's 4.5 - 5.5V and can deliver enough current Feb 20 18:33:58 *isn't that particularly fussy Feb 20 18:34:40 and it should ramp up fast enough (within 50ms) but that's generally not an issue I think Feb 20 18:37:48 GNUtoo: be aware that on the beaglebone green only, they made the weird choice of cross-connecting the usb 5v with the main 5v which connects to pins 5+6 of P9 (and to the dc barrel plug on most other beaglebones) Feb 20 18:38:03 so that means the 5v will backpower into the usb device port Feb 20 18:38:22 I don't know if there are hosts that severely object to this Feb 20 18:38:49 it should be possible to cut this cross-connection by removing one 0Ω resistor Feb 20 18:40:35 ummm ok Feb 20 18:41:38 Are the D+ and D- sufficent for host communication? Feb 20 18:44:00 ew, this sucks, I just realized that this cross-connection they did is pretty bad Feb 20 18:44:20 since it means that no matter how you power the board, the usb peripheral port will detect vbus high Feb 20 18:44:57 Is that an issue? Feb 20 18:45:09 it's not a huge deal, but it means it'll start pulling up D+ or D- to indicate device attachment Feb 20 18:45:10 It's peripheral only anyway Feb 20 18:45:15 oh ok Feb 20 18:45:41 so if the host port you're connected to isn't powered yet, that means it would be injecting current into it Feb 20 18:46:03 ok, that shouldn't be a big issue I guess Feb 20 18:46:17 (I guess that the USB port are somehow isolated on laptops) Feb 20 18:46:25 maybe not, depends on the current and on the fragility of the port Feb 20 18:46:35 Thinkpads mostly Feb 20 18:46:50 well there's all sorts of esd protection, but no I wouldn't assume the D+/D- IO drivers themselves are highly robust Feb 20 18:46:54 so I'd have to check that Feb 20 18:46:57 oh ok Feb 20 18:47:29 in case you want to consider fixing it: if you look at page 2 of the schematic, topleft corner: https://cdn.rawgit.com/SeeedDocument/BeagleBone_Green/6d9d2229/resources/BEAGLEBONE_GREEN_V1.pdf Feb 20 18:47:46 there's resistor R168 that's connecting USB_DC to VDD_5V Feb 20 18:48:00 oh never mind! Feb 20 18:48:03 sorry! Feb 20 18:48:07 I totally missed the "DNP" Feb 20 18:48:10 (Do Not Place) Feb 20 18:48:18 yes, I see it Feb 20 18:48:26 so everything is ok then Feb 20 18:48:35 so they designed it in but I guess they realized it was a bad idea Feb 20 18:48:43 lol ok Feb 20 18:49:04 thanks a lot for all the information! Feb 20 18:49:05 yeah in that case VDD_5V only connects to pins 5+6 of P9 Feb 20 18:49:16 you can safely power the system via that Feb 20 18:51:49 GND are pin 1,2 of P8 and P9? Feb 20 18:51:57 (It says DGND like Digital ground) Feb 20 18:52:16 see also the P9 and P8 tabs of my spreadsheet for a nice overview: https://goo.gl/Jkcg0w Feb 20 18:52:29 I'm looking at them here: http://wiki.seeed.cc/BeagleBone_Green/ Feb 20 18:54:00 yeah there are other floating around, but often much info is missing :) (or in case of the beaglebone green wireless they're just actively misleading) Feb 20 18:54:02 nice, there is even some stuff that I don't know of there.... Feb 20 18:54:14 like stuff for jtag Feb 20 18:54:46 the BBB tab lists all processor i/o and what they're connected to Feb 20 18:55:15 if you want to search the other way around: the signals tab lets you find a particular signal and then figure out on which pin(s) it can be made available Feb 20 18:55:18 I'll try to download it Feb 20 18:55:32 the BBB tab also has a few filter views (menu Data -> Filter views) Feb 20 18:56:06 download? into what format? I wonder how well that will survive Feb 20 18:56:19 sounds fine in odt Feb 20 18:56:25 I do always keep printouts of the P9/P8 tabs around for quick reference :) Feb 20 18:57:36 lol there is even the video output stuff Feb 20 18:58:08 That's the most comprensive sheet that I ever saw on the topic! Feb 20 18:58:38 there is even the BGA grid! Feb 20 20:27:40 yeah that one I blame on a silly mood Feb 20 20:28:03 (the ballouts) Feb 20 20:36:45 Yo...hello. Feb 20 20:37:31 Last Friday ZMATT helped me get the PRU reading in data over a SPI like interface. Now, I'm having issues with reading data out fast enough before the next clock pulse. With the lines commented out that store the other 3 data lines to an array it works, but when I uncomment these lines the code can't store the values before the next clock pulse. Here is the code I'm referring to: https://pastebucket.com/565464 Feb 20 20:38:08 Any suggestions as to how to speed up this code? Feb 20 20:41:51 Here is the logic analyzer showing the difference: https://pasteboard.co/H8z2fHN.png Feb 20 20:51:32 Do we have GCC support for PRUs? Feb 20 20:52:23 I'm no expert but what you're trying to do looks like programming old games consoles Feb 20 20:52:54 like you're trying to do stuff before an event (clock pulse, or the display refresh) Feb 20 20:53:43 Yeah, I'm actually trying to read out data from the AD7779 ADC. It acts as the master so I have to read the data before the next clock pulse. Feb 20 20:53:50 I think GCC only runs on 64 bit systems, i.e. at least the one for the BBB. Feb 20 20:54:30 oh Feb 20 20:54:40 Guest20651: there is a talk on SPI slave support in linux at last fosdem, Feb 20 20:55:00 I read it at: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-ARMCrossCompiler:GCC Feb 20 20:55:32 it talks about tricks that linux uses to be able to do it (Linux has no realtime scheduler...) Feb 20 20:55:44 (so it must prepare some stuff even before being asked) Feb 20 20:56:21 though it sounds strange to have the ADC act as master... Feb 20 20:57:00 "Yeah, I'm actually trying to read out data from the AD7779 ADC. It acts as the master" it is the ADC or the PRU? Feb 20 20:57:15 The ADC acts as the master on the DATA bus Feb 20 20:57:35 oh ok Feb 20 20:57:45 so you should definitely look at that talk Feb 20 20:58:01 What library are you using? Feb 20 20:58:13 so the ADC drives the CS# line... Feb 20 20:58:27 set_: thanks Feb 20 20:58:43 Okay. I did not mean to butt in. Sorry and enjoy. Feb 20 20:59:26 ... Feb 20 20:59:34 GNUtoo: You are welcome. Feb 20 21:00:03 set_: I was talking about GCC for the PRUs though Feb 20 21:00:11 here I only saw ARM cross compilers Feb 20 21:00:42 Ok, I'll check that out. I'm just reading the pin values and clock lines with the PRU. And yes, the ADC drives the CS line Feb 20 21:01:04 GNUtoo: I want to look something up. I will go and check it out. Feb 20 21:01:08 Guest20651: you could read before being asked the data Feb 20 21:04:19 https://github.com/dinuxbg/gnupru and that darn google showed a bunch of stuff. I was surprised. Feb 20 21:05:18 <<<< bowing out Feb 20 21:05:27 No more interruptions. Feb 20 22:13:12 set_: "I think GCC only runs on 64 bit systems" ... what on earth are you talking about -.- Feb 20 22:14:22 I know. Feb 20 22:14:28 That is what I told that fellow. Feb 20 22:14:54 ... Feb 20 22:15:03 ... I was quoting you, and added "what on earth are you talking about" Feb 20 22:15:09 since you're saying nonsense again Feb 20 22:15:15 They were talking about PRU stuff. I had to bow out. Feb 20 22:15:42 Oh. Feb 20 22:15:56 I get you, now. Is that not the case for the link I provided? Feb 20 22:16:47 They were discussing PRU and I thought they wanted a ARM GCC idea. Feb 20 22:16:52 I checked the links and so on and I didn't find out if gcc/binutils and so on were upstreamed, but I guess that since binutils format change it's not yet Feb 20 22:16:54 My bad. Feb 20 22:17:05 GNUtoo: probably TI's PRU C compiler is too stupid to allocate those four values (data[0], data[2], data[4], data[6]) into registers Feb 20 22:17:27 use four temporary variables and write the result out to your array after the loop Feb 20 22:17:39 btw, why are you only using the even indices? Feb 20 22:17:41 Guest20651: ^^^^ Feb 20 22:17:51 It's Guest20651 that had the question not me Feb 20 22:18:01 my question was only about the PRU gcc support status Feb 20 22:18:04 oh sorry! Feb 20 22:18:07 np Feb 20 22:18:14 somewhere along the way I got the names mixed up Feb 20 22:18:45 I also saw that it needs a kenrel patch to use gcc/binutils (due to the format changing to match the proprietary compiler closer and closer) Feb 20 22:18:52 np Feb 20 22:18:53 what? Feb 20 22:18:57 oh yeah Feb 20 22:19:18 because the pru gcc was still too limited to be able to comply with the PRU EABI Feb 20 22:19:21 iir Feb 20 22:19:22 c Feb 20 22:19:49 yes indeed. I hope that it'll be fixed one day. Feb 20 22:20:36 PRUs are really nice, and I was thinking of maybe one day using theses with the google cape for making a logic analyzer but given the software status I'll wait Feb 20 22:21:19 to be honest I still think asm is a better choice for pru code, considering how very little instruction memory they have and that the pru instruction set is totally not designed for C code Feb 20 22:21:19 Also I'd be limited to something like Ethernet 100 or USB speed for transfering the samples to a host computer Feb 20 22:21:30 ok Feb 20 22:21:33 you're aware of beaglelogic ? Feb 20 22:21:54 yes, it's dicontinued I think Feb 20 22:22:00 there is a new thing from google Feb 20 22:22:09 but I didn't check sigrok compatibility for that one Feb 20 22:22:20 let me find it Feb 20 22:22:23 uhh, that sounds unlikely, they recently actually made hardware specifically for beaglelogic Feb 20 22:22:32 https://elinux.org/Beagleboard:BeagleBone_Capes Feb 20 22:22:39 https://standalone.beaglelogic.net/en/latest/ Feb 20 22:22:41 https://elinux.org/PRUDAQ Feb 20 22:23:48 PRUDAQ is a 2-channel high-speed ADC, not a logic analyzer. (it actually builds on top of beaglelogic though iirc) Feb 20 22:23:59 oh ok Feb 20 22:24:18 note that beaglelogic itself has no cape... it doesn't require any external hardware Feb 20 22:24:53 I'm making confusion with the cape Feb 20 22:25:28 (the purpose of the 'beaglelogic standalone' is to be able to use more pru pins than are available on the beaglebone, and gigabit ethernet to be able to transfer the captured data in real time) Feb 20 22:26:12 anyway, beaglelogic is an excellent example of pushing pruss close to its max :) Feb 20 22:26:16 https://sigrok.org/wiki/BeagleLogic Feb 20 22:26:23 there's no way you could get even remotely near its performance using C code Feb 20 22:27:17 https://github.com/abhishek-kakkar/BeagleLogic/wiki/The-BeagleLogic-Cape Feb 20 22:27:28 This is the cape I'm making the confusion with Feb 20 22:28:37 I didn't know the standalone version Feb 20 22:30:59 oh, I'm not sure I ever saw that one Feb 20 22:31:06 so it's just a logic shifter Feb 20 22:31:10 yes Feb 20 22:31:17 makes sense Feb 20 22:31:35 the am335x i/o cells can definitely use some protection against the harsh outside world Feb 20 22:31:42 even if you're not using 5v Feb 20 22:32:16 it would also look nice on the cloud-something variant which has 1GB RAM and Gigabit Ethernet Feb 20 22:34:18 *sancloud Feb 20 22:36:13 well, the beaglelogic standalone has gigabit ethernet (like the sancloud BBE), 5v-tolerant buffered inputs (like the cape), and expands the number of channels to 16 Feb 20 22:36:23 it looks neat Feb 20 22:36:28 indeed Feb 20 22:36:38 no price information yet though as far as I can see? Feb 20 22:36:51 it doesn't seem to be released yet Feb 20 22:38:15 I know, but an indication would have been nice Feb 20 22:43:27 anyway thanks a lot for the info, as I'll probably have bought a useless cape that does ADC instead of logic analyzer Feb 20 22:47:09 Guest20651: did you catch my comments earlier? (I accidently directed them at GNUtoo ) Feb 20 22:50:42 Guest20651: btw, regarding lines 2-3... shouldn't setting that bit of out_reg be done somewhere *outside* the loop? (either before or after, dunno what's intended here) Feb 20 22:52:16 ah I see now why you used the even indices of data[] Feb 20 22:58:53 oh never mind clpru *is* smart enough to allocate the values in register Feb 20 23:05:35 Guest20651: maybe try something like https://pastebin.com/mDiALEMh Feb 20 23:09:12 Guest20651: if( gpi & (1 << D0_POS) ) data[0] |= 1; saves one cycle over data[0] |= (gpi & (1<>D0_POS; Feb 20 23:34:51 regardless, at this point you really may want to start considering writing this piece of code in assembly... I think that makes more sense than analyzing the C compiler's output and fiddling with the C code until the compiler produces the desirable instructions Feb 21 01:34:21 Hello. Feb 21 01:51:09 Motor Bridge Cape...Up and Running! Feb 21 02:13:30 I did not plug it in. Feb 21 02:13:45 Aw! Feb 21 02:20:34 I thought I could run software w/out the hardware to test it. Feb 21 02:20:56 <<<<< unknowingly wrong 99.99% of the time Feb 21 02:21:29 ... Feb 21 02:21:53 damn rain tomorrow...I cannot test the motors now w/ the new software. Feb 21 02:24:11 Excuse me,I am a production process engineer. Feb 21 02:24:11 I want to make a monitoring system of product line. I think 20 photosensors and 10 PIR sensors will connect BBB board. I have some question,1.which kind of ports is connected? GPIO port or PRU port? 2. If two or more sensors are detected in same time, I don't know how to solve this problem. Feb 21 02:25:25 software! Feb 21 02:26:35 I sort of know stuff but I will tell you only so much. More people here know more than I. Feb 21 02:26:50 ... Feb 21 02:27:09 Do you have a library so far? Feb 21 02:28:12 I tested PIR sensors before. Feb 21 02:28:22 Let me look up my software. Feb 21 02:29:03 Oh dude or oh lady...there is a PIR sensor ex. on the bbb.io page(s). Feb 21 02:29:06 I buy a book, Exploring BeagleBone Feb 21 02:29:08 Hold for the link. Feb 21 02:29:19 Oh. Feb 21 02:29:27 I think I have that book. Feb 21 02:29:31 Let me get it. Feb 21 02:30:17 W_Olympic: By Molloy? Feb 21 02:30:26 yes Feb 21 02:30:32 Oh...what page? Feb 21 02:32:04 I looked up PIR Sensor in the index. I found nothing. Feb 21 02:32:15 Erm....I want to learn this book, then I can make a monitoring system, this isn't in book. Feb 21 02:32:23 Oh. Feb 21 02:32:41 Hey. Look at bbb.io under the examples. Feb 21 02:33:00 I will get the link this time. Feb 21 02:33:21 is it in BBB? Feb 21 02:33:33 https://beagleboard.org/Support/BoneScript/PIRMotionSensor Feb 21 02:33:35 I think so. Feb 21 02:33:57 I tried that example. It works. It is typed up in .js. Feb 21 02:34:11 Sorry...bonescript. Feb 21 02:34:46 But...you can search. PIR sensors are vast and numerous in examples. Feb 21 02:38:35 Thank you very much, I think photoelectic sensor is a switch, it connect GPIO, I think it is right. But i know PRU real-time port, I don't know I should use which kind of ports. Feb 21 02:39:28 GPIO works. Feb 21 02:40:04 Hey. Let me look up that old software. I know I have it around here somewhere. Feb 21 02:41:12 W_Olympic: Do you know if it is digital or analog? Feb 21 02:42:16 haha,,,I think it is digital Feb 21 02:42:46 Serious. I look up so much stuff, I forget what is what. Feb 21 02:43:10 https://learn.sparkfun.com/tutorials/pir-motion-sensor-hookup-guide is for Arduino but you can incorporate the BBB w/ it. Feb 21 02:43:45 the PIRs are slow enough to not need the PRU Feb 21 02:43:54 Oh. Feb 21 02:44:27 Confirm: PIR sensors are digital! Feb 21 02:45:28 bonescript is similar to that stuff they type up for the arduino. Feb 21 02:45:52 I think that was an easy way for people to start out. Feb 21 02:46:56 I learn analog and digital signal many days...but my friend tell me it is a switch, not tell me sensor output analog or digital. i think it is digital.https://learn.sparkfun.com/tutorials/analog-vs-digital Feb 21 02:47:13