t r o n i x s t u f f

fun and learning with electronics

First look: Arduino Due

Updated 27/02/2013

Introduction

After much waiting the Arduino Due has been released, so let’s check it out. We’ll run through the specifications and some areas of interest, see what’s different, some random notes – then try out some of the new features. Before moving forward note that it might look the same - the Due is not a drop-in replacement for older boards – even the Mega2560. It’s different.

First announced in late 2011, the Due is the Arduino team’s first board with a 32-bit processor – the Atmel SAM3X8E ARM Cortex-M3 CPU. With an 84 Mhz CPU speed and a host of interfaces and I/O, this promises to be the fastest and most functional Arduino board ever. According to the official Arduino press release:

Arduino Due is ideal for those who want to build projects that require high computing power such as the remotely-controlled drones that, in order to fly, need to process a lot of sensor data per second.
Arduino Due gives students the opportunity to learn the inner workings of the ARM processor in a cheaper and much simpler way than before.
To Scientific projects, which need to acquire data quickly and accurately, Arduino Due provides a platform to create open source tools that are much more advanced than those available now.
The new platform enables the open source digital fabrication community (3d Printers, Laser cutters, CNC milling machines) to achieve higher resolutions and faster speed with fewer components than in the past.

Sounds good – and the Due has been a long time coming, so let’s hope it is worth the wait. The SAM3X CPU holds a lot of promise for more complex projects that weren’t possible with previous ATmega CPUs, so this can be only a good thing.

Specifications

First of all, here’s the Due in detail – top and bottom (click to enlarge):

You can use Mega-sized protoshields without any problem (however older shields may miss out on the upper I2C pins) – they’ll physically fit in … however their contents will be a different story:

The specifications of the Due are as follows (from Arduino website):

Microcontroller AT91SAM3X8E
Operating Voltage 3.3V
Input Voltage (recommended) 7-12V
Input Voltage (limits) 6-20V
Digital I/O Pins 54 (of which 12 provide PWM output)
Analog Input Pins 12
Analog Outputs Pins 2 (DAC)
Total DC Output Current on all I/O lines 130 mA
DC Current for 3.3V Pin 800 mA
DC Current for 5V Pin 800 mA
Flash Memory 512 KB all available for the user applications
SRAM 96 KB (two banks: 64KB and 32KB)
Clock Speed 84 MHz

Right away a few things should stand out – the first being the operating voltage – 3.3V. That means all your I/O needs to work with 3.3V – not 5V. Don’t feed 5V logic line into a digital input pin and hope it will work – you’ll damage the board. Instead, get yourself some logic level converters. However there is an IOREF pin like other Arduino boards which intelligent shields can read to determine the board voltage. The total output current for all I/O lines is also 130 mA … so no more sourcing 20mA from a digital ouput for those bright LEDs.

The power regulator for 5V has been changed from linear to switching – so no more directly inserting 5V into the 5V pin. However the 3.3V is through an LDO from 5v.

Each digital I/O pin can source 3 or 15 mA – or sink 6 or 9 mA … depending on the pin. High-current pins are CAN-TX, digital 1, 3~12, 23~51, and SDA1. The rest are low current. And there’s still an LED on digital 13. You will need to redesign any existing projects or shields if moving to the Due.

The analogue inputs now have a greater resolution – 12-bits. That means it can return a value of  0~4095 representing 0~3.3V DC. To activate this higher resolution you need to use the function analogReadResolution(12).

Memory – there isn’t any EEPROM in the SAM3X – so you’ll need external EEPROMs to take care of more permanent storage. However there’s 512 KB of flash memory for sketches – which is huge. You have to see it to believe it:

Excellent. A new feature is the onboard erase button. Press it for three seconds and it wipes out the sketch. The traditional serial line is still digital 0/1 – which connect to the USB controller chip.

Hardware serial – there’s four serial lines. Pulse-width modulation (PWM) is still 8-bit and on digital pins 2~13.

The SPI bus is on the ICSP header pins to the right of the microcontroller – so existing shields that use SPI will need to be modified – or experiment with a LeoShield:

You can also use the extended SPI function of the SAM3X which allow the use of digital pins 4, 10 or 52 for CS (chip select).

The SAM3X supports the automtive CAN bus, and the pins have been brought out onto the stacked header connectors – however this isn’t supported yet in the IDE.

