Support Thread for Seeeduino

End-Of-Life Products & Services Tech support before 2012
#1

Seeeduino v1.1

Overview
Seeeduino is Arduino compatible board. Its design is based on Diecimila scheme, 100% compatible to its existing program, shield and IDEs. On the hardware part, remarkable changes are taken to improve the flexibility and user experience.

Schematic & Reference Design
EAGLE Schematic file: clickto downlaod
EAGLE PCB file: clickto download

Product page >>here.

#2

Hello,
This looks nice - I was wondering though, you have 3 switches, of which 2 you have described. What is the purpose of the third switch? I am guessing power source? Or something else new? :slight_smile:
Thanks!

#3

Thanks, the third one is the switch for USB/EXT power source source.

#4

Would it be possible to have Eagle-files for Seeduino v1.0b?
It seems that V1.0b files were replaced with v1.1

thanks,

#5

You may download them here:
seeedstudio.com/depot/datash … 090815.rar

Thanks for reminding! :slight_smile:

#6

Very nice arduino implementation.

I’m very interested in the 3V mode. How did you get that to work? I only see 1 voltage regulator on the board. What about the clock frequency- is still 16Mhz for both 5V and 3V? Will it work with both USB and EXT power?

Also, it’s hard to tell from the picture, but is there actually room for both sets of headers on the digital pins? Or do you have to pick one or the other?

Thanks,

#7

The 3.3V voltage is supplied via FT232 chip, you may use them either USB or EXT powered. We tested every board under 3.3v before release.

Atmega168 will work in 3.3V, 16Mhz in a narrower temperature range. You may refer to the datasheet, atmel.com/dyn/resources/prod … oc2545.pdf : Figure 29-2.
Also, a discussion here: atmel.com/dyn/resources/prod … oc2545.pdf .

Note: the 50mA current is limited by FTDI output, thus Seeeduino can’t take much load but prefer control or communicate with 3.3v devices only.

There is enough room for both row of pins, the Arduino compatible pin set is pre-soldered. You may add the second row yourself, either female or male, top side or bottom side.

Thanks :slight_smile:

#8

Hi, I have received my seeeduino a few days ago; I’ve been testing it out, and overall it has worked very well, but i’ve run into a problem I’m starting to believe to be hardware related.
Please see http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1227395987 for more details.
Is it possible that I somehow have a faulty board? Or is it a hardware quirk I’m unaware of?
Thank you for your time!

#9

dsc - It might be hardware problem, but more likely caused by software environment.

Do you have other Arduino board to try it out? We have tested it with several Seeeduino and Arduino Duemilanove, they are all OK with the code.

Maybe you could try install a different version of Arduino IDE. Also, a description of your system configuration would be helpful. Thanks:)

#10

Thanks for the tip! I’m running Ubuntu linux, and it seems this is indeed a IDE problem since different versions produce different (bad) results.
However in windows it works exactly as expected, so it is surely not a hardware problem!
I’d rather not have to use windows though >.<
Thanks again! :wink:

#11

I seem to be having problems with connecting to my seeeduino via usb.

I can connect to it but not consistently, approx 9/10 times I get:

[ 3581.747908] usb 1-2: new full speed USB device using uhci_hcd and address 97
[ 3581.869529] usb 1-2: device descriptor read/64, error -71
[ 3582.088561] usb 1-2: device descriptor read/64, error -71

so I have to pull the cable out and try again…

I’m running ubuntu on an eepc, usb ports work fine for other peripherals. Furthermore, the cable I’m using with fine with my phone, so both of those can be ruled out.

Is this normal behavior or am I doing something wrong?

#12

Hi dikkie

We don’t have ubuntu around, since it is working 1/10 I think there might be some confliction. To isolate the problem, you may find a PC running windows to try your Seeeduino, if it’s working please remove all other usb devices and reinstall the driver.

Here are some link might be helpful,

ubuntuforums.org/showthread.php?t=797789
mepis.org/node/5860

#13

sorry for delayed replay, been trying to use other computers, I’ve tried it on a vista machine and ubuntu pc, both work fine with other usb devices but not with my seeeduino… any other ideas??

#14

Any notification after you install the hardware? Does the leds on board lit?

Please try the newest driver for vista support: ftdichip.com/Drivers/CDM/CDM%202.04.14.zip
And Linux version: ftdichip.com/Drivers/VCP/Lin … sio.tar.gz

This post might be of help: arduino.cc/cgi-bin/yabb2/YaB … 27655095/3

