**** BEGIN LOGGING AT Fri May 20 02:59:59 2016 May 20 06:00:30 Hello I am new to Beagle Bone and want to know about progarming for beagle and zigbee in C, is there any manual or guide which will help me getting started? May 20 06:03:19 your question is at the same time far too vague and yet strangely specific... the beaglebone has no particular functionality related to zigbee, which means that "programming for beagle and zigbee in C" is no different from "programming for and zigbee in C" May 20 06:05:26 which itself is just composed of "programming in C" and "using a zigbee stack" May 20 06:06:32 It is actually, is there something that can help me with the zigbee stack? The code has not much comments for one to understand it completely ! May 20 06:07:17 I've never used zigbee myself May 20 06:07:37 I am using it for the very first time too May 20 06:08:57 So how do you use beagle bone for programming? May 20 06:09:46 Are there sample codes for understanding the basics of the beagle bone ? May 20 06:09:58 exactly the same as any other system (plus there's some web-based thingy installed on the default images but I've never really used it) May 20 06:10:24 it's just a small ARM-based computer running linux May 20 06:11:11 most commonly debian, although other distros are also in use May 20 06:11:19 It is. What i want to do is get data from a zigbee temperature sensor and may be store it on the board in some file. May 20 06:11:59 But I am not getting anything specific about how to do this! May 20 06:12:10 I've never used zigbee and know nothing about whatever interface modules or software stacks are available May 20 06:13:14 you obviously need some external interface/controller module since the beaglebone has no innate wireless transceivers May 20 06:17:00 Yes for that I am using ZigBee CC2531 dongle which can be pluged in the USB port of the beagle bone May 20 06:23:29 I see TI chose the beaglebone as their preferred development platform for that thing, which is probably what ultimately brought you here May 20 06:24:53 they have a zigbee module? May 20 06:24:53 they probably that so because it's a low-cost platform that's based on a TI processor. since it's an usb dongle though, it would probably also work fine on any other system May 20 06:25:07 wonder if they got the key thing sorted out May 20 06:25:21 http://www.ti.com/tool/CC2531EM-IOT-HOME-GATEWAY-RD May 20 06:27:23 Mukesh: TI actually mentions in the description of their "Z-Stack": "Ability to run on most Linux or Android-based platforms" May 20 06:29:33 Yes it does mentionn that, but the problem is there is nothing about application developement and I need it ! May 20 06:32:39 if true then you should complain to TI about that, not to us :P e.g. http://e2e.ti.com/support/wireless_connectivity/zigbee_6lowpan_802-15-4_mac/f/158 May 20 06:37:35 Mukesh: the thing you're trying to get help with is software development for TI's Z-Stack. the host platform (a beaglebone black in this case) is largely irrelevant May 20 06:38:28 I don't think I've ever seen zigbee discussed here, so I fear you're not likely to get useful help here May 20 06:39:32 feel free to hang around though, it's always possible someone might still have useful tips May 20 06:40:25 hmm May 20 06:41:45 * tbr could help with 6lowpan :-> May 20 06:41:56 both use IE³802.15.4 May 20 06:54:43 http://standards.ieee.org/about/get/802/802.15.html there ya go, all the help you need! :D May 20 07:27:47 ZMatt, Thank you for your help :) May 20 08:03:09 whoa, I was helpful? that was an accident May 20 09:25:30 odd that the wilink8 "level-shifting i/o" datasheet doesn't mention the twl1200 ... it seems quite suitable May 20 12:10:26 hi, /sys/devices/platform/bone_capemgr/slots file is confusing for me. I can echo dts file in it. But Can I write multiple lines in the file slots. I'm asking this because when I start the bbb with LCD7' I cannot echo (output:-bash: echo: write error: File exists) May 20 12:11:57 you probably need to use multiple separate writes May 20 12:13:16 note that everything in sysfs is magic... they're not actual directories or files, they're kernel objects and their attributes represented via an interface that makes it look like a filesystem May 20 12:25:40 zmatt: Thanks for the answer. Yes magic is the Word. What do you mean by 'multipleseparate writes' May 20 12:25:47 ? May 20 12:26:54 echo OVERLAY1 >/sys/devices/platform/bone_capemgr/slots May 20 12:26:57 echo OVERLAY2 >/sys/devices/platform/bone_capemgr/slots May 20 12:26:59 actually I have this http://pastebin.com/GyR8Mw4t (with the LCD) May 20 12:27:57 note that what you read from it looks very different to what you write to it May 20 12:28:44 you always just write the name of the cape, or the name preceded by a minus sign to remove the overlay May 20 12:29:53 note that since kernel 4.1 there's also a newer mechanism to add overlays via configfs May 20 12:30:06 I made utilities to simplify using that: https://github.com/mvduin/py-uio/tree/master/dts/bin May 20 12:31:12 add-overlay takes as argument a path to a dtbo file, rm-overlay the name(s) of one of more overlays (filename without the ".dtbo") May 20 12:32:36 note that although the two mechanisms ultimately use the same underlying kernel infrastructure, they're not aware of each other... so capemgr overlays don't show up in configfs (hence not in the output of my list-overlays utility), and configfs overlays don't show up in the capemgr slots file May 20 12:33:31 capemgr's actual purpose is for automatically adding overlays for true CAPEs detected via i2c May 20 12:34:12 using it to add overlays is somewhat abuse of it, although it was common since there wasn't a generic way to add custom overlays in earlier kernels May 20 12:35:42 ok ok. huge amount of info ;). Stupid question: overlay is filename.dts or filename ? May 20 12:38:57 differs for the two mechanisms. for my utility it is a path to the .dtbo file (not dts, those need to be compiled first). capemgr looks for /lib/firmware/CAPENAME-VERSION.dtbo where CAPENAME and VERSION are normally obtained from the CAPE's eeprom. when using the slots file to manually add an overlay, you just give the "CAPE name" (even though it's not really a cape) and it uses 00A0 as the version May 20 12:39:32 so if you echo FOO >/sys/devices/platform/bone_capemgr/slots then capemgr will try to load /lib/firmware/FOO-00A0.dtbo May 20 12:39:47 So, when I start the bbb with LCD I have http://pastebin.com/GyR8Mw4t slots. But I want to use other pwm output which isn't use by LCD. If I understand you I have to use add-overlay /opt/source/beaglebone-universal-io/cape-universaln ? May 20 12:43:43 my utility wants a file path that's a dtbo file, which that clearly isn't. afaik normally cape-universal is normally enabled via /boot/uEnv.txt to load it automatically at boot. I normally always turn that off however since I think cape-universal is an ugly hack and it conflicts with nearly every other overlay May 20 12:45:31 which pwm do you want to use? May 20 12:45:38 ok ok , could you advise me a dtbo file which can set pwm output ? May 20 12:45:48 all ;) May 20 12:46:08 without pwm used by LCD May 20 12:47:03 Do you want a precise answer or ...? May 20 12:47:07 there are actually a lot of pins that can be used for pwm, and for several pwm outputs you also have a choice of multiple pins May 20 12:47:56 in my pins spreadsheet ( https://goo.gl/Jkcg0w ) on the P9 and P8 tabs, pwm-capable functions are marked in orange May 20 12:48:51 looks like lcd conflicts with only two of them (pwm 2 A/B) May 20 12:48:58 (pwm 1 A/B are also available on P9) May 20 12:50:55 hold on May 20 12:52:29 my py-uio project also includes tools that make it significantly easier to make overlays May 20 12:53:07 I'll make one example for pwm1, but since I normally use uio myself I quickly need to look up the necessary parameters for using the kernel driver :) May 20 12:53:39 ok thanks May 20 13:05:41 could you do: grep -Pv '^#|^$' /boot/uEnv.txt May 20 13:05:52 just do check on your boot config May 20 13:05:55 *to check May 20 13:07:53 I've also just verified: any instructions involving writing "cape-universal" or variations thereof to capemgr slots only apply to old kernels (3.x) May 20 13:08:07 actually only to 3.8.x apparently May 20 13:10:22 uname_r=4.1.18-ti-r53 May 20 13:10:28 cmdline=coherent_pool=1M quiet cape_universal=enable May 20 13:10:48 so you actually should have cape_universal enabled already May 20 13:11:48 that kernel is moderately old btw, you may want to update to the latest 4.1-ti kernel May 20 13:12:36 apt-get update && apt-get install linux-image-4.1.24-ti-r61 May 20 13:13:51 thanks, I'll do it May 20 13:14:53 if you're wondering how I easily checked the latest version, first run apt-get update (if you haven't yet already in the last day or so) then: May 20 13:14:56 apt-cache search -n 'linux-image-4.1.*-ti-r[0-9]+$' | sort -V | tail -n 1 May 20 13:15:30 hmm, better regex would be: May 20 13:15:49 apt-cache search -n 'linux-image-4\.1\..*-ti-r[0-9]+$' | sort -V | tail -n 1 May 20 13:17:22 so the search is for package names for kernels in the 4.1-ti series, then sort by version number and grab the last line :) May 20 13:18:28 ok, I did noticed the difference between the 2 lines, haha ;) May 20 13:18:39 \ May 20 13:20:44 yeah my failure to escape the first dot is benign since there's really not going to be any other character there, but forgetting the \. after the 1 means it would also have matched kernels 4.10 and later... it'll still be a while though before those become available :) May 20 13:21:05 we're at 4.6 now (though not in the -ti series) May 20 13:44:31 wait, you have an LCD cape but are using the default dtb? May 20 13:45:32 ohh wait, are you using a beaglebone black or green? May 20 13:46:12 I just plug the LCD and it works. I think default. Black :( May 20 13:47:04 forget to mention sorry May 20 13:48:34 huh, weird, the default dtb for the black includes HDMI output which should conflict with using an LCD cape May 20 13:49:26 pastebin /boot/uEnv.txt ? May 20 13:49:52 well the grep I let you do already searched for all relevant lines (it skipped blank lines and comments) May 20 13:50:43 what is uuid ? May 20 13:51:36 it's the third line of the grep May 20 13:52:44 an ugly hack needed because most kernel versions don't give stable numbering to mmc devices, so identifying it by filesystem uuid is used instead May 20 13:52:58 any other lines from your uEnv.txt you neglected to mention? :P May 20 13:53:37 nope ;) May 20 13:53:57 grep -Pv '^#|^$' /boot/uEnv.txt uname_r=4.1.18-ti-r53 cmdline=coherent_pool=1M quiet cape_universal=enable uuid=c2e59c0a-1da1-4019-886f-17c045ad0fa0 May 20 13:58:31 lol, overlays suck so hard... I first inserted cape-universaln using my add-overlay... then realized that the config-pin utility associated with cape-universal only supports the use of capemgr and not configfs so I removed it there and inserted it in slots instead... kernel panic May 20 14:00:58 aouch May 20 14:03:10 removal is actually the more dangerous part, I was surprised it didn't kernel panic then but only when I tried to reinsert May 20 14:03:28 especially since cape-universal meddles with everything and the kitchen sink May 20 14:05:07 it seems cape-universaln does enable all pwm devices though May 20 14:06:13 labeled in some seemingly random way May 20 14:06:24 just to make it extra easy to find the right one May 20 14:06:48 yes I manage enable all pwm but without the LCD May 20 14:06:57 *managed May 20 14:07:10 then there's probably some pin conflict May 20 14:07:24 which is not surprising, like I said cape-universal conflicts with almost any other overlay May 20 14:07:32 that's why there are so many variants of it May 20 14:07:50 all of them are "cape-universal, except for this or that pin since it's occupied for something else" May 20 14:08:18 lemme see if my pwm-specific overlay works May 20 14:08:29 (time to reboot since I know I can't safely remove cape-universal) May 20 14:11:23 Is it possible to enable (with a dts) just some pwm that I want in order to avoid conflict (I don't want trouble, just pacific guy) May 20 14:11:42 yes, that's exactly what I'm testing now May 20 14:23:08 dirkk: in any case you should remove the cape_universal=enable from your /boot/uEnv.txt May 20 14:24:35 and add: dtb=am335x-boneblack-emmc-overlay.dtb to disable HDMI. no idea why the lcd cape works nonetheless, maybe it gets applied before the hdmi drivers get loaded, but then the hdmi-audio pins would probably still be claimed May 20 14:24:38 zmatt: by doing this LCD will still be functional ? May 20 14:24:54 I'm surprised the LCD is functional *without* it May 20 14:25:31 I'm also still puzzled why my overlay doesn't work even though it should have all the right ingredients May 20 14:26:56 ok May 20 14:27:03 LCD use this 0: P---L- 0 4D 7.0 LCD CAPE- 4DCAPE-70T ,00A3,4D SYSTEMS ,BB-BONE-LC D7-01 May 20 14:27:22 BB-BONE-LC ? May 20 14:27:51 BB-BONE-LCD7-01 May 20 14:27:58 no idea what those spaces are doing there May 20 14:28:13 hah May 20 14:28:18 your lcd uses a pwm May 20 14:28:21 https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD7-01-00A3.dts May 20 14:28:27 yes for the brightness May 20 14:28:50 so that one is already claimed by the lcd overlay May 20 14:29:23 along with a bunch of other pins May 20 14:34:05 so, I add the 'dtb=am335x-boneblack-emmc-overlay.dtb' in uEnv.txt . Where is this 'dts' stored ? May 20 14:36:14 /boot/dtbs/$(uname -r)/ May 20 14:37:31 argh I'm an idiot May 20 14:38:01 I once again accidently typed status="disabled" instead of status="okay" May 20 14:38:21 *enabled sorry May 20 14:38:36 what idiot came up with "okay" as opposite of "disabled" anyway May 20 14:39:04 haha ;) May 20 14:39:29 now it works May 20 14:43:29 you're editing dts May 20 14:47:45 http://pastebin.com/Mduupacd May 20 14:50:54 so this is syntactically quite nicer than manually writing an overlay would typically be... since the file is preprocessed I can use macros for pin stuff, and it uses a little perl script to convert from dtsi syntax to overlay dts syntax May 20 14:51:49 ok still reading it ;) May 20 14:51:55 (I should probably split this part off from py-uio since it is clearly useful independent of it) May 20 14:53:43 you create pwm1.dtsi as example as you said it May 20 14:54:16 the process remain the same for all pwm May 20 14:54:23 ? May 20 14:55:25 for pwm0 just change all the 1s to 0s (epwmss0, ehrpwm0, pwm0, pwm0_pins) May 20 14:55:38 and change the pin declarations to use the correct pins and pinmode May 20 14:55:59 status for subsyst. then PIN_OUT_NOPULL( PX_XX, X ) config then status for pwm . May 20 14:56:47 it seemed sensible to write it in that order but I don't think the order actually matters May 20 14:57:40 if you want to use ecap as pwm outputs it's basically the same, but with ehrpwm replaced by ecap May 20 14:58:11 same subsystem, i.e. ecap0 also lives in epwmss0 May 20 15:00:29 the name and label of the pinmux block (e.g. "pwm1" and "pwm1_pins") aren't really important, as long as the name is unique within the &am33xx_pinmux node and the label is unique among all labels of the overall device tree... that's why I gave the label a longer and unambiguous name May 20 15:02:34 ok so in the 'folder' pwmchip0@ you have pwm1 or ? May 20 15:03:25 why this line pinctrl-names = "default"; ? and not pinctrl-names = "pwm"; maybe stupid question ;) May 20 15:03:39 the name is the state of the device May 20 15:05:21 some devices also support a 'sleep' state, which might e.g. change the pins to gpio May 20 15:05:55 to be used when devices are disabled to put the system into suspend May 20 15:06:20 and pwmchip0 is referring to the peripheral May 20 15:07:22 I just realized I picked the wrong pwm peripheral as example though, since this one has one pin conflicting with your lcd cape May 20 15:08:10 should still be fine though if you load it before loading the lcd cape May 20 15:09:48 to control the pwm1b output from userspace you need to export it with echo 1 >/sys/class/pwm/$device/export (the 1 is referring to the B output, the A output would be 0) May 20 15:10:02 it'll appear as child folder of the pwmchip device May 20 15:10:04 yes it's fine. Last question this cannot be undo by plugin the LCD for example (I mean if I took the right, no conflit pwm) May 20 15:10:36 oh actually it will conflict May 20 15:10:46 you need to remove the pinmux for 1a from your overlay May 20 15:10:59 otherwise the kernel should detect conflicting pinmux May 20 15:12:10 there will be some consequences of sharing the pwm output since e.g. the two outputs only have independent duty cycle but always the same frequency May 20 15:12:38 so in principle there shouldn't be a problem with you using the B output while the cape uses the A output, but I'm not sure how it'll work out in practice May 20 15:13:28 Yes for the pwm used by LCD. But I mean if I do this for instance for P9_31 et P9_29 ehrpwm0A/B May 20 15:13:46 then you can just export both outputs May 20 15:15:53 lol wtf May 20 15:16:23 nice, well done guys May 20 15:16:24 # echo 50000 > /sys/class/pwm/pwmchip0/pwm0/period May 20 15:16:25 Segmentation fault May 20 15:16:52 yeah I will keep informed if I have trouble ;) BIG Thanks. No.... May 20 15:16:56 ;) May 20 15:17:52 maybe this happened because I removed and reinserted the overlay May 20 15:19:08 you mean pwm1.dtbo May 20 15:19:10 , May 20 15:19:12 ? May 20 15:19:19 this sort of crap is why I normally 1. don't use overlays 2. often access peripheral registers directly from userspace instead of relying on some (often crappily written) kernel driver May 20 15:19:26 hmm? May 20 15:20:23 note that the pwmchip numbering is just according to the order in which the kernel encountered pwm devices May 20 15:23:00 I found that pwmchipX vary May 20 15:23:03 so to be sure which peripheral is which you need to check everything in /sys/class/pwm/ and check what those symlinks are pointing at May 20 15:23:07 or, use: May 20 15:23:08 ls /sys/devices/platform/ocp/48302000.epwmss/48302200.ehrpwm/pwm/*/ May 20 15:23:22 yeah May 20 15:24:51 the problem is that sysfs was meant to be mostly informational, not really a way for applications to interface with devices... that's what devices in /dev are for, and those can be given useful aliases using udev rules May 20 15:25:31 I made a spreedsh this morning. I used :/sys/devices/platform/soc/subsystem/devices May 20 15:25:42 for pwmchipX May 20 15:26:17 unfortunately as you noticed the pwmchipX numbering isn't stable May 20 15:26:30 yes May 20 15:26:34 this is true for most device numberings May 20 15:27:13 the instability for mmc device numbering is exactly what led to the introduction of uuid in /boot/uEnv.txt May 20 15:27:30 when you said access peripheral registers directly from userspace. It Read Mem By Addr and Write or more complicate May 20 15:27:50 look at the readme of the git project you cloned :) May 20 15:28:59 it's a project for directly accessing peripheral registers using python3.4 May 20 15:29:57 it includes an example for eQEP but not yet for the other pwmss modules... eHRPWM modules have an extra complication since they need their timebase clock enabled via the control module May 20 15:30:06 still need to figure out a clean way to work around that May 20 15:30:57 ok great work, Again Thank you for your time ;) May 20 15:32:38 the qep-test.py is already a nice example showing that direct register access becomes relatively simple :) I probably should use constants for the "magic values", then again you'd need to consult the documentation anyway to know what exactly those bits do May 20 15:32:56 the register map for the peripheral is defined in ti/qep.py May 20 15:33:01 which isn't very complicated either May 20 15:36:48 unfortunately you can't have a mix of kernel drivers and uio for the same pwmss May 20 15:36:54 well, not easily May 20 20:33:34 My beaglebone eMMC when in a kind of read-only mode, when playing with motor and PWM. May 20 20:33:47 Looking at dmesg I got this kind of error I think : May 20 20:33:59 [ 196.702675] mmcblk0: error -110 sending status command, retrying [ 198.629500] mmcblk0: error -110 sending status command, retrying [ 198.635823] mmcblk0: error -110 sending status command, aborting [ 198.642127] end_request: I/O error, dev mmcblk0, sector 198664 [ 198.648229] Buffer I/O error on device mmcblk0p2, logical block 1 [ 198.654594] lost page write due to I/O error on mmcblk0p2 [ 202.502187] mmcblk0: error -110 send May 20 20:35:30 I imagine this is a kind of 'safe mod' that was trigger by something problematic happening of the pins May 20 20:36:23 Is there other place than dmesg that I can look to to find what trigger this move to read-only by the BBB ? May 20 21:12:31 hello May 20 21:13:03 I am building my own am3358 based board May 20 21:13:31 neat May 20 21:13:45 and i have a question on the uart0 in the schematic of the BBB May 20 21:13:56 why do we need a SN74LVC2G241? May 20 21:14:13 why dont connect directly to the header? May 20 21:19:00 ljo: because once you connect a serial cable, you'd be driving a voltage onto the BBB's I/O May 20 21:19:45 if the BBB is powered off, that's Bad(tm) May 20 21:21:02 but if you're debugging boot or shutdown issues (the most common reason to need the serial console), it would be very inconvenient and complicated if you'd have to ensure the cable is disconnected whenever the bbb is powered off May 20 21:25:00 btw, if making a new design, consider researching known issues of the bbb instead of copying it directly ;) in particular, unless you intend to use the li-ion charger functionality of the bbb, you may want to explore the option of using a different one (e.g. the TPS65910A31A1) May 20 21:26:01 (if you do want to use the li-ion battery support of the tps65217, do check http://elinux.org/BeagleBone_Power_Management and follow the links there about known issues) May 20 21:31:10 I can probably think of more known deficiencies with the bbb design if you're interested, although it'll have to wait since I need to do some other stuff first now May 20 21:34:08 thank you May 20 21:34:52 but why a pull down resistor ? May 20 21:35:21 im a newbie sorry May 20 21:36:30 although pull-up is indeed seen more often, pull-down is actually more correct. a continuous high level indicates a valid but idle connection, a low level indicates a broken connection (hence the name "break") May 21 01:25:43 i wish the am335x just had a fet on ever input May 21 01:26:02 i feel like the board is so delicate May 21 01:31:32 ayjay: there are io buffers designed for just such purposes .. I'm not sure whether anyone's made a cape of them yet May 21 01:40:23 veremit: bidirectional and high-speed? :P May 21 01:40:44 zmatt: possibly not .. but better than using the am335x as an expensive fuse :) May 21 01:41:18 a nanny-cape might be useful, but bidirectional level shifters tend to be awful for signal integrity May 21 01:41:21 and define "high speed" bi-directional buffers are less of aproblem these days May 21 01:41:39 yes .. think of our users, zmatt ... lol .. May 21 01:42:29 apparently there are decent-ish ones where a transition on one side basically makes the other side briefly push-pull May 21 01:45:42 this is impressive... a colleage got some error when he inserted an sd card, then the system hung, and then failed to boot May 21 01:46:13 I just hooked it up to serial console... I'm not even reaching SPL anymore, ROM is regarding eMMC as non-bootable May 21 01:47:14 wuh-oh May 21 01:47:22 CCCCC? May 21 01:51:37 yes, and then it booted from my tftp server causing it to enter mass storage mode... so I'm about to check wtf happened to that thing May 21 01:54:16 wow lol nice May 21 01:55:26 O.O May 21 01:55:30 what May 21 01:55:32 the May 21 01:55:33 f May 21 01:55:39 oooookay May 21 01:55:44 ?? May 21 01:55:46 ehm May 21 01:56:30 the first 108 MB (exactly, not approximately) of eMMC are all-zeros May 21 01:59:59 very nice **** ENDING LOGGING AT Sat May 21 02:59:58 2016