**** BEGIN LOGGING AT Mon Dec 01 02:59:58 2014 Dec 01 03:26:35 Hi, does anyone experiment with the BeagleBone Black Audio Cape Rev B before? Thanks Dec 01 03:51:18 veremit / derRichard: hmm, which reminds me I should maybe make some good baremetal examples for the am335x ... not having an OS getting in the way between you and your I/O can be quite liberating ;) Dec 01 03:57:57 (there's AM335x StarterWare of course, but what I've seen there made me want to gauge my eyes out with a spoon. stuff that, assuming it worked for the original author, did so purely due to lucky coincidence and compiling without optimization) Dec 01 08:14:14 zmatt: why bare metal? i use the am335x to have a nice os like linux.... Dec 01 08:16:52 for close to hardware, use PRU Dec 01 08:19:48 derRichard: for certain special applications, bare metal might be the right thing to do Dec 01 08:20:23 derRichard: but the effort you have to put in to get bare metal stuff running efficiently on a modern application processor is quite off putting Dec 01 08:20:38 KotH: i'm well aware for that, but then i don't use the am335x Dec 01 08:20:52 and in 99% of the cases, a properly written driver for linux solves the stuff as well as a bare metal solution Dec 01 08:20:59 very true Dec 01 08:26:10 KotH: well, the fact that the most recent kernel available from TI for the processor I'm actually working with is 2.6.37 may have helped somewhat with motivating me to try baremetal :P Dec 01 08:26:31 oh, and it only compiles with a specific gcc release from 2009 Dec 01 08:26:38 zmatt: let me guess, the kernel is done? Dec 01 08:26:45 hehehe Dec 01 08:27:06 2.6.37 is awesome Dec 01 08:27:19 zmatt: i can feel your pain :) Dec 01 08:27:38 zmatt: no current mainline kernel? Dec 01 08:27:54 * derRichard runs mainline on the bbb Dec 01 08:28:26 also, after a bit of learning-curve I'm actually starting to like it... in theory the plan is still to try to port a mainline kernel to it (dm814x) based on its similarity to the am335x, but I'm gonna miss the freedom I have right now Dec 01 08:28:27 anyone tried playing around with i2c on bbb running openbsd? Dec 01 08:28:45 Are the BBB kernel patches mainlined now? Dec 01 08:29:42 creemj: most of them Dec 01 08:29:49 no idea, but am335x at least seems decently supported... the official kernel for the dm814x also predates Device Tree which means that you're expected to patch the kernel with your custom board definition -.- Dec 01 08:29:50 there is no cape manager for example :) Dec 01 08:29:58 derRichard: is there a wiki page with mainline status? Dec 01 08:30:00 dmelani: not many people running *bsd on bbb Dec 01 08:30:04 Humpelstilzchen: no Dec 01 08:30:12 well, there is no cape manager in mainline Dec 01 08:30:25 KotH: i know. it's working rather nicely although i'm having issues writing data over i2c Dec 01 08:30:25 zmatt: the good old way Dec 01 08:30:26 dmelani: I can tell you the i2c peripheral is buggy as shit, if that's any help? Dec 01 08:30:27 av500: that's what i've said Dec 01 08:30:41 derRichard: Probably not a problem to me. Is there a useful default BBB kernel config mainlined? Dec 01 08:30:50 mainline is getting runtime DT changes only now Dec 01 08:31:04 dynamic dt is mainline Dec 01 08:31:08 once that is in one could think of redoing capemanager Dec 01 08:31:15 zmatt: yeah, i sort of suspected that. the thing wouldn't even compile at first Dec 01 08:31:29 creemj: the omap2 defconfig should work Dec 01 08:31:34 i2c: if in doubt, bitbang Dec 01 08:31:35 but then again, what fun is it if everything works out of the box? Dec 01 08:31:58 Good, I will give it a go as a need newer device drivers (with a bit of patching too probably) Dec 01 08:32:03 i'm not using the bbb for get it work. i need to develop stuff _ontop_ of it :P Dec 01 08:32:40 dmelani: I actually wrote an i2c-debugger running on another microprocessor which (using clock stretching) allowed me to single-step through an I2C transaction bit by bit to see what TI's I2C peripheral was doing and when it would report what via what irq Dec 01 08:33:22 zmatt: i'm sort of thinking of hooking an arduino up to it and see what the f it's doing Dec 01 08:34:46 at least reading from i2c works, so it's something... Dec 01 08:34:59 in the end I ended up asking for a HW patch to cut the I2C link between the main board (where the TI SoC lives) and the aux board (where the other processor lived), have each manage the few I2C devices on their side and communicate with each other via an uart link Dec 01 08:35:13 since I didn't see multi-master I2C ever going to work reliable Dec 01 08:36:07 yeah no. i'm not doing anything advanced like that. i just need to write a single byte to a register to get a stupid sensor out of suspend mode Dec 01 08:36:30 that it will manage, usually ;) Dec 01 08:36:47 derRichard: omap2plus defconfig ? there is no omap2 defconfig. Dec 01 08:36:58 any issues hw wise regarding i2c1 vs i2c2? Dec 01 08:37:13 am335x did have i2c hw issues iirc Dec 01 08:38:03 i'll just try the other bus and hope for the best before digging through the driver Dec 01 08:38:29 instead of keeping data-out low and just driving output-enable they drive both of them, timing skew then causes a brief current injection on the rising edge Dec 01 08:38:39 ... Dec 01 08:38:59 (and since it goes high-Z immediately after, that injection can then nicely bounce around) Dec 01 08:39:42 it's in the errata Dec 01 08:39:53 great... Dec 01 08:40:00 you didn't check the errata yet? Dec 01 08:40:07 nope Dec 01 08:40:31 i guess i know what i'll be doing later today then Dec 01 08:40:36 generally speaking, it's a good idea to check those ;) Dec 01 08:40:50 reading manuals before implementing stuff? pfft. Dec 01 08:41:40 assuming stuff actually works first time .. pfft indeed! Dec 01 08:41:40 well, otherwise you should have used an RPi... broadcom doesn't publish any official errata, so it's probably a bug-free chip Dec 01 08:41:49 *ahem* yea right Dec 01 08:42:05 (apart from how they totally screwed up I2C for example) Dec 01 08:42:25 if any chip dares to use clock stretching, random data corruption occurs ;) Dec 01 08:42:31 zmatt: nah, openbsd won't work on rpi and i really want to use the sensors framework they have Dec 01 08:43:13 no raspbsd ? Dec 01 08:43:41 guess they're too far into debian Dec 01 08:43:47 dmelani: btw, they fixed the i2c hw bug in revision 2.1 Dec 01 08:44:44 veremit: nope, something about hardware documentation or whatever Dec 01 08:45:12 hehehe Dec 01 08:45:51 or lack of ;) Dec 01 08:48:54 yeah, I can complain plenty about TI's documentation, but if I then look at what the RPi people have to work with, suddenly I appreciate it a lot more ;) Dec 01 08:50:15 KotH: btw, what exactly were you referring to when you mentioned "the effort you have to put in to get bare metal stuff running efficiently on a modern application processor" Dec 01 08:50:28 heh ok time to git to work .. bbl :p Dec 01 08:54:02 zmatt: modern processors are complex beast. fully understanding them and designing a software framework that exploits the core features of multi-core and caches is not an easy task Dec 01 08:54:46 zmatt: if you screw that up, you might end up with something that is slower than linux...quiet easily Dec 01 08:54:57 well, the am335x is hardly multi-core (I mean, it is strictly speaking, but that's not what people usually mean with "multi-core") Dec 01 08:55:17 you do need to setup the MMU of course, but that turned out to be a lot easier than I feared Dec 01 08:55:45 not SMP at least.. Dec 01 08:56:39 and if you work with a flat (or mostly flat) memory map you can use section or supersection mappings rather than page tables, which will relieve a lot of pressure on the TLBs Dec 01 08:59:14 a TLB miss gets you a 24-cycle penalty _minimum_, and you got only 32 entries on the data-side and 32 on the instruction side... 32 pages aren't all that much, while 32 supersections probably means your whole memory map fits in TLB Dec 01 09:00:09 zmatt: do you have something that actually needs the added performance from bare metal? Dec 01 09:01:12 no, it basically just started out as a simple way to validate the hardware, and combined with the crappiness of the official kernel it kinda stuck Dec 01 09:02:02 ah..ok Dec 01 09:02:04 plan is still to migrate the baremetal code to the several cortex-M3s the DM814x has and free the cortex-a8 to run linux for non-real-time stuff Dec 01 09:02:49 (although the primary real-time aspect, audio processing, runs on the dsp core) Dec 01 09:03:22 any special reason use use a dm814x? Dec 01 09:03:27 you use* Dec 01 09:03:56 dsp? Dec 01 09:03:58 yeah, the whole C6-Integra line vanished into thin air Dec 01 09:04:26 :-/ Dec 01 09:04:27 and the processor was selected before it became clear TI isn't really interested in supporting it Dec 01 09:04:32 another victim of opamgeddon Dec 01 09:04:36 yep Dec 01 09:05:42 really, I would rather have had a C6A811x on it, based on the limited info I have on that semi-mythical processor Dec 01 09:06:03 the headers I found were dated 2010 though, before we made the processor selection Dec 01 09:06:17 but it seems it never made it to market Dec 01 09:06:31 except maybe as the automotive DRA62x Dec 01 09:06:33 wasnt Ti working on some new C-A8+dsp SoC? Dec 01 09:07:07 arm+dsp is mostly the keystones, but those are... not for casual use Dec 01 09:07:21 yeah Dec 01 09:07:34 but if you need a dsp, it's not casual use either ;) Dec 01 09:08:25 well, we make audio components, not UMTS basestations or whatever the fuck those keystone processors are typically used for :P Dec 01 09:10:43 zmatt: what company is that? Dec 01 09:10:53 (actually, given that the keystones have specific accelerators for "WCDMA/HSPA+, TD-SCDMA, LTE, LTE-A and WiMAX Uplink and Downlink Bit Processing" it's pretty clear what they are intended for :P ) Dec 01 09:12:11 KotH: so C6-integra made perfect sense... a modest ARM but still capable of running a normal OS for "management" tasks, and a DSP for audio processing Dec 01 09:12:39 http://www.ti.com/dsp/docs/dspcontent.tsp?contentId=77427 Dec 01 09:12:41 zmatt: i guess using a dsp at the side is out of quesion for price reasons? Dec 01 09:13:05 KotH: it has SATA!!!! Dec 01 09:13:24 \o/ Dec 01 09:13:38 av500: try clicking the link to the product page Dec 01 09:13:41 ...TI recommends that customers consider DM8148 or DM8168 solutions, which are pin-to-pin and software compatible devices to the C6A816x devices.... Dec 01 09:13:50 yep Dec 01 09:14:03 so Dec 01 09:14:07 same chip then Dec 01 09:14:11 no? Dec 01 09:15:50 C6A was a defeatured DM.. which also means you didn't pay for the video shit you didn't need... but now they've completely focussed on video applications, which also means the support guys barely know about anything else, and the video framework drivers are also the main reason they're stuck with an ancient kernel Dec 01 09:17:22 also, the 811x (which doesn't exist, except there's an EVM for it) replaced some of the video stuff with the pruss/pwmss features from the am335x Dec 01 09:17:29 that I would have loved :D Dec 01 09:23:44 zmatt: yes, I know about the video horrors on DM81x8 Dec 01 09:25:11 like I said in one of those threads, if they're not interested in putting in the effort themselves, then at least publish the documentation so other people can give it a try Dec 01 09:25:32 even that takes work Dec 01 09:26:24 the lack of docs on the crypto accelerators (or SecSS in case of the 81xx) is also annoying Dec 01 09:29:16 well, it's ITAR Dec 01 09:29:22 ITAR ? Dec 01 09:31:46 the usian way of telling you, you belong to the axis of evil Dec 01 09:32:18 the only way they deliver ITAR products to you is with the intend to kill Dec 01 09:32:36 yeah it's the OMG-secretive... apart from the linux drivers they publicly released Dec 01 11:08:53 ppl...i'm having problem using beaglebone black + debian + nrf24 (wireless) + pynrf24 (python lib)...when i set pipes and channel, he return other value... Dec 01 11:09:35 example: setChannel(0x60) return me RF_CH=0x70 Dec 01 11:09:43 can someone help-me? Dec 01 11:12:52 Hii all Dec 01 11:13:17 i read about trustedzone in ARM Dec 01 11:13:30 how to implement it on Beagle bone?? Dec 01 11:14:37 i got something like genode OS which support virtualization Dec 01 11:14:46 How to port it on BBB Dec 01 11:15:35 seriously? 272 onlines and noone can help? Dec 01 11:15:40 :/ Dec 01 11:16:52 :( Dec 01 11:17:23 pedroIvo did you test it on your host system? Dec 01 11:17:32 proably its a wireless driver problem Dec 01 11:17:41 and has nothing todo with the bbb at all Dec 01 11:17:50 pedroIvo: please upgrade your support subscription. The free support only contains the "please wait patiently for answers" level. Dec 01 11:18:25 RahulAN for trustedzone you need to hire developers from arm I guess Dec 01 11:18:32 woglinde, thanks for the answer... :) Dec 01 11:18:54 woglinde, but what do u mean with "test it on your host system"? Dec 01 11:18:57 pedroIvo no problem, but you could easly come this conclusion too Dec 01 11:19:04 woglinde, it is already implemented on BBB but how to test it Dec 01 11:19:07 i am not getting Dec 01 11:19:37 RahulAN impleted in the soc and used by the os/kernel are diffrent things Dec 01 11:19:57 pedroIvo your host system aka. the system where you are chatting from Dec 01 11:20:09 pedroIvo or do you chat from the bbb? Dec 01 11:20:28 woglinde, is there any way to test or debug that?? Dec 01 11:20:57 RahulAN I am not an arm soc dev Dec 01 11:21:04 so I can not tell you Dec 01 11:21:27 woglinde, sorry but i still didn't get it :S ... nrf24 is a wireless board that use bbb GPIOs...how can i test here in my pc? o.O Dec 01 11:21:33 Ohk, is there any software work Dec 01 11:22:31 rahulan btw. a five second google search, revials this http://stackoverflow.com/questions/7955982/arm-trustzone-development Dec 01 11:22:52 pedroIvo ah okay I tought its the usual usb stuff Dec 01 11:23:50 pedroIvo hm first look at the python-code and second look at the kernel driver code Dec 01 11:23:56 woglinde, ahh...no no, that's a RF board to communicate between 2 bbb (or bbb <-> arduino) Dec 01 11:24:27 woglinde, good ideia...kernel driver code... Dec 01 11:24:31 woglinde, thanks mate! Dec 01 11:29:16 woglinde, thats wortht :D Dec 01 11:42:15 a while ago i wrote a driver that bitbangs via Dec 01 11:42:27 echo low > /sys/class/gpio/gpio"+str(pin_id)+"/direction" Dec 01 11:43:05 heh Dec 01 11:43:11 its horribly slow. And i wonder why. Dec 01 11:43:45 is the class/gpio/ interface slow? Or is my program the limiting factor? Dec 01 11:44:18 with slow i mean, i need roughly 3 seconds to update 16chars on a display :D Dec 01 11:54:23 day use the pru Dec 01 11:55:06 hey woglinde Dec 01 11:58:05 day -> https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCYQFjAA&url=http%3A%2F%2Fevents.linuxfoundation.org%2Fsites%2Fevents%2Ffiles%2Fslides%2FEnhancing%2520RT%2520Capabilities%2520with%2520the%2520PRU%2520final.pdf&ei=v1d8VK_QHoT9ygOMrIDYBQ&usg=AFQjCNFAX6cM6KYnlY0AzG5gv91UXmIvww Dec 01 11:58:10 args Dec 01 11:58:16 damn google link Dec 01 11:58:18 hi koth Dec 01 11:59:15 thats better http://events.linuxfoundation.org/sites/events/files/slides/Enhancing%20RT%20Capabilities%20with%20the%20PRU%20final.pdf Dec 01 12:03:42 woglinde: my problem isnt necessarily the hardware. Its more the fat stack of software between me and the hardware :3 Dec 01 12:04:18 im just wondering, why is the class/gpio interface slow? Dec 01 12:07:15 day I do not know Dec 01 12:08:35 day: because it goes trough a lot of stuff in the kernel Dec 01 12:08:39 woglinde: hm at least your slides verify that its the interface and not my program Dec 01 12:08:50 day: several hundred if not thousand lines of code are executed Dec 01 12:08:51 they are not my slides Dec 01 12:08:57 but yes I attended the talk Dec 01 12:09:04 you posted them Dec 01 12:09:21 day: gpio toggling from userspace is damn slow. if you can reach 1MHz, you are already quite good Dec 01 12:09:36 eww Dec 01 12:10:01 it's a code path problem Dec 01 12:10:11 that means if i do the same thing from kernelspace it would be much faster? Dec 01 12:10:13 if you need faster toggling, write a kernel driver or use the PRU Dec 01 12:11:42 http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/ Dec 01 12:11:52 it's for the rpi, but 90% of it applies to the bbb as well Dec 01 12:16:59 day: oh.. just in case: do not even dare thinking to write to /dev/mem Dec 01 12:17:13 day: that way leads to desctruction Dec 01 12:17:18 KotH: :3 Dec 01 12:18:01 i will wreck it anyways Dec 01 12:18:09 :( Dec 01 12:20:03 if you do not want /dev/mem try UIO.. Dec 01 12:23:52 Humpelstilzchen: sooo /dev/mem is possible? Dec 01 12:26:02 either way. i need to get a better understanding of (linux)drivers in general before i attempt to build one that runs in kernelspace Dec 01 12:27:07 read ldd3 Dec 01 12:27:24 it contains (almost) everything you need to know Dec 01 12:27:58 hm i hope its not too complicated :/ Dec 01 12:28:34 i'm a master of 'half knowledge' :X Dec 01 12:30:28 it's not Dec 01 12:30:37 and dont worry, you wont beat me on half knoweldge ;) Dec 01 12:37:30 out of curiousity which service connects the driver modules to the hardware? When i plug in a usb device for example. Dec 01 12:38:04 i guess the first thing that happens, is a universal usb driver will grap the basic infos Dec 01 12:39:27 does this driver then act as a new device (which presents basic infos for another service, which then connects the correct driver to it)? Dec 01 12:39:31 it's a multi-level process Dec 01 12:39:37 read up on how udev works Dec 01 12:40:08 the list grows :P Dec 01 12:40:19 well, you are dealing with a complex topic :) Dec 01 12:40:32 day: is it a day job or hobby? Dec 01 12:40:36 reminds me of xkcds *learning a complex topic* Dec 01 12:40:40 hobby Dec 01 12:41:09 which xkcd is that? Dec 01 12:41:20 :( no idea which number Dec 01 12:42:09 it goes like this. Reads Book A. Book A requires knowledge of Book B and C. B and C require D E F G .... etc :P Dec 01 12:47:19 nobody said an operating systems is so simple like using a washing machine Dec 01 12:48:25 I'm just looking for the eco-timesaver mode :X Dec 01 12:49:44 day: i'm not sure that was an xkcd Dec 01 12:49:57 day: at least i neither rember one like that nor can i find it Dec 01 13:49:39 KotH: im very sure that it is one. But my google fu isn't good enough to compensate for the lynx malus :p Dec 01 17:14:58 BBB/linux interrupt latency: http://dan.drown.org/bbb/latest/interrupt-latency.png Dec 01 17:15:18 time between a GPS PPS event captured by the timer and the interrupt handler running Dec 01 17:17:03 ddrown: would you mind sending a mail with that info to the time-nuts mailinglist? Dec 01 17:17:10 ddrown: i'm sure quite a few people would want to know that Dec 01 17:17:27 KotH: yeah, I was planning on including it with my timer driver Dec 01 17:18:01 ddrown: also, what's this floor? Dec 01 17:18:09 ddrown: it looks weird Dec 01 17:18:18 the 6us floor? Dec 01 17:19:15 hmm..wait a sec Dec 01 17:19:21 what does this graph actually show? Dec 01 17:19:34 time of day vs latency? Dec 01 17:19:44 yeah, it's over multiple days Dec 01 17:19:50 or latency vs histogram? Dec 01 17:19:58 ah.. Dec 01 17:20:03 7 days worth Dec 01 17:20:10 maybe you should switch this to a histogram Dec 01 17:20:17 gnuplot can do that out of the box, iirc Dec 01 17:20:18 that makes sense Dec 01 17:20:51 do you know the u-blox lea6-t timing datasheet? Dec 01 17:21:04 nope Dec 01 17:21:21 http://www.u-blox.com/images/downloads/Product_Docs/Timing_AppNote_%28GPS.G6-X-11007%29.pdf Dec 01 17:21:45 have a look at the two histograms on page 6 Dec 01 17:22:00 that's a quite good way how to display this kind of information Dec 01 17:23:13 ah, cumulative probability included, nice Dec 01 17:23:24 and I'm guessing the purple are 25%/75% Dec 01 17:23:42 nope, they are 1\sigma Dec 01 17:23:51 ah Dec 01 17:25:10 also, that's a pretty impressive compensation they've got there Dec 01 17:26:11 you mean the sawtooth? Dec 01 17:26:15 that's not really impressive Dec 01 17:26:24 yeah, the sawtooth Dec 01 17:26:29 it just shows how big the sawtooth effect is :) Dec 01 17:26:50 and it's about the size you'd exepct from a 48MHz clock Dec 01 17:27:26 anyways.. gtg home... Dec 01 17:27:30 bbl Dec 01 19:09:57 Can anyone from BB.org -- or otherwise -- comment on the status of the Userspace-Arduino project? Is is still being supported as a project for the BBB? If not, why not? Thanks. Dec 01 19:15:11 I would say the best way to find that out is to talk with the project maintainers for the project. Dec 01 19:17:18 I actually have spoken with the original creators of it, which was a GSCOC project. But it's a bit unclear to me why bb.org is no longer supporting it since it had/has much promise on expanding the BBB to the Arduino user base. Dec 01 19:18:11 GSOC project, that is Dec 01 19:18:54 WHat support do you expect to see that is lacking?> Dec 01 19:21:10 Well, I see no more dev or projects around it for some time now. It's not even touched now by BBB users, new or old. It seems like it's gotten the cold shoulder after much early promise Dec 01 19:21:33 The cynic in me wants to just say "Welcome to GSOC" Dec 01 19:22:11 The realist in me wonders whether other things provide similar function; was the project a solution looking for a problem? Dec 01 19:22:26 well, yeah. But still... it had some good demos/examples. Dec 01 19:22:43 The FOSS advocate in me suggests that you yourself take up the mantle of the project and get it going again. Dec 01 19:23:03 solution in search of a problem: paucity of capes v. wealth of shields Dec 01 19:23:18 Yeah, but shields suck. Dec 01 19:25:10 That's a pretty broad statement. And FWIW, I've had some capes that certainly sucked Dec 01 19:26:13 Every cape I have used worked perfectly the first time. Dec 01 19:26:32 And capes have a standard interface and mechanical design. Dec 01 19:26:59 Shields...not so much, and the average quality leaves much to be desired. Dec 01 19:41:29 KotH: new graph with histogram/CDF - http://dan.drown.org/bbb/latest/interrupt-latency.png Dec 01 19:42:02 ddrown: +1 Dec 01 19:42:10 ddrown: btw: how do you measure it? Dec 01 19:42:17 not sure what other stats would be useful, stddev or other percentiles Dec 01 19:42:38 hmm.. Dec 01 19:42:40 KotH: I'm using the timer hardware, it captures the counter at PPS and I see how much time has passed in the interrupt handler Dec 01 19:43:08 it doesnt look like a normal distribution Dec 01 19:43:19 so stdev would probably not be very usefull Dec 01 19:43:40 min/max, 10% and 25% probably Dec 01 19:43:44 and mean Dec 01 19:44:01 ah... Dec 01 19:44:08 ok, that explains it Dec 01 19:44:22 but then you have a jitter that is much below a clock cycle Dec 01 19:44:50 ie, for the GPSDO the interrupt latency is not of importance Dec 01 19:45:05 well, the majority of my jitter is from my local oscillator/temperature differences Dec 01 19:45:55 yes Dec 01 19:46:07 the oscillator in SoC is not optimized for low jitter Dec 01 19:47:18 do you have an idea what your measurement jitter is? Dec 01 19:47:51 ie trigger edge to counter value Dec 01 19:48:11 ah, like the latching time variance? Dec 01 19:48:22 I have no idea Dec 01 19:49:21 I assume it's around a single tick of 24mhz, but that's not something I've measured Dec 01 19:50:22 there's chrony's consideration of the local clock's stddev - http://dan.drown.org/bbb/latest/local-clock-stddev.png Dec 01 19:51:11 median of that is 51ns Dec 01 19:51:13 hmm.. so your stdev should be around 20ns Dec 01 19:52:12 jkridner: chnyc is curious as to the "lack of support" for the Userspace-Arduino project by CircuitCo/beagleboard.org. Dec 01 19:52:49 ddrown: hmm.. a bit higher than i expected Dec 01 19:53:02 hi chnyc.... I think hearing more from users would help a lot... Dec 01 19:53:09 ddrown: also, the distribution seems quite skewed Dec 01 19:53:18 mostly, users don't bring it up a lot, so not much gets updated. Dec 01 19:53:25 KotH: that includes temperature noise, but I agree Dec 01 19:53:47 KotH: the interrupt latency distribution? Dec 01 19:54:22 nope, http://dan.drown.org/bbb/latest/local-clock-stddev.png Dec 01 19:54:34 jkridner: gotcha. Just seemed like a promising project Dec 01 19:54:45 KotH: ah Dec 01 19:54:54 chnyc: got suggested updates/fixes for it? Dec 01 19:55:41 not yet. Exploring how/if to use an Adafruit amp board that typically uses Arduino sketches Dec 01 19:55:55 ddrown: actually it's much more skewed than i'd expect it to be Dec 01 19:55:59 KotH: I modified the chrony settings on day 2 at 14:17 to tell it to accept clock changes faster (modified minsamples). You can see the bottom of the stddev dropping at that point Dec 01 19:56:27 ddrown: could it be that that the time is limited to 0 somehow? Dec 01 19:56:50 ddrown: given my understanding of the environment, i would expect negative deviations as well Dec 01 19:57:14 are you asking if the standard deviation could go to 0? Dec 01 19:57:20 or below it? Dec 01 19:57:35 or are you expecting an offset graph? Dec 01 19:57:55 offset looks like this: http://dan.drown.org/bbb/latest/percentiles-offset.png Dec 01 19:58:12 ah! Dec 01 19:58:15 that's more like it :) Dec 01 19:59:18 the median of the offsets is -2ns Dec 01 19:59:21 hmm.. sigma should be around 130-150ns then... Dec 01 20:00:08 stddev of all samples is 143ns Dec 01 20:01:22 that doesn't sound too shaby for a BBB Dec 01 20:02:20 using the pps-gpio module, stddev of all offsets was 244ns Dec 01 20:02:45 huh? really? Dec 01 20:02:47 How much of that would be due to the clock, and how much due to the timer capture logic? As in, how much improvement could be expected from connecting a better clock to tckin? Dec 01 20:02:54 i would have expected it to go into the us range Dec 01 20:03:31 Peanut: good question. guestimating from what i know, i'd say most jitter comes from the PLL+VCO in the SoC Dec 01 20:03:43 Peanut: these things are not really stable Dec 01 20:03:47 Because that's definitely what I'll be trying next, now that I've got chrony running. Dec 01 20:04:01 Peanut: I'd love to know the answer to your question :) Dec 01 20:04:02 Peanut: the next thing is probably the reference oscillator on the board (ie the quartz crytsal) Dec 01 20:04:33 KotH: I'd rather leave that quartz on, and simply provide 10MHz (or 24MHz) via tckin. Dec 01 20:04:49 Peanut: also, i guestimate that the 24MHz of the capture unit leads to an stdev of about 20ns Dec 01 20:05:21 here's a local clock offset graph for a pps-gpio run: http://dan.drown.org/bbb/run6/percentiles-offset.png Dec 01 20:06:11 ddrown: you should really do a write up of all this and post it to time-nuts Dec 01 20:06:15 ddrown: they will love it :) Dec 01 20:06:33 KotH: yeah, I plan to :) Dec 01 20:06:49 Hehe, I just re-subscribed too, as I got repeatedly kicked off the list in the past due to their bounce-issues. Dec 01 20:07:45 yes Dec 01 20:07:52 there were issues with overjealous spam filters Dec 01 20:08:08 (ie breaking of mail standards by freemailers) Dec 01 20:08:30 it should work now[tm] Dec 01 20:08:53 ok.. time to get some work done.. cul Dec 01 20:09:56 this pruss everyone is all excited about, can it be used for INPUT gpios, or only for output? Dec 01 20:11:04 The PRU can do both input and output, yes. Dec 01 20:12:08 kenrestivo: http://www.element14.com/community/community/designcenter/single-board-computers/next-gen_beaglebone//blog/2013/08/04/bbb--high-speed-data-acquisition-and-web-based-ui Dec 01 20:13:16 ooh.... very cool... thanks Dec 01 20:37:06 ddrown: http://loopy.jive.nl/~boven/ppstest-chrony.png Dec 01 20:37:39 Peanut: pretty good Dec 01 20:37:59 Yeah.. for a BBB at home and a GPS antenna in the window sill, not bad at all. Dec 01 20:39:09 What kind of timeconstant does the chrony PLL use? Dec 01 20:40:00 I think that depends on your "poll" setting Dec 01 20:40:11 That's currently 16 seconds. Dec 01 20:40:45 check the "span" column in "chronyc sourcestats" Dec 01 20:40:48 So all these outliers upwards would be interrupts being late assigning a timestamp to the pps-gpio? Dec 01 20:40:59 that seems likely Dec 01 20:41:11 span is 335 for the PPS, 80 for the NMEA. Dec 01 20:41:44 span - Length of measurement set (in seconds when not labeled) Dec 01 20:42:09 Oh, one of the things I like about chrony: most things have units! Dec 01 20:42:23 heh yeah, it exports a lot of its internal working state too Dec 01 20:51:10 what clock are you testing? Dec 01 20:52:11 oh, looks like the RTC Dec 01 20:52:50 kenrestivo: Peanut and I have GPS modules with PPS signals connected to our BBB's. The offset is a measurement between the local clock and the PPS signal Dec 01 20:53:35 The Linux kernel uses a 24mhz timer as its running local clock source Dec 01 20:53:48 on the BBB hardware Dec 01 20:54:19 cool, thanks Dec 01 20:56:37 Hi why are there no BeagleXM boards in any of the stores????? Dec 01 20:57:00 WHich stores where? Dec 01 20:57:35 Digi-Key, Elemnt 14, RS Components, ect. Dec 01 20:58:25 Probably because it is an ancient board and it may not be under production anymore? Dec 01 20:58:58 Not that ancient is it? what replaces it? Dec 01 20:59:18 Beagle X15 probably replaces Dec 01 20:59:41 Guest65000: The xM is several years old at this point. Dec 01 21:00:09 Ok I understand Dec 01 21:00:37 Note that I do not speak for CircuitCo; most people here are not in any way affiliated with them. Dec 01 21:00:46 jkridner may be able to shed more light on the matter. Dec 01 21:01:15 I do not think the X15 nexists for sale yet. Dec 01 21:01:23 I appreciate that, we are a research lab in a university and have used the XM before Dec 01 21:01:27 Is Pandaboard still around? Dec 01 21:01:34 Panda is dead Dec 01 21:01:49 How about Wandaboard? Dec 01 21:01:50 I like Pandas Dec 01 21:02:26 Guest65000: taste like chicken Dec 01 21:02:56 Oh that was really fowl Dec 01 21:03:00 Guest65000: Is what you are doing more CPU-intensive than the BeagleBone Black can offer? Dec 01 21:03:39 CPU? Hummingboard has quad Dec 01 21:04:00 Right, there was the one I forgot about. Dec 01 21:04:35 Since we have no idea what Guest65000 is looking for out of a board, we could just keep rattling off names of ARM dev boards. Dec 01 21:04:55 I mean, there is the entire series of ODROID boards from HardKernel. Dec 01 21:06:55 Yes its true I dont know I'm the procurment gal not the computing researcher who need the board so rattle on your suggestion are most helpful. Dec 01 21:10:11 Guest65000: It would be more useful for us (and you, as procurement) to know what the board needs to do. Dec 01 21:10:39 You are absolutly right! Dec 01 21:11:00 So I will go to the researcher and ask thank you all! Dec 01 21:11:04 No problem. **** BEGIN LOGGING AT Mon Dec 01 21:20:39 2014 Dec 01 21:48:02 what'd you use to write the buildroot? it probably overwrote your uboot too Dec 01 21:50:15 wow that odroid looks tasty. quad core, 3 usb's... Dec 01 21:50:53 same price as BBB, four times the ram... Dec 01 21:53:01 Hardly any GPIO. Dec 01 21:53:11 Little to no community or support. Dec 01 21:53:19 Hard to get one's hands on, apparently. Dec 01 21:53:42 But, made for a different purpose. Dec 01 22:06:16 kenrestivo: I copied uboot, kernel, etc to one partition on an SD card, and dd for the filesystem to the other partition. Then I stuck that in the BBB, held down the button while applying power Dec 01 23:54:29 Does uboot get flashed onto the BBB somewhere, or is it read from eMMC or the SD card at boot? Dec 01 23:57:46 JetForMe: check /boot folder Dec 01 23:58:07 Yeah, I have one there, I'm just wondering if some part of the process ends up flashing it to some other part of the BBB Dec 01 23:58:23 u-boot and MLO are on a fat32 partition Dec 01 23:58:29 I've worked with other embedded boards where uboot is written to a separate flash IC Dec 01 23:58:35 OK Dec 01 23:58:47 here uboot and mlo and on a fat32 partition on the eMMC or usd Dec 01 23:58:50 And u-boot executes directly from the fat32 partition? Dec 01 23:59:03 (loaded from there each boot?) Dec 01 23:59:06 yes Dec 01 23:59:32 Thank you. I'm trying to figure out why I used to see "2013" in the u-boot startup, and now I see 2014. Dec 01 23:59:50 if you reflashed your bbb u-boot got a new version also Dec 01 23:59:50 I didn't re-flash my eMMC, but it seems like it changed. Maybe I'm just remembering wrong Dec 02 00:00:16 maybe, u-boot stays with the eMMC/uSD nowhere else Dec 02 00:00:57 Okay, thank you! Dec 02 00:01:29 np Dec 02 02:31:38 hi, a newbee from Slovenia Dec 02 02:32:06 anyone here able to hlep with capturng HD video from c920? Dec 02 02:34:19 no one here? Dec 02 02:36:26 :( Dec 02 02:36:36 all asleep? Dec 02 02:53:27 anyone here? Dec 02 02:56:11 gre2gor: https://www.youtube.com/watch?v=8QouvYMfmQo Dec 02 02:58:11 I watched over and over again Dec 02 02:58:32 but when I try to build I always get some errors Dec 02 02:58:43 I am totally lost **** ENDING LOGGING AT Tue Dec 02 02:59:58 2014