text:
Writing First Library - Serial Stream Object
I have done quite a few projects with Arduino, but have never done more than a "Hello World" in C. I am writing my first library, and a lot of the object oriented stuff is going over my head. Anyway, my library is working as it is supposed to, I pass a float to my function and it formats it properly and sends it out over serial. However, I implemented it in a clunky way. The Arduino API Style Guide mentions a way that seems much better:

When using serial communication, allow the user to specify any Stream object, rather than hard-coding "Serial". This will make your library compatible all serial ports on Mega and the Due, and can also use alternate interfaces like SoftwareSerial. The Stream object can be passed to your library's constructor or to a begin() function (as a reference, not a pointer). See Firmata 2.3 or XBee 0.4 for examples of each approach.

Can anybody elaborate on how to do this, or show me some code?

Here is a simple example (built and tested with a mega2560), with a class that can be passed a Stream object, and sends a Hello over this generic stream object. When constructing the object, you can pass the Stream object you want to actually communicate:
#include "Arduino.h"

class MyProtocol
{
public:
    MyProtocol(Stream& s):serial(s){}
    void send(){
        serial.println("Hello");
    }
private:
    Stream& serial;
};

MyProtocol p(Serial);

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

void loop() {
    delay(1000);
    p.send();
}

NOTE: The serial.println() is not the Serial global object, note the lower case, it is the internal Stream class variable.
If you are confused with the OO and classes, take into account (while you gain more knowledge about it) that this approach can be also used with a simple function, you can pass the serial parameter. Furthermore, it is not necessary to hardwire the Serial interface for ever, you can in fact switch in run time and use a different channel depending on some condition:
#include "Arduino.h"

void send(Stream& serial){
    serial.println("Hello");
}

void setup() {
    Serial.begin(9600);
    Serial1.begin(9600);
}

void loop() {
    delay(1000);
    if(someCondition)
        send(Serial);
    else
        send(Serial1);
}

You can also declare the constructor as MyProtocol(Stream& s=Serial):serial(s){} sou you don't need to pass the Serial but you can if you want to. You would build then build the object just as MyProtocol p;

Thanks, this was really helpful, it took some work but I figured it out. You can see the result on my Github.


text:
Opamp for amplifying 1V signal voltage to 2V
I'm doing my first electronics project where a signal that varies between -1 to 1 V is going into an analog pin on the Arduino. The amplified signal has to be read as fast as possible by Arduino. The source signal is at 60 Hz.
Will this LM324 be a suitable 4-channel opamp for my needs? How concerned should I be about the 2 mV input offset and 20 nA input current bias?
To make full use of the 10bit ADC, would you recommend using an opamp with gain of 2 and biasing the signal by +2.5V? If so, will it be better to create the bias using a potential divider across +5V and GND, or using a 2.5V voltage regulator?
Or would it be better to set AREF to 2V and bias the signal by +1V? In this case, will it be better to use a 2V voltage regulator, or a voltage divider across Arduino's 3V3 and GND using 20M and 33M resistors?

A 2mV offset voltage will become a 4mV error after amplification. You haven't shown the schematic for your amplification, but the current bias will also become error after amplification.
That LM324 variant is surface mount, but there are other LM324 variants in a DIP package, which will work fine in a breadboard.

