How to link a computer processor to an Arduinno on a board?

It sounds like you need a lot of compute power. You can either put the sensors and AI on one device (and @majenko's suggestion of a Raspberry Pi would be a direction to pursue) or you need two devices, one to manage the data collection - Arduino, perhaps -  and one to do the AI. We don't know enough about your post-processing and AI to make a good recommendation, but, as you already have a PC with Python running on it, an Arduino talking to the PC would be a good start.

You didn't say which Arduino you're considering, but as most people mean "Uno" when the speak of a generic Arduino, I'd just suggest that an Uno is far too under-resourced for the post-processing part of your project, but probably ideal for the data collection. Cross-compiling your Python code for an Uno still doesn't address its processing speed and memory size limitations.

There are, of course, a lot of "Arduino" products, some with considerably more resources, that may approach your needs - I'm thinking of the Arm-based boards, here - but I've no way of evaluating your project needs at that level.

My own first approach would be to use what you have, to start with: an Uno collecting data and sending it to your PC. Once you have something running, you'll understand the needs and issues better and if you still want a stand-alone solution at that point, you'll be much better able to make that choice.


How can I use IRsend with a string or convert a char from serial to uint32_t?

Instead of
irsend.sendNEC(buf, 32);

cast it to an unsigned int32 type:
irsend.sendNEC((uint32_t) buf, 32);


Having an issue accessing values from a pointer

As Majenko mentioned in the comment, you created new local arrays in the constructor, but never put anything in the member arrays of the classes. They have the same name, but are not the same variable. Responsible for creating the new variable is the keyword int. However, you cannot simply assign array values by just omitting the int. Therer are multiple possibilities:

You can fill the array for each index: durations_shaveAndAHairCut[0] = 1;
You can copy your local array to the member variable with memcpy: memcpy((void*)this->durations_shaveAndAHairCut, (void*)durations_shaveAndAHairCut, 9*sizeof(int));
You can declare the arrays static in the class declaration and initialize it outside of the constructor in MelodyPlayer.cpp:

int MelodyPlayer::durations_shaveAndAHairCut[] = {
    4, 8, 8, 4, 4, 4, 4, 4, 4};

I prefer the last option.


How to fix memory-leak code in ESP8266/NodeMCU caused by string concenation?

To write code that will not cause memory leak, you need to understand of where and what caused the memory leak first. The memory leak in this particular case is caused by the line
serial_data_read.concat(character);

When you instantiate a String object with String serial_data_read = "", Arduino String class create a memory allocation using dynamic memory allocation in the heap, and since your initialised it with "", it therefore create a minimum size of allocation. This is all good if you know how to the dynamic memory is created and how it going to be used.
The problem started when you start doing String concatenation with the line serial_data_read.concat(character), the original allocation for your global variable serial_data_read is no longer have enough space for the concatenated variable, so it create a temporary variable in the heap and do the concatenation, and then eventually put the result back to this newly allocated memory for serial_data_read on the heap, leaving a hole at the heap for the original serial_data_read variable (and the temp variable).
What make this worst is that this is happening for each iteration every 16 iterations(see Edgar Bonet's comment below) of the while loop. Theoretically the old serial_data_read prior the concatenation should be free-up at some point (e.g. if your while loop is within a function, the part of the heap might be free-up at the exit of the function), it however does not necessary be the case because your newly created serial_data_read stay on top of piles of to-be-free-up memory that blocking the free up(think of a piece of cheese with a lot of holes on it), so the heap memory get less and less at each iteration.
Short term fix - do not do String concatenation in a loop
String class is not always evil if you know what's going on and how to use it. One of the quick fix for your problem is simply do not do String concatenation within a loop. And if you are using it within a function, keep it local. This will minimise the heap fragmentation.
if ((last_weight_time < millis() - 1000)) {
   last_weight_time = millis();
   if (Serial.available() > 0) {
      String serial_data_read = Serial.readStringUntil('\n');
   }
}

BTW, you can add ESP.getFreeHeap() in your loop() to check if there is still memory leak.
Long term fix - Don't use String class
For a better fix, and especially for some one new to the programming or C/C++, do not use String class and learn how to use c string and array. Here is the version without using String class.
length = 80;
char buffer[length] = {0};
if ((last_weight_time < millis() - 1000)) {
   last_weight_time = millis();
   while(Serial.available()) {
      Serial.readBytesUntil('\n', buffer, length);
   }
}

Other resources to learn about
https://www.cplusplus.com/reference/cstring/ all the functions for c string and array manipulation to replace Arduino String class.
https://hackingmajenkoblog.wordpress.com/2016/02/04/the-evils-of-arduino-strings/


You are using pin 13, but you set pin 10 as an OUTPUT.

pinMode(10, OUTPUT);

Try changing that to

pinMode(pinOut, OUTPUT);

PS by not setting pin 13 to OUTPUT, digitalWrite(pinOut, HIGH); enables the internal pull-up, instead of "connecting" it to 5V. The internal resistors are around 35kOhm. So pulling a bit of current through them will result in a lower voltage at the pin.


Servo noise during program flash on Arduino

It would depend on which Arduino and what bootloader it's running.  Generally MCUs have their pins in INPUT mode when they reset.  Sometimes the bootloader will leave some pins configured for a particular mode by the some the sketch runs.  E.g. the Leonardo seems to leave pin 13 set to OUTPUT mode.
You usually want devices connected to your Arduino to have stable signals when the Arduino MCU is in reset, or in the bootloader, so it makes sense to pull the signal pins, that will later be output from the Arduino sketch, to known levels.  So maybe pulling your servo driver enable signal to inactive (HIGH) is appropriate.
Looking at the A4988, it has an EN (enable) pin, which seems to be active low.  So putting a high(ish) value resistor, say 5k or 10k, on it to VDD/HIGH (to inactive) is probably the thing to do.  When the Arduino is not driving the enable line to its low (active) state, that is when it's in the bootloader or being held in reset, the A4988 should stop its activity.


Voltage meter ADC + serial: Bytes lost during communication

With help in a comments I've managed to deal with the task myself.

First of all, as @Majenko pointed out, I was dealing with some multi-byte data. So I need some control character, that separates packets. I choose hex output with '\n' delimeter as control character - that served good. I was able to read 3.5 to 5k packets per second (with voltage reading) from serial on the host.

Second improvement, credited to @Jot, is to stack some sequential values right in arduino, before sending.

Alongside with increasing sampler frequency that could be very good.

#define cbi(sfr, bit) (_SFR_BYTE(sfr) &= ~_BV(bit))
#define sbi(sfr, bit) (_SFR_BYTE(sfr) |= _BV(bit))

void setup() {
  sbi(ADCSRA, ADPS2);
  cbi(ADCSRA, ADPS1);
  cbi(ADCSRA, ADPS0);
  Serial.begin(115200);
}

void loop() {
  int val = 0;
  for( int i = 0; i < 32; ++i )
    val += analogRead(A0);
  Serial.print(val, HEX);
  Serial.print("\n");
}

at the host recieve side, some simple conversion could be done:

#include "Serial.h"
#include <iostream>
#include <fstream>
#include <string>
#include <ctime>

// sample to voltage
double s2v(int sample) {
    return 5.0 * (static_cast<double>(sample) / 1024);
}

int main() {
    std::ofstream ofs("test.csv", std::ios::out | std::ios::ate);

    size_t comPort = 3;
    size_t baudRate = 115200; // 57600;

    CSerial serial;
    if (serial.Open(comPort, baudRate))
    {
        std::cout << "COM" << comPort << " opened @" << baudRate << "bit/s\n";

        // serial recv buffer
        size_t bufSize = 1048576;
        auto lpBuffer = new char[bufSize];

        // accumulator
        size_t nVals = 0;
        int nAcc = 0;

        // timer
        __time64_t destTime;
        __time64_t destTime2;
        _time64(&destTime);

        while (true) {
            SleepEx(10, false); // care of 100% cpu core usage, poll serial port lazily
            size_t nBytesRead = serial.ReadData(lpBuffer, bufSize * sizeof(lpBuffer[0]));

            //parse buffer:
            size_t cvtPtr = 0;
            for (size_t i = 0; i < nBytesRead; ++i) {
                if (lpBuffer[i] == '\n') {
                    try {
                        lpBuffer[i] = '\0';
                        auto val = std::stoi(lpBuffer + cvtPtr, nullptr, 16);
                        nAcc += val;
                        nVals++;
                    }
                    catch (...) {
                        // ignore, or warn that serial recieved junk/empty packet
                    }
                    cvtPtr = i + 1;
                }
            }

            //check if doom had come!
            _time64(&destTime2);
            if ((destTime2 - destTime) > 0) {
                auto fVoltage = ( s2v(nAcc) / 32 ) / nVals;
                std::cout << fVoltage << "\t(" << nVals << " ksps)\n";
                ofs << destTime << "," << fVoltage << "," << nVals << "\n";
                if((destTime % 30 ) == 0) // care of disk, write only once in 30 seconds
                    ofs.flush();
                destTime = destTime2;
                nVals = 0;
                nAcc = 0;
            }
        } // while
    } // if opened
    return 0;
}

That gives voltmeter with high precision, about ±0.5mV, that is updated every second.

Also! It was stated about 10bit adc, 5.0V/1024 = 4.88mV, but i got some subthreshold oscillations in vivo, adding samples up. So you are wrong, noise can be attenuated and resolution can be artificially pumbed up, in a trade for increased sampling time. Here is 14bit ADC built on top of 10bit ADC: . Its photovoltaic cell in a dark street, oscillations are caused by cars' front lights. Timescale is 1000 seconds per grid div


The width parameter to dtostrf() is the width of the resulting string NOT including the null terminator. So you are overflowing the array.

Change:

char clat[11];
char clng[11];

to

char clat[12];
char clng[12];

and it should work.


Open video file if sensor reaches certain threshold value

What I'm thinking is that you could make a conditional statement. Below is a little a bit of pseudo code on how to possibly open said video from an SD card because there's no way Arduino would be able to store a video on it's own, let alone play good quality videos:

int dangerLevel = 500 (or however the shield reads the smoke level)

int smokeDetectorPin = A0

setup:

smokeDetected = analogRead(smokeDetectorPin)

loop:

if smokeDetected >= dangerLevel:

open video from SD card directory or computer.

So in order to get a "video" from the SD card, you should check this website. Like I mentioned before, this is really primitive and it's probably not what you're looking for.

I found something very interest about the Arduino that I never knew you could do before and using composite display from a TV. Interesting and you can find that info here.

And lastly, to get a video from your computer or laptop, there's really no easy way. However, I did find two solutions that might be able to do this. First of all, and this may sound ironic since we're on an Arduino Stackexchange, you could use a Raspberry Pi (and this is the easily solution I can think of) though I believe your instructor prefers if you use the Arduino instead. Second, and this took me forever to find on the internet, you could use a third party software called "Gobetwino" and you can check out what that does here. I saw on YouTube video of a quick little demonstration of what it does. When the button is pressed, the video is played. That's conditional and you can do the same thing but for the smoke detector.


Send RF 433MHz data to Domoticz RfxCom with protocol X10 from Arduino Nano

I finally found a documentation about RF X10 protocol:
X10 RF Receiver.pdf

With following Hardware :

Arduino Pro Mini 5V         (4€)        https://www.amazon.fr/gp/product/B00QPUEFNW/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
RF 433MHz emitter/receiver  (3€) (Note: only the emitter is used)       https://www.amazon.fr/HDigiWorld-metteur-cepteur-commande-Arduino/dp/B00JTQI39G/ref=sr_1_3?s=computers&ie=UTF8&qid=1470813610&sr=1-3&keywords=433
3 wires : VCC, GND, Signal (on Arduino pin 2)

I've created the following working code for Arduino Nano :

/*
* Custom sensor (base code)
*
* Emission in RF 433MHz with the X10 protocol for Domoticz
*
* Hardware :
*   Arduino Pro Mini 5V         (4€)        https://www.amazon.fr/gp/product/B00QPUEFNW/ref=oh_aui_search_detailpage?ie=UTF8&psc=1
*   RF 433MHz emitter/receiver  (3€)        https://www.amazon.fr/HDigiWorld-metteur-cepteur-commande-Arduino/dp/B00JTQI39G/ref=sr_1_3?s=computers&ie=UTF8&qid=1470813610&sr=1-3&keywords=433
*       Note: only the emitter is used
*   3 wires : VCC, GND, Signal (on Arduino pin 2)
*
* Documentation found for RF X10: http://www.printcapture.com/files/X10_RF_Receiver.pdf
*
* Example of malformed data received in RfxMngr in mode "nodec" (before this code was correctly debugged) :
*
*       Packettype        = UNDECODED RF Message
*       UNDECODED NEC:1C515C86F0
*
*
* Correct data that is now receveived by RfxMngr with this program :
*
*------------------------------------------------
*       Packettype    = Lighting1
*       subtype       = X10
*       Sequence nbr  = 13
*       housecode     = D
*       unitcode      = 1
*       Command       = On
*       Signal level  = 7  -64dBm
*------------------------------------------------
*       Packettype    = Lighting1
*       subtype       = X10
*       Sequence nbr  = 14
*       housecode     = D
*       unitcode      = 1
*       Command       = Off
*       Signal level  = 7  -64dBm
*------------------------------------------------
*/

const int pin_emit = 2;         // Signal pin for RF433 emitter
const int pin_led = 13;         // Internal LED : it will be ON when the "On" command is sent in RF, and OFF the the "Off" command is sent (changed each 60s)

const unsigned int X10_A1_ON = 0x00;
const unsigned int X10_A1_OFF = 0x20;

const unsigned int X10_address = 5;     // this is Housecode. In my case 5 results in "D" house code
unsigned int X10_data = X10_A1_ON;      // command. I have implemented only On/Off for unit code 1

void setup() {
  pinMode(pin_led, OUTPUT);
  pinMode(pin_emit, OUTPUT);
  digitalWrite(pin_emit, LOW);
}

/**
* Bit to 0 : 1.125ms between rising edges, so before next bit
*/
void X10_sendBit_zero()
{
  digitalWrite(pin_emit, HIGH);
  delayMicroseconds(555);       // Arbitrary value: I took around 1.125ms divided by two for the "VCC" state.
  digitalWrite(pin_emit, LOW);
  delayMicroseconds(570);       // Total 555+570 : 1125µs = 1.125ms
}

/**
* Bit à 1 : 2.25ms entre les "rising edges"
*/
void X10_sendBit_one()
{
  digitalWrite(pin_emit, HIGH);
  delayMicroseconds(555);       // Arbitrary value: I took around 1.125ms divided by two for the "VCC" state.
  digitalWrite(pin_emit, LOW);
  delayMicroseconds(1695);      // Total 555+1695 : 2250µs = 2.250ms
}

void X10_send8bits(unsigned int data)
{
  // - Send the 8 bits, and then the complementary of the 8 bits.
  // from documentation: "Within each byte, bit7 is received first and bit0 last"
  int mask = 0x80;
  for(int i = 0; i < 8; i++)
  {
    int bit = mask & data;
    if (bit == 0)
      X10_sendBit_zero();
    else
      X10_sendBit_one();

    mask = mask >> 1;
  }
}

/**
* Sending a byte consists of sending this byte, and then sending the opposite of the same byte.
* As we send the opposite as well as the data, the total duration is always the same : 8 * (1.125ms+2.250ms) = 8 * 3.375 = total of 27ms
*/
void X10_sendByte(unsigned int data)
{
  X10_send8bits(data);
  X10_send8bits(~data);
}

/**
* Send a complete X10 packet
*
* Total duration :
* (9ms + 4.5ms) + (27ms + 27ms) + 0.555ms + 40ms = 108.055 ms
*  from doc: "It appears, from articles on the 'net, that other people have seen a range from 95 msec to 116 msec for various transmitters and that standard X-10 transceivers can tolerate timing variations of 30-35% from nominal."
*/
void X10_sendState_once(unsigned int data)
{

  // - Header
  digitalWrite(pin_emit, HIGH); // "Burst" de 9ms
  delayMicroseconds(9000);
  digitalWrite(pin_emit, LOW); // Silence de 4.5ms
  delayMicroseconds(4500);

  // - Data
  X10_sendByte(0x50); // - Address
  X10_sendByte(data); // - Data

  // - Send a last rising edge to validate last bit
  digitalWrite(pin_emit, HIGH);
  delayMicroseconds(555);       // Arbitraty value (but always the same), for "VCC" state.

  // - Footer
  digitalWrite(pin_emit, LOW); // Silence de 40ms pour signifier la fin de l'émission
  delayMicroseconds(40000);

}

/**
* Send a complete packet multiple times (this X10 protocol has not ACK))
* From doc: "Most X-10 RF transmitters send a minimum of five copies of the code separated by 40 msec silences although some can send single bursts."
*
*  5 times 108.055ms = 540.275 ms, half a second
*/
void X10_sendState(unsigned int data)
{
  // - "clean" to be sure to have a zero for the first rising edge on init
  digitalWrite(pin_emit, LOW);
  delay(1);

  // - Send 5 time complete packet
  for(int repeat=0 ; repeat<5 ; repeat++)
    X10_sendState_once(data);

}

void loop() {

  if(X10_data == X10_A1_ON)
    digitalWrite(pin_led, HIGH);
  else
    digitalWrite(pin_led, LOW);
  X10_sendState(X10_data);
  delay(60000);              // 1 minute

  // - I change state each 60 seconds to see changes in Domoticz
  if(X10_data == X10_A1_ON)
    X10_data = X10_A1_OFF;
  else
    X10_data = X10_A1_ON;
}

By changing House code and data, it is now possible to create our own RF sensors.


expected unqualified-id before '.' token

You declare an object of type DHT and name dht. Then you try to call a method of DHT.read11().

Instead, you should be using the object name, dht.read11(), or as @Gerben points out, change the way you declare the object:  DHT dht;.


I think I understand what's going on from here. That's why speed_value appears to change sign suddenly when entering the if...else... statement. But why speed_value == -speed_value is necessary is yet to be answered.


Arduino Mega 2560 not showing up in Serial Port in IDE

Did you try:-

Unplugging and reconnecting the board?

or

Holding down the reset button (on the board) during compile and then letting go when the Ide says "Uploading to ..."? (Make sure the sketch has a setup(){} and loop(){} so is not entirely empty)

If that doesn't work then ...

The pin13 on all the time with an empty sketch might indicate a hardware problem. Is anything connected to the board apart from the usb cable? Green LED simply means the board has power unless you are talking about the tx/rx Led's?

for windows users ...

Look in "Control Panel>Device Manager" to see if there is an exclamation mark against any devices, or "Unknown/Other" devices? If you can see the board but it has an error against it look at the properties to see if you can see what the error is. Re-installing the arduino ide will attempt to install the usb drivers again but they can also be found in the \drivers sub folder below the Arduino Ide.
If you can see an entry in control panel but it is not showing in the Arduino Ide try changing the port to a different COM number (right click>properties)
If you can't see anything in Control Panel try a different usb port on your computer.
Is the board connected directly to the pc via usb or via a usb hub? Make sure direct connect. If power externally make sure enough power.


pushing accelerometer data in packets from an arduino due to the pc and unto processing

It's pretty simple to store the x, y and z co-ordinates in three separate arrays. Instead of storing them in single int variables you can just store them in int arrays. You can make three arrays that are of size 1000 a store the raw values there. In order to iterate through the arrays within loop() you can set up i at global scope and include an if statement that will know when the arrays are filled, for example if (i == 1000) and within this if statement you can set up a for loop that will iterate through the arrays and print their values and after reset i to 0 and then reset the buffer arrays i.e. fill them with zeroes. This last step is not needed since they will be overwritten anyway but it is good to have so you don't accidentally use old values.

Also the for loop that will print the values will take 8 minutes with that delay(500); You can make this delay smaller or print the value before each if statement as the data comes in.

#include <AcceleroMMA7361.h>

AcceleroMMA7361 accelero;
int xAxisBuffer [1000] = {0};
int yAxisBuffer [1000] = {0};
int zAxisBuffer [1000] = {0};

int i = 0;

void setup(){
    Serial.begin(9600);
    accelero.begin(13, 12, 11, 10, A0, A1, A2);
    accelero.setARefVoltage(3.3);     //sets the AREF voltage   to 3.3V
    accelero.setSensitivity(LOW);           //sets the sensitivity to +/-6G
    accelero.calibrate();
}

void loop(){
    // This stores the x, y and z values in their
    // respective arrays
    xAxisBuffer[i] = accelero.getXRaw();
    yAxisBuffer[i] = accelero.getYRaw();
    zAxisBuffer[i] = accelero.getZRaw();
    ++i; // moves to the next position

    if (i == 1000){ // the arrays are full
        // prints the (x, y, z) values
        // because the delay is .5 seconds it will
        // take about 8 minutes to print all 1000
        for (int j = 0; j < 1000; j++){
            Serial.print("\nx: ");
            Serial.print(xAxisBuffer[j]);
            Serial.print("\ty: ");
            Serial.print(yAxisBuffer[j]);
            Serial.print("\tz: ");
            Serial.print(zAxisBuffer[j]);
            delay(500); //(make it readable)
        }
        // restart at beginning of the arrays
        i = 0;
        // reset the arrays
        memset(xAxisBuffer,0,sizeof(xAxisBuffer));
        memset(yAxisBuffer,0,sizeof(yAxisBuffer));
        memset(zAxisBuffer,0,sizeof(zAxisBuffer));
    }
}


Thanks to comments I received from several people here I quadruple checked the wiring and eventualy found the problem. My recent Arduino Uno tests were done on a breadboard, but I had the Pro Mini prototype soldered on the prototyping board which has the holes connected in columns on the copper side. I made the cuts in all the necessary places ... but one! That one omission caused a short between pin 6 and the drain from the other channel's mosfet. The problem with these boards is that the parts are on one side and while flipping the board to the copper side, it is too easy to get lost in all the columns and miss something.
The morales of this story are: "Never be too certain about your wiring/soldering" and "Arduino is pretty resistent to my attempts to fry it :)".


Adafruit Circuit Playground Express interrupt not working

Pin 4 on Zero can't be used with attachInterrupt. It is pin PA08 of the SAMD21 and this has NMI as interrupt control function in EIC and can't be used as EXTINT.

Adafruit Circuit Playground maps PA28 to pin 4, but the description of the pin is left as for Zero and doesn't declare interrupt capability.

In file arduino/hardware/samd/1.6.21/variants/circuitplay/variant.cpp change the line for pin 4 to

  { PORTA, 28, PIO_DIGITAL, (PIN_ATTR_DIGITAL), No_ADC_Channel, NOT_ON_PWM, NOT_ON_TIMER, EXTERNAL_INT_8  },                           // GPIO D4 / Left Button

Packages are located in ~/.arduino15/packages/ on Linux and %userprofile%\AppData\Local\Arduino15\packages\ on Windows (AppData is a hidden folder).

Warning: In variant.cpp the overview comment's table describes Zero, not Circuit Playground.

Note: It is not beneficial to read a button with interrupt. You can only set some flag in interrupt and then handle it in the loop(). But then you can directlly check in loop the state of the pin, because it will be active many loops even if the user pushes it for a short time.


You don't really need your regulator. That board has a connection (X1) intended for directly connecting two AA batteries (according to the schematic).

However, if you want to keep it regulated at 3.3V for other reasons (the MCU will happily run from as low as about 1.62V) then sure - use your regulator.  But just treat it like batteries regardless. Connect the output of your 3.3V regulator to the battery connector, which goes via the power switching and control circuitry to the 3.3V rail of the board.


How to connect to pins when using I2C LCD shield?

What it means is although all pins from the Arduino are connected only A4, A5 5V and Gnd are actually used by the shield.  I think that these 4 pins are shared with other shields and all the rest of the pins are available for shields to either share or use exclusively.

So, if you have this shield and an Ethernet shield, which needs exclusive access to pins d7, d8 and d9 then you would be to use both shields at the same time.


Controlling 5V PWM Fan with Potentiometer

According to Your Fan Datasheet its 1.3 W/5V Fan...
That means its nearly consume 3 A current which cant be supplied directly from arduino pins...
so you have to use PWM converter ...
it almost solve your issues...


How to process this XBee analog pins signal?

Sounds like your pots are not connected correctly and you pick up noise. The waveform you are seeing could be from the mains, or another source. Stray magnetic fields from transformers etc. can couple and be picked up by your circuit and you will notice them if your input is of high impedance. The atmosphere is also full of electromagnetic radiation from human sources and from space, that you can also pick up. The longer wires that are connected to your high impedance input, the more noise you will pick up.

Your pots should be wired 1.2V-AIN-GND, with the 1.2V source being low impedance, coming from a power supply/regulator and not eg. a voltage divider. If your potentiometer is high impedance (say 100 kOhm), and it is connected with wires from eg. a breadboard, you might want to add a decoupling capacitor between AIN and GND. 0.1 uF would be a typical value. It will short out AC waveforms(noise) to ground.


LiquidCrystal library and timers don't seem to be compatible

Dang, it was a bit of a noobish error. I had the interrupt handler setup for the overflow interrupt, but when I swapped the code in for the Compare Match interrupt I didn't make a handler for it. So since there's an interrupt without a handler it seems it just resets, hence the flashy-flashy garbage I was seeing on the LCD.

Adding this fixed the problem:

ISR(TIMER1_COMPA_vect)
{
  j++;
}


Instead of a multiplexer you can use a "shift register"; the difference is that it keep the last state of the pin, while the multiplexer goes unconnected (and this is because you need at least 30fps, and even so you'll get low light as you are PWMing the leds).
This is why shift register are also called "led driver".

Official tutorial can be found here http://arduino.cc/en/Tutorial/LEDDriver


Serial.write() is meant for sending binary data. So if you want to send a string with it, you need to provide a c-string, not the Arduino implementation of the String class. That's done easily with a member function of that class:
Serial.write(strrpm.c_str());

That compiles successfully for me.
Though you should not do it like this. The String class is generally bad on small microcontrollers, especially on the AVR microcontrollers with little memory (like Uno, Nano, Mega, ...), because it causes memory fragmentation (see Majenkos "The Evils of Arduino Strings").
Instead you should just use the corresponding print() functions of the Serial class. They are made for sending human readable strings. No need to first build up a String object. Just do
Serial.println(rpm);

And it will do the string conversion itself without using the String class.

Besides that I have some notes on your code:

The way you use millis() is a bit weird. There is no need to actually reset the millis() value itself. Normally you would hold a timestamp in a variable and then only calculate the difference between millis() and the timestamp. That is also overflow safe. Like this
  unsigned long timestamp = 0;

  ...
  if(millis()-timestamp >= 1000){
      ...
      timestamp+=1000;
  }

That doesn't use an extern variable, it is not resetting the millis() counter (which might mess with other things too, that rely on it) and is somewhat the standard way to do it.

You are using an atomic section for resetting the millis() counter, but not for accessing pulsecount. That is actually the place, where you absolutely need this. pulsecount is of type long, so it will need many instructions to do the calculation for revs. The your interrupt service routine can easily mess with the data in that moment, resulting in garbled data. Move  the calculation into the if statement and use an atomic section like with the millis() counter to read it into a local variable then you can do the calculations. That will keep the time, where interrupts are turned off very short. You can also - instead of turning all interrupts off - just detach the pin interrupt for that time, so that other things are not affected. Like this code:
  void loop(){
      if(millis()-timestamp > 1000){
           // deactivate our pin interrupt, so it cannot mess with the data
           detachInterrupt(digitalPinToInterrupt(encpin));
           // copy pulsecount to local variable for further calculation
           long local_pulsecount = pulsecount;
           // reactivate our pin interrupt
           attachInterrupt(digitalPinToInterrupt(encpin),function,RISING);
           // Do calculation and print the value
           ...
           timestamp += 1000;
       }
   }


Can you drive a stepper motor without the L293D

Depending on the type of stepper motor the answer can be "Yes" or "No".

There are two types of stepper motor: Unipolar and Bipolar.  Bipolar motors typically have 4 wires and require a H-bridge to drive them.

The L239D is a popular (and cheap), though inefficient, H-bridge that is commonly used. But it is possible to build your own H-bridge from discrete components. There are a lot of caveats and pitfalls when building your own H-bridge though, so people generally don't unless they have a specific requirement that isn't addressed by an integrated one. There are plenty of schematics and descriptions of operation online if you want to learn more about H-bridges.

There are also dedicated bipolar stepper drivers which are easier to work with: you just set the direction and give it a pulse to step in that direction. Much easier to program with, but can be more expensive. However these do tend to be more modern MOSFET based components which are far more efficient and dissipate less heat (or can handle more powerful motors in a similar size package).

Unipolar stepper motors, on the other hand, have more wires (typically 6) and are much simpler to drive. All you need for these is a transistor per coil (typically 4 coils connected as pairs) and you just need to activate them in the right sequence.

The ULN2003 is a popular integrated chip for driving unipolar stepper motors. It's just a bunch of transistors in a single package that is easier to wire up than discrete transistors, though there is no reason why you couldn't do it just with 4 discrete transistors. It's just simpler and tidier to use a single chip.

There are plenty of demonstrations and tutorials online describing driving a unipolar stepper motor with the ULN2003.


Uploading new sketch to Leonardo-type boards when you've changed the HID mode

From Sparkfun's page Pro Micro Hook-upGuide

When a Pro Micro is externally reset (by pulling the RST pin low), it’ll only briefly (<750ms) start the bootloader before continuing on to the sketch. If you need the bootloader to run longer, resetting twice quickly will get the Pro Micro to enter bootloader mode for eight seconds.

Hope that helps! If not there are some other procedures you might want to look into.


Here's the guide I used to correct the problem :-

HOW TO FIX THE USB-FTDI PROBLEM

(on arduino nano, usb ttl, ft232, ...)

There must have been a production of faulty ftdi drivers (version 2.12.0.0 or later) on august 2014 that makes some arduino boards and other usb devices not readable from the computer. The problem is random, meaning that it is possible to program the arduino a couple of times and then it comes out the ftdi problem, at that point the board isn't accessible anymore.

Once you come up with this problem, upgrading/downgrading the drivers, the IDE or the bootloader is just a waste of time, as the ftdi driver installed leaves some wrong data. This guide followed step by step will completely fix the driver problem thus making your board working again.

Step 1: check if you have a faulty ftdi chip driver

Not every ftdi chip has faulty drivers, so the first step is to check the chip's driver version. In order to check the version you need a software like usbview or usbdeview (both freeware and don't need any installation). Run the software and look for the "USB serial converter" device which is the one related to the ftdi driver, then read the vendor-id and the Product-id whose values should be 0x0403 for the vendor and 0x6001 for the product. The goal is to modify that 0x6001 value with 0x0000, and to do that we need some other software.

Step 2: modify values

Unplug your arduino nano or usb device. In order to modify the driver values you need CDMUninstaller (no installation needed). Fill the vendor and product fields with the values found with usbview (0403 and 6001) and click 'add', finally click 'remove devices'.

Step 3: download the 2.10.0.0 ftdi driver

Go to the ftdi website and download the 2.10.0.0 virtual driver choosing between 32 or 64 bit version, voiding the 'setup executable' file: just download the folder. After downloading the folder, we have to overwrite some files inside of it. Click FTDI.rar to download the files already modified, and place them inside the 2.10.0.0 folder overwriting the old ones.

Step 4: connect your arduino board

connect your arduino board, and stop windows from looking for new drivers. Go to device manager and look for FT232 USB device, then right click on it, select Properties and click on update drivers. Manually select the place in which scan for the new drivers and choose the 2.10.0.0 driver folder with the modified files. Now windows will prompt you saying that it can't certificate the new drivers. Ignore the alert and proceed with the installation. Once installation has finished, windows should recognize the connected board as 'USB recuperacion'.

Close the window and go to device manager, and look for the COM ports device. The connected device is now showing up like USB recuperation by ElectroHobby.es

Step 5: modify the chip eeprom

This is the last step and you need to restore the initial vendor and product values inside the ftdi chip eeprom. In order to do that you need to download and install Ftprog, click on the magnifing glass icon, select 'USB device descriptor' and again select 'custom pid'. Finally click on 'ftdi default'.

A new window shows up and you just need to check flag the device list and then click on 'program'.


Is there a cheap relay that can control voltage from stuff like bulb lights with a 5 V control output?

You can use a 5V Solid-State Relay module to control light bulbs. They cost $4-6 from US-based suppliers and $1-3 from a Chinese supplier. Just hook up the supply to the center pin and the load to either the NO or NC pin. Supply 5V to the module and wire a digital pin to the module to control it.


No Data Received on Serial Port & Unable to DFU Reset. Advice?

Step Zero - check that the port selected works.

Step Next -  if you still get the error, try the DFU reset options and follow the steps outlined in the link below.

https://learn.adafruit.com/bluefruit-nrf52-feather-learning-guide/using-the-bootloader


How to use code for OV7670 on Arduino Uno

I am ComputerNerd. I read this post and realized the real problem and why I am having difficulty helping you. You are asking the wrong question. What you should be asking is "how do I compile it using GNU Make and Avr-Gcc on Windows?". Instead you are asking "how can I use this code in the Arduino IDE?".

The answer to what you should be asking is simple. Use what you already have. The Arduino IDE ships with Avr-gcc and (maybe) GNU Make. Just run the programs directly. Better yet download MinGW and compile GCC to target the AVR yourself.


"function" was not declared in this scope (called in setup)

The function name you're calling is calcOppervlakte but the function name in the definition is calcOpppervlakte. If you look closely you'll see there is an extra p in the function definition. If you change the names to match the error will be resolved.


Will a 12 VDC 1A Power Supply Adapter supply too much power and damage an Arduino Mega 2560?

No. You have everything wrong there.

First off, a power supply does not provide power. It provides voltage. The device attached to it then draws current. As much current as it needs at any particular moment in time.  The current rating of a power supply is the maximum that the power supply can give.

The same goes for Arduino IO and power pins: The current ratings are the maximum current you can draw from the pin.

Exactly what current it will draw from the power supply depends completely on what is connected to what pins, and even what calculations the Arduino is doing at the time.  To get a ball-park figure of current requirements you need to know the current requirements of whatever is attached. If a device has its own power input that is the current you need to worry about. If a device is powered directly from an IO pin (such as an LED) then that forms part of the Arduino's current (which starts at about 40mA or so for the board itself).

There are many other factors to take into consideration:

The 5V regulator on the Arduino can't give more than 1A maximum, and considerably less than that when powered from a high voltage like 12V.
The DC jack on the Arduino is limited to 1A due to a polarity protection diode.

It is usually recommended to use a separate 3.3V regulator for an ESP8266 module (or 5V if your module has a built-in 3.3V regulator) due to the lack of power capacity in the Arduino's on-board regulators.

As a rough guestimate:

Arduino: 40-60mA
ESP8266: 200mA (when transmitting)
PIR: Negligible
Relay: 50mA when active

So you'd be looking at 300mA as a minimum. More is better. 1A should be more than sufficient. 2A would be overkill but give a big margin of error.

For everything you have there, it would be better to use a 5V power supply, not a 12V power supply.


Detecting ball moving between IR pair and handling ambient light changes

this is the same problem that IR remote/television has; how can TV they tell if that high voltage is a direct light or a logic 1 sent by remote? Simply because remote does not send a "HIGH" signal, but a modulated one, tipically at 36KHz. This mean a logic "HIGH" is a train of "HIGH-LOW" at 36KHz (you can see it as PWM at 50%duty cicle and 36KHz frequency)

Ambient light des not have fast variation, and inside light are at 50-60Hz, so they will be "filtered" out.

So, until you see high voltage change at 36KHz, you have your beam fine, if it is not the case, then look at voltage: if fixed at normally low voltage, beam is broken; is fixed at normally high voltage then some light stronger than your emitter is "blinding" the sensor.

note that because 36KHz is a very use frequency on Remote, there a a lot of chip that will emit or read a modulated IR, but expose a normal digital input/output, but still can be done by software, expecially if hardware assistet (like PWM for output), interrupt for input


Motor driver not able to drive motor in reverse direction

The motor driver's GND does need to be connected to the Arduino's GND so that the signal loop is complete. This won't break the Arduino.


My Code turns on my LED even when my switch is not pressed

I think your problem might be connected to wiring.

This is one of the ways you can correctly connect a switch to Pin 8.

In this case you need to configure Pin 8 as INPUT_PULLUP to use internal "pullup" resistor. When switch is not pressed Pin8 is connected to 5V through that resistor and value on the pin is HIGH. When you press the switch it connects Pin 8 to ground (the resistor prevents a short) and that way value on Pin 8 is LOW.

This is code that works correctly with the design above

void setup()
{
  pinMode(8, INPUT_PULLUP);
  Serial.begin(9600);
}

void loop()
{
  if (digitalRead(8) == HIGH)
  {
    Serial.println("It's HIGH");
  }
  else
  {
    Serial.println("It's LOW");
  }

  delay(1000);
}

If you do not configure Pin 8 as INPUT_PULLUP but just normal INPUT (as you did in your code) when the button is not pressed Pin 8 is "floating" (it's not connected to anything) and on a "floating" pin values are random.


Connecting LEDs and push buttons 12 feet away from Arduino UNO

That is a big no-no. You are adding extremely long antennas to the Arduino asking for problems. At a minimum on the inputs add a 10K series resistor at the Arduino pins.  My preference would be to put the capacitors at the arduino pins to help decouple noise etc as well as the pull up resistors on the wire side of the 10K resistors. Use a buffer of some type for the LEDs, a transistor would work. This may work but for how long and how many processors can you destroy over time.


AtTiny85 and MMA8452Q accelerometer cannot connect using i2c

On an ATtiny85 pin 5 (PB0) is SDA and pin 7 (PB2) is SCL for the I2C interface.  You're using the wrong pin for SCL.

Additionally, your pull-up resistors are too strong.  Somewhere between 4.7K Ohm and 10K Ohm are recommended for pull-up's on the SDA and SCL lines.


changing bitrate of audio recording and taking samples from audio in arduino

First of all, I am pretty sure your idea of using discrete ADC samples
as predictors for your model is hopelessly naive. As explained by
Majenko, you cannot expect anything meaningful from a sound recording
taken at 20 samples per second. You may have more luck using
spectral intensities as predictors. I suggest you start by doing some
time–frequency analysis on your training data, just to get some ideas on
what predictors may be worth trying. In any case, I strongly suggest you
train and test your model on your computer, before committing any
code to the Arduino.
That being said, sampling a signal at 20 Hz is quite easy: wait for
50 ms (or 50,000 µs for better accuracy), take one sample,
repeat. The only caveat is that you have to use millis() or micros()
rather than delay() or delayMicroseconds(), otherwise the sampling
period will be longer than expected because of the time needed to
execute the code.
Applying the sigmoid function just to compare the result to 0.5 makes
little sense. You know the sigmoid is larger than 0.5 only when its
argument is positive, so you can trivially save yourself expensive
floating point operations.
Here is a tentative implementation of (my understanding of) the idea you
suggest:
const uint8_t mic_pin = A0;
const size_t sample_count = 100;
const uint32_t sample_period = 50000;  // 50,000 us = 50 ms
const int weights[sample_count] = { 12, -42, 23 /* etc... */};

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

void loop() {
    // Record the samples.
    int samples[sample_count];
    uint32_t last_sample = micros();
    for (size_t i = 0; i < sample_count; i++) {
        while (micros() - last_sample < sample_period) { /* wait */ }
        samples[i] = analogRead(mic_pin);
        last_sample += sample_period;
    }

    // Compute the weighted sum.
    long sum = 0;
    for (size_t i = 0; i < sample_count; i++) {
        sum += (long) samples[i] * weights[i];
    }

    // Predict.
    if (sum >= 0) {
        Serial.println("The baby is crying!");
    }
}


How to read serial data without any blocking using ESP8266

First, I think the protocol is slightly different probably. The first byte is 71. The next byte seems to be the number of bytes that follow (C8 hex is 200). The last byte is the checksum.

So you need to check for 71, when that is received you can read the next byte (number of bytes), the data, and the checksum.

So the code should be something like:

void readSerial()
{
   if (Serial.available() > 0)
   {
      uint8_t readByte = Serial.read(); // uint8_t = 8 bit unsigned integer
      if (readByte == 71)
      {
         // Read message
         data_length = Serial.read();
         data_length = Serial.readBytes(data, data_length);
         checksum = Serial.read();
         // Check checksum
      }
      else
      {
         data_length = 0;
      }
   }
}

(note: code is untested)

About blocking prevention, you will have to read them one by one and doing other tasks meanwhile.

Update

Assuming reading starts while sender is already sending possibly, and assuming a message always starts with 71 C8.

Create an enumeration that shows how many 'start bytes' have passed (71 C8 are start bytes).

enum EStartByte
{
   WaitForMessage,
   FirstStartBytePassed,
   ReadMessage
};

enum EStartByte startByte = WaitForMessage;

void readSerial()
{
   while (Serial.available())
   {
      switch (startByte)
      {
      case WaitForMessage:
          // Expect first start byte
          if (Serial.readByte() == 0x71)
          {
               startByte = FirstStartBytePassed;
          }
          break;

      case FirstStartBytePassed:
          // Expect second start byte
          if (Serial.readByte() == 0xC8)
          {
               startByte = ReadMessage; // Start reading
          }
          else
          {
               startByte = WaitForMessage;
          }
          break;

      case ReadMessage:
          // Read data
          data_length = Serial.readBytes(data, 200);
          checksum = Serial.read();
          // Check checksum

          startByte = WaitForMessage; // Start over
          break;
      }
   }
}


PT2257 only gives me heavy buzzing sound

many amps and BT audio chips use differential input/outputs. none of the inputs nor outputs are considered grounds.
the Lp(left,postivie) Ln, Rp and Rn on your audio chip should be connected to loads directly. Ln or Rn are not audio grounds. so you can't use simple POT volume controls or any processor or amplifier chip that doesn't support differential IOs. so, you can't use PT2257 in this circuit.
for better understanding here are two audio signal types:

the simple, well known one, which consists of GND and an audio IN per channel. you can use many amplifiers, processors (e.h. PT2257) and POT volume controls. and one end of the output (e.g. speaker) is connected to GND.
the differntial audio signal which consists of a GND and a pair of IN+,IN- per channel. you can't use the soulutions mentioned above. for example, if you wanted to amplify the output signal of the bluetooth chip, you have to use something like PAM8302, 2.5W mono class D audio amp per channel. note the IOs:


High errors in transmission (completely eliminated by adding delay): What's the issue?

You are probably just transmitting too fast.

Your receiver is writing at least 80 bytes of debugging information (if
I counted it right) for every 3 bytes of incoming data. Since both input
and debug output happen at the same baud rate, this means the receiver
can only cope with an input data rate equal to 3/80 = 3.75% of
the nominal baud rate.

I would expect no errors at the very beginning of the program run,
because the debugging info is written to a RAM buffer. Only when that
buffer fills up the receiver is slowed down by every Serial.write()
and Serial.println() it performs.


Precise rotation (steering direction to a given angle) on obstacle avoidance robot

The only way you can know how far you have turned, with any form of accuracy and, more importantly, repeatability, is by employing some form of feedback.

In other words, to work out how far you have turned you need, first, to know how far you have turned.

The simplest method is probably to use some form of monitoring on the wheels themselves. That could be an optical encoder to give a nice high resolution "number of degrees the wheel has turned", which can be coupled with the circumference of the wheel to calculate the distance travelled (which can then be used with some simple trigonometry to work out the angle you have turned through) or a more coarse "magnet on the wheel + hall effect sensor" to give you the number of revolutions the wheel has gone through (not very accurate and only really any use at higher speeds when there will be lots of revolutions. Maybe this method would be better on the motor before the gearbox that drives the wheel?)

However, do you really care that much anyway? Are you over thinking things a little too much?

Surely a simpler method would be to first turn left an arbitrary amount (somewhere around 60-degrees-ish, you're not really worried) then sweep from left to right (a distance of somewhere around 120 degrees in total) looking for the furthest distance. Once you have completed your sweep you then just reverse your turn direction until you read the same (or within a certain tolerance) distance at which point you will be facing your longest space.

All that can be done just with spinning the wheels either for a pre-defined period, or until a specific reading has been obtained. No need to worry about precise angles or anything fancy like that.


Need help with on off switch to power arduino.

Since you are using an Arduino Uno board, putting the MCU (the ATmega328P-PU) to sleep won't save you much battery juice. Putting the MCU to sleep won't make a difference because the voltage regulator on the Uno will waste a lot more power than anything else on the board. The ON LED will also draw significant amount of current on that board.

To really save power you should look into getting an Arduino board that has a more efficient voltage regulator, or use no regulator at all by changing your 9V battery by, say, 4 NiMH AA cells.

Here's some more information about the issue for you to look at: What are (or how do I use) the power saving options of the Arduino to extend battery life?


I would connect each of the IC's IO pins to both a digital output and
a digital (or analog) input of the Arduino, like this:

simulate this circuit – Schematic created using CircuitLab

Drive each pin with the digital output, alternatively LOW and HIGH.
While doing this, read the pin voltage through your input:

If the IC pin is an input, you will have no significant voltage drop
through the protection resistor. Your reading should be LOW when
driving the pin LOW and HIGH when driving it HIGH.
If the IC pin is an output, you will have 5 V through the
resistor whenever the IC's output value doesn't match your Arduino
output. The reading on your input will be independent of the level of
your output.

Obviously, an Uno doesn't have enough I/O pins to implement this idea.
You could use a Mega instead. Notice also that with this setup you don't
need the joystick input: you could just test for every known IC type
until you find one that matches the observed behavior, then display the
part number on your LCD.


How to connect Wi-Fi shield ESP-12E-ESP8266-UART-WIFI-Wireless-Shield with Arduino

There are some fake Modules on eBay! Only after changing the wiring can you use them. The fake modules have the wrong text printed on it.

  Moer info $ tech

instead of

  More info & tech

But when you change the wiring you can use the shield!

The two transistors which are connected to Arduino board pin 0 and 1 have to disconnected. Also the connection to the switches 1 and 2 have to change. Then you can stack ESP-12 shield on the Arduino. You can now flash the Arduino Uno when you switch off (switch 1 and 2) With the old wiring you can't use it because the transistors are wrong connected.

The voltage divider is need for 3,3 V ESP-12 RX pin


How to get the rightmost four bits from a byte

Just mask it with an AND operator:

val = var & 0xF;


How can I fix this error "invalid operands of types 'const char [17]' and 'float' to binary 'operator+'"?

These lines give you errors, because you cannot simply add character arrays (aka c-strings) and floats together with the + operator. C/C++ is very strict, when it comes to variable types. The compiler does not know, how it should add these types together.

In other high level languages a string literal (characters enclosed by " in the source code) are more complex types, than c-strings. They mostly have various different methods and also an implementation of the + operator for adding a float number in human readable form. This complex type in the Arduino world is the String type. You can convert the float variable into a String and then add them together. But that's not the way, that you should do it. Strings on AVR based Arduinos (like Uno, Nano, ...) can be very evil due to the limited RAM. See Majenko's blog entry about The Evils of Arduino Strings for more information.

Instead you should just use multiple print statements. As Serial data is send out serially (one byte after another), it doesn't matter, if you put all the data to send in one print statement, or in multiple onces. So each of the offending lines can be converted to something like this:

Serial.print("Gyro degree(x)= ");
Serial.print(rtX);
Serial.print(" ");

It does exactly, what your code does. But it will not produce an error, since the Serial.print() method is also implemented for using float arguments.


Arduino Due as Triggered DMA SPI Slave is possible?

I think I have discovered a solution while searching:
https://github.com/avrxml/asf/blob/master/sam/drivers/spi/spi_dmac_slave_example/spi_dmac_slave_example.c

It is an example for atmel's sam3X8EK. But the MCU cores are same. Though the code serves different purpose, we can manage to mold it in the direction we need.
Only thing remained to do is to push an array through it.
Fellows, what do you think?


How is that possible that it has two different baudrates?

Very simple. Exactly the same as the Arduino.

If you put:

Serial.begin(9600);

in your program then your sketch runs with the serial port at 9600 baud. However, just before then, the bootloader runs at 115200 baud for a few seconds listening for instructions from the PC.

There's no magic there.

You can even do it yourself:

Serial.begin(9600);
Serial.println("Hello at 9600 baud");
Serial.flush();
Serial.end();
Serial.begin(115200);
Serial.println("Hello at 115200 baud");
Serial.flush();
Serial.end();

The baud rate isn't fixed. It's whatever the firmware that is running at that precise moment deems it to be - whether that is the bootloader, the AT firmware, or your own custom sketch.


Disable the Amplifier during the flashing ESP8266

SD is pulled up to VIN by a 10kΩ resistor. You will need to pull it down to ground with something "stronger" that 10kΩ - a 1kΩ resistor would probably do it.

Then you can drive the pin HIGH and override that 1kΩ resistance to enable the module.

You could also modify the module to remove the 10kΩ pull-up resistor (the one right by the VIN label which has 1002 printed on it) and use a weaker pull-down resistor (10kΩ would be good).


RF24 library commands, channel, and address

A. Does address take character or number as input?

The address is 5 bytes. In this library it is provided as an array. In C a string is merely an array of bytes. So it is possible to represent an array of bytes as a simple string. Internally the two representations:

byte address[] = "123ab";

and

byte address[] = { '1', '2', '3', 'a', 'b' };

and even:

byte address[] = { 0x49, 0x50, 0x51, 0x97, 0x98 };

are all identical, except that the first one adds an extra 0x00 to the end of it to mark the end of the string (which the library completely ignores).

  B. From some other video I learned that RF24 have channel and address for communication, where channel can take value from 0 to 125; pin/port take value from 0,1-5; and the address.

It's helpful here that you have some understanding of basic radio communication terminology.

When you say that a device works at X frequency you are generally only referring to the "frequency band" that the device operates within (2.4GHz in this case). The device doesn't work at 2.4GHz - only "in the 2.4GHz band". That frequency band is then divided up into channels. Each channel is a specific frequency. Just like your television has channels you select one specific channel (and thus frequency) to tune into and communicate on.

Channel numbers are just used because it's far far easier to remember "channel 21" instead of 471.25MHz, for example.

For two devices to be able to communicate they both need to be tuned to the same frequency, and hence the same channel.

The "address" is more like the address your computer has on the network. Within the channel frequency you can have multiple devices communicating. The address identifies exactly which of the devices you want to send data to or are receiving data from.

  C. Can one open up more pin/port in transmitting and writing?

The nRF24L01 internally uses pipes as a method of separating data from different devices into distinct feeds that you can read from. It is merely for convenience. You can open up to 6 pipes at once, each one receiving from a different address. All pipes are in the same channel though since you can only tune to one channel at a time.

By the way - the keywords.txt file exists solely for the IDE to do highlighting of certain words. It's not meant for a human to read when working out how to use a library.


Connecting microSD reader and e-paper display to Nano at the same time?

No. Even the e-Paper alone is not usable by an Arduino Nano.


Writing a new function: configMotor(speed, direction)

All you need to do is pass a parameter to config that says forward or backwards (was direction).
This parameter then sets the values of that the pins INA/B will be set to, because they are opposite.

Does that make sense?  If not add a comment with you question and I'll try and clarify.

int inaDirection = LOW;
int inbDirection = LOW;

void configMotor( int speed, bool forwards = true)
{
   pwmVal = speed;
   inaDirection = forwards?HIGH:LOW;   // ? and : are the same as an if statement, just more compact.
   inbDirection = forwards?LOW:HIGH;
}

// move no need for forward and reverse anymore
void move()
{
    analogWrite(pwn, pwmVal);
    delay(sDelay);
    digitalWrite(ina, inaDirection);
    digitalWrite(inb, inbDirection);
}


Can I use a MCP23017 to connect multiple RC522 modules?

Sure, you can use IO expanders for the chip-select pins of SPI devices. You will have to modify the device libraries to support them, though, because no one is going to do that by default unless it's a very very specific library.
However you will probably not have much luck with your project anyway, since you will more than likely run into problems with fan-out and bus capacitance before you even remotely approach 64 devices on your bus.
You would need to be adding extra bus drivers and partition your bus to reduce and spread the load - at which point it would be simpler and cheaper to just use multiple microcontrollers with just a few RC522s one each.


ESP8266 in AP Mode -determining if a station is connected

Followup answer from comments:

The issue was an outdated version of the ESP8266-Arduino framework. The function WiFi.softAPgetStationNum() is available in 2.4.1

For the sake of completeness: The function itself is simply a wrapper for the Espressif non-os SDK function:

/**
 * Get the count of the Station / client that are connected to the softAP interface
 * @return Stations count
 */
uint8_t ESP8266WiFiAPClass::softAPgetStationNum() {
    return wifi_softap_get_station_num();
}

See Espressif Non-OS SDK API reference chapter 3.5.36.

That function should also be available on older framework versions. However, upgrading is the recommended way to use that function.


Never used neoPixels in arduino before so this is a complete guess based on reading the code but it looks like you are only setting the colour of the first LED.

Try creating 16 LED colours:

CRGB led[16];

and then setting them all:

for (int i = 0;i<15; i++) {
  int colourIndex = index + i;
  if (colourIndex > 15)
    colourIndex -= 15;
  led[i] = ColorFromPalette(auroraPalette, colourIndex , 255, LINEARBLEND);
}

edit - as @rDg indicates in his answer

FastLED.addLeds<NEOPIXEL, 6>(&led, 16);

becomes

FastLED.addLeds<NEOPIXEL, 6>(led, 16);

since led is now an array not a single value

Finally I think paletteSize should only be 16 not 5*16, you only have 16 colours in there.


String is not a simple type like an int or a char. It is a class with many member functions and, more importantly, operators.  When you create the object it allocates room for that object either on the stack (for a local variable) or in the global data area if it's a global variable. However that object doesn't contain the memory used to store the actual string data - it only has a pointer. The memory for the string data is allocated on the heap using malloc() and realloc().

Assigning string data to the String object is done through the = operator defined in the class, of which there are a number of overloaded varieties:

String & String::operator = (const String &rhs)
{
    if (this == &rhs) return *this;

    if (rhs.buffer) copy(rhs.buffer, rhs.len);
    else invalidate();

    return *this;
}

#if __cplusplus >= 201103L || defined(__GXX_EXPERIMENTAL_CXX0X__)
String & String::operator = (String &&rval)
{
    if (this != &rval) move(rval);
    return *this;
}

String & String::operator = (StringSumHelper &&rval)
{
    if (this != &rval) move(rval);
    return *this;
}
#endif

String & String::operator = (const char *cstr)
{
    if (cstr) copy(cstr, strlen(cstr));
    else invalidate();

    return *this;
}

String & String::operator = (const __FlashStringHelper *pstr)
{
    if (pstr) copy(pstr, strlen_P((PGM_P)pstr));
    else invalidate();

    return *this;
}

They all, ultimately, call the copy() or move() functions which copy the data from the source into the memory allocated on the heap (increasing the allocation if needed).

Using:

String s1 = "Foo";
String s2 = s1;

s1 has memory allocated on the heap, then Foo\0 copied into it.  s2 then also has memory allocated on the heap, and the data from s1 is copied into it. So you have two separate objects with separate memory allocated for their content.  So then doing:

s2 += "bar";

you end up with:

s1: "Foo\0"
s2: "Foobar\0"

Since it's an object that's allocated on the stack (or in global space) and not a pointer to the object you can get a pointer to it like with an int:

String s1 = "Foo";
String *s2 = &s1;
(*s2) += "bar";

Which gives you just one object and one memory space, but two names for it, and the result is:

s1: "Foobar\0"
s2: "Foobar\0"

This is why it's important to use either pointers or references when passing String objects as parameters to functions, and the constant allocation and reallocation on the heap why String objects are frowned upon in microcontrollers with very limited RAM.


stick to one type of variable, to prevent mix-up

So if you stick to a byte (uint8_t) type for keypad:

uint8_t keys[4][3] = {
  {1,2,3},
  {4,5,6},
  {7,8,9},
  {0xF,0xA,0xB}                 // F-*  B-#
}

then you can save it to your EEPROM as a byte and read it as a byte.it will prevent mix-up.
your code which you are not displaying (everybody here can write one of those faster then to download it from here)already translate numbers to numbers and then you are growing them to symbols with higher value


How to close humidity sensor at specific humidity

In this code:
void loop()
{
   sample temp and humidity;
   display temp;
   display humidity;

   if humidity <= 50
      LED on;
      buzzer on;
   else
      display temp
      wait 2 sec
   end

There is a missing '}' to to close the if/else.
Why do you display temp twice within the loop?
Where is the logic for the relay and the buzzer at 65%?
Pin numbers for the LED and the buzzer are undefined.
The LED and buzzer pins need to be set to OUTPUT mode in your setup() function.

If I understand your description, you probably need somethng like the following, in your loop function:
   if humidity <= 50
      LED on;
      buzzer on;
   else if hum >= 65%m
      close relay;
      buzzer on;
   end

When I have a problem with program logic that isn't obvious to me, I write it out in pseudo-code as I did above. Once I figure out the logic, then I'll type in C++ with proper syntax.
If I haven't understood your intentions in the above pseudo-code, I'd suggest you do the same thing, until you believe what you've written. Only then try to make it into working code.


ESP32-Cam No Response and Unable to Program - Timed out waiting for packet header

You're right. There is no LED when you power up your ESP32 cam. So this is normal.

Try to power it with the 5V, so you can power it from your USB instead of the 3.3V regulator of your FTDI. The ESP just need 50mA when in programming mode, so it should not be a problem for your FTDI.

Do you see anything on your serial output? Once you connect it in this way, you should set the baudrate to 115200 on your serial terminal and see some characters.

Then, try to program it.
Once you see the output "...___...", press the reset button! Since you are just connecting RDX and TDX, you have to manually press "RESET" on your ESP32 module.

At this point the ESP will reset and enter in the programming mode.


Because you have only declared the class static variables; you never defined them.  For the Robot class, you must have:

class Robot
{
    public:
         ...
};

float      Robot::x;
float      Robot::y;
float      Robot::t;
State      Robot::state = doingNothing;
SpeedState Robot::speedState = notMoving;
int        Robot::currentSpeed;

void setup()
{

Ditto for other classes.  (Dangit, Mikael!  :) )


make EEPROM.h use custom eeprom partition

EEPROM on the ESP32 doesn't work like you would expect.  It uses the SDK's "Non-Volatile Ram" storage system to store the data within the nvs partition.  This works through a system of "Key / Value" pairs, and the data is stored as a "BLOB" (Binary Large OBject) for the key eeprom in the namespace eeprom.

Quite what the internal layout of the data within the partition itself is I have no clue (the SDK is closed source), but it won't just have your string located at the start of the partition - it will be at the start of the BLOB, wherever that happens to be in the partition.

The eeprom partition is no longer used. It's just wasted space.

  Can this flash-detection be trusted or does it simply fail because I try to flash 8MB to a 4MB ESP32?

I can't comment on that I'm afraid. I would have thought it would look at the chip's JEDEC data, but it may just look at the partition table information instead.

  What is supposed to happen if I created a partition table that exceeds the flash memory size?

Probably not a lot, since much of the partition table refers to data storage, or a (presently) unused OTA partition.

When you compile your code you're only compiling it for the partition in which it will reside (app0 for example). When you upload the code you are only uploading to that partition.  Anything outside that range is irrelevant to the compilation / uploading.

  When I put a partition table at an offset of 10M the build process still doesn't fail (is that what should happen?).

As I mentioned, it won't care. The partition will not be accessible, since it doesn't actually exist, but it's just an entry in a table. The compiler doesn't know or care what it is.


How to assign two or more variables incoming from app

This is a classic problem that is solved either by uniquely identifying each value or by agreeing on a pre-defined sequence of data.  However, it can be said that many solutions exist for this problem & that these are only 2 examples.

In the first case, the sender and receiver need to agree that all data will be sent in pairs.  A pair of bytes, for example, where the first identifies the data and the second is the data.  In this case the order of data does not matter.  And much more of one type of data can be sent than another.  This is good to use when the data rate is irregular and does not need to be fast.  Stock prices for example.

In the second case, the sender and receiver need to agree that all data will be sent in the same sequence even if there is no data to be sent.  Such a scheme may employ a special synchronizing bit to identify the beginning of a sequence of data.  Usually, when there is no data to be sent, a zero is sent.  But if zeros are significant, then special null characters will have to be agreed upon.  This is good when the data rate is regular and needs to be fast.  Digitized audio for example.


Serializing data created by ATTiny85 for use on PC

So thanks to Ignacio Vazquez-Abrams' tip, it looks like I'll be able to accomplish this with V-USB:

  V-USB is a software-only implementation of a low-speed USB device for
  Atmel’s AVR® microcontrollers, making it possible to build USB
  hardware with almost any AVR® microcontroller, not requiring any
  additional chip.

Requirements: AVR microcontroller with at least 2 kB of Flash memory, 128 bytes RAM and a clock rate of at least 12 MHz.

Taken from ATTiny85's Datasheet:

  8K Bytes of In-System Programmable Program Memory Flash
  512 Bytes In-System Programmable EEPROM (enough for third-two 16-byte keys)
  512 Bytes Internal SRAM

Looking forward to trying it out :)


Arduino Mega timeout communication with programmer error

The bootloader on an arduino is just a piece of software written to enable you to update your sketches using the usb connection. Without the bootloader you can't upload sketches using just the arduino ide.

More information about the bootloader can be found here: http://arduino.cc/en/Guide/Environment?from=Tutorial.Bootloader
Look under the heading entitled uploading which explains the part the bootloader plays in uploading sketches.

When you use the "Burn Bootloader" button in the arduino ide it will attempt to write a new copy of the bootloader onto the attached Arduino board. To do this the board must be attached in a specific manner - that is - using the icsp/isp header rather than the usb cable.

Now to program the avr chip directly you have to use an external (hardware) programmer. Fortunately you don't have to buy one if you have a second arduino because the second arduino can be used as a programmer. Instructions for doing so can be found here: http://arduino.cc/en/Tutorial/ArduinoISP

Even more info about the bootloader: http://arduino.cc/en/Hacking/Bootloader?from=Main.Bootloader


How do I transfer more than 1 byte at once via SPI bus?

I believe Arduino's SPI.transfer waits to receive 8 bits after sending 8 bits.

Incorrect. With SPI, a byte is clocked in at the same time as a byte is clocked out. It may be that this byte is simply a dummy byte though, if the slave has nothing to say.

So for 24 bits, simply clock out 3 bytes without deasserting the select. Since SPI is a synchronous protocol there should be no issue with having a delay in between bytes provided the select is maintained.


Which Protocol to use to control WiFi (esp 32) enabled Led Light

You can use your ESP as a server by the following code and then put your DigitalWrite(1, HIGH) line in the code like the following:
 String line = client.readStringUntil('\r');
 Serial.print(line);
if(line=="ledon")
{
DigitalWrite(1, HIGH);
}

and at this point you just can call the following link to turn the led on
http://192.168.*.**/ledon

or whatever the starting of your ipv4 is.


You have a lot of redundant code:

include Ultrasonic.h is unnecessary.
servo.attach and servo.detach without reusing pin is unnecessary
The ultrasonic code is not correct.
It should be:

    digitalWrite(trigPin, HIGH);
    delayMicroseconds(10);
    digitalWrite(trigPin, LOW);

    // measure duration of pulse from ECHO pin
    duration_us = pulseIn(echoPin, HIGH);

    // calculate the distance
    distance_cm = 0.017 * duration_us;

Refer to the Ultrasonic sensor tutorial and Servo motor tutorial


How can I control neopixels attached to a Digispark?

You need a dedicated microcontroller since you need very precise timing for controlling the neopixels. It works well on an ATTiny85, we are using Adafruit Trinket boards to control Neopixels and work well. So far up to 12 pixels :)

You can download a Trinket Neopixel library, which is modded for an internal osc ATTiny85 from Adafruit.

Then your Raspi can talk to the microcontroller. It is a little problematic, though, since the software serial port handling consumes too much memory on ATTiny, and the ATTiny will ignore all serial input while refreshing the neopixels. Therefore you may get it easier by using an Arduino UNO, or Leonardo or Micro which is powerful enough for many pixels, and have a built-in hardware serial port.

As a matter of fact, you can talk to these Arduino boards as if it would be a serial port, so just plug in a Leonardo over USB and you'll get a new serial port in Rpi to talk to.


Analog output doesn't work for just 2 LEDs [Arduino Mega]

Analog pins an only read analog values, not write them.

analogWrite() is a deceptive name. It should really be PWMWrite() since all it does is PWM. And that, of course, needs PWM pins.


What sensors do I need to detect magnetic "take off"?

You have two options here, either a Hall Effect sensor or an Inductive Sensor. The hall effect sensor is probably the best option. This will likely need some calibration on your end to identify the exact value you record at "Take Off" for your setup.


Process Sensor Data from Arduino Yun with Python

You might want to try the Process method, although, looking at your recent edits to the question, it seems like you already have.

Nevertheless, I was having difficulty getting my head around the problem when I first used my Yún, and I found the information below helped me understand how to get up and running. You do say that you've tried many solutions already, and maybe you've already seen this, but as you don't list which solutions you have already tried (apart from one), I thought it might be worth posting this link as an answer.

From this post to the thread on the Arduino forums, Yun Serial connection between Arduino and Linux

  Accepting HTTP connections, as shown in the Bridge tutorial, is
  but one facet of the Bridge library. (And probably the least useful
  and least efficient facet.) It is intended for accepting incoming
  connections from the greater network, not necessarily the local Linux
  processor.

  The Bridge library is a collection of different classes that perform a
  variety of operations, all over the serial link between the two
  processors, and all can be used at the same time. The Bridge uses a
  network port paradigm, not HTTP. Using ports gives it a little more
  overhead, but it allows multiple simultaneous "connections" between
  the sketch and Linux sides.

  I suggest you take a look at the Process tutorial. It does what
  you want, and 95% of the time it is the only part of the Bridge
  library that I use. The example defines Process objects that are local
  to a function, which run simple commands that do a little bit
  different f processing, return a result, and then exit.

  My projects typically define a global Process object which starts a
  Python script, and keeps the connection open. Once open, the sketch
  can write to the Process object at any time, and the Python script
  reads that data from STDIN. Python can write to STDOUT at any time,
  and the sketch can read it from the Process object. The Process class
  derives from the Stream class, just like Serial, so your sketch can
  use any of the read/write methods you would use for a serial port. On
  the Linux side, you are just reading/writing as you would to the
  console. By default, Pythons runs in a buffered mode: I've found that
  you need to add the -u option to the command line that runs your
  Python script, or add it to the hashbang at the beginning of your
  script.

  There are those who disable the Bridge library, and use the serial
  port manually on both sides. This can be done, but I've not had to
  resort to that yet. The Process class does everything that a direct
  serial connection can do, and more: you can have multiple simultaneous
  Process connections going, and you can still use all of the other
  Bridge library features. If you disable the Bridge library, you get
  just the one connection stream. It would be a bit more efficient, but
  unless you are dealing with high amounts of data, I'll bet you don't
  need to do that.

  My typical project has the sketch running as a rather dumb I/O
  processor, passing barely digested input data down though one or more
  Process objects to a Python script. The Linux side does all of the
  heavy processing and network communications, and then sends output
  data back up the sketch which outputs it to the pins.


So first thing, you should try to be more disciplined with your code formatting and the question...

FYI: it's best to use #define as it doesn't use memory for storing pin numbers... It's like Find and Replace in a text editor, this:

const int controlPin2 = 4; // connected to pin 2 on the H-bridge
const int enablePin = 3;   // connected to pin 1 on the H-bridge

Becomes this:

#define controlPin2 4  // connected to pin 2 on the H-bridge
#define enablePin   3  // connected to pin 1 on the H-bridge

So this is the tidied up code, you can see the problem is a lot more approachable when the code is indented consistently, and good use of spaces and new lines is used...

#define controlPin2 4  // connected to pin 2 on the H-bridge
#define enablePin   3  // connected to pin 1 on the H-bridge

void setup () {
    pinMode( controlPin2, OUTPUT );
    pinMode( enablePin, OUTPUT );

    digitalWrite( enablePin, LOW );
    digitalWrite( controlPin2, LOW );

    Serial.begin( 9600 );
    Serial.println( "Ready" );
}

void loop() {
    if ( Serial.available() > 0) {
        int inByte = Serial.read();

        switch ( inByte ) {

            case '0':
                digitalWrite( enablePin, LOW );
                digitalWrite( controlPin2, LOW );
                Serial.println( "OFF" );
            break;

            case '1':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 50 );
                Serial.println( "CW slow" );
            break;

            case '2':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 100 );
                Serial.println( "CW slow +" );
            break;

            case '3':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 150 );
                Serial.println( "CW medium" );
            break;

            case '4':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 200 );
                Serial.println( "CW fast" );
            break;

            case '5':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 250 );
                Serial.println( "CW fast +" );
            break;

            case '6':
                digitalWrite( controlPin2, LOW );
                analogWrite( enablePin, 50 );
                Serial.println( "CCW slow" );
            break;

            case '7':
                digitalWrite( controlPin2, LOW );
                analogWrite( enablePin, 100 );
                Serial.println( "CCW slow +" );
            break;

            case '8':
                digitalWrite( controlPin2, LOW );
                analogWrite( enablePin, 150 );
                Serial.println( "CCW medium" );
            break;

            case '9':
                digitalWrite( controlPin2, LOW );
                analogWrite( enablePin, 250 );
                Serial.println( "CCW fast" );
            break;

        }
    }
}

