Show Posts
Pages: [1] 2
1  Forum 2005-2010 (read only) / Troubleshooting / Re: SoftwareSerial timeout on: January 22, 2008, 04:05:57 pm
I've been playing around with the SS library.  I'm pretty new to the arduino platform, but it looks like there is surely room for improvement with the SS library.  I've been meaning to add basic things like a timeout.  This really shouldn't be all that hard.  If you want to give it a go, I'm sure you can make it work for you.  Otherwise, I plan on getting around to this sometime soon.
2  Forum 2005-2010 (read only) / Syntax & Programs / Re: Need help coding a loop on: January 09, 2008, 06:24:19 pm
Is the progression supposed to be linear or do you have in mind something else?
3  Forum 2005-2010 (read only) / Syntax & Programs / Re: Need help coding a loop on: January 09, 2008, 06:06:42 pm
Does it have to be actual integer math, or does it just have to produce an integer result?
4  Forum 2005-2010 (read only) / Development / Re: New Library - QuickPin on: February 13, 2008, 10:35:44 am
That could be a parent class.
5  Forum 2005-2010 (read only) / Development / Re: New Library - QuickPin on: February 12, 2008, 11:08:24 pm
Quote
  • It looks like there a few cases where you can call a function that's not meaningful - e.g. set() on a QuickPin instance representing an analog input, or get() on analog output.  If you split the library up into three classes (e.g. DigitalPin, AnalogInputPin, AnalogOutputPin), you could have each one only provide the functions that are meaningful for that type of pin.  It would probably even speed things up, since you wouldn't need to check the pin type inside the get() and set() functions.

I certainly considered that idea.  However, I opted for the consolidated approach; in favor of a more centralized point of entry for pin manipulation.  My idea is that it's easier to remember and use a class of the same name,  the same instantiation parameters, and the same methods.  With everything in one spot if you want to manipulate a pin, QuickPin will do it for you.

Quote
  • What about using read() and write() instead of get() and set() for better consistency with the existing API's (e.g. digitalRead(), digitalWrite())?

This is a very good idea.  I think that I will adopt this before anyone starts to use QuickPin.

Quote
  • In open(), I think you want to call setError(ER_NONE) before re_initialize() - otherwise you mask initialization errors (like invalid pin numbers).  

I'll look into this.  Thanks!
6  Forum 2005-2010 (read only) / Development / New Library - QuickPin on: February 12, 2008, 12:14:45 am
This library's main goal was to be as fast as possible for those applications that need speed.  QuickPin is around twice as fast as the digitalRead and digitalWrite functions that it replaces.  The library can be found Here.

Here are some samples on how the library is used:

                       Analog Input
Code:
#include <QuickPin.h>

QuickPin analogSensor(0, ANALOG, INPUT);

void setup() {
  Serial.begin(115200);
}

void loop() {
  int val = analogSensor.get();
  
  Serial.println(val, DEC);
  delay(500);
}



                       Analog Output (PWM)
Code:
#include <QuickPin.h>

QuickPin analogOutput(11, ANALOG, OUTPUT);

void setup() {
}

void loop() {
  for(int i=0; i<254; i++) {
    analogOutput.set(i);
    delay(20);
  }
}



                       Digital Input
Code:
#include <QuickPin.h>

QuickPin digitalInput(5, DIGITAL, INPUT);

void setup() {
  Serial.begin(115200);
}

void loop() {
  byte result;

  for(int i=0; i<20; i++) {
    result = digitalInput.get();
    Serial.print(result, DEC);
    delay(200);
  }
  Serial.print('\n');
}



                       Digital Output
Code:
#include <QuickPin.h>

QuickPin digitalOutput(13, DIGITAL, OUTPUT);

void setup() {
}

void loop() {
  byte result;

  for(int i=0; i<20; i++) {
    digitalOutput.set(HIGH);
    delay(200);
    digitalOutput.set(LOW);
    delay(200);
  }
}

