**** BEGIN LOGGING AT Mon Feb 05 03:00:02 2018 Feb 05 04:34:02 window 10 to driver install falled Feb 05 04:41:44 if you're using a recent enough image, you don't need any driver for windows 10 Feb 05 11:07:35 Hi, Feb 05 11:08:05 Are the BeagleBone Boards completely royalty free? Feb 05 11:08:46 Can I make products using beagle boards? Feb 05 11:09:12 commercial products Feb 05 11:10:02 Bose: you can buy beaglebones and put them into your whatevers. AFAIK you are not allowed to use the beagle names as advertising for your stuff, unless explicitly permitted by the trademark holders. Feb 05 12:27:55 that’s pretty accurate Feb 05 12:28:35 dang, that was totally not my intention. can i do $POLITICALTHING and now claim the exact opposite? :-P Feb 05 12:30:20 i won’t tell... but all your words will be recorded. all the better for denying them later. Feb 05 12:30:51 i have alternative facts here. Feb 05 12:31:11 *sigh* nevermind, sorry for digressing. Feb 05 12:32:03 :-) Feb 05 13:17:37 jkridner: just about to listen to your interview on TheAmpHour ;) Feb 05 13:18:56 thinkfat: :-) Feb 05 14:00:35 jkridner[m]: the host seriously has been living under a pile of micro controllers for all his life :-D Feb 05 14:02:45 Chris is an analog guy. Feb 05 14:03:12 he needs to attend e-ale.org! Feb 05 14:05:25 (shameless plug) Feb 05 14:10:33 jkridner: the jtag on the pocket beagle, is there a connector that's just not populated or do I need to wire them individually? Feb 05 14:11:45 looks like wires to me Feb 05 14:12:30 http://files.linuxgizmos.com/bboard_pocketbeagle_back.jpg Feb 05 14:41:18 yeah, there’s no connector. it’ll be a PITA, but possible. Feb 05 14:42:10 just couldn’t find a viable footprint Feb 05 14:42:26 everything took too much space. Feb 05 15:03:16 hi al;l Feb 05 15:14:33 Does anyone has an answer for this question? Or at least a direction on where to search further? Thanks https://groups.google.com/forum/embed/?place=forum/beagleboard&parenturl=https%3A%2F%2Fbeagleboard.org%2Fdiscuss#!category-topic/beagleboard/support/advanced/beaglebone-black/boot/angstrom/eMEPdEuAQjE Feb 05 15:17:04 wow, do you really need to hack that old Angstrom image? Feb 05 15:19:29 this step makes no sense to me: Feb 05 15:19:30 tail -c+65 < initramfs.bin.SD > Angstrom-xxxxxxxx_m-eglibc-ipk-v2013.06-beaglebone.rootfs.cpio.gz Feb 05 15:19:38 Yes. Not sure if -9 for gzip is preventing boot. Or perhaps -T ramdisk need to be added to mkimage. Feb 05 15:19:41 what are you trying to accomplish there? Feb 05 15:20:13 the tail is to skip the first 64 bytes Feb 05 15:20:38 skipping is needed in order to extracht the image Feb 05 15:21:16 all sources mention this, also in other ways, e.g. with dd command. result is identical Feb 05 15:21:31 does mkimage create a cpio.gz? Feb 05 15:24:43 no, that is the input, -d refers to 'data to use' Feb 05 16:23:51 jkridner[m]: who else might I ask about this issue? Feb 05 17:36:50 Are there any figures for jitter of i2c reads on the beaglebone? Feb 05 17:37:09 is it totally dependent on system load or is there any kind of guarantee? Feb 05 17:37:37 for example if I want to read a sensor every 10ms Feb 05 17:48:00 Linux is not a real time OS Feb 05 17:57:59 yes, but say I wanted to do a read every second, with a low load average, I would think I could get to around 10ms of the desired time Feb 05 17:58:21 thought maybe there would be some figures but couldn't find any Feb 05 17:58:28 I'm just setting a test up now to find out Feb 05 17:58:46 but will probably get stuck figuring out how to turn the i2c on ;) Feb 05 18:58:47 ok, my test is very simple: Feb 05 18:58:57 while true; do i2cget -y 2 0x68 0x87 2> /dev/null; done Feb 05 18:59:06 which is getting about 60 reads per second Feb 05 18:59:24 I'm going to dump the captured data (with sigrok) and then plot the variance Feb 05 18:59:32 will post back here when I'm done Feb 05 19:25:18 > Feb 05 19:26:45 what kind of sensor is it? Feb 05 19:40:36 it will be an accellerometer Feb 05 19:41:00 but I don't have it yet, so I'm just capturing the i2c writes Feb 05 19:57:32 mattvenn_: that test, while simple, is not really a good indication of what's posssible Feb 05 20:02:19 also, only 60 reads per second? jesus I wonder if your i2c device is that horribly slow of whether it's due to all of the overhead of i2cget (incl spawning it) Feb 05 20:06:37 zmatt: nothing connected yet, so jsut the overhead of i2cget Feb 05 20:06:48 lol Feb 05 20:07:02 yes I need to do this again with just a simple c program Feb 05 20:07:09 but interesting for me anyway Feb 05 20:08:25 doesn't a NAK on the bus result in an entry being logged in the kernel log? i.e. aren't you generating a big stream of data into logfiles right now? Feb 05 20:08:43 maybe Feb 05 20:09:18 don't see anything in syslog messages or kern.log Feb 05 20:09:30 ok maybe it doesn't Feb 05 20:09:57 greping for i2c shows a few timeouts but looks fairly infrequently Feb 05 20:10:01 good idea though Feb 05 20:10:23 ok here's the result of my crappy test: https://imagebin.ca/v/3qh7a1iKKRcf Feb 05 20:10:30 as you point out though, a lot of overhead. Feb 05 20:10:35 but interesteing to see the variance Feb 05 20:11:04 I was sporadically running this: dd if=/dev/zero of=/dev/null Feb 05 20:11:09 and capture time was 10 seconds Feb 05 20:11:14 variance should be a lot better though if your process uses an actual timer and is given real-time scheduling Feb 05 20:11:40 I'll give it a go for sure Feb 05 20:12:05 when you say timer, can that be a hardware timer from the chip or would it be a linux kernel thing Feb 05 20:12:44 why not just use the FIFO in the accel Feb 05 20:13:08 if it has one then yeah that's the more obvious thing to do Feb 05 20:13:17 if you are doing it in userland, you are fighting the scheduler in userland Feb 05 20:13:41 if anyone is interested in the sigrok-cli or plotting code it's here: https://gist.github.com/mattvenn/17b6b66f5a233a5f271b007a4e746d13 Feb 05 20:13:42 plus you got the kernel side of the scheduler (driver runs, I2C driver runs, plus you get bus uncertainities with the DMA to the I2C block Feb 05 20:13:54 that's in addition to jitter from I2C itself Feb 05 20:14:16 ds2: I'm basically trying to work out whether I can get away with reading the accell in userland or if I have to do it on the fpga I've got in the system Feb 05 20:14:16 i2c dma? I very much doubt it uses dma? Feb 05 20:14:25 especially for single-byte reads Feb 05 20:14:58 the accell data needs to be synced to the adc data from the fpga, but I can have a bit of slop Feb 05 20:15:07 zmatt: some do... forgot which one...been a few years since I looked into this Feb 05 20:15:37 mattvenn_: if you need accurate timing, use the FIFO Feb 05 20:15:46 ds2: re fifo in the i2c, how would that help me with getting accurately timed samples? Feb 05 20:15:47 which accel is this anyways? not all of them put out a sync signal Feb 05 20:16:11 mattvenn_: you program the accel to sample at a fix rate to the fifo; on interrupt, empty out fifo Feb 05 20:16:28 not all accels have fifos but that's a parts selection issue Feb 05 20:16:41 http://es.farnell.com/nxp/mma8452qt Feb 05 20:16:56 ok interesting Feb 05 20:17:00 freescale accels are newer then when I was looking at them Feb 05 20:17:18 the one I posted has some cool dsp to detect taps and such Feb 05 20:17:26 a lot of accels have tap detect Feb 05 20:17:41 the more expensive part does have a fifo Feb 05 20:18:51 yeah, I think the part I was using before was quite old. Feb 05 20:18:53 the 51 has a fifo, the 52 doesn't :( Feb 05 20:19:24 even if you run it from the FPGA (or PRU), you stil won't have a guarantee sync with the accel Feb 05 20:19:50 [MEMS] -- [analog processing]---[ADC]---[Digital processing] --- --- Feb 05 20:20:05 the I2C is not sync'ed with the MEMS side Feb 05 20:22:19 right, but now the difference in time between the last measurement and the read can be a lot smaller Feb 05 20:22:43 for many apps, that is not a sufficient condition Feb 05 20:22:55 if you want low latency, use an analog accel Feb 05 20:23:13 right, thanks that is so interesting Feb 05 20:23:25 of course, use a ADC on a parallel bus Feb 05 20:23:30 otherwise, you are back to where you started Feb 05 20:23:47 jitter can be a major PITA Feb 05 20:23:47 I just hadn't taken the i2c latenncy into consideration on the accell side at all Feb 05 20:24:55 got any idea of what order of magnitude it might be in? or how to find out? I just searched the datasheet for jitter Feb 05 20:25:19 depends on device Feb 05 20:25:34 and it can vary with temperature Feb 05 20:25:35 although: say the accell is setup to sample at 500hz, and use the fifo, with an interrupt to read the fifo Feb 05 20:25:59 I suppose it all depends on how much jitter the system can tolerate Feb 05 20:26:16 are we talking nanoseconds or microseconds? Feb 05 20:26:32 depends on the device Feb 05 20:27:18 alright, well thanks for the help Feb 05 20:27:25 always learn something new on this channel Feb 05 20:27:46 I gotta go and eat! Feb 05 20:27:48 =) Feb 05 20:27:58 hmmm eat... must be west coast :D Feb 05 20:28:33 Europe. Feb 05 20:28:38 spain, we eat late here! Feb 05 20:28:42 dinner Feb 05 20:28:44 cheers, Feb 05 20:28:47 not lunch...later Feb 06 00:06:20 hi, my project is to control a motor with at least 30 sensors like temperature, air flow, is the beagleboard x15 is fine for my project? Feb 06 00:06:53 i will need to control some lighs, heater, resistances etc Feb 06 00:09:17 all sensors are industrials version, so i will need to use analog/digit convert etc... **** ENDING LOGGING AT Tue Feb 06 03:00:04 2018