**** BEGIN LOGGING AT Wed Feb 07 03:00:02 2018 Feb 07 06:06:13 hello all, i was getting started with using the pru cores on the beagle bone Feb 07 06:06:35 now I wanted to know, whether i need to create a device tree for my led blinking program as i am using the beagle bone lbue Feb 07 06:06:40 blue* Feb 07 08:34:01 I've got a BeagleBoard b6 board that seems to be totally dead, I've got it connected to my PC through serial port but when I power it on I get nothing at all Feb 07 08:40:57 Hi Feb 07 08:45:28 hi Feb 07 12:22:26 hello all, I noticed that the USR_LEDs and the RED and GREEN led on the beagle bone blue don't have a PRU mode, Feb 07 12:22:49 so does that mean i cannot control them via the PRU? Feb 07 12:30:30 the am355x_pru_package is not supported by TI anymore? Feb 07 12:30:45 i am running stretch 9.3 and can't find it Feb 07 12:41:07 Does anyone have some advice on unbricking a beagleboard? Feb 07 12:47:20 pru_blue: you can control them through the OCP GPIO Feb 07 12:48:05 sulphurik: check out bbb.io/start Feb 07 12:49:36 Unfortunately I’m not getting anything through serial boot or anything at the moment Feb 07 12:52:25 did you hold the SD/BOOT button when you applied power? Feb 07 12:52:37 Yeah Feb 07 12:52:59 and flashing the microSD was incident free? Feb 07 12:53:16 do you get the power LED to come on and stay on? Feb 07 12:53:19 Well I have an original beagleboard....not a beagle bone Feb 07 12:53:27 But yes the power light comes on Feb 07 12:53:47 Oh. Should be the same deal. Which rev? Post C4? Feb 07 12:53:57 B6 Feb 07 12:54:17 You might try the older image. The new one isn’t well tested yet. Feb 07 12:54:23 Ah. Robert hasn’t validated with B6. :-( Feb 07 12:54:44 I have one I can test with, but he used a C4. Feb 07 12:55:32 I believe the RAM changed. Feb 07 12:55:39 My concern is that I can’t get anything when connecting the serial port at power on....no messages at all Feb 07 12:55:49 Like, nothing Feb 07 12:56:02 yeah, you should still get the CCCC at the right baud. Feb 07 12:56:21 if using the BOOT button. Feb 07 12:57:12 I set up minicom on 115200 Feb 07 12:57:23 on the right tty Feb 07 12:58:27 I might be able to swap a board for you. Not sure how else to resolve. Where are you located? Feb 07 12:58:35 uk Feb 07 12:58:38 you? Feb 07 12:58:57 US Feb 07 12:58:58 I'm happy to post the board to someone to look at Feb 07 12:59:20 What’s your use? Would an xM work? Feb 07 13:00:03 I just wanted to get it working, it was a gift many years ago and I've played with it on and off for ages Feb 07 13:01:20 most likely I'll end up using it as nas Feb 07 13:02:04 it would be good to understand how it died. i’d worry a bit about it sitting around here. Feb 07 13:02:10 getting you an xM would be easy. Feb 07 13:02:21 That would be cool Feb 07 13:02:42 I'm guessing it should be fixable but I've tried everything. Feb 07 13:03:06 sulphurik[m]: jtag? Feb 07 13:03:16 Well, everytning i can think of Feb 07 13:03:20 :-) Feb 07 13:03:33 The lack of serial boot attempts is alarming. Feb 07 13:04:01 yeah, and XDS100v2 would be handy. Feb 07 13:04:04 could be a shot uart? the board doesn't have a usb/serial adapte Feb 07 13:04:07 s/and/an/ Feb 07 13:04:17 Really don't know how to do jtag but I'm sure that would be one way to fix it Feb 07 13:04:20 Hello, I'm trying to compile a C-program for the BeagleBone Blue. I've got compiler errors on my program, I've also got compiler errors on the rc_project_template.c located in /usr/share/roboticscape/rc_project_template Feb 07 13:04:20 Do anyone know what could be wrong? The errors goes away when I have a "empty" program, but with rc_initialize() or rc_cleanup() in the program I've get errors Feb 07 13:05:02 or does it... Feb 07 13:05:48 undefined reference to `rc_initialize' Feb 07 13:05:49 thinkfat: it's got usb otg and serial Feb 07 13:06:26 jkridner: yeah everything i've read says it should always show something through serial Feb 07 13:19:10 peroyvib: sounds like you're not linking against the library? Feb 07 13:20:01 peroyvib: are you using the provided Makefile ? Feb 07 13:20:23 zmatt: Yes, and I have #include Feb 07 13:21:47 can you provide a transcript of command you're using to compile it and the output it produces? (use a paste service such as pastebin.com) Feb 07 13:29:13 zmatt: Now I can compile, I just have some other issues. I did use gcc instead of make Feb 07 14:30:16 hello all, i am trying to use py_pruss to load the pru program Feb 07 14:30:24 but on my blue it is not working Feb 07 14:30:30 it keeps throwing a buffer overflow error Feb 07 14:30:37 can someone please help me with this Feb 07 14:34:57 is anyone eonline Feb 07 15:00:10 (evidently not within the few minutes you were here) Feb 07 15:00:33 lol Feb 07 15:24:17 I've got a problem with some of the GPIO-pins on BeagleBone Blue Feb 07 15:24:17 BLUE_GP0_PIN_6 with pin number 113. But on BLUE_GP0_PIN_3,4 and 5 give me: "gpio/direction: No such file or directory" when setting direction, and gpio/set-value: "No such file or directory" when setting value. Feb 07 15:24:48 BLUE_GP0_PIN_6 works Feb 07 15:25:25 * zmatt checks pins spreadsheet Feb 07 15:26:34 hm Feb 07 15:38:11 * zmatt makes a bbblue version of his show-pins script Feb 07 15:51:09 peroyvib: see if my script indicates anything interesting for the pins you can't control: https://github.com/mvduin/bbb-pin-utils/tree/blue#show-pins Feb 07 16:37:18 zmatt: Thank you, I have left the university (where my project are) for today. I will look into it tomorrow. Feb 07 16:39:29 hi there, is barebox the preferred bootloader nowadays for BBB ? or do people still use mainly u-boot? I am setting up a toolchain and I wonder which bootloader will make things easier, I am planning to use tftp and nfs Feb 07 16:46:22 anyone online who could help me with a few doubts about the pru cores on the blue? Feb 07 16:52:45 jsolano: I've never heard of anyone using barebox Feb 07 16:54:22 anyone online who could help me with a few doubts about the pru cores on the blue? Feb 07 16:54:52 pru_python: the only way to find out is by actually asking your question and then sticking around Feb 07 16:55:25 (plenty of knowledgeable people tend to look at irc every now and then so it can take time to get a response) Feb 07 16:56:04 right, sorry: I need to write a PPM Signal Decoder using the PRU cores, which forms a small part of a larger project which is written in python. Hence I wanted to use PyPRUSS to program the PRUs Feb 07 16:56:17 pru_python: still around? Feb 07 16:56:42 pru_python: There's already a PPM signal decoder written for the PRU on Blue. Feb 07 16:56:53 jsolano: you can replicate the standard bootloader used on the bbb by grabbing a mainline u-boot release and applying the "0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch" and "0002-U-Boot-BeagleBone-Cape-Manager.patch" patches from the appropriate subdir of https://rcn-ee.com/repos/git/u-boot-patches/ Feb 07 16:57:04 pru_python: it is integrated into ArduPilot. Feb 07 16:57:14 I have read up on PRU literature (not the TI RM!, but derek molly's book) but I cannot use PyPRUSS to load my firmware onto the PRU, it throws a "buffer overflow error" Feb 07 16:57:19 big element is that it uses the eCAP module w/in the PRU. Feb 07 16:57:41 pru_python: hmmm.... did you switch from RPROC to UIO? Feb 07 16:57:55 I *believe* PyPRUSS uses the old UIO interface. Feb 07 16:58:12 Here's my ArduPilot install instructions: https://gist.github.com/jadonk/6080ca92d6e225eb89d33ad7744e1775 Feb 07 16:58:29 uio++ Feb 07 16:58:35 I ran "modprobe_uio" from the terminal of the BBB Feb 07 16:58:50 you normally never need to modprobe anything Feb 07 16:58:53 zmatt: thanks, I wasn't aware we need to apply a patch to u-boot, I thought it was supported by the mainline build Feb 07 16:59:18 I understand that AP has a PPM decoder, but I cannot understand where it is giving out the decoded pulse lengths Feb 07 16:59:27 jsolano: afaik it mostly is Feb 07 17:00:04 echo "uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo" >> /boot/uEnv.txt Feb 07 17:00:04 echo "enable_uboot_overlays=1" >> /boot/uEnv.txt Feb 07 17:00:32 @jkridner Just out of curiosity btw, using a normal I/O library for catching interrupts on GPIOs is generally a bad idea right? Feb 07 17:00:50 jsolano: the patches may include fixes that haven't reached mainline yet, changes in default config Feb 07 17:01:06 what is the "normal I/O library"? Feb 07 17:01:12 @jkridner: would you mind explaining what that does, i am not well versed in embedded linux :( Feb 07 17:01:19 something like the adafruit BBIO Feb 07 17:01:26 catching interrupts on the GPIO is a fine thing. Feb 07 17:01:42 pru_python: it wouldn't necessarily be bad, but it depends what you are trying to do. Feb 07 17:01:54 jkridner: ew for just appending those lines instead of uncommenting the existing ones Feb 07 17:01:54 pru_python: the "Linux way" to do it is to make a kernel module. Feb 07 17:02:32 zmatt: avoid the case where there's already an assignment. needed to provide newbs with something scriptable. Feb 07 17:02:54 * jkridner does like to write perl -i.bak -pe foo Feb 07 17:03:00 jkridner: I understood the motivation, that doesn't make it less ew :P Feb 07 17:03:23 indeed. but, you'd never run it and it documents what you *would* do. :-) Feb 07 17:03:40 jkridner: besides, I'd hope that anyone who is doing programming of any sort is able to find a line in a config file and uncomment it Feb 07 17:04:03 maybe I'm being naive here :P Feb 07 17:04:08 * jkridner checks out https://github.com/ArduPilot/ardupilot/blob/2d2ed7b06e8df3631d5d5ce92183cc8ba4fc2784/Tools/Linux_HAL_Essentials/README.md Feb 07 17:04:16 jkridner: I was referring to catching the PPM signal on the gpio via the adafruit library. Feb 07 17:04:18 I would love to understand how to use the PRU, but since my project is an implementation of my theory, I have a limited time frame :( Feb 07 17:04:21 yucky old instructinos. Feb 07 17:04:33 pru_python: I'd never do that. Feb 07 17:05:20 pru_python: there are multiple eCAP peripherals that drastically reduce the CPU cycles for PPM monitoring and provide tremendous more timing reliability. Feb 07 17:05:34 pru_python: to try to do it with GPIOs in userspace.... I'd never trust it. Feb 07 17:05:57 pru_python: creating an ARM-side kernel module that uses eCAP, that'd be fine... Feb 07 17:06:08 eCAP is great for things like pulse width. eQEP is usually better for pulse counting or pulse frequency Feb 07 17:06:09 pru_python: but the PRU-size eCAP makes the most sense. Feb 07 17:06:37 zmatt: true, but let's explore the ArduPilot code. looking for it now. Feb 07 17:07:05 umm.... im terribly sorry but i don't know how to use the eCAP mode Feb 07 17:07:07 using eCAP for pulse frequency still requires handling an irq every 1-4 pulses Feb 07 17:07:13 could you point me to some docs? Feb 07 17:07:17 I don't know what sort of frequency we're talking about here? Feb 07 17:07:25 seems to be in https://github.com/ArduPilot/ardupilot/tree/2d2ed7b06e8df3631d5d5ce92183cc8ba4fc2784/Tools/Linux_HAL_Essentials/pru/rcinpru Feb 07 17:07:43 ahh, never mind Feb 07 17:07:49 I misunderstood what ppm meant Feb 07 17:08:10 looks like they kept the PRU pretty dumb here: https://github.com/ArduPilot/ardupilot/blob/2d2ed7b06e8df3631d5d5ce92183cc8ba4fc2784/Tools/Linux_HAL_Essentials/pru/rcinpru/rcinpru0.c Feb 07 17:08:11 ok yeah, eCAP is definitely the right peripheral to use for that Feb 07 17:08:54 just throws pulse-widths into a ring buffer. Feb 07 17:09:15 does the am335x_pru_package have examples using the eCAP mode? Feb 07 17:09:20 using eCAP and handling it in userspace should be fine for most purposes, if you just need a recent measurement and not necessarily measure every single pulse Feb 07 17:09:38 no need for PRU in that case Feb 07 17:10:31 then fetched on the ARM side here: https://github.com/ArduPilot/ardupilot/blob/6c6515711c8960a634841b5e0e130d8f5f3b67df/libraries/AP_HAL_Linux/RCInput_AioPRU.cpp Feb 07 17:11:09 they could have made the PRU much smarter. Pretty much just using it for "smart dma" Feb 07 17:11:18 creating that ring buffer Feb 07 17:11:59 guess they are leveraging existing userspace code to interpret the pulse-widths. Feb 07 17:13:05 Yes, it differentiates between a variety of protocols Feb 07 17:13:34 pulse processing in https://github.com/ArduPilot/ardupilot/blob/dab29fd9462370539ab65e4c4f104da7bd3928a3/libraries/AP_HAL_Linux/RCInput.cpp Feb 07 17:13:49 https://github.com/ArduPilot/ardupilot/blob/dab29fd9462370539ab65e4c4f104da7bd3928a3/libraries/AP_HAL_Linux/RCInput.cpp#L320 Feb 07 17:14:31 interesting that it just tries to treat it as all the protocol types. Feb 07 17:17:08 for up to 3 channels I would probably just use map an eCAP instance into userspace and use that. above that I'd use PRU, with or without eCAP. (or maybe eCAP + edma from userspace but only because I'm nuts and I've already done that in the past :P ) Feb 07 17:17:56 jkridner: umm... even with sudo, im not being allowed to run echo "uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo" >> /boot/uEnv.txtecho Feb 07 17:18:19 oh. Feb 07 17:18:26 wait nvm Feb 07 17:18:38 eesh that was stupid -_- Feb 07 17:18:42 sorry about that Feb 07 17:19:44 umm but the pypruss error is still existent, every time I run pypruss.modprobe() : *** buffer overflow detected ***: python terminated Feb 07 17:20:02 what is it trying to do? Feb 07 17:20:06 it shouldn't be modprobing anything Feb 07 17:20:16 also wtf is that weirdass error Feb 07 17:20:46 oh wow it hasn't been updated in ages it seems Feb 07 17:21:01 * jkridner added sudo's to https://gist.github.com/jadonk/6080ca92d6e225eb89d33ad7744e1775 Feb 07 17:21:16 use echo blah, blah | sudo tee -a blah Feb 07 17:21:50 the problem with using "sudo echo blah > blah" is that "echo" runs as root, but the write is still done as debian. Feb 07 17:21:51 im just running the command because in the examples given in the pypruss git (https://github.com/HudsonWerks/pypruss/blob/6edbddbb2172a934cf93b3113a03b7a8c7a0a6fd/examples/blinkled/blinkled.py#L7) Feb 07 17:22:11 it has been mentioned to run it only once per boot Feb 07 17:22:25 jkridner: Thanks for that info! never knew that! Feb 07 17:22:26 https://github.com/HudsonWerks/pypruss assumes much older images.... Feb 07 17:22:38 maybe I should fork and update. Feb 07 17:22:49 so does it mean the python wrapper is rendered unusable? Feb 07 17:22:56 that would be amazing !! Feb 07 17:23:35 i guess the only thing would be to use the remoteproc library, and write it as a wrapper to be used in a python code? Feb 07 17:23:38 I don't really immediately see the buffer overflow in the pypruss_modprobe code though Feb 07 17:24:13 pru_python_: uio-pruss is fine, it's probably just something silly in that python wrapper that's broken Feb 07 17:25:59 zmatt: probably. Seems like it might be really needed for the community to have a Python wrapper that used remote-proc. Feb 07 17:26:25 is it the ddr size? Feb 07 17:26:28 that worked out-of-the-box. Feb 07 17:26:47 sorry i got timed out... Feb 07 17:27:54 pru_python: looks like the cmd[] buffer overflows if ddr_size >= 0x10000000 (256MB, which would be a silly amount of memory to allocate for most purposes anyway) Feb 07 17:28:33 but, just start by skipping that call entirely since uio_pruss already get loaded automatically at boot anyway, hence that call to modprobe does absolutely nothing (when it doesn't crash) Feb 07 17:28:46 okay thats reassuring Feb 07 17:29:19 I also don't understand why anyone would implement that in C instead of in pure python Feb 07 17:29:50 i couldn't find ANY other python firmware loader Feb 07 17:30:08 I mean the modprobe method specifically Feb 07 17:30:30 one more teeny question, according to what i understood about device trees, the pins you want to talk to need to be setup for "pru mode" right? but I can't see a pru mode for the USR lets on the blue Feb 07 17:31:20 leds* Feb 07 17:31:37 pru mode gives the pru particularly efficient direct access to a pin, but isn't available for all pins Feb 07 17:32:32 so i can control pins that don't have the pru mode via the pru?! Feb 07 17:32:44 you can, via the normal gpio peripherals Feb 07 17:32:53 it's just not as efficient or precisely timed Feb 07 17:33:18 ok thanks for that but of info Feb 07 17:33:20 like, it could easily jitter for dozens of nanoseconds Feb 07 17:33:35 btw this seems like a boon for a noob: https://github.com/nesl/Cyclops-PRU Feb 07 17:34:02 yeah I read a bit about it Feb 07 17:34:32 shoudldnt it be given more attention/support? Feb 07 17:35:07 it will drastically reduce the learning curve and make the PRU much more accessible to application based developers Feb 07 17:35:42 it sounds like a good idea. I'm not really the right person to speak to about that :) Feb 07 17:35:42 i for example am not a developer o=whatsoever, I study controls for aerospace engineering and wanted to implement my control scheme on a quadrotor drone Feb 07 17:36:03 haha alright :p Feb 07 17:36:23 I'm just a random guy who uses beaglebones at work Feb 07 17:38:14 do you have any pointers I should keep in mind while writing the signal decoder, seeing as I am a complete newb to this? Since the signal decoder will be running in the bang round, would it be stupid to put it in a while(1)? Feb 07 17:38:30 it wouldn't actually be hard to implement a pure-python interface to uio-pruss... it's too bad that I really don't like python very much Feb 07 17:39:02 what does it do? Feb 07 17:39:48 well as the main quadrotor code is running on the ARM, I was planning to use one of the PRUs to read the signal for the radio transmitter and send the decoded pulse widths back to the code running on ARM Feb 07 17:40:29 and the other PRU to write a particular PWM value (that will come from the main quadrotor code) to the servo channels Feb 07 17:40:41 on the pru it's not a problem to just spin in an infinite loop, although using the sleep instruction might save some power (probably not significant compared to things like motors though) Feb 07 17:41:39 okay and about the eCAP mode you mentioned, where can i find any examples/docs about it? Anything other than the TI RM???? Feb 07 17:41:44 module* Feb 07 17:41:49 yeah as long as you only have two tasks to do in parallel, using one pru core for each is a good way to keep your code simple Feb 07 17:43:35 okay, also just to confirm, i can skip the pypruss.modprobe() function while writing the loader correct? Feb 07 17:43:42 depending on your requirements, it may be simpler to not use eCAP unless it's imperative to be able to measure the pulses with 10ns precision Feb 07 17:43:54 no it is not Feb 07 17:44:14 the pulse widths are of the order of microseconds ! :) Feb 07 17:44:36 uio-pruss should already be loaded (check lsmod). if it isn't, probably your /boot/uEnv.txt isn't correctly configured Feb 07 17:44:44 ah right, so pru can grab a cup of coffee in between pulses Feb 07 17:44:52 zmatt: lol Feb 07 17:44:58 ahahah true ! Feb 07 17:46:24 well i think I have the errors sorted out ! I think I might have the test bed ready by this weekend! jkridner and zmatt thanks a lot for your time! Feb 07 17:47:10 the main disadvantage of using the PRUSS eCAP is that there's only one specific pin for it (the fourth encoder input on the blue) Feb 07 17:48:29 oh! thats why the ardupilot codebase uses that specific pin! Feb 07 17:48:37 and it might require more code than just doing it the stupid way... although you'll need to set up a timer of some sort anyway Feb 07 17:48:54 (if not eCAP then one of the IEP timers probably) Feb 07 17:48:54 but like you said, i could configure any other pin for catching the interrupts right? Feb 07 17:49:05 which interrupts? Feb 07 17:49:08 since the pulsewidths are microseconds long Feb 07 17:49:12 the signal rises Feb 07 17:49:42 the PPM signal rising edges etc.. Feb 07 17:49:43 if you're using pru you wouldn't use an interrupt, you'd just poll the pin Feb 07 17:50:22 ah interesting Feb 07 17:51:13 and keep track of how many times it reads it as high? Feb 07 17:53:12 you can either do cycle-counting or read some hardware timer/counter when you observe the signal transition Feb 07 17:53:49 if programming in C, the latter is your only option Feb 07 17:54:08 Id be writing the firmware in assembly Feb 07 17:54:15 then either option is available Feb 07 17:54:18 as i am referring to derek molloy's book Feb 07 17:55:05 i don't have a clue about all the features the PRU has, Feb 07 17:55:16 so i feel id be better of counting the number of times its high Feb 07 17:55:41 sure Feb 07 17:56:13 okay thanks a lot Feb 07 17:56:17 in sufficiently simple use-cases, cycle-counting is definitely the simpler option. and your case seems sufficiently simple Feb 07 17:56:41 could you give an example in where you would need to use a timer Feb 07 17:57:53 if you want to be able to do other things while waiting, without the headache of having to do careful bookkeeping of how many cycles are being spent (which may even be impossible to do reliably when using loads/stores) Feb 07 17:58:33 out of curiosity, could the peripherals like an IMU be read using the PRU, or would this be impractical? Feb 07 17:59:18 or if you want to be able to use the sleep instruction to pause the core while waiting for a signal to go high (e.g. to save a bit of power) Feb 07 18:00:46 PRU can access basically all resources on the SoC, but for most peripherals PRU would need exclusive access, i.e. linux should not have a driver loaded for it Feb 07 18:01:04 in case of i2c, that means PRU would need exclusive access to the whole i2c bus, not just one device on it Feb 07 18:01:56 Hmmmm multimaster I2C Feb 07 18:02:34 but would it be hard to implement, rendering it impractical Feb 07 18:03:31 https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/I2C-Master-Controller Feb 07 18:03:40 pru_python: not very hard I guess... not sure how to measure that Feb 07 18:03:51 okay cool Feb 07 18:04:05 looks like what you just linked is a pure-pru implementation Feb 07 18:04:09 thanks again! :p Feb 07 18:04:33 rather than using an i2c controller Feb 07 18:05:34 so that probably means it will hog the pru core (since it needs to do bit-banging) for a long time (i2c is slow) Feb 07 18:07:10 if using one of the i2c controllers pru needs to do much less work and only occasionally check for completion Feb 07 18:07:34 oh you left Feb 07 18:18:39 does anyone know what layout program the beagle X15 was design in? Feb 07 18:19:53 might be allegro? Feb 07 18:20:40 yeah Feb 07 18:21:11 allegro/orcad Feb 07 18:27:39 so the X15 circuit board was designed in allegro? The only problem I have now is that I can't import the X15 .brd design file into altium unless I also have the allegro installation. Has anyone else made the full import into altium for the X15? I have the schematic, but having trouble importing the layout Feb 07 18:31:30 has anyone imported the beagle X15 into Altium? Feb 07 19:28:52 hi all Feb 07 19:29:38 i got a question about systemd services, have we got an expert? Feb 07 19:31:00 the best way to find out is by asking your question Feb 07 19:31:29 (and being patient. there are plenty of experts here but many will only sporadically pay attention to irc) Feb 07 19:34:34 thx zmatt. ok here is my question. i got a bbgw and i wrote a c-programm with IO, CAN0 and WLAN0 used. when i want to autostart the programm from bootup with a systemd service this programm ist starting. also the led is on. i can read messages, but i cant get my wifi connection to my mqttbroker working Feb 07 19:35:18 when i start my c programm from command line, everything is working. if i start my service from command line, everything is fine Feb 07 19:35:40 only when i want to autostart with service, it doesnt work Feb 07 19:35:42 then I'm guessing your program isn't robust to the possibility that it may not be able to connect immediately Feb 07 19:35:54 even when i ifconig... and there is a wifi connection to the internet Feb 07 19:36:20 if you restart your service after boot has completed and internet works, it still doesn't work? Feb 07 19:36:30 what error are you getting? Feb 07 19:36:43 yes, after restart it is working Feb 07 19:37:43 okay then it's probably what I just said Feb 07 19:38:18 you shouldn't assume you can reliably connect anyway, wifi typically doesn't come with guarantees :) if connection fails just retry (after some short delay) Feb 07 19:39:16 mom, brb Feb 07 19:39:33 you could also order your service after the network has been setup, the details of which Feb 07 19:39:40 may vary depending on network manager used Feb 07 19:40:06 that's not really a robust solution though, and it would stall startup if the network fails to come up Feb 07 19:40:21 well, the latter probably not in a bad way Feb 07 19:45:35 ok, sorry.... Feb 07 19:45:47 for? Feb 07 19:46:00 for afk Feb 07 19:46:03 :) Feb 07 19:46:31 i think you are right. the program starts when there isnt an internet connection available Feb 07 19:46:56 i do also reconnects, when i cant get an connection Feb 07 19:47:26 but the programm doesnt put out an error like: "cant establish connection"! Feb 07 19:47:50 it does, when the progamm is running from command line and i disable wifi manually Feb 07 19:48:21 i think the problem is, when programm tries to connect, but there isnt wifi device ready Feb 07 19:48:41 in my service i got this: after=network.target Feb 07 19:48:53 that's the same as not having a wifi connection, or any other sort of reason for a connection to fail Feb 07 19:49:32 whick MQTT client? Feb 07 19:49:41 paho c Feb 07 19:49:45 ah Feb 07 19:49:53 mosquitto seems to retry Feb 07 19:50:09 broker is mosquitto, i also tried a free mqtt broker in web Feb 07 19:50:19 mosquitto also has a client Feb 07 19:50:27 mosquitto_pub and mosquitto_sub Feb 07 19:50:37 yes, i tried that from command line Feb 07 19:50:52 but in my c program i use paho client Feb 07 19:50:59 i have a wrapper script and they retry...esp. the sub Feb 07 19:51:23 octo_: the purpose of After=network.target is to ensure that during shutdown your service is stopped before the network is brought down btw Feb 07 19:51:46 with NM, network.target may not mean what you think Feb 07 19:51:57 see also https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ Feb 07 19:51:58 (or wifi in general) Feb 07 19:52:23 thx for the hint with network target @zmatt @ds2 Feb 07 19:52:25 network.target just means network *management* is up Feb 07 19:52:39 you may have to qualify it with DBUS messages from NM or similar Feb 07 19:52:53 or just retry if connection fails Feb 07 19:52:56 in the good old days.... Feb 07 19:53:08 he's probably not using gnome network manager Feb 07 19:53:13 connman Feb 07 19:53:54 it is possible to determine whether a route is available to a specific ip (which is probably what you want) and be notified of changes... but really, it makes little sense to bother with that Feb 07 19:54:00 there are more reasons for a connection to fail Feb 07 19:54:16 i think there is some problem with my code Feb 07 19:54:16 and a single robust way to deal with it: periodically retry Feb 07 19:54:26 it sounds like it yet Feb 07 19:54:28 *yes Feb 07 19:54:31 i do periodically retry Feb 07 19:54:43 then there's probably just a bug Feb 07 19:54:53 add verbose debugging Feb 07 19:55:04 but when autostart doesn work my serial debug says nothing about a connection try Feb 07 19:55:24 usually there must be something like : try to connect... Feb 07 19:55:31 but it doesnt. Feb 07 19:55:47 if you print to stdout or stderr in a service, it'll end up in journal btw Feb 07 19:55:53 see journalctl Feb 07 19:56:17 also the last few lines printed by the service can be seen if you do systemctl status Feb 07 19:56:21 ok thx Feb 07 19:57:06 i also got another question Feb 07 19:57:08 you can also use the 'ss' utility to see if there are open connections (e.g. ss --tcp --n -p ) Feb 07 19:57:19 ok Feb 07 19:57:19 -n sorry, not --n Feb 07 19:57:27 got it Feb 07 19:59:00 if i want to start the service only when a specific file is not empty, there is a statement like: conditionallyFileExists=/...... Feb 07 19:59:30 your retry may not be doing a deep enough retry Feb 07 19:59:37 i want to start the programm when in /sys/class/net/wlan0/address is set with the macadress of my device Feb 07 19:59:54 depending on your bind() call, it may need to be redone on the interface up Feb 07 20:00:58 octo_: 1. that's not what Condition statements are for (they prevent your service from running at all if condition fails) 2. that's a disgusting way to check anything related to networking 3. why do you think your service needs to care? Feb 07 20:01:09 i use this example for mqtt client https://www.eclipse.org/paho/clients/c/ Feb 07 20:01:52 just find and fix whatever bug is preventing the periodic retry to not work Feb 07 20:02:03 uhh, sentence fail Feb 07 20:02:15 preventing it from working, or causing it to not work :P Feb 07 20:02:29 i try this for days.... Feb 07 20:03:49 sorry to hear that Feb 07 20:03:59 I hope you find and fix the problem soon Feb 07 20:04:05 thx Feb 07 20:04:31 the project is a kind of can-wifi-gateway Feb 07 20:08:59 if you're not sure what sort of state your program is in when it's "stuck" after boot, if you compile it with debugging enabled then you can attach with gdb to the running process and try to inspect its state Feb 07 20:09:13 please don't send private messages Feb 07 20:10:03 ok, sorry Feb 07 20:10:23 i will do that, i got gdb installed Feb 07 20:10:36 problem is, i use threads Feb 07 20:10:56 when i got to breakpoint, threads go crazy Feb 07 20:11:15 "go crazy" ? Feb 07 20:11:38 is there a way, that the service will only start when i got wifi access? Feb 07 20:11:41 I don't know if gdb halts all threads on a breakpoint, it might have a setting for that. even if it doesn't, why would it matter Feb 07 20:12:33 maybe, but I'm not really motivated to help you do that since it would be a really fragile "solution" and your program would still be buggy Feb 07 20:12:54 good point Feb 07 20:13:18 ok, i will try to fix this tomorrow with your hints Feb 07 20:13:21 thx for your time! Feb 07 20:13:42 cu Feb 07 22:20:23 I'm using a beaglebone green and attempting to enable SPI. After rebooting I'm not able to SSH in anymore. This results in having to reimage the SD card and works afterward. This behavior has also occured when doing other things like attempting a SCP where it hangs and after reboot SSH no longer works. Not really sure where to go from here. Feb 07 22:25:57 that's really too vague to say anything helpful about Feb 07 22:26:20 check the serial console? Feb 07 22:28:44 rgr that will try that when i go back Feb 07 22:29:25 check if you're not running out of space Feb 07 22:30:15 would the device default write to the board disk rather than sd card? Feb 07 22:31:27 uhh, it will only write to whatever you booted from Feb 07 22:31:42 which will be the sd card if a bootable sd card is present at boot Feb 07 22:31:55 okay well we are using a 16gb sd card ~25% is used Feb 07 22:32:07 ok Feb 07 22:32:57 the filesystem is expanded to cover the whole card? (I don't know whether there's any magic in the default images to ensure this happens automatically) Feb 07 22:33:18 that is a good question, i do not know Feb 07 22:33:25 i will have to check that Feb 07 22:33:39 df -h / Feb 07 22:38:33 i'll be able to check it in 2.5 hrs Feb 07 22:43:04 tip: asking for help here when you're not actually able to check things on your bbb is probably not the most efficient use of your or our time Feb 07 22:43:13 hello! I have a project I would like to try with a Beagle board and I was wondering if someone could tell me if it can be done and which board would be recommended Feb 07 22:44:38 I have independent inputs (5v) and I would like a sound to be played for each input every time it receives a 5volt pulse Feb 07 22:46:58 pretty much board with gpio could do that, although note that 1. the beaglebones don't have integrated audio output (other than via hdmi, for those models that have it) 2. no beagleboard or beaglebone has 5v tolerant inputs Feb 07 22:48:01 so you'd need a level shifter Feb 07 23:02:43 Sorry, I am new to this, but what type of tolerant inputs are available? Feb 07 23:02:54 Is it very difficult to do the project I mentioned? Feb 07 23:03:26 beaglebone uses 3.3v i/o Feb 07 23:04:21 that's an impossible to answer question since it depends entirely on your experience, skill level, and ability to learn. I don't feel qualified to judge that Feb 07 23:04:37 It is possible that the output device is less than 3v; let's say for argument's sake it is, is the project I mentioned difficult? Feb 07 23:05:13 or overly complicated for a beginner? Feb 07 23:08:06 thanks for the information; have a great day Feb 08 00:16:13 did a df -h / on a 64gb sd card and got 3.3G, 1.7G used, 1.4G available Feb 08 00:16:27 top Feb 08 00:34:46 hello, I am new here and to beagleboard Feb 08 00:35:57 I am trying to download the angstrom distribution but having problems Feb 08 00:54:25 Bongobong: yeah, so the partition and filesystem need to be expanded Feb 08 00:55:07 you can either do that from another linux system or even while booted from the card itself Feb 08 01:07:13 yeah i have done that it seems to be more stable now Feb 08 01:07:39 still haven't tried enabling spi, i noticed it said something about capes being deprecated and to use u-boot overlays Feb 08 01:10:25 you normally don't need to enable spi, it should be enabled by default, all you have to do is configure the pins with config-pin Feb 08 01:15:10 even if i am not showing anything in /dev about spi? Feb 08 01:23:53 I would guess that's because you already made changes in configuration that caused this Feb 08 01:23:59 they are there by default Feb 08 01:24:21 (unless you're using a really old image) Feb 08 01:24:40 but you're not since you mentioned u-boot overlays Feb 08 01:25:55 i am on 4.9 kernel and the latest debian image, however when i first boot on a clean image it is not there Feb 08 01:26:35 what's the name of the image you're using? Feb 08 01:26:45 also, you've booted from sd card right? Feb 08 01:26:56 yes and one second Feb 08 01:27:11 do you care about the content of eMMC? if not, consider erasing it with sudo blkdiscard /dev/mmcblk1 Feb 08 01:27:19 debian 9.3 iot Feb 08 01:27:55 by default ROM prefers to load u-boot from eMMC over loading it from SD Feb 08 01:28:30 if the system on eMMC is much older than the system on SD card, that can cause trouble Feb 08 01:28:51 e.g. the system is expecting u-boot overlays to be used, but the old u-boot on eMMC doesn't know anything about that Feb 08 01:41:15 I'm having trouble installing the BeagleBone Driver Installation on Windows 10. I'm downloading the 64bit driver file:///H:/Drivers/Windows/BONE_D64.exe. All are reporting Install Failed. Even when I run as administrator. Feb 08 01:41:45 H: is the beaglebone via USB. Feb 08 01:41:55 if you're using a recent image on the beaglebone, no driver is needed for windows 10 Feb 08 01:42:31 if whatever image is flashed onto the beaglebone is old enough to still need a driver, I'd suggest reflashing the beaglebone with the latest image Feb 08 01:42:38 ok. At the moment I've just unplacked the board and plugged it in and ran Start.htm following the instructions there Feb 08 01:43:04 Is there a way to interogate it to see what version is on there? Feb 08 01:43:51 there is, but that requires you're able to log into it Feb 08 01:44:20 haha ok. I'll keep reading and see if it explains how to try and log into it :) Feb 08 01:44:37 check the "status" column of the table here to check for connectivity: http://beagleboard.org/getting-started#step2 Feb 08 01:44:39 sigh.... dump that crap Feb 08 01:44:50 no point in having a massive spyware at home Feb 08 01:45:19 Guest8276: anyway, fresh out of the box... who knows how old the stuff on there might be Feb 08 01:45:22 ds2: ? Feb 08 01:45:29 win10 == massive spyware Feb 08 01:46:13 I don't like using windows either, but this doesn't seem like the appropriate place to try to convert people to linux Feb 08 01:46:38 I am specifically complaining about win10 but you have a fair point Feb 08 01:46:54 specially - why are we supporting use of spyware Feb 08 01:47:40 trev Feb 08 01:47:51 because trying to be elitist about which OS people should used is not exactly a good way to welcome new users? Feb 08 01:48:27 anyways... let's just follow your suggestion =) Feb 08 01:49:46 Guest3950: I recommend reflashing the beaglebone anyways... whatever is on there is most likely not very recent Feb 08 01:49:50 eh Feb 08 01:49:55 other guest Feb 08 01:49:58 who already left it seems Feb 08 02:17:38 zmatt erasing emmc worked Feb 08 02:17:46 i now have spidev stuff Feb 08 02:18:18 :) **** ENDING LOGGING AT Thu Feb 08 03:00:01 2018