Does anyone know what makes this compatible with Arduino sketches? I suspect that the Arduino sketch has to target the Duo and perhaps the M0 and M3 share the Thumb-2 instruction set, but the M0 uses a "subset" of that instruction set. So I am wondering how compatibility is guaranteed. If they said that the M3 would run code target to the M0 I would say that makes sense, but I'm not so sure about the reverse.
 

Many good choices. If you want wireless, there is bluetooth, bluetooth low energy, wifi, XBee, and a bunch of other stuff. Your specific application may dictate the best choice.

I'm not sure I am following you exactly, but the wifi shield essentially provides a medium over which you can move data using a few different protocols. Did you mean to say that Matlab can receive the data via a TCP socket? If so, you'll have to connect tp that socket by writing code on the Uno, then you'll have to format the data in the wat Matlab wants to receive it, then send it.

If you can do anything you want, you have many options. You could make the Uno look like a web server and have an http client get the data from the Uno. The Uno could be an http client and do a PUT or POST to a web server. You could open a socket to some other computer and send the data. You could use a protocol called UDP to just shoot the data at another device which can receive it. (TCP can guarantee delivery, UDP can not).

There is even a website, called something like Pachu (I tried to Google it, no luck) that lets you POST data to it, and it will log and graph it for you.

So your question is a bit complex. But basically, once you have the wifi shield working and connected to something, you need to write the code that moves the data.

Awesome thread! I did notice this:

http://www.embeddedartists.com/support/faq.php?id=29

It seems that these displays are not suitable for production, which of course makes me wonder what they are suitable for.

The Eagle messages can be a bit confusing, but what's to fear? Just back up the files before you make the change so you can revery back if you mess it up.

The "best" one is the one I am working on, since it does not yet exist. It will:

- Allow operation as an access point
- Have a web server built in
- Have extra memory for storing web content
- Talk to the Arduino host board using I2C or SPI (or both) in addition to offering the UART.

So far, I have yet to find this. There are a few based on the Ganispan 1.2 device, but this has limitations that prevent it from using the latest GS firmware. The official Arduino wifi shield uses SPI, which is great, but the HDG104 has limitations that prevent it from meeting my needs.

Its been frustrating, but I determined that I need to build my own.


 

I just backed that. Looks pretty cool, I'll find some use for it.

CrossRoads can be a huge help ;-)

I agree, the electronics and firmware is the easy part. The enclosure is the hard part. Best to use an off the shelf enclosure if you can. If not, have a look at shapeways.com.

The hardest, and possibly the most expensive part, is certification. Europe and Japan need "CE Certification." Depending upon what you're building, you may be able to "self certify" but you may have to pay a "noted agency" to certify it for you.

In the US, if your clock speed exceeds some amount (I think 7 MHz) you'll need FCC certification. Similar deal.

 

I have had great service using these guys:

http://www.internationalcircuits.com/

You can price your order on their site easily, and depending upon your board size and quantity, it can be a very good deal.

I needed to do something similar, although a bit more complex. The code pasted below should help you out.

Code:

#include "Pulser.h"

Pulser::Pulser(uint8_t pin, unsigned long debInt) : Bounce(pin, debInt)
{
  // Initialize private members
  shortPressCount = 0;
  flag = false;

  SHORT_PRESS_INTERVAL = 500;
  LONG_PRESS_DURATION = 1000;
 
  // Set up the input pin
  pinMode(pin, INPUT);
 
  //digitalWrite(pin, HIGH); // Activate internal Pull-Up
  digitalWrite(pin, LOW); // Deactivate internal Pull-Up
}

Pulser::~Pulser(){}

