Posts with «i2c» label

DIY I2C Devices with ATtiny85

[Pawel] has a weather station, and its nerve-center is a Raspberry Pi. He wanted to include a light sensor but the problem is, the Pi doesn’t have a built-in ADC to read the voltage off the light-dependent resistor that he (presumably) had in his junk box. You can, of course, buy I2C ADC chips and modules, but when you’ve already got a microcontroller that has ADC peripherals on board, why bother?

[Pawel] wired up a tremendously simple circuit, downloaded some I2C slave-mode code, and added an LED for good measure. It’s all up on GitHub if you’re interested.

Bright by Day, Dark by Night!

We’re covering this because we rarely see people coding for I2C slave devices. Everyone and their mom uses I2C to connect to sensors, for which the Arduino “Wire” library or “i2c-tools” on the Pi do just fine. But what do you do when you want to make the I2C device? [Pawel]’s project makes use of TinyWireS, a slave-mode SPI and I2C library for AVR ATtiny Arduino projects.

Here, [Pawel] just wanted a light sensor. But if you’re building your own devices, the sky is the limit. What’s the most esoteric I2C sensor that you can imagine? (And is it really the case that we haven’t seen an I2C slave device hack since 2010?)


Filed under: ATtiny Hacks
Hack a Day 07 Nov 09:00

Three Arduinos, Sixteen Square Waves

[Folkert van Heusden] sent us in his diabolical MIDI device. Ardio is a MIDI synthesizer of sorts, playing up to sixteen channels of square waves, each on its separate Arduino output pin, and mixed down to stereo with a bunch of resistors. It only plays square waves, and they don’t seem to be entirely in tune, but it makes a heck of a racket and makes use of an interesting architecture.

Ardio is made up of three separate el cheapo Arduino Minis, because…why not?! One Arduino handles the incoming MIDI data and sends note requests out to the other modules over I2C. The voice modules receive commands — play this frequency on that pin — and take care of the sound generation.

None of the chips are heavily loaded, and everything seems to run smoothly, despite the amount of data that’s coming in. As evidence, go download [Folkert]’s rendition of Abba’s classic “Chiquitita” in delicious sixteen-voice “harmony”. It’s a fun exercise in using what’s cheap and easy to get something done.


Filed under: musical hacks
Hack a Day 03 Aug 16:30
arduino  i2c  midi  music  musical hacks  

Arduino Stroboscope Animation


This tutorial will show you how to build your own Stroboscopic Animator using Magzor's Mechanotronic Design Portal as a starting point. Magzor Corporation is a business in California that is trying really hard to simplify robotic design. They want to enable users with little to no engineering experience to design and manufacture a custom robot by themselves in a matter of hours.

What is a stroboscope? A stroboscope is an instrument that uses a strobe light to make a moving object look stationary… We will use this feature to create an interesting 4 picture animation on a rotating disk.

 


 
Have a look at the video below to see the project in action, and the MDP process walk-through:


 

Video



 
 

Parts Required:


 

Magzor Schematic Diagram

Click to zoom ...

 

Further build instructions can be obtained by selecting the components in the Mechanotronics Design Portal within the Magzor website. Generating the build, and then selecting "Setup Instructions" tab at the top of the page. See video above to see this process in action.
 
 

Arduino Sketch


Make sure to copy and paste the following code into your Arduino IDE. It doesn't seem to work directly from the browser. You also need to install the Arduino Magzor I2C library ( http://magzor.com/downloads/ )


 

Putting it together


 

Arduino MEGA


 

Magzor I2C board


 

MIC Boards


 

MIC Boards Assembled


 

Sensors, Modules and Shields - all put together


 

Motor with Bracket and Wire


 

Picture lined up with magnet on disk


 

Stroboscopic Animation


 

The Arduino MEGA microcontroller listens for the hall effect sensor to be triggered by the south facing side of the magnet on the underside of the rotating disk. As the magnet moves over the hall effect sensor, the sensor is triggered and the Arduino instructs the LED to blink for a fraction of a second. By manipulating the delay after the trigger time, we can get the LED to blink when one of the four images on the rotating disk is towards the front position. And if we get the timing right, we can make a simple animation.
 
