waveform80

U-Boot Environment Tools

A simple Python script for editing U-Boot environments. Should automatically detect the size of the U-Boot environment, and whether the "redundand" (sic) byte is included in it.

The script can be renamed (or linked) to "dump-env" for a simple tool to dump U-Boot environments too, or to "dot-env" for a tool that'll attempt to generate a Graphviz dot graph by parsing the U-Boot environment from $bootcmd (please note this last function is quite experimental, although I've found it useful in the past for figuring out the dependencies and execution paths of certain scripts).

Summary

• edit-env env - Edit U-Boot environment env in the system editor

waveform80

# Working (overlays image on videotestsrc)
gst-launch-1.0 videomixer name=mix ! videoconvert ! xvimagesink   multifilesrc location="test.png" caps="image/png,framerate=0/1" ! pngdec ! imagefreeze ! alpha method=0 alpha=0.5 ! mix.  videotestsrc ! "video/x-raw,format=AYUV,framerate=25/1,width=320,height=240" ! mix.

# Fails (attempts to overlay image on webcam source)
gst-launch-1.0 videomixer name=mix ! videoconvert ! xvimagesink   multifilesrc location="test.png" caps="image/png,framerate=0/1" ! pngdec ! imagefreeze ! alpha method=0 alpha=0.5 ! mix.  v4l2src device=/dev/video0 ! "video/x-raw,format=YUY2,width=320,height=240" ! videoconvert ! mix.

# Output of failing command:
cat << EOF

Setting pipeline to PAUSED ...

waveform80

An extremely hacky, quickly thrown together script to extract various revisios of a specific Discourse post on discourse.ubuntu.com. Uses the "markdown diff" to extract the "current" revision and dumps them to individual markdown files

Does Discourse actually have an API for this? I couldn't find it...

waveform80

Demeter Installation

These instructions cover a non-root manual build of Bruce Ravel's Demeter package under Ubuntu 12.04. The instructions are deliberately written with a non-technical audience in mind and hence might read as somewhat patronizing for the technical reader. The main

waveform80

Capturing video both before and after motion detection

Assuming you want to record 10 seconds of video before motion is detected, and 10 seconds of video after motion is detected, you can simply create a circular buffer with enough space for 20 seconds of video, wait until motion is detected, then wait 10 seconds more, and only then write the contents of the circular buffer to disk. basic_circular.py demonstrates this.

The second example is a little more complicated and results in a couple of files per motion event: the 10 seconds before and the all seconds that motion is still occurring after first detection. Once motion is detected, we start recording subsequent frames to a file, and while that's going on, dump the circular buffer to another file. Once we stop detecting motion, we close the "after" file, and split recording back to the circular stream. This is demonstrated in advanced_circular.py.

waveform80

#!/usr/bin/env python

import io
import time
import picamera
import picamera.array
import numpy as np
from PIL import Image, ImageDraw

waveform80

from __future__ import (
    unicode_literals,
    absolute_import,
    print_function,
    division,
    )
str = type('')

from picamera import PiCamera
import curses

waveform80

ZMQEventLoop / SelectEventLoop "hang"

The following scripts can be used to reproduce the ZMQEventLoop (and the default SelectEventLoop) in urwid "hanging" when watched queues (or file descriptors) are ready but aren't serviced by their respective handlers.

The zmq_send.py and zmq_recv_1.py scripts can be run together to demonstrate a simple urwid application that receives messages from a SUB socket and displays them next to a clock. The zmq_recv_2.py script demonstrates what happens when the SUB socket is "ready" but isn't cleared by the handler; it's simply called repeatedly in preference to anything else. The display doesn't update unless draw_screen() is

waveform80

From the original comment:

@Yoshqu there is a much simpler way to measure boot time to the usec, without having to use that custom bootloader

basically, ST_CLO begins counting at 1mhz, the instant the SoC comes out of reset and /proc/uptime begins counting seconds when linux starts up its internal clocks

the code in the gist, will then print both of them at once, and if you find the difference, youll see how long it took for linux to gain control of the core

waveform80

Relies upon PIL to parse the initial JPEG structure and then does its own TIFF/Exif parsing because PIL's isn't up to dealing with the "full" Exif structure; looks like it gives up after IFD0.

Only tested with the V1 camera module, but I expect it'll work with either model. There's lots of stuff in here which isn't as efficient as it could be and a fair bit of cruft, but it's only a demo :)