cigwindow 10 to driver install falled
zmattif you're using a recent enough image, you don't need any driver for windows 10
BoseAre the BeagleBone Boards completely royalty free?
BoseCan I make products using beagle boards?
Bosecommercial products
LetoThe2ndBose: 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.
jkridner[m]that’s pretty accurate
LetoThe2nddang, that was totally not my intention. can i do $POLITICALTHING and now claim the exact opposite? :-P
jkridner[m]i won’t tell... but all your words will be recorded. all the better for denying them later.
LetoThe2ndi have alternative facts here.
LetoThe2nd*sigh* nevermind, sorry for digressing.
thinkfatjkridner: just about to listen to your interview on TheAmpHour ;)
jkridner[m]thinkfat: :-)
thinkfatjkridner[m]: the host seriously has been living under a pile of micro controllers for all his life :-D
jkridner[m]Chris is an analog guy.
jkridner[m]he needs to attend!
thinkfat(shameless plug)
thinkfatjkridner: the jtag on the pocket beagle, is there a connector that's just not populated or do I need to wire them individually?
zmattlooks like wires to me
jkridner[m]yeah, there’s no connector. it’ll be a PITA, but possible.
jkridner[m]just couldn’t find a viable footprint
jkridner[m]everything took too much space.
Panderhi al;l
PanderDoes anyone has an answer for this question? Or at least a direction on where to search further? Thanks!category-topic/beagleboard/support/advanced/beaglebone-black/boot/angstrom/eMEPdEuAQjE
jkridner[m]wow, do you really need to hack that old Angstrom image?
jkridner[m]this step makes no sense to me:
jkridner[m]tail -c+65 < initramfs.bin.SD > Angstrom-xxxxxxxx_m-eglibc-ipk-v2013.06-beaglebone.rootfs.cpio.gz
PanderYes. Not sure if -9 for gzip is preventing boot. Or perhaps -T ramdisk need to be added to mkimage.
jkridner[m]what are you trying to accomplish there?
Panderthe tail is to skip the first 64 bytes
Panderskipping is needed in order to extracht the image
Panderall sources mention this, also in other ways, e.g. with dd command. result is identical
jkridner[m]does mkimage create a cpio.gz?
Panderno, that is the input, -d refers to 'data to use'
Panderjkridner[m]: who else might I ask about this issue?
mattvenn_Are there any figures for jitter of i2c reads on the beaglebone?
mattvenn_is it totally dependent on system load or is there any kind of guarantee?
mattvenn_for example if I want to read a sensor every 10ms
ds2Linux is not a real time OS
mattvenn_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
mattvenn_thought maybe there would be some figures but couldn't find any
mattvenn_I'm just setting a test up now to find out
mattvenn_but will probably get stuck figuring out how to turn the i2c on ;)
mattvenn_ok, my test is very simple:
mattvenn_while true; do i2cget -y 2 0x68 0x87 2> /dev/null; done
mattvenn_which is getting about 60 reads per second
mattvenn_I'm going to dump the captured data (with sigrok) and then plot the variance
mattvenn_will post back here when I'm done
ds2what kind of sensor is it?
mattvenn_it will be an accellerometer
mattvenn_but I don't have it yet, so I'm just capturing the i2c writes
zmattmattvenn_: that test, while simple, is not really a good indication of what's posssible
zmattalso, 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)
mattvenn_zmatt: nothing connected yet, so jsut the overhead of i2cget
mattvenn_yes I need to do this again with just a simple c program
mattvenn_but interesting for me anyway
zmattdoesn'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?
mattvenn_don't see anything in syslog messages or kern.log
zmattok maybe it doesn't
mattvenn_greping for i2c shows a few timeouts but looks fairly infrequently
mattvenn_good idea though
mattvenn_ok here's the result of my crappy test:
mattvenn_as you point out though, a lot of overhead.
mattvenn_but interesteing to see the variance
mattvenn_I was sporadically running this: dd if=/dev/zero of=/dev/null
mattvenn_and capture time was 10 seconds
zmattvariance should be a lot better though if your process uses an actual timer and is given real-time scheduling
mattvenn_I'll give it a go for sure
mattvenn_when you say timer, can that be a hardware timer from the chip or would it be a linux kernel thing
ds2why not just use the FIFO in the accel
zmattif it has one then yeah that's the more obvious thing to do
ds2if you are doing it in userland, you are fighting the scheduler in userland
mattvenn_if anyone is interested in the sigrok-cli or plotting code it's here:
ds2plus 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
ds2that's in addition to jitter from I2C itself
mattvenn_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
zmatti2c dma? I very much doubt it uses dma?
zmattespecially for single-byte reads
mattvenn_the accell data needs to be synced to the adc data from the fpga, but I can have a bit of slop
ds2zmatt: some do... forgot which one...been a few years since I looked into this
ds2mattvenn_: if you need accurate timing, use the FIFO
mattvenn_ds2: re fifo in the i2c, how would that help me with getting accurately timed samples?
ds2which accel is this anyways? not all of them put out a sync signal
ds2mattvenn_: you program the accel to sample at a fix rate to the fifo; on interrupt, empty out fifo
ds2not all accels have fifos but that's a parts selection issue
mattvenn_ok interesting
ds2freescale accels are newer then when I was looking at them
mattvenn_the one I posted has some cool dsp to detect taps and such
ds2a lot of accels have tap detect
mattvenn_the more expensive part does have a fifo
mattvenn_yeah, I think the part I was using before was quite old.
ds2the 51 has a fifo, the 52 doesn't :(
ds2even if you run it from the FPGA (or PRU), you stil won't have a guarantee sync with the accel
ds2[MEMS] -- [analog processing]---[ADC]---[Digital processing] --- <I2C>---
ds2the I2C is not sync'ed with the MEMS side
mattvenn_right, but now the difference in time between the last measurement and the read can be a lot smaller
ds2for many apps, that is not a sufficient condition
ds2if you want low latency, use an analog accel
mattvenn_right, thanks that is so interesting
ds2of course, use a ADC on a parallel bus
ds2otherwise, you are back to where you started
mattvenn_I just hadn't taken the i2c latenncy into consideration on the accell side at all
ds2jitter can be a major PITA
mattvenn_got any idea of what order of magnitude it might be in? or how to find out? I just searched the datasheet for jitter
ds2depends on device
ds2and it can vary with temperature
mattvenn_although: say the accell is setup to sample at 500hz, and use the fifo, with an interrupt to read the fifo
mattvenn_I suppose it all depends on how much jitter the system can tolerate
mattvenn_are we talking nanoseconds or microseconds?
ds2depends on the device
mattvenn_alright, well thanks for the help
mattvenn_always learn something new on this channel
mattvenn_I gotta go and eat!
ds2hmmm eat... must be west coast :D
mattvenn_spain, we eat late here!
ds2not lunch...later