If you have any comments or suggestions please let me know.  I'm still tinkering with this, but I think at the very least the interface that exists will be compatible with future versions.
7  Forum 2005-2010 (read only) / Development / Re: shiftOut code and double not (!!)? on: January 22, 2008, 04:02:37 pm
or (val >> i) != 0
8  Forum 2005-2010 (read only) / Troubleshooting / Re: Add on serial port - parts questions on: January 08, 2008, 04:04:10 pm
Might you post a link to the site?

Thanks!
9  Forum 2005-2010 (read only) / Interfacing / Re: Wireless Arduino on: January 29, 2008, 07:48:12 pm
Those little $14 wireless pairs are probably not the best solution for a hovercraft.  I've been working with mine for the last two weeks (off and on) and they are difficult to deal with.
10  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: February 02, 2008, 01:42:10 pm
ZingBerra,
   I'm happy that it's working for you!  This code really needs quite a lot of help, and isn't nearly robust nor general enough to be refactored into a library, yet.  I'll be working on making this more release quality in the next short while.  This project is moving slower than I anticipated as my free time seems to evaporate from beneath me.  smiley-grin
11  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: February 01, 2008, 05:08:53 pm
Ok, this is still very far from finished.  Very far...

The Tx side of things just prints the numbers from 0-254 to the air.

Tx:
Code:
/*********************************\
 *  Author: Dustin Johnson       *
 *  E-mail: Dustin@Dustinj.us    *
 *  Date: February 1, 2008       *
\*********************************/

#define _delay delayMicroseconds
#define DELAY 1000
#define OUTPUT_PIN 7
byte last = 0;

void print_byte(int pin, byte input_byte) {
  int i;
  
  for (i=0; i<8; i++) {
    if (((input_byte >> i) & 1) != last) {
      last = !last;
      digitalWrite(pin, last);
    }
    _delay(DELAY);
  }
  
  // Parity bits
  input_byte ^= input_byte >> 4;
  input_byte ^= input_byte >> 2;
  input_byte &= 0x3;
  for (i=0; i<2; i++) {
    if (((input_byte >> i) & 1) != last) {
      last = !last;
      digitalWrite(pin, last);
    }
    _delay(DELAY);
  }
}

void print_preamble(int pin) {
  for (int i=0; i<7; i++) {
    if (((0x5B >> i) & 1) != last) {
        last = !last;
        digitalWrite(pin, last);
    }
    _delay(DELAY);
  }
}

void wireless_print(int pin, byte input_byte) {
  print_preamble(pin);
  print_byte(pin, input_byte);
  digitalWrite(OUTPUT_PIN, LOW);
  last = 0;
}

void setup() {
  pinMode(OUTPUT_PIN, OUTPUT);
  digitalWrite(OUTPUT_PIN, LOW);
}

void loop() {

  for (byte i=0; i<254; i++) {
    wireless_print(OUTPUT_PIN, i);
    delay(10);
  }
}

The Rx side of things gets the numbers from the air and prints them to the serial port (that you can see with the built in Serial Monitor or Hyperterminal or anything else...) at 115200 baud.

Rx:
Code:
/*********************************\
 *  Author: Dustin Johnson       *
 *  E-mail: Dustin@Dustinj.us    *
 *  Date: February 1, 2008       *
\*********************************/

#define DELAY 1000
#define GRACE 150
#define LOWER_BOUND (DELAY-GRACE)
#define UPPER_BOUND (DELAY+GRACE)
#define INPUT_PIN 2

void setup() {
  Serial.begin(115200);
  pinMode(INPUT_PIN, INPUT);
}

