Code:

if(XBee.available() > -1){
digitalWrite(ledpin, HIGH);
}
else{
digitalWrite(ledpin, LOW);
}

In this example at least, you're not consuming the data that has been received, so it remains available because it is still in the buffer. Flushing the buffer has the desired effect as it consumes all the available data.

In terms of the serial polling, I don't know what your "emergency button transmitter" consists of, but you may be able to use the XBee's line passing feature to trigger the interrupt on the receiving device.

You can get a feed of the BBC weather too:

http://newsrss.bbc.co.uk/weather/forecast/8/Next3DaysRSS.xml
http://newsrss.bbc.co.uk/weather/forecast/8/ObservationsRSS.xml

If you go to http://news.bbc.co.uk/weather/ and enter a location, a little orange RSS button appears in the boxes you can get feeds for.

Do you mean synchronization in Java between multiple threads, or between the computer and the Arduino?

If it's the first then the Java Tutorial on concurrency is a good information source.

If it's the latter, then I'm assuming you're getting mistakes because the computer is sending the data faster than the arduino can process it. (This means the serial buffer will be filling up and bytes will be lost, resulting in mismatched upper and lower values). You can get around this by having the arduino send acknowledgements back so the computer knows when it is ready to send more data.

As an example, in a project I've been working on I have a Java class which manages the serial connection, and it counts the number of bytes that have been sent, when 100 bytes have been sent it will not send any more until a certain message is received from the arduino. The arduino then counts the number of bytes it has recieved and processed, and when that number reaches 100, it sends the request for more to the computer.

Hi,

Firstly, you should be aware that java's idea of an int is a 4 byte value, but an arduino int is 2 bytes. In java you could use a short which is a 2 byte value.