Thanks, would this 14-PDIP version of LM324 be a better choice? (http://www.digikey.com/product-detail/en/LM324N/296-1391-5-ND/277627)

It will have the same specs, it will just be better for breadboarding.

Is it possible to use the opamp to bias the amplified signal by 2.5V? Or will using a potential divider across the ground and +5V pins of the Arduino be the easier route?

It is definitely possibly to bias the signal. You won't want it at exactly 2.5V though, because of the current bias. And in fact, biasing it will remove it from the rails. This is a good thing.

Just an alternate idea I saw: If you dont need high accuracy, you can use a voltage divider to bias -1 to +1 into 0 to 1, and set the analog reference to 1.2, and get almost the same result but skip the op amp.
A voltage divider with 2 equal resistors will give you the voltage halfway between its two inputs. If the bottom of the voltage divider is at 1v, and the top input is at -1, you get 0 out.
If the bottom is at +1, you get 1 out.
I saw a really clever design using 2 1 megaohm resistors, and actually using the aref pin as an output to provide the bias for the divider, setting the reference to the 1.2v setting, putting the signal in the top of the divider and ground and connecting the adc to the output of the divider.
Aref wasnt meant as a current source, but they use 1meg resistors so the current draw will be at most a few microamps.
A filter cap on aref probably draws more than that if vcc is noisy(if there wasnt current to filter we wouldnt need the cap!) So a few uA should be fine.
They put a 1nf capacitor betcan the input and ground to fix the issues with the ADC input current causing voltage drop. It worked up to 100hz. They never tested accuracy because it wasnt needed though. I'd guess that the adc internal reference was the major error source, probably a few percent.
You can also actually bias with a voltage divider to the 5V supply, and get a 0 to ~1.6V output, it's just a little harder to understand.
This simulation explains the concept(5v version)
http://www.falstad.com/circuit/#%24+1+5.0E-6+81.92041607667615+50+5.0+50%0Ar+304+160+304+224+0+1000.0%0Ar+304+224+304+304+0+5000.0%0AR+304+304+256+304+0+0+40.0+5.0+0.0+0.0+0.5%0AR+304+160+208+160+0+1+40.0+1.0+0.0+0.0+0.5%0Aw+304+224+400+224+0%0Ax+368+208+456+214+0+24+To+ADC%0Ao+3+64+0+35+2.5+0.00625+0+-1%0Ao+4+64+0+35+2.5+9.765625E-5+1+-1%0A
Left click the output, use view in scope.

That's a really interesting approach that's simplier! Any chance that you still have the schematics for the 2nd idea you mentioned? I can't figure out what it means to put the signal in the top of the divider and ground.

To make full use of the 10bit ADC, would you recommend using an opamp with gain of 2 and biasing the signal by +2.5V using a potential divider across +5V and GND, or bias using a 2.5V voltage regulator?

Or would it be better to set AREF to 2V and bias the signal by +1V? In this case, will it be better to use a 2V voltage regulator, or a voltage divider across Arduino's 3V3 and GND using 20M and 33M resistors?

Edited to include the 5v bias way of doing it, with a link to a web based simulation.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Timer2 does not work as it should
I am currently playing with Arduino timers (on UNO currently) and I am building a library that  has a function that must be called every millisecond.
There is plenty of code samples on Internet so I went with something that seemed perfect for my needs. I have then updated it to make it a reusable C++ class.
Here is my code (simplified to just isolate the issue):
#define BIT(x) (0x01 << (x))

static volatile uint32_t milliseconds = 0;

class Timer
{
    public:
    Timer()
    {
        // Disable interrupts
        uint8_t savedStatus = SREG;
        cli();
        // Use Timer2 with 1 ms interrupts
        // OC2A & OC2B disconnected, mode 2 (CTC, Clear Timer on Compare match)
        TCCR2A = BIT(WGM21);
        // Don't force output compare (FOCA & FOCB), mode 2, Clock Select clk/128 (CS = 5)
        TCCR2B = BIT(CS22) | BIT(CS20);
        // Set timer counter compare match (when value reached, 1ms has elapsed)
        OCR2A = 125 - 1;
        // Reset Timer2 counter
        TCNT2 = 0;
        // Set Timer2 interrupt mode (Set interrupt on OCR2A compare match)
        TIMSK2 = BIT(OCIE2A);

        // Restore interrupt enabling state
        SREG = savedStatus;
    }
};

static void callEveryMillisecond(uint32_t ms)
{
    // Do something here
}

// Attach interrupt routine to the Timer Compare Interrupt
ISR(TIMER2_COMPA_vect)
{
    milliseconds++;
    callEveryMillisecond(milliseconds);
}

After checking ATmega328 datasheet (section 17) several times, I came to the conclusion that what I do in Timer class constructor above is correct, and for Arduino UNO, the values used must lead to one call of the ISR every ms:

CPU frequency = 16MHz
Prescaler = 128
-> timer frequency = 16MHz/128 = 125KHz
-> max counter value = 125

I decided to use the CTC (Clear Timer on Compare match) mode, which means that when the timer TCNT2 (which is incremented at 125KHz frequency), reaches OCR2A value, then it will trigger the ISR, and then will be reset on next tick; the additional tick to reset the counter explains why we use 125 - 1 for OCR2A and not just 125.
Now comes the weird stuff. In order to check that my code worked, I decided to blink the LED on pin 13 every 10 seconds, hence I have added the following code to my program:
static void callEveryMillisecond(uint32_t ms)
{
    if (ms % 10000 == 0)
        digitalWrite(13, digitalRead(13) ^ 1);
}

static Timer timer;

void setup()
{
    pinMode(13, OUTPUT);
}

void loop()
{
}

Then I measured the time during which pin 13 LED is lit on (or off, both measures are the same). Measures are not very accurate (I just used my wristwatch) but good enough for my check.
I was surprised to see the measured time to be about 20 seconds instead of 10s.
Initially I thought about a mismatch in CPU frequency, but after performing a lot of small changes, here is what I found which worked perfectly:
//static Timer timer;

void setup()
{
    static Timer timer;
    pinMode(13, OUTPUT);
}

Just moving the Timer instance into setup() did the trick: my measures rightly indicated 10 seconds between 2 states of the pin 13 LED.
Now my questions are:

Why the second code sample works perfectly, whereas the first does not?
Is there, in standard Arduino included code, some code that would overwrite some of the settings I perform for Timer2 in Timer::Timer()?
Is there a way to make the first code sample work? Note that I don't like the second sample because it does not seem natural coding, also, I will need access to Timer timer instance in several locations of my future program, hence it can't be possible if it is declared in the scope of setup().

Is there, in standard Arduino included code, some code that would overwrite some of the settings I perform for Timer2 in Timer::Timer()? You can easily check it, read the timer registers in the start of setup and send them through the serial port in the console to see if they match the values they should have.

Good idea! Initially I did not want to add Serial to the picture but that could help. However that will not tell what changed these register. I'll check that tonight and report back on the results.

We'll take it step by step, lets make sure first that something does change and then we can search further what changed the timer values.

I have located the source of the problem.
In file wiring.c (arduino-1.5.6-r2\hardware\arduino\avr\cores\arduino) which gets called before setup(), there is the following part that tries to changes the timer 2 prescaller to 64 by setting the CS22 bit.
// set timer 2 prescale factor to 64
#if defined(TCCR2) && defined(CS22)
    sbi(TCCR2, CS22);
#elif defined(TCCR2B) && defined(CS22)
    sbi(TCCR2B, CS22);
#else
    #warning Timer 2 not finished (may not be present on this CPU)
#endif

You already set CS20 and  CS22 so this doesn't affect you. What does affect you is the following part which sets bit WGM20
    // configure timer 2 for phase correct pwm (8-bit)
#if defined(TCCR2) && defined(WGM20)
    sbi(TCCR2, WGM20);
#elif defined(TCCR2A) && defined(WGM20)
    sbi(TCCR2A, WGM20);
#else
    #warning Timer 2 not finished (may not be present on this CPU)
#endif

and you have already set WGM21 so WGM21 and WGM20 set changes the timer mode to fast PWM , top=0xFF which gives almost double delay that the mode you were trying to use (CTC top=124).
How to workaround this issue?
Timer2 is used when its associated PWM pins are used with an analogWrite() call, so the Arduino setup code sets all prescalers to well-defined values just in case the timers might get used later.
I would not try to fight that code; instead, I would just make sure that my setup code runs later, e.g. by moving it to a separate setup() method in your Timer class and calling that from the global setup() routine.

Great! Do you have an idea why wiring.h does that? I mean, normally Arduino default libraries don't use Timer2 on UNO, so this behavior is strange.

Do you think there is a way to "disable" this code from wiring.h?

Timer2 is used when its associated PWM pins are used with an analogWrite, so the Arduino setup code sets all prescalers to well defined values in case the timers might get used later. I would not try to fight that code; instead, I would just make sure that my setup code runs later, e.g. by moving it to a separate setup() method in your timer class and calling that from the global setup() routine.

@jfpoilpret The wire.c gets called from init() and if timer2 registers are defined it applies the values shown above, why , I have no idea (one of the reasons I code in native C using AVRstudio).

@jfpoilpret Normally it would be very easy to use a conditional define (like #ifndef _LEAVE_TIMER2_ALONE_ ... #endif) in wire.c to exclude the timer2 part, but a #define from inside the sketch will not reach it. This can only work if you add the define in arduino.h or wiring_private.h but that is not convenient at all, because if you forget to remove it in an new sketch it will mess things up. Setting the timer inside setup is your best bet I think.

I have just checked wiring.c content and I have to say the init() function content seems to exceed its responsibilities somehow. Obviously there's no usable #if in the function to bypass this code block. Hence I'll have to find another solution to solve my problem. However I consider you have fully answered my question and therefore accept your answer. Maybe I'll edit the content to mention the fact we cannot really bypass this code block.

@jfpoilpret, if you truly care about bypassing this code block, it’s very easy to clone a “new” Arduino core from the standard one.

@microtherion maybe but that must reduce the possibilities to share my code with other people as they'll have to do the same cloning work on their installs. I think I'm gonna find a simpler solution to workaround the issue. I already have an idea, I'll post about it later today.

As a follow-up up to @alexan_e answer, here is what I finally did to ensure that my Timer2 settings are not overwritten by the init() method in Arduino wiring.c.
#define BIT(x) (0x01 << (x))

static volatile uint32_t milliseconds = 0;

class Timer
{
    public:
    // Don't use the constructor anymore
    void init()
    {
        // Disable interrupts
        uint8_t savedStatus = SREG;
        cli();
        // Use Timer2 with 1 ms interrupts
        // OC2A & OC2B disconnected, mode 2 (CTC, Clear Timer on Compare match)
        TCCR2A = BIT(WGM21);
        // Don't force output compare (FOCA & FOCB), mode 2, Clock Select clk/128 (CS = 5)
        TCCR2B = BIT(CS22) | BIT(CS20);
        // Set timer counter compare match (when value reached, 1ms has elapsed)
        OCR2A = 125 - 1;
        // Reset Timer2 counter
        TCNT2 = 0;
        // Set Timer2 interrupt mode (Set interrupt on OCR2A compare match)
        TIMSK2 = BIT(OCIE2A);

        // Restore interrupt enabling state
        SREG = savedStatus;
    }
};

static void callEveryMillisecond(uint32_t ms)
{
    if (ms % 10000 == 0)
        digitalWrite(13, digitalRead(13) ^ 1);
}

// Attach interrupt routine to the Timer Compare Interrupt
ISR(TIMER2_COMPA_vect)
{
    milliseconds++;
    callEveryMillisecond(milliseconds);
}

static Timer timer;

void setup()
{
    // Explicit call to Timer initialization; this occurs AFTER
    // Arduino wiring.c init() has been called
    timer.init();
    pinMode(13, OUTPUT);
}

void loop()
{
}

The way most of the libraries do this is to put an instance of (in your case) Timer in the Timer.cpp file, and reference it with an extern definition when needed - typically in your main cpp file.
Also you are calling digitalWrite() and digitalRead() during an ISR. This can be bad since those functions are slow, and may not be guaranteed to behave when interrupts are disabled (as they are during an ISR). A safer approach is for your ISR to set a flag in your Timer class that can be read by an Timer.isExpired() or similar method in your loop() code.

Putting an Timer instance in Timer.cpp won't change the issue: the problem is the well-known C++ initialization order chaos.

I don't see anything indigitalRead() or digitalWrite() that should prevent it from being called from an ISR.

In your setup function, you need to instantiate your timer, like this:
static Timer timer;

void setup()
{
    timer = new Timer();                       <<<--- here
    pinMode(13, OUTPUT);
}

void loop()
{
}

There is no need for a new as timer is not a pointer but an instance of Timer: it is in the static data section, not the heap. Its constructor is called (otherwise my ISR would never get called)

That will bloat the code with the malloc library and consume a bit of the precious RAM for no good reason. The only thing needed here is to get the init code called after the static object constructors. You don't need another instance to do that, just move the object creation inside setup() or put the init code in a separate method that you will call inside setup().

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How to organize my Arduino projects' structure for easy source control?
It's been a long time I've been looking for a good answer to this question.
Typically, any Arduino project but the simplest one will include:

The main source code file MyProject.ino
Libraries specific to the project (MyProjectLibrary1.h, MyProjectLibrary1.cpp...)
Third-party libraries (generally free open source, added manually to Arduino libraries directory)
Schematics, PCB diagrams
Documentation
...

All this makes it hard to keep the whole code and doc of one project under Source Code Management (e.g. on Subversion, Git or GitHub).
Managing source control of your project means managing the version of all files used by the project including 3rd-party libraries.
Now for a single project, I need to define a directory structure that:

Includes all project files as described above
I can entirely commit to a Source Code Management tool (including 3rd-party dependencies)
I can checkout anywhere on my hard drive and build the project from there (does it have to be a single location as imposed by Arduino IDE)
I can zip into a self-contained archive that I can send to a friend for him to build as easily as possible (no extra manual download)

What I find particularly tricky with Arduino projects is the management of external libraries dependencies. Java projects developers have maven repositories for that and that helps a lot in managing all external deps. But we don't have an equivalent system for Arduino libraries.
I would be interested to know how other Arduino project makers deal with these aspects in their own projects.
Also note that I am open to changing my development process, including my IDE (currently I use Eclipse with the Arduino plugin most of the time, and then I ensure my projects can also work directly with the Arduino IDE).

I've also been struggling with this. I have two projects which need different versions of an external library, and currently they are outside of version control.

Please note for further research that those are Package Managers. JavaScript got Node.js/npm and bower, PHP got PEAR and Composer, etc.

Here is the way I finally decided to follow for my projects.
Arduino-CMake
The first important decision I made was the choice of a build tool that could work for my environment (Windows) but was not limited to it (I want my projects easily reusable by other people).
I have tested various open source Arduino make tools:

Guyzmo Makefile (suggested by @zmo answer): this is just a standard Makefile handcrafted for Arduino builds; this is a Unix Makefile but there  is a good port of Unix make for Windows; still, unfortunately this Makefile works only for Unix, of course it could be adapted for Windows, but I wanted a tool that works "out of the box".
Arduino-Makefile (suggested by @adnues answer): this a more advanced project, based on Unix Makefile, that aims to be easily reusable by all Arduino projects; it is documented as working on Mac, Linux and Windows, but Windows support proved wrong in my first experiments (many dependencies on Unix shell).
Graduino (not suggested by any answer): this build tool is based on well-known gradle build tool from the groovy world; the tool seems quite well done but requires some (little) groovy/gradle knowlegde, and has only little documentation; I decided not to go with it due to the burden of installing groovy and gradle just for it (I'd like to avoid too many pre-requisites to people who want to build my projects on their environments).
Arduino-CMake (not suggested by any answer): this seems the best of all, it has a long history, has many supporters and maintainers, is very well documented, comes with simple examples and also has a few good tutorial blog posts on the Web, e.g. here and there. It is based on CMake, a "Cross-Platform Make".

I have also found ArduinoDevel, another Arduino build tool -which I have not experimented- that can generate Unix Makefiles or ant build.xml files; that one seemed interesting but a bit limited in terms of functionality.
Finally I decided to go with Arduino-CMake:

it was easy to setup: just install CMake on your machine and copy Arduino-CMake in some directory that is easily accessible (through relative paths) from your projects directories.
the examples worked out of the box for me (just followed the comments in CMakeLists.txt configuration file to adapt properties that needed to for my environment, e.g. Arduino type, serial port)
you can organize your projects any way you want
it can generate configuration files for various build tools out there (I have only tested Unix Makefiles though), including Eclipse projects.
in the generated make, several targets get created to support:

libraries build
programs build
program upload to boards
serial monitor launch
and a few others I have not tested yet

Project Structure
Since Arduono-CMake does not impose any directory structure for your project, you can choose the one that fits you best.
Here is what I've done personnaly (that still requires further refinement, but I'm happy with it now):

I have decided to put all my projects under a common arduino-stuff directory (which I commit to github as a whole, I know I could use git submodules for a better organisation on github, but had no time to check that yet).
arduino-stuff has the following content:

build: that's a directory where cmake and make will generate all their stuff (makefiles, cache, object files...); this one does ot get committed to github
cmake: that one is just a copy (unmodified) of Arduino-CMake cmake directory. This one gets on github so that it's easier for someone who wants to build my projects
CMakeLists.txt: that's the "global" CMake configuration that declares all defaults for my environment (board, serial port) and the list of build target subdirectories
TaskManager: this is my first project based on Arduino-CMake, this one is a library with examples; this idrectory also contains a CMakeLists.txt that states the targets for the project

Points to improve
The current solution is not perfect though.
Among improvements I see (that's rather for Arduino-CMake project to include these improvements if they see fit):

Feature to copy a library directory from the current project to the Arduino libraries directory
Feature to upload a library to github
Feature to download a library from github

Have you tried PlatformIO yet? It might not have been around when you were asking this question.. http://platformio.org/

It looks like the project died and resurrected a few times: arduino-cmake → forked arduino-cmake → Arduino-CMake-NG → Arduino-CMake-Toolchain.

My way of organizing an arduino project is quite simple, all my project are git repositories so that there is at least the following:

project/

project.ino
Makefile

I have a preference using my favorite editor and a Makefile which I have crafted to work against most use cases (and I even improved on that one that I'm going to share soon).
For the libraries, I prefer to keep them as their own repositories and use git submodule to include them to the project. As many libraries written by the community are shared as git repositories, that's a good generic solution. Then, within the Makefile, I just have to add the libraries path I want to include in the LOCALLIBS variable.
Though, for some projects, it makes sense to encapsulate the libraries into a hardware abstraction layer library crafted for the project, then I prefer to use a path such as:

project

project.ino
Makefile
project_hal_lib

library1
library2
library3
…

Though, with arduino 1.5.x a new way to specify libraries is offered, that will offer a way to create and build arduino projects the same way we already do with pipy and virtualenv in python, i.e. you define the set of libraries you need and they get downloaded.

I was working on a similar answer. You beat me to it!

+1 Thanks! This way looks quite interesting. I'll have to give it a try this week (I need to check out how to setup the Makefile stuff first, though).

@AsheeshR if your answer was similar, that means it still has some differences, right? I'd be interested to know about these!

actually the main changes to come with next version of my Makefile will be the ability to either flash using a programmer or upload using the bootloader. As well as handling merging of bootloader with firmware. I also wrote an in-makefile fuse setter.

@zmo bounty deserved, though your Makefile solution cannot work in my situation (using Windows but I did not specify that point). But I am convinced that using one of the existing makefile solutions available is the way to go. Once I have found one tha tworks for me I'll post my answer here.

well, actually I have designed my Makefile to by somehow windows-compatible… though at the time I did not have a windows to test it! So definitely, if you want to help improving it, you're welcome :-)

So , what's the "arduino 1.5.x a new way to specify libraries"? That's too many words. Could you show an example?

When I wrote that answer that was pretty new, but today it's widely used. The best way to find an example (beyond reading the spec) is to crawl github: https://github.com/search?q=%22library.properties%22 . An example would be the first match. Sadly, I haven't done much Arduino over the last few years, and I'm not up to date anymore with the best practices, so I don't know how far they went with this, and whether a pip like CLI is possible or not.

The simplest way to do this is to copy the header and code files of the library into your source directory and include them.
myproject/
    myproject.ino
    somelib.h
    somelib.cpp

In your code, you can do include "somelib.h"
The down side to this is that the libraries must be in the same folder, not sub folders, so it makes your directory look messy.

Regarding the directory structure of my entire project, including schematics and documentation, mine usually looks like this:
myproject/
  schematics/ - eagle files or whatever you may have
  docs/       - include relevant datasheets here
  test/       - any test cases or other code to test parts of the system.
  myproject/  - since Arduino code must be in a directory of the same name
    myproject.ino
    ...

Another downside is that I will have to copy the same libraries on many projects. Also, it is not clear to me if you put only YOUR libraries in there or also 3rd-party libraries?

First point: That's not really a down side, that's just a side effect of keeping libraries and project source together as you wanted with version control. What if another project needs an updated version of the library? What if you modified it? Second point: both will work.

Agreed. Now where do you put other files for the project and the libraries (scehmatics, documentation)? In a subdir, in the project dir, outside?

@jfpoilpret I updated my answer with my typical directory structure.

Thanks for the update, +1 for your answer. I am curious to see what others do for their own projects.

One more question, after duplicating your own libraries into the different projects that use them, one of these projects may find some bugs or improvements of a duplicated library; then you have to duplicate changes everywhere again, that is error-prone and time-consuming! Also, if you want to "open" one of these libraries on its own (outside any project) for others to use, you also have to duplicate changes into there. Do you have any trick to work around this problem.

I do not. The Arduino IDE is quite limited in many ways. You may want to look into a better environment to work in that has better support for this. People have made custom make files that let you import libraries from other sources as well.

This is not a good way to organize projects from the point of view of software licenses. If you are including third-party libraries in your project, which may have different licenses, then you may be violating them as soon as you start sharing the project file. Different open source licenses are generally not compatible with each other.

@AsheeshR having all your files in one directory so the arduino IDE doesn't complain is not a good way to organize projects at all. It's just a way. Feel free to propose a better solution. I don't know of one that still allows you to use the Arduino software.

Git submodules are extremely powerful when it comes to organizing multiple nested repositories. Handling multiple libraries from different sources, and even handling parts of your own project which may be stored at different sources becomes easy with git submodules.
Directory Structure
A way to organize your projects would be:

projectA - Parent Directory

projectA - Source code directory containing Arduino code

projectA.ino
header.h
implementation.cpp

docs - Your main documentation directory
schematics - these may be maintained separately on a separate Git repo or part of the same repo
libs - This will contain your third party libraries.

libA - These may be maintained as third party repositories
libC - ...

license
README
Makefile - Necessary to handle dependencies across directories

Workflow
You would follow your normal cycle of make changes, add and commit as far as the main repository is concerned. Things get interesting with the sub-repositories.
You have the option of adding a repository into the parent directory of your main repository. This means that any part of you directory structure, i.e. docs, schematics, etc. can be maintained as a separate repository and continuously updated from.
You can do this using the git submodule add <repo.git> command. To keep it up to date, you can use git submodule update <path>.
When it comes to maintaining multiple third party libraries within your repository such that each can be version controlled in itself or each can be kept up to date if need be, git submodule again saves your day!
To add a third party repo to libs, use the command git submodule add <lib1.git> libs/lib1. Then, to maintain the library at a fixed point in the release cycle, checkout the library and make a commit. To keep the library up to date, use the command git submodule update <path>.
Now, you can maintain multiple repositories within a main repository as well as multiple third party libraries in their independent stages of release.
Versus Single Directory Approach
While the single directory approach is the simplest, it is not possible to version control parts of a directory without a lot of pain. Hence, the simple approach fails to accomodate different repositories with varying states in the project.
This approach allows maintaining multiple repositories but brings in the need for a Makefile to handle the compilation and linking process.
Depending on the complexity of your project, the optimal approach can be selected.

+1, but just as a sidenote: Git Submodules are pretty unstable and likely loose track. It makes no difference if you use a single directory or multiples (like vendor, node_modules, etc.). Git references them and keeps track of it.

"It makes no difference if you use a single directory or multiples (like vendor, node_modules, etc.)." I didn't understand this part. Could you elaborate?

MyProject
|_MyProject
  |_MyProject.ino
  |_data
  |  |_documentation
  |  |_PCB
  |  |_schematics
  |_src
     |_MyProjectLibrary1
     |_ThirdPartyLibrary

MyProject folder (repository root)
The reason I suggest the seemingly redundant MyProject root folder is that you mentioned using GitHub. When you download (rather than clone) the contents of a GitHub repository the branch or tag name is appended to the repository name (e.g. MyProject-master). The Arduino IDE requires that the sketch folder name match the sketch file name. If you open an .ino file that is in a folder that does not match the sketch name the Arduino IDE prompts you create an appropriately named sketch folder and move the sketch to that folder. In addition to this not being a very good initial experience for the user, the greater problem is that the Arduino IDE may not copy all the other associated files to the newly created folder, which could cause the program to no longer compile. By putting the sketch in a subfolder you avoid GitHub altering the name of the sketch folder.
If the GitHub file name thing is not an issue for you then the redundant root folder is not necessary.
data folder
I recommend using the data subfolder for your non-code files because the Arduino IDE has a special treatment of subfolders of that name. They are copied to the new location when you do a File > Save As.... Subfolders of any other name are not.
src folder
The src subfolder has the special property of allowing recursive compilation. This means that you can leave the libraries in that folder and include them from your sketch like this:
#include "src/MyProjectLibrary1/MyProjectLibrary1.h"
#include "src/ThirdPartyLibrary/ThirdPartyLibrary.h"

The Arduino 1.5 Library format folder structure is also supported, you only need to adjust your #include statements accordingly.
Note that only Arduino IDE 1.6.10 (arduino-builder 1.3.19) and newer support recursive sketch compilation.
Unfortunately some libraries use the incorrect #include syntax for local file includes (e.g. #include <ThirdPartyLibrary.h> instead of #include "ThirdPartyLibrary.h"). This still works when the library is installed to one of the Arduino libraries folders but does not work when the library is bundled with the sketch. So some libraries may require minor edits to use this way.
I greatly prefer this to the alternative of dumping all the library files in the root of the sketch folder because that is messy and every library file will be shown in the Arduino IDE as tabs when you open the sketch (Of course any source files you do want to be editable from the Arduino IDE should be placed in the sketch root folder).
Being able to use bundled libraries in place is also in line with another of your goals:

send to a friend for him to build as easily as possible

Removing the requirement to manually install libraries makes the project much easier to use.
This will also avoid any chances of conflict with other versions of library files of the same name that may be previously installed.

You could use the makefile
https://github.com/sudar/Arduino-Makefile
for compiling Arduino codes. You don't necessarily need the IDE.

I have tried but unfortunately it will work only on Unix machines and I need Windows support. Currently I am evaluating another project based on CMake but I'm not done with it yet. I'll post an answer when I have decided on a tool.

Probably really late to the game but it's a popular enough question to answer using slightly different methods than those posted already.
If you need to maintain compatibility with Arduino IDE directly you could use something like the one I outlined here:
https://gitlab.com/mikealger/ExampleArduinoProjectStructure/tree/master/ExampleSketchBook
I based most of this off the notes of Arduino -- Project structure and build process, and some tips I have picked up over the years.
I really don't know why this is so hard to find via Arduino pages directly, it seems silly coming from a semi professional background that the build process is so obtuse.
best of luck out there
----edited link to the project structure notes i used as they have been erased
they are now here

The gitlab link appears to be broken

odd does it work with out the the direct link ? i.e. https://gitlab.com/mikealger/ExampleArduinoProjectStructure

Actually both links work in Firefox, but neither work in my outdated Chrome version 49.0.2623.112 (64-bit). Nothing to worry about, I guess. :-)

ok grahamwideman's page is gone now but the wayback machine has a copy at https://web.archive.org/web/20161106122158/https://grahamwideman.wikispaces.com/Arduino+--+Project+structure+and+build+process

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Interfacing Arduino Leonardo with PCA8574AN
I'm trying to interface my Leonardo with a "Mindsensors Magic Wand" - 8 LEDs connected to a PCA8574AN chip.
On the manufacturer's page, they say it's compatible with Arduino, however no instructions or code are given.
http://www.mindsensors.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=120
I've connected the SDA, SCL, 5v, and GND connectors on the arduino to the device, but have had no luck in communicating with it. None of the LEDs light up regardless of input.
I can verify that power is being supplied.
The i2c address of the device is 0x70.
Code is below.
#include "Wire.h"
#define TWBR=400000L
void setup() {
  // put your setup code here, to run once:
 Wire.begin();
}

void loop() {
  // put your main code here, to run repeatedly:
  delay(2000);
  Wire.beginTransmission(0x70);
  Wire.write(32);
  Wire.endTransmission();
}

tl;dr: It seems like you need to send a null bit (0) to terminate the communication with this board.
In the downloads section, I found a .nxc file, which I assume is a NXT code file.
In the main loop, they configure the I2C port and a "touch sensor" (I believe this is to figure out how to synchronize the text with the motor). In that, there is a main loop in which they call DispLetter.
This is the DispLetter function:
void DispLetter (const byte & letter[])
{
  int nbytes;
  // Wait for the end of previously sent data
  while(I2CStatus(I2Cport, nbytes)==STAT_COMM_PENDING);
  // Write buffer to send to PCF8574
  byte WriteBuf[];
  ArrayBuild(WriteBuf, I2CAddr8574, letter);
  for(int i=1; i<ArrayLen(WriteBuf); i++)
  {
     WriteBuf[i] ^= 0xff;
  }
  I2CWrite(I2Cport, 0,  WriteBuf);
}

Let's read this code! First of all, it seems to make sure that the I2C port is connected, which we don't really have to worry about in our case since that's platform-specific.
After that, they create an array called WriteBuf[] that will store the data to be sent to the controller. Then we come across a function called ArrayBuild. Looking that up, it combines I2CAddr8574 and letter and places it into the WriteBuf array. (Click here for documentation for that function.) Please note that the I2CAddr8574 is just a byte containing 0x70 (the address of the chip), so we will not have to do this step since the Arduino handles the address. So, you will just have to send the letter array to the controller, ignoring the WriteBuf and ArrayBuild!
Let's figure out how letter is passed. In the main loop, they had this code:
DispLetter(L_);
DispLetter(E_);
DispLetter(G_);
DispLetter(O_);

That must display "LEGO." Let's figure out what L_ is defined as. At the beginning of the document, they have this defined:
// Display patterns
// Each byte represents a column of dots
// Bit set to 1 means lit LED.
// Least significant bit is at top of column.
// Last byte must be all 0
// Maximum number of bytes par pattern: 15

byte L_[] = {0xff, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0};
byte E_[] = {0xff, 0x89, 0x89, 0x89, 0x89, 0x81, 0x81, 0};
byte G_[] = {0x7e, 0x00, 0x81, 0x81, 0x81, 0x81, 0x91, 0x90, 0x72, 0};
byte O_[] = {0x7e, 0x00, 0x81, 0x81, 0x81, 0x81, 0x81, 0x00, 0x7e, 0};

byte La_[] = {0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0x80, 0xff, 0};
byte Ea_[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0};
byte Ga_[] = {0x72, 0x90, 0x91, 0x81, 0x81, 0x81, 0x81, 0x00, 0x7e, 0};
byte Oa_[] = {0x7e, 0x00, 0x81, 0x81, 0x81, 0x81, 0x81, 0x00, 0x7e, 0};

byte N_[] = {0xff, 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80, 0xff, 0};
byte X_[] = {0x80, 0x41, 0x22, 0x14, 0x08, 0x14, 0x22, 0x41, 0x80, 0};
byte T_[] = {0x01, 0x01, 0x01, 0x01, 0xff, 0x01, 0x01, 0x01, 0x01, 0};

As you can see, they listed out how the dots are configured. There's a max of 15 bytes (I assume including the null bit).
There's one more piece of code that we haven't talked about:
for(int i=1; i<ArrayLen(WriteBuf); i++)
{
   WriteBuf[i] ^= 0xff;
}

So it goes through each bit, and does something to it. That is the shorthand for this:
WriteBuf[i] = WriteBuf[i] ^ 0xff;

No, that is not an exponent. That is an exclusive OR, a bitwise operator. A bitwise operator is basically where it "overlays" the two binary sequences and it does a special computation on them. If the nth bit of each input number is 1 or the nth bit of each input number is 0, the nth output bit is 0. If the nth bit of one input number is 1 and the nth bit of the other input number is 0, then the nth bit of the output is 1.
Since 0xff = B11111111, it will essentially reverse the values of each bit. You can avoid this if you say that a bit set to 0 is on, instead of a bit set to 1 (like they do in the example code). A minor adjustment that just makes your life a bit easier :)
After that, you can write that array to the I2C bus and it should display the data!

Hi,If i'm understanding it correctly, the way to go is to write the byte for the LEDs I want activated, then 0x00. I'm just trying to display a static pattern at the moment. `#define TWBR=400000L
#include "Wire.h"
void setup() {
// put your setup code here, to run once:
Wire.begin();
}
void loop() {
// put your main code here, to run repeatedly:
delay(2000);
Wire.beginTransmission(0x69);
Wire.write(0x12);
Wire.write(0x00);
Wire.endTransmission();
}` This doesn't work, is it what you meant? Thanks.

@Tim that is what I meant... I must have overlooked something in the code. I'll look at it later tonight if I have time.

@Tim sorry just got time today to look back at it. 1.) the address is 0x70, not 0x69. 2.) The only other thing that I can think of is, in the examples, they always send the data to 0x0 and then the first byte is the address (0x70). 3.) Ignore the advice in my post about the last bit being a 0: that just is supposed to shut it off... right! Further than that I don't have a lot of other ideas.