There are two I2C buses – located on digital 20/21 and the second is next to AREF just like on the Leonardo.

There’s a 10-pin JTAG mini-header on the Due, debug pins and a second ICSP for the ATmega16U2 which takes care of USB. Speaking of USB – there’s two microUSB sockets. One is for regular programming via the Arduino IDE and the USB interface, the other is a direct native USB programming port direct to the SAM3X.

The SAM3X natively supports Ethernet, but this hasn’t been implemented on the hardware side for the Due. However some people in the Arduino forum might have a way around that.

Using the Due

First of all – at the time of writing – you need to install Arduino IDE v1.5.1 release 2 – a beta version. Windows users – don’t forget the USB drivers. As always, backup your existing installation and sketch files somewhere safe – and you can run more than one IDE on the same machine.

When it comes time to upload your sketches, plug the USB cable into the lower socket on the Due – and select Arduino Due (Programming Port) from the Tools>Board menu in the IDE.

Let’s upload a sketch now (download) – written by Steve Curd from the Arduino forum. It calculates Newton Approximation for pi using an infinite series. As you can see from the results below, the Due is much faster (690 ms) than the Mega2560 (5765 ms). Click the image to enlarge:


Next, let’s give the digital-to-analogue converters a test. Finally we have two, real, 12-bit DACs with the output pins being … DAC0 and DAC1. No more mucking about with external R-C filters to get some audio happening. These pins provides true analogue outputs which is controlled by the analogWrite() function. To use them is very simple – consider the following example sketch which creates a triangle wave:

void setup() 
{
 analogWriteResolution(12); // 12-bit!
}
void loop() 
{
 for(int x=0; x<4096; x++) 
 {
 analogWrite(DAC0, x); // use DAC1 for ... DAC1
 }
 for(int x=4095; x>=0; --x) 
 {
 analogWrite(DAC0, x);
 }
}

And the results from the DSO (click image to enlarge):

This opens up all sorts of audio possibilities. With appropriate wavetable data saved in memory you could create various effects. However the DAC doesn’t give a full 0~3.3V output – instead it’s 1/6 to 5/6 of the Aref voltage. With the IDE there are example sketches that can play a .wav file from an SDcard – however I’d still be more inclined to use an external shield for that. Nevertheless for more information, have a look at the Audio library. Furthermore, take heed of the user experiences noted in the Arduino forum – it’s very easy to destroy your DAC outputs. In the future we look forward to experimenting further with the Due – so stay tuned.

Getting a Due

Good luck … at the time of writing – the Dues seem to be very thin on the ground. This may partly be due to the limited availability of the Atmel SAM3X8E. My contacts in various suppliers say volumes are quite limited.

Quality

I really hope this is a rare event, however one of the Dues received had the following fault in manufacturing:

One side of the crystal capacitor wasn’t in contact with the PCB. However this was a simple fix. How the QC people missed this … I don’t know. However I’ve seen a few Arduinos of various types, and this error is not indicative of the general quality of Arduino products.

Where to from here?

Visit the official Arduino Due page, the Due discussion section of the Arduino forum, and check out the reference guide for changes to functions that are affected by the different hardware.

Conclusion

Well that’s my first take on the Due – powerful and different. You will need to redesign existing projects, or build new projects around it. And a lot of stuff on the software side is still in beta. So review the Due forum before making any decisions. With that in mind – from a hardware perspective – it’s a great step-up from the Mega2560.

So if you’re interested – get one and take it for a spin, it won’t disappoint. The software will mature over time which will make life easier as well. If you have any questions (apart from Arduino vs. Raspberry Pi) leave a comment and we’ll look into it.

Have fun and keep checking into tronixstuff.com. Why not follow things on twitterGoogle+, subscribe  for email updates or RSS using the links on the right-hand column, or join our Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.

February 8, 2013 Posted by | arduino, arm cortex, AT91SAM3X8E, dev-11589, due, part review, review, SAM3X8E, tutorial | , , , , , , , , , , , , , , , , , , , , | 6 Comments

Tutorial: Analog input for multiple buttons – Part Two

This is chapter forty-six of a series originally titled “Getting Started/Moving Forward with Arduino!” by John Boxall – A tutorial on the Arduino universe. The first chapter is here, the complete series is detailed here.

