 |
| A General Purpose 3 Channel 16A Relay Board
Every year, for about 5 years now, I get motivated on a long term project of mine, to make an open source heating control system, and every year, I get distracted and fail to make any real progress.
Well, this year it's different. I have had a week off work at the end of November, and I was determined to progress the project along a little further.
I've come up to North Wales this week to meet up with Trystan Lea and Glyn Hudson of OpenEnergyMonitor.org to have one of our irregular meet-ups, to work on collaborative projects together.
The relay board was something I had wanted to do for some time, and to do it as a potential project with OEM was an attractive idea. Not only will it reach a wider user base, but it has been designed to be compatible with and complement the existing OEM ecosystem - consisting of emonTx, emonGLCD, emonCMS etc.
The board is intended to be a plug in replacement for existing central heating controllers, though with 3 16A mains relays, it is also a very versatile board for other applications.
Power Supply.
The mains section consists of the 3 relays and a 2.3VA transformer power supply. This restricts the live, mains-potential voltages to the upper third of the pcb where they can be kept out of harms way with a suitable insulating enclosure.
Sensor Connectors
The lower two-thirds of the pcb is the microcontroller section, expansion connectors and user interface.
The expansion connectors allow a range of temperature sensors to be plugged in.
There is an RJ45 connector which allows the Dallas "One Wire" DS18B20 temperature sensors to be connected. OEM use these already on their emonTx and emonTH products, and so it seemed sensible to use these again, benefiting from their stock item and existing firmware. Additionally they stock an RJ45 break out board, which will accept up to six of these sensors, and can be daisy-chained using standard RJ45 network leads to extend the sensors 6 at a time. If you have a lot of sensors to wire in, this would be a neat solution.
In addition there is provision for up to 6 analogue inputs. These have been tailored for 10K thermistors, but any analogue signal up to 3.3V may be measured. I prefer thermistors to the digital type sensors, because they can give better resolution, and they are available in a handy "pipeclip" package, from Rapid Electronics - which are great for making measurements on heating pipes.
Open Collector Output
In addition to the temperature sensing channels, there are some unbuffered digital inputs which are 5V tolerant, and one 200mA open collector transistor output which can be used for driving a 4th external relay.
User Interface.
The user interface is designed to be simple and intuitive - just 4 push button switches and 4 LEDs. As this device will generally be commuicating with the rest of the system via a wireless link, to a remote display (emonGLCD), the user interface can be very simple.
The LEDs give positive confirmation that the relay has switched to its ON position, and the push buttons are arranged below the LEDs - and can be used for selecting a "boost" or "over-ride" function for any of the 3 relays or external relay drive.
Microcontroller Section
This unit is designed to have a plug in microcontroller module, which includes the wireless device.
The reason for this is that it will allow various combinations of microcontroller and wireless to be used. It also puts all of the slightly tricky surface mount components onto the one pre-built module, whilst the rest of the board uses through hole components for easy home construction.
The first module to be used will be the newly updated RFMPi from OEM - below.
This is a combination of an ATmega328 and either an RFM12B or a RFM69. Whilst this module has previously been used to provide RFM wireless connectivity for the Raspberry Pi, we have updated the design this week, to break out most of the I/O to a 24 pin connector (on the left) - allowing access to 8 analogue input and 8 digital I/O lines plus the SPI bus. Indeed this should make a compact and useful module with many possible applications.
Another option is my RFM_Stick. It's based on the ATmega328 and has a position for an RFM12 and the new Espressiv ESP8266 WiFi module. This is a new board from me, and no samples are available yet.  The RFM_Stick is the first of a series of boards that share a common 40 pin footprint. There will be a choice of AVR or ARM based boards, designed to have a range of communication options and be breadboard friendly. ARMiGo is the first of these.
On the right hand side of the pcb is the standard "FTDI" connector footprint which allows serial comms and local programming of the microcontroller.
For those who wish to use another microcontroller or wireless, all of the I/O appears on a 40 pin DIL footprint - which is compatible with my recently updated ARMiGo module. This is a high performance ARM M4 Cortex - with a choice of 48 pin package microcontroller options.
Real Time Clock
I have included an option for a real time clock on the pcb. This can either be a DS1307 or similar, (industry standard footprint) - or my preferred MCP79410 - which is very cheap. The RTC has back-up from a supercapacitor - so that time is maintained during a power outage.
In some applications, operation from a dc supply or a battery might be applicable. A 3 pin connector allows a LiPo or similar battery pack to be added if required.
It is anticipated that samples of the relay board will be available around the 10th of December. Please contact openenergymonitor.org in early December for full details and availability. |
Thursday, November 27, 2014
At Last - The Long Awaited Relay Board!
A Sneaky Week In Snowdonia
 |
| It's not every day your daily commute includes a view of Snowdon in the early morning November sunshine! |
Sometimes you just need to get away......
With an enforced week off work in late November, I decided to travel back to North Wales, where I was a student back in the early 1980's. For 3 years, Bangor, Gwynedd and Snowdonia was my immediate life.
With a bit of nostalgia, I left a very wet Surrey last Sunday afternoon, and drove the 250 miles up to southern Snowdonia.
Now 30+ years on, I am back in my old familiar university stomping ground, marveling at the changes that have occurred since I was last her, 3 decades ago. A lot more retail parks, more roads, and bigger buildings than were here when I was a student. My old hall of residence Neuadd Reichel still stands, but now surrounded by a cluster of new student accommodation blocks painted in garish pastel colours. Any Bangor alumni who remembers the Plas Gwyn and Tryfan halls, will be shocked to see how they are now demolished and replaced with the modern blocks. Gone also are the old students union building and the Theater Gwynedd - currently under re-construction, over budget and months behind schedule.
Whilst I have lost touch with almost all of my University contemporaries, I now have new friends in and around the Bangor area.
 |
| The Bothy - home for a few days |
I'm staying in a bothy, a small traditional cottage, about a mile from the village of Llanfrothen. It's a stone built Welsh cottage, located in a valley that contains a small stream.
Inside it's about 12' x 18' living space with a bed on a mezzanine floor. Roof lights make the most of the natural daylight. Downstairs a small kitchen, with two ring gas cooker, fridge and washing machine. The all important woodstove becomes the focal point of the room. Adjacent to the main living space is a toilet/shower-room. It's basic - but sometimes basic is just what we need to bring us back to realise some of our fundamental values.
The bothy is located in a wooded valley and so is well supplied with firewood for heating, there is an electric immersion water heater, telephone landline and broadband. Mobile reception here is at best flaky on some networks - at worst, non existent.
So, I'm here for a week, not exactly for relaxation, but to catch up with some of my good friends who live in this little corner of North Wales.
My hosts this week are Trystan Lea and Glyn Hudson - who founded Open Energy Monitor about 4 years ago. The bothy belongs to Trystan's father, and was once used as an architect's studio, before Trystan and Glyn took it over a few years ago as the premises for their start up, open source energy monitoring company, Megni.
Megni has now outgrown the bothy, and has moved to a serviced office premises in Parc Menai - a fairly new development on the southern outskirts of Bangor.
It's a 25 mile commute from Llanfrothen to Parc Menai - and so Trystan has wisely invested in a Nissan Leaf Electric Car. With a range of 60 miles, it easily meets his daily commute requirements - and what a commute that is, through the beautiful scenery of south Snowdonia.
 |