short Pulser::get(void)
{
  // Get the current status of the button. This needs to be done
  // very frequently, so every loop iteration 
  update();

  // Read the button condition and return the state
  if(!read()) // If button is pressed
  {
    // Note the last time the button was pressed
    lastPressMs = millis();
   
    // Record the duration of this press
    dur = duration();

    // Flag that we have an unread pressed button
    flag = true;
   
    // Return 0, since we don't know anything about this press
    // until the user releases it and we look to see what other
    // presses happened recently
    return 0;
  }

  // Button is not currently pressed. Check duration of last press
  if(dur > LONG_PRESS_DURATION)
  {
    // Long press - clear the short press counters since this cancelles
    // the short press history
    if(flag)
    {
      shortPressCount = 0; // clear the short presses counter

      flag = false; // clear the we-have-a-press-to-read flag
      return 0x10; // return the state for a long press
    } 
  }
 
  // It was not a long press, so we look for a short press series

  // Was there a press within the last 1/4 second?
  // If not, clear the counter and return the number
  // of presses in the series. If so, record the press
  // and return 0, waiting for the next press of the series
  // or the user to be done pressing.
  if(millis() - lastPressMs < SHORT_PRESS_INTERVAL)
  {
    // We are still in a series of presses
    if(flag) // do we have a press to read?
    {
      shortPressCount++;
      flag = false;
    }
    return 0; 
  }
  else
  {
    // No press within the last 1/4 second. we are done with
    // this series of short presses. Or, there is no current series
    // which is effectively a series of 0 presses
    short temp = shortPressCount;
    shortPressCount = 0;
    flag = false;
    return temp;
  } 
} 
 

Code:

#include "Pulser.h"

Pulser::Pulser(uint8_t pin, unsigned long debInt) : Bounce(pin, debInt)
{
  // Initialize private members
  shortPressCount = 0;
  flag = false;

  SHORT_PRESS_INTERVAL = 500;
  LONG_PRESS_DURATION = 1000;
 
  // Set up the input pin
  pinMode(pin, INPUT);
 
  //digitalWrite(pin, HIGH); // Activate internal Pull-Up
  digitalWrite(pin, LOW); // Deactivate internal Pull-Up
}

Pulser::~Pulser(){}

short Pulser::get(void)
{
  // Get the current status of the button. This needs to be done
  // very frequently, so every loop iteration 
  update();

  // Read the button condition and return the state
  if(!read()) // If button is pressed
  {
    // Note the last time the button was pressed
    lastPressMs = millis();
   
    // Record the duration of this press
    dur = duration();

    // Flag that we have an unread pressed button
    flag = true;
   
    // Return 0, since we don't know anything about this press
    // until the user releases it and we look to see what other
    // presses happened recently
    return 0;
  }

  // Button is not currently pressed. Check duration of last press
  if(dur > LONG_PRESS_DURATION)
  {
    // Long press - clear the short press counters since this cancelles
    // the short press history
    if(flag)
    {
      shortPressCount = 0; // clear the short presses counter

      flag = false; // clear the we-have-a-press-to-read flag
      return 0x10; // return the state for a long press
    } 
  }
 
  // It was not a long press, so we look for a short press series

  // Was there a press within the last 1/4 second?
  // If not, clear the counter and return the number
  // of presses in the series. If so, record the press
  // and return 0, waiting for the next press of the series
  // or the user to be done pressing.
  if(millis() - lastPressMs < SHORT_PRESS_INTERVAL)
  {
    // We are still in a series of presses
    if(flag) // do we have a press to read?
    {
      shortPressCount++;
      flag = false;
    }
    return 0; 
  }
  else
  {
    // No press within the last 1/4 second. we are done with
    // this series of short presses. Or, there is no current series
    // which is effectively a series of 0 presses
    short temp = shortPressCount;
    shortPressCount = 0;
    flag = false;
    return temp;
  } 
} 
 

Yes its a one time investment, as you put it. This is true with any good programming environment, whether you're coding for Arduino, Linux, Windows, whatever. The linker should not include stuff that you didn't use. There are piles and piles of linker switches to configure and customize what's linked, how its linked and so on.

But the bottom line is, once its linked, its linked. You won't incur the same penalty for each call to new.

 

That last part, I never understood what was going on there.

I'll have som time this weekend to write a detailed explanation. I also need to compare these macros to ManiacBug's standard 1284P distribution and see if these are a bug or if there is something going on I am missing.

But on the plus side, the off the shelf Seeed Studios card works killer well on my board! I have to use SoftwareSerial but, the shield has a UART on it so I believe that I should not have a problem. The thing has been blasting data via bluetooth to my phone all night.

Of course, its BT 2.1, not BLE. Android needs BT 2.1 and Apple iOS needs BLE. What a pain!
 

I made a lot of progress...

As I mentioned, I had modified the SoftwareSerial library under Arduino v0.22 to work with what at the time we called the Sanguino which was based on the 644P, and has the same pin out as the 1284P.

maniacBug had released his 1284P support, and I had asked him to do a version that matched the pin out nomenclature of the AVR Developers 1284P support, which he did. So i don;t know if the issue I had related to the Maniacbug 1284P or the AVR Dvelopers 1284P, but I'll get to the bottom of it.

