Hi,
I'm working on something similar...
At the moment I have an arduino ethernet as base which controls via i2c one pca9586 (16channel PWM driver) and one pca8575(16 channel i2c expander, outputs used as switches).
To control low voltage devices (PWM, led stripes, 12V DC halogen lamps etc) I use a MOSFET as driver. For 230V AC devices I will use solid state relais with integrated optical coupler for safety.

The whole thing is controlled via ethernet from a webserver which also visualizes the actual state.

For the future I plan:
- Spoken feedback
- Voice recognition
- Intelligent light controlling if e.g. I leave the room and re-enter the room
- Heater controlling
- some degree of "learning"

more pictures....

setup:

atmega 2560 ---- touchOSC ---- Processing

2 rgb Led strips

2 UV Led strips

2 light dimmers

future ir control (trying to make it work right)
future voice control (Processing Voce library)
future temperature/humidity/light sensors...


send me a PM if someone whats some of the code (arduino/processing) or more info

(again sorry for my english)

[--prefix]

Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr

You are correct about that output. I get that also. I have to be honest, you present a good case except for the "Configured with:" stuff above. I'm not certain about these parameters and what they do:
--prefix=/usr/lib
--bindir=/usr/bin
--libdir=/usr/lib

Does that means this is supposed to use the executable binaries in /usr/bin and libraries in /usr/lib?

No these parameters have only been important during building the toolchain itself on running e.g. make install after successful building it:

--prefix the path all paths are prefixed for generating default values
--libdir the path where the libraries and object files would have been stored
--bindir the path where the executables would be installed

Ironically you can overwrite all of these on the commandline and the linker will anyway search the system paths for executables and libraries so these values can be misleading (which they do in this case).

regards

You may be correct if you use your commandline, but what does the IDE tells you if you do compile ?
The unchanged downloaded version tells me the following:

Code:

/home/drizzt/Programme/arduino-1.0.1/hardware/tools/avr/bin/avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=16000000L -MMD -DUSB_VID=null -DUSB_PID=null -DARDUINO=101 -I/home/drizzt/Programme/arduino-1.0.1/hardware/arduino/cores/arduino -I/home/drizzt/Programme/arduino-1.0.1/hardware/arduino/variants/standard -I/home/drizzt/Programme/arduino-1.0.1/libraries/SPI -I/home/drizzt/Programme/arduino-1.0.1/libraries/Ethernet -I/home/drizzt/Programme/arduino-1.0.1/libraries/Metro -I/home/drizzt/Programme/arduino-1.0.1/libraries/Flash -I/home/drizzt/Programme/arduino-1.0.1/libraries/Wire -I/home/drizzt/Programme/arduino-1.0.1/libraries/Adafruit_PWMServoDriver /tmp/build7825702190261685714.tmp/cd_regal_controller_tcp.cpp -o /tmp/build7825702190261685714.tmp/cd_regal_controller_tcp.cpp.o

and if I run

Code:

/home/drizzt/Programme/arduino-1.0.1/hardware/tools/avr/bin/avr-g++ -v

from the commandline I get the following output

Code:

Using built-in specs.
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --disable-libssp --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=avr
Thread model: single
gcc version 4.3.2 (GCC)

Whereas the following command

Code:

avr-g++ -v

gives the following results

Code:

Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/avr/gcc-bin/4.5.3/avr-g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/avr/4.5.3/lto-wrapper
Ziel: avr
Konfiguriert mit: /var/tmp/portage/cross-avr/gcc-4.5.3-r2/work/gcc-4.5.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/avr/gcc-bin/4.5.3 --includedir=/usr/lib/gcc/avr/4.5.3/include --datadir=/usr/share/gcc-data/avr/4.5.3 --mandir=/usr/share/gcc-data/avr/4.5.3/man --infodir=/usr/share/gcc-data/avr/4.5.3/info --with-gxx-include-dir=/usr/lib/gcc/avr/4.5.3/include/g++-v4 --host=x86_64-pc-linux-gnu --target=avr --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-ppl-version-check --with-cloog-include=/usr/include/cloog-ppl --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --disable-libgomp --with-python-dir=/share/gcc-data/avr/4.5.3/python --enable-checking=release --disable-libgcj --enable-languages=c,c++ --enable-shared --disable-threads --disable-bootstrap --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.3-r2 p1.1, pie-0.4.7'
Thread-Modell: single
gcc-Version 4.5.3 (Gentoo 4.5.3-r2 p1.1, pie-0.4.7)