| Trystan's electric Nissan Leaf, on the Pen Y Pass, en route to Llanberis. |
The Nissan Leaf is an all electric super-mini. It can seat 4 adults in comfort, and has a boot that can easily swallow a couple of mountain bikes, with the back seats lowered.
A 50 mile round trip uses about 13.5kWh of mains electricity, or about £2 worth. The same trip in my Golf TDi would cost about £6.50 in diesel.
Trystan uses the Leaf on a daily basis and at weekends, recharging at night on a standard 13A extension lead, and occasionally with a top up at the office, on the end of an extension lead.
Snowdonia was an early pioneer of renewable energy. A little research shows that hydro electricity was first developed here in Snowdonia in the early 1900's. Today there are several hydro schemes in operation, including the pumped storage scheme at Dinorwic - which was under construction 30 years ago, when I started as a student here.
 |
| "Chapel in the Valley" Cwm Dyli. Hydro-electricity generated here has served this part of Snowdonia for 110 years. |
 |
| A mirror-like lake, Llyn Cwellyn - on the way to Caernarfon |
 |
| Though early morning mists we see, visions of reality....
A visit to my old engineering department revealed that Engineer's have a sense of humour too
  TBC |
Sunday, November 16, 2014
As Easy as ABC (and D)
The Arduino has definitely been a major force behind the open hardware movement, democratising hardware and making it much easier to develop microcontroller based gizmos.
However, despite it's popularity, the Arduino is showing it's age and has a few flaws. It has however shown that a simple microcontroller board combined with an IDE , an ecosystem based on shields and a strong community following is certainly one way to gain traction in a market for ever more complex products.
The 8 bit AVR at the heart of every Arduino, is a success story in itself. Conceived in the early 1990s and comercialised in partnership with Atmel in 1996, the AVR is a leader in the 8 bit microcontroller market. However, there is much competition from 32 bit micros - especially ARM, so perhaps it is time to work on a new platform, with its own ecosystem, and for the next few years, there is no reason why AVR and ARM cannot co-exist in the open hardware community.
A great YouTube about the "AVR Story"
So how would you design a better "Arduino" ? Here's some of my thoughts:
1. A smaller footprint 60 x 20mm (about 1/3rd the size of an Arduino Uno).
2. Pins on a proper 2.54mm pitch that can be easily plugged into a breadboard
3. USB as standard for VCP comms, programming and power
4. Easily identified ports - arranged by function
5. A forgiving footprint. If you plug it is backwards, you won't fry the microcontroller
6. More I/O - 32 pins, as opposed to 20
7. Higher resolution ADCs: 12bit and 16 bit available. 2 DAC channels
8. More UARTS, SPI and PWM
9. Wireless connectivity - with a choice of BLE, WiFi or low power 433/868MHz
10 Upgradable as new microcontrollers arrive in the marketplace
Many vendors sell their microcontrollers in a 44 or 48 pin surface mount package. This is nice and compact, but not easy to prototype with. So let's mount the SMT device on a carrier pcb, add a crystal and reset circuit and bring the pins out to an industry standard 40 pin DIL footprint. A mini B USB connector at one end allows the device to be plugged into a laptop for programming, communications and power.
Here's one I made earlier - ARMiGo a platform for 48 pin STM32F ARM devices:
As you can see, there's a 48 pin LQFP at the centre, a mini USB B at the right hand side and a SMT crystal. The 5 pin header on the left is for programming, using the ST Microelectronics ST-Link programmer.
Now this was based on the STM32F303, a great little ARM Cortex M4 device. But it could equally use the STM32F103, or STM32F373, or STM32F411, or even the stonking Cortex M7 - a 200MHz mcu. The great thing about the STM series of ARM devices is that once you have settled on a package size, you can move up and down the family to suit the needs of your application, as packages are fully pin compatible.
The ARMiGo was my first attempt at a generic module, and I must admit, I did not get it right first time. It was tracked out in such a way that gave maximum convenience for pcb layout - rather than in a logical manner where pins were grouped by function. The other faux pas - was my power pins were at opposite corners (common on many DIL packages). If you plug it in backwards - you fry the microcontroller.
I decided to look at the DIL package AVR devices - in particular the 40 pin ATmega1284. These parts have their power pins in the centre, and the ports are generally symmetrical. Plug it in backwards, and no damage will occur.
Here's a neat diagram to illustrate this point:
This can readily be mounted on the carrier pcb and tracked out so that the various peripherals and ports appear on the correct pins. The 8 analogue inputs map to Port A. The obvious communications pins TXD, RXD, MOSI, MISO, /SS and SCK map to Port C. The PWM channels map to Port D etc.
This same philosophy could be applied t0 the 44 Pin ATmega 32U4 which is used on the Leonardo.
Summary.
This post has outlines that any 48 pin or less microcontroller from ARM and AVR families can be placed onto a small carrier pcb in such a way that the GPIO and peripherals are located in the same place. This allows the developer to rapidly switch between families or manufacturers.
More on this next time.......
However, despite it's popularity, the Arduino is showing it's age and has a few flaws. It has however shown that a simple microcontroller board combined with an IDE , an ecosystem based on shields and a strong community following is certainly one way to gain traction in a market for ever more complex products.
The 8 bit AVR at the heart of every Arduino, is a success story in itself. Conceived in the early 1990s and comercialised in partnership with Atmel in 1996, the AVR is a leader in the 8 bit microcontroller market. However, there is much competition from 32 bit micros - especially ARM, so perhaps it is time to work on a new platform, with its own ecosystem, and for the next few years, there is no reason why AVR and ARM cannot co-exist in the open hardware community.
A great YouTube about the "AVR Story"
So how would you design a better "Arduino" ? Here's some of my thoughts:
1. A smaller footprint 60 x 20mm (about 1/3rd the size of an Arduino Uno).
2. Pins on a proper 2.54mm pitch that can be easily plugged into a breadboard
3. USB as standard for VCP comms, programming and power
4. Easily identified ports - arranged by function
5. A forgiving footprint. If you plug it is backwards, you won't fry the microcontroller
6. More I/O - 32 pins, as opposed to 20
7. Higher resolution ADCs: 12bit and 16 bit available. 2 DAC channels
8. More UARTS, SPI and PWM
9. Wireless connectivity - with a choice of BLE, WiFi or low power 433/868MHz
10 Upgradable as new microcontrollers arrive in the marketplace
Many vendors sell their microcontrollers in a 44 or 48 pin surface mount package. This is nice and compact, but not easy to prototype with. So let's mount the SMT device on a carrier pcb, add a crystal and reset circuit and bring the pins out to an industry standard 40 pin DIL footprint. A mini B USB connector at one end allows the device to be plugged into a laptop for programming, communications and power.
Here's one I made earlier - ARMiGo a platform for 48 pin STM32F ARM devices:
As you can see, there's a 48 pin LQFP at the centre, a mini USB B at the right hand side and a SMT crystal. The 5 pin header on the left is for programming, using the ST Microelectronics ST-Link programmer.
Now this was based on the STM32F303, a great little ARM Cortex M4 device. But it could equally use the STM32F103, or STM32F373, or STM32F411, or even the stonking Cortex M7 - a 200MHz mcu. The great thing about the STM series of ARM devices is that once you have settled on a package size, you can move up and down the family to suit the needs of your application, as packages are fully pin compatible.
The ARMiGo was my first attempt at a generic module, and I must admit, I did not get it right first time. It was tracked out in such a way that gave maximum convenience for pcb layout - rather than in a logical manner where pins were grouped by function. The other faux pas - was my power pins were at opposite corners (common on many DIL packages). If you plug it in backwards - you fry the microcontroller.
I decided to look at the DIL package AVR devices - in particular the 40 pin ATmega1284. These parts have their power pins in the centre, and the ports are generally symmetrical. Plug it in backwards, and no damage will occur.
Here's a neat diagram to illustrate this point:
 |