[Updated 19/01/2013]

A while back I described how to read multiple buttons using only one analogue input pin. However we could only read one button at a time. In this instalment we revisit this topic and examine an improved method of doing so which allows for detecting more than one button being pressed at the same time. This method is being demonstrated as it is inexpensive and very easy to configure.

(For a more exact and expensive method please consider the use of the Microchip MCP23017 which allows for sixteen inputs via the I2C bus).

As you know the analogue input pins of the Arduino can read a voltage of between zero and five volts DC and return this measurement as an integer between zero and 1023. Using a small external circuit called a “R-2R ladder”, we can alter the voltage being measured by the analogue pin by diverting the current through one or more resistors by our multiple buttons. Each combination of buttons theoretically will cause a unique voltage to be measured, which we can then interpret in our Arduino sketch and make decisions based on the button(s) pressed.

First the circuit containing four buttons:

Can you see why this is called an R-2R circuit? When building your circuit – use 1% tolerance resistors – and check them with a multimeter to be sure. As always, test and experiment before committing to anything permanent.

Now to determine a method for detecting each button pressed, and also combinations. When each button is closed, the voltage applied to analogue pin zero will be different. And if two buttons are pressed at once, the voltage again will be different. Therefore the value returned by the function analogRead() will vary for each button-press combination. To determine these, I connected a numeric display to my Arduino-compatible board, then simply sent the analogRead() value to the display. You can see some of the results of this in the following video:

The analogRead() results of pressing every combination of button can be found in the following table:

After this experiment we now have the values returned by analogRead() and can use them in a switch… case function or other decision-making functions in our sketches to read button(s) and make decisions based on the user input. Unfortunately there was some overlap with the returned values and therefore in some cases not every possible combination of press will be available.

However, we’re still doing well and you can get at least eleven or twelve combinations still with only one analog input pin. You can add delay() functions in your sketch if necessary to take care of switch debouncing or do it with hardware if you feel it is necessary.

So now you have a more useful method for receiving input via buttons without wasting many digital input pins. I hope you found this article useful or at least interesting. This series of tutorials has been going for almost two years now, and may soon start to wind down – it’s time to move forward to the next series of tutorials :)

So if you have any suggestions for further articles (and not thinly-veiled methods of asking me to do your work for you…) – email them to john at tronixstuff dot com.

Have fun and keep checking into tronixstuff.com. Why not follow things on twitterGoogle+, subscribe  for email updates or RSS using the links on the right-hand column, or join our Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.

February 29, 2012 Posted by | arduino, education, electronics, learning electronics | , , , , , , , , , , , , , , , , , | 7 Comments

Tutorial: Arduino and the SPI bus part II

This is chapter thirty-six of a series originally titled “Getting Started/Moving Forward with Arduino!” by John Boxall – A seemingly endless series of articles on the Arduino universe. The first chapter is here, the complete series is detailed here

[Updated 10/01/2013]

This is the second of several chapters in which we are investigating the SPI data bus, and how we can control devices using it with our Arduino systems. If you have not done so already, please read part one of the SPI articles. Again we will learn the necessary theory, and then apply it by controlling a variety of devices. As always things will be kept as simple as possible.

First on our list today is the use of multiple SPI devices on the single bus. We briefly touched on this in part one, by showing how multiple devices are wired, for example:

Notice how the slave devices share the clock, MOSI and MISO lines – however they both have their own chip select line back to the master device. At this point a limitation of the SPI bus becomes prevalent – for each slave device we need another digital pin to control chip select for that device. If you were looking to control many devices, it would be better to consider finding I2C solutions to the problem. To implement multiple devices is very easy. Consider the example 34.1 from part one – we controlled a digital rheostat. Now we will repeat the example, but instead control four instead of one. For reference, here is the pinout diagram:

Doing so may sound complex, but it is not. We connect the SCK, MOSI and  MISO pins together, then to Arduino pins D13, D11, D12 respectively. Each CS pin is wired to a separate Arduino digital pin. In our example rheostats 1 to 4 connect to D10 through to D7 respectively. To show the resistance is changing on each rheostat, there is an LED between pin 5 and GND and a 470 ohm resistor between 5V and pin 6. Next, here is the sketch (download):

Example 36.1