As one clearly can see the stock IDE is not using the system wide compiler as long as the bundled one hasn't been disabled. I disable it by renaming

Code:

/home/drizzt/Programme/arduino-1.0.1/hardware/tools/avr

to

Code:

/home/drizzt/Programme/arduino-1.0.1/hardware/tools/avr.orig

It can also be removed.

This is one of the reasons why I choose the title 'pitfalls' since these things are not obvious if you do not inspect the compiler output carefully and start to wonder why your perfect running code starts to fail.

regards

Hi,
please read carefully. The built-in or bundled toolset of the IDE-1.0.1 download contains gcc-4.3.2. My own(gentooish) toolset is gcc-4.5.3 based. I could even try to use gcc-4.6.3 but I haven't had the time to test.

The problem with WString.h can be triggered by using:

Code:

Serial.print(F("Hello"));

with the linux version which can be downloaded from here.

Which OS are you running on ?
Maybe you recently changed the toolchain ?
I had on linux similar problems which where toolchain related. Maybe this helps you: http://arduino.cc/forum/index.php/topic,95741.msg734762.html#msg734762

regards

[arduino-1.0.1/hardware/arduino/cores/arduino/WString.h]

Just wanted to share my experience with new IDE-1.0.1 running on Gentoo AMD64 Linux.

