**** BEGIN LOGGING AT Thu Mar 14 02:59:57 2019 Mar 14 08:53:24 what is the input - output library for beagle board in python Mar 14 08:54:59 HI! Im looking at schematics for the x15 Mar 14 08:55:27 ok Mar 14 08:56:04 One of the balls i need (AC10) has a cross symbol attached to the pin and thats all, this often means a testpoint but there is no refdes shown and i cant see testpoints on the pcb pictures.... is it a testpoint?! thanks :) Mar 14 08:56:46 I have Beagle Board Rev C3 board,i am trying to run python code for led toggling Mar 14 08:57:04 jb__: cross means nothing connected Mar 14 08:57:16 so i need python package for input output Mar 14 08:58:25 @zmatt sono trace on pcb, nothing? Mar 14 08:59:52 jb__: nothing. you wanted access to it to prototype using an usb port for OTG functionality or something? Mar 14 09:01:47 nupam: I'm not really familiar with the old beagleboards. my guess would be that they'd use the same gpio facilities provided by the linux kernel as basically every other linux embedded system Mar 14 09:02:01 nupam: check if there's stuff in /sys/class/gpio/ Mar 14 09:10:43 jb__: I wonder if this really needs to be controlled by the peripheral... I feel like a software-controlled gpio ought to be fine for something like drvvbus Mar 14 09:11:02 but that may require writing driver support for it Mar 14 09:15:36 (similar to how vbus detection, id pin detection, and charger-enable control are delegated to software in the am572x (which would use the pmic and/or gpios for them), in contrast with the am335x where these things are done directly by the usb2phy) Mar 14 09:17:01 how to clear all the files in bbb? Mar 14 09:17:15 what do you mean? Mar 14 09:17:52 if you want to have a clean slate again, you can just reflash it. see https://beagleboard.org/getting-started Mar 14 09:18:03 how to reset the bbb? Mar 14 09:19:31 even if it is reflashing its not deleting all the files Mar 14 09:19:33 jb__: in fact, the usb wrapper can give the cpu an interrupt whenever the drvvbus signal from the usb2phy changes, which the driver could use to control a gpio Mar 14 09:19:54 Guest32001: ehm, what do you mean? if you reflash it, everything is gone Mar 14 09:20:03 what do you mean? Mar 14 09:20:30 jb__: so if the driver currently doesn't support it, it probably would be easy to implement Mar 14 09:20:40 Guest32001: what do I mean with what? Mar 14 09:21:07 see i need to restart the bbb Mar 14 09:21:14 what should i do Mar 14 09:21:39 "clear all files", "reset", "restart", "reflash" all mean completely different things Mar 14 09:21:53 it could be helpful if you actually say want you want to achieve Mar 14 09:22:17 my best guess is that you want to reflash, in which case I've already pointed you to a webpage which has instructions Mar 14 09:23:15 i hv to clear all the file Mar 14 09:24:22 Guest32001: stop repeating your vague question. If the information at https://beagleboard.org/getting-started does not suffice, explain _CLEARLY_ what you are trying to do Mar 14 09:24:30 i have already installed debian images but i need clear that and new image i should install what Mar 14 09:24:57 you are not making sense Mar 14 09:26:16 i want to delete all files and i need to reflash it again....what should i do Mar 14 09:26:57 learn to read Mar 14 09:27:16 https://beagleboard.org/getting-started has instructions for reflashing Mar 14 09:27:31 reflashing will delete all files anyway, you don't need to do that separately Mar 14 09:28:06 thank you Mar 14 09:30:04 @zmatt thanks for your help :) Mar 14 09:58:14 we got it thank you Mar 14 09:58:53 then how to run bonescript Mar 14 10:15:42 what should i do if i get this type of error in bbbAfter this operation, 317 MB of additional disk space will be used. E: You don't have enough free space in /var/cache/apt/archives/. Mar 14 10:15:48 what should i do if i get this type of error in bbbAfter this operation, 317 MB of additional disk space will be used. E: You don't have enough free space in /var/cache/apt/archives/. Mar 14 10:16:12 what are you trying to do? Mar 14 10:16:17 also, which image did you start with? Mar 14 10:16:35 debian 4 gb lxqt Mar 14 10:16:36 it sounds like you're trying to install a ton of large stuff and simply don't have th espace Mar 14 10:16:47 generally you should use the iot image Mar 14 10:17:08 for image processing Mar 14 10:17:10 the lxqt image has a full desktop environment installed, which is almost never useful but takes up a lot of space Mar 14 10:17:50 for image processing what should i do Mar 14 10:17:54 install Mar 14 10:18:10 for pretty much any application the stretch-iot image is the recommended image Mar 14 10:19:06 the lxqt image is just if you really need or want a desktop environment installed. since this nearly fills up the 4GB of eMMC space, it doesn't leave much room for installing other stuff Mar 14 11:18:35 i have a ttl sensor which needs to be powered with 2.5-3.0 VDC. the datasheet explicitly says max Vin = 3.1V. i can't wire it to the 3.3V source on the bbb, obviously. is it me or this is insane? why on earth a sensor giving signals using 3V3 TTL wants to be powered at 3V?? Mar 14 11:37:21 samael: part number? Mar 14 11:37:25 (or link to datasheet) Mar 14 11:37:53 zmatt: http://www.egismos.com/intergrated-photonics-modules/Laser-distance-measurer-module-M2.pdf Mar 14 11:41:16 this looks really weird. if these specs are true, it would need to have an on-board charge pump or something to generate the higher I/O voltage for its uart tx pin Mar 14 11:41:43 the fact that they call a TTL-level uart interface "RS232" is also not very confidence-inspiring Mar 14 11:42:48 actually no, this datasheet is plain bullshit Mar 14 11:42:59 look at Vpeh Mar 14 11:43:13 min 3.0V, max Vin+0.3V Mar 14 11:43:43 that's an impossible constraint if you use Vin=2.5V Mar 14 11:44:02 I suggest contacting the manufacturer Mar 14 11:46:14 (if you do contact them, please also point out to them that "RS232" is an electrical standard which is totally incompatible with TTL-level uart) Mar 14 11:50:50 "Resistors of a few hundred Ohm are preferentially added between the pins UART Rx, UART Tx and the user's MCU in order to limit the voltage discrepancy between the two systems that would lead to current loss." Mar 14 11:50:54 o.O Mar 14 12:05:37 the EE equivalent of "we'll fix it in software" Mar 14 12:08:10 but the datasheet reads like some non-EE's designed that whole thing Mar 14 12:08:17 -> do not use Mar 14 12:10:24 yeah, like I said this datasheet is not confidence-inspiring Mar 14 12:11:42 I wonder if they originally wanted it to be 3.3v but they realized the chip they used doesn't support that, so now they're just using its I/O out-of-spec ? Mar 14 12:11:57 with aforementioned resistors limiting the current through the protection diodes Mar 14 12:12:14 very likely Mar 14 12:12:49 if the circuit contains a 741 and/or aluminium foil, then the culprits were phycisists Mar 14 12:16:00 samael: so, I'd suggest powering this thing at 2.5V-3.0V (preferably 2.5V), weakly pulling up the I/O to 3.3V with a large-value resistor (10K or more), and measure the actual voltage on the I/O of this module Mar 14 12:16:23 pulling up the inputs I mean, not its output Mar 14 12:17:43 if it looks like the I/O is actually referenced relative to Vin, and you're still intending to use this module, use a level shifter to translate between the beaglebone's 3.3V and the supply for this module Mar 14 12:18:37 should be OK with TTL (Vih threshold is 2.4V) bunt in general I agree with zmatt, it seems to be specced to work if there's a 3V3 pullup Mar 14 12:20:42 artag: I'm not worried about the 3V signals from the module, I'm worried about the 3.3V signals the beaglebone would drive into the module Mar 14 12:21:17 especially since their remark recommending series resistors strongly implies there are protection diodes from those I/O to the module's supply Mar 14 12:24:02 yeah, I think you're right that they've specced it to look safe with a 3v3 interface Mar 14 12:24:51 don't know how they ended up with those thresholds though. Maybe they used a 3v instead of 3v3 supply and are limited to Vs + 0.3V ? Mar 14 12:26:16 * zmatt pokes gently in samael Mar 14 12:26:46 zmatt: poking gently with a claymore? Mar 14 12:46:05 zmatt: sorry, been afk. your feedbacks confirmed my guess, this thing is far to be trustworthy. i got basic undestandings of electronics, nonetheless the document seems unaccurate to me. i suspected there were simple typos in there, would have asked clarifications to the manufacturer. but all the flaws you pointed out are enough to evaluate other solutions, i think Mar 14 12:47:43 at first i supposed i could use a 3V zener to cut the voltage on the 3V3 line of the bbb to power it up, but after reading your comments i'm not sure it'd be a good idea Mar 14 12:47:57 ehhhhhhhhhh Mar 14 12:48:25 use a lab supply or an LDO Mar 14 12:49:54 (note: when using a supply that is independent of the bbb, be sure to power the bbb up first to ensure you don't accidently drive any of the BBB's I/O while it's unpowered) Mar 14 12:52:46 i don't have 3V supplies at hand. don't want to dig in that detail, i lack tools and know-how. this thing is not likely to be easily used with a bbb, better find something else Mar 14 12:53:30 if you don't want to have to use anything more than wires to connect it, then yes Mar 14 12:54:01 a silicon diode to drop 0.6v from the supply would probably keep things safe, though might not give you the best logic levels Mar 14 12:54:26 let's say it's not what i was supposed to do. Mar 14 12:54:49 i suspect there's either a typo or it works OK but they're stretching the specs to make it sound more carefully designed than it was Mar 14 12:55:10 I don't think it's a typo Mar 14 12:55:18 mainly because of the resistor remark Mar 14 12:56:03 there is that, true Mar 14 12:57:12 any idea what parts are on it ? Mar 14 12:57:27 I haven't found a decent-quality photo online Mar 14 13:05:24 https://imgur.com/a/0FWBDT3 here they are. not quite clear, though Mar 14 13:06:29 that's the best i can do with my smartphone Mar 14 13:08:34 uhh, these seem weirdly low-res... 461 x 346 pixels. these have got to be downscaled versions? but the images are not clickable, no option evident to get a higher-res version Mar 14 13:09:37 sorry, that's imgur fault. i don't use it often Mar 14 13:09:55 hold on a min Mar 14 13:14:43 http://multivac.valis-e.com/static/tmp/1.jpg also 2.jpg and 3.jpg Mar 14 13:17:36 stm32f030 microcontroller Mar 14 13:22:43 is it just me or do those two caps in the bottomleft corner of 3.jpg seem wonky? like they don't match the footprint or something Mar 14 13:22:51 inductor on top side, might be part of a boost converter Mar 14 13:23:27 they're a bit offset, but not disconnect, I think Mar 14 13:26:58 so, nothing obvious that would indicate why max 3.0V Mar 14 13:27:06 my knowledge of electronics makes me uneligible for comments :) Mar 14 13:27:09 (the stm32 is 2.4V - 3.6V) Mar 14 13:29:37 my guess would be that something on their board imposed that 3V limit, and they looked at the abs max ratings of the stm32 (max VDDIO+0.3V) and figured "eh, it's fine" or something Mar 14 13:30:19 although I do wonder why they then didn't integrate an ldo or something to allow the thing to run on 3.3v, since supplying 3V is annoying Mar 14 13:30:35 *shrug* Mar 14 13:34:00 (I also wonder they didn't use the 5V-tolerant I/O pins the stm32 has) Mar 14 13:36:09 the separate battery connections almost look like they expect it to run off 2xAA. But they could be well over 3 when new Mar 14 13:37:14 'batt' is an odd thing to label the supply when it's so much more likely to be integrated with other parts Mar 14 13:39:08 what's the range of a 3v lithium ? Mar 14 15:14:48 I'm trying to compile lirc driver for beagle, i get this "not found": make[1]: *** /lib/modules/4.14.94-ti-r91/build Mar 14 15:16:32 I have only "extra" and "kernel" directories under /lib/modules/4.14.94-ti-r91/ Mar 14 15:19:31 would apt install linux-headers-`uname -r` fix it ? Mar 14 15:22:50 I don't know if headers suffice, it might want the actual kernel tree. either way I'd cross-compile it, not attempt to native-compile it on that poor beaglebone Mar 14 15:23:01 fred__tv: probably yes. you need it anyway, so it won't hurt Mar 14 15:26:01 I don't even know the difference between "cross" and "native" sorry, I think native is what I'm trying to do now, however it fails... Mar 14 15:30:43 cross means you compile on another machine, typically a decently performing x86 machine running debian or ubuntu Mar 14 15:31:23 native means you compile on the beaglebone itself, with its slow cpu, slow and limited storage, and limited ram Mar 14 15:32:05 I suppose the other machine must have the same identical kernel running... Mar 14 15:32:12 doesn't matter whatsoever Mar 14 15:32:58 you've got easy cross-compilation toolchains nowadays Mar 14 15:33:01 on arm official website Mar 14 15:33:04 I think you can even cross-compile from a windows system, although that's probably not the simplest road Mar 14 15:33:09 download, extract, add to $PATH, done Mar 14 15:33:11 no need to go to any website Mar 14 15:33:16 just apt-get install gcc-arm-linux-gnueabihf Mar 14 15:33:26 yeah if you distro has it it's better Mar 14 15:33:39 on debian stable it may not be the latest of all Mar 14 15:34:21 fred__tv: but what's this out-of-tree driver? lirc sounds familiar, but I thought it was a userspace thing? Mar 14 15:34:25 I was talking of this thing: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads Mar 14 15:34:30 it has windows binaries too Mar 14 15:35:19 zmatt: is lirc (infrared receiver support) already included ? Mar 14 15:36:20 I don't know what you mean by that. lirc is userspace software that supports a large number of different capture devices Mar 14 15:37:33 the beaglebone has many facilities that could be used to capture IR signals, though I don't know which have suitable drivers let alone lirc support Mar 14 15:39:34 zmatt: sorry for a late followup, indeed you're right, I found OSD335x docs which describe USB schematics, and it says that that ID needs to be floating for peripheral mode. I changed to dr_mode="peripheral" in overlay, but no success, I'm investigating why. Am I correct that for peripheral mode I do not need to connect VBUS and VIN pins on USB1? I'm using only VBUS. Mar 14 15:39:40 let me ask simply... what's the easiest way to capture IR signals ? any module to add ? any package ? Mar 14 15:40:28 mixaz: vbus needs to be connected to the vbus line from the host Mar 14 15:40:33 it's how connection is detected Mar 14 15:43:10 yes, I see, I did that Mar 14 15:43:46 fred__tv: I see, you probably googled for it and found this disgusting-looking kernel module that for some reason is called "lirc_bbb" even though it seems to be a completely generic gpio-based driver (not making use of any particular feature of the beaglebone) Mar 14 15:44:08 yeah , you're right ! Mar 14 15:48:35 I'm guessing there just hasn't been much interest in it. the beaglebone has excellent facilities for it, but nobody seems to have implemented anything for them Mar 14 15:49:23 other than this pure gpio-based driver, which sounds inefficient and unreliable (since it'll be subject to timing jitter dependent on interrupt latency) Mar 14 15:52:50 ardupilot does have something similar (capturing timing of edges of a received signal), except they use it for decoding various protocols used in remote control vehicles Mar 14 15:53:15 iirc they use pru's eCAP Mar 14 15:55:33 I'm not even able to compile that bad one on my beagle , so it doesn't even work rather "it works badly".....:-( Mar 14 15:57:19 well it looked pretty hacky to me, not to mention it's 3 years old Mar 14 15:58:17 issue #1 is the same I have.... https://github.com/miero/lirc-bbb/issues/1 Mar 14 16:00:02 it seems like there's a gpio-based IR receiver driver in mainline linux already anyway Mar 14 16:01:34 and it's compiled as module in the standard 4.14-ti kernels Mar 14 16:01:47 so it looks like you don't need to compile anything, you just need to figure out how to use it Mar 14 16:03:49 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.14.94-ti-r97/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt Mar 14 16:06:05 so how should I use it ? inserting that node into an overlay ? Mar 14 16:07:13 (remember I'm at the stone age...) Mar 14 16:07:22 yeah, as new child of the root node. no need to label the node like they do in that example btw, no idea why they do that Mar 14 16:07:45 and of course with appropriate values for the gpio and that rc-map-name thing Mar 14 16:08:47 should I build a new overlay or adding to an existing one ? Mar 14 16:09:54 if you already have a custom overlay you can add to that if you want, or use a separate one, doesn't really matter Mar 14 16:13:54 But, must I have 4.14.94-ti-r97 or newer ? Mar 14 16:14:44 doesn't really matter as long as the module is enabled Mar 14 16:15:02 you can double-check whether your current kernel has it with: grep CONFIG_IR_GPIO_CIR /boot/config-$(uname -r) Mar 14 16:16:02 CONFIG_IR_GPIO_CIR=m Mar 14 16:16:21 yep Mar 14 16:27:04 but how to use once installed ? Mar 14 16:27:49 presumably with a suitable DT node in place a lirc device should show up Mar 14 16:29:11 hmmm this evening I'll give it a try... Mar 14 16:37:14 ls Mar 14 16:37:18 Dang it. Mar 14 17:11:07 Okay. So, get this. The src file I am looking into states it created a .kml file for Google Earth that I can view online at an address and port. Mar 14 17:11:08 ... Mar 14 17:11:54 gps3 is what it is called. I am reading out of gps3/examples/gegps3.py. Mar 14 17:12:07 zmatt: You are familiar w/ it. You showed me this library. Mar 14 17:14:18 The example gegps3.py works but getting it to Google Earth is another story. I changed the address so far w/out any luck. Mar 14 17:35:43 Hello everybody. I would like help with a problem to keep any GPIO in LOW throughout the boot. I already configured a gpio in input with init low, in outout with init low, but when I reboot all the ports go up in HIGH state. Is there any way for the board to go up in LOW? Mar 14 17:39:33 config-pin or a .sh script in a .service file maybe. Mar 14 17:39:46 That is a lot of work, though. Mar 14 17:39:59 Lots and lots of button pushing. Mar 14 17:41:25 abreu: Do you know how to get the config-pin utility to work? Mar 14 17:41:53 Oh wait. Mar 14 17:42:20 echo >/sys/class/gpioX Mar 14 17:42:22 and then... Mar 14 17:42:48 yes, i know.. Mar 14 17:42:56 I created a DTS and it is loaded low to LOW, but before about for a while in HIGH. Is there any way to do this via some DTS or even with a service? I have a relay attached to a port it presses HIGH: | Mar 14 17:43:08 Oh. Okay. Mar 14 17:43:25 Oh. Mar 14 17:43:51 So, .service files work fine still. Mar 14 17:43:54 The problem is for my project I need the port never to stay HIGH otherwise than for my application. Mar 14 17:44:38 abreu: I think you may need extra support other than me. Maybe someone will show up soon. I think your issue is above my knowledge base. Mar 14 17:45:34 Ok set_, thank you anyway. Mar 14 17:46:57 No issue. Mar 14 17:47:04 Sorry for the inconvinience. Mar 14 17:47:22 thanks ;) Mar 14 17:51:41 abreu: So, you need to set your GPIO pins high and keep them, right? Mar 14 17:53:09 no, start at LOW all the time and only when my application needs, change to HIGH. Mar 14 17:53:28 abreu: Oh. Dang it. I thought I figured it out. Mar 14 17:53:33 Okay. Mar 14 17:53:50 So, your DTS overlay works right? Mar 14 17:54:03 It does what you want it to but it does not last past a reboot? Mar 14 17:54:28 no, the DTS don't work :( Mar 14 17:54:32 Oh. Mar 14 17:54:37 look Mar 14 17:54:40 Okay. Mar 14 17:54:42 fragment@3 { target = <&ocp>; __overlay__ { cape-universal { compatible = "gpio-of-helper"; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <>; P8_09 { gpio-name = "P8_09"; gpio = <&gpio2 5 0>; input; dir-changeable; }; P8_10 { gpio-hog; gpio-name = "P8_10"; gpio = <&gpio2 4 0>; Mar 14 17:54:46 no. Mar 14 17:54:47 no.. Mar 14 17:54:51 Use pastebin.com. Mar 14 17:55:15 Oh. I understand. You are using an older image and older kernel? Mar 14 17:55:16 https://pastebin.com/QFCystRL Mar 14 17:56:02 I use a debian 9.5 Mar 14 17:56:04 You just need three gpio pins to go high after low? Mar 14 17:56:05 Okay. Mar 14 17:56:12 kernel 4.14.91-ti-r90 Mar 14 17:56:15 Okay. Mar 14 17:56:29 "You just need three gpio pins to go high after low?" yes, is this Mar 14 17:56:39 is this what? Mar 14 17:56:50 the problem is in reboot when GPIOs go to HIGH. Mar 14 17:57:21 I meant that's what I need. Mar 14 17:57:25 Maybe you could put that dts file in your u-boot overlays section in the file /boot/uEnv.txt. Mar 14 17:57:27 Okay. Mar 14 17:57:43 "in the file /boot/uEnv.txt." i made this :D Mar 14 17:57:48 Oh. Mar 14 17:58:38 So, you are using buttons or you are just wanting these pins to listen to high or low cmds when you make them? Mar 14 17:58:53 I do not get it just yet. Mar 14 17:59:35 I have a python application that changes state to HIGH when it reads another input GPIO (a sensor). Mar 14 18:00:07 Oh. Mar 14 18:00:55 So, something like a .service file on boot will work w/out the need for a dts file. I am pretty sure of this fact. Mar 14 18:01:08 my problem is being able to make the card not raise the ports to HIGH during the boot, this I will not encotnrei way to do. I can change to low in several ways, but the port gets HIGH for a while ... and I have a relay that is triggered unduly ... Mar 14 18:01:45 Okay, so I'll test this. But I expected to have something more robust and not rely on a script ... Mar 14 18:02:00 Oh. Mar 14 18:02:22 So, you know how to put your dts files to work in the u-boot overlay way? Mar 14 18:02:37 yes, i know.. Mar 14 18:02:51 Okay. Mar 14 18:03:27 but the problem is this, that the bootloader or kernel raises the port to HIGH during boot and wanted to change it. Mar 14 18:03:41 Tthank you very much for the help, I will create a .service and see if it rises before and prevents the door from changing to HIGH. Mar 14 18:04:13 Sorry. Mar 14 18:04:32 I guess I know little of how the dts files work these days. Mar 14 18:05:22 If you want me to test it on my end, give out some simple software to test a GPIO and I can do it. Mar 14 18:05:43 I have my board plugged in and it is runnin' and movin' now. Mar 14 18:06:55 good, i will sent do you. Mar 14 18:07:59 Try "echo 1 >/sys/class/gpio/gpioXXX/value" and then see if it goes high or low on that cmd. If that works, you could use it w/ a bash script. Mar 14 18:09:55 Or, you could use config-pin instead of the dts file. Set up your gpio pins w/ config-pin and then set up a .service w/ a bash script link. Mar 14 18:10:01 ... Mar 14 18:10:27 But w/ the dts files, I am out of luck and I cannot help you w/ them any longer. I stopped using them a long time ago. Mar 14 18:10:38 look http://rlrobotics.com/mtv-test.dts Mar 14 18:11:08 What is that page? Mar 14 18:11:21 I just went to it and it tried to make me download something. Mar 14 18:11:23 my dts Mar 14 18:11:31 I already saw your dts file. Mar 14 18:11:38 You showed me on pastebin.com. Mar 14 18:11:40 ok Mar 14 18:12:02 https://pastebin.com/WBc4M0e5 Mar 14 18:13:15 See, you need all that work for just a couple GPIO pins. Mar 14 18:13:28 Does that not seem like too much? Mar 14 18:14:13 I read when you said, "robust." But still, it is a complicated process that needs updating constantly. Mar 14 18:14:48 no, the DTS only defines the modes that the pins can assume and at the end of it is that I use the modes defined before. Mar 14 18:16:12 I will put a monitor to see the serial and find out if it is the bootloader or the kernel that goes up the doors to HIGH and I will be back soon :) Mar 14 18:16:51 Let me wrap my head about this idea. You want to use the chip to rereference the routing of the GPIO pins? Mar 14 18:17:08 Yep. Above my knowledge base. Mar 14 18:18:05 Okay. Mar 14 18:18:54 These pins will connect relays and read an input sensor. It's quite simple, but I can not seem to get the board up with the pins in LOW and that's pretty frustrating .. Mar 14 18:19:29 But I'll be back in a few minutes, I'll monitor the serial and also see if a .service work.. Mar 14 18:22:45 Okay. Mar 14 18:24:50 No issue. If it is something simple, I can catch it. If it is complicated, you may need some extra support from another person here. Mar 14 18:29:00 p9_11 uart pin works well? Mar 14 18:29:37 yes, work well. Mar 14 18:29:45 Okay. Mar 14 18:31:37 What are you receiving at uart4? Mar 14 18:32:27 like some type of sensor to read or the relay? Mar 14 18:32:47 Hey Coffee...I remember you. Do you know about .dts files? Mar 14 18:33:50 good on ya. can't help right now :/ Mar 14 18:34:24 Okay! Mar 14 18:34:35 have fun! Mar 14 18:44:45 abreu: bbl. I hope you can figure out the issue. If not, I will pitch in some more in time. I know you are probably in a rush. You may not have time to tell me things and I understand if you no longer want me help w/ this issue. Mar 14 20:24:41 hi set_ Mar 14 20:26:19 I gave up making the board climb with the pins in LOW. So I'm going to reverse logic and use a PNP transistor to trigger my relay. Thus, the board rises with the pins in HIGH by default, so to polarize my transistor will be LOW value, which then triggers the relay. Mar 14 20:56:35 hello, anyone knows future plans of beaglebone ? Mar 14 21:04:49 Okay. Mar 14 21:05:46 abreu: If you find time, let me know what happens. Mar 14 21:12:35 set_: for sure Mar 14 21:13:20 Hi , can I get some technical help here? Mar 14 21:21:03 abreu: I am dealing w/ making MachineKit work right now but I would like to know how falling or rising works from your dts file. Mar 14 21:22:38 set_: after I can solve this big problem here I can help you too. Mar 14 21:23:32 Yea boy! Mar 14 21:23:46 abreu: Are you using MachineKit yet? Mar 14 21:24:12 I am exploring its opportunities now. Mar 14 21:24:28 The research phase is over and now I can finally attempt ideas. Mar 14 21:32:24 EngineerNeil: Yes. I think people will help in time. Stay patient. Mar 14 21:39:18 It is like a flashback in time. Mar 14 21:39:23 MachineKit! Mar 14 21:39:46 Ok thanks. I am working on this project: http://www.ti.com/lit/ug/tiduci9c/tiduci9c.pdf Mar 14 21:40:19 I am stuck at the following steps: Mar 14 21:40:22 Program the SD card with the Linux processor SDK image using the following steps: 1. Download the prebuilt TI Linux processor SDK SD card image am335x-evm-linux-xx.xx.xx.xx.img.zip from http://software-dl.ti.com/processor-sdk-linux/esd/AM335X/latest/index_FDS.html (where xx.xx.xx.xx is the version number of the latest Linux Processor SDK). 2. To program the micro SD memory card, see the instructions in Processor SDK Linux Creatin Mar 14 21:40:43 Oh. Mar 14 21:41:15 EngineerNeil: I think people do not support the SDK from TI.com here. I am not completely sure but one person told me this idea a couple days back. Mar 14 21:41:35 Stick around. Who knows? Mar 14 21:42:31 But when I follow that link , the image it is showing me that is for windows is 16GB big , which doesn't seem right in the requirement they say an 8Gb sd card is needed Mar 14 21:43:11 Right. Mar 14 21:43:13 I tried too. Mar 14 21:43:33 16 GB is for porting to another board from another board. Mar 14 21:43:57 For instance, what I can configure, you or me for this fact would need another board to port Linux to the BBB. Mar 14 21:44:18 There would have to be some steps to create a smaller Linux Distro out of that 16GB image file. Mar 14 21:45:24 I bouth x15 board where is the root password? Mar 14 21:46:25 Hello, can anyone please help me to create a simple DTS that makes the BBB boot up with two OUTPUT ports starting in LOW and one INPUT in PULL DOWN? Mar 14 21:47:19 I have been suffering for some days with this problem without being able to resolve this. Mar 14 21:48:17 I was here earlier. My big problem is that the board starts with all the ports in HIGH and the same thing happens when I reboot. Mar 14 21:48:44 Right. Mar 14 21:48:59 I'm trying to do a DTS to properly configure the pins, but to no avail. Mar 14 22:01:55 306 upgrades. Yawn. Mar 14 22:11:21 abreu: Did you get the devices working w/out the DTS yet? Mar 14 22:36:31 Up, up, and Otay! Mar 14 23:17:00 abreu: no port "starts in HIGH", all pins are by default floating with a weak (100K ± 50%) pull-up or pull-down (varies per pin) Mar 14 23:18:35 hi zmatt Mar 14 23:18:41 the best way to ensure a default level directly from power-on is by using an external pull-up or pull-down resistor (in the 1K-10K range) Mar 14 23:19:22 configuring pins in device tree is still only done by software, even if it is done by the kernel and much earlier in boot than the first opportunity in userspace Mar 14 23:20:28 which means there would still be some amount of time after power-up where the pins are not in your desired state, even if that time is shorter Mar 14 23:20:59 yes Mar 14 23:21:00 I have an npn transistor with a pull down of 10K and a resistor of 1k in the base, but in every reboot the pin has positive value. But I have noticed that it is weak, correct? Mar 14 23:21:17 which pin are you using? Mar 14 23:21:52 a 10K pull-down should ensure the pin remains low after power-on Mar 14 23:22:20 so if you're still seeing the pin go high, that would imply it is being configured by *some* software to go high Mar 14 23:22:42 P9.11 and P8.10 out / P8.09 IN Mar 14 23:23:59 those indeed have internal pull-up by default Mar 14 23:24:49 oh I guess the problem isn't that the pins are "logic high", since with a 10K pull-down they should be logic-low, but they won't be quite 0V and some amount of current can still flow through the transistor Mar 14 23:24:57 a transistor base isn't a digital input Mar 14 23:25:43 the internal pull-up and external pull-down make a voltage divider Mar 14 23:26:06 yes, right.. Mar 14 23:26:43 I'll confirm if I have no DTS sabotaging me, bou put a pull down of 10k and see if it divides the voltage .. Mar 14 23:26:59 typo* Mar 14 23:27:00 I will confirm if I do not have any DTS sabotaging me, I will put a pull down of 10k and see if it divides the voltage .. Mar 14 23:27:10 uhh what do you mean by that? Mar 14 23:27:21 the default dts does not reconfigure those pins Mar 14 23:27:37 i a'm using the /lib/firmware/cape-universalh-00A0.dtbo Mar 14 23:27:53 i.e. it will leave them in the same state they have during and immediately after reset Mar 14 23:28:03 (floating with weak internal pull-up) Mar 14 23:28:24 because these not I preferred this because it frees pins I'm using and the universal default caused problems. Mar 14 23:29:00 sorry I don't understand what you're trying to say Mar 14 23:29:38 also that sounds like the wrong universal overlay? Mar 14 23:29:45 at least for current debian systems Mar 14 23:30:02 sorry, I said I'm using the "/lib/firmware/cape-universalh-00A0.dtbo" instead in the standard universal cape. Mar 14 23:30:30 (regardless the specific universal overlay should not be overridden manually, u-boot will pick the correct one based on beaglebone model and /boot/uEnv.txt settings) Mar 14 23:32:23 ok, i got it. Mar 14 23:32:24 I'm going to test with a 10K resistor as a pull down and see if the voltage divides during the entire boot process and does not go up to HIGH to determine if I'm not using a wrong overlay. Mar 14 23:32:34 anyway, to solve your problem you can try using 1K pull-downs instead of 10K. With 10K pull-down the expected voltage on the pins (with internal pull-up enabled) is 0.20 - 0.55V, with 1K pull-down the expected voltage would be 0.02-0.06V Mar 14 23:32:44 okay Mar 14 23:33:01 you can also use my show-pins utility to confirm the pinmux state at runtime: https://github.com/mvduin/bbb-pin-utils/#show-pins Mar 14 23:33:33 "anyway, to solve your problem you can try using 1K pull-downs instead of 10K. With 10K pull-down the expected voltage on the pins (with internal pull-up enabled) is 0.20 - 0.55V, with 1K pull-down the expected voltage would be 0.02-0.06V" nice, i have 1k 1% here Mar 14 23:34:42 you are the man! I'm going to test, it seems more understandable to know that it's just an internal pull up: D Mar 14 23:34:58 :D Mar 14 23:35:37 the only downside is that it wastes some power whenever the pin is driven high. alternatively, depending on the application, you may be able to replace the transistor with a component that only depends on logic level, like an open-drain bfufer Mar 14 23:36:08 " replace the transistor with a component that only depends on logic level, like an open-drain bfufer" this is the perfect solution. Mar 14 23:36:28 i will search for a fet with logic level gate. Mar 14 23:37:14 even then a pull-down would be required of course, but it only needs to be strong enough to make the signal logic-low for whatever component you use (check its datasheet) Mar 14 23:37:32 yes :D Mar 14 23:38:37 I'm going to use a 1K resistor, I tried other combinations, but I lost current in the transitor. It's because I'm improvising with the material I have here, but soon I'll get a more suitable fet :D Mar 14 23:40:34 I'm surprised the transistor opened up at all when using a 10K pull-down though... 0.2-0.55V should normally be insufficient to allow significant current to flow through the transistor Mar 14 23:44:53 yes, this caused me a lot of headache and was desperate thinking that the kernel or some DTS was raising the logical state of the pin, but thank you for telling me about the pull up. Mar 14 23:45:32 you should be able to check easily by measuring the voltage Mar 14 23:46:35 yes :D Mar 14 23:46:37 I will not do a voltage divider, I will do the following: a pull down just at the pin out and a resistor adjusted to the current I need between the pin and the base of the transistor. So I do not lose current in the collector if I choose a voltage divider .. Mar 14 23:47:18 I don't understand what you mean Mar 14 23:48:45 you'd only have a voltage divider as long as the weak internal pull-up is enabled. once you reconfigure it as output (and/or change the internal pull-up to internal pull-down), there's no longer a voltage divider Mar 14 23:50:11 yes Mar 14 23:50:15 Yes, if I could send a diagram it would be easier to explain, but if I'm still here I'll be back in 10 minutes with the result :D Mar 14 23:50:40 go measure and experiment! that's more important than trying to explain to me probably :) Mar 14 23:50:54 :D :D Mar 15 00:15:47 | Mar 15 00:15:48 | Mar 15 00:15:53 10K / Mar 15 00:15:58 GPIO ----[===]----| Mar 15 00:16:03 | \ Mar 15 00:16:07 | | Mar 15 00:16:10 |-| | Mar 15 00:16:13 |_| 1K | Mar 15 00:16:16 I tried to apply an overlay in /boot/uEnv.txt (to change USB1 mode to OTG), I wrote `dtb_overlay=/lib/firmware/USB1-00A0.dtbo` there, dr_mode changed as expected, but suddenly P8 and P9 pinmuxes disappeared in /sys/devices/platform/ocp/. What's going on? Mar 15 00:16:16 | | Mar 15 00:16:20 | | Mar 15 00:16:23 ---------------------- GND Mar 15 00:16:29 uh, try a pastebin next time abreu Mar 15 00:16:44 :D Mar 15 00:16:46 abreu: indeed, don't paste multi-line output into irc Mar 15 00:16:50 sorry, disrupted your picture ) Mar 15 00:17:19 mixaz: on older images cape-universal would be automatically disabled if any custom overlay is enabled. this should no longer be the case on the latest image Mar 15 00:17:20 no probleam :P Mar 15 00:18:22 yes, I know, so I put row by row: D Mar 15 00:18:51 zmatt: i made the first option => https://pastebin.com/13WT9Qf2 Mar 15 00:19:15 DTS: https://paste.ubuntu.com/p/PbrVB5pTSD/ Mar 15 00:19:35 abreu: yes, the first option is the correct one Mar 15 00:19:53 not to make a voltage divider, but the pull-down was enough to make it less than 0.65v. Mar 15 00:20:01 before the overlay: https://paste.ubuntu.com/p/JvtmFmRMtV/ and after: https://paste.ubuntu.com/p/XbGF5gzJWv/ Mar 15 00:20:53 probably `dtb_overlay` in uEnv.txt has some default value? Mar 15 00:20:57 mixaz: it's not related to the contents of the overlay, merely the presence of one. reflashing to the latest image, or at least upgrading the bootloader (first make sure you have the latest overlays package) would fix it Mar 15 00:21:04 no Mar 15 00:32:08 zmatt, could you pls elaborate - I use an old kernel 4.9 (downgraded from 4.14), and already added some other overlay to uEnv.txt (via uboot_overlay_pru) and it seems to work OK. Do you mean that there's some mismatch between bootloader version and uEnv.txt? Mar 15 00:33:47 kernel doesn't matter, only u-boot version does. uboot_overlay_pru indeed does not trigger this same phenomenon, only the nine variables used for actual capes and custom overlays Mar 15 00:34:01 wow Mar 15 00:34:05 why did you downgrade the kernel? 4.9 is getting pretty dated Mar 15 00:34:29 because beaglelogic project uses it Mar 15 00:35:16 they haven't forward-ported yet? that sucks Mar 15 00:36:24 I did wrote some code for PRU using that projects as a sample, tried to port to 4.14, but it didn't go smooth, and I'm too lazy and stupid, waiting when they do the job instead Mar 15 00:36:51 they should have stuck with using uio-pruss for loading the pru firmware, that API has been stable from kernel 3.x all the way up to 4.19 so far Mar 15 00:37:09 while apparently remoteproc-pru drastically changed in every major kernel version so far Mar 15 00:37:22 (it's still not in mainline) Mar 15 00:39:01 yeah. I know only about remoteproc-pru, but I feel you're right it would be better to use uio-pruss Mar 15 00:39:03 )) Mar 15 00:39:47 remoteproc-pru is an API sourced by TI? Mar 15 01:08:31 yes Mar 15 01:08:43 well, so is uio-pruss, but that's much older **** ENDING LOGGING AT Fri Mar 15 02:59:57 2019