tag:blogger.com,1999:blog-36474085218033975152024-03-08T06:15:41.357-08:00CPcphttp://www.blogger.com/profile/15414601070491994061noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-3647408521803397515.post-76150021105012845922011-09-03T04:06:00.000-07:002011-09-03T04:06:58.278-07:00Getting the Point Grey Firefly MV camera to work with OS XSetting up the Point Grey Firefly MV camera working with OS X is really straightforward.<br />
<br />
There are multiple Firefly MV models. If you have the model with the 1394 interface, you just need libdc1394. If you have the model with the USB 2.0 interface, you need libdc1394 and libusb. (Interestingly, the USB firefly uses 1394-over-USB in some unholy mixing of standards. But anyway, it works.)<br />
<br />
Use MacPorts to install libusb and libdc1394<br />
<br />
Download the libdc1394 source (from <a href="http://sourceforge.net/projects/libdc1394/">here</a>).<br />
<br />
Run configure in the unpacked libdc1394 directory. It's crucial that your output looks like this:<br />
<br />
<div class="p1"><br />
</div><div class="p1"><span style="font-family: 'Courier New', Courier, monospace;">Configuration (libdc1394):</span></div><div class="p2"><span style="font-family: 'Courier New', Courier, monospace;"><br />
</span></div><div class="p1"><span style="font-family: 'Courier New', Courier, monospace;"> libraw1394 support (Linux legacy): Disabled (Linux not detected)</span></div><div class="p1"><span style="font-family: 'Courier New', Courier, monospace;"> Juju support (Linux new): Disabled (Linux not detected)</span></div><div class="p1"><span style="font-family: 'Courier New', Courier, monospace;"> Mac OS X support: Enabled</span></div><div class="p1"><span style="font-family: 'Courier New', Courier, monospace;"> Windows support: Disabled (Windows not detected)</span></div><div class="p1"><span style="font-family: 'Courier New', Courier, monospace;"> IIDC-over-USB support: Enabled</span></div><div class="p1"><br />
</div><div class="p1">With both Mac OS X support and IIDC-over-USB support Enabled.</div><div class="p1"><br />
</div><div class="p1">Then just run make, and go to the examples directory and use some of the example code. Worked great for me!</div><div class="p1"><br />
</div><div class="p1">(Notes: I'm using OS X 10.6.8 on a MacBook Pro 6,2 (Intel Core i5 2.53 GHz))</div>cphttp://www.blogger.com/profile/15414601070491994061noreply@blogger.com0tag:blogger.com,1999:blog-3647408521803397515.post-33757332073116392362011-06-28T14:20:00.000-07:002011-06-28T14:20:38.376-07:00Building atlas on macports takes forever - try disabling spotlight indexingLast night I was trying to upgrade all my installed MacPorts programs to the latest versions, using the command<br />
<br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">sudo port upgrade outdated</span><br />
<br />
I noticed that the process seemed to take an incredibly long time building atlas. It got to this stage and nothing happened.<br />
<br />
<br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">---> Computing dependencies for atlas</span><br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">---> Building atlas</span><br />
<br />
I left it for an extremely long time, however (>6 hours), and atlas still failed to build (1). I have a pretty fast 15" MacBook Pro (6,2 - 2.53 GHz Core i5 (dual core)), so this was surprising.<br />
<br />
I ctrl-c'd and tried again, thinking that something might have gotten stuck. Then re-ran with the same results - build seemed to go hours without completing.<br />
<br />
Then I noticed in Activity Monitor that none of the compile processes were actually taking much CPU. Something that was taking up CPU was mdutil, a process that does spotlight indexing.<br />
<br />
So I disabled spotlight indexing using the following command (2):<br />
<br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">sudo mdutil -a -i off</span><br />
Afterwards things proceeded as I expected - the compile processes started taking up large amounts of CPU, and the atlas build finished within the hour.<br />
<br />
It might not be related, but if your atlas build takes forever, give this a shot.<br />
<br />
<br />
<br />
1) Similar issue that no one really had a solve for:<br />
<br />
<a href="https://trac.macports.org/ticket/27600">https://trac.macports.org/ticket/27600</a><br />
<br />
<br />
2) Disabling spotlight:<br />
<br />
<div class="p1"><span class="s1"><a href="http://osxdaily.com/2009/09/20/disable-spotlight-in-mac-os-x-10-6-snow-leopard/">http://osxdaily.com/2009/09/20/disable-spotlight-in-mac-os-x-10-6-snow-leopard/</a></span></div>cphttp://www.blogger.com/profile/15414601070491994061noreply@blogger.com4tag:blogger.com,1999:blog-3647408521803397515.post-54649846792296832202011-01-08T16:50:00.000-08:002011-12-05T09:16:00.606-08:00Digital I/O on the beagleboard using GPIO and the expansion headerI needed to send a digital output signal from my Beagleboard to a data acquisition system. This turned out to be more challenging than I thought it would be. I'm posting these notes in case they're helpful for anyone else.<br />
<br />
I used as my reference <a href="http://linuxjunk.blogspot.com/2009/01/beagleboard-gpio-input-driverless.html"><strike>this</strike></a> excellent post [Edit: the post moved to <a href="http://41j.com/blog/2011/09/beagleboard-gpio-input-driverless/">here</a>]. Because I wanted to do output rather than input, it wasn't perfectly applicable, but a lot of what they do applies.<br />
<br />
To access the necessary registers from user space, they use memory mapping. They then set up the Beagleboard expansion header pins to map to GPIO Bank 5, set the appropriate pullup registers, and enable input. They then set up Bank 5 as an input, and read from it.<br />
<br />
I first tried to mirror that setup, but doing output instead. This didn't exactly work for me. One /huge/ problem is that I am communicating with my beagleboard over a USB network adaptor. For some reason (that I have yet to figure out), toggling some of the bits on GPIO5 clobbers the USB interface. I don't know why, but I do know that only happens with the high bits, so I settled for using the low bits.<br />
<br />
Here's the relevant C code for output, based on the aforementioned post:<br />
<br />
includes:<br />
<br />
<br />
<blockquote><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">#include <stdio.h><br />
#include <stdio.h><br />
#include <stdlib.h><br />
#include <sys/types.h><br />
#include <sys/stat.h><br />
#include <unistd.h><br />
#include <fcntl.h><br />
#include <sys/mman.h></span></blockquote><br />
<br />
Setting the pin configuration:<br />
<blockquote><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">//O_SYNC makes the memory uncacheable<br />
<br />
int fd = open("/dev/mem", O_RDWR | O_SYNC);<br />
if (fd < 0) {<br />
sprintf(stderr,"Could not open memory\n");<br />
return 0;<br />
}<br />
// Pad configuration<br />
volatile ulong *pinconf;<br />
pinconf = (ulong*) mmap(NULL, 0x10000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0x48000000);<br />
if (pinconf == MAP_FAILED) {<br />
sprintf(stderr,"Pinconf Mapping failed\n");<br />
close(fd);<br />
return 0;<br />
}<br />
// set lower 16 pins to GPIO bank5<br />
pinconf[0x2158/4] = 0x00040004;<br />
pinconf[0x215C/4] = 0x00040004;<br />
pinconf[0x2160/4] = 0x00040004;<br />
pinconf[0x2164/4] = 0x00040004;<br />
/* pinconf[0x2168/4] = 0x00040004; */<br />
/* pinconf[0x216C/4] = 0x00040004; */<br />
/* pinconf[0x2170/4] = 0x00040004; */<br />
/* pinconf[0x2188/4] = 0x00040004; */<br />
close(fd);</span></blockquote><br />
GPIO Bank 5 configuration:<br />
<br />
<blockquote><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">volatile ulong * gpio_fd = open("/dev/mem", O_RDWR | O_SYNC);<br />
if (gpio_fd < 0) {<br />
sprintf(stderr,"Could not open memory\n");<br />
return 0;<br />
}<br />
// First set all output on bank5 to high<br />
// (set_data_out has offset 0x94)<br />
gpio[0x6094/4]=0xFFFFFFFF;<br />
<br />
// Configure low 16 GPIO pins on bank 5 as output.<br />
// GPIO 5 is at physical address 0x49056000 = 0x49050000+0x6000<br />
// GPIO Output enable (GPIO_OE) is offset by 0x34 for each bank<br />
// (set low for output)<br />
gpio[0x6034/4] = 0x00000000;<br />
// Also disable the wakeupenable and irqenable intertupts<br />
// GPIO clear_Wakeupenable is offset by 0x80 for each bank<br />
gpio[0x6080/4] = 0x0000FFFF;<br />
// GPIO clear_irqenable1 is offset by 0x60 for each bank<br />
gpio[0x6060/4] = 0x0000FFFF;<br />
// GPIO clear_irqenable2 is offset by 0x70 for each bank<br />
gpio[0x6070/4] = 0x0000FFFF;</span></blockquote><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br />
</span><br />
Toggling the pins from high to low, waste some time, then toggle pin back to high:<br />
<br />
<blockquote><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">//clear_data_out has offset 0x90<br />
gpio[0x6090/4]=0x0000FFFF;<br />
usleep(500);<br />
for (i=0;i<25000;i++);<br />
//set_data_out has offset 0x94<br />
gpio[0x6094/4]=0x0000FFFF;<br />
usleep(500);</span></blockquote><span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br />
</span><br />
I do not know if the "usleep" commands are absolutely necessary, but I couldn't get this to work without them.cphttp://www.blogger.com/profile/15414601070491994061noreply@blogger.com8