void loop() {
//#define _PRINT_DEBUG
#ifndef _PRINT_DEBUG
  unsigned long read_bits;
  boolean timed_out;
  boolean current_bit;
  byte last_state = digitalRead(INPUT_PIN);
  unsigned long start_time = millis() + 500;

  timed_out = true;
  while(millis() < start_time) {
    unsigned int length = pulseIn(INPUT_PIN, HIGH);
    if (length >= LOWER_BOUND*2 && length <=UPPER_BOUND*2) {
      length = pulseIn(INPUT_PIN, LOW);
      if (length >= LOWER_BOUND && length <=UPPER_BOUND) {
        timed_out = false;
        break;
      }
    }
  }

  if (timed_out == true) {
    return;
  }

  delayMicroseconds (DELAY/2);

  timed_out = true;
  while(millis() < start_time) {
    read_bits = (read_bits >> 1) | (digitalRead(INPUT_PIN) << 6);
    delayMicroseconds(DELAY);
    if ((read_bits & 0x78) == (0x5B & 0x78)) {
      timed_out = false;
      break;
    }
  }

  if (timed_out == true) {
    return;
  }

  read_bits = 0;  
  for (int i=0; i<10; i++) {
    current_bit = digitalRead(INPUT_PIN);
    read_bits |= (current_bit << i);
    delayMicroseconds(DELAY);
  }

  // Parity check
  byte check = (read_bits & 0xFF);
  check ^= check >> 4;
  check ^= check >> 2;
  check &= 0x3;
  if (check == ((read_bits >> 8) & 0x3)) {
    Serial.println((read_bits & 0xFF), DEC);
  } else {
    Serial.print('\n');
  }

#else
  unsigned long test[60];
  
  Serial.println("Starting!");
  for (int i=0; i<60; i+=2) {
    test[i] = pulseIn(INPUT_PIN, LOW);
    test[i+1] = pulseIn(INPUT_PIN, HIGH);
  }
  
  for (int i=0; i<60; i++) {
    if (i%2 == 1) {
      Serial.print("1 - ");
      if (test[i] >= LOWER_BOUND && test[i] <=UPPER_BOUND){
        Serial.print("S ");
      }
    }else{
      Serial.print("0 - ");
    }
    Serial.println(test[i], DEC);
  }
#endif
}

Anyhow I'll have more time in a few days to get back to this.... hopefully!   smiley-razz
12  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: February 01, 2008, 12:04:55 pm
I'm sure.  The library that I am writing doesn't use manchester encoding at all.  My experience of how the Rx/Tx pairs work is you just raise the Tx pin and the Rx pin goes high too.  Now, there are some serious issues with timing, bit slicing, and noise but mine work as I described.  I have an ancient oscilloscope that I've been working with and it is clear to see that the Rx/Tx pair just raises the pin when you do, except for some noise.
13  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: February 01, 2008, 10:54:23 am
I've been working on my wireless stuff, the last few days.  While it certainly isn't complete (and it also isn't manchester encoded) I'll try and post the code today.

I've decided that manchester encoding was not needed in this case.  The pairs don't specifically need it and I can get double the bitrate without it.  Also, I found it sufficient to print 6 bits of preamble before the data byte to lock onto the clock.  I then followed up the data byte with two bits of Frame Check Sequence.  This allows me to transmit with an overhead of only 100%.  If I was to use manchester encoding as well, my overhead would be 300%.

Anyhow, these wireless things are very difficult to work with.   smiley-grin
14  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 22, 2008, 12:32:59 am
Quote
so the expression:
   (curdata >> 16)  
is no different from
  ((curdata >> 16) & 0xFFFF)

Yes, that is surely the way that it should be.  However, I really don't understand why yerg2k was getting the results he was.  My suspicion is that there is something very odd with how 32bit values are handled.  My mask was just an added layer of insurance that the value was actually 16bit and that the compiler wasn't doing something stupid like moving the value pointer back two bytes.
15  Forum 2005-2010 (read only) / Interfacing / Re: Manchester encoding algorithm and library on: January 21, 2008, 06:07:01 pm
I really don't know how it works like this.  If curdata == 0xAAAA5555 and you put it through

Code:
((curdata >> 16) == ~(curdata & 0xFFFF))

then (curdata >> 16) = 0x0000AAAA
and ~(curdata & 0xFFFF) = 0xFFFFAAAA

this is because curdata & 0xFFFF evaluates first giving 0x00005555, then the ~ is evaluated giving 0xFFFFAAAA.

I don't understand how that expression can ever evaluate to true. smiley-sad  If somebody knows that part of the puzzle please let me know!  [smiley=huh.gif]

you might want to try something like this:
Code:
(((curdata >> 16) & 0xFFFF) == (~curdata & 0xFFFF))
Pages: [1] 2