It should work in Breadboard and Schematic mode, but absolutely doesn’t work in PCB mode. This shouldn’t be a problem, as it’s only available as a standalone board. Fritzing doesn’t have any way to create new parts from scratch any more, so I had to base it on a somewhat similar-looking board, the SparkFun Electret Microphone Breakout.
I’m looking forward to see what I can do with gpiozero and the clap sensor.
I just set up a Raspberry Pi Zero to be a little breadboard computer. Running a headless machine only through SSH gets a bit dull at times, so the inclusion of VNC Connect in Raspbian is handy.
Only problem was that the default screen size — something like 720×480 — was too small for most dialogue windows. Here’s how to enable a more useful resolution of 1024 × 768.
All of these are enabled from the raspi-config tool, so open a terminal and start it with:
Select 5 Interfacing Options → P3 VNC, and answer Yes to Would you like the VNC Server to be enabled?: Set Screen Resolution
Select 7 Advanced Options → A5 Resolution → DMT Mode 16 (1024×768) …: Once you’ve enabled all of these, raspi-config will ask if you wish to reboot your Raspberry Pi. Once it has rebooted, you should have a usable remote desktop.
(All of the above screenshots were taken from a headless Raspberry Pi Zero via VNC.)
Before & After
These were taken later on a Raspberry Pi 2 I’m setting up for a maker festival booth:
decidedly smol: 720×480fix it to 1024×768 …so much better!
PDP (Pocket DEC Pretender) Zero: lettering came out a bit more, um, artisanal than I’d hoped …
Digital (aka DEC) used to make some very solid minicomputers back when a minicomputer was fridge-sized and people were still building nuclear power stations to be controlled by them. The Raspberry Pi Zero is a very mini computer indeed, and in USB gadget mode running SimH it makes a nice little emulation platform.
DEC minis were famous for their arrays of blinkenlights. The Pocket DEC Pretender, not so much: it has one tiny green light that flickers a bit now and again:
PDP (Pocket DEC Pretender) Zero: case open, very few blinkenlights
But it’s a genuinely useful (for my values of useful) emulation platform. Here it is pretending to be a PDP-8, running BASIC under OS-8:
PDP (Pocket DEC Pretender) Zero: PDP-8 BASIC!
(background in case pictures woven in Toronto by Deftly Weft)
Building and installing the linapple-pie Apple IIe emulator is relatively easy on the Raspberry Pi:
sudo apt install libcurl4-openssl-dev libzip-dev zlib1g-dev libsdl1.2-dev libsdl-gfx1.2-dev libsdl-image1.2-dev libsdl-sound1.2-dev build-essential git
git clone https://github.com/dabonetn/linapple-pie.git
cd linapple-pie/src
make
sudo make install
This also works on an x86_64 Ubuntu machine. It does also install on a PocketCHIP (even if it takes a really long time) but I can’t get the display resolution to fit correctly.
The Raspberry Pi Zero can be set up to appear as one of several USB OTG “gadgets” if you plug it into another computer. The most popular setting seems to be the virtual network gadget that turns your Zero into a computer on the end of your USB cable. Andrew Mulholland’s guide Raspberry Pi Zero – Programming over USB! (Part 2) (along with his super-short simple guide) seems to be the definitive source on how to set these modes up.
One problem, though, is that the Zero would show up on different network addresses every time it was restarted. The changing addresses made ssh access no fun at all. A suggestion on the Raspberry Pi forum helped me come up with a solution. On the Raspberry Pi Zero, run this command once:
This will set the USB port’s hardware addresses to a fixed value, and you should always get a connection on the same IP address if it’s available.
How my Raspberry Pi Zero appears on my Ubuntu machine
Update: For some reason, this seemed to stop working, and I was getting the old random addresses again. I was resisting putting more stuff in /boot/cmdline.txt, but it seems to me it’s more reliable than what I proposed. So if your g_ether.conf looked like:
Running Mini vMac on a Raspberry Pi is hardly news. But maybe running it as a colour Mac II is. The screen size I’ve chosen is closer to a Color Classic, for no other reason that I like it.
To build a Mac II-capable version of Mini vMac, you’ll need the Alpha source code. You’ll also need a working Mini vMac setup, as it uses a 68k Mac program to set up the source. Pretty much any basic setup and bootable disk will run this okay:
Mini vMac building on an emulated Mac Classic booting from the System 7 Network Access floppy image (no, I couldn’t boot from Classic’s hidden boot ROM disk)
I’ve chosen to swap the Ctrl key with the Command (⌘) key, as most non-Mac keyboards work better with this.
The build program will export a file out/minivmac-3.5.0-larm.tar that you can unpack into the full source code. It’s a really simple build, and fast, too.
Now you’ll need a Mac IIx ROM image (which I’m not supposed to help you find, but it’s an easy search) and OS image disks from the Mini vMac System Software page. Have fun!
I wanted to have a “Hey, be here now!” ping throughout the working day. Something loud enough to hear, but not irritating.
Doing this with cron was harder than you might expect. It seems that sound is typically part of the X11 display infrastructure, so you need to give the command permission to make a noise on this particular machine’s display. Here’s the crontab line I came up with:
# m h dom mon dow command
0 9-17 * * 1-5 export DISPLAY=:0 && /usr/bin/play -q /home/scruss/sounds/ting/ting.wav
That translates as: at 0 minutes past the hours of 09:00 to 17:00 on any weekday (day of week = 1-5, and we don’t care about day of month or which month it is), execute the command play (part of the sox package) with no text output (-q). cron needs environment variables like DISPLAY set, and prefers full command paths. It may trigger a second or so after the turn of the hour; this is good enough for me.
As for the alert, I wanted something distinctive — percussive, short, bright — but with a tiny bit of modulation to stop it sounding like a bland computer-generated sine wave. This is what I made; click on the image and the sound should play or download:
It’s essentially a 2093 Hz (C7) sine wave, mixed with itself frequency-modulated at 7 Hz. Why 7 Hz? Apart from sounding about right, 2093 is exactly divisible by 7, 13 & 23, so I used a factor for neatness.
There was some later messing about in Audacity (mostly fades and length edits; I forget exactly what). The two components were generated using sox:
sox -n ting-plain.wav synth 1 sine C7 fade l 0 1 1
sox -n ting-vibrato.wav synth 1 sin C7 synth 1 sine fmod 7 fade l 0 1 1
Yes, sox does have pretty horrible syntax, doesn’t it?
The frequency-modulated one seems to be pretty close to the final result. It would be less time spent trying to save time …
micro – https://github.com/zyedidia/micro – is a terminal-based text editor. Unlike vi, emacs and nano, it has sensible default command keys: Ctrl+S saves, Ctrl+Q quits, Ctrl+X/C/V cuts/copies/pastes, etc. micro also supports full mouse control (even over ssh), Unicode and colour syntax highlighting.
micro is written in Go – https://golang.org – so is very easy to install:
If your running under Linux, you probably want to have xclip installed for better cut/paste support.
Overall, I really like micro. It’s much easier to use than any of the standard Linux text editors. It uses key commands that most people expect. Creating code should not be made harder than it needs to be.
(I was about to suggest FTE, as it appears to be the closest thing to the old MS-DOS 6 editor that I’ve seen under Linux. While it’s a great plain text editor, its Unicode support isn’t where it needs to be in 2016.
micro suggestion came via MetaFilter’s Ctrl + Q to quit. Need I say more?)
My previous adventures with my Sinclair ZX Spectrum 48K in Canada were not resounding successes. I couldn’t get the display to work, and tapes wouldn’t load well, so I’d been using Fuse while the hardware sulked in a cupboard.
I’d previously got a proper power supply (9 V DC, ≥ 1.4 A, centre negative) and bypassed the PAL UHF modulator to give composite video. No television, monitor or converter box that I had tried seemed to give a useful display.
Back in May, Walter Miraglia brought a tiny 7″ composite colour monitor to TPUG‘s Retrocomputing Night. He let me try it with the Spectrum, and it worked very well. Walter said it was an extension monitor for a car DVD player.
I dug around, and found that local surplus clearout store Tech Source Canada had the Philips 7″ portable DVD Player PD7016/37 for $60. This gives you two identical DVD players with composite input. I think my other one will be destined for a Raspberry Pi project somewhere.
To get these monitors running, you’ll need:
a 9–12 V DC power supply able to give ≥ 1 A. I use a regulated supply that gives 9.1 V open circuit and is rated at 2 A. Note that the power connector is slightly smaller than the common 2.1 mm barrel, so you may have to order this one, unless you can solder something up.
A cable like this 3.5mm Stereo to Composite Video + Audio Cable (3 RCA). These are sometimes just called camcorder cables. They use a 3½ mm TRRS jack, and can also — if you don’t mind not quite having the connectors in the right order — work with the composite/audio output of more recent Raspberry Pis. Tech Source had these for under $5.
Connect it up , and — success! Well, slightly qualified success. The screens do not have the greatest resolution, so pixels are slightly smeared together. The screens do have a decently fast refresh, and the whole look is just right. With its colour clash and dot crawl, nobody ever expected great video from the Speccy anyway.
Here are some screen shots taken with my phone, and a couple of pixel-sharp screenshots from Fuse to compare:
Moon Cresta – complete with authentic weird languageMoon Cresta — the same screen from FuseMoon Cresta – nice loading screenManic Miner — a game I am not good atManic Miner – perhaps the (deliberately?) worst game music everDeathchase — OH NOES A TREE!!!!1!! Looks like the Riders of the Big Bikes just lost another memberKnight LoreChuckie EggChuckie Egg from Fuse. We can’t do anything about the attribute clash
So I can now definitely view the screens. Huge thanks to Walter for tipping me off to these DVD players.
[Incidentally, the screens are designed for car use, so don’t stand up properly unless you get creative with some supports. I laser-cut these out of 3 mm plywood:
mini screen feet for 3 mm ply. Cutting template PDF is linked underneath this image
Glue the little sticks on to the flat ends, and they’ll fit into the slots in the back of the monitor. Here are the feet with the sticks fitted:
screen feet with sticks glued in place
There are better-designed feet than these, but they work, mostly.]
I was still having game loading problems. Try as I might, I couldn’t get anything to load reliably. Retrocomputing Stack Exchange came to the rescue, in the shape of mcleod_ideafix’s very helpful answer. If your audio player is running from batteries and you can use a stereo cable, you can convert the normal mono loading audio into stereo with one channel inverted. This gives you effectively double the volume, and works quite well with my audio player, an old Edirol R-1*.
If you want to check your audio levels, sox can also create the 800 Hz header tone used by the Spectrum. Run the output of the command below through the script above, load it onto your audio player and fiddle with the volume until the border flickers steadily:
I was also looking for the games to load fairly quickly. Tapes used to take over three minutes to load, and while retrogaming all is about the experience, I haven’t got time for that. Fuse has some utility programs which will convert a .Z80 game snapshot into an audio file that loads in about 1¼ minutes.
To convert the snapshot to a speed-load TZX tape image:
snap2tzx -o game.tzx -s 3 game.z80
To convert that virtual tape image into audio:
tape2wav -r 16000 game.tzx game.wav
You can then run that WAV file through the stereo/differential script I listed above. Have fun!
I’d tried making several Raspberry Pi Zero enclosures, but none of them quite worked. My needs are pretty simple, but I do need to be able to fit a full 40 pin strain-relieved (possibly keyed) header into the device while keeping questing fingers and dropped conductors off the circuit board.
Conserves material: The Coo~Coo uses just under 80 × 80 mm of 3 mm ply or acrylic, plus four nylon machine screws, nuts and washers.
Takes a full-sized GPIO header with a little headroom.
Provides edge protection for the µSD and connectors.
Has only a single cut layer, with no time-wasting engraved rasters.
Needs only simple tools to make: really only needs diagonal cutters to snip off half of the nylon screw heads. Needle-nose pliers might help too, as there are some fiddly small parts.
Free as in CC0. Yup, since this is derived from the Raspberry Pi Foundation’s copyrighted drawing, my modifications didn’t really add anything of value. Thus I waive all copyright and related or neighbouring rights on my additions:
To the extent possible under law, Stewart C. Russell has waived all copyright and related or neighbouring rights to the “Coo~Coo” Raspberry Pi Zero Case. This work is published from: Canada.
Why the odd “Coo~Coo” name? Well, look at the pattern of spacer washers and half-spacer washers:
To save material, I arranged these washers inside the GPIO cutout. I realised that I could spell COO~COO. It’s even clearer on the cutting document:
Coo~Coo — PDF for cutting is linked under the image
Update: here’s a revised path that cut well with acrylic and probably will work slightly better on plywood, too: coo-coo-rpi_zero-acryl.zip
(If you do use acrylic, let me introduce you to one of the marvels of backing-paper removal: d-limonene. This fruity solvent — present in products like Goo Gone — causes backing paper to slough off with only a few minutes’ soaking. It washes off to a clean shine with water and dish soap/washing up liquid. I have just saved you fingernails from certain damage!)
The cutting path in the PDF could use a little clean up if you want to try this design in acrylic. The base of the design has been flipped so that any laser flare will be hidden inside the case.
You’ll need four M2.5 or M3 nylon screws of 20 mm length, plus 8 washers and 4 nuts. M3 screws of this length are easier to get, but the mounting holes in the Raspberry Pi Zero are only 2¾ mm in diameter. You can thin the M3 screws down slightly by lightly twisting them inside a piece of folded fine sandpaper. You’ll still have to push them through the Raspberry Pi Zero circuit board with a little force, though.
Cutting & Assembly Instructions
If you have it, place some fine wire mesh or sacrificial heavy card-stock between the laser cutter honeycomb bed and the plywood. The spacer washers are just the right size to fall through the cutter bed and be lost inside the discard hopper.
Cut the piece as normal.
Remove the work from the laser cutter. Masking tape applied over the washers will stop them falling out.
Take the top piece, and thread the other two screws through the holes by the HDMI and PWR labels.
(It may be easier to do these one at a time)
Place two of the full spacer washers over each screw.
Push the screws through the Raspberry Pi Zero board. M2.5 screws won’t need any force, but M3 will need some coaxing, possibly even cajoling.
Place a nylon washer on each of the two screws under the Raspberry Pi Zero board.
Take the base and flip it horizontally so the screw holes match the top.
Very loosely attach the nuts to each of the screws.
(You’ll need the slack to fit the top two screws and their C-shaped spacers)
Feed the top two screws through the half-holes by the GPIO cutout in the case and the Raspberry Pi Zero board. Again, coaxing and/or cajoling may be required if you used M3 ones.
Put nylon washers over the screws between the Raspberry Pi Zero board and the base.
Very loosely attach the nuts to the top two screws.
(This is the fiddly bit) Stack two of the half spacers and put them on each screw. You need to get the screws tight enough to just grip the spacers against the case, but not too much or you won’t be able to align them to let the GPIO connector fit in the gap. Tightening the screws at the HDMI and PWR ports can help with this, too.
Nip off half of the heads from two of the nylon screws. This will allow the GPIO connector to fit easily.
Tighten all the screws (finger tight is fine) and make sure the trimmed heads align with the edge of the GPIO cutout.
Raspberry Pi Zero in Coo~Coo case showing GPIO and spacers
The new Raspberry Pi Zero with camera connector should also fit, but I don’t have one to test it.
Pen plotters were pretty expensive and complex pieces of electromechanical equipment. While they often earned their keep in the CAD office, they also had a function that’s almost forgotten: they could be used as input devices, too.
As a kid, we sometimes used to drive past the office of Ferranti-Cetec in Edinburgh. They specialized in digitizers: great big desk or wall mounted devices for capturing points from maps and drawings. Here’s one of their 1973 models:
While the technology and size have changed a bit, these huge bits of engineering kit are the ancestors of today’s track pads and touch screens.
Realizing that their plotters had very precise X-Y indexing and that they had two-way communications to a computer, HP made a drafting sight that fitted in place of a pen on their plotters:
HP drafting sight, part no 09872-60066
This is a very pleasing piece of kit, all metal, thick plastic and polished optical glass. They show up on eBay occasionally, and aren’t cheap. With a bit of coercion, it fits into my HP plotter like this:
Drafting sight in HP7470A plotter
The image is very bright and clear:
Drafting sight near an axis labelDrafting sight over a point, showing cursor dot
If one has a digitizing sight, one needs to find something to digitize post haste … I’m sure everyone can sense the urgency in that. So I found this, a scan from my undergraduate project writeup (centrifugal pump impeller design ftw, or something), which was probably made on an Amiga or Atari ST:
It’s a graph, with pointy bits on it
I printed this as large as I could on Letter paper, as it’s the only size my HP7470A plotter can take. Now all it needed was a small matter of programming to get the data from the plotter. Here’s a minimally-useful digitizer for HP and compatible serial plotters. Although I ran it on my little HP grit wheel plotter attached to a Raspberry Pi, I developed it with my larger Roland plotter. The only fancy module it needs is pySerial.
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# a really crap HP-GL point digitizer
# scruss - 2016
from time import sleep
from string import strip
import serial
ser = serial.Serial(port='/dev/ttyUSB1', baudrate=9600, timeout=0.5)
lbl = ''
points = []
labels = []
k = 0
retval = 0
ser.write('DP;') # put in digitizing mode
while lbl != 'quit':
ser.write('OS;')
ret = strip(ser.read(size=5), chr(13))
print ('Retval: ', ret)
if ret != '':
retval = int(ret)
if retval & 4: # bit 2 is set; we have a point!
print ('Have Point! Retval: ', retval)
retval = 0
ser.write('OD;')
pt = strip(ser.read(size=20), chr(13))
print ('OD point: ', pt)
lbl = raw_input('Input label [quit to end]: ')
points.append(pt)
labels.append(lbl)
k = k + 1
ser.write('DP;') # put in digitizing mode again
sleep(1)
ser.close()
f = open('digit.dat', 'w')
for i in range(k):
f.write(points[i])
f.write(',')
f.write(labels[i])
f.write('\n')
f.close()
In the unlikely event that anyone actually uses this, they’ll need to change the serial port details near the top of the program.
The program works like this:
Move the drafting sight to the point you want to capture using the plotter’s cursor keys, and hit the plotter’s ENTER key
Your computer will prompt you for a label. This can be anything exceptquit, that ends the program
When you have digitized all the points you want and entered quit as the last label, the program writes the points to the file digit.dat
I didn’t implement any flow control or other buffer management, so it can crash in a variety of hilarious ways. I did manage to get it to work on the lower trace of that graph, and got these data:
The first two columns are X and Y, in HP-GL units — that’s 1/40 mm, or 1/1016 inches. The third column will always be 1 if you have the sight down. The last columns are the label; if you put commas in them, opening the file as CSV will split the label into columns. I used it to fudge axis points. You’ll also note that the last three lines of data are my valiant attempts to quit the program …
Assuming the axes are not skewed (they are, very slightly, but shhh) some simple linear interpolation gives you the results below:
(For prettier things to do with plotter digitizing commands, Ed Nisley KE4ZNU has made some rather lovely Superformula patterns)
If you don’t have a plotter, or even if you do and you don’t have hours to waste mucking about with Python, obsolete optics and serial connections, Ankit Rohatgi’s excellent WebPlotDigitizer gets numbers out of graphs quickly. It handles all sorts of graphs rather well.
I’m still happily using a Raspberry Pi 2B 3 as a lightweight desktop machine. It’s not my main computer, but it’s pleasantly capable. Set up with a couple of paged desktops (or virtual desktops, as we used to call ’em), I can get a bunch of things done with it.
One feature that really irked me, though, was the way that window switching worked. Or, for greater clarity, didn’t work. Openbox, the standard window manager in Raspbian, didn’t allow you to switch to windows on another desktop with Alt+Tab. As I have a smallish screen, I typically have very few windows per desktop, so I want that ability to move from task to task.
This, however, can be fixed. In your ~/.config/openbox/lxde-pi-rc.xml file, change the keybinding sections for Alt+Tab and Alt-Shift+Tab from:
Log out, log back in, and Alt+Tab across desktops should Just Work. If you’re not using the default pi user, I suspect you’ll have to edit the ~/.config/openbox/lxde-user-rc.xml file instead.
Hey! This is yet another of my ancient posts about Raspberry Pis that probably contains out-of-date information. In order to run FreeBASIC on a Raspberry Pi, all you need do is:
FreeBASIC is a pretty nifty cross-platform BASIC compiler. It uses a Microsoft-like syntax, has an active user and developer base, and is quite fast. Building the latest version on a Raspberry Pi is a bit of a challenge, though.
FreeBASIC 1.01 demo running on a Raspberry Pi from Geany
Part of the problem is that FreeBASIC is mostly written in FreeBASIC, so you need a working compiler to bootstrap the latest version.
Update: you’re probably best just downloading the binary install packages from the FreeBASIC site. I’m having difficulty getting recent (late 2016) source packages to build for reasons that would take too long for most people to care about.
unzip fbc_linux_armv6_rpi_version.zip
cd fbc_linux_armv6_rpi/
chmod +x install.sh
sudo ./install.sh -i
Don’t delete the installation folder just yet.
Grab the latest version of the source from github:
cd
git clone https://github.com/freebasic/fbc.git
Change directory to the new FreeBASIC source folder (cd fbc), and type make. (or, on a Raspberry Pi 2 or 3, make -j4 to use all the cores …). After a while (in my tests, about 52 minutes on a 512 MB Raspberry Pi, or around 6½ minutes [!] on a Raspberry Pi 2), it should finish. If there’s a bin/fbc file, the compilation worked!
Before you install the new compiler, uninstall the old one: change directory to the fbc_linux_armv6_rpi folder, and type:
sudo ./install.sh -u
Once that’s done, go back to the new fbc folder, and type:
sudo make install
And you’re done! You can delete the fbc_linux_armv6_rpi folder now. If you don’t mind it taking up space, keep the fbc folder to allow you a quick rebuild of the latest version of the compiler with:
cd fbc
git pull
make
sudo make install
Note that this will build a native armv7l compiler on a Raspberry Pi 2, and an armv6l one on a Raspberry Pi. This means you can’t run binaries you built on a Raspberry Pi 2 on a Raspberry Pi (you’ll get an Illegal Instruction error), but you should be able to run ones built on a Raspberry Pi on a Raspberry Pi 2. Binary compatibility is overrated, anyway …
So, the DVD drive on my laptop’s on the fritz. It reads data fine, but ripping CDs with CDDA checks makes it go over the transport error rainbow bridge. So, partly through necessity and partly for lulz, I wondered how well a Raspberry Pi B+ would do on ripping CDs. I’ve got an old IDE DVD-R drive in an external 5¼” USB enclosure (huge!). I set about installing abcde, which is about the leanest way of ripping CDs in a terminal that I know. The standard sudo apt-get install abcde didn’t quite come up with all of the options I’d want to use, so I made the mistake of trying this:
sudo apt-get install --install-suggests abcde
Nooooooooooooooooooooooooooo! This horror suggested I install the following:
Eep! That looks like the full TeXLive system, most of QT4, almost every TrueType font ever (plus a font editor), printer drivers, the full Apache webserver setup, MySQL, a couple of web browsers, scanner drivers and OCR programs, a mail server … 2.4 GB of downloads, or over 6 GB installed. And all this for a command line script for ripping CDs.
Much better. Installed in a couple of minutes. Worked quite well, if not fast — ripped and encoded a 45 minute CD in just under 26 minutes (using lame -V2, which is good enough for me). For setup hints for abcde, abcde: Command Line Music CD Ripping for Linux is a good resource. On a Raspberry Pi, with its single core processor, you probably want to set MAXPROCS=1 in the abcde.conf file, or the encoders will fight for resources and get really slow.
$ stty -F /dev/ttyACM0 speed 115200 raw cs8
$ rngtest -t 6 < /dev/ttyACM0
… much snippage …
rngtest: bits received from input: 312368864
rngtest: FIPS 140-2 successes: 15602
rngtest: FIPS 140-2 failures: 16
rngtest: FIPS 140-2(2001-10-10) Monobit: 2
rngtest: FIPS 140-2(2001-10-10) Poker: 2
rngtest: FIPS 140-2(2001-10-10) Runs: 8
rngtest: FIPS 140-2(2001-10-10) Long run: 4
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=837.317; avg=1168.033; max=1948.060)Kibits/s
rngtest: FIPS tests speed: (min=16.834; avg=27.779; max=77.221)Mibits/s
rngtest: Program run time: 271917796 microseconds
Over a megabit/second of decent quality random data. This is from an Arduino Due, which has an Atmel SAM3X8E ARM Cortex-M3 microcontroller on board. I hadn’t found much use for this board previously, as it fell between a regular 8-bit Arduino and my (many!) Raspberry Pis.
This changed when I found out about Walter Anderson’s Entropy library, which uses µc timer jitter as a source of entropy. Originally designed as a slow but true source of random integers on the Atmel AVR chips, it’s been extended to use the SAM3X8E‘s built-in hardware RNG. Since the Due has a native USB port, you’re not limited to standard baud rates.
Here’s the code, trivially modified from one of Walter’s examples:
// Generate_Random_Bytes_Due - speedy demo of Arduino Due's HWRNG
// based on Generate_Random_Bytes, for Entropy, an Arduino library.
// Copyright 2012 by Walter Anderson
// modified - scruss - 2014-08-13
// remember to reconnect to native USB port
#include <Entropy.h>
void setup() {
SerialUSB.begin(115200);
while (!SerialUSB) {
; // wait for serial port to connect.
}
Entropy.initialize();
}
void loop() {
uint16_t r = Entropy.random();
SerialUSB.write(lowByte(r));
SerialUSB.write(highByte(r));
}
It’s a minor pain to have to reconnect the USB cable to the other port on the Arduino Due after programming, but it’s worth it just to see an 84 MHz µc belting out random bytes 37½% faster than an 800 MHz Raspberry Pi …
I don’t recommend this in any way, but cpuminer will run on the Raspberry Pi. It’s pretty easy to build:
sudo apt-get install build-essential libcurl4-openssl-dev automake git
git clone https://github.com/pooler/cpuminer.git
cd cpuminer/
./autogen.sh
./configure CFLAGS="-march=armv6 -mtune=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp -ffast-math -ffast-math -O3"
make
sudo make install
I’m not convinced that the l33t funroll-l00pz CFLAGS are strictly necessary. Yes, you still only get 0.34 khash/s on a stock Raspberry Pi — which means it would take several days to earn 1Đ (or roughly 0.1¢).
I’m trying to find the most futile computer on which to dig Đ. My BeagleBone Black is (somewhat surprisingly) more than 2× as fast, once you replace the very limited Ångström distribution with Debian. I’m really disappointed that I can’t build cpuminer on my Intel Galileo. Its Yocto distribution is extremely small yet confusing. As the board runs burny hot under no load, I wonder how quickly it would glow white-hot under 100% CPU load.
Given all the warnings about static, I was a little too careful trying to install the camera into the housing. Slip open the camera case, then put the board in at an angle with one side in one slot, then (with a bit more force than I’d like) spring or flex the housing so the other side of the board can click into place. You have to make sure that both sides are fully engaged in the slots before the cover will slide back on.
So here it is, all set up:
Oh, sorry; should’ve warned you about the bright pink case and the awesome/appalling Lisa Frank sticker. The sticker is in no way to cover up where I cut the wrong place for the camera connector, nope nope nope …
Hey! This is very old and there’s an officially supported version outnowcoming out very soon.
Update for Raspberry Pi 2/Processing 2.2.1/Processing 3.0.5: Raspbian now ships with Java 8, and Processing only likes Java 7. oracle-java7-jdk is still in the repos, so install that, and follow the instructions below. It’s a bit flakey, but when it runs, runs quite fast on the Raspberry Pi 2. You might have more luck running Processing.js or p5.js in the browser.
With Sun Oracle hardfloat Java now available, Processing now runs at a decent clip on the Raspberry Pi. My old instructions are now very obsolete. Here are current, tested instructions for installing it under Raspbian.
[This is a particular solution to installing a Serial/Firmata-enabled Processing 2.1 distribution on a Raspberry Pi. Processing still has issues with other aspects of visual programming (particularly video) that I’m not addressing here.]
A lot of software is installed here, and much of it depends on previous steps. Don’t jump in mid-way and expect it to work.
Update the system
Always a good plan if you’re doing major upgrades:
sudo apt-get update
sudo apt-get dist-upgrade
Install Sun Oracle Java
sudo apt-get install oracle-java7-jdk
Check if the right version is installed as default: java -version should give
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) Client VM (build 24.0-b56, mixed mode)
If you get anything else, you need to make Sun Oracle’s version the default:
sudo update-alternatives --config java
Download & Install Processing
Go to Download \ Processing.org and get the Linux 32-bit version. It’s big; about 100 MB. I’m going to install it in my home directory, so the base path will be ~/processing-2.1. Extract it:
tar xvzf processing-2.1-linux32.tgz
Now you have to remove the included x86 Java runtime, and replace it with the Raspberry Pi’s armhf one:
// Example by Tom Igoe
import processing.serial.*;
// The serial port
Serial myPort;
// List all the available serial ports
println(Serial.list());
When this runs (it’s a little slow), you should get a single line of output, which should start /dev/tty___:
/dev/ttyACM0
(I have an Arduino Leonardo attached, which usually appears as an ACM device.)
Installing Arduino/Firmata support
(I’m not going to go into uploading Firmata onto your Arduino here. All I can recommend is that you use the newest version at firmata/arduino, rather than the old code bundled with your Arduino distribution.)
Exit Processing, and download processing-arduino.zip from firmata/processing. Extract it into your Processing sketchbook:
What this sketch does is emulate the µC’s “Hello World” program, Blink. It flashes the board’s LED once per second. Boring? Yes. But if it worked, you have a working Processing 2.1 installation on your Raspberry Pi. Go forth and make more interesting things.
(Props to bitcraftlab/wolfing for the basic outline for installing Processing, and for samaygoenka for the prodding needed to update and test the Processing installation process. If you’re still stuck, the Processing 2.0 Forum and the Raspberry Pi Forum are good places to ask.)