| ATmega1284 - a great layout for a 40 pin DIL package
Notice how the power pins are at the centre - so if you did plug this in the wrong way it wouldn't fry - it just wouldn't run. Also, see how the ports are more or less symmetrical - at the corners of the package. The 4 ports are PA, PB, PC and PD.
Now whilst PA is exclusively for the ADC inputs, ports B, C and D are a bit of a mixture. It's a good layout, but not perfect.
So I came up with the idea of 4 generic ports, A, B, C, D - each which has a specific function.
Here's the key point of this post:
Any microcontroller, of 48 pins or less, from any manufacturer, could be fashioned onto a 40 pin carrier pcb. Regardless of the specific micro, the boards would be interchangeable.
I like to keep things simple, so here's the naming scheme:
A Analogue
B
C Communications
D Digital
Ok, Port B does not have an easy to remember name yet, but A,C and D are pretty much memorable.
Port A - 8 Channels of A-D converter
Port B - Plan B - all the pins that don't go with the flow
Port C - UART (Tx, Rx), SPI (MOSI, MISO, SCK & /CS), I2C (SCL, SDA).
Port D - General purpose digital I/O, timers, PWM etc
Port B is a bit tricky to define at the moment. In the case of the STM32F373, it would be 8 channels of 16-bit high resolution ADC, but in the case of the STM32F103 in would just be 8 consecutive pins that constitute part of GPIO PortB.
I know this is a bit of a cop-out - but bear with me.
What about AVR devices - can they be moulded into this common format?
The 32 pin LQFP ATmega328-MU certainly can be pinned out into the common format. It has 8 ADC channels to route to Port A, the UART, I2C and SPI can be routed to Port C - the communications port, and the remaining digital I/O routed to Port D.
Here's our old friend the ATmega328P-PU
As you can see, the power pins are in the centre of the package and the ports are generally arranged in the corners - not perfect, but manageable.
Here's the SMT part - the ATmega328-AU
|
This can readily be mounted on the carrier pcb and tracked out so that the various peripherals and ports appear on the correct pins. The 8 analogue inputs map to Port A. The obvious communications pins TXD, RXD, MOSI, MISO, /SS and SCK map to Port C. The PWM channels map to Port D etc.
This same philosophy could be applied t0 the 44 Pin ATmega 32U4 which is used on the Leonardo.
Summary.
This post has outlines that any 48 pin or less microcontroller from ARM and AVR families can be placed onto a small carrier pcb in such a way that the GPIO and peripherals are located in the same place. This allows the developer to rapidly switch between families or manufacturers.
More on this next time.......
Plot It - a useful graphing programme for serial data
 | ||||
