**** BEGIN LOGGING AT Sat Oct 15 02:59:58 2016 Oct 15 06:20:50 hello Oct 15 06:21:02 I am new on oe Oct 15 06:21:33 how can i install gnuradio on beagle board xm??? Oct 15 06:22:04 also with native os(angstrom) Oct 15 06:45:50 mehrdad, http://www.kd0cq.com/2014/08/packed-full-beaglebone-black-img-file-rtl-sdr-gnuradio-gqrx-lots-more-on-ubuntu-14-04/ Oct 15 06:46:16 this is a bbb image with ubuntu and gnuradio n friends Oct 15 06:48:55 is this apropriate for beagle board xm??? Oct 15 06:50:00 this is dont know, sorry didnt notice your xm request Oct 15 06:50:48 but i guess there is a ubuntu img for xm Oct 15 06:51:32 well rechecking the xm, i think the mentioned image might be good enough Oct 15 06:52:12 thank you i will check it Oct 15 06:52:29 have fun Oct 15 06:53:12 i will be thankful for any suggestion and help Oct 15 06:54:07 u building a radio device ? Oct 15 06:54:45 not actually Oct 15 06:55:14 im testing gnuradio on this board for sound in/out Oct 15 08:51:13 Hello People Oct 15 12:05:28 Hello ? Oct 15 19:27:11 hi :) Oct 15 19:31:03 i tried connecting my bbb with an 3.3V arduino. somehow the sdl and scl lines are at 1.2 Volts if i connect them to the beaglebone pins. undconnected the bbb is at 0 an the arduino at 3.3v. this seems very wrong... Oct 15 19:42:07 didn't find anything in the SRM. pins should be in the right mode, since i've enabled them by writing "BB-I2C1" in the capemanager slots. Oct 15 19:48:11 the i2c communications works btw... just the voltagedrop seems odd. the link to "this guide to asking smart questions" is down. so please be patient :) Oct 15 21:34:28 knttl: did you by any chance forget pull-ups on the sdl and scl lines? Oct 15 21:34:55 (I²C always requires external pull-ups) Oct 15 21:35:03 zmatt: thanks for the answer :) the arduino uses internal pullups :) Oct 15 21:35:20 how strong are those? Oct 15 21:35:49 when i disconnect the bbb and measure the arduino pins there are 3,3V. and connected to the bbb there are 1.2 Oct 15 21:36:08 don't know exactly... will look it up Oct 15 21:36:11 "undconnected the bbb is at 0" <-- that sounds wrong too, are the bbb pins configured with pull-down instead of pull-up ? Oct 15 21:36:46 though if that's the reason you get 1.2V then the arduino has pretty feeble internal pulls just like the bbb, which means you need external pull-ups anyway Oct 15 21:37:03 bbb is around 50Kohm-150Kohm Oct 15 21:37:57 i think something like 5kohm sould be okey... Oct 15 21:38:42 i thought if i set the bbb pins to the right mode without changing anything else there are no pull ups or downs.. Oct 15 21:39:31 pulldown on i2c isn't really usefull, is it? Oct 15 21:39:43 all pins have pull-up or pull-down enabled by default Oct 15 21:39:54 no, but the default pull on a pin isn't dependent on the mux mode Oct 15 21:40:35 (to be a bit more precise: the lcd_data pins do not have internal pulls enabled by default, but they have external 100K pulls on the beaglebone pcb) Oct 15 21:41:18 hm... where do i find this kind of information.? Oct 15 21:41:46 my pins spreadsheet for example: https://goo.gl/Jkcg0w the P9 and P8 tabs give a quick reference of the expansion header pins of the bbb Oct 15 21:41:47 i didn't find information of the voltage used at the i2c pins. just assumed it was 3,3 as everthing else... Oct 15 21:42:03 all digital I/O on the beaglebone is 3.3V Oct 15 21:42:32 which means you should always hovering the voltage at 1.2V (something that can happen basically only due to pull-conflict) for too long Oct 15 21:42:36 *should avoid Oct 15 21:44:23 pull-up resistor values for i2c can be found in section 7.1 of http://www.nxp.com/documents/user_manual/UM10204.pdf Oct 15 21:46:08 is it possible to disable the pullups completely? Oct 15 21:46:13 yes Oct 15 21:46:57 which pins are you using btw? Oct 15 21:47:35 hm... thats really a lot to read before you can use somthing as simple on the bbb without fearing to fry the board... Oct 15 21:48:12 hehe, screwing up the pull-up value shouldn't fry anything unless you use really way too small value Oct 15 21:48:23 probably 100ohm would still not be damaging Oct 15 21:48:58 I'm still a bit puzzled though, since I'd expect any i2c overlay to enable internal pull-ups Oct 15 21:49:25 can you verify using my show-pins utility: https://github.com/mvduin/bbb-pin-utils Oct 15 21:50:06 using ping 17 and 18 on the P9 header.. Oct 15 21:53:33 what sould i verify with your utility? :) Oct 15 21:53:36 ok. do be a bit careful with those, for some boot modes (in particular when powering on with the S2-button held down) those pins are configured as output during early boot (until reconfigured e.g. by an overlay), so I'd recommend using a series resistor just to be safe Oct 15 21:53:54 the mux mode and pull direction (it shows "up" or "down" if enabled) Oct 15 21:54:18 will try it. give me a second... Oct 15 21:58:33 I found some other source mentioning the arduino has weak internal pull and external 4.7k pull-ups should be used Oct 15 21:59:08 to be precise its an arduino pro mini. the 3.3V version... Oct 15 21:59:47 but i found something similar. 4.7 sounds right. Oct 15 22:03:50 zmatt: is there an option in your tool to show what the columns mean? :) Oct 15 22:04:47 what is the fast/slow column? :) Oct 15 22:05:36 the up/down column are pulls? Oct 15 22:06:19 hehe, no, minor oversight O:) but it's not very hard: pin description, index (in padconf array), slew (fast/slow), receiver enabled (rx), pull (up/down), mux mode (0-7), pin function (= description of mux mode), usage according to kernel Oct 15 22:07:03 pins requested as gpio in the kernel also shows value and direction in the pin description column Oct 15 22:08:12 P9.18 / spi boot out 86 slow rx up 2 i²c 1 sda i2c@4802a000 (pinmux_bb_i2c1_pins) Oct 15 22:08:14 P9.17 / spi boot cs 87 slow rx up 2 i²c 1 scl i2c@4802a000 (pinmux_bb_i2c1_pins) Oct 15 22:09:59 eh, ok, that actually means they have internal pull-up enabled Oct 15 22:10:22 zmatt: thats strange.. Oct 15 22:10:32 measurement shows 3.3v... Oct 15 22:10:34 wtf? Oct 15 22:11:22 more like 3.1 but thats fine i think... Oct 15 22:11:27 yes Oct 15 22:12:20 that's due to the weakness of the internal pull-up combined with some leakage in the input buffer probably Oct 15 22:13:48 is the ground of the ardino thoroughly connected to the ground of the bbb? Oct 15 22:14:03 also make sure both devices are powered up before loading the overlay Oct 15 22:15:34 yes common ground. can't be shure the arduino is powered before loading the overlay. but its connected afterwards. so this should be no problem. Oct 15 22:15:39 also beware that hot-connecting after loading the overlay may cause glitches that confuse the i2c state machine; that can probably be cleared by performing some i2c transaction in master mode Oct 15 22:15:52 :D Oct 15 22:16:05 a stronger pull-up should reduce the sensitivity to noise and glitches Oct 15 22:16:48 this still doesn't explain 1.2V though, unless the arduino is driving the pins high (which it never should) Oct 15 22:19:29 thanks for the help. cant reproduce the phenomenon at the moment :D will send some data through and check again. Oct 15 22:19:55 connecting via a 100ohm series resistor is a simple way to avoid damage in case of drive conflicts, and also lets you recognize when this is happening by measuring the voltage across the resistor Oct 15 22:20:38 ok. i will do it. Oct 15 22:21:31 zmatt: single handedly helping all bbb users... :) Oct 15 22:23:10 btw the link http://bbb.io/boot and http://bbb.io/latest in the topic point to an empty page>? Oct 15 22:23:32 hi. not looking into PRU anymore, just trying to get the eQEP modules loaded. testing with debian jessie and 4.8.1-bone1 . i see a tieqep kernel module on my FS, but unable to modprobe it. any thoughts? Oct 15 22:24:07 rajesh: you normally never need to modprobe a module, the kernel loads them automatically Oct 15 22:24:53 zmatt: lsmod does not show tieqep as loaded.. Oct 15 22:25:18 also I don't think I've seen tieqep being included with 4.8 yet? it's an unofficial driver, not included in mainline linux afaik, so it needs to be ported to each new kernel version and perhaps that hasn't happened yet Oct 15 22:26:11 I remember being not very impressed with it, so I just use uio instead Oct 15 22:27:50 knttl: they seem to work here, although the boot flow chat is confusing and wrong, and the "latest" debian images aren't the latest Oct 15 22:32:05 zmatt: sry. false alarm again. had some necessary script blocked. Oct 15 22:32:34 not my day :D Oct 15 22:32:50 hehe Oct 15 22:46:22 zmatt: everything now works as expected. 3.3V at idle. no measuareable voltagedrop at the 100 Ohm resistor. Oct 15 22:47:00 i must have fucked up somthing else at the last measurement. Oct 15 22:54:15 zmatt: can you send me the link to your github a/c for the uio? Oct 15 22:54:19 thanks Oct 15 22:54:39 https://github.com/mvduin/py-uio Oct 15 22:55:01 which language would you consider the best for some simple communication protocoll on top of i2c? aka. which language has the best libaires? :) Oct 15 22:56:35 dunno, I think most languages probably have bindings for the i2c-dev ioctl interface Oct 15 23:28:29 zmatt: now looking into uio basics ... Oct 15 23:30:09 it basically lets a userspace process directly map a peripheral's registers, and also receive irqs from it Oct 15 23:30:56 right. you dind't use the mmap python module in your project, did you? Oct 15 23:31:05 yes Oct 15 23:31:24 ah yes, you did Oct 15 23:32:09 you open the appropriate /dev/uio device (I include udev rules to give them convenient symlinks and set up permissions) Oct 15 23:32:12 and then mmap it Oct 15 23:33:48 a device on a gpio pin gets registered on udev? Oct 15 23:34:33 exported gpios do, but this isn't about gpios Oct 15 23:36:11 Hello! Oct 15 23:36:41 an uio device exists because of a device tree node representing it; in case of eqep it's a node representing that peripheral, which I enable with this overlay: https://github.com/mvduin/py-uio/blob/master/dts/pwmss2.dtsi Oct 15 23:37:38 (I'm not entirely happy with that one and have tried different approaches over time) Oct 15 23:37:57 the pwmss modules are slightly more annoying than most other peripherals Oct 15 23:38:15 ok. Oct 15 23:38:45 it looks like the situation has improved in kernel 4.8, I still need to check whether my impression is correct and create a better overlay for it Oct 15 23:39:02 i think i'm just going to stop trying to find a readymade solution, and spend time understanding how this all works. Oct 15 23:39:07 hehe Oct 15 23:39:08 i was hoping i didn't have to. Oct 15 23:40:05 well my example is largely ready-made Oct 15 23:40:13 assuming it still works, haven't tested recently Oct 15 23:40:42 yeah, that makes me not very eager to commit... i'm sure you know what i mean Oct 15 23:41:54 well the thing is, since uio directly maps hw registers, and the hardware obviously isn't subject to change, the only reason it can break is due to the awkward structure of pwmss Oct 15 23:42:24 but even that is unlikely Oct 15 23:43:15 it's certainly less fragile than using the non-mainlined tieqep driver, which isn't guaranteed to be present at all anymore if you upgrade your kernel, let alone with unchanged API Oct 15 23:44:02 the kernel driver I use, uio_pdrv_genirq, has been an unchanged part of mainline linux since ancient history Oct 15 23:44:23 that module's loaded. Oct 15 23:44:34 i was going to investigate that a little. Oct 15 23:44:54 so here's how the ingredients fit together: Oct 15 23:45:01 i'm afraid 'a little' is not enough on this platform. :) Oct 15 23:46:03 https://github.com/mvduin/py-uio/blob/master/etc/modprobe.d/uio.conf this configures the uio_pdrv_genirq driver to match on compatible="uio"; property in device tree (for some weird reason it doesn't match anything by default) Oct 15 23:47:13 https://github.com/mvduin/py-uio/blob/master/dts/pwmss2.dtsi this device tree fragment uses that to create five uio devices: Oct 15 23:47:53 one for each of the three submodules (eCAP, eQEP, eHRPWM) Oct 15 23:47:56 zmatt: are you paid by TI, 'cos you should be for providing a valuable servie on this channel... Oct 15 23:48:02 nope Oct 15 23:48:07 :) Oct 15 23:48:20 an extra one purely for the second irq (tripzone) coming from eHRPWM Oct 15 23:48:36 and one for the pwmss subsystem in its entirety Oct 15 23:49:40 unfortunately the submodules are not page-aligned so you can't mmap those directly, in fact the whole subsystem's registers fits in a single page. that's one reason why the subsystem is needed as uio device Oct 15 23:51:48 the other reason is because the kernel needs to enable the pwmss in PRCM (power/reset/clock manager) before you can use it. this happens automagically when the pwmss device is opened (this is true regardless of what driver is used) Oct 15 23:52:29 when these five devices show up, my udev rules kick in: https://github.com/mvduin/py-uio/blob/master/etc/udev/rules.d/uio.rules Oct 15 23:53:29 note that in the overlay I gave each device an 'uio-alias' property; my udev rule extracts that and creates a /dev/uio/$alias symlink Oct 15 23:55:27 I then have python wrappers for pwmss and the (e)qep submodule: https://github.com/mvduin/py-uio/tree/master/ti Oct 15 23:56:19 where did you get the register structure from? Oct 15 23:56:35 is that a standard? Oct 15 23:57:33 https://github.com/mvduin/py-uio/blob/master/ti/qep.py these? they're simply from the TRM, though I renamed registers to be somewhat legible instead of looking like someone just bashed their keyboard Oct 15 23:57:56 gotcha Oct 15 23:59:49 (actually eqep's register names aren't that terrible, compared to e.g. those of EDMA) Oct 16 00:00:44 you should know there are a lot of terms that i haven't heard of before and search for, including eqep which was new to me until 2 days ago. now i search for edma Oct 16 00:00:47 :) Oct 16 00:01:59 oh! i was indirectly reading about edma through a blog post by ken shirriff Oct 16 00:02:37 hmm, no maybe not. Oct 16 00:03:05 yeah nope Oct 16 00:03:25 edma itself is reasonably okay, I've used it from userspace also (e.g. in combo with pwm to change the duty cycle each period, to create the funky control signal required for ws2812 leds) Oct 16 00:03:31 saw direct mem access and thought mmap-related Oct 16 00:04:03 uio is somewhat similar to /dev/mem, except: Oct 16 00:04:47 1. /dev/mem requires root privileges. uio limits access based on the DT declaration and you can assign ownership and permissions using udev. Oct 16 00:05:21 that's useful Oct 16 00:05:24 2. /dev/mem bypasses the kernel, which means you also have to manually operate PRCM. uio is a proper kernel driver hence the kernel will take care of such things for you Oct 16 00:06:17 3. uio also lets you receive irqs in userspace. Oct 16 00:10:04 zmatt: thanks for the detailed explanation. it's going to take me some time to digest... Oct 16 00:10:55 you're welcome :) Oct 16 00:11:38 I'm sort of an uio cheerleader ;) since it pains me to see the resources available on the am335x often being severely underutilized due to lack of convenience Oct 16 00:12:18 to the point of such ridiculous results as someone hooking up an external 555 timer to gpios... -.- Oct 16 00:22:58 zmatt: if you were to try something as simple as blinking an led, how would you do it? Oct 16 00:24:25 set the led trigger to 'timer' and configure the on- and off-time Oct 16 00:38:00 Can a L293D handle a 12v power supply if I plug it directly from the L293D H-Bridge to the I/O Pins of the BBB? Oct 16 00:38:49 I think that was asked incorrectly. Let me try again. Oct 16 00:39:27 that's what datasheets are for Oct 16 00:40:01 I know. Oct 16 00:40:10 I read it. It can. Oct 16 00:40:21 I am getting errors. Oct 16 00:41:00 the V_IH(min) is 2.3V, so it should be okay with a 3.3V control signal Oct 16 00:41:22 Should I be able to take a 5v cord apart and mess witht he wiring to harness power? Oct 16 00:41:29 ???? Oct 16 00:41:33 I am sorry. Oct 16 00:42:35 Project A: Make this damn motor go. Project B: Understand datasheets and the BBB. Project C: Make it all work. Oct 16 00:42:45 Now...I have a disconnect somewhere. Oct 16 00:43:15 I have it running on 3.3v and I do not expect the motor to turn. Oct 16 00:43:38 I do have a 12v motor that I can wire up but I am reluctant. Oct 16 00:43:39 the datasheet shows VCC1 should be between 4.5V and 7V (e.g. 5V is fine) and VCC2 should be beween VCC1 and 36V Oct 16 00:43:48 e.g. 12V is fine for VCC2 Oct 16 00:44:04 I know. How can I wire up the 12v? Oct 16 00:44:07 Serious? Oct 16 00:44:28 Should I put the power (live wire) to the ground on the BBB? Oct 16 00:44:35 uhh Oct 16 00:44:41 you connect ground to ground Oct 16 00:44:42 i.e. after it goes through the H-Bridge? Oct 16 00:44:46 OH...okay. Oct 16 00:45:17 Thank you. Oct 16 00:45:48 unfortunately I don't have any convenient way to sketch a schematic Oct 16 00:45:48 So...what does 12v go to? Oct 16 00:45:52 VCC2 Oct 16 00:46:05 I know. But where should I attach it on the BBB? Oct 16 00:46:13 you don't Oct 16 00:46:19 Thank you. Oct 16 00:46:51 I got this book, see. The schematic is wrong. Oct 16 00:47:00 I followed it until I was blue in the face. Oct 16 00:47:20 Now...I am slowly grasping that even books are wrong. I am sorry to waste your time. Oct 16 00:47:46 hold on, I'll just sketch a schematic on paper and scan it Oct 16 00:47:58 Do not. Oct 16 00:48:00 I am okay. Oct 16 00:48:10 I have the datasheet and I understand. Oct 16 00:48:53 I just wanted to use the external battery source or the 5v plug with hacked wires. Oct 16 00:49:21 I could not make my mind up. I wasted your time. Oct 16 00:57:29 Hey zmatt: ? Oct 16 00:58:14 I understand P9 and P8. I have those downpat. I understand the L293D H-Bridge. I get that, too. Oct 16 00:58:36 I still have one disconnect somewhere. Oct 16 01:01:24 The 12v will not turn on my board and I want to use it while I have it plugged in via USB. Oct 16 01:02:04 BBB = USB and 12v...for power and software execution. Oct 16 01:05:54 (note to self: next time use pen instead of pencil) Oct 16 01:06:45 Sorry. Oct 16 01:07:20 why are you apologizing for me using pencil? Oct 16 01:07:41 Because...without me, there would be no pencil. Oct 16 01:07:49 Ha! Oct 16 01:17:32 https://gerbil.xs4all.nl/bbb-motor.png Oct 16 01:19:09 I should have explicitly labeled that LM293D instead of LM293 but w/e Oct 16 01:19:26 zmatt: it is okay. I am going to check it out. Oct 16 01:22:36 the appropriate enable input should of course also be high Oct 16 01:22:48 What is that thing that looks like a watch? Oct 16 01:22:52 motor Oct 16 01:22:57 Augh...thank you. Oct 16 01:23:33 So, I need 5v and 12v instead of 3.3v and 12v? Oct 16 01:23:50 the lm293 requires 5V, not 3.3V Oct 16 01:24:31 02:43 < zmatt> the datasheet shows VCC1 should be between 4.5V and 7V (e.g. 5V is fine) and VCC2 should be beween VCC1 and 36V Oct 16 01:24:43 Augh...okay. This is where my disconnect is now. How can I get online and produce my software when I am not using 3.3v and attached to a computer? Oct 16 01:25:07 ????? Oct 16 01:25:20 Can I use PuTTY when I am attached via 5v? Oct 16 01:26:14 what do those things have to do with each other? the bbb always runs on a 5V supply Oct 16 01:26:34 I never run the 5v supply. Oct 16 01:26:41 usb provides a 5v supply Oct 16 01:26:46 Oh. Oct 16 01:26:53 I thought that produced 3.3v. Oct 16 01:27:34 the bbb generates 3.3V (and 1.8V, 1.35V, and 1.1V) from the 5V supply Oct 16 01:31:32 my board is fried. Oct 16 01:31:34 Damn. Oct 16 01:31:41 I need to set up a new system. Oct 16 01:31:42 what did you do? Oct 16 01:31:56 I plugged in the battery and the 5v to my motor go. Oct 16 01:32:23 Or something. Who knows? Oct 16 01:33:44 Damn it. Oct 16 01:34:08 No more power. Crap. Oct 16 01:34:34 Well...thank you anyway. I will ask more questions as time persists. Oct 16 01:34:42 Off to the old drawing board. **** ENDING LOGGING AT Sun Oct 16 02:59:58 2016