Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


older | 1 | .... | 3 | 4 | (Page 5)

    0 0
  • 06/09/16--18:02: Adafruit_BBIO bugs
  • First bug was mine.  I was doing "import Adafruit_BBIO as GPIO" instead of "import Adafruit_BBIO.GPIO as GPIO".  That gave this error once I started trying to use it:

    $ ./test.py
    Traceback (most recent call last):
      File "./test.py", line 5, in <module>
        GPIO.setup("P9_11", GPIO.OUT)
    AttributeError: 'module' object has no attribute 'setup'


    The other bug was theirs: the code appeared to be working, but the GPIO pins weren't changing state.  Turns out there's no error checking in the library (ugh).  So it wasn't giving any errors when I failed to run the script as root.

    0 0

    Working with the Beaglebone can be really frustrating.  There are a lot of buggy libraries and incomplete docs, and the Sitara chip is really complicated, overloading its pins to do lots of different things.

    Today I needed 8 GPIO pins for a test harness.  I looked at the diagrams for the P8 and P9 headers and picked some likely-looking pins.  I used the Adafruit_BBIO python library and set them up as outputs, then toggled them and watched with the meter.  Three of them didn't work.

    So I changed my script to try to toggle *all* the pins on P9, even the ground and VCC pins.  Of course this doesn't bother Adafruit_BBIO because it has no error checking (ugh).  Here are the pins that worked as GPIO outputs.

    Note that this is from my Beaglebone *Green*.  On the Beaglebone *Black* you'd probably need to disable HDMI for some of these pins to work.

    Beware: I repeated this test several times across reboot and power down, and some of the pins worked the second or third time that didn't work the first.  It's possible that's sloppiness on my part, but my intuition says no, and that Adafruit_BBIO isn't initializing the pins correctly, so there's some random chance at play.  The best reference I've found so far in how stuff actually works is "Exploring Beaglebone", which is unfortunately a non-free book, but very well written.

    P8_7
    P8_8
    P8_9
    P8_10
    P8_11
    P8_12
    P8_13
    P8_14
    P8_15
    P8_16
    P8_17
    P8_18
    P8_19
    P8_26
    P8_27
    P8_28
    P8_29
    P8_30
    P8_31
    P8_32
    P8_33
    P8_34
    P8_35
    P8_36
    P8_37
    P8_38
    P8_39
    P8_40
    P8_41
    P8_42
    P8_43
    P8_44
    P8_45

    P9_11
    P9_12
    P9_13
    P9_14
    P9_15
    P9_16
    P9_23
    P9_24
    P9_25
    P9_26
    P9_27
    P9_28
    P9_29
    P9_30
    P9_31
    P9_41
    P9_42



    0 0

    Seems like every time I try to use the Xadow board, I have to spend hours getting it to program via the Arduino IDE.  This time, the solution seems to have been putting this in a file called /etc/udev/rules.d/78-xadow.rules and then rebooting:

    ATTR{idVendor}=="2886",  ENV{ID_MM_DEVICE_IGNORE}="1"



    0 0

    Update: Huh, I just discovered that this exists: Settings > developer options > networking > select USB configuration > RNDIS (USB ethernet).  But it doesn't seem to work.  So I suspect the RNDIS option there doesn't actually do anything.

    The BeagleBone comes with a neat feature: when you plug it into your computer's USB port, the BeagleBone pretends it is a USB hub connected to several things: a serial port, USB storage and an ethernet adapter.  Thus you can point your PC's browser to http://192.168.7.2 and pull up the BeagleBone's built-in webserver, login via /dev/ttyACM0, or look through the files on its boot partition.

    This all happens thanks to the g_multi Linux kernel module, which is one of several modules that allow devices with USB OTG ports to pretend to have things like storage, serial ports, ethernet and even MIDI ports.  g_multi aggregates a bunch of those together and presents them all to the host under a virtual USB hub.

    This works great when connecting the BeagleBone to my Linux workstation over USB, and it also partly works when I connect the BeagleBone to my (stock) Nexus 5X: I can attach the BeagleBone to the phone using this VicTsing OTG adapter, and the BeagleBone will power itself from the phone and let me browse its USB storage.

    I haven't had any success with the serial port, unfortunately.  I tried a bunch of different Android serial apps, and the phone seems to realize that the BeagleBone is offering a serial port, but I can't get any data between the devices.

    Ethernet: if you want to talk from your Android phone to your beaglebone via TCP/IP over the USB cable, the first thing you'll have to do is, sadly, turn on airplane mode so that cellular and wifi data are disabled.  If one of those interfaces is active, pings and HTTP requests no longer make it to the BeagleBone.

    Here's the other issue: recent phones like the Nexus 6P have a smaller set of USB Ethernet drivers enabled in the stock distro.  So with the BeagleBone in its default configuration, the Nexus 5X sees the ethernet interface just fine, but the Nexus 6P doesn't.

    Fortunately, the g_multi can pretend to be one of two different *types* of USB Ethernet device.  The default is RNDIS, which apparently is a common thing on Windows, and is one of the drivers that got removed on the Nexus 6P.  The other is CDC, which is apparently a cleaner standard that manufacturers of USB Ethernet adapters can follow (so that each manufacturer doesn't have to invent their own driver interface).

    Annoyingly, I can't find docs on g_multi's module parameters anywhere.  But I did manage to switch my BeagleBone from RNDIS to CDC ethernet with this change to /opt/scripts/boot/am335x_evm.sh.

    As you can see, I just commented out the block of code that decides how to load g_multi, and instead I load the standalone g_cdc CDC Ethernet driver.  (This means you'll no longer get the USB storage and serial interfaces):


     # Added these two lines:  
    modprobe g_cdc ${g_network}
    usb0=enable

    # And commented out this big block:
    ##g_multi: Do we have image file?
    #if [ -f ${usb_image_file} ] ; then
    # modprobe g_multi file=${usb_image_file} cdrom=0 ro=0 stall=0 removable=1 nofua=1 ${g_network} || true
    # usb0="enable"
    # ttyGS0="enable"
    #else
    # #g_multi: Do we have a non-rootfs "fat" partition?
    # unset root_drive
    # root_drive="$(cat /proc/cmdline | sed 's/ /\n/g' | grep root=UUID= | awk -F 'root=''{print $2}' || true)"
    # if [ ! "x${root_drive}" = "x" ] ; then
    # root_drive="$(/sbin/findfs ${root_drive} || true)"
    # else
    # root_drive="$(cat /proc/cmdline | sed 's/ /\n/g' | grep root= | awk -F 'root=''{print $2}' || true)"
    # fi
    #
    # if [ "x${root_drive}" = "x/dev/mmcblk0p1" ] || [ "x${root_drive}" = "x/dev/mmcblk1p1" ] ; then
    # #g_ether: Do we have udhcpd/dnsmasq?
    # if [ -f /usr/sbin/udhcpd ] || [ -f /usr/sbin/dnsmasq ] ; then
    # modprobe g_ether ${g_network} || true
    # usb0="enable"
    # else
    # #g_serial: As a last resort...
    # modprobe g_serial || true
    # ttyGS0="enable"
    # fi
    # else
    # boot_drive="${root_drive%?}1"
    # modprobe g_multi file=${boot_drive} cdrom=0 ro=0 stall=0 removable=1 nofua=1 ${g_network} || true
    # usb0="enable"
    # ttyGS0="enable"
    # fi
    #
    #fi



    Be careful not to comment too much: you still want the "if [ "x${usb0}" = "xenable" ] " block below to be active so that the network interface gets set up correctly.

    You might want to do all this while booted from a microSD card so that if you screw it up and can't access the BeagleBone over USB anymore, you can just pop out the card and fix am335x_evm.sh from your PC.

    0 0

    As I mentioned in my last post, BeagleBone uses the Linux g_multi kernel module so that when you plug it into a PC, it appears to be a USB hub with USB-serial, USB-ethernet and USB storage devices attached.

    In the other post I talk about how to plug a BeagleBone into an Android phone via USB and communicate between them using Ethernet.  Unfortunately it requires shutting off Wifi and cellular data.

    So instead, I investigated communicating via USB serial instead of USB ethernet.  It should work out of the box, but none of the dozens of Android apps I tried could find the USB Serial device the BeagleBone provided.

    Thus I used the same trick as before, replacing g_multi with a single-purpose device.  As in the last post, you'll have to comment out a big block of shell script in /opt/scripts/boot/am335x_evm.sh.

    Then, instead of adding "modprobe g_cdc ${g_network}" and "usb0=enable" to explicitly load the USB Ethernet CDC driver, add:

    modprobe g_serial
    ttyGS0="enable"

    When you reboot, you won't be able to "ssh 192.168.7.2" from your PC anymore.  Instead, you'll only get /dev/ttyACM0, and you'll need to login using a terminal emulator like minicom or screen.

    (As before, you may want to make these changes while booting from a microSD card so that you can just pop the card out if it doesn't work).

    After verifying that I could get in from my workstation, I connected my phone to the BeagleBone with an OTG adapter (careful!  Not all of them work right), then used the "Android USB Serial Monitor Lite" to connect to the BeagleBone.  (Open the "three dots" menu and select "Open Device", then send a newline and you should get a login prompt).

    0 0



    I've been having fun with this RGB LED string from Amazon with 300 5050 LEDs in a 16.4ft string.

    One bug: after using it for a few minutes, it seems to have swapped the red and green columns of colored buttons: red displays green and green displays red.  The controller is nonvolatile: it remembers settings across powerdowns.

    I set the controller to white (W button) full brightness and powered it with a bench supply.  I went as high as 13.8V since that's typical for a running car, and they know people will put them in their cars.  I briefly ran it upwards of 15V and it didn't immediately die, drawing about 3A.

    The color temperature changes with applied voltage, going from yellow at lower voltages to very blue at high voltages.

    The red LED first barely comes on at 5V 10mA.  The blue LED is last to come on, at around 9V 0.85A (so looks like you could power the string from a 9V battery) .  At 10V it draws 1.19A.  At 11.0V, it draws 1.56A.  At 12V it draws 1.96A.  At 13V it draws 2.33A, and at 13.8V it draws 2.65A.

    At 12V and max brightness with just one color lit, red draws 1.17A, green draws 0.95A and blue draws 0.87A.

    The output of the controller has 4 pins: White, Green, Red, Blue.  White connects to the positive rail (12V) and the three color channels are pulled down toward ground with PWM.  Each PWM channel supports 8 brightness levels if you've pushed one of the colored buttons.

    If you press one of the DIY buttons, though, you get 64 levels per color.

    PWM period is 4.1ms (244Hz frequency).

    Under the hood, the heavy lifting is done by a trio of 70T03GH MOSFETs.  The microcontroller has no markings.  The remaining IC is a 24C02 EEPROM.

    Here's an amusing aside: observe the wire harness in the top right of the photo below, which feeds the LED strip.  The LED strip's wires are colored white (12v), R, G, B, as expected.  But in the cable coming from the board: 12v is black instead of white, the green channel is a red wire marked B (but ever since my controller glitched, it's actually red), the red channel is a red wire marked G (but is actually green), and the blue channel is a blue wire marked R (and is actually blue).  So I bet the glitch I observed is part of a broader bug in which the controller flips around its channels, and which the manufacturer kept trying to fix by changing the order of wires in the harness.



    The IR signal from the remote is received by an integrated IR receiver that produces serial for the microcontroller.  Normally high (5V), it pulls low for about 9ms for a start bit, back to high for 4ms, then sends data bits.  The data bits look to me like an RTZ code: high 600us, then high or low for 600us (depending on the data bit), then high 600us, then low 600us.  Looks like about 24 data bits.




    0 0

    I have a cheap Stanley 24-inch level like this one:


    The other day I noticed it didn't seem to be very accurate.  I checked by flipping it end for end on my workpiece, and sure enough the bubble settled in a different spot.

    To measure how far off it is, I propped up the two ends with stacks of about 15 sheets of printer paper on my kitchen counter.  (It was important to support both ends because my counter isn't perfectly flat).  I added paper to one side until the bubble was dead center, then flipped the level end for end and had 9 sheets of paper (0.036") to one side before it was dead center again.

    atan(0.036 / 24) = 0.086 degrees.  Since the vial is crooked and I'm flipping end for end, 0.086 degrees represents the angle between it being crooked to one side and being crooked to the other side, which is double the crookedness.  So the vial in my level is crooked by 0.043 degrees, +- 1/64" over 2 feet, or +-0.00075 inches per inch.

    That doesn't sound like much, but it means that if I set two 8 foot beams indicated as "level", but flip the level around in between, they'll vary by 1/32 every 2 feet, for a total of 1/8" over the whole length.

    Stanley doesn't make any accuracy claims for my level, but their fancier "professional I-beam level" claims accuracy of only 0.0015 inches per inch, twice as bad as mine!  But then their 24-inch aluminum box-beam level claims 0.0005 inches per inch, somewhat better than my 0.00075.

    A fancier brand, Stabila, claims 1/32" over 72", which is also 0.0005 inches per inch.  The manual for their fancy digital level (which doesn't exactly inspire confidence with its poor formatting) claims 0.05 degrees within 0.1 degrees of level, and 0.2 degrees elsewhere.  So that's worse than my crappy level's 0.043 degrees even in the best case.  But then just below it they have a heading of "measuring accuracy of level" and claim 0.029 degrees, which is pretty confusing but just works out to the familiar 0.005 inches per inch.  Bottom line: the level could be off by 3x the allowed 0.0005 inches per inch, and the digital readout could still read it as dead level.

    So the bottom line seems to be that for best results, I want a spirit level that'll allow me to adjust it, and even fancy digital levels aren't guaranteed to be any better than perhaps 3/16" over 8 feet.

    (Just for my future reference, I also measured how much angle change there is between level and when the bubble just touches the first line.  That came out to 0.120" (about 1/8"), so a rise of about 1/16" per foot.)

    0 0

    The NVidia Jetson TX1 dev kit comes with a 5MP camera and a bewildering array of different libraries for accessing it.  One of the routes is using v4l2 through the /dev/video0 device.  This route only offers raw bayer data, rather than the more usual YUV-style formats.  Also it only supports V4L2_MEMORY_MMAP, not V4L2_MEMORY_USERPTR or read()ing from /dev/video0.

    If you 'sudo apt-get install v4l-utils' you can use this to capture a frame from the camera:

    v4l2-ctl --stream-mmap --stream-to=foo.raw --stream-count=1

    foo.raw is 10077696 bytes, 2 bytes for each of the 2592x1944 pixels.  If you want to write your own code to grab frames like this, this capture example gets you most of the way there, but you need to request the V4L2_PIX_FMT_SRGGB10 (raw bayer) format instead of the default.  So change init_device to be like this:

     static void init_device(void)  
    {
    struct v4l2_format format = {0};
    format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
    format.fmt.pix.width = 2592;
    format.fmt.pix.height = 1944;
    format.fmt.pix.pixelformat = V4L2_PIX_FMT_SRGGB10;
    format.fmt.pix.field = V4L2_FIELD_NONE;
    int retval = xioctl(fd, VIDIOC_S_FMT, &format);
    if (retval == -1) { perror("Setting format\n"); exit(3); }

    if (io != IO_METHOD_MMAP) {
    printf("Sorry, Jetson TX1 v4l2 only supports mmap\n");
    exit(4);
    }

    init_mmap();
    }



    0 0


    My friend likes to make wooden mallets:

    So I thought he might get a kick out of making one with a brass head.  Here's the head so far.  (he's still thinking about what to do for a handle).


    This much 1.5 inch hex bar stock cost me about $50 on ebay, enough to make two heads:

    The bar was too big to fit through the headstock on the lathe, so on the mill I clamped it sideways and faced the ends, indicated it vertical (overkill), used the edge finder to find the center, then center drilled both ends:

    I tapered a piece of scrap steel rod in the chuck to make a dead center.  That let me turn the piece "between centers", which is a lot more accurate than clamping the bar in the 3-jaw chuck.

    I was inspired by this brass hammer, but I wasn't sure if I wanted to use the same shape for the head.  I decided on a taper, and tried several different variants.  Because of the center hole, I had to discard the first half inch or so of stock, so it was a great place to experiment.  Here's a 20 degree taper:

    Collar grooves look nice but ultimately I kept it really simple:

    This profile was really tempting as well: flat / taper / flat leaves a sort of brickish look that's very hammer-like:


    In the end, a 10 degree taper at each end was all I wanted.  It produces a beautiful parabola shape and emphasizes the intrinsic beauty of brass.

    I did a pass all the way across to cut off the corners (which were a little banged up), and should have gone a little deeper since there were still a few blemishes.  I didn't notice them until I had already cut off the piece, so I couldn't put it back between centers, and I don't trust the 3-jaw chuck to hold it true, so I didn't have an easy way to clean up the corners later.

    Here you can see the dimple I put in the very center of the head to make it easy to put whatever kind of hole my friend decides to use for attaching the handle.

    I also rounded off the round edge of each face of the hammer so that it doesn't immediately mushroom when used on a flat surface.  But really, this hammer is more decorative than useful; it's several pounds, so it's not great for delicate work, and the whole point of a brass hammer is to get dinged up instead of the steel part you're trying to nudge.

    0 0

    There are lots of threads about problems compiling new kernels for their Jetson TX1 boards.  A lot of the issues seem to be related to the cross compilation environment.

    The TX1 is pretty beefy, so I figure it can compile its own kernel.  I installed an SSD to give me enough disk space, then copied the source_sync.sh script from the Jetpack installation to the device.  I had it download the 'tegra-l4t-r24.2.1' tag which is currently the latest version.

    I copied over the .config file from /usr/src/linux-headers-3.10.96-tegra/ to my kernel/ directory to start with the stock kernel config.  Then I ran make menuconfig to set the additional modules I wanted.

    Alas, when I tried to compile with make -j6 zImage, I got errors like this:

      VDSO32C arch/arm64/kernel/vdso32/vgettimeofday.o
    /bin/sh: 1: -Wp,-MD,arch/arm64/kernel/vdso32/.vgettimeofday.o.d: not found
    /mnt/ocz_ssd/leopard/kernel/arch/arm64/kernel/vdso32/Makefile:40: recipe for target 'arch/arm64/kernel/vdso32/vgettimeofday.o' failed
    make[2]: *** [arch/arm64/kernel/vdso32/vgettimeofday.o] Error 127
    scripts/Makefile.build:455: recipe for target 'arch/arm64/kernel/vdso32' failed

    Apparently it has something to do with backward compatibility to 32-bit ARM, which I don't even care about.   To get around that, I installed the 32-bit toolchain with 'sudo apt-get install gcc-arm-linux-gnueabihf', then export CROSS32CC=arm-linux-gnueabihf-gcc

    The next issue was this:





    drivers/platform/tegra/tegra21_clocks.c: In function ‘tegra21_cpu_clk_init’:
    drivers/platform/tegra/tegra21_clocks.c:1064:31: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses]
    c->state = (!is_lp_cluster() == (c->u.cpu.mode == MODE_G)) ? ON : OFF;


    That was fixed with an extra set of parentheses:

      c->state = ((!is_lp_cluster()) == (c->u.cpu.mode == MODE_G)) ? ON : OFF;


    That seems to do it.  I could then make -j6 zImage as well as Image, modules and (sudo) modules_install, then copy the zImage and Image to /boot.

older | 1 | .... | 3 | 4 | (Page 5)