If I use the built in toolset (avr-* version 4.3.2 I think) my sketch doesn't work anymore. It compiles fine, but there is missing some data (binary is about 400 bytes smaller).
First investigation suggests that the FLASH-Library (http://arduiniana.org/libraries/flash/) and the F()-macros seem not to work.
Warnings regarding the Flash-Library look like this:

Code:

In file included from ~/Programme/arduino-1.0.1/libraries/Flash/Flash.cpp:21:
~/Programme/arduino-1.0.1/libraries/Flash/Flash.h:68: warning: ‘__progmem__’ attribute ignored
~/Programme/arduino-1.0.1/libraries/Flash/Flash.h:91: warning: ‘__progmem__’ attribute ignored
~/Programme/arduino-1.0.1/libraries/Flash/Flash.h: In member function ‘char* _FLASH_STRING::copy(char*, size_t, size_t) const’:
~/Programme/arduino-1.0.1/libraries/Flash/Flash.h:75: warning: comparison between signed and unsigned integer expressions
~/Programme/arduino-1.0.1/libraries/Flash/Flash.h: At global scope:
~/Programme/arduino-1.0.1/libraries/Flash/Flash.h:181: warning: ‘__progmem__’ attribute ignored
~/Programme/arduino-1.0.1/libraries/Flash/Flash.h:201: warning: ‘__progmem__’ attribute ignored
~/Programme/arduino-1.0.1/libraries/Flash/Flash.cpp:23: warning: ‘__progmem__’ attribute ignored

And warnings regarding the F()-macro look like this:

Code:

cd_regal_controller_tcp.cpp:385: warning: only initialized variables can be placed into program memory area

Size: 18.148 Bytes

If I use my own toolchain (http://arduino.cc/forum/index.php/topic,95741.msg734762.html#msg734762) everything works fine.

Size: 18.580 Bytes

Also it was necessary to apply a fix to arduino-1.0.1/hardware/arduino/cores/arduino/WString.h:

Code:

class __FlashStringHelper;
//#define F(string_literal) (reinterpret_cast<__FlashStringHelper *>(PSTR(string_literal)))
#define F(string_literal) (reinterpret_cast<const __FlashStringHelper *>(PSTR(string_literal)))

Otherwise the compiler complains about reinterpret_cast discarding some qualifiers.

Regards

Danke für die schnelle Antwort.
Werd mir das mal genauer anschauen.

Grüße
Naxi

Hallo,
kennt jemand von euch ein Portal oder ähnliches, wo man sein (Hardware) Projekt vorstellen und gemeinsam entwickeln kann ?
Ich habe vor ein größeres Projekt in Angriff zu nehmen und will dazu möglichst vielen Gleichgesinnten die Möglichkeit geben es überhaupt zu finden, mitzuarbeiten und mitzuentwickeln.

Sowas wie ein "Collaboration Space" mit Website(vll. Blog) und Dokumentenablage.

Grüße
Naxi

[Edit sagt:]

Also,
Schaltbild hab ich keins gezeichnet, weil alles fertige Komponenten.

Das Schaltbild des MOSFET-Powerkits gibts hier: http://www.sparkfun.com/datasheets/Components/General/MOSFET-Power-Control-v10.pdf

Das Sketch funktioniert, eine einzelne TestRGB-LED macht exakt das, was sie soll: Man kann mittels udp Paket 3 PWM Ausgänge des Arduino-Ethernet steuern, bzw. Sequenzen ablaufen lassen.

Als nächsten Schritt will ich die TestRGB-LED durch einen RGB Stripe ersetzen.
Da der kleine Arduino das aber nicht aushält, bzw. auch keine 12V liefert, brauch ich was, dass in Abhängigkeit des PWM Ausganges die 12V "steuert".

Dazu wollte ich das Eingangs bereits erwähnte MOSFET-Powerkit verwenden.

LG Anaximander

Edit sagt:
Ich habe mal die GNDs der beiden Netzteile (Arduino und LED) verbunden und nu funktionierts. Verbesserungsvorschläge trotzdem immer gerne gesehen.

Hallo,
ich möchte mit meinem Arduino u.a. RGB-LED Stripes ansteuern. Dazu hab ich mir von SparkFun drei MOSFET-Kits (http://www.sparkfun.com/products/10256) gekauft.

Nun mein Problem:
Am 2 Pin Header hängt zum Test eine 5V-fähige LED. Am 3 Pin-Header habe ich an "+" und "-" eine 5V Spannungsquelle angeschlossen. Wenn ich den Anschluß "C" an den Arduino anschliesse, passiert genau gar nichts. Wenn ich den "C" testweise mit den +5V verbinde, leuchtet die LED.
Wenn ich statt der Spannungsquelle GND und +5V vom Arduino nehme, leuchtet die LED.

1. Frage: Sehe ich das richtig, dass ich den Arduino und die LED Kette aus dem gleichen Netzteil (gemeinsame GND ??? ) speisen muss ?
2. Frage: Kann man das ändern und wenn ja, wie ? Ich würde gerne die Stromkreise trennen.

Grüße

Hallo,
ich habe deinen Code mal "zerpflückt".
Hier die Fehler:

a)

Code:

#include <Udp.h>

ersetzen durch

Code:

#include <EthernetUdp.h>

b)

Code:

Udp.sendpacket(...)

ersetzen durch

Code:

//Udp.beginPacket(Udp.remoteIP(), Udp.remotePort());
    //Udp.write(<was immer auch für einen text>);
    //Udp.endPacket();

c)

Code:

int packetSize = Udp.available();

ersetzen durch

Code:

int packetSize = Udp.parsePacket();

d)

Code:

Udp.readPacket(packetBuffer,UDP_TX_PACKET_MAX_SIZE, remoteIp, remotePort);  //Liest Daten vom RemotePC in packetBuffer

ersetzen durch

Code:

Udp.read(packetBuffer,UDP_TX_PACKET_MAX_SIZE);

Damit konnte ich es auf der 1.0 kompilieren. Da ich aber weder deine LCD library noch ein LCD besitze kann ich den code leider nicht testen.

Grüße
Anaximander

Basically your problem arises from newest version of binutils. For some reason if no global variable is defined before any program code, the program code begins at wrong address. Besides this the delay()-function sis also broken with latest version of binutils.

Just follow my descriptions in the above mentioned thread and you should get a working avr-toolchain at least on gentoo/amd64.

Any feedback welcome
greetings

Hm good question. the toolchain builder is the one from the repository and it's fetching recent versions of avr* packages. I'm not informed enough to make any guesses why it isn't fixed yet...

Sadly, all infos I used are already reported bugs 
What do you mean with performance improvement ?

greetings

I don't know where the port assignments, preferences etc are stored on win installations but if we assume they're stored as ini-files inside the arduino installation you would have to install the arduino ide twice in different directories because if not one instance would override the configuration(port, type etc) of the other instance.