@Tim did you fix it? What fixed it?

Haven't yet.  Will try again today.


text:
Combining & averaging magnetometer values
I am trying to measure a users 'hand steadiness' in order to control a video game character in UNITY3D. I am using a MinIMU-9 Gyro/Accelerometer/Compass linked with Arduino. I can measure pitch/roll etc in Arduino...and I have passed previous Arduino measurements into Unity via the serial command but I am l trying to do two things:
1. simplify & reduce noise in the data coming from the magnetometer reading before I pass it into Unity by taking an average of every 10 magnetometer readings.
2. Combining the three magnetometer values to get one overall variable or measurement that can be passed into unity.
This is the demo Sketch I have but I'm not sure how to script the addition of the x,y,z magnetometer values:
#include <Wire.h>
#include <LSM303.h>
LSM303 compass;
char report[80];
void setup()
{
  Serial.begin(9600);
  Wire.begin();
  compass.init();
  compass.enableDefault();
}
void loop()
{
  compass.read();
  snprintf(report, sizeof(report), "A: %6d %6d %6d    M: %6d %6d %6d",
    compass.a.x, compass.a.y, compass.a.z,
    compass.m.x, compass.m.y, compass.m.z);
  Serial.println(report);
  delay(100);
}

This is the type of 'averaging script' I would like to add in somewhere but I'm not sure where exactly to place it:
for(int i = 0; i < 10; i++){    //take ten readings in ~0.02 seconds
    reading[i] = compass.m.y;
    delay(2);
  }
  for(int i = 0; i < 10; i++){   //average the ten readings
    finalMagYreading += reading[i];
  }
   finalMagYreading
 /= 10;