/*
 Example 36.1 - Multiple SPI bus device demo using four Microchip MCP4162s [http://bit.ly/iwDmnd]
 http://tronixstuff.com/tutorials > chapter 36 | CC by-sa-nc | John Boxall
*/

#include "SPI.h" // necessary library
int del=3; // used for various delays

int led1=10; // CS lines for each SPI device
int led2=9;
int led3=8;
int led4=7;

void setup()
{
  pinMode(led1, OUTPUT);
  pinMode(led2, OUTPUT);
  pinMode(led3, OUTPUT);
  pinMode(led4, OUTPUT);
  digitalWrite(led1, HIGH);
  digitalWrite(led2, HIGH);
  digitalWrite(led3, HIGH);
  digitalWrite(led4, HIGH);
  SPI.begin(); // wake up the SPI bus.
  SPI.setBitOrder(MSBFIRST);
  // our MCP4162s requires data to be sent MSB (most significant byte) first
}

void setValue(int l, int value)
// sends value 'value' to SPI device on CS digital out pin 'l'
{
  digitalWrite(l, LOW);
  SPI.transfer(0); // send command byte
  SPI.transfer(value); // send value (0~255)
  digitalWrite(l, HIGH);
}

void allOff()
// sets all pots to max resistance
{
     setValue(led1,255);
     setValue(led2,255);
     setValue(led3,255);
     setValue(led4,255);
}

void pulse(int l)
{
  allOff();
  for (int a=255; a>=0; --a)
  {
    setValue(l,a);
    delay(del);
  }
  for (int a=0; a<256; a++)
  {
    setValue(l,a);
    delay(del);
  }
}

void pulseAll()
{
  allOff();
  for (int a=255; a>=0; --a)
  {
    setValue(led1,a);
    setValue(led2,a);
    setValue(led3,a);
    setValue(led4,a);
    delay(del);
  }
  for (int a=0; a<256; a++)
  {
    setValue(led1,a);
    setValue(led2,a);
    setValue(led3,a);
    setValue(led4,a);
    delay(del);
  }
}

void loop()
{
  pulse(led1);
  pulse(led2);
  pulse(led3);
  pulse(led4);
  pulseAll();
}

Although the example sketch may be longer than necessary, it is quite simple. We have four SPI devices each controlling one LED, so to keep things easy to track we have defined led1~led4 to match the chip select digital out pins used for each SPI device. Then see the first four lines in void setup(); these pins are set to output in order to function as required. Next – this is very important – we set the pins’ state to HIGH. You must do this to every chip select line! Otherwise more than one CS pins may be initially low in some instances and cause the first data sent from MOSI to travel along to two or more SPI devices. With LEDs this may not be an issue, but for motor controllers … well it could be.

The other point of interest is the function

void setValue(int l, int value)

We pass the value for the SPI device we want to control, and the value to send to the device. The value for l is the chip select value for the SPI device to control, and ranges from 10~7 – or as defined earlier, led1~4. The rest of the sketch is involved in controlling the LED’s brightness by varying the resistance of the rheostats. Now to see example 36.1 in action via the following video clip:


(If you are wondering what I have done to the Freetronics board in that video, it was to add a DS1307 real-time clock IC in the prototyping section).

Next on the agenda is a digital-to-analogue converter, to be referred to using the acronym DAC. What is a DAC? In simple terms, it accepts a numerical value between zero and a maximum value (digital) and outputs a voltage between the range of zero and a maximum relative to the input value (analogue). One could consider this to be the opposite of the what we use the function analogRead(); for. For our example we will use a Microchip MCP4921 (data sheet.pdf):

(Please note that this is a beginners’ tutorial and is somewhat simplified). This DAC has a 12-bit resolution. This means that it can accept a decimal number between 0 and 4095 – in binary this is 0 to 1111 1111 1111 (see why it is called 12-bit) – and the outpout voltage is divided into 4096 steps. The output voltage for this particular DAC can fall between 0 and just under the supply voltage (5V). So for each increase of 1 in the decimal input value, the DAC will output around 1.221 millivolts.

It is also possible to reduce the size of the voltage output steps by using a lower reference voltage. Then the DAC will consider the reference voltage to be the maximum output with a value of 4095. So (for example) if the reference voltage was 2.5V, each increase of 1 in the decimal input value, the DAC will output around 0.6105 millivolts. The minimum reference voltage possible is 0.8V, which offers a step of 200 microvolts (uV).