So your actual problem is that you need to reverse cases 1, 2, 3, 4, 5 to be 5, 4, 3, 2, 1...

There are two solutions:

Inelegant: would be to simply change the case numbers, they don't have to be in-order.
Elegant: copy and paste the code in each of the 5 cases about.

The result of option 2 is as follows, please feel free to confirm this is working?

#define controlPin2 4  // connected to pin 2 on the H-bridge
#define enablePin   3  // connected to pin 1 on the H-bridge

void setup () {
    pinMode( controlPin2, OUTPUT );
    pinMode( enablePin, OUTPUT );

    digitalWrite( enablePin, LOW );
    digitalWrite( controlPin2, LOW );

    Serial.begin( 9600 );
    Serial.println( "Ready" );
}

void loop() {
    if ( Serial.available() > 0) {
        int inByte = Serial.read();

        switch ( inByte ) {

            case '0':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 250 );
                Serial.println( "CW fast +" );
            break;

            case '1':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 200 );
                Serial.println( "CW fast" );
            break;

            case '2':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 150 );
                Serial.println( "CW medium" );
            break;

            case '3':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 100 );
                Serial.println( "CW slow +" );
            break;

            case '4':
                digitalWrite( controlPin2, HIGH );
                analogWrite( enablePin, 50 );
                Serial.println( "CW slow" );
            break;

            case '5':
                digitalWrite( enablePin, LOW );
                digitalWrite( controlPin2, LOW );
                Serial.println( "OFF" );
            break;

            case '6':
                digitalWrite( controlPin2, LOW );
                analogWrite( enablePin, 50 );
                Serial.println( "CCW slow" );
            break;

            case '7':
                digitalWrite( controlPin2, LOW );
                analogWrite( enablePin, 100 );
                Serial.println( "CCW slow +" );
            break;

            case '8':
                digitalWrite( controlPin2, LOW );
                analogWrite( enablePin, 150 );
                Serial.println( "CCW medium" );
            break;

            case '9':
                digitalWrite( controlPin2, LOW );
                analogWrite( enablePin, 250 );
                Serial.println( "CCW fast" );
            break;

        }
    }
}