Any help with this would be great.

Also consider a rolling average where you take eg New_AVG = 10% x latest_reading  + 90% of Old_AVG. (Or 1/N of reading + (N-1)/N of old value for N samples. ) This behaves rather differently than you may expect and is smoother than just averaging N samples. Easyish to implement. | OLD=AVG; AVG = OLD x (n-1)/N + Sample/n .

Thanks Russell - I managed to use a Unity plugin to use the accelerometer in my android phone to remotely control the virtual object on my main monitor in Unity. I would now like to trigger an event based on a rapid rotational change on the y axis.
Is it possible to compare one realtime accelerometer reading against the same variable reading .2 seconds later? Something like:
'if ((euler.y) >= (euler.y)+30);
{
GUI.Label(Rect(150,150,200,150),"high tilt", largeFont);
}'

The later comparison sounds like a standard operation unless I am missing something. Save current value as eg OldValue. Then compare with current value 200 mS later. In a multi function system use eg millis() to determine when 200 ms is up. |One off save: ActionTime = 200 + millis(); Then in loop if (millis() >= ActionTime) { ....}


text:
Waking Raspberry Pi on time schedule using Sleepy Pi
I'm have a Sleepy Pi and am having extreme difficulties trying to program a wake/sleep cycle. Sleepy Pi is an Arduino board with a RTC. My ultimate goal is for a time-lapse project.
I have the Raspberry Pi programmed and operational to take a picture on boot, my trouble is coming from trying to program the Arduino board to actually do it's job.
I would like the Sleepy Pi to wake at 8am, 9am, 10am, ..., 3pm, 4pm, and 5pm, each for 5 minutes, then go back to sleep. I've been working with the SleepyPi, Time, TimeAlarms, LowPower, and DS1374RTC libraries in the Arduino IDE. However, I cannot find any examples on how to put everything to sleep until a specific time comes around. Also, in several of my tests, it seems that the clock actually stops when the Sleepy Pi is asleep!
Here is what I've been working with (and this is non-working). It's probably completely wrong.
#include "SleepyPi.h"
#include <Time.h>
#include <TimeAlarms.h>
#include <LowPower.h>
#include <DS1374RTC.h>
#include <Wire.h>

// Set the status LED pin constant
const int LED_PIN = 13;