Secondly, using the RXTX library you only send bytes over serial (http://java.sun.com/j2se/1.5.0/docs/api/java/io/OutputStream.html#write(int)), if you want to send a int then you're going to have to split it into two bytes then reassemble that on the arduino.

So in java you would do something like:

Code:

short x = 1200;
byte upper = x >> 8; //Get the upper 8 bits
byte lower = x & 0xFF; //Get the lower 8bits
output.write(upper);
output.write(lower);

Then on the arduino you'd have something like:

Code:

byte upper = Serial.read();
byte lower = Serial.read();
int x = (upper<<8) | lower; //Reassemble the number
Serial.print(x, DEC);

Just replying to say THANKS!

Your fix worked for me using 0017 and Windows 7 (RC).

Ah, ok. To use the return statement you just enter return, followed by the value you wish to return. It's not a function, more of a key word, so in your example you don't need the brackets:

Code:

return 0;

The reason return(0); works is because it is treating "(0)" as a mathematical expression. You can use this to perform arithmetic before returning a value, eg.

Code:

int add(int a, int b)
{
    return a+b;
}

I don't see how an extra else there would make any difference. There is after all a "return" at the end of both if-statements.

Hmm, that's true. Other than not returning an int (which the compiler will happily ignore) I'm not sure why it doesn't work then.

Aren't you supposed to decide once and for all whether a pin is input or output with pinMode() and stick to that?

When a pin is set to an output, digitalRead gives you the current output state, rather than reading the input.

The problem is after you're setting the pin LOW, you're still checking if it's LOW before setting it HIGH again. You want to use an "else if" statement so the second "pin is low" block doesn't execute after you have set the pin LOW in the first block.

Code:

int toggle(int pinnumber){
  if(digitalRead(pinnumber) == HIGH){
    Serial.print("toggle functions says ");
    Serial.print(pinnumber);
    Serial.print(" is on");
    Serial.println();
    // if light is on turn it off
    digitalWrite(pinnumber, LOW);
    return;
  }
  [glow]else[/glow] if(digitalRead(pinnumber) == LOW){
    Serial.print("toggle functions says ");
    Serial.print(pinnumber);
    Serial.print(" is off");
    Serial.println();
    // if light is off turn it on
    digitalWrite(pinnumber, HIGH);
    return;
  }
}

Also, your function is defined as returning an int, but your return statements don't return anything. Either you set the return type to void, or you return something.

Yeah, it's been a while since I used the LiquidCrystal library and I couldn't be bothered looking it up. (Fixed).

Something like this?

Code:

int numChars = 0;

//Fill top line
while ( numChars < 16 )
{
      while ( !Serial.available() ); //Wait for char
      LCD.print(Serial.read());
      numChars++;
}

LCD.cursorTo(0,1); //Move to second line

//Fill bottom line
numChars = 0;
while ( numChars < 16 )
{
      while ( !Serial.available() ); //Wait for char
      LCD.print(Serial.read());
      numChars++;
}

I'm not sure on the specifics of the LCD library you're using, but the rest should work.

I couldn't check it compiled, but it looks like you've got a spurious opening parenthesis on line 143 which is most likely what's stopping the second piece of highlighted code compiling. On line 161 it looks like a line break has gone missing and the if statement that checks the 5 minutes has passed has been commented out.

Code:

while ((newdata = false) && (timer < 300000)); //Look for a signal for 5 minutes if (timer >= 300000){ // if no signal in 5 minutes, power down

should become

Code:

while ((newdata = false) && (timer < 300000)); //Look for a signal for 5 minutes
if (timer >= 300000){ // if no signal in 5 minutes, power down

The last semicolon on this line is terminating the for loop, so when you try to refer to 'i' it's out of scope.

Code:

 for(int i=0; i<=num; i++);{

... should become ...

Code:

 for(int i=0; i<=num; i++){

Assuming you're using a HD44780 based LCD...

Firstly, as you've observed, if you make changes to the CGRAM while your custom characters are being displayed, they update. This is because the HD44780 constantly refreshes the screen. You are never going to be able to display a 10 character "graphic".

Code:

 if (( asc < 0 ) || ( asc > 7 )) // if asc is greater than 0 OR less than 7
    return;  

I'm not familiar with the code you're referring to but I'm guessing asc is short for the ASCII code for the character.

The controller has 64 continuous bytes of CGRAM for custom characters. To write to it you must tell the controller where to move the address pointer too. (The address pointer points to the memory location that will be written too next time you write to the display).

To tell the controller you're going to write to CGRAM you send it B01AAAAA. (B01000000==0x40). The high bit6 tells the controller to go to CGRAM, the AAAAA then tells it where abouts in the CGRAM to go to. Remember that the CGRAM is 64 bytes, so this AAAAA value points somewhere within those bytes.

Because the characters are stored contiguously, the lower three AAAs point to the byte within a character. This is why we shift the ASCII code three bits left, because the lower three bits are within a character. So for example, to write to character 4, we shift 4 three bits over, which gives us 32, which is the beginning of the fifth character (don't forget character codes begin at zero!).

Once we've told the controller to go to CGRAM, and which byte to go to, we then write the character data to the display, the address pointer auto-increments once you write to the display, so when we write the 8 bytes of character, those bytes are being put in CGRAM location

AAA000 (0)
AAA001 (1)
AAA010 (2)
...
AAA110 (6)
AAA111 (7)

(Where AAA is your character ASCII code)

It isn't possible to make the controller read the custom characters from anywhere but its own 64bytes, so you can't use the arduinos RAM to extend the CGRAM, you're still limited to only 8 custom chars.

I'm not sure if this is what you're after, if not I can try to explain it differently...

It seems that you're calling setVisible on a new SerialTest object, rather than the one you've initialised:

Code:

  public static void main(String args[]) {
       java.awt.EventQueue.invokeLater(new Runnable() {
           public void run() {
               [glow]new SerialTest().setVisible(true);[/glow]
           }
       });
                   SerialTest main = new SerialTest();
           main.initialize();
           System.out.println("Started");

   }

I'm not really sure what the purpose of making the SerialTest visible in a separate thread is, but this may work:

Code:

  public static void main(String args[]) {
           [glow]SerialTest main = new SerialTest();[/glow]
           main.initialize();
           System.out.println("Started");

       java.awt.EventQueue.invokeLater(new Runnable() {
           public void run() {
               [glow]main[/glow].setVisible(true);
           }
       });
                  


   }

You should be able to roll the minutes downwards using

Code:

minutes = (minutes+59)%60;