You can convert the PWM output of analogWrite() into an (approximate) analog voltage by adding a low-pass filter. That is, a resistor in series followed by a capacitor to ground.

The values to choose depend on the frequency response you want.

RC Filter Calculator (second section).

For anything more complex or accurate you will need a DAC. I often use the MCP4822 SPI DAC chip.


Right at the start of your loop you have this (and other similar constructs):
if ( ! mfrc522.PICC_IsNewCardPresent()) {
    return;
}

That means that if no new card is present on reader 1 then the rest of the loop is ignored. Nothing else can happen.
You need to restructure your whole program so that it works in the complete opposite way - instead of saying "If there's no card do nothing" you should say "If there is a card then do something".


It is easier than I thought! I soldered audio jack to MIC+GND, inserted microphone in and it works!
And pretty well :-)
Cheap random lavalier model: Panasonic RP-VC201. I guess any consumer model will do.


I did not download Arduino as ISP into my arduino. I realize how much of an idiot I am. The capacitor wasn't even needed for some reasons. I might make an intensive tutorial on this project.


Arduino Micro: Why am I getting 6.00 as a result instead of 6.66?

(community wiki answer derived from comments - takes Q off unanswered list)

Why am I getting 6.00 as a result instead of 6.66?

because integer arithmetic discards fractional parts of results, including intermediate results
static int count, thrust, weight;             // countdown, thrust, weight value