void setup()
{
  // Configure "Standard" LED pin
  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN,LOW); // Switch off LED

  // Start with the Pi off
  SleepyPi.enablePiPower(false);

  // Set our communication rate
  Serial.begin(9600);

  // Set up our boot times
  Alarm.alarmRepeat(8,0,0, startPiUp);
  Alarm.alarmRepeat(9,0,0, startPiUp);
  Alarm.alarmRepeat(10,0,0, startPiUp);
  Alarm.alarmRepeat(11,0,0, startPiUp);
  Alarm.alarmRepeat(12,0,0, startPiUp);
  Alarm.alarmRepeat(13,0,0, startPiUp);
  Alarm.alarmRepeat(14,0,0, startPiUp);
  Alarm.alarmRepeat(15,0,0, startPiUp);
  Alarm.alarmRepeat(16,0,0, startPiUp);
  Alarm.alarmRepeat(17,0,0, startPiUp);
}

void loop()
{
  // Tick the alarm clock every second
  SleepyPi.enableWakeupAlarm();
  Alarm.delay(1000);

  // Cut Power if we detect Pi not running
  bool pi_running;
  pi_running = SleepyPi.checkPiStatus(true);
  if(pi_running == false){
    SleepyPi.powerDown(SLEEP_FOREVER, ADC_OFF, BOD_OFF);
  }

  // Flash the LED
  digitalWrite(LED_PIN,HIGH);
  delay(1000);
  digitalWrite(LED_PIN,LOW);
}

// Function to tell the Pi to boot up
void startPiUp()
{
  // Turn the Pi on
  SleepyPi.enablePiPower(true);

  // Turn on the LED to signal we're here
  digitalWrite(LED_PIN,HIGH);

  // Keep the Pi on for 5 minutes
  delay(300000);

  // Start a shutdown
  digitalWrite(LED_PIN,LOW);
  SleepyPi.piShutdown(true);
}

I also cannot find a good way to "debug" things. I've been trying to use the LED flashes as a "I'm here" echo, but have been unsuccessful with this as well.
NOTE: I do not have enough reputation on this site yet to create new tags. Someone with over 150, please tag this with raspberry-pi and sleepy-pi. Thank you.

I would have thought you would use this device to wake the Pi, then have that do it's job & shutdown -h now, & use the checkPiStatus command to watch for that - it should save more battery than a set 5 minutes. You will then have the Pi status LEDs to se that power up/down, and can use the SleepyPi to monitor itself - Does it have a serial comms capability?

You're probably right, but I'm not even that far. I'm trying to get the device to just wake the Pi up on a set schedule using the RTC, and I cannot even get that part working. There seems to be no actual documentation about how to use the TimeAlarms library, and it seems like when I program the Arduino and the try to start the cycle, the RTC doesn't continue ticking.

I have the same problem and  I just saw that they fixed a bug in a library used by SleepyPi
More specific, the RTC library file DS1374RTC.cpp reads since March: '2015
(which is after the question was asked)

Releases
    ========
    V1_0 - 10 Aug 2013 - Initial release
    V1_1 - 11 Mar 2015 - Mod:    Added "ackAlarm" and "ackRTCOSF" functions to aid Alarm use
  - Bugfix: Changed the way the "SetAlarm(tmElements_t   &tm)" was updating the Alarm time. It wasn't mapping correctly

They also added a new example to wake up the Pi: WakePeriodicallySimple.ino

Same probem. Kludgy solution ... but it works
Get the startstopsimple skectch from GitHub.
Set the period to 60 minutes
Set the timeout to whatever makes sense for you
Modify the setup function to loop until the clock says the minute is 59.
something like
do
{
   delay (100);
} while !(minute() == 59);

Then it will go into the loop function. It will be asleep. So it will then do a whole "empty" loop and sync after that, dunno how one gets rid of first the empty loop. But it works .... :-)


text:
Why are Tone.cpp and IPAddress.cpp getting built for my project?
I'm using avr-size to see the size of library objects to free up some FLASH. Why are Tone.cpp and IPAddress.cpp getting built? e.g.
$ cd /var/folders/3j/6wp3hvrj34n0xg3xzq6vjq380000gn/T/build8391693238079360471.tmp/
localhost:build8391693238079360471.tmp
$ /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-size *.o
   text    data     bss     dec     hex filename
      0       0       0       0       0 CDC.cpp.o
      0       0       0       0       0 HID.cpp.o
   1816       0     170    1986     7c2 HardwareSerial.cpp.o
    512       0       6     518     206 IPAddress.cpp.o
  10186     391     377   10954    2aca MainINOFile.cpp.o
   1872      14       0    1886     75e Print.cpp.o
   1414       1       0    1415     587 Stream.cpp.o
   1365       1      21    1387     56b Tone.cpp.o
      0       0       0       0       0 USBCore.cpp.o
    288       0       4     292     124 WInterrupts.c.o
    306       0       0     306     132 WMath.cpp.o
   4796       1       1    4798    12be WString.cpp.o
     30       0       0      30      1e main.cpp.o
    618       6       0     624     270 malloc.c.o
     56       0       0      56      38 new.cpp.o
    450       0       0     450     1c2 realloc.c.o
    588       0       9     597     255 wiring.c.o
    266       1       0     267     10b wiring_analog.c.o
    550       0       0     550     226 wiring_digital.c.o
    320       0       0     320     140 wiring_pulse.c.o
    260       0       0     260     104 wiring_shift.c.o
