**** BEGIN LOGGING AT Mon Jul 16 03:00:01 2018 Jul 16 03:46:21 The previous problem that I asked about seems to be in the Adafruit_BBIO library. I have now compiled two different C programs, one of which was against the roboticscape library, and I did not have the problem with either test program. Jul 16 03:47:09 if you're using an adafruit library and have problems, when in doubt it's probably the library's fault Jul 16 03:47:20 adafruit writes junk Jul 16 03:47:41 To repeat, using the Adafruit library for a python program, I can run a blink test onec, but when I try to run it a second time, there is no control of the BeagleBone Blue USR LEDs. Jul 16 03:48:28 Is there a better python library that I can use with the current kernal and python 3? Jul 16 03:48:29 it probably doesn't help that controlling leds is very different from controlling gpios Jul 16 03:49:18 I'm just getting started with the Beagle boards, so I needed a simple test to get up to speed. Jul 16 03:50:07 I probably wouldn't even bother with a library Jul 16 03:50:40 So do I have to go with a C code program? Jul 16 03:50:41 considering you're just writing a value to a sysfs file, which is two lines of python code or one line using pathlib Jul 16 03:51:09 you can use any language you want Jul 16 03:52:09 for leds, you can find a directory per led in /sys/class/leds/ Jul 16 03:52:44 to set a led to manual control, write "none" to the "trigger" attribute of the led Jul 16 03:53:08 then control the led by setting the "brightness" attribute to 0 or 255 (the value of "max_brightness") Jul 16 03:53:25 For the main use of the Blue board, for servos etc, I need to use some kind of library so I don't have to get into the lower level stuff. Jul 16 03:54:14 the servo control is a different matter... that's something involving the pru firmware I think? not sure Jul 16 03:54:24 Probably will try using the robotiscape C library. Jul 16 03:54:24 I don't have a blue so never looked at those details Jul 16 03:59:28 but your original question was about leds. for that.. https://pastebin.com/Gx24DXLd Jul 16 04:00:46 of course this can be done more efficiently by keeping the file open instead of opening and closing it for every write, but for simple stuff it might not matter Jul 16 04:01:12 note that unfortunately, unlike gpios, controlling leds requires root privileges Jul 16 04:01:16 (obnoxiously) Jul 16 04:06:01 e Jul 16 07:28:16 bbb running Debian Stretch 9.5, apt-get install xinput_calibrator returns "E: Unable to locate package xinput_calibrator", even though it finds it with "aptitude search" (uninstalled). apt-get update and upgrade works. Am I doing something wrong, or is the package missing somehow? Jul 16 07:33:17 question, I'm sure it was answered on here already but I forgot: If I want to power the beaglebone black from a cape, on which pin do I need to feed the 5V? Jul 16 07:34:31 tbr: ^ Jul 16 07:34:37 tbr: btw my hotair station just arrived Jul 16 07:34:44 not sys Jul 16 07:35:30 P9.01+02 = gnd, P9.05+06 = 5v in Jul 16 07:36:42 zmatt: thanks Jul 16 07:36:45 using two pins each because the connector is officially not rated to carry the max amperage of the beaglebone across a single pin, but in practice you can probably get away with using only one pin Jul 16 07:37:08 zmatt: not a problem, I'll be making my own pcb anyway Jul 16 07:37:58 I'm currently using a rapi to control my garden irrigation, but it's such an in appropriate platform for that Jul 16 07:38:08 for future reference, see the handy P9 and P8 tabs of my pins spreadsheet => https://goo.gl/Jkcg0w Jul 16 07:38:10 s/rapi/raspi/ Jul 16 07:40:36 Knaldgas: I'm not seeing a package by that name Jul 16 07:41:05 Knaldgas: actually, you just made a typo, it's xinput-calibrator, not xinput_calibrator Jul 16 07:41:57 * Knaldgas feels quite stupid now Jul 16 07:42:05 Thanks zmatt :) Jul 16 07:42:30 I'll pour up another cup of coffee :) Jul 16 07:42:44 I understand, it's monday Jul 16 07:42:47 ;) Jul 16 07:45:08 thinkfat: have fun :) Jul 16 07:45:55 zmatt: P9.03 and P3.04 are 3.3V from the BBB, how much can I load them? Jul 16 07:46:53 there's a buch of triacs on the board, each gate needs about 5mA hold current Jul 16 07:47:43 500 mA minus whatever is consumed by on-board components (which is substantial, but I don't know the exact amount) Jul 16 07:48:05 even a gpio could provide 5 mA :P Jul 16 07:48:20 zmatt: ok, so the rail is rated 500mA in total, including components on the BBB itself? Jul 16 07:48:56 there are two 3.3v rails on the BBB, 3v3a is 400 mA, 3v3b is 500 mA Jul 16 07:49:18 3v3a is used for the 3.3v supplies of the am335x itself Jul 16 07:49:33 and some minor stuff Jul 16 07:50:39 3v3b is for the P9 header and other components (ethernet, eMMC, sd card, console buffer, possibly other things I'm overlooking) Jul 16 07:51:08 iirc ethernet and eMMC were both up to 100 mA worst case Jul 16 07:51:38 it's been a while since I dug into this though Jul 16 07:53:34 I put some power-related notes here a long time ago: https://elinux.org/BeagleBone_Power_Management Jul 16 07:56:21 zmatt: so that means approx. 200mA power budget left for a cape... Jul 16 07:56:29 zmatt: but that's plenty Jul 16 07:56:42 approx 300 if sd card is not used Jul 16 07:57:07 I think I'll maybe need 80mA, tops Jul 16 08:00:22 that little would even be fine for a beaglebone with unified 3v3 patch (which we used to do with our beaglebones but apparently stopped doing at some point without analysis of the implications -.- ) Jul 16 08:02:31 yeah, the only power-hungry stuff on the cape will be the triac gates, and I'm thinking about switching to mosfets anyway Jul 16 08:03:12 mainly because they're smaller ;) Jul 16 08:05:40 but then again, maybe not. Jul 16 08:06:14 the board I have works nicely with the raspi, so I'll likely just convert it to a different form factor Jul 16 08:06:21 I still have some mild concerns about the 3v3b staying enabled for too long during poweroff, and the resulting current flowing from 3v3b-powered components into io pins of the am335x and via their internal esd protection diodes back into 3v3a... but beaglebones seem to survive well enough so *shrug* Jul 16 08:07:38 zmatt: btw is there any benefit from hooking up an external RTC to a bbb? Jul 16 08:08:04 zmatt: can the internal rtc be backup-powered? Jul 16 08:08:09 the ability to keep the time while the board is powered off Jul 16 08:08:14 there you go Jul 16 08:08:55 in theory yes, in practice that's a big can of worms and you're better off with an external rtc + backup battery if timekeeping during poweroff matters to you Jul 16 08:09:15 well, then pcf8523 it is.. Jul 16 08:09:18 (and using ntp is not a good option) Jul 16 08:29:10 btw is any of the "wireless" variants of the beaglebone worth considering? Jul 16 08:30:06 it's the only advantage the raspi solution currently has, that I don't need ethernet in the garden hut Jul 16 08:30:47 tbr: I bought from the same vendor on aliexpress, it took a while to arrive, but not unduly long Jul 16 08:31:07 did DHL extort you much? Jul 16 08:31:28 tbr: no, I used the "china post registered parcel" option ;) Jul 16 08:31:41 good job :D Jul 16 08:32:15 tbr: I used dhl once for a pcb delivery, that was an expensive experience Jul 16 08:34:46 yes, I had my DHL experience with that smoldering-hot-air station. Managed to avoid anything related ever since. Jul 16 08:36:06 DHL is the most expensive in terms of import handling fees. 27€ IIRC. So if possible I go with normal mail (0€ handling) or UPS or FedEx (12-18€). Jul 16 08:37:21 also with finnish post I can immediately see it in online tracking if something gets diverted into customs. I then go and fill out all the forms online, pay online and it immediately gets released back into the Postal flow. Delay is usually 0-1 days. Jul 16 08:59:31 tbr: dhl offers to do the customs handling for you, which I foolishly accepted (is there even an option to not?) and of course that came with a hefty fee Jul 16 09:01:29 thinkfat: here they charge you a 'we hand it over to customs and you do it fee', which is 1€ less than having them do it. wegelagerer… Jul 16 09:24:00 thinkfat: if you want wifi instead of ethernet then the BBBW is exactly that Jul 16 09:24:06 thinkfat: ignore the BBGW Jul 16 09:24:25 zmatt: sounds like a plan Jul 16 09:29:15 hI, i'VE INSTALLED dEBIAN 4.14 ON bbb. i WANT TO USE a dts file that worked on 3.8 to run two PRU files. It runs one but not the other. Any ideas? Jul 16 09:33:05 problem description is way too vague Jul 16 09:34:10 note that on recent images you usually don't need overlays. they are still supported (however may sometimes require changes) Jul 16 09:38:22 hi zmatt. 'on recent images you don't need overlays' I just call the PRU functions from C? Jul 16 09:39:06 you can enable uio-pru by uncommenting the right line in /boot/uEnv.txt Jul 16 09:39:22 and any pins you need for pru can be configured using config-pin Jul 16 09:39:25 I've done that Jul 16 09:40:00 well those are the two things which an overlay for pru would typically have done Jul 16 09:40:22 No, not config-pin. But I'll try it. Thanks Jul 16 09:40:37 note that config-pin won't work if you've enabled any custom overlay Jul 16 09:40:46 it's either-or Jul 16 09:43:58 So in uEnv.txt I comment out my .dtbo file. What about the disable_uboots? If I allow disable_uboot_overlay_emmc it trashes Linux Jul 16 09:44:25 well duh if you're booting from eMMC you can't disable eMMC Jul 16 09:44:27 :P Jul 16 09:46:16 Ok. What about the other disables - as I remember from Molloy you had to disable HDMI coz it competed with the pins you need Jul 16 09:46:44 depends on which pins you need Jul 16 09:48:09 hdmi isn't mentioned in the current uEnv.txt: there's 'video', 'audio', 'wireless', 'adc' Jul 16 09:48:46 eMMC uses P8.03-06 and P8.20-25, hdmi video uses P8.27-P8.46, hdmi audio occupies P9.25+28+29+31 Jul 16 09:49:16 wireless is not applicable on a BBB, adc has dedicated pins and there's no reason to disable it Jul 16 09:49:41 (on the beaglebone black wireless there's also no reason to ever disable wireless since it doesn't conflict with any expansion header pins) Jul 16 09:50:45 so, are you saying disable video and audio? Jul 16 09:51:20 if you don't need hdmi video/audio and want to use those pins for other purposes then yes Jul 16 09:53:59 zmatt - sorry, our conversation vanished - what's the utility that sets pins? Jul 16 09:54:04 config-pin Jul 16 09:54:14 thanks Jul 16 09:56:23 btw, be careful with connecting stuff to P8.31-P8.46 since those pins are also used for boot configuration. there are 100K pull-up/down resistors on these pins to make sure they have the correct level during power-up (which is when the processor samples them), but since those are pretty weak pulls it's easy to accidently influence them if you connect stuff to them Jul 16 09:58:05 for normal boot, pins 31, 41, 43, and 44 (of P8) need to be high (pulled to 3.3v) during power up, and pins 32, 33, 35, 39, 40, 45, and 46 need to be low Jul 16 10:01:52 Luckily we don't use any P8 pins. In uEnv, do I load AM335X-PRU-UIO-00A0.dtbo? Jul 16 10:02:52 then why are you disabling hdmi? Jul 16 10:02:56 yes Jul 16 10:03:49 of course if you don't need hdmi you can disable it simply for that reason I guess Jul 16 10:03:54 OK - u asking me about HDMI? Only because Molloy says to Jul 16 10:04:14 I listed the pins used by various things Jul 16 10:04:22 11:48 < zmatt> eMMC uses P8.03-06 and P8.20-25, hdmi video uses P8.27-P8.46, hdmi audio occupies P9.25+28+29+31 Jul 16 13:41:48 Hello everyone, I am facing an issue where my disk usage shows 3.4G Used and 0 available. However if I reboot the system then it shows 700MB available. Can someone help in tracking the problem? Jul 16 14:06:47 Hello everyone, I am facing an issue where my beaglebone disk usage shows 3.4G Used and 0 available. However if I reboot the system then it shows 700MB available. Can someone help in tracking the problem? Jul 16 14:12:10 asking a question once is sufficient Jul 16 14:13:06 what you're describing suggests something is filling up disk space with either 1. temporary files which are deleted at boot (e.g. in /tmp), or 2. unlinked files Jul 16 14:54:42 Hello everyone, I am facing an issue where my beaglebone disk usage shows 3.4G Used and 0 available. However if I reboot the system then it shows 700MB available. Can someone help in tracking the problem? Jul 16 14:56:31 ACK! Jul 16 14:58:49 a_: stop repeating your question, instead actually pay attention to answers given (you were still connected when I replied) Jul 16 14:59:35 what you're describing suggests something is filling up disk space with either 1. temporary files which are deleted at boot (e.g. in /tmp), or 2. unlinked files Jul 16 15:12:55 zmatt Thanks for the answer, sorry i couldnt notice the answer before Jul 16 15:14:40 of course, if something is continuously writing data, then presumably it will also start spitting out errors once the disk runs out of space, so if you just keep a window open that monitors the system logs (journalctl -f) then you may very well catch the culprit red-handed Jul 16 15:14:54 unless it's really badly written and ignores errors Jul 16 15:20:23 hi Jul 16 15:20:34 i need help Jul 16 15:45:10 (then maybe you should have asked a question) Jul 16 22:10:16 https://pastebin.com/eEe76Bfz <<<<<< this is a read from i2cdetect -r -y 2 from the BBBlue. I am trying to get arduCopter working but the mpu and bmp might be "corrupt." What does this mean to you? Jul 16 22:18:02 using i2cdetect is a bad idea and can confuse the hell out of i2c devices Jul 16 22:18:17 I saw that. Jul 16 22:18:23 What else should I use? Jul 16 22:18:33 for? Jul 16 22:18:40 Oh. Jul 16 22:18:56 I am receiving an error about a...dang it. please hold. Jul 16 22:19:49 error: sensor failure: Baro: unable to initialise driver. Jul 16 22:20:16 I am assuming this is a barometer but I do not have a barometer attached to my BBBlue. Jul 16 22:20:29 I think it has one integrated Jul 16 22:20:37 That is what I thought, too. Jul 16 22:20:51 is that the exact error? (i.e. copy-pasted, not typed over) Jul 16 22:21:05 No Sir, please hold. Jul 16 22:21:16 I am going to pastebin the copy/paste. Jul 16 22:21:40 in the future, when saying you get an error, always give the exact error Jul 16 22:21:57 Yes sir. Jul 16 22:22:45 https://pastebin.com/xJXSdKSu is the error but when I run my .service file and run arducopter on the BBBlue, the lines that are the same in the pastebin keep going and going and going. Jul 16 22:22:46 ... Jul 16 22:22:53 I could not even use ctrl-c to escape. Jul 16 22:23:18 use q Jul 16 22:23:24 q? Jul 16 22:23:26 meaning quit? Jul 16 22:23:35 I will try next time. Jul 16 22:23:37 at least, how did you get those errors? Jul 16 22:24:02 journalctl -f is killed using ctrl-C, plain journalctl runs its output through a pager ("less"), which you exit using q Jul 16 22:24:41 also, I've told you to first get programs working when executed manually *before* trying to make them into a service Jul 16 22:24:56 That is correct. Jul 16 22:25:05 I forgot totally about that conversation. Jul 16 22:25:46 looks like that error means "no barometer was configured", so that may be a build configuration issue (since the blue does have one) Jul 16 22:26:03 That is what I thought. Jul 16 22:26:24 If you do not get too bored reading this material, here: https://github.com/imfatant/test/issues/5. Jul 16 22:26:41 That is mean querying a person about the arducopter/ardupilot program. Jul 16 22:26:53 mean = me Jul 16 22:26:54 Sorry. Jul 16 22:27:30 There was a file that was supposedly a "fix all" for the issue at hand. Jul 16 22:27:42 I'm reading the gitter thread Jul 16 22:27:48 Okay. Jul 16 22:28:13 Not too much on sense but people know stuff there, obviously. Jul 16 22:29:12 What address is the barometer located? Jul 16 22:30:31 0x76 Jul 16 22:30:42 How did you know that? Jul 16 22:30:46 datasheet Jul 16 22:30:50 Aw! Jul 16 22:30:55 hm, what's that 0x0c Jul 16 22:30:55 I am looking up datasheets now. Jul 16 22:31:01 I do not know. Jul 16 22:31:06 I have nothing plugged in. Jul 16 22:31:27 There are no other devices except what comes w/ the board. Jul 16 22:31:31 so somehow the barometer is responding at the wrong address? it really must be confused Jul 16 22:31:39 Ha! Jul 16 22:32:40 I am opening up the schematic now. Jul 16 22:33:01 try disabling any services of yours. then fully power off and back on, and try i2cdetect again Jul 16 22:33:26 Okay. Jul 16 22:33:36 (I'm not a fan of using that, but based on what the dude on gitter said it seems that it should be safe for these two devices) Jul 16 22:33:51 Okay. Jul 16 22:33:57 Please hold. Jul 16 22:34:43 Can I just reboot? Jul 16 22:34:46 no, power off Jul 16 22:34:57 Sir, okay but... Jul 16 22:34:59 This is the issue. Jul 16 22:35:04 if reboot were okay, I would have said reboot, not "fully power off and back on" Jul 16 22:35:34 At the 12v barrel jack power supply, there is an On LED. Jul 16 22:35:39 It stays lit no matter what. Jul 16 22:35:44 that's okay Jul 16 22:35:45 What do you think of this issue? Jul 16 22:35:47 Okay! Jul 16 22:35:49 Great. Jul 16 22:35:53 So, sudo poweroff? Jul 16 22:36:09 Or power button? Jul 16 22:36:20 whichever works Jul 16 22:36:25 Okay. Jul 16 22:36:29 is there any reason you can't unplug the 12v ? Jul 16 22:36:40 It is not plugged in. I am on by USB. Jul 16 22:36:49 oh, or that Jul 16 22:37:04 I can unplug it. I just thought poweroff was safer. Jul 16 22:37:10 poweroff, then unplug Jul 16 22:37:15 Gotcha! Jul 16 22:37:54 poweroff probably suffices Jul 16 22:38:03 but unplugging is the easy way to be sure Jul 16 22:38:20 I used poweroff and then unplugged it. I plugged it back in. I am waiting for it to boot. Jul 16 22:38:25 the reason reboot is not useful is because the barometer and imu have no reset line, so a system reboot does absolutely nothing to them Jul 16 22:38:38 Okay. Jul 16 22:38:45 That is some juicy info. Jul 16 22:38:50 I was unaware of that. Jul 16 22:39:24 so the only way to reset them is by cycling their power (the 3.3v supply) Jul 16 22:39:51 lemme see if I can find a better way to check the barometer than i2cdetect Jul 16 22:40:03 Oh. Hey, you know what. I stopped the service yesterday but I did not disable the service. Jul 16 22:40:04 Okay. Jul 16 22:40:13 I disabled it today. Jul 16 22:40:17 stop and disable are very different things Jul 16 22:40:22 I know. Jul 16 22:40:27 stop = stop it right now, disable = make sure it's not started at boot Jul 16 22:40:35 sidetracked. Jul 16 22:40:41 Right. it removes the symlink. Jul 16 22:41:43 i2cget -y 2 0x76 0xD0 Jul 16 22:41:48 Okay. Jul 16 22:41:51 That is the cmd? Jul 16 22:41:51 should be safer than i2cdetect Jul 16 22:41:54 Okay. Jul 16 22:42:12 Should I look for those addresses or type them in like you have them typed out? Jul 16 22:42:23 copy-paste that exact command Jul 16 22:42:26 Okay. Jul 16 22:43:18 0x58? Jul 16 22:43:24 that's good Jul 16 22:43:27 Yea! Jul 16 22:43:30 barometer is alive and well Jul 16 22:43:37 That you BBBlue. Jul 16 22:43:55 whatever you did to confuse it previously, try to avoid doing that again Jul 16 22:44:15 So, it may be there .cpp or compiled software for barometers that interfere. Jul 16 22:44:27 Hmm. Jul 16 22:44:32 It may just be the service file. Jul 16 22:45:20 See, I am making a quadcopter like the one that Mr. Kridner made on that Gist he produced. Jul 16 22:45:25 I have no idea what could cause it. my guess would be either software doing some really bogus transaction to the barometer, or maybe something like an electrostatic discharge Jul 16 22:45:30 or voltage glitch Jul 16 22:45:41 Hmmm. It has to be software. Jul 16 22:45:57 B/c, as soon as I start their service file they produced, it gets funky. Jul 16 22:46:32 Hmm. It may be a bunch of different software that was compiled and causing issues. You are right. I do not know either. Jul 16 22:49:18 zmatt: If you have more time, I would like to know what you think about me not using a barometer on my "Flight Plan." Jul 16 22:49:20 don't forget to mention on gitter that it turned out to be a confused barometer fixed by power cycling Jul 16 22:49:26 Okay. Jul 16 22:49:27 Yes sir. Jul 16 22:49:45 I don't know anything about or have any opinions on flight control software Jul 16 22:49:51 Okay. No issue. Jul 16 23:41:23 how do i flash beagleboard x15 Jul 16 23:42:14 hello? anyone there? Jul 16 23:42:47 patience is a virtue. people generally only glance occasionally at chat Jul 16 23:42:57 ok Jul 16 23:44:20 you can find the latest images at https://beagleboard.org/latest-images Jul 16 23:45:31 I already have the latest image. I flashed to an SD card and im trying to flash it to the eMMC of the X15 Jul 16 23:45:53 okay, there's a line in /boot/uEnv.txt you can uncomment to turn the sd card into an eMMC-flasher card Jul 16 23:46:37 right but i cant even get to debian for some reason Jul 16 23:47:23 you mean you can't boot from the sd card? or can't log into the resulting system? since if so, that should first be resolved Jul 16 23:47:46 how do i resolve that? Jul 16 23:48:47 "cant even get to debian" is a too vague problem description to offer any diagnosis really Jul 16 23:49:20 so i insert the sd card on the x15 and im waiting for about 15 minutes. Jul 16 23:49:31 uhh, waiting for what? Jul 16 23:50:21 first, which image did you download exactly? Jul 16 23:50:26 waiting for boot sequence, i then tried pinging 192.168.7.2 while is connected to usb client but no response Jul 16 23:52:15 i download debian 9.4 2018-06-17 4GB SD LXQT image for beaglbone -x15 Jul 16 23:53:11 ah, latest-images actually only has one for bbx15, sorry my bad Jul 16 23:53:11 ok Jul 16 23:54:07 after inserting the card and hitting the power button, is there led activity? Jul 16 23:55:08 yes but about 20 minutes later the leds come to a top and one led is remain on Jul 16 23:55:28 huh Jul 16 23:55:36 it powers off? Jul 16 23:55:39 that's weird Jul 16 23:56:33 sorry i meant after 20 minutes the leds stop and only one led remains on Jul 16 23:57:20 only led on = board is powered off. that one remaining led just indicates 12V input power is present Jul 16 23:58:25 there's always a second led on when the board is powered on (it's the first led that turns on when you press the power button) Jul 16 23:59:49 yes that one and the led near the power switch are on but there is a third led that still on. is labeled d4 Jul 17 00:00:55 okay it really helps if you describe what happens accurately, since "one led remains on" is not the same as "three leds remain on" :P Jul 17 00:01:19 if the user leds completely freeze that sounds like it might be a kernel panic Jul 17 00:02:00 does the board ever appear as usb network device when it's connected via usb? Jul 17 00:02:52 also, have you verified the content of the sd card after flashing to exclude the possibility of a bad/flaky sd card? (some software like etcher.io does automatically) Jul 17 00:05:59 sorry you're right i should be more descriptive i just assumed we were talking about the user leds already. what should i do if it is a kernel panic? The board does not appear on my device manager while using usb Jul 17 00:07:04 do you get any output if you connect a monitor or tv via hdmi? Jul 17 00:07:34 none at all Jul 17 00:07:39 hmz Jul 17 00:08:13 well the first thing that comes to mind is to reflash the sd card and verify its contents after flashing, or try a different sd card if you have one Jul 17 00:08:32 ok ill try that Jul 17 00:14:05 I don't suppose you have a 3.3v usb-serial cable, to be able to monitor the serial console? Jul 17 00:14:41 yes i do but im redownloading the image and getting it ready to reflash Jul 17 00:14:47 sorry slow internet Jul 17 00:15:58 It is possible to interface the BBB with the DE0-Nano FPGA, through the memory bus? Jul 17 00:16:30 sure Jul 17 00:16:34 Jcat93: the serial console typically helps a lot when debugging boot issues, since you'll probably be able to see exactly what goes wrong Jul 17 00:16:45 or at least when it goes wrong Jul 17 00:17:13 ok ill start setting that while the image is downloading Jul 17 00:17:46 CoffeeBreakfast: note however that using the gpmc conflicts with using eMMC Jul 17 00:19:41 CoffeeBreakfast: data in or data out? what's the direction of data flow Jul 17 00:20:08 or did you mean the memory bus of that fpga? Jul 17 00:20:20 oh that's a cute little board Jul 17 00:20:21 ds2: both Jul 17 00:20:45 PRU is an alternative Jul 17 00:21:18 I'm thinking in buying that little board, and keep with the BBB, instead of a full SoC like the DE10-Nano Jul 17 00:22:08 what sort of bandwidth needs? Jul 17 00:22:59 wonder if the 2nd ethernet's MII is exposed on theexpansion port Jul 17 00:23:23 lcdc can also act sort of like a memory bus controller (without conflicting with eMMC) Jul 17 00:23:29 ds2: it isn't Jul 17 00:23:52 blah Jul 17 00:24:59 CoffeeBreakfast: what kind of processing are you thinking doing on the FPGA? Jul 17 00:26:57 uhmm I don't know right now the bandwidth, just planning Jul 17 00:27:15 nice thing about an FGPA is you can use other interfaces besides GPMC Jul 17 00:27:31 yeah there are a bunch of options with different trade-offs Jul 17 00:36:33 afk, back in half an hour or so Jul 17 00:38:35 No! Jul 17 00:38:51 Do .dtb files need to set as executable? Jul 17 00:47:11 zmatt I just flashed the sd card and booted the x15 it looks like there there is an error mmc0: -110 whilst initializing sd card Jul 17 00:51:37 no idea set_ Jul 17 00:54:02 I am reading now about these files and how they are used but I am far behind and I think u-boot is used now, anyway. Jul 17 00:54:04 Yikes! Jul 17 00:55:59 So, the overlay part is for booting purposes but I can still use a .dtbo in our uboot-overlays. Jul 17 00:56:08 ... Jul 17 00:56:48 See, I got this new file w/, what i have found recently, that should help me on boot w/ the ArduCopter and the BBBlue. Jul 17 00:56:54 e.g. .dtb Jul 17 00:57:12 Oh well. Jul 17 00:57:16 I am off to learn! Jul 17 01:05:42 ds2: a DSP coprocessor (for the BBB) implemented in the FPGA would be great Jul 17 01:36:11 DSP for what? Audio? Jul 17 01:36:22 if so, an I2S or TDM interface may work nicely Jul 17 01:46:26 we need a lot of matrix manipulations basically Jul 17 01:46:38 for non-audio too. for a continuous data stream, mcasp is probably one of the best options Jul 17 01:48:06 with data coming from a lot of instrumentation amplifiers Jul 17 01:49:13 (note that the Neon unit of the cortex-a8 can actually perform a decent amount of computation too) Jul 17 01:53:13 First we will try with the Neon unit Jul 17 01:54:26 for a performance indication of using mcasp as interface: there are two instances, mcasp0 has up to 4 data pins, mcasp1 has up to 2 data pins, and iirc the max rate is 25 Mbps (per data pin) Jul 17 01:55:28 the two instances mean you can use one in master mode for bbb -> fpga and one in slave mode for fpga -> bbb, which should ease timing closure and allows the two to run at different rates Jul 17 01:57:31 You mean, send data to the fpga, through mcasp0, do the heavy dsp, and back the result through mcasp1? Jul 17 01:57:46 yep, something like that Jul 17 01:57:51 if it fits your use case Jul 17 01:58:27 even if it is non audio? Jul 17 01:59:01 bits are bits, neither the kernel nor the hardware cares what those bits mean Jul 17 02:00:05 the main limitation is that it's a constant data stream, although you could of course format packets of some sort over it Jul 17 02:01:59 only issue is the data rate on the McASP is a bit limited for non audio apps Jul 17 02:02:06 (ie. video won't work) Jul 17 02:02:44 I think you're going to have trouble getting *much* more bandwidth by other means though Jul 17 02:03:38 do you know the max bandwidth? Jul 17 02:03:54 the max baudrate* Jul 17 02:04:02 of mcasp? I stated that above Jul 17 02:04:28 the PRU Jul 17 02:04:53 high-bandwidth outbound data via PRU is non-trivial though Jul 17 02:09:49 I think the that baudrate is enough Jul 17 02:10:33 sorry for that sentence Jul 17 02:10:58 all the right words were there ;) Jul 17 02:13:27 probably one of the highest bandwidth solutions would be PRU for inbound data (e.g. clock + 8 data bits ddr) + lcdc for outbound data... it would be a bit hacky though ;) Jul 17 02:13:56 good point Jul 17 02:17:43 I wonder what the max (reliable) rate would be for the inbound data... I think 50 MT/s should definitely be achievable? Jul 17 02:22:06 so that would be 4 times the max rate of mcasp0, and perhaps a more convenient data layout Jul 17 02:22:46 the max rate of the mcasp is 25 Mbps? Jul 17 02:23:09 25 Mbps x 4 versus 50 Mbps x 8 Jul 17 02:33:17 and can we use (for example) a TMS320 instead of the FPGA? Jul 17 02:36:05 I considered saying earlier "why not use a DSP to do DSP?" Jul 17 02:36:58 but also, is the beagleboard-x15 worth considering? it has two TMS320C66x DSPs as part of the SoC. it might be a bit overkill/expensive though I guess (and the expansion connectors are no fun to deal with) Jul 17 02:38:09 "TMS320" is pretty vague though, it encompasses some very different architectures Jul 17 02:38:51 also we need to reduce costs, linux is mandatory, and we need to think alternatives before switch to the X15 Jul 17 02:44:21 step 1 of course is to evaluate Neon. if you manage to keep its pipeline flowing it can do four 16x16->32 bit integer MACs per cycle or two 32x32->64 bit integer MACs per two cycles, or two single-precision floating point ops per cycle Jul 17 02:44:24 Any DSP with floathing point, and McASP Jul 17 02:46:10 Sorry, when I said "TMS320" I intended to keep open the options Jul 17 02:49:26 floating point is pretty unusual among DSPs. for TI you'd be looking at a C674x or C66x I think, but those are really SoCs, not merely DSPs Jul 17 02:50:31 I mean, they're also names of DSP cores, but the discrete parts with those names are pretty substantial (C674x) or obscenely huge (C66x) SoCs Jul 17 02:51:06 I will ask my mentor, maybe we could use fixed point dsp Jul 17 02:51:41 He knows better the details of the problem **** ENDING LOGGING AT Tue Jul 17 03:00:03 2018