SoylentNews

(This is the 34th of many promised articles which explain an idea in isolation. It is hoped that ideas may be adapted, linked together and implemented.)

In the book: Waldo by Robert Anson Heinlein, a 1950s style workshop (lathe, hammer, saw) is used to make a 1/4 scale matching pair of three finger mechanical hands. This requires the tedious work of drawing wire, winding motors, constructing capacitors and suchlike. A 1/4 scale set of tools is also constructed. Using the hands and the appropriate size tools, 1/16 scale hands can then be constructed. Likewise for 1/16 scale tools. Then, 1/64 scale hands and tools can be constructed. (Incidentally, this process requires very little material. For example, 1/64 scale hammer handle requires very little wood.)

A stable work environment for an Arduino is an analogous problem. While it is possible to install Arduino development software on any system, this is a haphazard approach which can fail at inopportune times. There are also the problems of security and reproducibility. My solution to this problem is pragmatic but far from ideal. Ultimately, chips used in all Arduino designs are proprietary. Deployment of code onto these chips uses avrdude for AVR architecture or bossac for ARM architecture. These handle architectual quirks, such as EEPROM partitioning, EEPROM privileges as seen from the running code and recovery from failed programming cycles. I also assume conversion of ELF blobs to raw binary occurs at this stage but I have seen no mention of this process. Regardless, all of this occurs over a virtual serial port over USB which itself is poorly defined. The implementation may involve an FTDI serial adapter or functional equialent and therefore safe and continued use is mutually exclusive with Microsoft Windows drivers.

For development of a speaker array, the solution to this mess is as follows:-

• An arbitrary computer with wired Ethernet. I'm using a donated laptop without any storage except 4GB USB storage containing TailsOS. This computer is only used as a screen, keyboard and SSH client which is thankful because it has a dodgy power connector, systemd and a GUI which is worse than Ubuntu's hateful default.
• A Raspberry Pi with 8GB MicroSD storage. Variant is unimportant. Primary instance was an old model donated by a children's coding academy. The hot spare belongs to an ex-colleague who is avoiding me. This runs the Jul 2017 release of Raspbian. For my sanity, systemd has been replaced with fully patched simple-init which runs unchanged on all versions of Raspbian released over the last three years. I also note that simple-init correctly handles CVE-2017-9445, unlike systemd.
• A clone Arduino Due. Also known as a rectangular tuit due to its mind-focussing ability.
• SPI DACs to arrive within two weeks. These are slightly more expensive than I2S DACs but do not require a continuous bit rate. Therefore, SPI DACs are more suitable for bit-banging techniques which match or exceed the 25Mb/s required for 32 channel audio. For testing, Microchip MCP4921 12 bit SPI DACs will be used with PAM8403 amplifiers. For deployment, Analog Devices AD1952 24 bit SPI DACs will be used with LM741 amplifiers.
• For testing, cheap speakers will be purchased from retailers. These will be replaced with cube speakers despite their known limitations.

The advantages of this arrangement are numerous:-

• System is portable and can be demonstrated at any location.
• System is fairly well air-gapped and can be used off-line.
• No software updates are required during the development cycle.
• Can use any choice of text editor.
• One step build with make.
• Hedged against most hardware failures with the exception of the Arduino Due development board.
• Backup of work requires an incremental tar. Total size of one backup will never exceed 8GB.
• Deliverable is source code which runs on hardware available from multiple manufacturers and multiple vendors.