Show Posts
Pages: [1] 2 3 ... 5
1  Using Arduino / General Electronics / Re: VERY basic math resistor question. on: February 18, 2011, 03:43:57 pm
Simple LED resistor calculation:

(Vsupply - Vled) / Iled = R

So for a normal red/yellow/green LED, the forward voltage drop of 1.8V results in:

(6V - 1.8V) / .02 = 210 ohms. Nearest "stock" 5% resistor would be 220 ohms.

For a White or Blue LED with a higher drop, limiting the current more, and using a higher voltage, you would get:

(9V - 3V) / .015 = 400 ohms. You could go with a 390 ohm 5% resistor.

At 5V, 220 ohms will let 20mA through a monochrome LED; 470 limits it to roughly 10mA, and 1K gets it down to approximately 5 mA. Limiting the current saves battery power, but makes the LED proportionally dimmer. If you can remember those 3 resistor/current values, then adjusting upwards for higher voltages is pretty easy.

2  Using Arduino / General Electronics / New voltage divider calculator available on: February 18, 2011, 03:31:17 pm
Most of the voltage divider calculators on the Internet make the assumption that the user needs to find out what the output is from a specified input and known pair of resistors; I've written a Java application that basically works backwards from that: the user enters the input, the desired output, and the application cycles through and figures out what combinations of fixed resistors will produce it. The application allows for 5%, 1%, and .1/.25/.5% resistors, can copy the values to the system clipboard or print them out. Included in the file is FULL source code (with libraries and everything else), and well as the Java .jar file (neatly stored in the dist subdirectory). It's available as a zip at:

It's released as Open Source, so feel free to molest and mangle it to your hearts content!  smiley

3  Using Arduino / Installation & Troubleshooting / Can't find stdlib.h, string.h, etc in Linux IDE 22 on: February 13, 2011, 02:02:28 pm
Just installed the ide (using zypper, following the openSuSE instructions), and just as a test, tried to verify the blink example - and MUCH to my surprise, it promptly threw up... giving me this:

In file included from Blink.cpp:8:
/usr/share/arduino-0022/hardware/arduino/cores/arduino/WProgram.h:4:20: error: stdlib.h: No such file or directory
/usr/share/arduino-0022/hardware/arduino/cores/arduino/WProgram.h:5:20: error: string.h: No such file or directory
/usr/share/arduino-0022/hardware/arduino/cores/arduino/WProgram.h:6:18: error: math.h: No such file or directory
/usr/share/arduino-0022/hardware/arduino/cores/arduino/WProgram.h:8:27: error: avr/interrupt.h: No such file or directory

<bunch more word salad deleted>

I edited my path to include /usr/include, where stdlib et al reside, but I'm still getting this.

Whiskey Tango Foxtrot, over?
4  Forum 2005-2010 (read only) / Syntax & Programs / Re: I2C -- EEPROM testing on: March 21, 2009, 07:34:10 pm
I understand that page size is hardwired -- in the case of my chip, it's 32 bytes. What I'm unclear on is whether or not those 32-byte pages have to correspond to the logical binary boundaries -- that is, could I conceivably write a "page" of 32 bytes that started at 0x11 and ran to 0x31, for example? Or would trying to do so cause some kind of error within the chip (i.e. hit address 0x1F, and wrap around to 0x00)?
5  Forum 2005-2010 (read only) / Syntax & Programs / Re: I2C -- EEPROM testing on: March 21, 2009, 11:25:11 am

1) I wasn't too worried about writing the same 32 bytes over and over; I was more after just being able to read/write - but I still appreciate it.

2) The EEPROM spec says that 32 bytes is the page size; the comments on the eeprom buffer routine suggest that the Wire buffer might be the problem there. I'll back off to 16 bytes, and see how that goes.

3) I'll set it to 10mS delay, and work with that, then.

Perhaps you know something that isn't real clear in the datasheets: they specify a page size, but what I'm not sure of is whether or not page boundaries are logical or hardwired -- that is, can a 32-byte page run from, say, memory location 0x17 - 0x37, or would it have to be at 0x00/0x20/0x40 etc ?

Again, thank you for taking the time to double-check me on this.
6  Forum 2005-2010 (read only) / Syntax & Programs / Re: I2C -- EEPROM testing on: March 18, 2009, 11:26:32 am
Thanks -- I'll give it a go.
7  Forum 2005-2010 (read only) / Syntax & Programs / Re: I2C -- EEPROM testing on: March 18, 2009, 10:54:20 am
Actually, I have.