If you watch the video above, you will see that the image bounces around a little bit. The duration of each frame is determined by the speed of the rotating disk (or motor), and the number of LED flashes per frame. Any changes in rotation speed will affect the position of the picture when the LED blinks. My rotating disk is not completely semetrical or centred correctly, and therefore a bit jumpy… but you get the idea. Bold images with high contrast seem to work best… Precision is key for this type of project. And if you can get the disk to rotate at a constant speed, you could probably do away with the hall effect sensors and magnets… however, in my case, these were essential in getting the project to work as intended.
 
This project is a lot of fun. You can really get creative by making your own pictures or 3 dimensional models (for a stop motion effect). Try different colours. It really is quite cool.


Concluding Comments


I would like to thank Magzor for supplying the components used in this tutorial, and letting me try out their MDP process. I really like the concept, the one stop shop which looks after you from beginning to end. Providing everything I needed to get the project off the ground. The point of this exercise was to go through the entire process of selecting the parts, build the project, and get it up and running. And I have done that in no time at all.
 
There is only one library to download and install, and the good thing is that you don't have to go hunting for it. The latest "correct" working version of the library is easy to find, right there on the Magzor website… Speaking of the Magzor website, please make sure to take a quick look around. It is quite impressive.



If you like this page, please do me a favour and show your appreciation :

 
Visit my ArduinoBasics Google + page.
Follow me on Twitter by looking for ScottC @ArduinoBasics.
I can also be found on Pinterest and Instagram.
Have a look at my videos on my YouTube channel.


 
 
             

This project would not have been possible without the collaborative effort from Magzor Corporation.
Please visit their site and check out the MDP.



However, if you do not have a google profile...
Feel free to share this page with your friends in any way you see fit.

PJON, Fancy One Wire Arduino Communications Protocol For Home Automation

PJON, pronounced like the iridescent sky rats found in every city, is a cool one wire protocol designed by [gioblu].

[gioblu] wasn’t impressed with the complications of I2C. He thought one-wire was too proprietary, too complicated, and its Arduino implementations did not impress. What he really wanted was a protocol that could deal with a ton of noise and a weak signal in his home automation project with the smallest amount of wiring possible.

That’s where is his, “Padded Jittering Operative Network,” comes in. It can support up to 255 Arduinos on one bus and its error handling is apparently good enough that you can hold an Arudino in one hand and see the signals transmitted through your body on the other. The fact that a ground and a signal wire is all you need to run a bus supporting 255 devices and they’ll play nice is pretty cool, even if the bandwidth isn’t the most extreme.

Aside from the cool of DIY protocols. We really enjoyed reading the wiki describing it. Some of the proposed uses was running your home automation through your ducting or water pipes (which should be possible if you’re really good at isolating your grounds). Either way, the protocol is neat and looks fun to use. Or check out PJON_ASK if you want to do away with that pesky single wire.


Filed under: Arduino Hacks
Hack a Day 31 Mar 21:00

Serial vs I2C communication