If some of these are intended to have decimal values you need to use a more suitable data type (e.g. float)


In short: No and no.

  Can I use AudioInI2S library to receive audio samples?

No.  The library is not for the Mega:

  This library provides simple way to play and analyze audio data using Arduino on SAMD21 based boards (i.e Arduino or Genuino Zero, MKRZero or MKR1000 Board) using the I2S bus.

  Does HC05 support this type of communication?

No.  The HC05 is a serial module. It works at baud rates that are far to low to transfer the data in a timely fashion, and can't send data in a form the PC sees as audio (so you'd need to write your own translation software to convert serial data into an audio file).

  Any guidance would be appreciated.

Just buy a cheap bluetooth headset.


I just had to connect the RX/TX jumpers. There was no real issue.

I though connecting the power jumpers was enough to just see HM-10 on my phone, since I didn't care about any data. Turns out if the RX/TX jumpers are not connect, the module behaves weird.


Arduino MKR Zero problem with new UART comunication

When a library does not highlight, it might be that the library is not coded to be highlighted (see here).

If you installed the library yourself, you may have put it in the wrong path.


It takes twice as long to print "1023" (6 bytes, including the CRLF line
terminator) than to print "0" (3 bytes). Thus, in the same time, you are
printing twice as many "0" than "1023".

If you want the data points to be printed at a consistent rate,
you can impose the printing timing just like you did on the
output_state. Keep in mind that you cannot print more than 20 samples
per second at 1200 bps. You could also pad the strings so that they
always have the same length:

char s[5];  // one byte for the NULL terminator
sprintf(s, "%4d", output_state);
Serial.println(s);

I would prefer the first solution (explicitly control the timing).


Difference between ISR and other functions in AVR twi library

The confusing thing is that there is only one interrupt, and it is called for a number of different reasons.

To make sense of why it's being called you also have to know what you have just done in order to know what to expect. In this case we have just sent a START bit, so we set the current status to "start sent". When the interrupt fires we know that it must be in response to the start bit we sent earlier having been completed, so it's time to then send the address.  It's just implementing a simple state machine.

To answer your second question: both are "real" and used.

When sending data to a slave it can be easily implemented with a non-blocking interrupt arrangement. This makes it fast and efficient, and you can get on with doing other things while the data is being sent. That uses the ISR.

When reading from a slave it's harder to implement it with an ISR and still fit into the Arduino ethos of "data is available immediately", so when using requestFrom a simpler blocking routine is called that doesn't use the ISR. This means that when the function is completed all the data has been received and you can get on with reading it from the buffer. If you used the ISR instead then data wouldn't have arrived until some unknown time after you have made the request - so you would have to implement either some kind of callback system to execute a user function when the data has arrived, or manually block waiting for the data to arrive polling a status set by the ISR, which is pretty pointless anyway. So it's just been implemented as a simple blocking routine.

It's crude, but like much of the Arduino API it "gets the job done with the minimum of fuss" - sacrificing efficiency for simplicity and ease of use.

To break it down for you further:

When using Wire.beginTransmission(...) the ISR is used to empty the buffer onto the physical wires. Your sketch can continue while that is happening.
When using Wire.requestFrom(...) the ISR is not used. Your sketch cannot continue until the whole buffer has been received (or it times out).

When using Wire.beginTransmission(...) you first fill the buffer (32 bytes maximum) with your data to send. Calling Wire.endTransmission(...) then starts the sending of the data from the buffer using the ISR.

When you use Wire.requestFrom(...) a call to the Wire.beginTransmission(...) and Wire.endTransmission(...) functions are called to send the address. This uses the ISR.  Following that the twi_readFrom(...) function is called to receive the data in a blocking fashion. That first blocks itself waiting for the ISR to signal that the I2C bus is available and it has finished sending the address. The twi_readFrom(...) function then, if it's using repeated start, sends the start bit again. If it's not using repeated start then it just gets on with the task of reading the data into the buffer.  The actual reception of the data triggers an interrupt which copies the data into the incoming RX buffer from the FIFO, but that's pretty much all the interrupt does when receiving.

Much of the confusion (and it's confusing even to me) comes because the Wire library is written in two layers - an Arduino API wrapper class which implements the Wire object that you are familiar with, and a pure C set of helper functions which most likely were ported over from some other Atmel application library originally. This makes it quite hard to follow what is going on, since the two programming styles and ways of working are very different. Following the thought processes of two different parties working in different ways with different goals in mind is tricky at best.

To better understand how it all fits together you want to sit down with a couple of example transactions (both read and write) and a copy of the datasheet and trace exactly how the program would flow and respond to the different events and sequences within those transactions. Have the transaction waveforms on paper in front of you and mark on them where the different interrupts trigger. Follow that through in the code and work out what exactly gets called when and why it gets called. Quite an arduous task, but essential if you want to fully understand exactly what is going on in the code.


analogWrite never outputs a non-zero voltage

On most boards, the standard implementation of Arduino's analogWrite() will only ever produce PWM, and only on a specific set of (digital) pins. These are usually pins 3, 5, 6, 9, 10, and 11, although it's slightly different on some boards.

The only official board which has 'true' analog output is the Due (pins DAC0 and DAC1).

If you want any other behaviour (such as outputting PWM on non-standard pins), you'll either need to modify the Arduino implementation, or directly manipulate the microcontroller's special registers. Note though that modifying the chip's configuration could cause other standard Arduino functions not to work as expected.


Communication between three NodeMCUs such that one in in AP mode, second one in AP+STA mode and the third NodeMCU in STA mode

The two network interfaces (station and SoftAP) of the middle esp8266 must have different IP address range. If the top esp8266 has SoftAP with 192.168.4.x, set for the SoftAP of the middle esp8266 IP for example 192.168.5.1. Because with same IP address ranges the esp8266 doesn't know to which network do you want to connect a TCP socket or send an UDP message.


Is it possible to gather data while the Arduino is being powered with a battery, connect to comp, and then read off the values in Serial Monitor?

Yes, this is perfectly possible. You will need to write a routine that you can trigger via Serial. For example you will listen on Serial until you get the dump command. Then run a function that spits your variables out to Serial.
You just have to be careful where you save your 5 variables.
If stored in memory (RAM), you should avoid power loss. Therefore I'd suggest a FTDI USB-to-Serial adapter. There you just connect the TX, RX and GND wires and proceed with the Arduino IDE's Serial Monitor.
If stored in EEPROM, you can use the regular USB connector of Arduino.


Resolved with the following Makefile options:
BOARD_TAG=324
MCU=atmega324a
VARIANT=standard


Looking further here

http://forum.arduino.cc/index.php/topic,188236.0.h...

I found the following

"Removing
the files - libraries\RobotIRremote\IRremoteTools.cpp and
libraries\RobotIRremote\IRremoteTools.h solved the problem. They are
example files which somehow are getting included. You can move those two
files to some other location as backup."

I went to my libraries
file and did this and can confirm that the example given above then
compiles fine without downloading a new library. Its an Arduino
libraries problem .

Either way will work

answer from here and worked for me

i use this code:

#include <IRremote.h>
int input_pin = 10; //set D10 as input signal pin
IRrecv irrecv(input_pin);
decode_results signals;
void setup()
{
    Serial.begin(9600);
    irrecv.enableIRIn(); // enable input from IR receiver
}
void loop() {
if (irrecv.decode(&signals)) {
        Serial.println(signals.value, HEX);
        irrecv.resume(); // get the next signal
    }
}


Problems with detecting button digital state

turns out that it is very simple, I shouldn't put buttonPin[1] a variable for PressNHold, I had to put just1, buttonPin was used already in button_state, also, PressnHold local variables should be declared static to not get a reset after function execution.


Arduino Uno with UsbSerial Android library w/ baud rate over 9600?

I have no enough reputations to make a comment so I will drop my two cents here.

Are you changing the baudrate at both sides?

I have been using the arduino's built-in UART library for a while using different baudrates with no problems. Your problem could be an issue related to the library you are using.


Get USB host controller serial number or ID using Teensy or other HID devices

Nothing in the USB spec requires the host to provide any sort of identification to connecting devices. The standard way of implementing what you want consists in writing a custom driver which communicates the necessary information to the device. If installing a custom driver is not an option, all you can do is try to detect the OS by observing what it does during the enumeration process. Such identification will not be reliable (enumeration process can change after an OS update) and by no means unique.

Note that if your goal is to make sure the host is trusted, a simple ID will not be enough as it can be easily spoofed. You'll have to implement some sort of authentication scheme, e.g. challenge-respose.


I guess avoiding functions may have been relevant with dumb compilers, a
few decades ago. Compilers today are pretty good at optimizing and,
since recently, the Arduino environment enables “link time
optimization”. This means the optimizer can see the whole program at
once, which enables:

function inlining across compilation units (and the optimizer does
this pretty aggressively)
saving, in the function prologue, only the registers that really need
to be saved.

In most cases, the “optimal” size for a function is whatever size
optimizes the readability of the code. In the rare cases where you would
need to merge a function into its callers for performance purposes, you
can qualify the function as
inline __attribute__((always_inline))

But this only makes sense after you disassembled the program and noticed the
compiler did not make the right optimization choices. A quite infrequent
situation.


Welcome to the wide world of Communications.  You are asking about "Error Detection and Correction".  This is different from "framing", which allows you to determine when a message starts and ends.

With "error detection", you know there was an error, but you can't necessarily recover from it.  With "correction", you know there was an error and you can determine what was originally sent.

This always requires extra bytes.  There are many schemes, but the Fletcher checksum for Error Detection is easy to implement, fast, and only requires 2 extra bytes in the message (4 if hex digits).

The generic approach is to use a finite-state machine.  In complicated message protocols, there would be nested state machines: the inner-most would probably determine framing, the next one out might looks at addressing, etc.  Any or all of those layers could use Error Detection and/or Correction.

For your simple "protocol", a single state machine is probably sufficient.  The states might be IDLE, RX_PAYLOAD and RX_CS.  As characters are received, they are processed according to the current state and occasionally change the state variable.

while (Serial.available()) {
  uint8_t c = Serial.read();
  switch (state) {
    case IDLE:
      if (c == MSG_START)
        state = RX_PAYLOAD;
      break;
    case RX_PAYLOAD:
      if (c == MSG_END) {
        state = RX_CS;
        cs = 0;
        csCount = 0;
      } else if (length < MAX_LENGTH-1) {
        msg[ length++ ] = c;
      }
      break;
    case RX_CS:
      //  Add in the next hex CS digit
      cs = cs * 16 + fromHex(c);
      if (++csCount == 2) {
        // both digits received, see if the CS matches
        if (cs == csOfMsg( msg, length )) {
          // Handle the message
          msg[ length ] = '\0';
          Serial.println( msg );
        } else {
          Serial.println( F("Bad message!") );
        }
        state = IDLE;
      }
      break;
  } // end switch
} // end while

There are entire books written on protocols and their design.  This is just a made-up example to give you an idea of how it should be structured: a finite state machine, driven by received character "events".

Sometimes you can compute the checksum as the characters are received, like Fletcher.  Here, it waits until the entire message plus 2 CS bytes are received.