The output of a DAC can be used for many things, such as a function generator or the playback of audio recorded in a digital form. For now we will examine how to use the hardware, and monitoring output on an oscilloscope. First we need the pinouts:

By now these sorts of diagrams shouldn’t present any problems. In this example, we keep pin 5 permanently set to GND; pin 6 is where you feed in the reference voltage – we will set this to +5V; AVss is GND; and Vouta is the output signal pin – where the magic comes from :) The next thing to investigate is the MCP4921′s write command register:

Bits 0 to 11 are the 12 bits of the output value; bit 15 is an output selector (unused on the MPC4921); bit 14 controls the input buffer; bit 13 controls an inbuilt output amplifier; and bit 12 can shutdown the DAC. Unlike previous devices, the input data is spread across two bytes (or a word of data). Therefore a small amount of work needs to be done to format the data ready for the DAC. Let’s explain this through looking at the sketch for example 36.2 that follows. The purpose of the sketch is to go through all possible DAC values, from 0 to 4095, then back to 0 and so on.

First. note the variable outputvalue - it is a word, a 16-bit unsigned variable. This is perfect as we will be sending a word of data to the DAC. We put the increasing/decreasing value for a into outputValue. However as we can only send bytes of data at a time down the SPI bus, we will use the function highbyte() to separate the high side of the word (bits 15~8) into a byte variable called data.

We then use the bitwise AND and OR operators to set the parameter bits 15~12. Then this byte is sent to the SPI bus. Finally, the function lowbyte() is used to send the low side of the word (bits 7~0) into data and thence down the SPI bus as well.

Now for our demonstration sketch (download):

Example 36.2

/*
 Example 36.2 - SPI bus device demo using a Microchip MCP4921 DAC [http://bit.ly/j3TSak]
 http://tronixstuff.com/tutorials > chapter 36 | CC by-sa-nc | John Boxall
 */

#include "SPI.h" // necessary library
int del=0; // used for various delays
word outputValue = 0; // a word is a 16-bit number
byte data = 0; // and a byte is an 8-bit number
void setup()
{
  //set pin(s) to input and output
  pinMode(10, OUTPUT);
  SPI.begin(); // wake up the SPI bus.
  SPI.setBitOrder(MSBFIRST);
}

void loop()
{
  for (int a=0; a<=4095; a++)
  {
    outputValue = a;
    digitalWrite(10, LOW);
    data = highByte(outputValue);
    data = 0b00001111 & data;
    data = 0b00110000 | data;
    SPI.transfer(data);
    data = lowByte(outputValue);
    SPI.transfer(data);
    digitalWrite(10, HIGH);
    delay(del);
  }
  delay(del+25);
  for (int a=4095; a>=0; --a)
  {
    outputValue = a;
    digitalWrite(10, LOW);
    data = highByte(outputValue);
    data = 0b00001111 & data;
    data = 0b00110000 | data;
    SPI.transfer(data);
    data = lowByte(outputValue);
    SPI.transfer(data);
    digitalWrite(10, HIGH);
    delay(del);
  }
  delay(del+25);
}

And a quick look at the DAC in action via an oscilloscope:

By now we have covered in detail how to send data to a device on the SPI bus. But how do we receive data from a device?

Doing so is quite simple, but some information is required about the particular device. For the rest of this chapter, we will use the Maxim DS3234 ”extremely accurate” real-time clock. Please download the data sheet (.pdf) now, as it will be referred to many times.

The DS3234 is not available in through-hole packaging, so we will be using one that comes pre-soldered onto a very convenient breakout board:

It only takes a few moments to solder in some header pins for breadboard use. The battery type is CR1220 (12 x 2.0mm, 3V); if you don’t have a battery you will need to short out the battery holder with some wire otherwise the IC will not work. Readers have reported that the IC doesn’t keep time if the USB and external power are both applied to the Arduino at the same time.