In case anyone is interested, the changes I made are in pins_arduino.h. I have not checked yet to make sure i didn't break anything else. I suspect I probably did, but we'll see.

Here is the original:

Code:

#define digitalPinToPCICR(p)    (((p) >= 0 && (p) < NUM_DIGITAL_PINS) ? (&PCICR) : ((uint8_t *)0))
#define digitalPinToPCICRbit(p) (((p) <= 7) ? 1 : (((p) <= 15) ? 3 : (((p) <= 23) ? 2 : 0)))
#define digitalPinToPCMSK(p)    (((p) <= 7) ? (&PCMSK2) : (((p) <= 13) ? (&PCMSK0) : (((p) <= 21) ? (&PCMSK1) : ((uint8_t *)0))))
#define digitalPinToPCMSKbit(p) ((p) % 8)

Here are my changes:

Code:

#define digitalPinToPCICR(p)    (((p) >= 0 && (p) <= 31) ? (&PCICR) : ((uint8_t *)0))
#define digitalPinToPCICRbit(p) (((p) <= 7) ? 1 : (((p) <= 15) ? 3 : (((p) <= 23) ? 2 : 0)))
#define digitalPinToPCMSK(p)    (((p) <= 7) ? (&PCMSK1) : (((p) <= 15) ? (&PCMSK3) : (((p) <= 23) ? (&PCMSK2) : (((p) <= 31) ? (&PCMSK0) : ((uint8_t *)0)))))
#define digitalPinToPCMSKbit(p) (((p) <= 7) ? (p) : (((p) <= 15) ? ((p) - 8) : (((p) <= 23) ? ((p) - 16) : ((p) - 24))))

I suspect this related to pin change interrupts. I now recall that I had to modify the original SoftwareSerial library to support the 1284P, so I'm now chasing this in the new library :-(

Hi All...

I am playing with the Seed Studio Bluetooth shield, bought up the road at Radio Shack. I am testing it on two different boards, an Uno and my own 1284P board.

On the Uno, the code below works well, letting me exchange text with my Android phone.

On the 1284P board, I can send text to the phone, but data sent from the phone is not displayed on the terminal, leading me to believe that it is not actually being received.

I have checked the schematic and verified that the pins are correct. I even reversed which were the TX and RX pins, and of course rejumpered the shield, and the problem remained the same, indicating that there is not a hardware problem. I have also tried it with and without the internal pullup enabled.

Any ideas?

Thanks...

Code:

#include <SoftwareSerial.h>   //Software Serial Port

// Use these for 1284P board
#define RxD 14
#define TxD 15

// Use these for Uno
//#define RxD 6
//#define TxD 7

#define DEBUG_ENABLED  1
 
SoftwareSerial blueToothSerial(RxD,TxD);
 
void setup()
{
  Serial.begin(9600);

  pinMode(RxD, INPUT);
  digitalWrite(RxD, HIGH); // enable pullup

  pinMode(TxD, OUTPUT);
 
  setupBlueToothConnection();
}
 
void loop()
{
  char recvChar;

  while(1){
    if(blueToothSerial.available()){//check if there's any data sent from the remote bluetooth shield
      recvChar = blueToothSerial.read();
      Serial.print(recvChar);
    }
    if(Serial.available()){//check if there's any data sent from the local serial terminal, you can add the other applications here
      recvChar  = Serial.read();
      blueToothSerial.print(recvChar);
    }
  }
}
 
void setupBlueToothConnection()
{
  blueToothSerial.begin(38400); //Set BluetoothBee BaudRate to default baud rate 38400
  blueToothSerial.print("\r\n+STWMOD=0\r\n"); //set the bluetooth work in slave mode
  blueToothSerial.print("\r\n+STNA=SeeedBTSlave\r\n"); //set the bluetooth name as "SeeedBTSlave"
  blueToothSerial.print("\r\n+STOAUT=1\r\n"); // Permit Paired device to connect me
  blueToothSerial.print("\r\n+STAUTO=0\r\n"); // Auto-connection should be forbidden here
  delay(2000); // This delay is required.
  blueToothSerial.print("\r\n+INQ=1\r\n"); //make the slave bluetooth inquirable
  Serial.println("The slave bluetooth is inquirable!");
  delay(2000); // This delay is required.
  blueToothSerial.flush();
}