$ /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-size */*.o
   text    data     bss     dec     hex filename
   2790       0       0    2790     ae6 DS3231/DS3231.cpp.o
     38       0       1      39      27 EEPROM/EEPROM.cpp.o
   1444       0       0    1444     5a4 LSM303/lsm303.cpp.o
    782       0       0     782     30e Messenger/Messenger.cpp.o
    116       0       1     117      75 SPI/SPI.cpp.o
    142       0       4     146      92 SdFat/MinimumSerial.cpp.o
   2568       0       0    2568     a08 SdFat/Sd2Card.cpp.o
  10644       0       4   10648    2998 SdFat/SdBaseFile.cpp.o
   1322       2       0    1324     52c SdFat/SdFat.cpp.o
    152       0       0     152      98 SdFat/SdFatUtil.cpp.o
    233       0       0     233      e9 SdFat/SdFile.cpp.o
    736       0       0     736     2e0 SdFat/SdStream.cpp.o
   2604       0     523    3127     c37 SdFat/SdVolume.cpp.o
   3395       0       0    3395     d43 SdFat/istream.cpp.o
   1635       0       0    1635     663 SdFat/ostream.cpp.o
    754       0      86     840     348 Wire/Wire.cpp.o
$ /Applications/Arduino.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-size *.elf
   text    data     bss     dec     hex filename
  29204     442    1279   30925    78cd MainINOFile.cpp.elf

The fact that source files be compiled does not mean they all will be linked together in the final exe. The linker only takes what's needed.

Might I suggest aliasing avr-size et alia? It would save quite a few keystrokes.

@IgnacioVazquez-Abrams ctrl-c ctrl-v :)  I mainly put them there for reference to future question viewers who might not know about avr-size

I was able to reproduce this building the Blink example. It explains why building a small sketch sometimes takes ages.

That's the price you pay for minimal-config development.

@Jippie, if you are on a windows machine; move the arduino directory to a path that has NO-white spaces. Any White Spaces in the path to the core lib will cause a "clean" rebuild, which is much slower. To verify turn on "output compile" in the IDE pref's. While this is a different topic. It is related. Hope it helps. (looks like 1.5.7 always does a clean build. 1.5.6r2 and prior works.)

@mpflaga who in his/hers right mind would develop on Windows?

As stated the IDE's equivalent to the make will compile anything everything it can find, in scope. But its linker has eliminate garbage enabled, hence anything not called or not static will not be linked into the EXE.
You can "avr-objdump -t" to create a map from your elf. And -d for an assembly listing. As to see exactly what is in the EXE, for your self. You need to enable show verbose output of compilation from the IDE's preferences, to display the temporary directory that contains the elf file.
example:
C:\DOCUME~1\mflaga\LOCALS~1\Temp\build6395515806682540138.tmp>C:\projects\Arduino\hardware\tools\avr\bin\avr-objdump -t MP3Shield_Library_Demo.cpp.elf > MP3Shield_Library_Demo_wo_mem.cpp.elf.map
C:\DOCUME~1\mflaga\LOCALS~1\Temp\build6395515806682540138.tmp>C:\projects\Arduino\hardware\tools\avr\bin\avr-objdump -d MP3Shield_Library_Demo.cpp.elf > MP3Shield_Library_Demo_wo_mem.cpp.elf.lst

I did the above and commented out a call to a function member of my library, between subsequent builds. To see that the code was not linked into the assembly.


text:
Why client.stop causes some significant delay to do another task in a loop?
void setup() {
    Serial.begin(9600);        // Initialize serial communications with the PC

    // disable SD SPI
    pinMode(4, OUTPUT);
    digitalWrite(4, HIGH);

    // disable w5100 SPI
    pinMode(10, OUTPUT);
    digitalWrite(10, HIGH);

    SPI.begin();                // Init SPI bus
    mfrc522.PCD_Init();        // Init MFRC522 card
    //Serial.println("Scan a MIFARE Classic PICC to demonstrate Value Blocks.");

    Ethernet.begin(mac, ip); //we used a STATIC address to start ETHERNET

    // print your local IP address:
    Serial.print("My IP address: ");
    for (byte thisByte = 0; thisByte < 4; thisByte++) {
        // print the value of each byte of the IP address:
        Serial.print(Ethernet.localIP()[thisByte], DEC);
        Serial.print(".");
    }
    // give the Ethernet shield a second to initialize:
    delay(1000);
    Serial.println("connecting...");
}

void loop() {

    // Prepare key - all keys are set to FFFFFFFFFFFFh at chip delivery from the factory.
    MFRC522::MIFARE_Key key;
            key.keyByte[0] = 0xFF;
            key.keyByte[1] = 0xFF;
            key.keyByte[2] = 0xFF;
            key.keyByte[3] = 0xFF;
            key.keyByte[4] = 0xFF;
            key.keyByte[5] = 0xFF;

    // Look for new cards
    if ( ! mfrc522.PICC_IsNewCardPresent()) {
        return;
    }

    // Select one of the cards
    if ( ! mfrc522.PICC_ReadCardSerial()) {
        return;
    }
    // Now a card is selected. The UID and SAK is in mfrc522.uid.

    // Dump UID
    //Serial.print("Card UID:");
    //Serial.print(mfrc522.uid.uidByte[i] < 0x10 ? " 0" : "");

    // In this sample we use the second sector (ie block 4-7). the first sector is = 0
    // scegliere settore di lettura da 0 = primo settore
    byte sector         = 0;
    // block sector 0-3(sector0) 4-7(sector1) 8-11(sector2)
    // blocchi di scrittura da 0-3(sector0) 4-7(sector1) 8-11(sector2)
    byte valueBlockA    = 0;
    byte valueBlockB    = 1;
    byte valueBlockC    = 2;
    byte trailerBlock   = 3;
    byte status;
    // Authenticate using key A.
    // avvio l'autentificazione A
    //Serial.println("Authenticating using key A...");
    status = mfrc522.PCD_Authenticate(MFRC522::PICC_CMD_MF_AUTH_KEY_A, trailerBlock, &key, &(mfrc522.uid));
    if (status != MFRC522::STATUS_OK)
    {
        Serial.print("PCD_Authenticate() failed: ");
        Serial.println(mfrc522.GetStatusCodeName(status));
        return;
    }

   //No KEY B Authentication
   int val1 =(mfrc522.uid.uidByte[0]);
   int val2 =(mfrc522.uid.uidByte[1]);
   int val3 =(mfrc522.uid.uidByte[2]);
   int val4 =(mfrc522.uid.uidByte[3]);

   String valA=String(val1);
   String valB=String(val2);
   String valC=String(val3);
   String valD=String(val4);

   uID=valA+valB+valC+valD;
   Serial.print(uID);
   Serial.println();
   counter=counter+1;
   Serial.print(counter);
   //}
   Serial.println();

   // Halt PICC
   mfrc522.PICC_HaltA();

   // Stop encryption on PCD
   mfrc522.PCD_StopCrypto1();

   if (counter>first)
   {//delay ifs
       // enable w5100 SPI
       if (client.connect(server, 80)) { //start of IF
           Serial.println("connected");
           client.print("GET /accessdenyrfid.php?rfid="); //dont make these println
           client.print(uID);   //dont make these println
           client.print("&&");
           client.print("ip=mech1");

            //client.print( ip );
            //client.print("&&");
            //client.print("ipkey=");
            //client.print( ipkey );

            client.println(" HTTP/1.1");   //println
            client.println("Host: ");    //println
            client.print(server);//don't make println
            client.println("Connection: close");  //println
            client.println();   //terminates the query
            Serial.print("SENT");
            Serial.println();
            first++;
            Serial.print(first);
            Serial.println();
            // add this
            while(client.connected()) {
                while(client.available()) {
                    char ch = client.read();
                    Serial.write(ch);
                }
            }

           client.stop();
           client.flush();

       } //end OF IF
    }//delay ifs
}

The code above works perfectly with another php. that either saves or denies a card into a database. The arduino sends and receives data back and forth from and to php in less than a second. But the problem is that whenever the function client.stop is called. It takes approx. 8 seconds before another data is sent in the loop function. I need the loop to continue with just 2 second interval, which is enough or even faster. I don't think that the mysql query in the php is the one that makes it longer cause all the queries are made before the delay starts. (The server has already sent it's response, before the delay starts, which i think is in the client.stop.) Please help me on other alternatives on stopping the client or any way I can do this faster. Thanks, I'm really in trouble right now. I'm using Arduino UNO. Data sent back and forth are just a couple of letters and numbers.

Could you post the full code? There's a bit missing...

I would bet the problem relies on
if (counter>first)

As seems like you never reset counter, there might be weird things going on

Can you please edit your answer to explain why this causes the code in question and how it should be fixed? Thanks!

@AnnonomusPenguin Edited

I can't even see where counter is declared, nor first.


text:
Is it possible to infer the length of a neopixel string using 1-wire protocol?
I'have been looking at the AdaFruit NeoPixels recently and am trying to understand how the addressing scheme works.
All of the examples I've seen explicitly identify the length of the string (number of neopixel units) and are typically set using an array of 24-bit values to control the color of a particular neopixel.
My question is two fold:

How do the neopixels know where they are in a string to allow for addressing?
If the neopixels know where they are in the string, would it not be possible to potentially feed the output of the last neoxpixel back to a microcontroller to determine the number of neopixels in the string?

OP Note (this is my interpretation and may be suspect, but it is more or less my take away)
Thank you for all the answers on this - it has been very enlightening from ALL of the answers. General take away, the NeoPixel is not "directly" addressable in the sense that you can pick pixel "X" of "n" pixels. The string of NeoPixels acts essentially as a gigantic shift-register (as stated in one of the answers) so to "address" a particular pixel you have to update a buffer that represents the state of the entire string and then shift it down the wire. This is why micro-controllers, such as an Arduino, would have limitations on how many NeoPixels it could control. This is also why it is more practical to define the number of pixels in the string and allocate memory to represent that state.

Why do you want to do this? Don't you know how many NeoPixels you have?

I've seen people light every pixel in a row, and measure the slight voltage drop in the supply voltage. When you try to turn on an led that isn't there, the voltage drop disappears, and you know where the string ends.

As noted in Chris Stratton's answer, “Each pixel "peels off" the first data word before passing on the rest, so the payload gets shorter and shorter as you move down the chain”.
This behavior is spelled out clearly in WS2812.pdf and WS2812B.pdf datasheets from http://www.world-semi.com :

The data transfer protocol use single NZR communication mode. After the pixel power-on reset, the DIN port receive data from controller, the first pixel collect initial 24bit data then sent to the internal data latch, the other data which reshaping by the internal signal reshaping amplification circuit sent to the next cascade pixel through the DO port. After transmission for each pixel, the signal to reduce 24bit. pixel adopt auto resha-ping transmit technology, making the pixel cascade number is not limited the signal transmission, only depend  on the speed of signal transmission.

This means that each WS2812 unit in a chain picks off the first 24-bit data packet, latches that data into an internal register, and passes the rest of the data on out, through reshaping circuitry.  Hence, if you put m packets of data into a chain and k packets come out, the chain length is m-k or more.  (The chain length may be more than m-k when k is zero.)

Each pixel "peels off" the first data word before passing on the rest, so the payload gets shorter and shorter as you move down the chain.  Although the data wire may look continuous it isn't - the signal is electrically re-driven from each unit to the next.
For the RGB ones, they are logically three monochrome pixels of different colors, so they peel off three words rather than just one.
At any point in the chain you can determine how many logical pixels potentially remain to be updated, by counting the words you are passing on.  You can't of course tell if they are actually there, or if there are further pixels for which no data is being provided.  And you can't tell how many pixels preceded, other than to bound it by the amount of gap time from the previous update you received.

So that more or less answers my understanding in that each neopixel peels off the data it knows about (the "head" of the data set) and then passes the rest. But doesn't that mean I could feed the end of the last pixel back to the microcontroller and have a routine to "watch" for pulses to come back? If no pulses were received then we are either at or below the length of the chain. The first group of pulses that we receive after sending would indicate the number of pixels-1 yes?

Yes, if you have access to both ends of the chain and don't know how many elements you have, you can measure it that way.  It may get a little tricky in practice as the transition edges you get will probably be delayed from those you sent, at the least by electrical delay and probably by many register clock-to-out delays as well, and for a long enough chain could make receiving them in software a little challenging.  For some of these signalling schemes (would have to look again to see if this one) you can persuade a sufficiently flexible UART peripheral to help, for others you cannot.

I guess a simpler method than truly receiving the data could be to configure a pin change interrupt on the tail-of-chain return, and then send frames with increasing numbers of data words in each into the head end until you finally see something make it out that tail end, or do so in a pattern more like a binary search.

Looks like I finally arrived at the same conclusion you did, Chris. However the binary search idea may have a speed penalty. What number would you start with? Too small and you miss a long string, too large and it would take a long time to send all those pixels. Still this guy drove 1000+ pixels at 30 FPS, so maybe it is a pretty reasonable idea at that. Maybe start with 1000 pixels and work your way down. :)

Or maybe send in increments of 100 until you overshoot, then do a binary search on that last amount.

It is possible to do this by feeding the end of the strip back into the arduino.  bunnie Huang blogged about doing this a few years ago: http://www.bunniestudios.com/blog/?p=3345
He has schematics and firmware which uses a modified neopixel library that can measure the length of the strip.

As far as I can make out (eg. NeoPixels Revealed: How to (not need to) generate precisely timed signals) the NeoPixels are not in fact addressed, but are like a long shift register. Thus if you have 10 pixels, you have to send out 10 lots of RGB colours and then latch them. This is why you need to know how many pixels you have, so that you send out the right number of RGB bytes.
I don't think it would be particularly practical to try to detect how many pixels are in the chain, because the individual ones "reshape" the timing pulses.

What about feeding the far end of the data line back into an arduino input pin?

What would that tell you? Because of the reshaping done by individual pixels you don't know how long each bit will be, exactly. Thus whilst you might know how long it took for a bit to arrive at the other end, without knowing the length of each bit, you don't know what to divide that time by, to arrive at a count.

I suppose, since each pixel "peels off" one RGB colour, you might try sending increasing numbers of pixels out, and waiting until one arrives at the other end. That might work.

This is certainly possible as I have now confirmed.
The code below will detect the length of a string of NeoPixels up to 10000 long.
/*
 *
 * Find length of NeoPixel string.
 * Author: Nick Gammon
 * Date:   11 March 2016
 */

#include <SPI.h>

const unsigned long LIMIT = 10000;  // maximum pixels to test

// Note: Connect NeoPixels to MOSI (pin D11 on a Uno, pin D51 on a Mega)
//       Connect the other end of the NeoPixels to D2 (External Interrupt 0)

void sendByte (byte b)
  {
    // send one byte to the Neopixels - note that the "off" gap is partly handled by the loop overhead
    //   gaps measured empirically to be 1.7 µs to 2 µs, so we don't need to add any more of our own
    for (byte bit = 0; bit < 8; bit++)
      {
      if (b & 0x80) // is high-order bit set?
        SPI.transfer (0b11111100);  // 1 bit - 750 ns on + 250 ns off (acceptable "on" range 550 ns to 850 ns)
      else
        SPI.transfer (0b11100000);  // 0 bit - 375 ns on + 625 ns off (acceptable "on" range 200 ns to 500 ns)
      b <<= 1; // shift next bit into high-order position
    } // end of for each bit
} // end of sendByte

void ledsetup()
{
  SPI.begin ();
  SPI.setClockDivider (SPI_CLOCK_DIV2);
  SPI.setBitOrder (MSBFIRST);
  SPI.setDataMode (SPI_MODE1);   // MOSI normally low.
} // end of ledsetup

void sendPixel (const byte r, const byte g, const byte b)
  {
  sendByte (g);
  sendByte (r);
  sendByte (b);
  } // end of sendPixel