A device will have one or more registers where information is read from and written to. Look at page twelve of the DS3234 data sheet, there are twenty-three registers, each containing eight bits (one byte) of data. Please take note that each register has a read and write address. An example – to retrieve the contents of the register at location 08h (alarm minutes) and place it into the byte data we need to do the following:

  digitalWrite(10, LOW); // select the DS3234 that has its CS line on digital 10
  SPI.transfer(0x08); // tell the DS3234 device we're requesting data from the register at 08h
  data=SPI.transfer(0); // the DS3234 sends the data back and stores it in the byte data
  digitalWrite(10, HIGH);  // deselect the DS3234 if finished with it

Don’t forget to take note of  the function SPI.setBitOrder(MSBFIRST); in your sketch, as this also determines the bit order of the data coming from the device.

To write data to a specific address is also quite simple, for example:

digitalWrite(10, LOW);
SPI.transfer(0x80); // tells the device which address to write to
SPI.transfer(b00001010);   // you can send any representation of a byte
digitalWrite(10, HIGH);

Up to this point, we have not concerned ourselves with what is called the SPI data mode. The mode determines how the SPI device interprets the ‘pulses’ of data going in and out of the device. For a well-defined explanation, please read this article. With some devices (and in our forthcoming example) the data mode needs to be defined. So we use:

SPI.setDataMode(SPI_MODE1);

to set the data mode, within void(setup);. To determine a device’s data mode, as always – consult the data sheet. With our DS3234 example, the mode is mentioned on page 1 under Features List.

Finally, let’s delve a little deeper into SPI via the DS3234. The interesting people at Sparkfun have already written a good demonstration sketch for the DS3234, so let’s have a look at that and deconstruct it a little to see what is going on. You can download the sketch below from here, then change the file extension from .c to .pde.

#include "SPI.h"
const int  cs=8; //chip select 

void setup() {
  Serial.begin(9600);
  RTC_init();
  //day(1-31), month(1-12), year(0-99), hour(0-23), minute(0-59), second(0-59)
  SetTimeDate(11,12,13,14,15,16);
}

void loop() {
  Serial.println(ReadTimeDate());
  delay(1000);
}
//=====================================
int RTC_init(){
	  pinMode(cs,OUTPUT); // chip select
	  // start the SPI library:
	  SPI.begin();
	  SPI.setBitOrder(MSBFIRST);
	  SPI.setDataMode(SPI_MODE1); // both mode 1 & 3 should work
	  //set control register
	  digitalWrite(cs, LOW);
	  SPI.transfer(0x8E);
	  SPI.transfer(0x60); //60= disable Osciallator and Battery SQ wave @1hz, temp compensation, Alarms disabled
	  digitalWrite(cs, HIGH);
	  delay(10);
}
//=====================================
int SetTimeDate(int d, int mo, int y, int h, int mi, int s){
	int TimeDate [7]={s,mi,h,0,d,mo,y};
	for(int i=0; i<=6;i++){
		if(i==3)
			i++;
		int b= TimeDate[i]/10;
		int a= TimeDate[i]-b*10;
		if(i==2){
			if (b==2)
				b=B00000010;
			else if (b==1)
				b=B00000001;
		}
		TimeDate[i]= a+(b<<4);

		digitalWrite(cs, LOW);
		SPI.transfer(i+0x80);
		SPI.transfer(TimeDate[i]);
		digitalWrite(cs, HIGH);
  }
}
//=====================================
String ReadTimeDate(){
	String temp;
	int TimeDate [7]; //second,minute,hour,null,day,month,year
	for(int i=0; i<=6;i++){
		if(i==3)
			i++;
		digitalWrite(cs, LOW);
		SPI.transfer(i+0x00);
		unsigned int n = SPI.transfer(0x00);
		digitalWrite(cs, HIGH);
		int a=n & B00001111;
		if(i==2){
			int b=(n & B00110000)>>4; //24 hour mode
			if(b==B00000010)
				b=20;
			else if(b==B00000001)
				b=10;
			TimeDate[i]=a+b;
		}
		else if(i==4){
			int b=(n & B00110000)>>4;
			TimeDate[i]=a+b*10;
		}
		else if(i==5){
			int b=(n & B00010000)>>4;
			TimeDate[i]=a+b*10;
		}
		else if(i==6){
			int b=(n & B11110000)>>4;
			TimeDate[i]=a+b*10;
		}
		else{
			int b=(n & B01110000)>>4;
			TimeDate[i]=a+b*10;
			}
	}
	temp.concat(TimeDate[4]);
	temp.concat("/") ;
	temp.concat(TimeDate[5]);
	temp.concat("/") ;
	temp.concat(TimeDate[6]);
	temp.concat("     ") ;
	temp.concat(TimeDate[2]);
	temp.concat(":") ;
	temp.concat(TimeDate[1]);
	temp.concat(":") ;
	temp.concat(TimeDate[0]);
  return(temp);
}