Thanks! :slight_smile:

#15

I’ve solved it - the middle pin on the mini usb port of the seeduino was flatter than the others, using a pin I managed to bend it to be the same shape as the others, connect is still a bit hit and miss but is a lot better ( 9 out of 10 rather that 1 out of 10 ).

#16

thanks for your all your help ESP.

and for anyone who is wondering the seeeduino does work with eeebuntu without any hassle ( as long you don’t have problems with the usb port that is!!! )

#17

Dikkie - this is a cause we have never thought about… Glad to hear that you have resolved it. Thank you for all the efforts to isolate the problem and clarify with us!

#18

G’day All,

I have been trying to get my seeeduino to talk to a iRobot Create (basically a roomba with the cleaning part ripped out, and catered to hobbyists), with the following code:

void drop_baud_rate()
{
  int brcPin = 7;
  pinMode(brcPin, OUTPUT);
  digitalWrite(brcPin, HIGH);
  delay(2000);
  for(int i = 0; i < 3; ++i)
  { 
    digitalWrite(brcPin, HIGH);
    delay(100);
    digitalWrite(brcPin, LOW);
    delay(100);
  }
  digitalWrite(brcPin, HIGH);
}

void enter_full_mode()
{
  int ledPin = 13;    
  pinMode(ledPin, OUTPUT);  
  Serial.print(128, BYTE);  // START
  delay(50);
  Serial.print(132, BYTE);  // CONTROL
  delay(50);
  digitalWrite(ledPin, HIGH);
}

void setup() 
{ 
  drop_baud_rate();
  delay(4000);
  Serial.begin(19200);
  
  enter_full_mode();
  
  int bytes[]={139, 2, 0, 0 };

  
  for(int i=0; i < sizeof(bytes)/sizeof(int); ++i)
  {
    Serial.print(bytes[i], BYTE);
  }
} 

void loop() 
{ 
}

The code above first tells the Create to drop baud rate to 19200 from 57600, then after waiting for a little, tells the Create to enter full user controlled mode and then turns the play LED on.

Now if I load the above code without the drop_baud_rate() call on my seeeduino, the Create doesn’t get the bytes properly, and the play LED never comes on. With the drop_baud_rate() call however, the play LED comes on as expected. The strange thing is on a Arduino Duemilanove the code works reliably without the drop_baud_rate() call, suggesting that the seeeduino suffers from a timing problems which isn’t present on the Duemilanove.

I am not sure what would cause this, and I would like to ideally not have to drop the baud rate down to 19200. Is there anything in the seeeduino’s design that would cause its UART to fail to operate at 57600 baud? It seems like there is something in the seeeduino’s design that is causing slight timing issues which is ruining serial communication.

Cheers,
Steve

#19

Hi Steve

We have test the serial communication.It’s work well.

Try this code

 void drop_baud_rate()
{
  int brcPin = 7;
  pinMode(brcPin, OUTPUT);
  digitalWrite(brcPin, HIGH);
  delay(2000);
  for(int i = 0; i < 3; ++i)
  { 
    digitalWrite(brcPin, HIGH);
    delay(100);
    digitalWrite(brcPin, LOW);
    delay(100);
  }
  digitalWrite(brcPin, HIGH);
}

void enter_full_mode()
{
  int ledPin = 13;    
  pinMode(ledPin, OUTPUT);  
  Serial.println(128, DEC);  // START
  delay(50);
  Serial.println(132, DEC);  // CONTROL
  delay(50);
  digitalWrite(ledPin, HIGH);
}

void setup() 
{ 
  drop_baud_rate();
  delay(4000);
  Serial.begin(19200);
  
  enter_full_mode();
  
  int bytes[]={139, 2, 0, 0 };
  
  for(int i=0; i < sizeof(bytes)/sizeof(int); ++i)
  {
    Serial.println(bytes[i], DEC);
  }
} 

void loop() 
{ 
}

Got the data you expect,right?

Albert

#20

Yep, the data is exactly as expected.

I do not believe it is a problem with the code, since

  1. the code works exactly as expected
  2. the exact same code works fine on an official arduino without needing drop_baud_rate() being called.

The only issue is the fact I can not communicate properly at 57600 baud rate, while an official arduino can. I can only attribute this to a timing issue - either with the seeeduino, or the particular arduino board I was testing with. I will try with yet another arduino board to confirm it is a seeeduino only problem. It is entirely possible the arduino board, not seeeduino, is the anomaly.

Cheers,
Steve