At first, I thought I might be running into the 30-32 byte Wire buffer (which, incidentally, I suspect should probably be increased to a *definite* 64, since some of the EEPROM sheets I've looked at are that big), and dropped to 24, 16, and even 8 -- all without success.
8  Forum 2005-2010 (read only) / Syntax & Programs / Re: I2C -- EEPROM testing on: March 18, 2009, 10:29:05 am
KG4 - have you got a link to a page? Just went to the general address (, and couldn't figure out where I should go from there...

BroHogan - from the data sheet, the time to actually write a page is the same as for actually writing a single byte, so loading the EEPROM with a page of data before writing would appear to be a _little_ bit of a time saver when dealing with more than page-size chunks of data.
9  Forum 2005-2010 (read only) / Syntax & Programs / Re: I2C -- EEPROM testing on: March 17, 2009, 10:04:51 pm
That's the way I've got it wired -- I've check several times, and that I'm getting data in/out of the first page of the EEPROM makes me believe it isn't my hookup. I've only got the one chip at present; it's stuck in a breadboard, and I've verified that I don't have any bent pins on it.

I'm starting to wonder if I shouldn't call this in as an X-file   :o
10  Forum 2005-2010 (read only) / Syntax & Programs / Re: I2C -- EEPROM testing on: March 17, 2009, 09:49:32 pm
Since this isn't a matter of national security or anything, I'm not going to fuss if you need/want a couple days to help me  smiley-grin

I've tried both write_byte and write_page, neither has worked (yet); all I've gotten out of this exercise has been a headache smiley-razz
11  Forum 2005-2010 (read only) / Syntax & Programs / Re: I2C -- EEPROM testing on: March 16, 2009, 07:54:36 pm
I moved my delay to the end of the EEPROM write routine, as you have it, without effect.  :-[

The datasheet for my EEPROM shows the addressing byte as:
 1 0 1 0 A2 A1 A0 R/W; ignoring the r/w bit (which Wire is supposed to take care of), that leaves me with 101 0000, or 0x50. I've gone out and checked a few other Googled references, and found that 1010xxx seems to be fairly common for EEPROMs:
As an example, the Microchip 24LC01B Serial EEPROM has A0, A1, and A2 inputs, but the high order address bits are hardwired to 1010 – this allows slave addresses of the form 1010xxx, but no more than 8 of these devices on any I2C bus due to address conflict

(*shrugs*) Beats me.  smiley-wink

Would it be within the realm of possibility that you could try my code using (one of) your chip(s)? Just to eliminate biological errors?
12  Forum 2005-2010 (read only) / Syntax & Programs / Re: I2C -- EEPROM testing on: March 16, 2009, 05:24:47 pm
Florinc, your comment makes me believe that the wire library is probably good (I figured it was, but...).

I've looked at the datasheet (the problem seems to be at Catalyst' end; it wouldn't download for me, either), and it specs a MAX of 10mS for writes to complete before it'll respond to another request -- which doesn't quite explain why the varying values of delay I put in at the end of the writes didn't work (I started with a delay of 10, then 20, then 50, and finally 100).

Curiouser and curiouser...  :-?
13  Forum 2005-2010 (read only) / Syntax & Programs / I2C -- EEPROM testing on: March 15, 2009, 06:39:11 pm
That hollow clonking sound you've been hearing for the last couple of days has been me beating my head against the wall trying to get I2C working with a serial (I2C) EEPROM. I'm running Kubuntu 8.1, a Diecimila with a Lady Ada 328, and IDE v13.

I *think* I'm writing to it, but bugger-all if I'm getting anything reasonable back out of it; I can get a few (best so far has been 52 of 128) bytes to read back correctly, but that's it.

Here's the Sketch I've been using, in case someone can spot an otherwise obvious mistook I've made:

 *     20090313 -- I2C_DEVICE DEVICE writing
 *     by D.K.Merriman
 *  Arduino analog input 5 - I2C SCL
 *  Arduino analog input 4 - I2C SDA

#include "Wire.h"

#define ChipSize 128  // size of EEPROM in bytes
#define PageSize 32  // bytes per page (from datasheet)
#define ChipAddress 0x50  // address of the EEPROM - pretending lowest bit doesn't exist: 1010 000x = 101 0000 = 0x50

void setup()

void loop()
  int x;
  int y;
  int z;
  int PageCount= (ChipSize / PageSize);  // number of pages in the EEPROM

  byte SourceData[ChipSize];  // Source Data for testing
  byte TestData[ChipSize];  // for reading EEPROM data back
  byte t[PageSize];  // array for temp buffer (needed to write to eeprom in page-size chunks)

  delay(2000);  // just to give yourself time to switch over to the serial monitor before things start happening
  Serial.println("Loading Source data array");
  for (x = 0; x < ChipSize; x++) {
    SourceData[x] = 0x38;  // ASCII '8'
    TestData[x] = 0x00;  // make sure the test data array is "empty"
  Serial.println("Source data array Initialized - Writing to EEPROM");
  for (x = 0; x < PageCount; x++) {
    for (y = 0; y < PageSize; y++) {
      t[y] = SourceData[(x * PageSize) + y];
    i2c_eeprom_write_page(ChipAddress, x, t, PageSize);
    delay(1);  // a couple of examples have indicated that a delay is needed here. I've gone from 1-100 with no effect.

  Serial.println("EEPROM written");
  delay(5000);  // kill some time, just on general principles
  Serial.println("Reading data back from EEPROM");
  for (x = 0; x < ChipSize; x++) {
    TestData[x] = i2c_eeprom_read_byte(ChipAddress, x);
  Serial.println("All EEPROM data read");

  for (x = 0; x < ChipSize; x++) {
    if (TestData[x] != SourceData[x]) {
        Serial.print("Data mismatch at ");
        Serial.print(" Received: ");
        Serial.print(" Should have been: ");

// I2C Read/Write routines

void i2c_eeprom_write_byte( int deviceaddress, unsigned int eeaddress, byte data ) {
  int rdata = data;
  Wire.send((int)(eeaddress >> 8)); // MSB
  Wire.send((int)(eeaddress & 0xFF)); // LSB

// WARNING: address is a page address, 6-bit end will wrap around
// also, data can be maximum of about 30 bytes, because the Wire library has a buffer of 32 bytes
void i2c_eeprom_write_page( int deviceaddress, unsigned int eeaddresspage, byte* data, byte length ) {
  Wire.send((int)(eeaddresspage >> 8)); // MSB
  Wire.send((int)(eeaddresspage & 0xFF)); // LSB
  byte c;
  for ( c = 0; c < length; c++)

byte i2c_eeprom_read_byte( int deviceaddress, unsigned int eeaddress ) {
  byte rdata = 0xFF;
  Wire.send((int)(eeaddress >> 8)); // MSB
  Wire.send((int)(eeaddress & 0xFF)); // LSB
  if (Wire.available()) rdata = Wire.receive();
  return rdata;

// maybe let's not read more than 30 or 32 bytes at a time!
void i2c_eeprom_read_buffer( int deviceaddress, unsigned int eeaddress, byte *buffer, int length ) {
  Wire.send((int)(eeaddress >> 8)); // MSB
  Wire.send((int)(eeaddress & 0xFF)); // LSB
  int c = 0;
  for ( c = 0; c < length; c++ )
    if (Wire.available()) buffer[c] = Wire.receive();

The specific EEPROM I've been using is a CAT24WC33 (32K-bit) from FunGizmos at:
 where you can also get the datasheet from:

IF I'm understanding things I've read elsewhere, there _may_ be some question as to the reliability of the Wire library, as regards I2C -- can anyone even vaguely authoritative confirm or deny that?

Any suggestions on where/why I can't seem to read the EEPROM would be appreciated.

14  Forum 2005-2010 (read only) / Interfacing / Re: Dallas Semi 18S20 HALF-degree resolution? on: October 16, 2009, 04:53:40 am

Gah! I love this higher math stuff...

As soon as I explicitly assigned all the stuff on the ftemp calculation line to (float), and returned ftemp, I started getting fractions of degrees.


Thanks for hitting me up-side the head with the obvious smiley-razz
15  Forum 2005-2010 (read only) / Interfacing / Re: Dallas Semi 18S20 HALF-degree resolution? on: October 16, 2009, 04:19:49 am
Minus some Serial.print stuff I stuck in while trying to resolve things:

   float get_temp(byte* addr)
      byte present = 0;
      byte i;
      byte data[12];
      ds.write(0x44,0);         // start conversion, with parasite power on at the end
      delay(1000);     // maybe 750ms is enough, maybe not
      // we might do a ds.depower() here, but the reset will take care of it.
      present = ds.reset();;  
      ds.write(0xBE);         // Read Scratchpad
      for ( i = 0; i < 9; i++) { // 8 bytes of data, 9th byte to check for negative temps
        data[i] =;
      int temp;
      float ftemp;
      temp = data[0];      // load all 8 bits of the LSB
      if (data[1] > 0x80){  // sign bit set, temp is negative
        temp = !temp - 1; //two's complement adjustment
        temp = temp * -1; //flip value negative.

    //get hi-rez data
       int cpc;
       int cr = data[6];
       cpc = data[7];
       Serial.println(cr, HEX);
       Serial.println(cpc, HEX);
       if (cpc == 0)
          return BADTEMP;

       temp = temp * .5;  // Low-order byte is how many half-degrees
       ftemp = temp - (float)0.25 + ((cpc - cr)/(float)cpc);
//    end hi-rez data
       return temp;
Pages: [1] 2 3 ... 5