Don’t let the use of custom functions and loops put you off, they are there to save time. Looking in the function SetTimeDate();, you can see that the data is written to the registers 80h through to 86h (skipping 83h – day of week) in the way as described earlier (set CS low, send out address to write to, send out data, set CS high). You will also notice some bitwise arithmetic going on as well. This is done to convert data between binary-coded decimal and decimal numbers.

Why? Go back to page twelve of the DS3234 data sheet and look at (e.g.) register 00h/80h – seconds. The bits 7~4 are used to represent the ‘tens’ column of the value, and bits 3~0 represent the ‘ones’ column of the value. So some bit shifting is necessary to isolate the digit for each column in order to convert the data to decimal. For other ways to convert between BCD and decimal, see the examples using the Maxim DS1307 in chapter seven.

Finally here is another example of reading the time data from the DS3234 (download):

/*
 Example 36.3 - SPI bus device demo using a Maxim IC DS3234 Accurate RTC
 http://tronixstuff.com/tutorials > chapter 36 | CC by-sa-nc | John Boxall
 */
#include "SPI.h" // necessary library
// store hours, minutes, seconds, day of month, month, year
byte h,m,s,d,mo,y;
void setup() 
{
 pinMode(10, OUTPUT);
 SPI.begin(); // wake up the SPI bus.
 SPI.setBitOrder(MSBFIRST);
 SPI.setDataMode(SPI_MODE1); 
 digitalWrite(10, LOW); 

 SPI.transfer(0x8E); // write to control register 8Eh (page 14 data sheet)
 SPI.transfer(0x60); // oscillator on, 1Hz, alarms off (b01100000)
 digitalWrite(10, HIGH);

 Serial.begin(9600);
}

void readDS3234() 
{
 byte data=0;
 int a,b=0;
 digitalWrite(10, LOW);

 // get seconds
 SPI.transfer(0x00); // get seconds data from register 00h
 data=SPI.transfer(0x00);
 a = data & B00001111; // isolates 1's column
 b = (data & B01110000)>>4; // isolates 10's digit
 s=(b*10)+a; // calculate seconds!

 // get minutes
 SPI.transfer(0x01); // get minutes data from register 00h
 data=SPI.transfer(0x00);
 a = data & B00001111; // isolates 1's column
 b = (data & B01110000)>>4; // isolates 10's digit
 m=(b*10)+a; // calculate minutes!

 // get hours
 SPI.transfer(0x02); // get minutes data from register 00h
 data=SPI.transfer(0x00);
 a = data & B00001111; // isolates 1's column
 b = (data & B00110000)>>4; // isolate upper nibble
 if (b==B00000010) // 24 hr time
 { 
 b=20;
 } else
 if (b==B00000001) // 12 hr time
 {
 b=10;
 }
 h = a + b; // calculate hours

 digitalWrite(10, HIGH);
}
void loop()
{
 readDS3234();
 Serial.print(h, DEC);
 Serial.print(":");
 if (m<10)
 {
 Serial.print("0");
 }
 Serial.print(m, DEC);
 Serial.print(":");
 if (s<10)
 {
 Serial.print("0");
 }
 Serial.print(s, DEC);
 Serial.println();
 delay(500);
}

So there you have it – more about the world of the SPI bus and how to control the devices within.

In the meanwhile have fun and keep checking into tronixstuff.com. Why not follow things on twitterGoogle+, subscribe  for email updates or RSS using the links on the right-hand column? And join our friendly Google Group – dedicated to the projects and related items on this website. Sign up – it’s free, helpful to each other –  and we can all learn something.

June 15, 2011 Posted by | arduino, BOB-10160, dac, education, learning electronics, microcontrollers, SPI, tutorial, Uncategorized | , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | 6 Comments

   

Follow

Get every new post delivered to your Inbox.

Join 3,842 other followers

%d bloggers like this: