Added as new answer because comments limit was reached
Doesn't really matter which programmer you set because in this instance you're not actually burning the bootloader just setting the fuses (to those already stored in boards.txt for the Uno) but 'Using Arduino as ISP' is the nearest to what you're doing


PIR motion sensor (HC-SR501) false results with NodeMCU

I had the same issue. PIRs have very sensitive circuitry and can be triggered by the WiFi signal from the ESP8266. The answer is to move them apart and with some decoupling of the power supply lines you should see much better performance. My PIR and ESP are now a couple of metres apart and I use shielded cable to connect them together.


Arduino Pro micro Serial communication problem with Node MCU

RX and TX pin of Arduino Micro are Serial1. Replace Serial in your sketch with Serial1 to communicate with esp8266 over RX and TX pin.


Some may have the "Blink" sketch pre-installed, but many don't. However, when there is no sketch installed the board sits in bootloader mode waiting for you to upload a sketch.  While it's in bootloader mode the LED pin pin D13 blinks.

If your LED is blinking about once a second then it's the Blink sketch.  If it's rapidly blinking three or four times per second or so then it's in the bootloader and you have no sketch loaded.


Interconnected Arduinos via digital pins and magnets

While idea looks cool, you need some kind of "locks" because not "any combination" can work.

Rotate second Arduino in bottom row on 180 degree and you will see that GND/5V reversed relatively to first arduino in second row.

You have to account magnet N-S polarities to allow good lock. Probably you can use magnet polarities to achieve proper orientation.


I'm looking for a way to serially communicate with a multi mesh Arduino slave network

It's not obvious what the exact query is but answering the subject line question:

You can easily multidrop connect multiple serial / RS232 COM ports by having all slave RX inputs and the master TX output on one line, and all slave TX outputs connected by an OR network to a single line to the master's RX input.   The master 'talks' to all slaves at once. Each slave talks to only the master. Only one slave can usefully talk at once. Message destination assignment and slave-talking arbitration is carried out in software.

As shown below, the OR network at each slave can be as simple as a diode with cathode (bar side) to TX line and anode to common line to master RX.  A single pullup resistor (or an internal pullup in the master on the RX line) pulls the line high when all slave TX lines are high.

This diagram shows how simple multidrop communications can be.
NB - As shown the diodes polarity is for true RS232 with logical 1 = low = negative.
When connecting directly between UART TTL lvel (5V/0V) outputs reverse the diodes.

Also, add a pullup from +5V to the Blue RX line to the master - 10k to 5V is probably OK.

From here - Multidrop network for RS232.

When a slave TX pin is high its diode is "blocked" and it does not affect the common slave to master level. When any slave TX line goes low the common line is pulled low via its diode and the master sees the low. Normal RS232 COMs can occur between slave and master.

When the master sends all slaves see the transmission at once. A basic protocol must be established to allow messages to be handled by the intended recipient. This could consist of, e.g. sending an address word + command word or words. You can have a single slave act on a message or all slaves or a sunset, based on your addressing system.

The slave to master direction allows only one slave to send at one and you must ensure either that only one slave ever sends at a time and/or that collisions are able to be resolved.

Despite the obvious limitations of such a system it can work very well and is cheap and simple to implement. If there are many slaves the loadings should be checked so that e.g. the master TX is able to drive all slave RXs at once. As the circuit is unidirectional it is easy to add a basic buffer.


What does an Arduino do if the serial connection is closed on the other end?

That's some strange Intel monstrosity. It's impossible to know what it does or how. Intel's foray into the Arduinosphere was brief and somewhat abortive.
In general though (for most cores) the DTR signal (and sometimes the RTS signal too) of the CDC/ACM protocol is used to "gate" the serial data - if it's asserted then serial data gets sent through to the host PC. If it's not asserted then it just gets thrown away.
I have seen cores where if DTR is not asserted the data gets buffered until the TX buffer is full and then blocks, but that is rare.
You might find your answer if you delve into the core's source code, but you may find that big chunks of it are hidden away in closed source pre-compiled libraries, and the fact it seems to run some custom RTOS means it'll be even more obfuscated. YMMV...


It seems you have a problem of concurrent access to duration and pulsecount variables which are inter-related; with your code, it is possible that (and I guarantee that it will):

loop() reads duration value (in line unsigned long _duration = _duration;) but gets interrupted before executing the next line
myinthandler() changes both duration and pulsecount (it cannot be interrupted as it is already triggered by an interrupt)
loop() proceeds to where it was interrupted (after myinthandler() returns) and executes line unsigned long _pulsecount = pulsecount;: the values in _duration and _pulsecount do not match anymore!

To protect the access to pulsecount and duration variables, you have to disable interrupts inside loop() just for the time you get their values:

void loop() {
    ...
    // Disable interrupts while we get and reset duration and pulsecount
    cli();
    unsigned long _duration = duration;
    unsigned long _pulsecount = pulsecount;
    duration = 0; // clear counters
    pulsecount = 0;
    // Now we can re-enable interrupts again
    sei();
    ...
}


How can a function/method determine if a const array passed in is PROGMEM (flash) or not (RAM)?

I am afraid there is no good solution to this problem. One option I do
like is to use the __flash qualifier instead of PROGMEM:

const uint8_t ram_array[] = { 1, 2, 3, 4 };
__flash const uint8_t flash_array[] = { 5, 6, 7, 8 };

void function_reading_ram(const uint8_t *array)
{
    uint8_t secondElement = array[1];
    // ...
}

void function_reading_flash(__flash const uint8_t *array)
{
    uint8_t secondElement = array[1];
    // ...
}

int main(void)
{
    function_reading_ram(ram_array);      // OK
    function_reading_flash(flash_array);  // OK
    function_reading_ram(flash_array);    // Warning
    function_reading_flash(ram_array);    // Warning
}

Note that, with __flash, you don't need pgm_read_byte_near() or
anything similar. You just use the array like you would use any regular
array, and the compiler is smart enough to generate the code required to
access the Flash memory.

The warnings generated by gcc are:

warning: conversion from address space ‘__flash’ to address space ‘generic’ [-Waddr-space-convert]
     function_reading_ram(flash_array);
     ^
warning: conversion from address space ‘generic’ to address space ‘__flash’ [-Waddr-space-convert]
     function_reading_flash(ram_array);
     ^

Given how nice this solution is, you may wonder why I wrote “there is no
good solution”. Well, this comes with two caveats, one small and one
huge. The small caveat is that you need to explicitly pass the option
-Waddr-space-convert to the compiler if you want it to generate the warnings.
It is not implied even with
-Wall -Wextra. The huge caveat is that this only works in plain C.
If you try to use this trick in C++ you get:

error: ‘__flash’ does not name a type

This is an implementation of the “named address spaces” extension to the
standard C. Since nothing like this is standardized in C++, the authors
of gcc assumed it would not be useful to users of C++. :-( You can mix C
and C++ sources in Arduino, but you can't call class methods from C.


See page 5 of your datasheet - that 'fancy' sensor suppresses "• Continuous signals at any frequency".

So you'll need to pulse your 38.4kHz signal for the sensor to produce an output.


It's certainly possible to multiplex a UART port, yes, though you will need extra hardware to do it. You will need:

A multiplexer to select between the two RX lines and feed the right one to the Arduino's RX pin
A demultiplexer to select which of the devices to send the Arduino's TX pin to.

"Analog" (de)multiplexers (e.g., CD4052) may be the simplest option since they can work in both directions. Another alternative would be combinations of tri-state buffers and glue logic to control them.


This sounds very doable. The first point, tuning the distance threshold at startup, could be done with a bank of DIP switches or a potentiometer on an analog pin to set the value. You might include some startup code continuously pings the transducer and displays the result on an LED, until you press a button to tell it "use this".

The second, is a very typical communication technique - sending "hello" packets periodically to confirm that communication is up. In your case, the same packet could carry a hit/no-hit bit within it.


LCD library and timer2 CTC interrupt not working together

You're getting interrupt every 16th CPU clock cycle. The ISR handler might be even longer than that and your code and lower priority ISRs suffers by "starvation" as MCU can't do anything else than processing ISR.

If you use prescaler value 8, then you have 1/2us resolution of TCNT2 and overflow interrupt (in normal mode) occurs every 128us, so there will be enough time to do something else. However, if you want atomic value of TCNT2 and counted value from ISR handler, you'll have to stop Timer2 for a while.


When using Arduino Uno as ISP does "Yikes! Invalid device signature" mean a bad connection, bad config, or bad version of avrdude?

I soldered wires to pads to be sure the connection was good, and used those wires for programming from the Uno. Then the programmer worked, without any edits to the command lines as posted in the question. I ran a few variations and was able to answer all my questions, and a few more besides:

The "Yikes! Invalid device signature" error was being caused by poor contact between the programmer (Uno) and the ATTINY pins.
It had nothing to do with the bootloader not being on the new microcontroller. The new ATTINY45 chip doesn't need a bootloader for the in-circuit programmer to work.
The Uno can program the ATTINY45 configured to either of its speeds, 1MHz or 8MHz. The factory settings are fine, and don't require changing the fuses.
Both avrdude versions worked for programming- the 6.1 from the author's site, and the modified one from the Arduino IDE.
avrdude can program via the Uno using any of -c avrisp, -c arduino, or -c stk500v1, it doesn't matter which.

One little question I wasn't able to answer, was what speed the Uno programs at (communication speed between the Arduino I/O pins & microcontroller being flashed). Is it related to the serial port speed? But it turned out to be not pertinent to answering this problem. Someone else can ask it if curious enough.


A question about the possible limits of an Arduino Uno

A lot of Arduino code is written either generally inefficiently, or written in completely the wrong way.

For instance, take the LCD code.  Commands have to be sent at the right speed with the proper delays in there for things to happen.  LCDs are actually quite slow devices to communicate with, and as a result the LCD code has a large number of delays in it.

Nothing else can happen while there's a delay() running.

Many other things will introduce their own delays.  Put them all together and you have a slow system.

No, you're not overloading it, you're slowing it down on purpose, and all those small slow-downs add up to one big grind.

There are other ways of doing these things, of course, which are far more friendly to the chip - things that don't require delays of any form.

For a start there is the millis() function which tells you the time.  Using that to know when to do things, instead of sitting waiting for them to happen, allows you to do so much more at once.

It's like boiling an egg.  Do you put the egg in boiling water and sit there staring at it for 3 minutes (or however long you like your egg cooking), or do you set the timer on your oven to alert you in 3 minutes time so you can go and do the ironing while the egg is boiling?

It's the same with Arduino programming.  Note the time, then check that time against the current time to see if the required time has passed.

Of course, with things like the LCD library, changing it to work that way would be quite a lot of effort.

There are also hardware timers.  These allow you to run small snippets of code at regular periods.  Great for managing things like servos or other motors where you only want to be changing the state or speed of them say 10 times per second. Instead of updating them all the time, just set a desired speed / position variable and let the timer interrupt update the actual motor at a lower rate.

There are two key phrases to take away here:

Non-blocking.  That is basically writing routines that never wait for something to complete, but can check to see if it's time for something to happen.
Asynchronous programming.  This is using things like timers to make things happen "outside" your main loop.


You've got interrupts running and interrupting your code. Those take some cycles to run.


I found a solution. As the signals where too close I found where I could tone down the signal strength using:

   radio.setPALevel(RF24_PA_MIN);

Because I didn't want to loose long range capabilities too I send my packet out 4 times at this lower signal and then increase the strength back to max to send out another 4 packets. This way my close range and far range relay will receive the signal.


Can someone check my code? My Arduino isn't doing a consistent count cycle

The only reason it might "jump the gun" would be this line:

         while(digitalRead(Prox_Input) == HIGH){}          // waiting the sensor signal

I suggest you check for a transition, that is, make sure the proximity switch has become LOW, and then wait for it to become HIGH again. So for example, if sending HIGH to the relay should make the proximity sensor read LOW, then put a loop in to make sure it does that, before proceeding.


Correct Capacitors to use with L7805 Voltage Regulator

The answers are in the notes:

  Although no output capacitor is need for stability, it does improve transient response.
  Required if regulator is locate an appreciable distance from power supply filter.

So  the values aren't critical to the operation, but you should have them there. Bigger capacitors give more energy to the regulator and more energy to your circuit (input and output capacitors respectively) but at the cost of lower frequency response. The actual values you select depend on your circuit, not the regulator. 10µF is a good "ballpark" figure to use in most circumstances.

The input capacitor reduces the impedance of the power source by providing a local source of power. The output capacitor is like the "reservoir" capacitor you should have at the power entry to all boards anyway, and reduces the impedance to the rest of your circuit.

For the higher frequency responses you should have smaller value decoupling capacitors by all your active components anyway.

You can also add more smaller capacitors to the output of the regulator to improve high frequency responsiveness if needed - you're not just limited to the one capacitor.


I'm working on a NodeMCU project and have a small doubt about LEDs and resistors

No! Most likely it will not work.
An LED lights up if the Voltage between the Anode (one side of the LED) and cathode (the other leg) exceeds a so called forward voltage (Vf).
This Vf depends on the creation process and differs between different colors. Vf can be between abt. 1.8 Volt (red LEDs) and abt. 4.2 Volt (blue LEDs). Even if the LEDs would have the same color, they might have different forward voltages. If you arrage 4 LEDs in parallel, like you did above, the Voltage over the 4 LEDS is as low as the Vf of the LED with the lowest Vf among the four. If the four LED would not have equal (Vf)s, only one LED will light up and all others stay dark or just glow a little bit.
The sum of the current that flows through the 4 LEDs must also flow through the resistor. So the resistor must let pass 4 times the current that is required for one LED. An normal 3mm or 5mm LED works best at about 10mA to 20mA. Let's say the LEDs have all the same Vf = abt. 2 Volts, and you choose to drive them with 15 mA.
You need 60 mA in sum for the 4 LEDs, that must pass the resistor. You can compute the required resistance with  Ohms law. R = U / I.

R is the resistance in Ohms.

U is the voltage over the resistor in Volts.

I is the current through the resistor in Ampere.
U = Voltage of the ESP (3.3 Volt) minus
the lowest forward voltage of the LEDs (2 Volt)
I = the wanted current 60mA = 0.06 Ampere
R = (3.3-2) / 0.06 = 140 / 6 = abt. 23 Ohm
(27 Ohm resistors should be available.)

The resistor depends on the Voltage of the ESP, the kind of the LED and the amount of current you need to reliably light up the LEDs. You can not just take values from schematics or discussions the internet. Also 60 mA is very much current for the ESP pin. That might be a problem.
The best way the Light up 4 LEDs from one pin would be to use one resistor for each LED and a MOS FET Transistor that is connected to 5 Volts with its Drain pin, the parallel LED resistor pairs with its Source and to the ESP pin with its Gate. You should also be sure that the MOS FET you use is able to switch with a 3.3 V voltage from the ESP on its Gate.
If you did not understand what I have written, I advice you to learn the basics before experimenting further. The values above are all useless if the conditions change.


Unlike a normal servo motor where the argument of the Arduino's servo.write(angle) method represents a position, a continuous servo motor uses the argument for speed and direction.  Most continuous servo motors interpret stop to be approximately 90 degrees.  Full, say, reverse as 0 degrees.  And full, say, forward as 180 degrees.  As stated in the above link:

  On a continuous rotation servo, this will set the speed of the servo
  (with 0 being full-speed in one direction, 180 being full speed in the
  other, and a value near 90 being no movement).

Also of interest, most continuous servo motors have an adjustment to set the "90 degree position" (full stop).  That is to say, servo motor control signals are analog, not digital!  It follows that the processor's interpretation of the "90 degree position" may not be the same as the servos' interpretation of the "90 degree position".  Hence the ability to adjust the servos' interpretation.

This picture from the parallax servo tutorials web site shows how this is done:


Quaternion values from BNO055 not available

Apparently in the setup() it is preferable to have a delay(1000) as opposed to delay(100).

Code

#include <Wire.h>
#include <Adafruit_Sensor.h>
#include <Adafruit_BNO055.h>
#include <utility/imumaths.h>
#include <math.h>

#define DEG (180/M_PI)

Adafruit_BNO055 bno = Adafruit_BNO055(55);

void setup() {
  // put your setup code here, to run once:
  Wire.begin(13, 16, 400000);
  Serial.begin(115200);

  if (!bno.begin()) {
    Serial.println("No BNO055 Detected!");
    while(1);
  }
  delay(1000);
  bno.setMode(Adafruit_BNO055::OPERATION_MODE_NDOF_FMC_OFF);
  bno.setExtCrystalUse(true);
}

void loop() {
  // put your main code here, to run repeatedly:
  imu::Quaternion quat = bno.getQuat();
  imu::Vector<3> euler = quat.toEuler();

//  Serial.print("W: ");
//  Serial.print(quat.w());
//  Serial.print(F(" "));
//
//  Serial.print("x: ");
//  Serial.print(quat.x());
//  Serial.print(F(" "));
//
//  Serial.print("y: ");
//  Serial.print(quat.y());
//  Serial.print(F(" "));
//
//  Serial.print("z: ");
//  Serial.print(quat.z());
//  Serial.print(F(" "));

  Serial.print("Yaw: ");
  Serial.print(euler[0] * DEG);
  Serial.print(F(" "));
  Serial.print("Pitch: ");
  Serial.print(euler[1] * DEG);
  Serial.print(F(" "));
  Serial.print("Roll: ");
  Serial.print(euler[2] * DEG);
  Serial.print(F(" "));
  Serial.println("");
  delay(200);
}


Why does the Arduino UNO have a separate power port if USB also powers it?

Can you power the Arduino off a USB cable alone, without using the
  regular power connection?

You can use the USB cable alone to power the board.

  If so, what's the point of the additional power connection: to provide
  extra power?

You can use either to power the board. By using just the power plug you can make your Arduino portable by using a battery box or power it via a wall plug.

  Also Why not just have two usb ports one for power one for connecting
  to the computer, or a micro usb.

Only ONE USB is needed to power and program.


One of those MQ gas sensors ? They are electrochemical sensors. They can be calibrated more or less with a known concentration of a certain gas. But since the are often sensitive to a number of gasses, you do not know the concentration of that specific gas that was used for calibration.

A number that is going up and down is what you have. You can make a graph with it to show the value for each hour or each day.

The MQ gas sensors have a "preheat" or "burn-in" time. It is often 24 hours. Keep the sensor on for 24 hours to get more stable output values.

A temperature sensor is completely different, it contains electronics inside and has been calibrated at the factory. The MQ gas sensors are just a few wires, a heater and some chemicals.

[ADDED]
That is a module with the MP503 gas sensor. It just like the MQ sensors a electrochemical gas sensor. According to the datasheet it is sensitive for alcohol and smoke and the "preheat" or "burn-in" is called "aging time" and can be up to one week! The module has a amplifier.

The detection of gasses is according to a certain curve. To calculate the concentration of gasses a calculation is needed (and a calibrated sensor). I don't see that calculation in the supplied library. So all you have is numbers that change according to the air quality. That's all. And that is normal for these sensors.

Read the information and pdf files on that seeed page about this Grove module. It clearly says that you can't measure the concentration of gas (not "quantitatively"), you can only tell if the air quality gets better or worse (qualitative).


Recording of sensor results but only retain the last 3 sets of data

It depends how big the data is... if one data set is 100 bytes, you can spend 300 bytes of internal SRAM memory.

What you also can do if the memory usage is too big, is to add external SRAM, like the 32K256 which has 32 kb (kilobyte) SRAM or the 23LC1024 which has 128 kb SRAM.

To loop through the data sets you can easily use a so called 'ring buffer'.

You allocate 3 sets of data (like 3 arrays of a byte array), and an index. the index you increase after every use like:

index = (index + 1) % 3

External SRAM normally uses SPI to communicate with, and you can read/write it by a single byte, multiple bytes or page (typically 128 to 512 bytes). You cannot directly store variables in it, but you have to manually keep track where you store what ... for 3 data sets this will be relatively easy. You can even calculate (beforehand) the number of data sets that can be stored and cycle through them as needed.


How can I sense when someone is sleeping with my Arduino?

I actually did something like this, using a PIR Motion sensor.

The motion sensor is good enough to detect a person turning in their sleep, and my simple algorithm just counts movements per minute and when its over a threshold (found by trial and error), it sounds the alarm to wake you up.

The image above represents my body movements during a night. The spikes represent a high movements/minute.

  Here we see after about 30 minutes body motion was minimal. This suggests I was in a deeper stage of sleep during that time.

  The spike at 250 minutes (around 4:30AM) is when I woke up only to
  realize I could sleep for couple of hours longer. I recall the time
  being 4:38 when I looked at my clock and I was already facing it. This
  means I turned around to face the clock but actually "woke up" 8
  minutes later to see the time, and then turned back around (indicated
  by the shorter spike at 265).

  The data suggests I was not able to sleep very well (compared to the
  time period between 30 and 240 minutes) after waking up once and
  finally got up at 400 minutes (7:00AM), when I shut everything down.

Here are a couple of posts from my blog that have a lot more information.

Body Movement During Sleep
Intelligent Alarm Clock Hardware


Passing variable value in structure object

Use class and constructor

#include <EEPROM.h>
class MyObject {
    boolean stat;
    char password[6];
    char mobile[11];
  public:
    MyObject(bool tempStat, char tempPassword[], char tempMobile[])
    {
      stat = tempStat;
      strcpy(password, tempPassword);//As suggested by mikael
      strcpy(mobile, tempMobile);
    }
};

char pass[6] = "62345";
void setup() {
  Serial.begin(9600);
  while (!Serial);
  MyObject customVar(true, pass, "7539514682");
  EEPROM.put(1, customVar);
  Serial.print("Written custom data type!");
}


It is a common misconception that, because when you print a float you only get 2 decimal places, that the float only has 2 decimal places.

That is not true. A float doesn't have a number of decimal places - that is how it gets its name - floating point: the decimal point floats around as needed.

The problem is actually that, by default, all the Arduino print and string conversion functions are set to 2 decimal places. Unless you specify the number of decimal places you want to print (or convert to) you get 2 decimal places.

By specifying 5 decimal places when you print or convert to a string you get 5 decimal places.  It still won't always give you exactly the same number, but that is because a 32-bit float cannot store all possible numbers, so some are only an approximation. It's still a whole lot more accurate than 57.10598 -> 57.11 though.


Consequences of dynamically changing input/output configurations of digital pin?

There's no problem reconfiguring pins.  It happens all the time.  One example is with ping sensors where the pin is used as an  output to send the ping and then switched to an input to wait for the response.  The only caveat is that you must be sure what you're connected to.  For instance, if you set a pin to OUTPUT and LOW and it just happens to be connected to a HIGH OUTPUT then you just fried your board.


I do not have your PID_v1.h, but I made a simple experiment trying to control your example with a simple P-Controller instead of the PID lib. I made the following changes to your code:

...
double K_P = 1;
...
//myPID.Compute();
  Output = K_P*(Setpoint - Input);
  Input += Output;

This is working for very small amounts of K_P, but as soon as K_P gets higher than 2.0 it gets instable very fast. I guess this is what you are observing. The reason for me is, that you have implemented a ideal control path. In real control tasks you will always have some transfer behavior

Therefore I added a simple PT1 element (first-order lag element) to your code, now your system is much more stable and you can experiment with the K, I and D factors. Here it works with K_P even higher than 400:

// #include <PID_v1.h>

const unsigned int numReadings = 500;
double analogVals[numReadings];
unsigned int i = 0;
int angle = 0;
//Define Variables we'll be connecting to
double Setpoint, Input, Output;
double Input_PT1;
double K_P = 20;
//Specify the links and initial tuning parameters
//PID myPID(&Input, &Output, &Setpoint,2,5,1, DIRECT);
void setup()

{
  //turn the PID on
  // myPID.SetMode(AUTOMATIC);
  Serial.begin(115200);
  Setpoint = 300;
  // myPID.SetOutputLimits(-2,2);
  //myPID.SetSampleTime(100);
  Input = random(292, 302) ;
}

void loop()
{
  if (i % 2 == 0) {
    Input += random(-2, 3);
  }
  angle += 1 % 360;
  Input += sin(angle * 355 / (113 * 180));
  //myPID.Compute();
  Output = K_P * (Setpoint - Input_PT1);
  Input += Output;
  // start PT1
  Input_PT1 -= Input_PT1 / 25;
  Input_PT1 += Input / 25;
  // end PT1
  analogVals[i] = Input_PT1;
  i++;
  if (i >= numReadings)
  {
    for (int j = 0; j < i; j++) {
      Serial.println(analogVals[j]);
    }

    i = 0; //reset to beginning of array, so you don't try to save readings outside of the bounds of the array
  }
}

Some hint:

The sketch above does not initialize Input_PT1, so it takes some secondes until you reach a steady value of 300, if you do not want to wait, just initialize Input_PT1 with 300. But this is exactly where you can start increasing first I, then D factors to try to increase speed for reaching a steady value of 300 and experiencing what influence I and D part will have.
Input_PT1 is not a good naming, since this is the output of the PT1 element, but since you are using it as the PID Input, I did not change.

Here a drawing of what I implemented in contrast to your sketch (at least I hope so ;-))


Can analog pins be defined as either their analog name (A0) or their digital pin number?

For example, instead of defining A0 for a pinout with the Uno, it could be 14?

Yes. In fact A0 is just a placeholder for the number 14.
For all these things you should look in the pins_arduino.h file (Arduino\variants\wifio) for any variant you are interested in. That's where most of these symbols are defined. For example:
#define PIN_A0   (14)
#define PIN_A1   (15)
#define PIN_A2   (16)
#define PIN_A3   (17)
#define PIN_A4   (18)
#define PIN_A5   (19)
#define PIN_A6   (20)
#define PIN_A7   (21)

static const uint8_t A0 = PIN_A0;
static const uint8_t A1 = PIN_A1;
static const uint8_t A2 = PIN_A2;
static const uint8_t A3 = PIN_A3;
static const uint8_t A4 = PIN_A4;
static const uint8_t A5 = PIN_A5;
static const uint8_t A6 = PIN_A6;
static const uint8_t A7 = PIN_A7;

Incidentally, on the Uno you can also just use 0 for A0 with analogRead().


about how to write data in the whole EEprom?

In that case you write two pages, the first page containing the first 256 bytes and the second page containing the following 34 bytes.

You can do a speed check to see if writing the second page's 34 bytes by using the byte write is faster, but I doubt that.

In case you want to keep from the second page the remainder of the 34 bytes (the 256-34 bytes following), you first read the second page, than you change the first 34 bytes, than write it back.

Also note that there is a limit on the number of writes on a page. This is called page wearing. So if you write these 2 pages very often, you might want to come up with an algorithm to rotate through all the available pages in your EEPROM, and not writing every time to the same 2 pages.

EXAMPLE

Assume you want to write totalBytesToWrite:

// Calculate the number of pages to write, round up.
int pagesToWrite = int((totalBytesToWrite + 255) / 256;

for (int page = 0; page < pagesToWrite; page++) // Current page to be written
{
    // Calculate number of bytes to be written in this page, for the last page, write remaining bytes, otherwise 256
    int pageBytesToWrite = (page == pagesToWrite - 1 ? totalBytesToWrite % 256 : 256;

    // Write page (btw, I do not know what the second argument char deviceAddress means)
    page_write(n / 256, ??, &memory[n], pageBytesToWrite);
}


Why do my temperature sensor values become inconsistent when additional hardware is added to the board?

Don't take power for LCD from Uno pins. Connect LCD power to separate power source.


The real time clock method is the most accurate way but otherwise use millis

unsigned long startMillis = millis();
while (millis() - startMillis < LONG_DELAY_MS);

This will delay up to approx. 4294967295ms (2^32-1) or 49 days, after which the timer will catch up to the value of startMillis


Timer frequency calculation for UNO/Atmega328

Your comment:

TCCR2B |= (1 << CS21) | (1 << CS20); // 1:64 prescaling for timer 2

doesn't match the actual setting (= 1/32)

Also there are some issues with setting Timer2 CTC mode, it's better to set mode, then OCR2A + TCNT2 + interrupts and then Prescaler to start the timer. It behaves as there is OCR2A=0, so the frequency is much higher than expected.


I'm not sure which SoftwareServo library you are talking about, but with regards to the built in "Servo.h", no, it will not disrupt the arduino's other communication abilities, and they will not disrupt it.

I've used servos simultaneously with Serial, I2C, and SPI before and never had any problems.

The servo library does use a timer, but it will only conflict with an external library or code that uses the same timer. Which timer it uses depends on the board, just look in libraries/Servo/src/avr/ServoTimers.h to see which it uses, in what order as they fill up. Filling one up takes effort though, by default it puts up to 12 servos on each timer. The processing overhead is very low since they only update at 50Hz, so that will not become a problem.


I want to begin with arduino programming

You can purchase some great starter kits too:

They're easy to search for, here's a few that popped up right away:

http://www.arduino.cc/en/Main/ArduinoStarterKit

http://www.amazon.com/Kuman-Project-Complete-Starter-breadboard/dp/B016D5KUHS/

And here's one that I own, and I've recommended to other people:

http://www.microcenter.com/product/458578/Arduino_Compatible_Maker_Kit_with_LCD_Display

If you have a microcenter or radio shack or Fry's in your area, they all stock a variety of different starter kits.


Can I link another device to the Uno's clock?

Rather than using microprocessor-specific low-level programming, I was able to get a suitable signal using the core tone() function:

tone(11, 2000000);

It can be used to generate a 50% duty cycle square wave of a custom frequency on any individual GPIO pin (I'm using 11 in this case). Given the name, it's obviously designed for producing simple audio output, and 2 MHz is way above the range of human hearing.

The documentation doesn't list any upper limit on the frequency though, and the code it's based on doesn't appear to introduce any limitations. With that said, it clearly can't run faster than the internal timer it's based on (which I think will typically be 8 or 16 MHz).

It seems reasonable to assume that it will be in-sync with the microprocessor's internal clock, although I haven't been able to confirm that empirically as I don't have suitable equipment at home. Similarly, I haven't been able to confirm that it's actually producing a 2 MHz signal, but the LCD display is working properly so it's likely to be in the right vicinity. I had previously tried running it from regular PWM, but that didn't work, so frequency is obviously important here.

The signal can be stopped by calling:

noTone(11);

There are a couple of caveats to be aware of when using tone(). First of all, it can only work on a single pin at a time, so you can't generate multiple signals with it. And secondly, it will prevent some PWM output from working properly (on pins 3 and 11, according to the documentation). This is because it has to reconfigure one of the internal timers which is normally used for PWM.


At the moment you have become used to working with pre-defined named colours, like CRGB::Red and CRGB::Green.  Those are just symbolic names for combinations of numeric values for red, green and blue.

So by using numeric values and varying them slightly over time you can create fade effects.  I am not personally familiar with that library or class, so I cannot tell you how to do it, but reading the documentation should show you how you can use variables to specify each of the colour components as a single colour.

As for how to fade from red to green - since they are two completely separate colours (they use separate colour channels in the LEDs) there are two main ways of doing it:

Start with red on full and green off. Slowly increase green to get yellow. Then slowly decrease red to get green.
Start with red on full and green off. Slowly increase green while slowly decrease red. At 50% they will cross over.


home automation - What's a compact way to control a light switch with Arduino without interacting with high voltage?

you can glue an LED controlled by an MCU into the sensor hole of a dusk to dawn sensor. these are available in socket and outlet shapes, are UL certified, and require no messy wiring. I've been able to switch an outlet model by duct-taping an ESP8266's built-in LED against the window; can it get any simpler?

Here's a working example's parts, exploded for easy identification.

You can spot an inline socket-to-outlet adapter, a dusk-to-dawn sensor, a bulb, a cheap nodeMCU ESP8266 devboard, a short micro usb cable, a USB wall wort, and an RGB LED module attached to dupont wires. I'm wiling to bet anyone here can figure out how these pieces fit together to make a $10 "smart bulb". You can get most of these parts at the local home center, and everything shown on amazon/ebay.

Of course you won't get a lot of respect from EEs, but you will get the job done quickly and safely, and the opto-isolated controls work with any platform. I have cheaper/smaller build i've moved onto, but i still have several of these switch builds in-place for years and they work great.

I would recommend getting a dusk-to-dawn switch that is labeled as being compatible with LED bulbs; they tend to use a lower-"bleed" IGBT instead of the older/cheaper diac/triac combo which causes some low-energy bulbs to flicker when off.


will the buzzer make continuous sounds

If you mean the sensor will detect the rain drops in the air
Nop it's tiny to read it in the air
But if there is drops on the sensor your sensor will not gives you the right reading

There is a water proof ultrasonic sensors available.

I am working on water level devices, after long path of searching in different ultrasonic sensors and after I tried a lot of method like using water proof Cloth, I found the best way is using water proof sensors PLUS water proof cloth.

water proof sensors work perfectly in high humidity but at the same time if there is a water drop on the sensor the reading will be different, and for that some cars manufacturers used not only one sensor, to avoid the errors. and calculate the differences.

The left car used old technology with separate sensors, but that's make errors the only good thing was to detect more things, in the next generation they mix them together.

water proof cloth will make the water drops not stuck at the sensor, but you will need to replace it every 5-6 months. "in your case because the sun will destroy the cloth" in my case and because my sensor inside tanks that's will least more.

I tried to spray the sensor with a different material to make my sensor not catch any water drops, it dose not work too.

And to make my cheap sensor water proof, I tried to use ceramic layers, and that's not work too, they use it with ultrasonic fog maker, these layers not work with cheap ultrasonic sensors, it's need a lot of power to vibrate it and different frequency. and of course you need to replace the layers "depending on the environment"

If you find ultrasonic car sensor with special material for water drops just let me know, I am searching on that too.

NOTE These days car manufacturer use different ways, in the past the cover was vibrate itself and made from aluminum, now they cover it and make different filters to ignore the plastic cover, How?! maybe it's different plastic or material maybe they find away to vibrate the plastic! sorry I could not find the secret.


If I change it back to 115200 baud, it uploads fine...even though the sketch itself initializes the serial port to 57600.

The bootloader is a piece of code designed to work at a specific baud rate. As KIIV said in his answer only the USB-based Arduinos would be relatively immune to changing the rate.

What your own code does, after being uploaded, is completely irrelevant.

  Avrdude fails at specific baudrates

Your title really should be: "Avrdude only works at one baudrate (the one it was designed to use for a specific board)"


Why is 'n' parameter of snprintf ignored?

snprintf() will not write more than <size> (snprintf's 2d argument) characters to your buffer, but it does count (and discard the extra) characters it would have written, had there been space enough, and that is the number it returns. Yeah, it can be confusing!

See this snprintf() reference.


5 switches, 5 leds, 5 tones, in an Array

You have a rogue ; here:

  for (int i = 0; i < sizeof (LED) / sizeof (LED[0]); i++);{
  pinMode(LED[], OUTPUT);                                 ^------HERE
}

That is terminating the for, making it empty, and the following block is a completely different scope.

Another thing I spotted - you aren't putting i into your array index LED[] (should be LED[i]).  The same is true with Buttons[].

However, on a different subject, this:

buttonState == digitalRead(Buttons[0]);
buttonState == digitalRead(Buttons[1]);
buttonState == digitalRead(Buttons[2]);
buttonState == digitalRead(Buttons[3]);
buttonState == digitalRead(Buttons[4]);

is pretty meaningless.  You are comparing values and throwing away the result.

In a similar vein:

if (buttonState = Buttons[0])

stores the current value of Buttons[0] into buttonState and succeeds if Buttons[0] is anything other than 0.  The same goes for all the others.

You need to sort out your comparisons (==) and your assignments (=) and also sort out what you think you are doing with all those buttonStates at the top of loop.


I've had good success with the u8g2 library for the small I2C OLEDs.
u8g2 on GitHub


If you know the forward voltage of the LEDs you can easily do some calculations.

For a typical red LED the forward voltage is around 2V.  Other colours vary.  So we can work out that, at 5V supply, each LED with its own 150R resistor, would take:

     V    5-2
I = --- = --- = 20mA
     R    150

With 11 LEDs in parallel on at once that would be 0.02 * 11 = 220mA.

That is far more than the 25mA an IO pin is able to supply, so you will damage the Arduino doing it like that.

Instead you will need to switch each chain of LEDs with a transistor of some form.  I'd choose a logic-level N-channel MOSFET as a "low-side" switch:

simulate this circuit – Schematic created using CircuitLab

Now your Arduino doesn't care about the current - all it sees is the MOSFET.

If your LED forward voltages are less than 2.5V you can also chain them together to halve the current:

simulate this circuit

Since the forward voltage is now double you use a smaller resistance to set the current (R=V/I, where V is 5-2Vf).


Did you use setmode() to put it in station mode?

wifi.setmode()

Configures the WiFi mode to use. NodeMCU can run in one of four WiFi modes:

Station mode, where the NodeMCU device joins an existing network.
Access point (AP) mode, where it creates its own network that others can join.
Station + AP mode, where it both creates its own network while at the same time being joined to another existing network.
WiFi off.

When using the combined Station + AP mode, the same channel will be used for both networks as the radio can only listen on a single channel.

NOTE: WiFi Mode configuration will be retained until changed even if device is turned off.

Syntax

wifi.setmode(mode)

Parameters

mode value should be one of

wifi.STATION for when the device is connected to a WiFi router. This is often done to give the device access to the Internet.
wifi.SOFTAP for when the device is acting only as an access point. This will allow you to see the device in the list of WiFi networks (unless you hide the SSID, of course). In this mode your computer can connect to the device, creating a local area network. Unless you change the value, the NodeMCU device will be given a local IP address of 192.168.4.1 and assign your computer the next available IP address, such as 192.168.4.2.
wifi.STATIONAP is the combination of wifi.STATION and wifi.SOFTAP. It allows you to create a local WiFi connection and connect to another WiFi router.
wifi.NULLMODE to switch off WiFi

Returns

current mode after setup


Take an Arduino or Teensy prototype to Mass production - Loading software onto microcontroller

Arduino code and AVR code is essentially the same, at least once compiled it is. The only real difference is the existence of the bootloader, and that is not essential.

For quantities of a hundred or so it is probably most cost effective to manually program them via an ISP connector to the board. For larger quantities Atmel provide a mass programming service to pre-program the chips, but that costs money so the more you have done at once the cheaper it is per chip. I am not sure on Atmel's procedure off hand but others I have used just take either a .elf or .hex file which the Arduino IDE is perfectly capable of producing.

Either way you should design in an ISP connector on your board so the firmware can be upgraded in the future if needed.


Analog output low voltage issue, how to troubleshoot

why analogWrite? analogWrite parameter values are 0 to 255 (or 1023) so analogWrite(pin, 1) is close to 0.

analogWrite is PWM on digital ports and doesn't work on analog ports
analogWrite reference

use digitalWrite


You are calling setCursor() with:

//Row, Colum
lcd.setCursor (0, 4);
lcd.print(DiceOne);
lcd.setCursor (1, 4);
lcd.print(DiceTwo);

While your comment notes the order is Row, Column, there appear to be several LiquidCrystal libraries floating about, some of which use Column, Row order in the SetCursor() function. The official Arduino library source indicates the col, row order.

You are writing both values on row 4 (even though that doesn't exist on your display), and in columns 0 and 1, thus you are correctly computing the Dice values, but they are being written with no gap between.


expected primary-expression before ',' token

To answer your question we will assume your project is based on the Melody example at www.arduino.cc.

Likely you wanted to enter the ASCII values of these letters into an array of type char (type int would work as well.  But, in some cases, char would be more efficient).  To do this you need to place single quotes around each letter.  Specifically, you need to change your code:

int melody[]={ a,C,D, a,a,C,D,D,C, C,C,D,D,C, C,D,E,F,E,D,C};

...so that your line of code look like this:

int melody[]={'a','C','D','a','a','C','D','D','C','C','C','D','D','C','C','D','E','F','E','D','C'};


ArduinoUNO/MEGA, Is there a way to exceed 256 in analogWrite

Section 16, "16-bit Timer/Counter1 with PWM" of Atmel-8271J-AVR- ATmega-Datasheet_11/2015 describes using Timer/Counter-1 for 16-bit PWM, including sample code in both C and assembler. It might take a couple of reads over that section to get familiar with the hardware and learn what else T/C-1 is used for, and that you might have to give up while using it for PWM, but the code is fairly straightforward.

Using this T/C would give you 2-bits more resolution in your PWM output than mapping onto an 8-bit counter, if that is what your project needs.

+1 for the question. Not having needed PWM output for anything more than a demo with my DMM (yet), it hadn't occurred to me to look for a higher resolution until now.


I think you'll find you need to add some pull up resistors to both connections on the I2C (SDA and SCL).

Also I'm not sure what you should be pulling them up to 3.3v or 5v.  You should check if you need a level shifter or if the device you are connecting is 5v tolerant.

According to you question you should be using the address 0x6A.  0x6B is when you have an external pull up resistor, which I don't think you do have.  So your code is correct.


Generate 1khz square signal with Arduino Mega

My first question is: Is there a way to automatically control an output pin from the timer, without having to execute any line of code in my arduino program ?

Yes. It's called PWM with a 50% duty cycle.
You need to read up on 19. Output Compare Modulator (OCM1C0A) in the datasheet.

My second question is: What is wrong on my calculation on my code ? I want 1khz and i get 990Hz

You have to take into account the number of CPU cycles it takes to start executing your ISR. There's a short bit of code before your code is run that preserves any used registers on the stack and allocates any room needed for local variables. That takes time, and must be calculated into your timing factor.


How can I compare two serial port readings on Arduino Mega?

I think your code is implemented wrong in general. Even if it worked "like intended" it would not behave like you might want it to.

The first problem is, that you are polling for bytes that are received asynchronuously. That means that  two byte sequences must not only be equal, they must also be sent "at the same time" if they should pass your comparison test. As the atmega will loop() very fast, there is only very little tolerance in timing.

Secondly, the variables you write received values to are not reset, meaning that once they have the same value they will pass the if statement until another byte has been received. Actually they aren't initialized and therefore will be 0 at the very beginning. So I wonder why you don't get your Serial interface flushed with true. Is this actually the entire code?

As a solution I suggest accumulating received bytes into a buffer and waiting for a soecific termination byte (often /n). If a termination character has been received, perform the comparison on that buffer.


NodeMCU ESP8266 on Arduino IDE doesn't detect Wifi

Your router might be using 5GHz Wifi which the ESP8266 doesn't support but your other devices likely do. Try setting your wifi network to 2.4GHz.


My Digispark board won't show up in Ports tab in Arduino IDE (OSX)

I don't think it is supposed to. The Digispark briefly connects in "bootloader" mode, which you spotted as "Vendor-Specific Device:".

Then after 5 seconds it runs the loaded sketch. If your sketch doesn't create a USB port (eg. a keyboard) then it will disappear from the USB list.

See:

http://digistump.com/wiki/digispark/tutorials/connecting

You don't select the port, the core files automatically find the Digispark and program it. You have to plug in the Digispark when instructed, to activate the bootloader.


How do I make/get a odometer for a lunch box sized robot?

I had the idea to use a computer mouse (optical) to do this - cheap, easily available. You would need two, if you want to be able to measure turning rate, one on the left and one on the right.

You don't even need the whole mouse - if you pull it apart you can ditch the case, the buttons, and about half the circuitry. You will need to do some hacking to figure out how it works, but I doubt you'll find a cheaper odometer that is anywhere near as accurate.

Note: I pulled one apart, then got distracted on another project, but I can't think of a reason why it wouldn't work.


Some shields let you use jumpers or something to change the pin assignments, but I don't believe the Seed motor shield does.  What you can use is a go-between shield between the two shields to remap the pins on the top shield.  Then in your code, you just initialize the second instance using different pins.  You just have to make sure the alternate pins have the features you need, like pwm.


Parsing the string really is the only way. However there are many ways of doing it.

My preferred method is to first check that the format is correct, by looking for the T and Z being in the right place:

if (timeString[8] == 'T' && timeString[15] == 'Z') {
    ... parse in here
}

And the parsing is just making numbers with multiplication:

int year = (timeString[0] - '0') * 1000 +
           (timeString[1] - '0') * 100 +
           (timeString[2] - '0') * 10 +
           (timeString[3] - '0');

You can clean things up with a macro if you like:

#define NUM(off, mult) ((timeString[(off)] - '0') * (mult))

Then:

int year =   NUM(0, 1000) + NUM(1, 100) + NUM(2, 10) + NUM(3, 1);
int month =  NUM(4, 10)   + NUM(5, 1);
int day =    NUM(6, 10)   + NUM(7, 1);
int hour =   NUM(9, 10)   + NUM(10, 1);
int minute = NUM(11, 10)  + NUM(12, 1);
int second = NUM(13, 10)  + NUM(14, 1);

And then, yes, put them in a struct tm (or directly assign them calculation results without using the intermediate variables) and call mktime().


Problem communicating between arduino UNO R3 and Mega 2560 via MAX485

You have forgotten to add mySerial.flush().

mySerial.flush() waits for the transmission of outgoing serial data to complete.

Add it right after you have sent the data and want to change the DE pin status.


Pins A6 and A7 are analog only pins. They have no digital functionality at all.

You can see that pins 19 and 22 only have ADCn on them - no Pxn for digital operation (ignore the colour scheme of those pins - that's an error in the datasheet).


Unable to set up Intel Edison on Windows

I fixed it by following these steps (through trial and error, I don't really understand what I did but it works ...)

I am using Windows 8.1, 64 bit edition.

Download the Edison firmware from https://software.intel.com/en-us/iot/hardware/edison/downloads. For me it was http://downloadmirror.intel.com/25028/eng/edison-image-ww25.5-15.zip.
Extract the zip file.
Start the Windows Command Prompt as Administrator.
The extracted archive should contain a file called "flashall.bat". Change to the directory containing the file.
Connect all micro-USB ports and the barrel connector. At this point Windows did not recognize the Edison as a flash disk. This is part of what I was fixing.
Follow the steps in my question until the output on the console (also from my question) appears.
Run "flashall --recovery"
Run "flashall". When "Please plug and reboot the board" appears, disconnect the A (or middle) USB port and the barrel connector for the power. At this point everything is switched off. Then reconnect A and the barrel connector to reboot the board.
Wait about 5 minutes for the rest of the process to run automatically.

At this point everything should work again.

You should see this on the command line in Windows:

C:\Users\_\Desktop\edison-image-ww25.5-15>flashall --recovery
Starting Recovery mode
Please plug and reboot the board
Flashing IFWI
!!! You should install xfstk tools, please visit http://xfstk.sourceforge.net/

C:\Users\_\Desktop\edison-image-ww25.5-15>flashall
Using U-boot target: edison-blankrndis
Now waiting for dfu device 8087:0a99
Please plug and reboot the board
Dfu device found
Flashing IFWI
Download        [=========================] 100%      4194304 bytes
Download done.
Download        [=========================] 100%      4194304 bytes
Download done.
Flashing U-Boot
Download        [=========================] 100%       237568 bytes
Download done.
Flashing U-Boot Environment
Download        [=========================] 100%        65536 bytes
Download done.
Flashing U-Boot Environment Backup
Download        [=========================] 100%        65536 bytes
Download done.
Rebooting to apply partiton changes
Dfu device found
Flashing boot partition (kernel)
Download        [=========================] 100%      6111232 bytes
Download done.
Flashing rootfs, (it can take up to 5 minutes... Please be patient)
Download        [=========================] 100%    566330368 bytes
Download done.
Rebooting
U-boot & Kernel System Flash Success...
Your board needs to reboot to complete the flashing procedure, please do not unplug it for 2 minutes.

C:\Users\_\Desktop\edison-image-ww25.5-15>


best way to protect a digital or analog input from 12volts

There are some suggestions at Protecting Inputs in Digital Electronics .

Amended answer

Testing of my earlier answer involving clamping diodes gave unsatisfactory results. Due to the small current flow the diodes allowed a considerable voltage to reach the input pin (like, 9 V).

The amended circuit below, tested with 12V input, satisfactorily keeps the Arduino input pin to 4.9 V, even with 12 V from the device. The current through R1 is around 7 mA which is what you would expect:

I = V / R
I = 7 / 1000
I = 7 mA

The 1N4733A is a 5.1 V, 1 W zener diode which can therefore handle dropping 5 V at 7 mA.

In case you are wondering where the number 7 comes from in the calculations above:

The input voltage is 12 volts
The desired output is 5 volts
Therefore we need to drop (12 - 5) volts over the resistor
Thus 7 volts are dropped over the resistor

Further reference material:

10 Ways to Destroy An Arduino
Protection
Microcontroller Input Protection Techniques


Calculation:

320 x 240 resolution (assuming 8 bits for 256 colors) is 76,800 bytes

Assuming a frame rate of 50, that is 50 * 76,800 = 3,840,000 bytes/s

The most Arduino's are 16 MHz so assuming quite some instructions are needed (for converting and doing something) I doubt you will get this frame rate.

Also, you cannot store a complete page, but this may not be necessary.


Can multiple Arduinos be connected to a single relay?

Looking at the schematic, here are some points to be kept in mind when using this relay board:

The relay board should be powered through the 12V connector
The relay board has its own 5V regulator
The optocouplers are attached in "reverse"

So, the external connections should be

Connect all the arduino grounds together, and connect them to the board ground
Do not connect any +5V wire together
Connect arduino 1 to IN1, arduino 2 to IN2 and so on
Writing a HIGH value on the INx pin will result in the relay to be de-energized (so contact goes in NC position), writing a LOW value on INx pin energizes the relay (so contact goes in NO position)

If making this connection the board does not work as expected, try to detach all the arduino boards and manually shorting IN1 and +5V, IN1 and GND, IN2 and +5V, ...


You can choose to treat the byte array as a float array by typecasting. Your attempt isn't far from a solution:

((float *)data.data)[0] = lon; // uses data.data[0] ... data.data[3]
((float *)data.data)[1] = lat; // uses data.data[4] ... data.data[7]

When printing you should also treat the data array as float array:

Serial.println(((float *)data.data)[0]);

It looks like you are sending the data over some interface. Then of course you need to typecast the binary data back into a  float at the receiving end (if you want to do something useful with it) - similar to what is done above when it is passed to Serial.println.


fast memory buffer and setting output state

I would use an array, they're about as simple as it gets. 84 clock cycles per sample is very tight, but definitely possible. I'm guessing that's too close to the line to do any sort time testing - you will probably have to set up your loop to take exactly 84 instructions. This means you will probably need to hand-code in assembler. Be very mindful of branching instructions - both branches will need to take the same number of clock cycles.

The Uno (AtMega328) runs most (all?) instructions in one clock cycle, I don't know if the same applies to the Due. You would need to hand-code the assembler, check out how many cycles each instruction takes, and pad it out (there is a do nothing "NOP" instruction, which typically takes one cycle.

HOWEVER -

You can get all this work done for you by using a chip made for this purpose. This is called a Digital Delay Line, http://en.wikipedia.org/wiki/Digital_delay_line (or Analog Delay Line if you want analog values, e.g. for sound playback).


Optimization Teensy 3.6 Arduino IDE fast I/O Multiplexing Led Matirx

I have also written a driver for LED matrices based on shift registers. To quickly shift out the bits to the shift registers for each scan update, I used SPI. On the Teensy 3.6, this works quite well.

But what I suspect your issue is (since you didn't post your whole code) is that you are calculating each of the bit updates in between each shifting out. If you are doing this, I suggest that you don't. Instead, buffer the bit calculations, and use a timer interrupt to shift out each row update. This approach takes advantage of the fact that you are likely to recalculate the bit layout for the matrix overall at a much slower frequency than the need to send our row updates to effect the multiplexing of the LED rows. I explain this design in much more detail in this Instructable.

Using the interrupt allows you to cleanly do the heavy lifting of recalculating the bit layout into a buffer while the row updates will consistently go out, creating a very stable image. It's the closest thing you'd to true threading on Arduino-like platforms. Also, this approach will allow a much smaller base interval for row updates. In my code, I use a 5 µs update interval, that gets modulated in order to be able to create a 12-bit color palette. I probably could get a richer color depth on the Teensy 3.6 given it's clock speed, but I wanted my code to be universal, so I am able to get the 12-bit color on 8-bit AVR micro controllers too (e.g., Arduino Mega).

You can study (or use) my code at this GitHub repository, and read more about my LED matrices (hardware and software) at my website.


Problems with Dallas temperature sensor code

I presume the exact error you get is

  error: 'OneWire' does not name a type

This error is typical when the OneWire library (or any other library for that matter) is not located under the  libraries folder, which should be at the root of the Arduino installation folder.

Also, make sure that the OneWire.h and OneWire.cpp files are 1 folder down the hierarchy, as follows:

[Arduino Installation Folder]\libraries\OneWire\OneWire.h

If they are nested deeper inside the folder hierarchy, the Arduino IDE will not find these files in its initial scan, and you will get the same error.

Make sure to close all Arduino IDE windows and re-open it after fixing the folder path.


The schematic is totally working. My mistake was after burning bootloader, I was uploading code via ISP. If you upload code via ISP, you're removing bootloader.

Thank you everyone who helped me to I wasn't mistaken at schematic and else...


what else can I use to receive information that my Arduino sensed to people's smartphones/computers wirelessly?

take a different route. get the information to a pc (or to a server through a pc) and you have much more flexibility.

there are many ways to get that information to a pc, like serial, spi, i2c, acquisition cards, wired / wireless, ....


Arduino Mega keep states after reprogramming

You have basically 2 distinct problems here. The problem to somewhat automatically enable/disable the reset from USB and the problem to keep the relays at their set states over reprogramming.

Enable/disable reset: The easiest way is to use a jumper, that you disconnect everytime you want to program the board. If you want to do it remotely, you already described a valid way, though I think, that you don't need a relay for that. A transistor or MOSFET should be sufficient for it.
Keep the relay states:

  Like using a newer Arduino board which can keep pin states over reprogramming?

I don't think, that something like that exists. It does not make sense for general purpose microcontrollers to do that; they all start from a clean state. So you need to save the state of the relays outside of the Arduino. What type of device you want to use for that is up to you. Majenko mentioned flipflops, which gives you the most basic functionality for this. You could also use devices, which are interfaces serially, like shift registers or even port expanders. Using flipflops will be the easiest way, since the programming does not change much. There are many examples how to use each of these devices with an Arduino on the web.


Open the Uart0 Serial Port on Intel Edison

I have solved the issues and successfully connected this printer with the Compute Module. I solved the issue by changing the target of /dev/ttyAMA0 to /dev/ttyMFD1 as shown by http://iotdk.intel.com/docs/master/mraa/edison.html . This was the final step after I had installed pyserial.


It can have many options, the main reason is it cannot communicate with the Nano.

I try to create a list with options:

Hardware issues

Nano is broken (solution: change Nano)
USB cable is broken (solution: change cable)
USB port is broken (solution: change USB port)

Software issues

USB port 'corrupt' (solution: use another USB port)
USB connection incorrect (solution: reconnect USB cable)
IDE is corrupt (solution: reinstall IDE)
Nano in illegal state (solution: reset/reconnect power of Nano)
Serial communication is used (remove RX/TX wires)


Will I destroy my Arduino Uno if I connect a 600-mA DC motor to the +5V pin?

If you connect a motor to the +5V pin, it will always be on. Is that what you want?

The +5V pin on the Arduino Uno gets power from the on-board 5V linear voltage regulator OR from the USB jack, and thus the host computer. This allows the board to have a fixed 5V source even when applying 9 or 12 V to the barrel jack or the RAW pin, and to be powered by a USB host.

When you draw 600mA for your motor (ignoring what the other devices on the Arduino draw), you are drawing 600mA from the regulator's output. You are also drawing 600mA from the regulator's input, which supplies a higher voltage. Excess power is dissipated as heat. 5V * 600mA is 3W. If you power the board from 9V, you are discarding [(9V-5V)=4V] * 600mA = 2.4W of power. 2.4 Watts is probably too much for the little regulator to handle. It will get too hot and burn up.

If you do this, you will probably be able to still operate it powered by the USB port, as only the 5V regulator is damaged.

However, if you try to draw 600mA and power the board from a USB device like a computer, you may burn up the computer's USB chip and make it useless forever.

For high-power devices like motors, always power them from a sufficient external supply of the appropriate voltage. Be sure to connect the ground of the external power supply to the GND pin of the Arduino. Don't send high current through the Arduino board. The Arduino should handle signals, not power.

Use the signals to activate switching devices like MOSFETs, which are designed to control higher currents by low-power signals.


How to upload already compiled code when no changes were made?

You can upload hex file to your board from command line without Arduino IDE.

To get the hex file, use in Arduino IDE in menu the command "Export compiled binary". It will save the hex file next to the ino file.

I assume your board in printer has AVR MCU. Then you can use avrdude from command line to upload the hex file again and again without any compilation.

The avrdude command on Windows is (if started from the sketch's folder):

%LOCALAPPDATA%\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/bin/avrdude -C%LOCALAPPDATA%\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino17/etc/avrdude.conf -v -patmega328p -carduino -PCOM11 -b115200 -D -Uflash:w:Blink.ino.hex:i

The command line is for the Blink sketch and for AVC boards package 1.6.21


Sending MIDI messages using PING ultrasonic sensor

There is quite a bit that needs to be addressed for these programs to work, and I don't know too much about midi, but i'll use the arduino midi tutorial for info. http://arduino.cc/en/Tutorial/Midi?from=Tutorial.MIDI

The first code will take one measurement of an analog value, set it to note, make one digital reading of pingPin, set that to val, and then write noteOn() forever afterwards. The second code will continually make analog and Ping readings and then write those to serial if the ping reading is greater than 127.

Infinite loop aside, Your programs don't work largely because they send the sensor data in the wrong ways. The first byte sent to noteOn is a command byte, it should not contain sensor data. the arduino tutorial uses the command 0x90 to control the note being played on channel one. the second byte is the note and the third byte is velocity, which seems to work like volume.

to set the pitch and volume of channel one, you need to repeatedly send

noteOn( 0x90, note, volume);

If you want to play a note based on the analog readings that both of your codes set to "note" only when the ping value is larger than 127, you need something like this

if(ultrasoundValue > 127){
    noteOn(0x90, note, 0x45); //middle volume according to arduino tutorial
} else {
    noteOn(0x90, note, 0x00); //make the note silent by using 0 volume
}

if you instead wanted to control the pitch with the ultrasoundValue, you would need to scale the value to being within 0-255, and then use that as note instead of the analog reading. You can get much more complicated than this, but you will need to find a reference for the MIDI protocol you can use.


Simplest way is to have a flag to specify whether you've read the first reading or not.  Default to zero:

int read_first = 0;

Then you can say:

if (read_first ) {
    volt_V      = (resolution)*(float)sads1262Count;     // voltage = resolution * adc count
    Serial.print(volt_V,8);
}
else {
   // discarded first result, now we've read the first one
   read_first = 1;
}


Ethernet to Cellular Modem Possible? | GSM + Ethernet + Arduino

No, it's not possible.

Chiefly because the normal Ethernet shield is not capable of routing.  The Arduino never talks to the ethernet - it talks to the chip on the shield and tells it how to handle the ethernet connection - everything else is then done by the ethernet chip and the results passed back to the Arduino.

Similarly with GSM - you make requests to it and it goes off and does the work.

To link the two together you would need raw access to the incoming ethernet packets, and you would then have to perform NAT (Network Address Translation) and maintain internal state tables for current streams and such, and pass reformatted packets on to a GSM modem that could accept raw data like that.

Way outside the scope of a lowly Arduino.

Maybe possible with one of the higher end Arduino-ish systems like the Edison, Galileo or Yun (just) since they run Linux and have a real Ethernet port and a proper USB port to communicate with a proper celular modem.


the ArduinoJson library doesn't copy the strings, it only stores pointers and writes terminating zeros into input buffer. And your buffer buf is disposed by std::unique_ptr at the end of read_json() function


Use Arduino as transmitter and receiver UART

You sure now Serial.write() and Serial.read(). That's already what you want. A hint to make it clear to you: When using the common Serial.print() function only the RxD line is in charge an thus only "half" of the serial interface is used. If you connect TxD of arduino A to RxD of another arduino B and RxD to TxD respectively you have full-duplex communication which is what you're asking.


Arduino Mega 2560 and Android USB OTG serial communication

So I figured it out.

It was the VendorID. I found it and noticed, that the VIDs of the UNO and Mega are different.
I adjusted the code and now everything works as I expect.
So, thank you Chris Startton for the correct hints.

Thank you all.


Infortunately, I did not find any library but I found that the method shown below could work quite well for small projects. By adding a small delay, it helps the servo run a little smoother. It is not really ideal but it should work if your goal is to minimize the roughness of the servo.

Also by adding a 100uF capacitor between 5V and GND, the capacitor will help calm the sudden rush you might get when the servo first starts to turn. That rush is caused by the servo asking for more current when the servo is not moving.

#include <Servo.h>   //servo library
Servo myservo;       //servo object
int previousAngle = 0;

const int potPin = A3; //sensor pin

void setup() {
  myservo.attach(9);  //data pin of the servo
  pinMode(potPin, INPUT); //sensor pin as an input
}

void loop() {
  int val = analogRead(potPin);
  int angle = map(val, 0, 1023, 0, 180);

  if(angle>previousAngle)
  {
    for(int i=previousAngle; i<=angle; i++)
    {
      myservo.write(i); //turn servo by 1 degrees
      delay(10);        //delay for smoothness
    }
  }

  if(angle<previousAngle)
  {
    for(int i=previousAngle; i>=angle; i--)
    {
      myservo.write(i); //turn servo by 1 degrees
      delay(10);        //delay for smoothness
    }
  }

  previousAngle = angle;
}


Assigning an element of a multidimensional array to a second array

You can copy the array:

EXCLUSIVE_COLOR[0] = colors[0][0];
EXCLUSIVE_COLOR[1] = colors[0][1];
EXCLUSIVE_COLOR[2] = colors[0][2];

but this doesn't work in an initialization.

Alternatively, you can declare EXCLUSIVE_COLOR as a pointer to an
array of 3 integers:

int (*EXCLUSIVE_COLOR)[3]; // pointer to array 3 of int

Then you can have this point to a row of the 2D array, either by
assigning the pointer or in the initialization:

int (*EXCLUSIVE_COLOR)[3] = &colors[0];  // initialization

// Later in the program:
EXCLUSIVE_COLOR = &colors[1];

Note that when using this pointer, you will have to explicitly
dereference it:

for (int i = 0; i < 3; i++)
    Serial.println((*EXCLUSIVE_COLOR)[i]);

Edit: As pointed out by Juraj in a comment, you can instead make
EXCLUSIVE_COLOR a pointer to int. In this case you will make it point
to the first element in the row you want:

int* EXCLUSIVE_COLOR = &colors[0][0];

One nice thing of this approach is that you can use the “decay to
pointer” feature of the language to simplify the syntax:

int* EXCLUSIVE_COLOR = colors[0];

// Later
Serial.println(EXCLUSIVE_COLOR[i]);


How to make ESP8266-1S module work on Arduino Uno?

do I have to connect RX with RX and TX with TX or RX to TX and vice versa?

If you want to do serial communication between a sketch running on the Arduino and the ESP8266 you must connect the RX pin on the Arduino to TX on the ESP8266 and the TX pin on the Arduino to TX on the ESP8266.

If you want to do serial communication between the Serial Monitor on your computer through the USB port on the Arduino to the ESP8266 you must connect the RX pin on the Arduino to TX on the ESP8266 and the TX pin on the Arduino to RX on the ESP8266.

TX stands for Transmit and RX stands for Receive. So it makes sense that you should connect the transmit pin to the receive pin in the first case. But why connect transmit to transmit and receive to receive in the second case? The reason is that you are not communicating between the main microcontroller (ATmega328P on the Uno) and the ESP8266. You are communicating between the USB-serial chip on the Uno (usually ATmega16U4 on the official Arduinos or CH340 on the clones) and the ESP8266. The main microcontroller is not being used at all, you're just using the Arduino as a bulky and inconvenient USB-serial adapter.

In fact some people will go so far as to remove the ATmega328P from their DIP Unos for this purpose. The RX pin on the USB-serial chip is connected to the TX pin on the main microcontroller as well as the TX header pin and vice versa for TX pin on the USB-serial chip. This means by connecting the ESP8266's TX pin to the TX pin on the Uno's header you are actually connecting it to the RX pin on the USB-serial chip. I would highly recommend getting a USB-serial adapter made for this purpose rather than trying to use an Arduino. You can buy FTDI FT232 or CH340 breakout boards on eBay or Aliexpress for < $2 USD w/ free shipping.

  do I need any converters? Because now I directly connect the TX and RX to the Arduino's TX and RX

This is actually two questions. Let's address the easy one first. The TX pin of the ESP8266 is going to put out around 3 V. Even though the ATmega328P is running at 5 V this will still be seen as a high so no level conversion on that pin is necessary.

Now for the question of whether it's needed on the ~5 V level from the Arduino to the ESP8266 RX pin. There's a lot of disagreement on the question of whether the IO pins on the ESP8266 are 5 V tolerant. We certainly know that it's possible to connect the ESP8266 to 5 V levels as there are many projects published online that do this but the question is will this will shorten the life of the ESP8266?

The datasheet for the ESP8266 does not say the inputs are 5 V tolerant. There is a statement on the ESP8266 forum from a member of the Espressif (creator of the ESP8266) staff:
http://bbs.espressif.com/viewtopic.php?t=1145

  We donot recommend you to apply 5V to IO.

We have a comment from someone on Facebook named "Teo Swee Ann" who appears to be the CEO of Espressif:
 https://www.facebook.com/groups/1499045113679103/permalink/1731855033731442/?comment_id=1732364133680532

  i can reply officially here: it is 5V tolerant at the IO. while the supply voltage is at 3.3V.

So there is conflicting information and none of it has been presented in the most official manner, such as actually putting it in the datasheet. One thing we do know for sure, you will not harm the ESP8266 with 3.3 V levels. So the safest option is to avoid giving it 5 V inputs. However, as you are currently struggling just to get the most basic communication working the extra complication introduced by adding level shifting circuitry may not outweigh the possibility of reducing the life expectancy of your ESP8266.


Arduino Uno not working after Short-circuit

The regualator of that 5V Blew up or the diode you need to read the schemtics of the Arduino Uno and check the circuits.

https://www.arduino.cc/en/uploads/Main/arduino-uno-schematic.pdf


Accordly to Arduino Technical Specs:

-Input Voltage (recommended)    7-12V

-Input Voltage (limit)  6-20V

https://www.arduino.cc/en/main/arduinoBoardUno

Another Arduino thread:
https://forum.arduino.cc/index.php?topic=22676.0

I would say a better choice is to use another battery power supply just for Arduino. Is is easy to install, easier to handle and more verstile unless you really needs to use your motorcycle battery. And if you want or need to read your motorcycle battery just use a portable voltage meter plugged onto Arduino with no need to use your vehicle battery to power it.


You have declared count_pulse as a variable and NOT as function prototype.

int pin = 2;
volatile unsigned int pulse;
float volume = 0;
float flow_rate =0;
const int pulses_per_litre = 2000;

void count_pulse(); \\ <--- Function prototype

void setup()
{
    Serial.begin(9600);
    pinMode(pin, INPUT);
    attachInterrupt(0, count_pulse, RISING);
}


Calling functions from an array of pointers in a library causes 'undefined reference to' error

void (*caller[2])();

should be:

void (*Lib::caller[2])();

Since you are defining storage space for a static member variable you have to tell the compiler what class it's a static member of.


keep in mind that since you used

delay(100)

your 'loop' code runs in 10HZ (10 times a second)
So, every time you are lighting on your sensor, if its for longer than 1/10 of a second, you are likely going through several instances of 'loop', in which the condition

(val>700)

is satisfied.

If you know that your peaks are going to take several loops, and only want to count each peak once- a simple way would be to make sure you dropped from the previous peak before incrementing the counter. you can achieve that with something like:

int count=0;
int val;
int data;
bool inPeak = false;

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

void loop() {
  data=analogRead(A0);
  val=map(data,0,1023,1000,0);
  if(val>700) {
     if (!inPeak)
     {
        count ++;
        inPeak = true;
     }
  }
  else
  {
      inPeak = false;
  }

  Serial.println(count);
  delay(100);
}


What exactly does the Arduino preprocessor do?

It does four things, basically:

It adds #include <Arduino.h> to the top of your file, which gives you access to all the classes, functions and defined variables/macros of the API.
It joins together all the INO files together into a single monolithic file (in the same order as the tabs in the window),
It matches #include entries with libraries and adds the files in those libraries to the list of files to compile, and
It scans through the ino file(s) looking for functions and adds prototypes to them to the top of your file.

It's the latter that can cause problems. Historically it never got the prototypes in the right place, and if you ever passed a structure of your own devising to a function it would break horribly.  It does a better job these days, but it's still not 100% perfect.

It basically means that you don't have to adhere to the "You must define it before you use it" rule of C/C++.  Which of course makes for lazy programmers.


Do we have an alternative for millis() function?

You can use the SQW output of the module to indicate the passage of precisely 1 second. Every time it transitions from LOW to HIGH one second will have passed.

RTCs cannot give you times of higher resolution than 1 second, but they can give you that 1 second granularity to a high accuracy.


Your problem is that you are trying to measure motes of dust with a yard stick. The yard stick is great at measuring things in inches and feet, but when you want to find the size of something that's around 1mm in size all you can say is "it's less than an inch" or "smaller than an eighth of an inch".
You have to remember that a 20A sensor has to fit that whole range of 0-20A - that's 0-20,000mA into half the range of the ADC. That's at most 512 graduations on an Arduino, and since you can usually count on "±1 LSB quantisation noise" you really only get half that as a usable value. So you're looking at a resolution of about 40mA at best with an accuracy of  ±40mA. When you want to measure small currents they're just going to get lost in the lack of resolution. At 100mA you're still only in the range of just "There might be a current there, somewhere".
For measuring current you need to size your sensor / shunt appropriately to the range of the currents you're sensing. If you're working with small variations in a large DC current then pre-conditioning the sensing to change the offset and amplify the interesting part of the signal is required, so that the signal isn't swamped by the underlying offset. If you're working with small currents then you require a sensor / shunt that gives you an appropriate signal for that current range.
Additionally, different variants of the sensor have different sensitivity: 185 mV/A for the 5A model, and 100 mV/A for the 20A model. The code you are using doesn't take this in account. Using the correct sensitivity, the last value in your table, 683 mA, becomes 1,264 mA (683×185/100=1264). This is close enough, if you consider the ±40mA accuracy.


Assume you want the clock to start at 08:42:21, change

int seconds, minutes, hours;

to

int seconds = 21, minutes = 42, hours = 8;

Note that you should always also initialize (as in the second case above), and not only declare (as in the first case) all variables before you first read their values. Otherwise, for local variables you cannot be sure what their initial value is. (Global variables are implicitly initialized to zero if not explicitly initialized.)


Math with analog input values coming out wrong

Read this: Integer arithmetic and overflow.

float math = (5 + 6) / (4 + 5);
Serial.print("Math: ");
Serial.println(math);

The compiler is treating your expression (the RH side of the "=" sign) as integers. Thus it is working out:

11 / 9 = 1

Then you assign that 1 to a float. Too late to make it a float! It is already truncated.

Try:

float math = float (5 + 6) / float (4 + 5);
Serial.print("Math: ");
Serial.println(math, 4);  // 4 decimal places

You get:

Math: 1.2222

This also looks wrong:

while ( ( (frontleft + frontright) / (backleft + backright) <= 0.8 ) || ( (frontleft + frontright) / (backleft + backright) > 1.2) ) {
    if (backleft + backright > frontleft + frontright) {
      myStepper2.step(10);
    }
    if (backleft + backright < frontleft + frontright) {
      myStepper2.step(-10);
    }
    int backleft = analogRead(A0);
    int backright = analogRead(A1);
    int frontleft = analogRead(A2);
    int frontright = analogRead(A3);

How many backleft variables do you have? The one in the while instruction will not be the one you are doing the analogRead on. It doesn't "forward read" variables. I bet you have a different frontleft / backleft etc. set of variables declared earlier. These will not be updated inside the loop.

(To make them get updated drop the word int from inside the loop).


ArduCam ESP8266 and (Not-Mini) OV2640 Camera Module interface?

No, you can't "mix and match" like that. The 8-pin header has I2C and SPI on it for a "cooked" video interface. The 20-pin interface has the "raw" camera CSI interface.

The difference is, the mini version has its own small video processor and FIFO chip on it which processes and buffers the video image allowing you to take a picture then slowly stream that data back through to the slow Arduino at a speed it is comfortable with. The non-mini version doesn't have that and relies on the host controller board having enough power to process a live CSI video signal, which the Arduino cannot do.


Question: how to join two different codes

You need to write one program using elements from each block of code. There is no way the Arduino will run both programs concurrently, it will only run one or the other.  You can copy and paste them together but unless done correctly it will not work. This is why it is important to understand the code you are using.


Why does servo library conflict with irremote?

Usual problem is trying to use the same counter for both. For example arduino pins 6,7,8 are on TC4 and if you try to use IR on pin 6 and servo on 7 or 8, it won't work. You can't use pwms on these pins with servo either (it is possible to do it directly in registers, but in arduino framework it might get bad behavior)


Strange compiler error (Segmentation Fault)

This is a known fault with the compiler in Windows.  The annoying thing is that it's the version of the compiler that is included in the Windows Store App version of the Arduino IDE.

It also snuck into the Windows version of the IDE from version 1.8.6 from the Arduino.cc website, with the bundled version of the Arduino AVR core.

There are numerous Github issues open for the problem and navigating the tangled web of them is a bit of a chore, but this one seems to be the most promising for digging into the root cause:

AVR core 1.6.22 (IDE 1.8.6) crashes avr-gcc compiler (5.4.0) when F() string is assigned to a static variable

The simplest fix is to downgrade your compiler to 4.9.2.  This can be done by using the Boards Manager to install version 1.6.21 of the Arduino AVR Boards.  This should give you compiler version 4.9.2-atmel3.5.4-arduino2 which doesn't suffer from the problem.


I connected Lipo battery to device. On power outages it supply power to board and brown out problem solved. Thanks a lot


Good button debouncing/stateChange library

The Button library in the Arduino playground works perfectly.


ir sender detecting receiver and display

You can't.

IR is a one-way protocol. The transmitter has no way of knowing whether a receiver is in range; it's literally just an LED that emits infrared instead of visible light.


Reading serial buffer taking newline character instead of user input

if(data !='n')

This should be

if(data !='\n')

NEXT.

data=Serial.read();

only reads ONE character. You should add to a buffer, not assign a single character.


Is Arduino reliable for serious tasks, such as medical machines?

You should NOT trust using an Arduino for life safety measures (medical purposes).

This discusses the reliability of an Arduino pretty well- https://electronics.stackexchange.com/questions/15535/reliability-of-the-arduino-platform-for-industrial-use


Bluetooth OBD2 ELM327 connectivity issues

I managed to solve the issue. After some more testing, I ended up noticing that the problem was somehow the data exchange through the HC-05 bluetooth module. I changed it from being via SoftwareSerial library to the main serial com port and I had no issues since then. I don't know how that library may have caused the problem, but that was it.


I can't run shell commands on Linux through AVR sketch (Arduino Yun)

There's a few things wrong with your program, some more obvious than others.
First, you have to put each parameter to your shell command in a separate addParameter() call. Otherwise it treats all the parameters as a single parameter and tries to connect you to an address of 192.168.1.15 9911 instead of to port 9911 of address 192.168.1.15.
Secondly you should use runAsynchronously() instead of run() otherwise your sketch blocks at that point until nc terminates. If that never happens then your sketch never gets to the point where it can read the data.
Here is an adaption of your sketch that works for me:
#include <Process.h>

Process p;

void setup() {
    Bridge.begin();
    Console.begin();
    p.begin("nc");
    p.addParameter("192.168.1.15");
    p.addParameter("9911");
    p.runAsynchronously();
}

void loop() {
    static uint32_t ts = millis();

    if (millis() - ts > 1000) {
        Console.println(millis());
        ts = millis();
    }

    if (p.running()) {
        while (p.available()) {
            Console.write(p.read());
        }
    } else {
        Console.println("Restarting process");
        delay(100);
        p.begin("nc");
        p.addParameter("192.168.1.15");
        p.addParameter("9911");
        p.runAsynchronously();
    }
}

It also re-runs nc if / when it terminates. There's also a "heartbeat" printing of millis() so that you can see the sketch is running.  It uses the console, not Serial, for its output, so SSH in to the Yun and telnet localhost 6571 to view the output.


Actual baud rate of UNO R3 Firmata protocol

The baud rate is whatever the program opening the port requests it to be. The stuff in the device manager is only the default used if nothing else is specified when the port is opened.

And the Firmata protocol just squirts bytes over serial. It's based upon the MIDI protocol, which is just serial.


Converted Gerben's comment to an answer

That is not safe. Maximum voltage on the analog pins is 3.3v, according to the datasheet. But why don't you power it from 3.3v? Minimal voltage for that unit is 2.5v. And it uses only 2mA.


The Stack Exchange format is not well suited for opinions.  That said, people are apparently giving the kit good reviews.  And I see hardware that appears to allow for several projects (LED arrays?, motors?, ultrasonic-distance-measurement?, IR-remote-control?, Alpha-numeric-LCD?, 7-segmet-LED-display?, ect).  Which is more than you need for basic Arduino projects.

In general, it would make the most sense to find a kit with a book rather than obtain a book and a kit separately. This is because slight differences between the written material and independently obtained hardware will cause confusion.  This is generally not a problem for experienced embedded developers.

Keep in mind that embedded processor projects are half hardware and half software.  Since the hardware has already been collected, the majority of activity will be in software.  If this paradigm agrees with you, good luck & have fun.


What are the consequences of different clock speeds on different boards?

As was mentioned earlier about the DotStar LED strip/led

There is one thing missing in the calculation above. The End Frame shows as a 32 bit frame of all 1's. That is almost correct. The least obvious is that you need to add 1/2 of a bit for each led in the strip. This is due to the way that the clock is sent down the line. So the 180 led strip would require 90 bits in the End Frame. If you don't do this you will have some of the leds at the end that are not reacting correctly. I know this sounds strange, had me for a while (I use Raspberry Pi).

Also, I have seen where some have tested the SPI mode of sending the data down the line and managed to achieve about 16Mhz clock speeds. Great for POV display.

The DotStar don't require refreshment at all. Each LED has it's own PWM chip built in. They are more expensive than the Neopixel, so it depends on the application as to which is better for you. I loaded my string with colors and then disconnected the data lines (led strip on different power supply) and turned off my Pi. Yup, the DotStars stay as they are.

It has been said they are 'addressable' which is not truly accurate. When sending data, it is the first one, then the second and on. If you wanted, you can change only the first few. Odd hack. Just send the Start Frame (32 or more 0's) and start sending data to the first without affecting the rest of the strip. Note: you might have to account for the 1/2 bit clock loss. eg: 1 bit per 2 leds.

Here is a pretty good description of the DotStar functionality :
https://cpldcpu.com/2014/11/30/understanding-the-apa102-superled/

Here is a Youtube tutorial (2 short videos) that helped me quite a bit:
https://www.youtube.com/playlist?list=PLhXSL6B3uLd551fEQlQGd3LrhzvudKfJQ


Does the position in which you mount an IMU matter?

If the axes of measurement don't line up with the axes of motion, then comparing the IMU outputs to vehicle-relative (VR) coordinates will require some vector arithmetic to convert one to the other. It can be done, but requires some engineering time to code it and processor time to run.

It wasn't clear to me at a quick read whether your chosen IMU can do the coordinate translation itself, or your MCU has to do it. In either case, the computation will always reduce the accuracy of the original data, maybe a lot, maybe inconsequential, but expect some degradation.

Bottom line is: if you can line them up, things get simpler.


How to retrieve the data type of a variable?

In a typical C++ program, you would use the typeid operator, like this:

std::cout << typeid(myVar).name();

However, that requires a compiler feature called Runtime Type Information (RTTI). It's disabled in the Arduino IDE, presumably because it tends to increase the runtime memory requirements of the program.

You can get more information about the resource cost here: https://stackoverflow.com/questions/579887/how-expensive-is-rtti

Any fully-featured C++ compiler will definitely support RTTI though. If you want to try using a 3rd party IDE (such as Eclipse with the Arduino plugin) then you could easily enable it. It's probably not worth the hassle just for that though.

Alternative
A higher-performing (but less flexible) solution would be to use a traits class approach. This involves some funky template meta-programming:

// Generic catch-all implementation.
template <typename T_ty> struct TypeInfo { static const char * name; };
template <typename T_ty> const char * TypeInfo<T_ty>::name = "unknown";

// Handy macro to make querying stuff easier.
#define TYPE_NAME(var) TypeInfo< typeof(var) >::name

// Handy macro to make defining stuff easier.
#define MAKE_TYPE_INFO(type)  template <> const char * TypeInfo<type>::name = #type;

// Type-specific implementations.
MAKE_TYPE_INFO( int )
MAKE_TYPE_INFO( float )
MAKE_TYPE_INFO( short )

You can add MAKE_TYPE_INFO(..) lines for any type you want, including the names of custom classes. You could then use it like this:

int myVar = 17;
Serial.println( TYPE_NAME(myVar) );

Anything you don't define using MAKE_TYPE_INFO(..) will show up as "unknown".

That's some fairly advanced stuff in there, so I won't try to explain how it all works here. There are various tutorials on the web though about C++ template programming if you're interested.

EDIT: It's worth noting that the typeof operator isn't standard C++, but is supported by a few compilers, such as GCC. It's basically an older equivalent of decltype, which appears in the C++11 standard.


ssh root@[arduinoname].local

does the trick. Just replace [arduinoname] with your board's name: ssh root@myboard.local
Seems to take a minute or two to initialize, so if it doesn't work immediately don't give up right away!
This however won't allow you to access your internet, so I'll still have to connect to my router if I'm going to be downloading anything.


To get the value at a particular location, use this code:

boolean val = zero[y] & ((B1 << maxX) >> x);

where y is the y position from 0 to zero.length, maxX is the length of the binary constants minus one (in this case, it would be 6), and x is the x position from 0 to maxX.

For more information, see BitMask.