void show()
  {
  delayMicroseconds (7);
  } // end of show

volatile bool triggered;

void myISR ()
  {
  triggered = true;
  } // end of myISR

void setup()
  {
  ledsetup();
  Serial.begin (115200);
  Serial.println (F("Starting ..."));
  attachInterrupt (0, myISR, RISING);
  } // end of setup

unsigned int increment = 1000;
unsigned int counter = increment;

void loop()
  {
  noInterrupts ();
  triggered = false;
  EIFR = bit (INTF0);  // clear flag for interrupt 0

  for (unsigned int i = 0; i < counter; i++)
    sendPixel (5, 0, 0);
  TIMSK0 = bit (TOIE0);  // throw away timer overflow interrupt
  interrupts ();
  show ();  // latch the colours - handle the interrupt meantime

  if (triggered)
    {
    if (increment <= 1)
      {
      Serial.print (F("There are "));
      Serial.print (counter - 1);
      Serial.println (F(" NeoPixels in the string."));
      Serial.flush ();
      exit (0);
      }
    else
      {  // binary search
      counter -= increment;
      increment /= 2;
      } // end of if
    } // end of if triggered

  counter += increment;

  if (counter > LIMIT)
    {
    Serial.print (F("Could not find any NeoPixels after trying "));
    Serial.print (LIMIT);
    Serial.println (F(" pixels."));
    Serial.flush ();
    exit (0);
    }

  } // end of loop

It works by sending out increasingly long strings of 24 bits, and waiting for one to "shuffle off" the other end of the string.
Connect the Data In of the NeoPixels to MOSI (pin D11 on a Uno, pin D51 on a Mega) as this sketch uses SPI to generate the timed sequences. Connect the far end of the NeoPixels (Data Out) to pin D2 which is External Interrupt 0.
The sketch pumps out batches of pixels, and waits for an external interrupt. When that occurs it indicates that the last pixel in the chain was reached, and passed the pixel data out Data Out to the non-existent pixel past the end of the chain.
The number of pixels needed to do this is then noted.
The sketch does a "binary search" to speed things up for long strings of pixels. The worst-case scenario (where you have either 10000 pixels, or none at all) takes 6 seconds to execute. With less pixels it will be faster. I had under a second execution time for 3 pixels in my test string.
The sketch outputs a dull red (intensity 5) so you should see the pixels light up in red if all is well. If you wanted to do it unobtrusively, you could output black (as that still results in bits being sent down the string).
Example output:
Starting ...
There are 3 NeoPixels in the string.


text:
Arduino servo acts weird with photocell (lightsensor)
I have a weird thing with my servo, I really dont know what is wrong with my code, I tried everything. Either it is my connection on arduino or my code. Please help me guys, this is my code.
#include <Servo.h>

int servoPin = 9;
Servo servo;
int angle = 0;
int photocellPin = 0;

void setup() {
  servo.attach(servoPin);
}

void loop() {
  int reading = analogRead(photocellPin);
  Serial.print("Reading = ");
  Serial.println(photocellPin);
  int newAngle = reading / 2;
  servo.write(newAngle);
  delay(80);
}

Can you describe exactly what is weird with the servo? It just sits there and do nothing?

Maybe a good quality picture of your setup would help us help you. Also, it could help if you tested the photocell separated from the servo. For example, have you tried to feed a few hardcoded angles to the servo, say, 0, 90, 180, 90, 0, delaying a few seconds from each call? Also, what results do you get from the serial prints?

Thank you for answering. The servo acts weird in a way that it is moves and gives little shocks each time. Also my connection with my usb port doesnt work continue, I got the feeling their is a bad connection. I will make a picture of my setup, maybe it is just the wires.

You mean the servo doesn't move smoothly, but in quick steps, like it's quicking, is that it? Can you show us your circuit and tell us which servo it is. Maybe the servo is trying to use more current than the USB is able to provide and that's causing the suply voltage to drop and making the Arduino reset.

I added a photo :) It is a small servo.

It is just a weirdo servo to be honest, he doesnt know what he wants.

Servos accept a signal from 0 to 180, with 90 being the center point on the servo. analogRead() will output a number from 0 to 1023. The arduino "map" function makes a conversion easy to do. just replace
int newAngle = reading / 2;

with
int newAngle = map(reading, 0, 1023, 0, 180);

you can read more about the map function here: http://arduino.cc/en/reference/map
It is hard to tell from the picture that everything else is wired correctly, but this should fix up your code.


text:
Problem with structs and pointers(?) - Mega with QueueArray
I'm writing a sketch to run on a Mega that builds up an array of timestamps (using the QueueArray library and DS3231 library). I'm having a problem where a struct I'm defining and then queueing is always referring to the first in the list. The relevant bits of the code looks like this:
#include <QueueArray.h>
#include <DS3231.h>
struct payload_t
{
   unsigned long timestamp;
}

QueueArray <payload_t> dataQueue;
DS3231 clock;
RTCDateTime dt;

void setup() {
   clock.begin();
   clock.setDateTime(__DATE__, __TIME__);
}

void loop() {
    payload_t dataPayload;
    dataPayload.timestamp = getTimestamp();
    dataQueue.enqueue(dataPayload);

    payload_t tempItem = dataQueue.dequeue();

    /**
     * At this stage, the dataPayload.timestamp is correct,
     * but tempItem.timestamp will always show the value from
     * the first item in the queue
     */

    sleep(1000);
}

unsigned long getTimestamp()
{
    RTCDateTime dt = clock.getDateTime();
    return dt.unixtime;
}

As per the comment in the main() loop, the first time a packet is added to the queue, the timestamp matches. For subsequent items, the value retrieved from the queue always gives the timestamp from the first item in the queue.
I feel this is my C knowledge letting me down with something basic, but can anyone point me in the right direction?

Have you got FIFO and LIFO round the wrong way? dequeue() pulls from the front and enqueue() pushes on the back. Also, in your example code, the queue never contains more than one entry; you add a payload, then remove it on the very next line.

I think you have hit the nail on the head. I'm adding to the end of the queue, then grabbing the first item for the comparison check. The first loop iteration will work, but subsequent ones will show a difference. Obvious when you realise! Thanks for the pointer.

I'm confused by the fact that tempItem is always the original stamp - are you definitely using dequeue() in your code, or is if just used here as an example?

It's not your C knowlede letting you down, it's just that you haven't gotten used yet to the weirdness of the arduino ide/compiler.
You do not need to create a main() function.
You need to create a loop() function.
main() is already defined and calls loop() in a loop.
Check any other sketch and you'll notice that it usually defines setup() and loop(), almost never main().
You must put in the setup function all the code that needs to be executed once (settings and initializations) and in the loop() function whatever needs to be executed iteratively.
Also, leave declarations out of loop() unless you want such variables to have scope (and life) limited to only one round of loop()

My mistake - I'd been reading up on C, so wrote main() instead of loop() in the example code. It's definitely loop() in the actual sketch though...