Hi, please, can you tell me difference between I2C and Serial communication and which is the best for communication Raspberry Pi 2 with Arduino (T'Rex Controller). Thanks

Experimenting with MAX6955

MAX6955 is an interesting LED driver chip. It is the primordial charlieplexing device, being the materialization of a technique invented by Charlie Allen of Maxim Integrated. Without understanding how charelieplexing works, it is actually counter-intuitive to wire multiple (up to 8) 16-segment displays to such a driver chip. Fortunately, Maxim has great documentation on how to do it.


My experimenting actually started with MAX6954. After many failed tries due to SPI issues (Maxim uses a special interpretation of the protocol, I read), I switched to MAX6955.

MAX6955 is the I2C sibling of MAX6954 (which uses SPI). They both have identical LED driving abilities, only the microcontroller interface part of the chips differ. Once, both chips were available in DIP-40 package. Now, MAX6955 only comes in SSOP-36 (MAX6954 is still available in DIP-40). Luckily, the pin configurations for the two chips are compatible, which allows for easy swap. For this reason, I designed a breakout board (shared at oshpark), so I can use the same setup I built for MAX6954.


Beside Maxim's, there isn't much documentation on how to control these chips. One of the reasons they are rarely used by hobbyists is probably their price (about $20 at digikey), although in the same range as the wildly popular MAX72xx LED driver (available at around $10 from digikey). In "reality", for some reason, MAX72xx could be had for $1 or less on ebay, unlike MAX6954/6955. Therefore, a hobby kit designed around MAX6955 would be "extremely" expensive compared with others using different LED driving chips (e.g. MAX72xx).

MAX6954/6955 was designed to drive common cathode LED displays, like MAX72xx. But unlike MAX72xx, it cannot be used for displays with common segments (which require multiplexing), like the ones below (and used here). MAX6954/6955 requires the 14/16-segment displays to be single digit/character, because not all segments will be wired together.


Below is the Arduino sketch I wrote that works very well with MAX6955. Although it uses a minimal set of commands, it is capable of displaying a character at a given position, light up the dot, and even scroll a long message.

#include "Wire.h"

#define ID_MAX6955 B1100000 
#define NUM_DISPLAYS 6

#define max6955_reg_decodeMode      0x01
#define max6955_reg_globalIntensity 0x02
#define max6955_reg_scanLimit       0x03
#define max6955_reg_configuration   0x04
#define max6955_reg_displayTest     0x07
#define max6955_reg_digitType       0x0C

int writeMAX6955(char command, char data)
{
    Wire.beginTransmission(ID_MAX6955);
    Wire.write(command);
    Wire.write(data);
    Wire.endTransmission();
}

void initMAX6955()
{
    Wire.begin();
    // ascii decoding for all digits;
    writeMAX6955(max6955_reg_decodeMode, 0xFF);
    // brightness: 0x00 =  1/16 (min on)  2.5 mA/seg;
    // 0x0F = 15/16 (max on) 37.5 mA/segment
    writeMAX6955(max6955_reg_globalIntensity, 0x07);
    // active displays: 0x07 -> all;
    writeMAX6955(max6955_reg_scanLimit, 0x07);
    // set normal operation;
    writeMAX6955(max6955_reg_configuration, 0x01);
    // segments/display: 0xFF=14-seg; 0=16 or 7-seg;
    writeMAX6955(max6955_reg_digitType, 0x00);
    // display test off;
    writeMAX6955(max6955_reg_displayTest, 0x00);
}

void setup()
{
  // set D8 and D9 to GND (for I2C address);
  pinMode(8, OUTPUT);
  pinMode(9, OUTPUT);
  digitalWrite(8, LOW);
  digitalWrite(9, LOW);

  initMAX6955();
  delay(100);
  clear();
//  writeDisplay("HI");
//  writeChar(0, 'A', true);
//  scrollDisplay("     HELLO WORLD", 300);
  writeTime(15, 24, 39);
}

void loop()
{
}

void writeDisplay(char* msg)
{
  for (byte i=0; i < NUM_DISPLAYS; i++)
  {
    if (i < strlen(msg))
      writeMAX6955(0x25-i, msg[i]);
    else
      writeMAX6955(0x25-i, ' ');
  }
}

void writeChar(byte pos, char letter, boolean dotLit)
{
  writeMAX6955(0x25-pos, (dotLit? 0x80 : 0) | letter);
}

void clear()
{
  for (byte i=0; i < NUM_DISPLAYS; i++)
    writeMAX6955(0x25-i, ' ');
}

void scrollDisplay(char* msg, int delayMs)
{
  for (int i=0; i<=strlen(msg); i++)
  {
    writeDisplay(msg+i);
    delay(delayMs);
  }
}

void writeTime(int hours, int minutes, int seconds)
{
  char h1 = (hours/10)? '0' + hours/10 : ' ';
  writeChar(0, h1, false);
  char h2 = '0' + (hours%10);
  writeChar(1, h2, true);
  char m1 = '0' + (minutes/10);
  writeChar(2, m1, false);
  char m2 = '0' + (minutes%10);
  writeChar(3, m2, true);
  char s1 = '0' + (seconds/10);
  writeChar(4, s1, false);
  char s2 = '0' + (seconds%10);
  writeChar(5, s2, false);
}

The I2C address of B1100000 was set by grounding AD0 and AD1 (see table 5 in the datasheet on how to change that address). In my setup, these 2 pins are connected to D8 and D9. Don't forget to pull-up SDA and SCL with 4k7-10k resistors.

The left-most digit is at position 0, accessible at address 0x25. "Digit 1" is the second from left, accessible at address 0x24, and so on. This is determined by the wiring. In my case, "CC0" (in the table 1 of this application note) represents the right-most display, and it is accessible at address 0x20.

Embed with Elliot: I2C Bus Scanning

A lot of great ICs use I2C to communicate, but debugging a non-working I2C setup can be opaque, especially if you’re just getting started with the protocol/bus. An I2C bus scanner can be a helpful first step in debugging an I2C system. Are all the devices that I think should be present actually there and responding? Do they all work at the bus speed that I’m trying to run? If you’ve got an Arduino or Bus Pirate sitting around, you’re only seconds away from scanning your I2C bus, and answering these questions.

The Lowdown: I2C in Brief

I2C is a two-wire (plus ground) communications bus and protocol. The physical layer is just two signal wires: a clock line (SCL) that’s controlled by the master, and a data line (SDA) that can be controlled by either the master or the addressed slave unit. Data is always read on the SDA line when the clock is high, and a new value is established while the clock is low. The two exceptions to this rule are the stop and start signals, where the master is allowed to raise and drop the data line while the clock is still high. Because this change shouldn’t ever happen during data transfer, the stop and start signals are easy to detect.

All data is sent in eight-bit packets and each packet is acknowledged by the recipient, whether master or slave. To start up a conversation, the master sends the start signal and then the seven-bit address of the slave device that it wants to speak to. The eighth bit in the master’s first packet tells the slave whether the master is going to transmit more data (a “write” command, a zero) or whether the master is requesting data back from the slave (a “read” value, a one).

After the eight bits are sent, the slave is required to acknowledge receipt by pulling the data line low.  This acknowledge signal is exactly what the I2C bus scanning software will need to look for in order to detect a chip with the given address on the bus.

There are, of course, a lot more complicating details to I2C. For instance, there are a whole range of permissible clock speeds at which the transmissions can take place: ranging from the default 100kHz data rate, through 400kHz “fast mode”, 1MHz “fast mode plus”, and up as far as 5MHz “ultra-fast mode”. (We await the 10MHz “super-duper, really-really-fast mode” with baited breath.) And since the bus is clocked by the SCL line, almost any slower data rate up to the maximum allowed will work just fine.

The physical lines are pulled up to a logic-high voltage level by pullup resistors, and the devices signal low by pulling the line down. This means that the voltage transitions can be a little blurry, especially on long runs or other situations where the line itself capacitively couples to the circuit. These physical factors will play a role in determining how fast you can send signals on the I2C bus, and you may need to fine-tune the pullup resistors in your particular system.

There are a surprisingly large number of other ways that things can go wrong on an I2C bus, so it’s great to be able to start debugging at the very beginning — is the slave even getting my first (address) packet at the speed I’m sending? Hence the utility of an I2C scanner.

A Scanner

A first cut at an I2C bus scanner, then, can be made by just cycling through all 127 possible slave device addresses, and checking whether or not they acknowledge. Next, you might want to re-run the same test at a bunch of different bus speeds, if you thought that you might be having troubles with signal rise- and fall-times. Finally, and we’ve never seen this implemented, it might be cool to have a database of common I2C slave device addresses so that the scanner itself can report back which particular chips it’s found.

For the Arduino, the most featureful scanner we’ve seen is posted on the Arduino forums, with the code hosted on Github, in the “sketches/MultiSpeedI2CScanner” folder.  It actually does everything that we’d want in a simple scanner: scans the entire bus at different speeds and plots the results out nicely over the serial port for perusal on your computer. It’s configured to do a full scan on reboot. Type “ps” to print only the found devices and start a scan. Bam!

The one caveat with the Arduino scanner is that if you’ve neglected to connect pullup resistors on the SDA and SCL lines (we would never!) the scanner seems to hang somewhere when running at 800kHz. We suspect it’s waiting to become bus master and just gets stuck; we wonder why there’s not a timeout in the twi_writeTo() function in the Arduino “twi.c” library. (Anyone have a good guess?) Other speed modes worked just fine, and everything was peachy again after adding a 10k pullup resistor to SDA.

Naturally, the Bus Pirate (the swiss-army knife of serial communications) will do an I2C scan. It only runs one frequency at a time, but it’s quick enough that you can step through them all in short order. It’s got a quirk, or maybe a feature; it treats the read/write bit as part of the address, so it will test each chip in both directions. Enter the I2C mode, set the desired speed and pullup/power options, and finally type “(1)” for option 1: 7-bit address search. You should see all the devices that responded on the bus listed out for you.

Writing your own code to do a scan is surprisingly simple as well, if you know the chips you’re working with. Most microcontrollers’ dedicated hardware I2C interfaces will report error codes in a specific register. If you can figure out how to test for the “didn’t acknowledge after sending the address and data-direction packet” error, the code pretty much writes itself.

Going Further

Once you’ve got the basics verified — the slave responds when addressed at the desired speed — and your I2C setup still isn’t working, you’re on to debugging the harder problems. There are other tests you might like to do, but unfortunately they all run quickly into the slave-device specific command sets. For instance, many devices will receive a command to reply with a known device ID, or the contents of a default register, or similar. These are useful to make certain that you’ve got multi-byte commands working as expected.

If you suspect that you’re having problems with the signals not rising or falling fast enough, perhaps because you’ve seen chips respond at low speeds but not at higher ones during the scan above, you’re going to need an oscilloscope to actually probe out the analog voltages on the lines. Or try lower-value pullup resistors to speed up the rising edges and test again.

Harder to catch or infrequently occurring glitches on a multi-master I2C bus get really hard to track down really fast. But getting the simple stuff verified working first — all parts are on the addresses that you think they are — can get you set on the right path.

Good luck with your I2C projects! And if you’ve got any other useful I2C debugging tools or strategies up your sleeves, feel free to discuss in the comments.


Filed under: Hackaday Columns, Microcontrollers, peripherals hacks

High Speed SSD1306 Library

[Lewin] wrote in to tell us about a high speed library for Arduino Due that he helped develop which allows interfacing OLED displays that use the SSD1306 display controller, using DMA routines for faster display refresh time.

Typically, displays such as the Monochrome 1.3″ 128×64 OLED graphic display , are interfaced with an Arduino board via the SPI or I2C bus. The Adafruit_SSD1306 library written by [Limor Fried] makes it simple to use these displays with a variety of Arduinos, using either software or hardware SPI. With standard settings using hardware SPI, calls to display() take about 2ms on the Due.

[Lewin] wanted to make it faster, and the SAM3X8E on the Due seemed like it could deliver. He first did a search to find out if this was already done, but came up blank. He did find [Marek Buriak]’s library for ILI9341-based TFT screens. [Marek] used code from [William Greiman], who developed SD card libraries for the Arduino. [William] had taken advantage of the SAM3X8E’s DMA capabilities to enable faster SD card transfers, and [Marek] then adapted this code to allow faster writes to ILI9341-based screens. All [Lewin] had to do was to find the code that sent a buffer out over SPI using DMA in Marek’s code, and adapt that to the Adafruit library for the SSD1306.

There is a caveat though: using this library will likely cause trouble if you are also using SPI to interface to other hardware, since the regular SPI.h library will no longer work in tandem with [Lewin]’s library. He offers some tips on how to overcome these issues, and would welcome any feedback or testing to help improve the code. The speed improvement is substantial. Up to 4 times quicker using standard SPI clock, or 8 times if you increase SPI clock speed. The code is available on his Github repo.


Filed under: Arduino Hacks

OLED clock with Pacman mode

This large 2.42" OLED I2C module can be used as a replacement for the smaller 0.96" display for which I originally designed the ProMini OLED clock shield. It is built around the same SSD1306 chip, and it only comes in yellow (for now).

MikeM wrote this great Pacman clock sketch for it (available for download here), shown in the video below.



To display on the OLED, Mike used U8glib graphic library. Initially tested on the 0.96" OLED, the sketch froze after some time, for a yet to be explained reason. The same sketch works perfectly with the 2.42" display. Mike spent a lot of time trying to figure out if the culprit is software (bug in the U8glib) or hardware.
(Any feedback on this issue is greatly appreciated.)

The clock can also display the time as HH:MM:SS on the whole screen, as shown in the photo below, also courtesy of Mike.


My next step would be to design an enclosure for it. For that I will probably need some more help :)


Wise time with Arduino 24 Oct 02:41
i2c  oled  software  

Arduino-Powered Alarm System Has All The Bells And Whistles

Put aside all of the projects that use an Arduino to blink a few LEDs or drive one servo motor. [IngGaro]‘s latest project uses the full range of features available in this versatile microcontroller and has turned an Arduino Mega into a fully-functional home alarm system.

The alarm can read RFID cards for activation and control of the device. It communicates with the front panel via an I2C bus, and it can control the opening and closing of windows or blinds. There is also an integrated GSM antenna for communicating any emergencies over the cell network. The device also keeps track of temperature and humidity.

The entire system can be controlled via a web interface. The Arduino serves a web page that allows the user full control over the alarm. With all of that, it’s hard to think of any more functionality to get out of this tiny microcontroller, unless you wanted to add a frickin’ laser to REALLY trip up the burglars!


Filed under: security hacks
Hack a Day 03 Sep 06:00