When you fire-up your modern IDE, chances are that there is a vertical line running down the text editing area:
Do you know why this line it there? Well, this line marks the 80th column of text, which many coding standards define as the longest that a single line of code should be before wrapping onto the next line. Give yourself +1 points if you thinks that’s why the 80th columns marker is displayed.
OK, but why 80 columns in particular? If you then say “But Simon, that’s because old computer terminals could only display 80 columns”, then give yourself another +1 points:
The IBM punched card was used in the 1950s and 1960s by IBM and others to store data and code for processing by computer. The 80 column punched card predates even this, however – IBM designed the format in 1928 for storing numerical data for processing using semi-automatic electromechanical data processing equipment.
So, your modern IDE has a feature that relates to design decision made in the 1920s.
The maker-space is finally complete. Well, “complete” in the sense that it’s 99% complete. There are always minor jobs and additions to do, as is always the case with work-spaces; they keep evolving.
Most important development tool!Place for all the nasty gooey stuff
Finally got started on the workshop. I removed the wood and nails that provided the makeshift storage among the beams, then removed the faulty fluorescent light before treating all the remaining woodwork with a universal wood treatment solution. The walls were then painted with white masonry paint, and the metal beams with green metal paint.
Cleared and painted
I’m waiting for the floor paint to be delivered, and once that’s done I can think about getting the electrics installed, and fitting a bench and storage.
It was a long time coming, but I have finally moved house! After the chaos, stress and confusion of moving my prediction that I would have a functioning maker-space set up “very quickly” was hopelessly optimistic!
Before the transformation
I’m making the setting up of this space a priority. It kind of makes sense to; a functioning workshop will be useful when working of the rest of the house.
It was intention that my February 2016 post would be the start of the chronicling of the construction of the maker-space in my new house, but that turned out to be wishful thinking, as we haven’t moved in yet. Maybe next month…
Anyway, as I’ve no projects to show due to my current workshop having been packed up into crates, I though that I’d share this piece of video that I found languishing on an old VHS tape in my loft. It’s an excerpt on the latest developments in virtual reality from the BBC science & technology show “Tomorrow’s World”, and was broadcast in 1990.
I remember being utterly captivated watching this, and have waited for 26 years for the technology to mature! I really hope that I’m not disappointed when I finally get to try an Oculus Rift, HTC Vive, or Playstation VR…
After using pre-built Arduinos the next step is to ‘roll your own’. It may not have the niceties of built in USB/debug-console, but it’s fully functional (and much cheaper!).
There are plenty of tutorials on DIY Arduino compatible circuits, so there’s no point duplicating that information here. As a reminder, however, here is what you need to make a minimal Arduino:
AVR ATmega328 Microcontroller
16MHz Crystal
22pF Capacitor (x2)
10k Resistor
10uF Capacitor
Minimal Arduino circuit
So far, so good – but with no built-in USB interface you’ll have to use either an FTDI interface (for ATmegas with a bootloader already installed), or an ICSP interface (for blank ATmegas).
FTDI Method:
To use this method you’ll need an ATmega328P that has had the Arduino bootloader pre-installed. This is a small piece of code that allows sketches to be uploaded via the microcontroller’s serial link. You’ll also need a USB to FTDI interface. I wholeheartedly recommend Adafruit’s FTDI Friend product.
The FTDI interface is connected to the ATmega328P thus:
ATmega328 FTDI Connections
Building in a programming header into your project that plugs directly into the FTDI interface can be a bit of a pain – routing the connections around the circuit takes time and space, and adds to the complexity. I prefer to simply put header pins next to the relevant ATmega pins, then use an adapter with flying leads. Another advantage is that the 0.1uF capacitor can be built into the adapter, as its only required when programming the device.
FTDI Cable
Another good idea is to make a handy reference to remind you what goes where. Print this out (laminate it if you can) and keep it with the adapter:
ATmega328 FTDI Header Pins
ICSP Method:
For this method you’ll need an ICSP interface. You’ve got a lot of options when choosing one. I use the official ArduinoISP – although it is apparently no longer made.
One of the things I don’t like about the ArduinoISP is the lack of status LEDs showing activity. Adafruit’s FTDI Friend features blinking LEDs whenever data is transmitted or received, which is a great sanity check when things don’t quite work out the way you expect. I built an ICSP programming cable that flashes an LED every time the SCK pin goes high (as you can imaging, this pin is very active during programming). The LED is driven via a BS270 MOSFET as connecting an LED/resistor directly would interfere with the data transfer (why a BS270? – it’s what I had lying around in my parts collection!). As a bonus, programming the ATmega with the test ‘Blink’ sketch will flash the LED, as the ATmega’s SCK pin maps to the Arduino pin 13.
Here are the connections for ICSP programming:
ATmega328 ICSP Connections
Using a 3mm LED with built-in resistor saves space:
ICSP Cable
Once again, make a handy reference card, and keep it, err, handy:
ATmega328 ICSP Header Pins
** ICSP GOTCHA **
Here’s a tip that may save you a few headaches. If after programming a completely blank ATmega for the first time the sketch seems to run really slowly, then try burning the bootloader first, then reload your sketch afterwards. The bootloader will be erased, but when burning it the Arduino IDE also sets certain settings in the ATmega correctly for Arduino compatible operation (specifically, it sets the device to use the external 16MHz crystal oscillator rather than the 1MHZ internal one).
Electronics isn’t just a hobby that can be used for good, y’know. With just a couple of easily obtainable parts, basic tools, and rudimentary soldering skills it’s possible to really annoy people.
Take those irritating electronic Christmas musical modules, for example. Replace the push-switch with a vibration switch, and it will be activated by the slightest movement.
Parts list:
Electronic music box from greetings-card/novelty
Vibration sensor (really cheap one from eBay or Amazon marketplace)
Music box and cheap vibration sensor
Pry apart the music box exposing the internals – taking note where the switch is located.
Inside music box
Solder the vibration switch in place of the push switch (best to remove the battery before doing this)
Sensor installed
Re-assemble the music box (I had to cut-away part of the push switch to get it back together)
Completed device
Deploy the device in a place that will be set off by occasional movement. I taped mine to the bottom of a dining chair in the staff kitchen. This turned out to be a bad idea, as it went off so often that once my colleagues had worked out where it was hidden (took them long enough, mind) they took their annoyance out on it.
Discreetly taped to the bottom of a chair
I recovered most of the bits after it had been smash and thrown across the room.
I always wanted to build my own games console, so I was pleased when I stumbled across the TVOut library for the Arduino. It enables many different types of Arduino to generate both video (PAL and NTSC) and audio signals using interrupts. One of the best things about the library is the minimal hardware that is required to implement it – just 2 resistors at its most basic.
Of course, I wasn’t surprised to find out that others had had the same idea, probably the best known of which is the Hackvision by nootropic design.
I wanted to build a system that allowed the external connection of 2 joystick or 2 paddle controllers, and the Hackvision *almost* meets these requirements; 2 paddles can be used, but it only allows for 1 joystick/d-pad. Now I could’ve just ignored the Hackvision, and built my own version, but the Hackvision has had some really good games written for it I wanted to be able to play. I needed a way to build something that could be used with 2 joysticks, but was still compatible with the Hackvision.
The Hackvision design does actually have unassigned IO pins, although not the 5 required to simply assign to the functions of a joystick. I found that I could *just* manage to connect everything if I reused pin D0 (which is used for the first paddle button) for a direction function on the second joystick, and used pin D1 for both the paddle button and joystick button on the second controllers (the first controllers use different pins for the paddle and joystick buttons).
Confused?! The circuit and pinout should make things clearer:
Console circuit – basically an Arduino and a hand-full of passive components.Controller ports labelled with functions and associated Arduino pins
Sticking to the pinouts for Player A & B ports enables the use of classic joysticks with an “Atari” connector that were used throughout the 80s and 90s, and can still be sourced relatively easily on eBay, etc. If you really insist on making your own, then this is the circuit:
Joystick/D-Pad circuit
I’m afraid you’ll have to make your own paddle controllers, but they’re pretty simple:
Paddle circuitPaddle controller construction
Housing a project in an enclosure is always more complicated and time consuming that you anticipate. I happened to have an aluminium project box in my parts-bin:
Prepared aluminium chassis
Sticky-backed plastic (Fablon) gives a good exterior finish, and is far-less hassle than painting:
Internal construction
My grandfather used to work for Plessey back in the 70s – these LEDs found their way into his workshop…
Ancient LEDs
Woodgrain Fablon for the authentic ‘retro’ look:
Finished console – Front
Finished console – Rear
Hackvision Space Invaders
I intend to write a library for the console, however I’ll have to do that at a later date. Since upgrading my Mac to OSX ‘El Capitan’, the Arduino IDE is refusing to upload anything to any of my Arduinos. I’ll get around to it when I get it fixed.
In part 1 we implemented a simple electronic dice using an Arduino (R3). Part 2 implements the same (slightly enhanced) dice using a PIC 12F629 microcontroller.
So, why use a stand-alone microcontroller rather than an Arduino? Several reasons; the PIC 12F629 is a lot cheaper than an Arduino (its even cheaper than the AVR chip that the Arduino is based upon), it’s 8-pin DIL package makes it a lot smaller than an Arduino, and finally, it uses a lot less power than an Arduino.
Here’s the schematic for the new dice circuit:
PICMicro Dice Schematic
The LEDs and their matching resistors are connected to GPIO pins configured as outputs in much the same way as before. One thing to watch out for is that while the Arduino can sink/source up to 40mA per pin, the PIC can only manage 25mA. This isn’t a problem here as 25mA is more than enough to drive pairs of the 3mm LEDs with their built in resistors.
The push-button switch is connected between ground and a GPIO pin configured as an input that is being pulled high with an external 10k resistor. Yes, PICs do have built in pull-ups, but I’ve not used them here (read on to see why!).
The reset pin is also being pulled high with an external 10k resistor. This pin can be configured as an GPIO with the reset being held high with an internal 10k resistor, but there’s a weird issue regarding the 12F629 that means it’s best to use an external pull-up on reset if you’re; a) planning to also use the internal oscillator, and b) programming the PIC with a PICkit 3 programmer.
The 0.1uF capacitor across the supply pins is to filter out any noise in the power supply (probably unnecessary in this case as I’m powering the whole thing from a battery).
PIC12F629 dice circuit on prototyping board
Explaining how to code in assembler is well beyond the scope of this post, but if you’re in the process of learning then the code is commented so may be of some help:
;**********************************************************************
; Electronic Dice
;**********************************************************************
; Filename: dice.asm
; Date: 11-Aug-2015
; Author: Simon Buckwell
;**********************************************************************
; Files Required: P12F629.INC
;**********************************************************************
list p=12f629 ; list directive to define processor
#include <p12F629.inc> ; processor specific variable definitions
errorlevel -302 ; suppress message 302 from list file
__CONFIG _FOSC_INTRCIO & _WDTE_OFF & _PWRTE_ON & _MCLRE_ON & _BOREN_OFF & _CPD_OFF & _CP_OFF
; '__CONFIG' directive is used to embed configuration word within .asm file.
; The lables following the directive are located in the respective .inc file.
; See data sheet for additional information on configuration word settings.
;***** PORT
; output
led_1and7 equ 0x04
led_2and6 equ 0x00
led_3and5 equ 0x05
led_4 equ 0x01
button equ 0x02
; counters
d0 equ 0x20
d1 equ 0x21
d2 equ 0x22
;**********************************************************************
org 0x000 ; processor reset vector
; initialise device
init
; gpio pins all digital
movlw 0x07
movwf CMCON
; switch to bank 1
bsf STATUS,RP0
; set gpio2 as input
movlw 0x0C
movwf TRISIO
; enable wake on gpio2 (falling edge)
bsf INTCON,INTE
bcf OPTION_REG,INTEDG
; switch to bank 0
bcf STATUS,RP0
re_start
; switch LEDs off
bcf GPIO,led_1and7
bcf GPIO,led_2and6
bcf GPIO,led_3and5
bcf GPIO,led_4
power_down ; go into power-down mode and wait for wake on INTE
sleep
nop
; button should be pressed - put back into power-down mode if not
btfsc GPIO,button
goto power_down
; debounce button (short delay)
clrf d0
db_loop decfsz d0,f
goto db_loop
; rotate through dice values
dice_1 ; bit pattern for '1'
movlw b'00000010'
btfss GPIO,button
goto dice_2
goto display
dice_2 ; bit pattern for '2'
movlw b'00000001'
btfss GPIO,button
goto dice_3
goto display
dice_3 ; bit pattern for '3'
movlw b'00000011'
btfss GPIO,button
goto dice_4
goto display
dice_4 ; bit pattern for '4'
movlw b'00010001'
btfss GPIO,button
goto dice_5
goto display
dice_5 ; bit pattern for '5'
movlw b'00010011'
btfss GPIO,button
goto dice_6
goto display
dice_6 ; bit pattern for '6'
movlw b'00110001'
btfss GPIO,button
goto dice_1
; display result
display
iorwf GPIO,f
; 3 second delay
movlw 0x1a
movwf d0
movlw 0x8b
movwf d1
movlw 0x07
movwf d2
delay_loop decfsz d0,f
goto delay_hop0
decfsz d1,f
delay_hop0 goto delay_hop1
decfsz d2,f
delay_hop1 goto delay_loop
; return to re_start
goto re_start
; end
end
The design makes use of the low-power feature of the 12F629 which allows it to be permanently connected to a battery without draining it quickly. I tried measuring the current draw while in its powered-down state, but my digital meter simply doesn’t go that low (we’re talking nano-amps!).
(If you’re a PICMicro novice then be assured that low-power mode and interrupts are quite advanced topics, so don’t worry if the following doesn’t make sense)
I’d never used low-power mode before so I fell for a couple of ‘gotchas’:
Firstly, I simply couldn’t understand why the device was drawing so much current in power-down mode. Even with all the LEDs turned off, and only using external pull-ups (as per the docs) it was still drawing too much current – not a vast amount, but enough the drain the batteries in about 6 weeks. Upon reading the docs in more detail I read that the brown-out detect circuit uses a fair amount of current – once that was disabled the current draw fell to an amount I could’t even measure.
Secondly, sometimes after displaying the required random number pattern it would immediately display the pattern for a ‘1’ without the button being pressed. I immediately though that it was a switch debouncing issue, and I was right, but not in the way I initially thought. While I’d set up the button detection correctly – enabling interrupts on a falling edge of INT (pin 5) while disabling global interrupts – I hadn’t realised that the falling edge was being detected while not in power-down mode, and was ‘remembered’ when power-down was entered causing an immediate re-triggering. A simple test after the sleep instruction rejected these false triggerings.