| Plot It allows data to be exported in various image formats
An immensely powerful technique when developing smart sensor systems is the ability to capture data in real time from a microcontroller and save it either as a CSV file or plot it graphically.
Several open source programs are available, but the ones I have tried never seem to do exactly what I need, so it was great news when a software colleague of mine produced Plot It, and has agreed to make it widely available for hobbyists and enthusiasts.
Plot It takes in data from a serial port, by polling the microcontroller at regular intervals with a serial character as a request for data packets.
The data packets were designed to hold up to 32 bit data, and Plot It currently accepts 24 bit data - as it was intended to be used as a diagnostic tool for debugging a 24 bit ADC system.
The data packet consists of 4 data bytes - of which the most significant byte is set to zero.
Following the data bytes, a single byte represents the data channel number. This allows for up to 256 separate sensor channels. The early version of Plot It caters for just 2 channels at the moment.
Finally, there is a packet terminator consisting of the bytes 0x0D, 0x0A.
The code to send these packets from an Arduino or Nucleo is fairly simple. The microcontroller waits to see a character arrive in it's serial receive buffer, and then executes a routine that sends out the data packet.
A sketch for Arduino has been put on Github Gist - here.
Plot It currently works at 9600 baud, but can be tailored up to baudrates of 921600 baud. The 24 bit ADC system we were testing was sending packets at 20kHz (50uS) - and so we needed a super fast baud rate to get the data across quickly.
Temperature Monitoring - A Typical Application
Plot It can be used for local monitoring of sensors. One example is my Arduino based central heating controller, which reads a series of temperature values from analogue thermistor channels.
Thermistors are a fairly cheap method of measuring temperatures, and an alternative to the digital devices such as the one wire Dallas 18B20 series.
Although the Arduino ADC is just 10 bits, multiple readings can be averaged to produce a smoother data. In addition, a simple 100nF capacitor across each thermistor input is a good way of reducing analogue noise.
As a consequence, the thermistor can produce fairly high resolution data - down to about 1000th of a degree. Whilst the absolute accuracy of this measurement may only be to 1/10th of a degree, the high resolution allows minute changes in temperature trend - such as those caused by draughts etc to be analysed.
Plot It may be used to provide an insight into how quickly a room responds to having the eating turned on, or how quickly a tank of hot water cools down after heating. Seeing how these systems respond to inputs over time allows better analysis, and better control systems to be designed.
The right hand mouse button allows several features to be selected - such as auto-scaling, image export, and setting the scaling to default. The left mouse button allows drag selection of data to pan and zoom into any area of interest.
Plot It can export your data to a CSV file for further analysis in spreadsheets etc.
It is anticipated that further features will be developed in time.
|
Sunday, November 09, 2014
Using the SDcard, RTC and SRAM on WiNode and Nanode RF
This is an update of a post to the Nanode Website from October 2012.
The original is here
Nanode and Winode are something of a departure from the usual Arduino hardware, and when functioning as a pair, form a unique extension of the Arduino platform to include ethernet and low power wireless connectivity.
stringOne = String(temp_1);
stringTwo = String(temp_2);
stringThree = String(temp_3);
stringId = String(id);
The original is here
Getting to know Nanode and Winode Hardware
Part 1. Using the SD Card and RTC to make a 4 channel datalogger.
Nanode and Winode are both based on the ubiquitous ATmega328 microcontroller, but include the following common functional blocks.
1. An RFM12B low power wireless transceiver module.
2. A MCP79410 Real Time Clock. This provides RTC, two alarms, 64 bytes of battery backed RAM and 1kB of EEPROM.
3. microSD socket – accepts up to 2GB microSD cards for long term datalogging.
4. 32kB battery backed SRAM. Can be used for downloading sketches or buffering larger quantities of data from the web.
Using freely available libraries it is possible to utilise these hardware blocks, and quickly put together applications on the Nanode or Winode.
The RFM12 is connected to the SPI bus and is selected by Digital 10
The MCP97410 RTC is an I2C device using An4 and An5. It’s multipurpose output connects to Digital 3 – or Interrupt 1
The SD card is also connected to the SPI bus and is selected by Digital 4
The 23K256 SRAM is connected to the SPI bus and is selected by Digital 8 (Winode) and Digital 9 (Nanode).
In this post I will look at the operation of the SD card and the Real Time Clock.
The SD card is extremely useful for long term datalogging applications whilst the RTC, as well as providing clock and calendar functions for real time control, also provides two alarms or a square wave output which can be used to wake up the ATmega from sleep at regular intervals. The RTC also contains 64 bytes of non-volatile SRAM and 1K of EEPROM.
The SD card Library is included with the Arduino IDE. For my examples I am using Arduino IDE 1.0.1. This is an easy to use library, and if you are a newcomer I suggest Jeremy Blum’s excellent video tutorial.
This has 3 examples, how to write to the SD card, read and write and how to datalog several sensors to the SD card.
This has 3 examples, how to write to the SD card, read and write and how to datalog several sensors to the SD card.
For both the Nanode and Winode, the SD card is selected with Digital 4. You will need to modify the code to use the correct chip select line.
The MCP94710 is a powerful little chip – not just a RTC, but includes 2 independent alarms, 64 bytes of battery backed SRAM and 1024 bytes of E2. If you buy the MCP94712 version, it also includes a uniquely assigned 64 bit MAC address. These devices are available from Farnell for about £1.00. It is connected to the ATmega via the I2C bus, and so needs the Wire library to support its functionality. It has a multipurpose output which is connected to the Digital 3 (interrupt 1) input of the ATmega. This can output a squarewave to generate regular interrupts, or be triggered on either of the Alarm conditions. Please refer to the Microchip MCP9471X data sheet for full details of the internal registers.
I decided to write some code to exercise the main features of this RTC and also make use of the microSDcard for datalogging.
Before using these devices we have to include the SD card and Wire (I2C) libraries – so remember to add the #include statements at the top of the code.
#include
#include
The sketch initialises the RTC and the alarms, and then writes a 64 character text message to the battery backed SRAM.
The main loop then proceeds to log the analogue input from ADC0 to the SDcard every 5 seconds. The alarm has been configured to trigger every minute, and print out the 64 byte message to the serial terminal window, as well as illuminating the LED.
The code for this demo is available here on Github Gist.
It compiles to 18054 bytes on the ATmega328.
It compiles to 18054 bytes on the ATmega328.
This second sketch on Github Gist logs the four analogue input readings to the SD card, once per second. It compiles to 19166 bytes on the ATmega328.
The sketch sends out the current time, the value of the four analogue input channels – and once per minute, acting on an alarm it outputs the message “The Quick Brown Foxy Leapt over the Lazy Dog whilst he snoozed”.
The sketch sends out the current time, the value of the four analogue input channels – and once per minute, acting on an alarm it outputs the message “The Quick Brown Foxy Leapt over the Lazy Dog whilst he snoozed”.
I found it important to declare and reserve space for the various strings:
String dataString = ” ”;
String stringZero = ” ”;
String stringOne = ” “;
String stringTwo = ” “;
String stringThree = ” “;
String stringId = ” ”;
String stringZero = ” ”;
String stringOne = ” “;
String stringTwo = ” “;
String stringThree = ” “;
String stringId = ” ”;
And then form individual strings for the analogue readings which are then concatenated together.
int temp_0 = analogRead(0);
int temp_1 = analogRead(1);
int temp_2 = analogRead(2);
int temp_3 = analogRead(3);stringZero = String(temp_0); // Form strings from the individual ADC readings
int temp_1 = analogRead(1);
int temp_2 = analogRead(2);
int temp_3 = analogRead(3);stringZero = String(temp_0); // Form strings from the individual ADC readings
stringOne = String(temp_1);
stringTwo = String(temp_2);
stringThree = String(temp_3);
stringId = String(id);
//Create Data string for storing to SD card using the CSV Format
dataString = stringId + “, ” + stringZero + “, ” + stringOne + “, ” + stringTwo + “, ” + stringThree; // Concatenate the strings to write to the SD card
An early attempt using a different approach resulted in a memory leak which caused the ’328 to crash after about 5 writes to the SD card:
This code example will be further developed to make a real time logging, 4 channel temperature controller, as part of a central heating controller project.
The next post will combine the SDcard and RTC code example with simple 2-way wireless packet communication – allowing the temperature measurements to be send to a Nanode Gateway or other RF compatible device.
November 2014 Update.
It has been a couple of years since I wrote any code for WiNode. I got back from California and had to find myself a job, so WiNode went on the back burner for a while.
It was always the intention to make the WiNode part of an integrated system based around the JeeNode RFM12B wireless communications library. This library is popular amongst the hobbyist community and is supported by several open source devices including the emonTx, emonGLCD and Nanode Gateway produce by OpenEnergyMonitor.
The first step was to include the JeeNodes library with the code example - such that packets could be received from other RFM12B equipped nodes.
I have put together a fairly simple example of this, plus the ability to read temperature values from local thermistors connected to the ADC channels 0- 3.
This code is also available as a Github Gist
WiNode Revisited
I am currently revisiting WiNode, with the intention of designing a new version aimed specifically at central heating control applications.
This will retain the RTC and SDcard of the original, but include a mains power supply based around a small encapsulated pcb transformer and bridge rectifier, and a pair of 8A rated mains relays.
The intention is that this variant will be compatible with existing central heating controllers, providing control over hot water and central heating functions, remotely via wireless, from either a display such as the emonGLCD or via a web Gateway such as the Nanode RF.
In fact any RFM12B or RFM69 based module should be able to interact with WiNode. This opens out applications for Raspberry Pi users, and also other applications that require mains loads to be switched - such as solar hot water system pumps.
I will cover more detail of the new design in a future post.
November 2014 Update.
It has been a couple of years since I wrote any code for WiNode. I got back from California and had to find myself a job, so WiNode went on the back burner for a while.
It was always the intention to make the WiNode part of an integrated system based around the JeeNode RFM12B wireless communications library. This library is popular amongst the hobbyist community and is supported by several open source devices including the emonTx, emonGLCD and Nanode Gateway produce by OpenEnergyMonitor.
The first step was to include the JeeNodes library with the code example - such that packets could be received from other RFM12B equipped nodes.
I have put together a fairly simple example of this, plus the ability to read temperature values from local thermistors connected to the ADC channels 0- 3.
This code is also available as a Github Gist
WiNode Revisited
I am currently revisiting WiNode, with the intention of designing a new version aimed specifically at central heating control applications.
This will retain the RTC and SDcard of the original, but include a mains power supply based around a small encapsulated pcb transformer and bridge rectifier, and a pair of 8A rated mains relays.
The intention is that this variant will be compatible with existing central heating controllers, providing control over hot water and central heating functions, remotely via wireless, from either a display such as the emonGLCD or via a web Gateway such as the Nanode RF.
In fact any RFM12B or RFM69 based module should be able to interact with WiNode. This opens out applications for Raspberry Pi users, and also other applications that require mains loads to be switched - such as solar hot water system pumps.
I will cover more detail of the new design in a future post.
Saturday, May 17, 2014
Make Life Easy, Make it Modular
This is a follow on to a post I wrote back in March 2014.
As integrated circuits get smaller, and more powerful, it becomes increasingly difficult for the hobbyist to utilise them easily. Soldering tiny SMT parts is a challenge for many - so let's try to find a way to make life easier.
Why not make our microcontrollers modular - so you buy what you need that matches your application, and at a price you can afford. Unbelievably you can now buy an Arduino Nano or Pro-Mini from China, cheaper than you can buy the microcontroller IC from a Western supplier.
So if you want to quickly hack stuff together, standardised modules are one way to go.
A standard module footprint across different manufacturers.
This would really open up the competition between the various microcontroller suppliers. Whether it's PIC, TI or Atmel, they all release a reference design for a standard module, and an accompanying IDE based on a common standard, so that you can easily, and seamlessly swap between devices.
So let's speculate about a series of standardised modules, which can offer varying degrees of performance, choice of microcontroller and yet are available in a compact, breadboard friendly, dual in line (DIL) footprint. For interchangeability, the power pins, reset and uart pins need to fixed, whilst the remainder of the pins can be general purpose I/O, perhaps arranged into a row of analogue function pins on one side, and a row of digital on the other. SPI interfaces should preferably be assigned to 4 consecutive pins for convenience.
32 bit versus 8 bit.
32 bit ARM microcontrollers are now virtually the same cost as older 8 bit devices, yet offer a many fold increase in performance, as a result of their 32 bit architecture and faster clock speed. In addition to this, they come with a rich set of peripherals, making them ideal for more demanding applications.
For the hobbyist who may have first gained exposure to microcontrollers via 8 bit products such as the Arduino, the move to 32 bit may appear a little daunting. However we all have to progress and keep up with the times, so forget 8 bit and 5V logic and get into the world of 32 bit devices running at 3.3V - or less.
The Arduino shield idea was a good move to gain standardisation and traction within the Maker Community, but as we move to more powerful microcontrollers, the original shield pin-out is no longer appropriate or desirable. Perpetuating the non-standard header spacing this long after the original mistake was made is questionable.
At 68x53mm, the original Arduino form factor is starting to look a lot on the large size - particularly when you want to compact it into a small device, such as a robot. Fortunately this has been addressed, and the very compact Pro-Mini and Nano are clearly a step in the right direction.
In an ideal world we ought to be able to buy standard modules, that come in 28, 32 or 40 pin DIP packages, that offer whatever speed and resources we need. A 40 pin DIP is about the maximum convenient size, and with 35 or 36 I/O pins available it's well suited to the pin-out requirements of 48 pin microcontrollers, and offers nearly twice the I/O of the original Arduino in a footprint that is a quarter of the size. A smaller format uses a lot less pcb material, increases the density of the hardware, and allows manufacturers to focus on supplying a high-end microcontroller in a usable package,
In the Arduino world, the Pro-Mini and Nano, go some way to pin compatibility, at least they have the power pins and most of the I/O lines appearing on the same pins.
All it would take is someone to define a popular standard, and everyone else produces compatible hardware.
There will obviously be a requirement for more sophisticated boards, generally of the Raspberry Pi and BeagleBoard format, where a high-end ARM, running an operating system, is combined with external RAM, flash and a host of external peripheral interfaces. For these devices a different solution will emerge, but first let's focus on the easy stuff.
Keep it Modular - So easy to upgrade.
When your 16MHz ATmega328 module can no longer hack it, you search the suppliers for an upgrade. Do you stick with Atmel, or switch to TI, STM or Microchip? You select a module with the right footprint, Flash and RAM resources and clock frequency and do an instant upgrade. All of your existing code is easily ported to the new module.
I wanted to explore the module concept further, so set about designing my own.
Getting Started.
The plan was to make a standard plugable component, that gives users the power of a 32 bit ARM, but in an easy to use and breadboard friendly module. I reckoned that a 40 pin DIL module would be about the right format for most small projects.
I elected to use the STM32F3xx range of microcontrollers from ST Microelectronics. They have a great mix of both digital and high speed analogue ADC peripherals and are good value for money.
Initially I bought a Discovery F3 development board, which uses a 100 pin STM32F303 processor and has compass, accelerometer and gyro devices on the board. It was exceptionally good value at under $11 from Newark. However, whilst it provided a platform to get me started writing code and getting the framework to support my application built, it was just too big and the double row headers are not the friendliest of connectors to use. I didn't need all of the 80 lines of I/O provided by the 100 pin device, so I settled on the 48 pin part, offering 35 I/O lines, which was somewhat smaller, cheaper and more manageable in terms of pcb layout.
My solution was to create a 51mm x 19mm double sided pcb, which mounts the STM32F303 microcontroller, its clock and reset circuits and USB/programming connectors. This small breakout pcb, converts the pins from the 48 pin LQFP to an easier to use 40 pin dual in line module, and provide the minimum of features to get the STM32 to load and run code.
This approach is not new and has been used in minimalist products such as the Maple Mini, Teensy and the Arduino Pro Mini and Nano, all of which have been around for some time.
I decided to name the board "ARMiGo" in respect to its user friendliness and I designed the ARMiGo to be as open and flexible as possible, so that it can be used as a core for incorporation into other designs. The essential parts of that core are the microcontroller, the 8MHz crystal, the reset circuit, USB connection and programming header.
The first of the prototypes arrived this week, and now working running some simple test code.
ARMiGo uses the STM32F303 Cortex M4 ARM device which runs at a maximum of 72MHz. The pcb will also support the cheaper STM32F103 which is based on the M3 core and does not have such a rich mix of analogue peripherals.
The board is the same size as a standard 40 pin DIL format IC - making it ideal for breadboarding, and small enough to be used as a plug in module in a 40 pin socket, on a larger board.
All 35 I/O lines of the ARM chip are brought out to standard 2.54mm spaced headers.
The 5 pin right angle header on the left accepts the clock and data signals from the "ST-Link" programmer/debugger device. These are available very cheaply from ebay/taobao/deal xtreme etc.
However it is relatively simple to use the embedded STM bootloader and program it via either the mini-B USB connector on the right or via one of the USART channels.
There is a really rich mix of on-chip peripherals, particularly analogue ADCs, op amps, comparators and programmable gain apmplifiers, which gives these small ARM parts tremendous flexibility - including the following:
Full speed USB interface on chip - no need for FTDI or equivalent
4 Fast (5 Msps) 12bit ADCs, each with up to 4 input channels
4 Programmable gain op-amps and 7 comparators
2 12 bit DACs
3 USARTS
3 SPI
2 I2C
RTC with 32768 Hz oscillator and dedicated output pin for "alarm"
2 12 bit DACs
3 USARTS
3 SPI
2 I2C
RTC with 32768 Hz oscillator and dedicated output pin for "alarm"
10 timer channels, 2 basic, 6 general purpose and 2 advanced:5 General purpose 16 bit timer channels with up to 4 outputs for PWM generation, timing, counting etc.
1 general purpose 32 bit counter/timer - for optical encoder reading etc
2 advanced 16 bit timers for complimentary PWM generation etc.
In addition, the analogue section of the IC contains programmable gain op-amps and comparators which feed the ADC channels, and can be used to replace external analogue circuitry.
This small 48 pin packaged part contains 128KB of Flash and 40KB of SRAM - of which 8K can be battery backed up when the rest of the IC is powered down.
In the attached picture, most of the lower row of pins is the analogue I/O, and the upper row is mostly digital, although there are many options for allocating the peripheral functions to different pins.
With 5MHz 12 bit analogue interfaces it offers greater resolution and much faster sampling speed than Arduino. Additionally the 72MHz clock and 32bit wordsize will all make for a much faster data thoughput.
The combination of 35 I/O lines, on chip USB and a user friendly module, should make ARMiGo the starting point for a wide variety of new projects. Prototypes can now be breadboarded or easily built on stripboard, and the module just plugged straight in.
The combination of 35 I/O lines, on chip USB and a user friendly module, should make ARMiGo the starting point for a wide variety of new projects. Prototypes can now be breadboarded or easily built on stripboard, and the module just plugged straight in.
If you want more details about ARMiGo - please drop a comment. I expect to release the upated EagleCAD files shortly.
Sunday, May 11, 2014
SIMPL Revisited
SIMPL
SIMPL stands for Serial Interpreted Minimal Programming Language.
It provides a quick means of programming microcontrollers for I/O interaction, using short text strings.
What this means is that a block of code or function can be invoked by sending a single serial character. Text strings are interpreted, character by character, to produce a complex program flow.
A few characters typed in to the serial terminal can be used to set output ports, read inputs or create accurately timed, complex sequences of I/O interaction. Operations can be chained together, stored in RAM and given a single uppercase alpha identity, which when typed will execute the whole sequence of instructions.
SIMPL is an interpreted language, which although this gives a minor speed disadvantage over compiled code, is fast enough for most experimentation - but to it's advantage, massively increases interactivity with the code. Commands are easily retyped, modified and re-executed immediately, without having to go through the edit - recompile - reload process, which even on the Arduino slows down iterative development to every couple of minutes or so.
SIMPL builds up an interactive programming environment, the framework of which can be re-used from project to project, either for debugging, experimentation, or interacting with the microcontroller with the minimum of overheads.
The Arduino is essentially a serial connected device, as are many other microcontroller dev-boards, and as a simple, low overhead means of controlling the micro from a serial terminal program SIMPL provides a framework onto which more elaborate applications can be built. Blocks of code can be exercised in turn using serial commands, and debug sent to a terminal.
At the heart of SIMPL is an interpreter written in Arduino (or other microcontroller) using standard C code - for ease of portability. I have recently ported SIMPL to the 32 bit ARM STM32F407, STM32F303, and the 16 bit MSP430 in order to illustrate it's versatility.
SIMPL is an ongoing project that was inspired by Ward Cunningham's Txtzyme interpreter. If you want to learn more about Txtzyme - here's the link, and the Txtzyme Github page, where you can download the Arduino sketch version of Txtzyme. If you are new to this, it's worthwhile playing with Txtzyme, and studying the interpreter code to get a better understanding of it's operation.
For more background on SIMPL - please look at my blog posts from May 2013 onwards - starting here.
The Interpreter
At the centre of SIMPL is the interpreter, derived directly from Ward Cunningham's Txtzyme, which is just 90 lines of code. It is a series of switch/case statements contained within a loop. ASCII characters are allocated a function, which is executed by a small block of code, and then program control is returned to the main loop, to fetch the next character.
The original Txtzyme interpreter handles the following commands:
0-9 Numerical characters are enumerated to a 16 bit integer variable x
{} Code within the braces is executed repeatedly controlled by a loop counter
m A blocking delay of 1 millisecond
u A blocking delay of 1 microsecond
p Print the value contained in variable x to the serial terminal
_ _ Print the text contained within the underscores to the serial terminal
d Allocate a digital port pin
o output to the allocated port pin
i read input from the allocated port pin
s read the analogue input
k A variable which is decremented on each iteration of the loop
Txtzyme interprets a character into an action, and that action may be controlled using a single numerical 16 bit integer parameter x. It is the equivalent of passing an integer variable to a function in C code.
Numerical characters are enumerated into a 16 bit integer x. The value of x is used as a control parameter for the next instruction. For example
100{} this sets x to 100 and then repeats the commands within the braces 100 times
10m this sets up a delay of 10mS before the next instruction is executed
13d this allocates digital pin 13 as the one that will be handled by the next instruction
1o Set logic high (output) on the previously allocated pin
0o Set logic low on the allocated pin
So by combining these commands we can produce a simple LED flasher - on Arduino the LED is on digital pin 13
13d100{1o100m0o100m}
Turn the LED on, wait 100mS, turn it off, wait 100mS and repeat this 100 times.
If however you wanted a very accurate on and off time, you could incorporate the u microsecond delay command into the above.
13d100{1o100m250u0o100m350u}
This sets the on time to 100.25mS and the off time to 100.35mS
As you can see, Txtzyme used a mix of lower case alpha characters and punctuation symbols as the instructions. A Txtzyme interpreter running on any microcontroller, should be able to decode any string of these characters and produce the same overall action. This will give the language portability between microcontrollers. As there are only 26 lower case characters and 32 punctuation characters, this limits the scope of the language to something manageable. The alpha characters are chosen to act as mnemonics, so that the instructions are easy to remember. This mix of lowercase alpha and punctuation characters are known as the primitives.
Txtzyme was great and a lot of fun to use, but I wanted to extend it into a more capable language, which allowed more than just a few I/O and printing operations to be performed.
I chose to add some arithmetic operators to Txtzyme, and in doing so added a second 16-bit integer variable - called y.
Then it became obvious that the ascii strings typed in via the serial terminal could be stored in RAM, and executed at any time.
I found a simple way of allowing them to be addressed and executed, by using an upper case alpha character to act as a label to the address where the strings were stored.
This allowed the very short programs to be stored in RAM and executed just by typing a single uppercase character. These characters could be concatenated, formed into loops, or called recursively from within Txtzyme strings. Whilst only 26 of these micro-programs were available, it is sufficient to build up some quite sophisticated operations - the sort of thing that could be used for teaching programming techniques to a young audience.
With the extensions I have added to Txtzyme, the program is still only about 260 lines of C code or just over 6.1k when compiled for the Arduino.
The main loop of SIMPL consists of just 3 functions:
txtRead
txtChk
txtEval
txtRead simply reads a character from the serial input buffer.
txtChk looks at the first character to see if it is a colon : and if so, writes the remainder of the text buffer to an area of RAM, with the store address based on the value of the uppercase alpha character that follows the colon. This takes case of colon definitions.
txtEval is the heat of the interpreter. It does one of three things:
It takes each character in turn, if it is a number it forms a 16 bit integer which it stores in variable x.
If it is a lower case alpha or punctuation character, it looks it up in a switch/case structure, and executes any code associated with it.
If it is an uppercase alpha character, it transfers the attention of the interpreter to the area of RAM addressed by that character, and continues to interpret characters from there.
I have deposited this latest version of SIMPL at this Github Gist It compiles on Arduino 1.0.4.
FYI
There have been a few minimalist interpreted languages over the years, one notable example Mouse, was developed to operate within the acute memory limitations of an early minicomputer, intended for electronic music composition on a PDP-8. If you want to delve deeper - the full Mouse history is here.
SIMPL stands for Serial Interpreted Minimal Programming Language.
It provides a quick means of programming microcontrollers for I/O interaction, using short text strings.
What this means is that a block of code or function can be invoked by sending a single serial character. Text strings are interpreted, character by character, to produce a complex program flow.
A few characters typed in to the serial terminal can be used to set output ports, read inputs or create accurately timed, complex sequences of I/O interaction. Operations can be chained together, stored in RAM and given a single uppercase alpha identity, which when typed will execute the whole sequence of instructions.
SIMPL is an interpreted language, which although this gives a minor speed disadvantage over compiled code, is fast enough for most experimentation - but to it's advantage, massively increases interactivity with the code. Commands are easily retyped, modified and re-executed immediately, without having to go through the edit - recompile - reload process, which even on the Arduino slows down iterative development to every couple of minutes or so.
SIMPL builds up an interactive programming environment, the framework of which can be re-used from project to project, either for debugging, experimentation, or interacting with the microcontroller with the minimum of overheads.
The Arduino is essentially a serial connected device, as are many other microcontroller dev-boards, and as a simple, low overhead means of controlling the micro from a serial terminal program SIMPL provides a framework onto which more elaborate applications can be built. Blocks of code can be exercised in turn using serial commands, and debug sent to a terminal.
At the heart of SIMPL is an interpreter written in Arduino (or other microcontroller) using standard C code - for ease of portability. I have recently ported SIMPL to the 32 bit ARM STM32F407, STM32F303, and the 16 bit MSP430 in order to illustrate it's versatility.
SIMPL is an ongoing project that was inspired by Ward Cunningham's Txtzyme interpreter. If you want to learn more about Txtzyme - here's the link, and the Txtzyme Github page, where you can download the Arduino sketch version of Txtzyme. If you are new to this, it's worthwhile playing with Txtzyme, and studying the interpreter code to get a better understanding of it's operation.
For more background on SIMPL - please look at my blog posts from May 2013 onwards - starting here.
The Interpreter
At the centre of SIMPL is the interpreter, derived directly from Ward Cunningham's Txtzyme, which is just 90 lines of code. It is a series of switch/case statements contained within a loop. ASCII characters are allocated a function, which is executed by a small block of code, and then program control is returned to the main loop, to fetch the next character.
The original Txtzyme interpreter handles the following commands:
0-9 Numerical characters are enumerated to a 16 bit integer variable x
{} Code within the braces is executed repeatedly controlled by a loop counter
m A blocking delay of 1 millisecond
u A blocking delay of 1 microsecond
p Print the value contained in variable x to the serial terminal
_ _ Print the text contained within the underscores to the serial terminal
d Allocate a digital port pin
o output to the allocated port pin
i read input from the allocated port pin
s read the analogue input
k A variable which is decremented on each iteration of the loop
Txtzyme interprets a character into an action, and that action may be controlled using a single numerical 16 bit integer parameter x. It is the equivalent of passing an integer variable to a function in C code.
Numerical characters are enumerated into a 16 bit integer x. The value of x is used as a control parameter for the next instruction. For example
100{} this sets x to 100 and then repeats the commands within the braces 100 times
10m this sets up a delay of 10mS before the next instruction is executed
13d this allocates digital pin 13 as the one that will be handled by the next instruction
1o Set logic high (output) on the previously allocated pin
0o Set logic low on the allocated pin
So by combining these commands we can produce a simple LED flasher - on Arduino the LED is on digital pin 13
13d100{1o100m0o100m}
Turn the LED on, wait 100mS, turn it off, wait 100mS and repeat this 100 times.
If however you wanted a very accurate on and off time, you could incorporate the u microsecond delay command into the above.
13d100{1o100m250u0o100m350u}
This sets the on time to 100.25mS and the off time to 100.35mS
As you can see, Txtzyme used a mix of lower case alpha characters and punctuation symbols as the instructions. A Txtzyme interpreter running on any microcontroller, should be able to decode any string of these characters and produce the same overall action. This will give the language portability between microcontrollers. As there are only 26 lower case characters and 32 punctuation characters, this limits the scope of the language to something manageable. The alpha characters are chosen to act as mnemonics, so that the instructions are easy to remember. This mix of lowercase alpha and punctuation characters are known as the primitives.
Txtzyme was great and a lot of fun to use, but I wanted to extend it into a more capable language, which allowed more than just a few I/O and printing operations to be performed.
I chose to add some arithmetic operators to Txtzyme, and in doing so added a second 16-bit integer variable - called y.
Then it became obvious that the ascii strings typed in via the serial terminal could be stored in RAM, and executed at any time.
I found a simple way of allowing them to be addressed and executed, by using an upper case alpha character to act as a label to the address where the strings were stored.
This allowed the very short programs to be stored in RAM and executed just by typing a single uppercase character. These characters could be concatenated, formed into loops, or called recursively from within Txtzyme strings. Whilst only 26 of these micro-programs were available, it is sufficient to build up some quite sophisticated operations - the sort of thing that could be used for teaching programming techniques to a young audience.
With the extensions I have added to Txtzyme, the program is still only about 260 lines of C code or just over 6.1k when compiled for the Arduino.
The main loop of SIMPL consists of just 3 functions:
txtRead
txtChk
txtEval
txtRead simply reads a character from the serial input buffer.
txtChk looks at the first character to see if it is a colon : and if so, writes the remainder of the text buffer to an area of RAM, with the store address based on the value of the uppercase alpha character that follows the colon. This takes case of colon definitions.
txtEval is the heat of the interpreter. It does one of three things:
It takes each character in turn, if it is a number it forms a 16 bit integer which it stores in variable x.
If it is a lower case alpha or punctuation character, it looks it up in a switch/case structure, and executes any code associated with it.
If it is an uppercase alpha character, it transfers the attention of the interpreter to the area of RAM addressed by that character, and continues to interpret characters from there.
I have deposited this latest version of SIMPL at this Github Gist It compiles on Arduino 1.0.4.
FYI
There have been a few minimalist interpreted languages over the years, one notable example Mouse, was developed to operate within the acute memory limitations of an early minicomputer, intended for electronic music composition on a PDP-8. If you want to delve deeper - the full Mouse history is here.
Monday, May 05, 2014
A little more shifty....
Recap
In the previous post, I quickly reviewed the techniques for interfacing shift registers to Arduino based hardware and highlighted some simple code for reading and writing to the external shift registers.
Whilst to some, this may have appeared to be a whistle-stop tour, there is however a wealth of similar information available online and I felt that it would have been of little overall value just repeating the excellent examples and documentation provided by others.
Instead I wanted to get something up and running quickly which would extend the Arduino and act as the basis of a variety of projects, requiring additional input output devices such as LEDs, switches, and actuators such as stepper motors and hobby servos.
I am using the SIMPL language to control the shift registers. If you have not come across SIMPL yet - please see my related blog post, and those going back to May of 2013.
Output to Shift Registers
With my recent experiments with shift registers, I wanted to send a 16 bit word out to a pair of output shift registers to selectively illuminate an array of LEDs.
In SIMPL, I chose the lower case ascii character "r" to represent this output to register function using the following Arduino code:
case 'r': // Send an 16 bit byte to the shift register using shiftOut
PORTB &= ~_BV(0);
shiftOut(dataPin, clockPin, MSBFIRST, x,8); // shift out the high bits:
shiftOut(dataPin, clockPin, MSBFIRST, x); // shift out the low bits:
PORTB |= _BV(0);
break;
To use this function, you need to supply the 16 bit integer x immediately preceding the r character,
so 0r will turn off all the LEDs and 65535r will turn them all on.
Light Chasers
These are very simple to set up just by turning on the LEDs in a sequence. SIMPL is ideal for this.
We have a SIMPL command "r" which does a 16 bit write to the pair of shift registers.
128r will turn on LED 7, 64r will turn on LED 6 and so on. We can use the millisecond command m, to keep the LEDs lit for, say 100mS.
128r100m64r100m and so on.
So let's define a LED sequence that counts down from the left - ie moves to the Right. We do this using the colon to start a definition - called R
:R 128r100m64r100m32r100m16r100m8r100m4r100m2r100m1r100m
And similarly a LED sequence that moves to the Left
:L 1r100m2r100m4r100m8r100m16r100m32r100m64r100m128r100
Now you can use L and R to make chase sequences
10{LR} - 10 iterations of the Left-right chaser sequence
Stepper Motors
From creating a moving light chaser display, it is a very simple step to controlling the motion of a stepper motor. Rather than turning the LEDs on in a sequence, it is simply a matter of energising the windings of the stepper motor in the correct sequence.
The hardware we will use is available cheaply on ebay, and consists of a small unipolar 5V stepper motor with 64:1 reduction gearbox, and a small circuit board that contains a power driver IC (ULN2003) and usually 4 LEDs.
The stepper motor coils are energised in the following sequence for forwards motion. This sequence of 8 steps is known as a half step sequence :
1
1 and 2
2
2 and 3
3
3 and 4
4
4 and 1
So let's code these into a number sequence that can be sent to the shift register and driver.
1
3
2
6
4
12
8
9
Now let's define a Pause statement, so that we don't have to keep changing the 100m delay when we want to change speed. 100mS may be OK for testing, so as you can see what is going on, but for the real miniature stepper motors, this delay should only be about 1mS.
:P 1m
Now let's code these numbers into definitions F, for Forwards and B for Backwards
:F 1rP3rP2rP6rP4rP12rP8rP9rP
:B 9rP8rP12rP4rP6rP2rP3rP1rP
So we can now use a sequence of F or B to provide forwards or backwards motion
512{F} will produce one complete turn of the motor shaft, because there are 512 steps to a full rotation of the gearbox shaft, and each iteration of "F" produces 4 steps.
At the end of each sequence t might be wise to send a 0r - in order to turn off all of the windings whilst the stepper is idle.
There are other sequences of coil energisation, which are used, sometimes when more torque is needed. A useful link here.
Input from Shift Registers
To complement the output command q, I wrote a short function to read the input shift registers. Command "t" is used to test the input registers and put the resultant value into x.
In order to display the value x, you need the print command p. So the following construct was used
tp test the input register and print the value to the serial monitor
tq test the input register and display the value on the output LEDs
The code behind the "t" function is as follows:
case 't': // test the inputs from 74HC165 shift registers
digitalWrite(loadPin, LOW);
digitalWrite(loadPin, HIGH);
x = shiftIn(sinPin, sclkPin, MSBFIRST); // Read incoming word from 74HC165
digitalWrite(sclkPin,HIGH);
break;
In the next part, I'll be looking at the high power TPIC6B595 and using it to control a pair of stepper motors using SIMPL.
In the previous post, I quickly reviewed the techniques for interfacing shift registers to Arduino based hardware and highlighted some simple code for reading and writing to the external shift registers.
Whilst to some, this may have appeared to be a whistle-stop tour, there is however a wealth of similar information available online and I felt that it would have been of little overall value just repeating the excellent examples and documentation provided by others.
Instead I wanted to get something up and running quickly which would extend the Arduino and act as the basis of a variety of projects, requiring additional input output devices such as LEDs, switches, and actuators such as stepper motors and hobby servos.
I am using the SIMPL language to control the shift registers. If you have not come across SIMPL yet - please see my related blog post, and those going back to May of 2013.
Output to Shift Registers
With my recent experiments with shift registers, I wanted to send a 16 bit word out to a pair of output shift registers to selectively illuminate an array of LEDs.
In SIMPL, I chose the lower case ascii character "r" to represent this output to register function using the following Arduino code:
case 'r': // Send an 16 bit byte to the shift register using shiftOut
PORTB &= ~_BV(0);
shiftOut(dataPin, clockPin, MSBFIRST, x,8); // shift out the high bits:
shiftOut(dataPin, clockPin, MSBFIRST, x); // shift out the low bits:
PORTB |= _BV(0);
break;
To use this function, you need to supply the 16 bit integer x immediately preceding the r character,
so 0r will turn off all the LEDs and 65535r will turn them all on.
Light Chasers
These are very simple to set up just by turning on the LEDs in a sequence. SIMPL is ideal for this.
We have a SIMPL command "r" which does a 16 bit write to the pair of shift registers.
128r will turn on LED 7, 64r will turn on LED 6 and so on. We can use the millisecond command m, to keep the LEDs lit for, say 100mS.
128r100m64r100m and so on.
So let's define a LED sequence that counts down from the left - ie moves to the Right. We do this using the colon to start a definition - called R
:R 128r100m64r100m32r100m16r100m8r100m4r100m2r100m1r100m
And similarly a LED sequence that moves to the Left
:L 1r100m2r100m4r100m8r100m16r100m32r100m64r100m128r100
Now you can use L and R to make chase sequences
10{LR} - 10 iterations of the Left-right chaser sequence
Stepper Motors
From creating a moving light chaser display, it is a very simple step to controlling the motion of a stepper motor. Rather than turning the LEDs on in a sequence, it is simply a matter of energising the windings of the stepper motor in the correct sequence.
The hardware we will use is available cheaply on ebay, and consists of a small unipolar 5V stepper motor with 64:1 reduction gearbox, and a small circuit board that contains a power driver IC (ULN2003) and usually 4 LEDs.
The stepper motor coils are energised in the following sequence for forwards motion. This sequence of 8 steps is known as a half step sequence :
1
1 and 2
2
2 and 3
3
3 and 4
4
4 and 1
So let's code these into a number sequence that can be sent to the shift register and driver.
1
3
2
6
4
12
8
9
Now let's define a Pause statement, so that we don't have to keep changing the 100m delay when we want to change speed. 100mS may be OK for testing, so as you can see what is going on, but for the real miniature stepper motors, this delay should only be about 1mS.
:P 1m
Now let's code these numbers into definitions F, for Forwards and B for Backwards
:F 1rP3rP2rP6rP4rP12rP8rP9rP
:B 9rP8rP12rP4rP6rP2rP3rP1rP
So we can now use a sequence of F or B to provide forwards or backwards motion
512{F} will produce one complete turn of the motor shaft, because there are 512 steps to a full rotation of the gearbox shaft, and each iteration of "F" produces 4 steps.
At the end of each sequence t might be wise to send a 0r - in order to turn off all of the windings whilst the stepper is idle.
There are other sequences of coil energisation, which are used, sometimes when more torque is needed. A useful link here.
Input from Shift Registers
To complement the output command q, I wrote a short function to read the input shift registers. Command "t" is used to test the input registers and put the resultant value into x.
In order to display the value x, you need the print command p. So the following construct was used
tp test the input register and print the value to the serial monitor
tq test the input register and display the value on the output LEDs
The code behind the "t" function is as follows:
case 't': // test the inputs from 74HC165 shift registers
digitalWrite(loadPin, LOW);
digitalWrite(loadPin, HIGH);
x = shiftIn(sinPin, sclkPin, MSBFIRST); // Read incoming word from 74HC165
digitalWrite(sclkPin,HIGH);
break;
In the next part, I'll be looking at the high power TPIC6B595 and using it to control a pair of stepper motors using SIMPL.
Subscribe to:
Posts (Atom)