Even with that fix (btw, why didn't you past exactly the code you wrote?) I don't see what is strange with what you describe: you initialize an empty queue, put in one element, then extract that one element right away.
But you do not show how you are reading it. I suggest that you show exactly the code you are using, rather than some modified version of it.
It might well be that the problem lies in how you check that value, rather than in the way it's generated.


text:
Wifi REST API GET call - how to concatenate and pass URL parameters?
I'm not too familiar with the Arduino C++ language, but I would like to get this native code to work.
In curl this works:

curl "http://access.alchemyapi.com/calls/text/TextGetTextSentiment?text=i+feel+great&outputMode=json&apikey=my-apikey"^C

So I am trying to use a WiFi client for the same request but it seems the passing and parsing of the URL parameters is causing a problem.
sprintf(request,"/calls/text/TextGetTextSentiment?apikey=%s&text=%s&outputMode=%s","31adba6dfc3a879b88762f50efc9f892bd573207", "i+feel+great", "json");
Serial.println(request);

When I print the request, everything after the & gets truncated.
  char serverName[] = "access.alchemyapi.com";
  if(client.connect(serverName,port) == 1)
  {
    sprintf(outBuf,"GET %s HTTP/1.1",page);
    client.println(outBuf);
    sprintf(outBuf,"Host: %s",serverName);
    client.println(outBuf);
    client.println(F("Connection: close\r\n"));
  }

This works (HTTP status 200, though with missing parameters error from the API service) if I only pass in 1 parameter.

How is "request" defined?

Concatenating the string data in memory before sending it shouldn't be necessary. Instead, you should just be able to use client.print() (or equivalent) to output each part of the request in sequence. For example:
client.print("GET ");
client.print(page);
client.print(" HTTP/1.1\r\n");

client.print("Host: ");
client.print(serverName);
client.print("\r\n");

// etc.

That should let you output any combination of HTTP headers you need.


text:
Is the used clock for the Baudrate generator adjustable on an arduino due?
I hope to find some answers or pointers to a boggling task of mine:
Having an Arduino DUE that I want to push to its serial limits, I came up with the idea of hooking it up to my rPi via serial at least at 921600 baud.
Technically both seem capable of that. A loopback test with the rPi was successful up to 921600 and I've managed to get a "good" quality transmission up to 576000 bps already (error-rate should be around 1,3%), but anything higher gets problematic.
Problems:

DebugConsole, CuteCom and minicom don't have support for any speeds in-between, so either 921600 works or it doesn't
minicom supports 1.000.000 baud, but this would still mean a ~5% error-rate, which is according to my calculations and tests, but they are in question here as well ...

From the Atmel Doc I've got
BaudRate = MCK ⁄ CD × 16

From that I've derived that with the 84MHz Due a baudrate of 1.050.000 would be the actual rate I should aim for, as CD must(?) be an INT.
1050000 = 84000000 / 5 * 16

Questions:

Is my assumption of an optimal 1.050.000 baudrate right?
Is it possible to use a different clock for the baudrate generator than the 84MHz?

Remarks:
A Clock of 14,7456MHz should be optimal as it is equal to 921600 * 16.
I am using TXD/RXD1 on the Due.
The Due is transmitting on 921600 but the data is scrambled due to the errors.
In case somebody is wondering, my hope is that it is easier to adjust the arduino to 921600 baud than it is to setup a tool and configure the rPi to support 1050000 baud - but I am working both ways, only that with the rPi I know what to do ..

Localization note for this question: decimal points are shown as comma.  thousands separator is shown as dot.  yes?

oh, yes, that is correct

Why not use SPI to communicate between Due and rPi? You would support higher rates, and that would not be much more difficult to implement.

@jfpoilpret thanks, but the rPi is more like a verification device, the true challange is the arduino serial port, I am aware of SPI and USB, but I need to do this via serial or at least find out if this is possible or not

The clock of the transmitter and receiver have to be matched.
In theory, the worst case error tolerable is 1/2 bit per byte.  For the 10 bit byte (1 start, 8 data, 1 stop) that leads to a +/- 5% clock error tolerance that you will find reported.  Note that this actually depends on the specific UART implementation, either chip or internal.  There are various methods of sampling that make some UART's better than others.  It is common to sample in the middle, but some chips have methods to improve noise rejection.
For the receiver side, do not rely on what the terminal program is showing you.  Few applications would manipulate the clock directly; they commonly just call an API with an enumerator for the speed.  You need to know exactly what hardware the receiver side has and its clock.
In practice, the theoretical limit is not going to work.  At high data rates, the noise on the cable will eat away at that safe margin.  More common recommendations will say +/- 1% which allows for noise on the edges of the bit transitions.
The noise on the signal is important at these data rates.  You indicate you are using TXD/RXD which is just logic level.  You cannot connect logic level any significant distance.  If the two are directly next to each other with excellent attention to wiring, you might have a chance.  Adding transceivers will help your chances significantly.
Also, note that changing to 7 bits helps.  Do you need 8 bit data?
So in summary:
- The receiver is more important than the transmitter, but they both have to match.  If you can't find a match of clocks to 1%, you will have data errors.
- At these speeds, the cabling and connection is critical.
This article at Maxim is a good starter Maxim "Determining Clock Accuracy Requirements for UART Communications.

wires are like 10cm max; the arduino is powered by the rPi as there is no extra GND line; need 8 bit; used init_uart_clock=14745600 on the rPi; am aware of the +/-1%; the situation is clear, but how to solve it?! how to practically align the clocks and baudrates of the rPi and due to 921600 or anything else in the neighbourhood

Yes you can set the Master clock slightly slower and use Serial.begin(921600) and it will come out close enough to work with a HC05 bluetooth module set to 921600.
// multiplier 0x25 , divider 0x3
REG_CKGR_PLLAR=0x20253F03;// works at 921600
this will throw all other timings off but you can always compensate by changing the master clock definition in the Due ? .h file. if you want to print out of Serial0 port this will need to be set to 921600 also and you can monitor it with something like realterm that can do higher baud rates.
Atmel-11057-32-bit-Cortex-M3-Microcontroller-SAM3X-SAM3A.pdf

May be a little formatting and some punctuation might help understand your answer...

I had to put this project aside for quite a while but will check the answers when it will restart


text:
Disturbed digital out at 4Mhz on Arduino NANO
I've written a simple program - it generates signals over Port D at 4 MHz:
#include <Arduino.h>

int main(void) {

    DDRD = B11111111;
    PORTD = B00000000;

    while (true) {
        PORTD = 0;
        PORTD = 5;
        PORTD = 10;
        PORTD = 15;
        PORTD = 20;
        PORTD = 25;
        PORTD = 30;
        PORTD = 35;
        PORTD = 40;
    }
    return 0;
}

and this is the signal coming out on D4:

I've modified the program by inserting NOP after each assignment to POTRD:
#define NOP __asm__ __volatile__ ("nop\n\t")

int main(void) {

    DDRD = B11111111;
    PORTD = B00000000;

    while (true) {
        PORTD = 0;NOP;
        PORTD = 5;NOP;
        PORTD = 10;NOP;
        PORTD = 15;NOP;
        PORTD = 20;NOP;
        PORTD = 25;NOP;
        PORTD = 30;NOP;
        PORTD = 35;NOP;
        PORTD = 40;NOP;
    }
    return 0;
}

and now signal looks fine, but frequency is limited to 800 KHz:

What is the reason for interference at 4 MHz? Is there a limitation to maximal frequency on digital out? I do not really need it for some particular project, just wanted to know it.
I've asked this question on stackoverflow, but then I've discovered this dedicated forum so... I've decided to try it out ;)

Set your scope mode to Single instead of Normal and the “interference” will magically disappear.

This is correct... could you explain the reason for this?

Your scope synchronizes on the rising edges, but since those are unequally spaced, it gets out of sync with the full period of the signal. By adding a few nops you reached a lucky synchronization in your second version of the code. In Single mode it only displays a single trace, so synchronization is not an issue.

Could you paste your comment as an answer ? - thank you !

Try running avr-objdump -S /tmp/sketchname.elf and look at the generated assembler code. You'll see how many operations certain code requires.

While not the cause of what you are seeing, you should also know that unless you disable it the Arduino has a timer interrupt running in the background which will slightly disturb operations like this.

This is not a limitation of the Arduino: you can toggle a pin on every clock cycle. It's a synchronization problem between the generated signal and the triggering of the scope. Your scope displays several traces superimposed, and it synchronizes them on the rising edges, but since those are unequally spaced, it gets out of sync with the full period of the signal. By adding a few nops you reached a lucky synchronization in your second version of the code.
The simplest solution is to set the scope mode to Single instead of Normal. Then it only displays a single trace and synchronization is not an issue anymore.
Another option would be to use one of the bits of PORTD as a trigger
signal. This bit should cycle only once inside the loop. PD5 should
work in the current version of your code. Configure the scope for
external trigger and feed this signal into its TRIG input.

Thank you - correct trigger solves my problem:


text:
Read multiple char from USART
int i, j;
char data;
int flag=0;

void loop()
{
if(Serial.available() > 0){
    data  = Serial.read();
    flag=0;
  }

  if (data == 'd' && 'b') {
    digitalWrite(cONOF, HIGH);
  } else if (data == 't' && 'w') {
    digitalWrite(cONOF, LOW);
  }

  if (data == 'y' && 'w') {
    digitalWrite(start, HIGH);
    delay(2000);
    digitalWrite(start, LOW);
  }

  if (data == 'e' && 'r' && 'h' && 'i') {
    for (i=0;i<10;i++) {
      digitalWrite(horn, HIGH);
      delay(100);
      digitalWrite(horn, LOW);
      delay(100);
    }
    for (j=0;j<10;j++) {
      digitalWrite(horn, HIGH);
      delay(500);
      digitalWrite(horn, LOW);
      delay(500);
    }
    digitalWrite(horn, LOW);
  }

}

I want to read data from the USART where the messages have more than one character. I tried the code above but it doesn't work well. For example, I want to send the message 'db' to turn the output on, but just sending 'd' also turns it on, how do I fix this?

You need split the reading into two processes - storing the characters and checking if they are the right message.
To store the characters for example:
String message = "";

void loop()
{
while(Serial.available()) {
    char b = Serial.read();

    if (b == '\r') {
        processMessage();
        message = "";
    }
    else {
        message += b;
    }
}
}

The process might look like
void processMessage() {

    if (message == "fb") {
         foo();
    }
    else if (message == "bf") {
         bar();
    }
}

I just use the Messenger library usually. But note you have to change WProgram.h to Arduino.h in Messenger.cpp to get it to work.

ohh yaaa thx broder :) it works... perfect

Just be careful, in the code I posted if the string gets too big you could run out of memory. Might be wise to count the characters going in and stop adding em if it gets too long. Please accept my answer if its all good :P


text:
Receiver xbee receiving data while the Transmitter is powered off?
My receiver xbee is receiving data even if the transmitter is disconnected , so if i am sending the string hello world , the receiver will repeat this string .
void loop() {
    Serial.println("Hello");
    delay(1000);
}

void loop() {
     if(Serial.available()>0){
         Serial.print((char)Serial.read());
     }
}

And what is the question?

@Gerben there is no question there is a problem

As @Garben mentioned, we do not know what is your question, problem or whatever...
Provide some more information about wiring. I looked at your question 5 mins and still can't get what is wrong...
What are you doing here??? Sending from Arduino+XBEE to another Arduino+XBEE???
void loop() {
    Serial.println("Hello");
    delay(1000);
}

Here you are resending what you got
void loop() {
     if(Serial.available()>0){
         Serial.print((char)Serial.read());
     }
}

So what is your problem? Or is this all your code???
Arduino has to have
void setup(){
//Set up your Arduino here
}
void loop(){
//Code here will run over and over and over...
}


text:
What transparent casings are commonly used for smaller devices with a display
Not exactly Arduino-specific, but if you want to get a daily usable device (instead of a floating wire connection on your table) you eventually want to put your (Arduino-based) device into a nice casing. What are the different types of cases that people use?
I found soap cases as well as kitchen boxes (used one large cheese box from Mepal Rosti).

I found display cases for signed baseballs/golfballs/softballs useful for projects where I wanted all the pretty internals to be visible.  Just buy two - one to scratch up while planning, and then a clean one for the final result.

So far we have used:
ABS cases (pic camdenboss.com):

Small pelicases (convenient to open, pic pelican-case.com):

3D printed cases with a clear perspex window (pic instructables.com):

I've seen other people use laser cut perspex (pic spikenzielabs.com):

If you have affordable access to a laser cutter, then you could laser cut a box to exactly match your project.
Laser cutters typically come with software that reads SVG or DXF files.
Find out what file types are used, then search the web for something like "laser cut box design tool SVG", and you'll find a bunch of ways to make the box outline.
For example, this laser cut box web site generates a pdf file, which you can 'print'. You fill in a few parameters, and it does the rest, generating all the profiles for interlocking edges. Even though the edges are interlocking, you might want to add some glue to make it more robust.
An advantage of laser cutting is you can choose the materials. Maybe you'd like wood, with a transparent red acrylic lid.
A further advantage, if your laser can read things like SVG or DXF, is you could use a CAD or drawing program to modify the box. So, for example, you could 'etch' labels onto a control panel, or cut extra holes to mount LEDs. Or just decorate the outside of the box.

Yes, having a laser cutter would be handy. Unfortunately, that's no option for where I'm living. Nonetheless, thanks for the link, though the resulting pdf files waste a lot of material because of inefficient placing.

@Thomas S. I apologise for the poor choice of boxmaker. I thought I'd one which created DXF or SVG but I seen to have lost it. I'll ask a friend for the one they like, and update my answer if it is better. Do you not live in a country with MakerSpaces? Some of them offer to cut designs quite cheaply. I am not against ready made cases, it's just they often need to be cut anyway for cables, or to make components, like sockets, LEDs, etc. usable. I also like the idea of engraving labels onto it.