text:
Applause reactivity
I'm making a pretty basic light circuit and I'd like to have it react to applause or laughter, but NOT during regular speech, amplified over speakers.
I'm wondering if anyone has already made a function for this that I could use in this design!
Your help is greatly appreciated! Thanks for being awesome people who help educate, assist, and elevate others in their creative journeys. You're the best!
Ryan

Hi Ryan, welcome.  I can see why you asked this question on here, but I think you would get a better response if the question was asked on the Electronics Exchange forum because its something someone may have done on a none Arduino platform that you could port.  If you agree then flag the question for moderator attention and ask them to move it.  (Don't cross-post, its like poking a wasps nest!)

You could try the following:  get a sound frequency specific to the applause, convert it with an analog signal and filter it with an Inductor/RC type circuit whose output goes into Arduino for further processing.

Not really an applause detector, but I have written a sound meter
program you could use as a starting point for your own project. It is
available here: Arduino sound meter. It works as follows:

the analog input is read at a constant rate of about 9600 samples per
second, which is normally fine for telephone quality audio processing
the DC offset from the microphone is removed
the readings are squared in order to get the instantaneous sound
intensity; note that this is not immediately usable, as it fluctuates
furiously
this is run through a first order low-pass filter with a time constant
of 26.6 ms in order to get a usable sound intensity reading
the readings are decimated to keep only one every 26.6 ms
they are sent to the PC through the serial port.

The program does not use the analogRead() function, because it is
really not suited for this kind of real-time sampling. Instead, it
directly accesses the ADC, it configures it in the so called “free
running mode” and uses the ADC interrupt to retrieve the samples. This
limits the portability of the program, which has been written for an
Arduino Uno.
If you want to make an applause detector form this, I suggest the
following approach:

Use the program as is, to record and plot the sound intensity as a
function of time.
Test various types of sounds: applause, laughter, speech, noise...
Look carefully at the plots and try to see how the sounds you want to
detect are different from those you do not want: high peaks? short
peaks? fast rise times? You will have to make up some criteria to
tell them apart. This is the most difficult part, as it will require
some creativity.
Write some code to apply your criteria. Keep in mind that your code
will ultimately have to run in real time, i.e. process one intensity
sample at a time. It will not have the whole record to start with.
Test your code on your computer, on the data previously recorded.
Debug, fine-tune... until you are happy with your detection
algorithm.
Modify my sound-meter program: remove the last statement
(transmitting the data to the host computer) and replace it with your
detection code.

Good luck!

This looks pretty great. I think I can work with this. I'm going to plug it in and see what kinds of values I get. From there I may have an output signal trigger an Arduino Nano running the code for the Neopixels. Touching interrupts in a program running Neopixels can be a bit problematic. Neopixels require very specific timing and sometimes interrupts can disrupt that signal, as I've found out the hard way. This isn't a bad thing though. One development of our project is that we may be putting it onto multiple boards. We could have a Nano for each independent board. This would work splendidly

I'm attempting to recreate the "Sound Sensor Example" project (http://www.arduino.org/learning/tutorials/boards-tutorials/sound-sensor-example), which does use analogRead to detect sound, and operates with a 100 millisecond delay (i.e. 10 Hz sampling). Is this approach totally flawed, or just not suited to detailed analysis of sound waves?

@yoyo: At this rate, you can only reliably sample signals slower than 5 Hz, and you will only get one or two samples out of a clap. Those samples will essentially be random numbers between offset − amplitude and offset + amplitude. Only when they are in the high part of the range will they be identified as a clap. You can probably expect to detect most of the claps, but do not expect the detection to be reliable.

@EdgarBonet thanks for the info. I used the analogRead technique to pretty reliably detect and count claps, but I look forward to using interrupts for more detailed sound analysis.


text:
Delay In receiving data when SoftPWMBegin(); is used from SoftPWM.h library
when i use SoftPWMBegin() function in setup there is some delay while receiving data over bluetooth. And if i pressed o and 1 fastly (see in below given code), some time it receives data and sometime not receives.
when i not using SoftPWMBegin() it receives data fastly . I think SoftPWMBegin() function creating some problem.
I want use SoftPWM.h library for controlling RGB led brightness. So please give me any solution for that...
#include <"SoftwareSerial.h">
#include <"SoftPWM.h">

SoftwareSerial Genotronex(0, 1);

int redPin = A5;

int greenPin = 3;

int bluePin = A0;

int BluetoothData;

void setup()

{

 Genotronex.begin(57600);

  SoftPWMBegin();

  }

void loop()
{

if (Genotronex.available())

   {

      BluetoothData=Genotronex.read();

   if(BluetoothData=='0')

   {

  SoftPWMSet(redPin, 0);

   }

   else if(BluetoothData=='1')
{

    SoftPWMSet(redPin, 20);

   }

}

}

I don't understand why are you using SoftwareSerial on pins where hardware one is available and why are you using SoftPWM when there are six harware PWM pins available. There is also a slight difference between Arduino Uno and Mega. So which one is really used?

Maybe you need to change the class that contains the SoftPWMBegin() or Genotronex.read() methods.
I don't know this library, can you give the link for donwload it and to try it...?

https://www.pjrc.com/teensy/arduino_libraries/SoftPWM.zip  This is the link for downloading SoftPWM library in which you find SoftPWMBegin() function...

Software PWM is quite complex and uses interrupts to emulate PWM using a timer. SoftwareSerial also uses interrupts. You can't have two things happening at once, so one wilk take precedence over the other. In this case the timer interrupt is taking precedence over the Pin Change interrupt, so the reception is delayed, which breaks SoftwareSerial since it relies on a prompt response to the interrupt to work.
You basically have to avoid the use of both software emulations together. Either switch to using the hardware UART, or hardware PWM or, even better, ditch both and go for 100% hardware driven.

source: Stack Exchange

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

sort: votes


text:
Is it possible to run Python embedded in Arduino?
I know how to program in C but I'm more productive in python, so, I would like to know if there is a way to run a python code into arduino.

http://playground.arduino.cc/CommonTopics/PyMite

The whole concept just makes me break out in a cold sweat and rock quietly in the corner...

You can use other kind of board called MicroPython
But yes, is possible using some kind of TX-RX Python class...

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


text:
ESP8266 - How to know if incoming connection is from AP or station network?
I have an ESP8266 module connected with my Arduino configured as a server, with both AP and station modes (AT+CWMODE=3) activated, and I want to know if an incoming connection comes from the AP's network or the station's network. This is the package I'm receiving, and it's exactly the same whether it comes from one or another network:
+IPD,0,437:GET /?uuid=7be547af980d13c5&cmd=10 HTTP/1.1
Host: 192.168.0.222:51813
Connection: keep-alive
Cache-Control: max-age=0
Accept: */*
Origin: http://127.0.0.1:8020
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36
DNT: 1
Referer: http://127.0.0.1:8020/domo_ctrl/www/index.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: es-419,es;q=0.8,en;q=0.6

At first I thought that it would reject packages addressed towards another IP (AP's IP is different from station's IP), but since this IS the gateway, it receives ALL incoming traffic. Please help!
EDIT:
This is the firmware and other stuff shown by AT+GMR:
AT+GMR

AT version:1.1.0.0(May 11 2016 18:09:56)
SDK version:1.5.4(baaeaebb)
Ai-Thinker Technology Co. Ltd.
Jun 13 2016 11:29:20
OK

Which firmware do you have running on your ESP8266?

Hi @RobertoLoGiacco, I edited my question to include firmware info.

I don't think the default AT firmware allows to automatically reject packets because that would probably require a higher degree of control, but looking at the Expressif documentation about the AT command set I've discovered you can actually retrieve the remote address rather than the local one, just by using the same command you were using but with a different parameter
AT+CIPDINFO=1

Not sure though this actually might solve your problem.

This actually solves it! Thx!! It relies on both networks being on separate addresses though, so you can't have both on 192.168.0.0, for example (if you are one to do such things, and I've seen production environments with such network configuration... a complete IP nightmare).

Glad to hear my long shot turned out to be on the spot :-)


text:
Wrong microcontroller found on Arduino Leonardo
When I try to upload a sketch on this brand new Arduino Leonardo, I get this error:
Arduino: 1.6.11 (Linux), Board: "Arduino Leonardo"

Sketch uses 4,134 bytes (14%) of program storage space. Maximum is 28,672 bytes.
Global variables use 148 bytes (5%) of dynamic memory, leaving 2,412 bytes for local variables. Maximum is 2,560 bytes.

avrdude: Expected signature for ATmega32U4 is 1E 95 87
     Double check chip, or use -F to override this check.
Wrong microcontroller found.  Did you select the right board from the Tools > Board menu?

The output of "Get board info" is
BN: Arduino Leonardo
VID: 2A03
PID: 0036
SN: (null)

This is the actual board

And if I shine a very bright light on che microcontroller, take out my glasses and look veeeeeeery close at it, I can read MEGA32U4. So I think that this is an actual Arduino Leonardo.
I downloaded arduino.org IDE. After compiling ncurses5 (...) and making it starts, now i get this error
Arduino: 1.7.10 (Linux), Board: "Arduino Leonardo"

/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /tmp/build6488251228617422525.tmp/sketch_sep16a.cpp -o /tmp/build6488251228617422525.tmp/sketch_sep16a.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/wiring.c -o /tmp/build6488251228617422525.tmp/wiring.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/wiring_digital.c -o /tmp/build6488251228617422525.tmp/wiring_digital.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/wiring_analog.c -o /tmp/build6488251228617422525.tmp/wiring_analog.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/wiring_shift.c -o /tmp/build6488251228617422525.tmp/wiring_shift.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/hooks.c -o /tmp/build6488251228617422525.tmp/hooks.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/WInterrupts.c -o /tmp/build6488251228617422525.tmp/WInterrupts.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-gcc -c -g -Os -w -ffunction-sections -fdata-sections -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/wiring_pulse.c -o /tmp/build6488251228617422525.tmp/wiring_pulse.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/HardwareSerial1.cpp -o /tmp/build6488251228617422525.tmp/HardwareSerial1.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/HardwareSerial0.cpp -o /tmp/build6488251228617422525.tmp/HardwareSerial0.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/USBCore.cpp -o /tmp/build6488251228617422525.tmp/USBCore.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/HardwareSerial2.cpp -o /tmp/build6488251228617422525.tmp/HardwareSerial2.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/main.cpp -o /tmp/build6488251228617422525.tmp/main.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/abi.cpp -o /tmp/build6488251228617422525.tmp/abi.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp -o /tmp/build6488251228617422525.tmp/HardwareSerial.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/HardwareSerial3.cpp -o /tmp/build6488251228617422525.tmp/HardwareSerial3.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/WString.cpp -o /tmp/build6488251228617422525.tmp/WString.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/Stream.cpp -o /tmp/build6488251228617422525.tmp/Stream.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/Print.cpp -o /tmp/build6488251228617422525.tmp/Print.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/CDC.cpp -o /tmp/build6488251228617422525.tmp/CDC.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/Tone.cpp -o /tmp/build6488251228617422525.tmp/Tone.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/HID.cpp -o /tmp/build6488251228617422525.tmp/HID.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/WMath.cpp -o /tmp/build6488251228617422525.tmp/WMath.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/IPAddress.cpp -o /tmp/build6488251228617422525.tmp/IPAddress.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD -mmcu=atmega32u4 -DF_CPU=16000000L -DARDUINO=107010 -DARDUINO_AVR_LEONARDO -DARDUINO_ARCH_AVR -DUSB_VID=0x2a03 -DUSB_PID=0x8036 -DUSB_MANUFACTURER="Unknown" -DUSB_PRODUCT="Arduino Leonardo" -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino -I/home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/variants/leonardo /home/phas/Downloads/arduino-1.7.10-linux64/hardware/arduino/avr/cores/arduino/new.cpp -o /tmp/build6488251228617422525.tmp/new.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/wiring.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/wiring_digital.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/wiring_analog.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/wiring_shift.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/hooks.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/WInterrupts.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/wiring_pulse.c.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/HardwareSerial1.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/HardwareSerial0.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/USBCore.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/HardwareSerial2.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/main.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/abi.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/HardwareSerial.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/HardwareSerial3.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/WString.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/Stream.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/Print.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/CDC.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/Tone.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/HID.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/WMath.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/IPAddress.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-ar rcs /tmp/build6488251228617422525.tmp/core.a /tmp/build6488251228617422525.tmp/new.cpp.o
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-gcc -w -Os -Wl,--gc-sections -mmcu=atmega32u4 -o /tmp/build6488251228617422525.tmp/sketch_sep16a.cpp.elf /tmp/build6488251228617422525.tmp/sketch_sep16a.cpp.o /tmp/build6488251228617422525.tmp/core.a -L/tmp/build6488251228617422525.tmp -lm
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/build6488251228617422525.tmp/sketch_sep16a.cpp.elf /tmp/build6488251228617422525.tmp/sketch_sep16a.cpp.eep
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avr-objcopy -O ihex -R .eeprom /tmp/build6488251228617422525.tmp/sketch_sep16a.cpp.elf /tmp/build6488251228617422525.tmp/sketch_sep16a.cpp.hex

Sketch uses 4,252 bytes (14%) of program storage space. Maximum is 28,672 bytes.
Global variables use 151 bytes (5%) of dynamic memory, leaving 2,409 bytes for local variables. Maximum is 2,560 bytes.
Forcing reset using 1200bps open/close on port /dev/ttyACM0
PORTS {/dev/ttyACM0, /dev/ttyS0, } / {/dev/ttyACM0, /dev/ttyS0, } => {}
PORTS {/dev/ttyACM0, /dev/ttyS0, } / {/dev/ttyACM0, /dev/ttyS0, } => {}
Uploading using selected port: /dev/ttyACM0
/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/bin/avrdude -C/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/etc/avrdude.conf -v -patmega32u4 -cavr109 -P/dev/ttyACM0 -b57600 -D -Uflash:w:/tmp/build6488251228617422525.tmp/sketch_sep16a.cpp.hex:i

avrdude: Version 6.0.1, compiled on Jan 15 2015 at 13:12:29
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/home/phas/Downloads/arduino-1.7.10-linux64/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/home/phas/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/ttyACM0
         Using Programmer              : avr109
         Overriding Baud Rate          : 57600
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  9000  9000 0x00 0x00
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0x00 0x00
           lfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           lock           0     0     0    0 no          1    0      0  9000  9000 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : butterfly
         Description     : Atmel AppNote AVR109 Boot Loader

Connecting to programmer: .avrdude: butterfly_recv(): programmer is not responding
Problem uploading to board.  See http://www.arduino.cc/en/Guide/Troubleshooting#upload for suggestions.

Might be an Arduino cc vs org kind of thing in the IDE. Check using the IDE from org.

I don't think CC make the Leonardo any more (yes, looking at the site it is "retired"). So it must be a .org board. Maybe you have the wrong programmer selected?

Enable verbose output in the Arduino settings to get a more elaborate error message.

Personally I'd pick the chipKIT Lenny over the Leonardo any day ;)

@MikaelPatel might it be the opposite?

Just by looking at the picture, the silkscreen on the board clearly states ARDUINO.ORG.
It is possible you need to download the IDE from arduino.org (they have their own stupid fork).

Uninstall the modem-manager package in Linux.

@Majenko did that, didn't work. Same error.

@RiccardoCagnasso Damn, worth a try. You might like to check through this and see if there is anything else that may help: https://hackingmajenkoblog.wordpress.com/2016/08/24/diagnosing-arduino-problems-in-linux/

@Majenko nope, nothing useful there. I thoght it would be a permissions problem but nope. I will try it on windows to narrow it down.

I went on windows, i used the arduino.org IDE to flash "Blink" on it and it worked. And them BAM it started working on linux with android.cc IDE.
My knowledge of arduino's internals is limited, but I guess that there was "something" wrong that was overwritten flashing the sketch.
If someone want to elaborate a proper answer from this ...

Since no one has elaborated a better answer: if something like this happens, try to install arduino.org IDE on windows, connect the leonardo and flash a firmware. It should then start to work on any OS.


text:
Is it possible to charge a battery using a water flow sensor?
Is it possible to use a water flow sensor to charge a battery? Since the water flow sensor measures water flow using pulses, could I charge a battery using these pulses(instead of using it to read water flow).
Heres an example of the product?
https://netram.co.za/1200-g-12-water-flow-sensor-13mm.html
Thank you

Is it possible to charge a battery using a water flow sensor?

No, it is basically a hall-effect sensor that requires power and generates a low effect pulse.
Look for a generator. Something like this; https://netram.co.za/1199-36v-micro-hydro-generator.html
Cheers!

Thanks so much Mikael.  This helps me a great deal!  Especially that you went through the effort on showing me on the site I used.


text:
Arduino Due works perfectly on Windows but doesn't on Linux (SAM-BA operation failed)
I've been working with the Arduino Due for a project, we have been setting up these Arduinos with an ARM Board that hosts a Linux System with Busybox that connects to the Arduino. Recently I got assigned the job of making it possible for the Arduino Due to be updated with the new code remotely so we don't have to travel to each location every time we need to update anything.
At first it seemed easy, crosscompile bossac for Arduino Due and use it in the ARM Linux Board, needing to open the port at 1200 bauds so the Arduino is available for a new upload.
The problem is, i've tested bossac and it works perfectly on Windows same as the Arduino IDE, it always uploads the sketch without a single problem. On Linux, however it doesn't seem to be working properly, not even the full Arduino IDE in AMD64, we have already tested it in 2 Vbox with Linux and in 2 native Linux installations, testing 32b and 64b, ARM and x86, i've tested everything I've seen on the web: up the permissions, add the user to the dialout group, reset the board manually...
I'm sure i'm missing something stupid but I don't know what and it's driving me crazy because the Arduino IDE is supposed to work properly on Linux. Just in case, these are the steps I've followed:

Download the latest version of the Arduino Due, untar it and sudo ./install.sh
Add my user to the dialout group, and log out.
In the Arduino IDE go to the Board Manager and install the SAM support for Arduino Due
Select Arduino Due (programming port) and /dev/ttyACM0
Upload any sketch (also tried with example sketches), it compiles but when uploading the next message appears

SAM-BA operation failed

And if using the verbose output this always happens after the next output,it seems to fail the last write and tries to overwrite it again (this is not the full output, there are writes and reads before this)
Chip ID      : 285e0a60
version()=v1.1 Dec 15 2010 19:25:04
Version      : v1.1 Dec 15 2010 19:25:04
Address      : 524288
Pages        : 2048
Page Size    : 256 bytes
Total Size   : 512KB
Planes       : 2
Lock Regions : 32
Locked       : readWord(addr=0x400e0a08)=0x1
readWord(addr=0x400e0c08)=0x1
writeWord(addr=0x400e0a04,value=0x5a00000a)
readWord(addr=0x400e0a08)=0x1
readWord(addr=0x400e0c08)=0x1
readWord(addr=0x400e0a0c)=0
readWord(addr=0x400e0a08)=0x1
readWord(addr=0x400e0c08)=0x1
writeWord(addr=0x400e0a04,value=0x5a00000a)
readWord(addr=0x400e0a08)=0x1
readWord(addr=0x400e0c08)=0x1

Almost every time it crashes it's like that but sometimes it even starts uploading and showing the percentage of upload but again "SAM-BA operation failed" before finishing the upload.
What irks me is that in Windows it works flawlessly so the board is all good and even compiling bossac from the sources produces the same error in Linux, I've also tested an Arduino Duemilanove and it works perfectly on Linux however it uses avr, not bossac. As i've said i've tested it in 4 machines and it's always the same, even in the ARM version.
What is it that I'm missing?
Thanks in advance.

Uninstall the modem-manager package from Linux.

Tried it doing apt-get purge modemmanager and still no luck, it keeps saying SAM-BA operation failed, I have also tested it on a new Due and the same thing happens.


text:
Use an electromagnet for reading induction as well
I have an electromagnet that I wish to use to pull a neodyne magnet closer.
I'm thinking of having the electromagnet sensing when the magnet is close, but when the magnet is running I'm pushing 12 volts through it and I don't want to fry my Arduino. How can I do the wiring to achieve this?
I only have to be able to use the magnet as a sensor while it's turned off.

You could drive the electromagnet with 12 V and at the same time read back the current through a small shunt resistor.

Just add a resistor an a clamping diode to the analog pin. That way overcoat age can't damage the Arduino pin.

You can use a hall sensor from an old computer fan.
If the magnet is not moving you are not going to be able to sense it with the coil of your electromagnet.
You can also decouple de input of your arduino with a cap in series with the coil, but again if the magnet is not fast enough you will have to use a bigger cap.
You can also make a voltage divider between your coil and sense from there. When the 12V are applied just add some code to offset the input signal.


text:
ISR halts in DUE
I am using the following simple code to test the interrupt functionality of due:
void aMillion(){
    for(int i = 0; i < 1000000; i++){
        if(i % 1000 == 0){
            Serial.print("m");
        }
    }
}

void setup(){
  Serial.begin(9600);
  pinMode(2, INPUT);
  attachInterrupt(digitalPinToInterrupt(2), aMillion, CHANGE);
}
void loop()
{
}

obviously what we expect to see is a thousand "m" characters after each interrupt event. On Arduino Mega, this worked fine. But I have tested it on multiple Due boards.
Very odd news is that on the reset event of due, I do get a single "m" character printed.

Just a thought, check http://arduino.stackexchange.com/questions/23006/digitalpintointerrupt-doesnt-work

Doing a lot of stuff inside the ISR isn't advised. Especially if you are doing serial communication. What happens if you do just a single serial.print?

I am surprised this could ever work on the Mega. The test i < 1000000 is always true due to the limited range of int type. And you get undefined behavior when i overflows.

@EdgarBonet haha yea, but an automatic cast during the comparison would make the loop run forever. wouldn't it? That's what I saw with MEGA

I don't understand your comment. Could you be more explicit? I just compiled aMillion() for AVR and got “warning: comparison is always true due to limited range of data type”. And gcc optimized out the test i < 1000000. The generated assembly is just an infinite loop.

@EdgarBonet I guessed that it might have been cast to 'long' automatically. But apparently that is not what happens. In any case you are right and this is an infinite loop.

@EdgarBonet Initially I had extra delays in the loop, So I never reached a thousand output characters. That is why I did not notice this in the beginning.

thanks @Jesse but that link was a totally different issue. That was a Pin mismatch.

as @EdgarBonet and Gerben pointed out, It is not possible to have very long ISRs in the DUE. For the MEGA however, an infinite loop including anything, will be executed with no problem. that is why the infinite loop ran a good time in the MEGA. I will post this as the answer

An attempt to run long loops in the ISR for the DUE fails. This is the result of some sort of a run time monitoring system. An infinite loop like this one here, or even a loop with a thousand repetitions of a Serial Print will result in an early halt of ISR on the DUE.
On the MEGA however, This is not the case. ISRs can run much longer. (At least ten minutes as I tried)


text:
Problems with Ultrasonic Sensor
I want to check my understanding on how to use digitalWrite for 5V and Grd and why this code isn't working.
This is for the Makeblock sensor
Consider the image here which says to plugin a wire to 5V, Grd and a signal pin.
My code does the following
#define h  22
#define l  24
#define sig 26

void setup() {
   Serial.begin(9600);
   pinModde(h, OUTPUT);
   pindMode(l, OUPUT);
   pinMode(sig, OUPUT);

   digitalWrite(h, HIGH);
   digitalWrite(l, LOW);
}

void loop() {
   digitalWrite(sig, LOW);
   delayMicroseconds(2);
   digitalWrite(sig, HIGH);
   delayMicroseconds(10);
   digitalWrite(sig, LOW);
   pinMode(sig, INPUT);
   long duration = pulseIn(sig, HIGH, 38000);
   delay(2500);
}

When I run this code duration is always 0.  If I unplug 22 and 24 and use the board's 5V and Grd I get duration is 30001 no matter how far away an object is from the sensor.  Meaning it's not sensing anything, just returning this number.
Full disclosure that I'm using solder-less wires but I don't that would make this much of a difference?
So to summarize: why are 22 and 24 resulting in a 0 readout and not acting as 5V and Grd?  My only thought is maybe too much voltage and a resister is needed?
Secondly: why is the sensor not working even when using 5V and Grd pins?

You've set pinMode(sig,INPUT); and never changed this back to OUTPUT before triggering next measure:
void loop() {
   pinMode(sig, OUTPUT);    // ensure sig is configured as an output
   digitalWrite(sig, LOW);
   delayMicroseconds(2);
   digitalWrite(sig, HIGH);
   delayMicroseconds(10);
   digitalWrite(sig, LOW);
   pinMode(sig, INPUT);
   long duration = pulseIn(sig, HIGH, 38000);
   delay(2500);
}

And for example PING))) (which is basically the same module) has power consumption about 30mA-35mA in datasheet. Output pin might be strong enough to power it, but I'd recommend at least GND connect directly to arduino GND. And using transistor for powering it up would be even better


text:
Making three led's blink at different times in Arduino
I have a breadboard connected to an Arduino Uno, 220k resistors connected to an led, of course it has a common ground and a pin connected to 5v. All pins are digital.
Now, I want led 1 to turn on for one second, the next led for two seconds and the next for three seconds, but that means, when the second led which has to be on for two seconds then the first led will come back on after one second has past on the second led, the third led would be on for three seconds, so the second led will also be on when two seconds pass and the first would be on when one second passes. So basically, all leds are on for their given duration.
How do I do this? I have been trying to do this since three days. It would be a pleasure if someone helps me out. Thanks.
int ledPin1= 2;
int ledPin2 = 4;
int ledPin3 = 7;

void setup(){
  pinMode(ledPin1, OUTPUT);
  pinMode(ledPin2, OUTPUT);
  pinMode(ledPin3, OUTPUT);
  }

  void loop(){
  digitalWrite(ledPin1, HIGH);
  delay(500);
  digitalWrite(ledPin1, LOW);
  delay(500);

  digitalWrite(ledPin2, HIGH);
  delay(1000);
  digitalWrite(ledPin2, LOW);
  delay(1000);

  digitalWrite(ledPin3, HIGH);
  delay(1500);
  digitalWrite(ledPin3, LOW);
  delay(1500);
    }

So far this is the code. But it delays the whole program. Need leds on at given times.

What exactly is not working ? can you post the code you have tried so far ? Are you able to light On at least one LED ? (220k resistor seems much to me, usually it's somethink arround 330Ohm depending on the choosen LED)

Sorry 220 ohms, sorry my mind was somewhere else, yes I can switch on LED's and stuff but I need it in this pattern

Using a 220k Ohm resistor will lead to approximatively 20µA to light the LED. This is not enough to light the LED, you should replace the resitor by one of value 330Ohm (220 to 470 could be OK depending of the LED)

Sorry, the resistor is 220ohms,

Seems like you want a pattern like this ?
LED1 : 1 0 1 0 1 0 1 0 1 0 1 0 ... repeat
LED2 : 1 1 0 0 1 1 0 0 1 1 0 0 ... repeat
LED3 : 1 1 1 0 0 0 1 1 1 0 0 0 ... repeat

In which case you'll need something like this pseudo code
// set up the relevant pins as output etc
....
// set up a counter
counter = 0

loop
  toggle LED1
  if (counter modulo 2 == 0) then toggle LED2
  if (counter modulo 3 == 0) then toggle LED3

  counter++
  if counter > 11 then counter = 0 // your pattern repeats every 12 seconds

  delay for 1 second

Toggling the LED is just a case of checking if it is high or low and setting it to the opposite value.


text:
ISO C++ forbids taking the address of an unqualified or parenthesized non-static member function to form a pointer to member function
This question comes on the heels of this question
In the last question I learned how to use an initializer list to solve my issue, but working with ros::Subscriber is requiring a different solution.
I'm dealing with a callback in this scenario. If I leave the callback as a standalone function then the program runs but I have no access to class members and methods inside the function which defeats the purpose. Here is my standalone callback:
void setPRYCallback( const std_msgs::Empty& toggle_msg) {}

Once I move this into my class is when I encounter the error.
steps to implementing into class
// add member variable for callback
protected:
  void setPRYCallback( const std_msgs::Empty& );

...

// ass method
void ROSController::setPRYCallback( const std_msgs::Empty& toggle_msg) {}

...

// set initializer list
ROSController::ROSController() : sub("setPRY", &setPRYCallback )

How do I thwart this error while keeping my callback as a class method?
Program with Standalone Function Callback (program runs)
#include <ros.h> // https://github.com/ros-drivers/rosserial/blob/jade-devel/rosserial_arduino/src/ros_lib/ros.h
#include <std_msgs/Empty.h>

class ROSController {
  protected:
    ros::Subscriber<std_msgs::Empty> sub;
    ros::NodeHandle _nh;
  public:
    void loop();
    ROSController();
};

void setPRYCallback( const std_msgs::Empty& toggle_msg) {}

ROSController::ROSController()  {
  this->_nh.initNode();
  this->_nh.subscribe(sub);
}

void ROSController::loop() {
  this->_nh.spinOnce();
  delay(1000);
}

Program with Method Callback (program fails)
#include <ros.h> // https://github.com/ros-drivers/rosserial/blob/jade-devel/rosserial_arduino/src/ros_lib/ros.h
#include <std_msgs/Empty.h>

class ROSController {
  protected:
    ros::Subscriber<std_msgs::Empty> sub;
    ros::NodeHandle _nh;
    void setPRYCallback( const std_msgs::Empty& );
  public:
    void loop();
    ROSController();
};

void ROSController::setPRYCallback( const std_msgs::Empty& toggle_msg) {}

ROSController::ROSController() : sub("setPRY", &setPRYCallback )  {
  this->_nh.initNode();
  this->_nh.subscribe(sub);
}

void ROSController::loop() {
  this->_nh.spinOnce();
  delay(1000);
}

arduino mega

Is there somewhere we can see this "ros.h" library you are using?

This will do the trick: https://github.com/NimbRo/nimbro-op-ros/blob/master/src/nimbro/contrib/roscpp/include/ros/ros.h

Start by making "setPRYCallback" static.

When you move the setPRUCallback function into your class you change the prototype (well, C++ changes the prototype) from:
void setPRYCallback( const std_msgs::Empty& toggle_msg) {}

to:
void setPRYCallback( ROSController *this, const std_msgs::Empty& toggle_msg) {}

That is now not what the callback registering function expects, and so it breaks.
By making the method static it removes that *this parameter, but also means that the function can only access static data within your class (variables also marked static) and there is only one copy of the function (and static variables) shared between all instances of the class (maybe not what you want).

If you define instance as a global value, how about to set callback with using lambda expression as variable of constructor.
#include <ros.h>
#include <std_msgs/Empty.h>

class ROSController {
  protected:
    ros::Subscriber<std_msgs::Empty> sub;
    ros::NodeHandle nh;
  public:
    ROSController(void (*staticPRYCallback)(const std_msgs::Empty& msg));
    void begin();
    void loop();
    void setPRYCallback( const std_msgs::Empty& );
};

void ROSController::setPRYCallback(const std_msgs::Empty& toggle_msg) {}

ROSController::ROSController(void (*staticPRYCallback)(const std_msgs::Empty& msg))
  : sub("setPRY", staticPRYCallback )  {
}

void ROSController::begin() {
  nh.initNode();
  nh.subscribe(sub);
}

void ROSController::loop() {
  nh.spinOnce();
}

ROSController rosController([](const std_msgs::Empty& msg){
  rosController.setPRYCallback(msg);
});

void setup() {
  rosController.begin();
}

void loop() {
  rosController.loop();
  delay(1000);
}

Reference (A post of my blog in Japanese)
https://asukiaaa.blogspot.com/2020/09/define-cpp-callback-for-class-value-with-using-lambda-as-a-variable.html

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


text:
Water level Detection using Ultrasonic Sensor and arduino
I'm making a water level detector to control my motor which supplies water in water tank and for that I'm going to use ultrasonic sensor to be attached to tank lid. My question is whether the vapor arising from water inside the tank hamper the overall working of ultrasonic sensor and/or it may be damaged permanently. I can cover complete ultrasonic sensor using hot glue stick but cannot cover its diaphragm as it will block sound waves. Please suggest something.

You may be able to find a data sheet for the usual in-air transducers giving humidity limits.  You will not be able to seal them yourself without making them not work.  Sealed ones do exist for vehicle parking systems, but require different electronics.  Also beware minimum distances.

For fluid level measurement you are best off using a capacitive fluid level sensor.

I'm not sure if there is even an issue here. But you could try out different types of plastic bags, to see which are "transparent" to ultrasonic sound. Alternatively, just replacing the sensor every one or two year, wouldn't be that bad. Just make sure that your code accounts for a bad sensor (e.g. turn of the pump after 10 minutes regardless of the water level).

Plastic bag shields will not pass enough signal for the common sensors.

I am posting an answer just because I do not have enough reputation in order to comment. This is not a straight answer but more like a workaround. Have you tried using the system from a toilet water tank? also, you could put a floating magnet inside the tank (and limit its x-y movement) and a reed switch (or more) outside of the tank at the desired levels. Another idea (not sure of it works, depends on the water quantity) is to place a barometer on the bottom of the tank and measure the pressure.

Majenko, agreed.
Use some FM antenna cable, if you can find it. Insulate the lower end by dipping in molten heat glue.
Two rods, insulated with heat shrink tubing also works well.
Use LM393 dual comparator as Schmitt trigger and inverter. That will oscillate at  frequency dependant on the water level. Works well, recalibrate or clean the sensor when accuracy suffers due to being too dirty. should not be necessary more than annually.

A friend of mine worked on a liquid level monitoring project, and after many iterations finally abandoned the kinds of sensors you're talking about. Ultimately he just pointed a cheap USB webcam at the thing and used OpenCV and the edge detection algorithm to find the level of the water.  Then it's just a matter of doing some math using the dimensions of the container, to figure out how full it is.
If you are using a clear container and if you have the option of using a Raspberry Pi (or a PC, whatever) that can run OpenCV, you might find that option worth exploring.

Sensors exist for exactly your use case. Here is an example;
Maxbotix MB7589 Ultrasonic Sensor
I have used several of these to measure river levels. they are virtually indestructible and have all the features that you would expect;

Temperature compensation
Self heating to deal with humidity/condensation
serial output
1mm resolution

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


text:
Sending IR via a wire
So i have taken apart this old remote i found, and removed the IR-LED and replaced it with wires.
I thought that i would just be able to put the wire that used to go to the positive side of the IR-LED, to a pin on my Arduino UNO (and negative to GND), and just use the same IR decoding library to decode the signal, as if it was from an IR sensor.
But as it turns out, i receive undecipherable nonsense (or so it seems), like 5+ different codes from pressing the same button on the remote.
If i connect the 2 pins from the remote to the IR-LED on my breadboard, and an IR receiver to my Arduino i receive the signal you would expect, which in my case is "24137D" in HEX (1 on the remote) every time.
So my question is: Why does this happen and is it even possible to do what i am trying to do. Why? Why not? And if possible how is this done?
Here is the code i am using:
#include <IRremote.h> //https://github.com/z3t0/Arduino-IRremote

#define IR_Pin 7

IRrecv irrecv(IR_Pin);
decode_results results;

void setup() {
  Serial.begin(9600);
  pinMode(IR_Pin, INPUT);
  irrecv.enableIRIn();

}

void loop() {
    if(irrecv.decode(&results)) {
    Serial.println(results.value, HEX);
    irrecv.resume();
  }

}

Maybe the answer is obvious and i just don't understand how IR works. If so feel free to link some documentation that can help me.
Thank you.

Do you have a 3-pin IR receiver?

@Majenko Yes i do (VS18388)

Your IR receiver is decoding the high frequency pulsed On-Off-Keying waveform for you. The Arduino doesn't do that.
An IR signal consists of high frequency (say 36KHz) on-off light pulsed at a lower (data) frequency (different combinations to make 1 and 0)

The receiver you have takes that high frequency signal, amplifies it, filters it, and gives you just the resulting 1 and 0 signals. From that the Arduino can use simple time measurements to work out the code.
Without the filtering that the receiver provides the Arduino will have to do all that work by itself - and while that may be technically possible, it's seldom done. You may be able to find a library that can do it, but it's unlikely.

Thank you for the quick response. Is there a fixed timing that i could simply implement like eg. delay(10) digitalRead(IR_Pin) //Repeat x times  and so on?

No. You would need to implement a system that triggered an interrupt on every rising edge, count the microseconds between each triggering, work out which is the leading and falling pulses of each block, and calculate the times between them all.


text:
In-application programming for the Arduino Uno
I would like to know if it is possible to read from and write to the microcontroller's (Arduino Uno's ATmega328P) flash memory using a program or "bootloader" previously stored in the flash memory (or the EEPROM memory) itself.
If it is possible, can it be done using the Arduino IDE?

It is possible to read/write/verify data involving Flash or EEPROM storage by way of the ISP hardware interface.  I am not sufficiently familiar with the Arduino IDE but these operations are available in other tools such as Atmel Studio or AVRDude by using the "AVRISP MKII" device (or later).

@Wossname. Is it possible to separately access the ATmega328P on an Arduino so as to use the tools you have mentioned?

There will be a 6-pin header near to the 328P which will allow direct programming of the chip, but be careful not to set any fuses that will prevent future access.  Post a photo of your board (there are many variants of arduinos in the wild, and they are all different!).

@Wossname. My Arduino Uno board is the same as the image at this link: http://d2rormqr1qwzpz.cloudfront.net/photos/2013/06/12/48912-arduinouno_r3_front.jpg

The "ICSP" connector on the right side is in direct connection with the 328P.  Power up the main board with 5V and you will be able to program the chip directly through the AVRISP/BusPirate/3rd party programmer.


text:
Serial Communication Not Receiving Entire String
I have an Arduino connected to a pico motor driver that is supposed to take a number of steps for a specific number of triggers that gets from a source (i.e. waveform generator). I've setup the code so that it would ask the user to input number of steps and number of triggers. For example, if I want the motor to take 10 steps once it got 60 triggers, I should input s10; and t60; separately into Serial Monitor.
In addition, I want to be able to change the number of steps and triggers any time that I want. However the problem is that sometimes Arduino doesn't receive the input string entirely for the first time. Sometimes it works on the second try. Or even not at all. I really appreciate if someone can give a hint on why this is happening.
This is a simple version of the code (without the parts that move the motor):
#include<String.h>

long int steps;
long int num_triggers;
long int newtrigger;
long int newstep;
long int oldtrigger;
long int oldstep;

const int main_control = 0;
int triggers_count;
bool motor_trigger = true;

void setup() {

 Serial.begin(19200);
 Serial.println("Please enter chosen number of steps and triggers.");
 Serial.println("Example: \n If you want the pico-motor to take 10 steps per 40 triggers,");
 Serial.println(" write 's10;' and press enter then do the same for 't45;'(Order doesn't matter).");
}

void loop() {

  while (num_triggers == 0 || steps == 0) {

    getcommand(&steps, &num_triggers);

  }

  attachInterrupt(main_control, trigger, RISING);  // it starts looking for trigger

  if (motor_trigger == false) {

    getcommand(&steps, &num_triggers);
  }

  else if (motor_trigger == true) {

    motor_trigger = false;
    detachInterrupt(main_control);

    if (triggers_count <= (num_triggers - 1)) {

      getcommand(&steps, &num_triggers);

    }

    else {

      for (int i = 0; i < steps; i++) {

        oldstep = steps;
        oldtrigger = num_triggers;
        getcommand(&steps, &num_triggers);

        if (  num_triggers != oldtrigger || steps != oldstep) {
          break;
        }
      }
    }
  }
}

void trigger(void) {

  motor_trigger = true;
  triggers_count++;
}

void getcommand (long int *newstep, long int *newtrigger) {

    char   char_input;
    String string_input;
    String output_1;
    String output_2;

  while (Serial.available()) {

    char_input = Serial.read();
      if (char_input == ';'){
    Serial.println("done");

      }
      else{
    string_input += char_input;
    delay(500);
    }
  }

  Serial.println("Getting input...");
  Serial.println(string_input);
  Serial.println("Input printed.");

  int inputlen = string_input.length();
  output_1 = string_input[0];

    for ( int i = 1; i < inputlen; i++ ) {
      output_2 += string_input[i];
    }

      if ( output_2.toInt()<=0 && inputlen>0 ){   // check if there's an error

        Serial.println("Error with input number");
        delay(5000);
        Serial.println("Reading the input string");
        Serial.println(Serial.readString());
        Serial.println("Done reading the input string");
        }

    if (output_1 == "s") {

      *newstep = output_2.toInt();

    }

    else if (output_1 == "t") {

      *newtrigger = output_2.toInt();
    }

  }

Edits must not change literal details of command codes which the program is looking for; also, editing just to insert a comma or optional definite article is merely a waste of everyone's time and attention.

I can see several issues:

If the Serial buffer contains more than one command already, you'll read it too. For example serial buffer contains "s43;t25;" and  the input_string would be something like "s43t25". This is highly to happen if you send those characters in less than 3seconds (as you have delay(500) for each appended character). You have to stop reading from buffer if you detect ';'.
Parsing of commands is also pretty weird. You are blocking for some time, so you can detect 's'/'t' and then use Serial.parseInt(); with Serial.setTimeout(1000); to do similar but much faster get command.
Variables set inside of ISR (function trigger is called from ISR) must be volatile. Otherwise it might be optimized out or into register by compiler.

Anyway, if you want to read whole commands try the serialEvent() example. Just change checking for '\n' to ';' and then you can parse that command in your way when it's complete.


text:
Making three LED's blink at given times
I have a breadboard connected to an Arduino Uno, 220k resistors connected to an led, of course it has a common ground and a pin connected to 5v. All pins are digital.
Now, I want led 1 to turn on for one second, the next led for two seconds and the next for three seconds, but that means, when the second led which has to be on for two seconds then the first led will come back on after one second has past on the second led, the third led would be on for three seconds, so the second led will also be on when two seconds pass and the first would be on when one second passes. So basically, all leds are on for their given duration.
How do I do this? I have been trying to do this since three days. It would be a pleasure if someone helps me out. Thanks.
int ledPin1= 2;
int ledPin2 = 4;
int ledPin3 = 7;

void setup(){
  pinMode(ledPin1, OUTPUT);
  pinMode(ledPin2, OUTPUT);
  pinMode(ledPin3, OUTPUT);
  }

  void loop(){
  digitalWrite(ledPin1, HIGH);
  delay(500);
  digitalWrite(ledPin1, LOW);
  delay(500);

  digitalWrite(ledPin2, HIGH);
  delay(1000);
  digitalWrite(ledPin2, LOW);
  delay(1000);

  digitalWrite(ledPin3, HIGH);
  delay(1500);
  digitalWrite(ledPin3, LOW);
  delay(1500);
    }

So far this is the code. But it delays the whole program. Need leds on at given times.

You could start by drawing a time graph, like this:
LED 1   # # # # # # # # # # # # # # # # # #
LED 2    ##  ##  ##  ##  ##  ##  ##  ##  ##
LED 3      ###   ###   ###   ###   ###   ###
        <-period 1-><-period 2-><-period 3->

As you see on the graph, the whole sequence repeats itself every
12 seconds. Then, you can just write down all the pin toggles for
12 seconds and let the loop repeat itself:
void loop() {
    digitalWrite(ledPin1, HIGH);
    digitalWrite(ledPin3, LOW);
    delay(1000);
    digitalWrite(ledPin1, LOW);
    digitalWrite(ledPin2, HIGH);
    delay(1000);
    digitalWrite(ledPin1, HIGH);
    delay(1000);
    digitalWrite(ledPin1, LOW);
    digitalWrite(ledPin2, LOW);
    digitalWrite(ledPin3, HIGH);
    delay(1000);
    digitalWrite(ledPin1, HIGH);
    delay(1000);
    digitalWrite(ledPin1, LOW);
    digitalWrite(ledPin2, HIGH);
    delay(1000);
    digitalWrite(ledPin1, HIGH);
    digitalWrite(ledPin3, LOW);
    delay(1000);
    digitalWrite(ledPin1, LOW);
    digitalWrite(ledPin2, LOW);
    delay(1000);
    digitalWrite(ledPin1, HIGH);
    delay(1000);
    digitalWrite(ledPin1, LOW);
    digitalWrite(ledPin2, HIGH);
    digitalWrite(ledPin3, HIGH);
    delay(1000);
    digitalWrite(ledPin1, HIGH);
    delay(1000);
    digitalWrite(ledPin1, LOW);
    digitalWrite(ledPin2, LOW);
    delay(1000);
}

This was the simple, albeit tedious solution.
The smart solution is to go through the Blink Without Delay Arduino
tutorial. You will see that, once you start using millis() instead of
delay() for managing your timings, blinking three LEDs instead of one
is completely trivial.

EDIT: I just love Finit State Machines and templates to do some simple tasks:
class FSM {
  public:
    using Handler = void(*)(FSM &);

    FSM(Handler hnd) : m_func{hnd} {}

    void check(uint32_t ts = millis()) {
      if (m_next < ts) {
        m_func(*this);
      }
    }

    void delay(uint32_t _delay) {
      m_next += _delay;
    }

    void nextState(uint8_t state) {
      m_state = state;
    }

    uint8_t state() { return m_state; }

  protected:
    Handler   m_func;
    uint8_t  m_state = 0;
    uint32_t  m_next = 0;
};

template <uint8_t PIN, uint32_t HIGH_DELAY, uint32_t LOW_DELAY> void pin_fsm(FSM & fsm) {
  switch (fsm.state()) {
    case 0:
      pinMode(PIN, OUTPUT);
      // fall through
    case 1:
      digitalWrite(PIN, HIGH);
      fsm.delay(HIGH_DELAY);
      fsm.nextState(2);
      break;
    case 2:
      digitalWrite(PIN, LOW);
      fsm.delay(LOW_DELAY);
      fsm.nextState(1);
      break;
  }
}

FSM fsms[] = {{&pin_fsm<2,500,500>}, {&pin_fsm<4,1000,1000>}, {&pin_fsm<7,1500,1500>}};

void setup() {

}

void loop() {
  auto ts = millis();
  for (FSM& fsm : fsms) fsm.check(ts);
  delay(1);
}

The code should be working, so as mentioned before in that duplicate thread, 220k is far bigger than it should be. So just use 220R (= 220 Ohms) instead of 220k Ohms (= 220000 Ohms).
And if it's not working even with correct resistor, your LED is connected in reversed direction. Try the builtin LED on pin 13. That one must be working. Anyway you should read something about LEDs.

How about this? Basically each loop is 1sec, and each LED has it's own counter which increases. If the counter is higher than the LED number/onTime, the LED is off for that loop and the conter reset, otherwise LED is on.
uint8_t LED[3] = { 2, 4, 7 };
uint8_t LED_COUNTER[3] = { 0, 0, 0 };

void setup() {
  for (int i = 0; i < 3; i++) {
    pinMode(LED[i], OUTPUT);
  }
}

void loop() {
  for (int i = 0; i < 3; i++) {
    if (LED_COUNT[i] = i) { LED_COUNT[i] = 0; }
    else {
      digitalWrite(LED[i], 1);
      LED_COUNT[i] += 1;
    }
  }
  delay(1000);
}

You are never switching the LEDs off.

There is a problem with the led count

Yes sorry it was mainly intended to explain the concept, I didn't go much in detail. Either way I see on the duplicate of this question there is a far better solution...


text:
ATtiny serial.print() crash with INTs
I'm trying to print some data to and from an ATtiny85 via serial, using the SoftwareSerial library.  So far I've tried these setups with no results:

1/8MHz clock
baud rates from 9600 to 57600 (library doesn't seem to support higher rates)
printing to a newline or a single one
packing up a char array just as much as a String and then printing it
Txing/Rxing through an Arduino Nano/Uno/Mega or a cheap USB-Serial port

Reading up on the subject seemed to suggest that some values I was passing (such as '1000') might have been erroneously interpreted as EOL characters breaking the code, but attempts with different values (i.e. 845) returned the same failures.
As you might have guessed I'm writing code with the ArduinoIDE, and no errors are returned when compiling and uploading. Many other parts of the project involving serial work just fine, and I can communicate with the ATtiny on pretty much any of the above setups (actually packing up the String or char[] crash the whole thing).
The 'Ready' at the end of the setup is also printed fine, and the loop runs as long as it won't encounter any of the above issues.
Here's the code:
int VALUE = 1000;
int ANOTHER = 12;

#include <SoftwareSerial.h>
SoftwareSerial tSerial(3,4);

void _serialEvent() {
  if (tSerial.available()) {
    char mode = tSerial.read();
    if (mode == '?') {
      tSerial.println("someTextHere 1.23moreText");
      tSerial.print("value:");
      tSerial.print(VALUE);
      tSerial.print(";another:");
      tSerial.println(ANOTHER);
    }
    else if ...
  }
}

void setup() {
  tSerial.begin(57600);
  ...
  tSerial.println("Ready");
}

void loop() {
  ...
  _serialEvent();
}

Try to use F() macro to use string literals directly from flash. They must be copied into the RAM as they are now. Usage: tSerial.print(F("whatever you want")); and i saves lot of RAM.

ok that did it. can you please explain a bit more (a simple link to documentation will suffice) and set this as answer so I can accept it?

1/8 MHz is a little slow for using SoftwareSerial. I would rather clock it at 8 MHz.

Yes that's what I ended up doing, still that wasn't the cause.

It is much better to store string literals in the FLASH only. In Arduino there is __FlashStringHelper class and F() macro ensures that correct version of print method is used and that the string literal is not copied into the ram before it's printed.
Basically if you don't have enough memory, using lots of string literals results in stack overflows, coruption and/or returning to random adresses and it looks like crashes/resets.

Extremely helpful insight, thank you! This actually led to solve a couple other glitches I've been experiencing without understanding them. I was wondering if there is any tool available to debug this kind of situation?

You might want to read this article (https://learn.adafruit.com/memories-of-an-arduino/measuring-free-memory) reporting a quite clear explanation of typical micros memory usage, along with some advices to debug related problems


text:
Motor running slowly when connected to digital pins, but fine with 5V pins
I am trying to connect a Dagu DG01D motor to my Arduino Uno. First I tried connecting the black wire to GND and the red wire to digital pin 7. My code:
void setup() {
  pinMode(7, OUTPUT);
  digitalWrite(7, HIGH);
}

void loop() {
}

When I connected the motor, it wouldn't turn, but would rotate a little when turned in one direction. However, when I connected the red wire to 3.3V or 5V, the motor turned quickly as expected. Why didn't writing HIGH to pin 7 work?
I already verified that I can connect and run code on the Arduino by turning on the LED by replacing pin 7 with 13. I also tried running the same code on a SparkFun RedBoard, with similar results.

An Arduino pin can only supply an absolute maximum of 40mA of current (20mA is recommended). As Ignacio said, your motor requires around 190mA. Use a transistor, to increase the current capability.

No Load Current: 190mA (250mA MAX)

You're not getting that out of a ATmega328P GPIO. Use a driver instead.


text:
Sending textual and nontextual data simultaneously across a serial port
I am currently using an Arduino Uno and creating an LCD simulator that works by sending LCD data through the hardware UART (serial interface). This LCD data is very short in length; in this case, it's 2 bytes. The LCD simulator has already been made, and it is capable of detecting these LCD packets on the serial port and using them to control the simulated LCD.
However, I don't want to disturb the other traffic passing through the serial port; in this case, it's just text. The problem is that most serial monitors are able to pick up the LCD packets, which aren't supposed to be printed out because they appear as gibberish.
For now, I'm prefixing these short LCD packets with two magic numbers for it to be detectable by the LCD simulator alongside non-LCD traffic, and perhaps removable by a modified serial monitor.
I thought about using ASCII control characters to inform regular terminals that following data must not be printed, but there does not seem to be a specific control character to "hide" text/data; the closest thing there is is the BS character. All other control characters seem to give an inconsistent result among terminals - i.e. ESC doesn't actually hide text with the Windows console host, but it does with mintty.
My goal is to not have to integrate my own serial monitor and force others to use it if there is traffic present that can only be read by the LCD simulator. I want to allow others to use their own terminals and serial monitors to exchange textual data with the Arduino while seamlessly having LCD packets being sent invisibly and "under the hood."
Is this possible? Can I mix different types of data across the same serial port? If not, what are my options, or am I essentially forced to "reinvent the wheel" by making my own protocol that can mix the two types of traffic?

If it's only two bytes, the cost of encoding the data in hex or something like that so it won't seriously distort a serial monitor should not be too great.  But if you want to completely filter it out, yes, you will probably need your own client - theoretically you could follow it with a few backspaces or an ANSI escape sequence having similar effect, and that will work on some terminal emulators or configurations thereof, but it will only make an even bigger mess with other configurations.

The idea that sundry terminal programs can cleanly deal with binary data intended for your LCD simulator doesn't seem realistic.  Instead, look for a method to suppress the binary data when the Arduino isn't talking to an LCD simulator.
For example, during startup the Arduino could send some fixed text and a number to the host, and if the simulator is running, it would reply to the Arduino with some other fixed text and the 9's complement of the number.  If the Arduino doesn't get such a reply within a couple of seconds, it turns off LCD-simulation data transmission.

I would simply send the data as ASCII, in the form of hex bytes. It wil make your two bytes become four, plus the two "leader" characters to uniquely identify them becomes six. This minor overhead can probably be absorbed.
If you have much more binary (non-ASCII) data, you could look at using a different encoding format such as Base64. This only has a 2 character overhead for every 6 bytes of binary data.
You don't mention what data rate you use, either in baud rate or "packets per second", but if you're reading it on a serial monitor it can't be very much.

If I were to do something like this on Linux, I would probably have the
LCD simulator sit between the Arduino and the serial monitor, like this:
                    +---------------------------------------------------+
                    |                    host computer                  |
+-------------+     | +-------------------+         +-----------------+ |
|             |     | |                   |         |                 | |
| Arduino  UART-----tty  LCD simulator    ptmx----pts  Serial monitor | |
|             |     | |                   |         |                 | |
+-------------+     | +-------------------+         +-----------------+ |
                    +---------------------------------------------------+

For this, you have to:

open the serial port connected to the Arduino (“tty” on the figure)
create a pair of pseudo-terminals (ptmx/pts)
open the master side of the pair (ptmx)
ask the user to open the slave side (pts) with his serial monitor
forward all traffic but the LCD control messages between the Arduino
and the pseudo-terminal.

I don't know how this works on MacOS, but since the whole
pseudo-terminal concept is a standard Unix feature, I would expect it to
work in a similar way on MacOS and Linux. But then I have no idea how
hard it would be to port this to Windows.

From README.md at github ... LCDViewer, the Arduino links a LiquidCrystal library that substitutes for the usual LiquidCrystal library.  That library sends 4 bytes per LCD op, which a python program on host uses to control an on-screen simulated display.  Ie, there isn't a separate 'LCD simulator' piece of hardware.

@jwpat7: I know. I did read that README before answering. The LCD simulator is not a piece of hardware, it's a piece of software.

Ok - so in your diagram, the left box is Arduino hardware, and the other two boxes are host processes that communicate via pseudo-terminal or pipe?  Probably an elegant solution.

@jwpat7: Yes, via a pseudo-terminal rather than a pipe: a pseudo-terminal is essentially a virtual serial port, so it should play well with a serial monitor.


text:
Atmega328p programming with Arduino libraries
I'm trying to use the serial communication to work between a naked AVR Atmega328p and a computer (OS X and Linux Ubuntu).
I can program the atmega (using a pololu programmer), I make it blink a LED on a breadboard, it works fine.
I am using the Arduino libraries to facilitate the task. And they seem to work fine (using delay, digitalRead, digitalWrite, etc).
I use a USB-to-TTL CH340 chip bought on internet. The CH340 works fine, it is recognised both on Ubuntu and OS X, and the loopback test works (Put a jumper between the TX and RX line, launch screen, type something and it comes back in the terminal), so I assume the CH340 is properly recognise and works.
Then, I plug the CH340 on my board. The 5V on the + column of the breadboard, the GND to the - column. The circuit works, my LED blinks as requested. The loop function looks like this:
void setup() {
  Serial.begin(9600);
  pinMode(9, OUTPUT);
}

void loop() {
  digitalWrite(9, HIGH);   // sets the LED on
  delay(30);                     // waits for a second
  digitalWrite(9, LOW);    // sets the LED off
  delay(70);                     // waits for a second
  Serial.println("loop end");
}

As you can see, at the send of the loop I send a string on the serial line. Now, I see the blue LED blinking on the USB-to-TTL converter, so it is definitely receiving data. But when I try to connect like so:
screen /dev/cu.wchusbserialfd110 9600

on OS X, or
screen /dev/ttyUSB0 9600

on Ubuntu, nothing is displayed. I just get a black terminal.
Is the Arduino Serial works with Atmega328 ? I suppose so, as it is the same microcontroller than on the Arduino. Any idea of what I am doing wrong?
Update:
More details to answer Christ Stratton question:
My low fuse is 62: 01100010. So, according to the specifications, the internal clock is used and set at 1MHz.
I programmed the Atmega using my own test bed, a Pololu programmer (as described in the book Practical AVR Microcontrollers: Games, Gadgets, and Home Automation with the Microcontroller Used in Arduino) and avrdude (through the use of platformio).
This is the command line used by platformio to flash the ROM:
/Users/[user]/.platformio/packages/tool-avrdude/avrdude -v -p atmega328p -C /Users/[user]/.platformio/packages/tool-avrdude/avrdude.conf -c avrispv2 -B 10 -e -b 115200 -P "/dev/cu.usbmodem00149121" -U flash:w:.pioenvs/pololu/firmware.hex

According to avrdude documentation, -B 10 means bitclock is set to 10us (microseconds) so a clock at speed 100Khz.
Now if I set this -B option to 1 (1Mhz), I can't program the Atmega anymore. Avrdude just timeout:
avrdude stk500v2_ReceiveMessage(): timeout

I think it is necessary to consider the possibility that the Arduino's bootloader is setting up the UART in some way that the Arduino Serial library assumes, and does not do itself. I believe this is plausible as IIRC the Arduino bootloader will always be run before any uploaded (Arduino) program is started. Can you put the Arduino bootloader onto your ATmega328, and then try to upload to it using your USB-UART? You might need to fiddle with the reset to your ATmega to get it into the right state as autoboot might not work (unless you can wire that up correctly too)

Definitely a question for the Arduino StackExchange. Or even Ask Ubuntu..

@gbulmer your theory is incorrect.  There is absolutely no dependency whatsoever between the bootloader and main program, and it is well known that Arduino code does not in any way require a bootloader to be present.

What is the clock source and frequency of your circuit?  What was the clock source and frequency of the Arduino board configuration you used to build?  If there is a mismatch all the serial baud rates will be off.  If they are off by a power of two, you may be able to temporarily work around the issue by setting your computer to a baud rate that differs by the same factor, but it would be better to make the board configuration match the board.

@ChrisStratton, I tried to answer your question. I think I understand what you mean. The Arduino libraries are using some constants to deal with time dependent functionalities and those constant varies according to the board you want to program. If you compile you code with a ucontroller with 8MHz as target and run it on a 1Mhz, your 9600 baud rates will not be achieved. My guess is that either these constants are derived from the -B parameter or from another part of the avrdude configuration.

Bingo. The clock speed specified was the problem, but not through the -B parameter but by the board_f_cpu configuration option of the platformio.ini file. @ChrisStratton, if you post an answer summing up the solution, I'll accept it.

@ChrisStratton - I haven't read some of those sources for years, and clearly I'm misremembering, so thanks for the information. " it is well known that ... " a relative of "AssUme"?

The clock rate of your board must match the clock rate defined in the board file you used to compile your sketch.  If it does not, the baud rate will differ by the same factor.
If the actual baud rate so achieved is a valid one, you can temporarily achieve communication by setting the computer to that baud rate, but all delays and other clock-rate related functions will be off.
You should use or create a board file entry that matches your board, or use a standard clock source / clock divier setting for which there already is an entry.

Indeed, just needed to update the platformio.ini file used by platformio to configure avrdude.

authors: ﻣﺳـﮐووﻧهہ اﻟﻋراﻗﻱ


text:
Arduino Mega 2560 from .org- which IDE works?
My personal choice is to purchase from the .cc (or adafruit) for new boards. YMMV.  Craigslist locally of course has generic and .org boards now and then.
If I get a .org board on craigslist, will I need to use their fork of the IDE for the board to be recognized by the IDE?
My feeling is "yes" but I wanted to confirm.
A board there just now is Arduino mega 2560 from the .org.  Would I have to use their flavor of the IDE?
Thank you for your thoughts- photo of the board I am considering is attached.

Have you compared the schematics yet?

Yes, That doesn't look different that I can see.
I was thinking more about the IDE6 not recognizing the vendor or board ID due to all the things going on between .cc and .org.

Then you can use any IDE you like as long as you use the appropriate firmware.

Perfect timing on your reply, thank you for your help.

Arduino.org and arduino.cc have come to a agreement.
As such all incompatibilities that exist (I don't think they exist for this mega board) will be solved with next version of the Arduino IDE as if it is a board of their own.


text:
WiFiClient.connect() does fail all the time (ESP8266 Core for Arduino)
I have one ESP(1) opening an AP and running a server on it. The other ESP(2) is running a client on it and is connecting to the AP and after that trying to connect to the host server. The connection to the AP does succeed but the connection to the host always fails and I cannot figure out what the problem is here. Testing the server via netcat and packetsender works fine. Connecting to it via telnet fails because the connections gets closed by the "foreign host".
Server Sketch
#include <ESP8266WiFi.h>

const char* ssid = "artex11";
const char* pw = "getmenow11";
WiFiServer server(80);
WiFiClient client;

void setup() {
  Serial.begin(115200);
  //setup AP
  WiFi.softAP(ssid, pw);
  Serial.println("AP started at: ");
  Serial.print(WiFi.softAPIP());
  server.begin();
  Serial.println("Server started...");
}

void loop() {
  client = server.available();

  if(client){
    Serial.println("Client connected!");
    Serial.print("HasClient: ");
    Serial.println(server.hasClient());
    char message = client.read();
    Serial.printf("Message: %c\n", message);
  }
}

Client Sketch
#include <ESP8266WiFi.h>

const char* ssid = "artex11";
const char* pw = "getmenow11";
const char* host = "192.168.4.1";
const int port = 80;

void setup() {
  Serial.begin(115200);
  WiFi.begin(ssid, pw);
  Serial.println("Connecting to AP");
  while(WiFi.status() != WL_CONNECTED){
    delay(500);
    Serial.print(".");
   }
  Serial.println(" connected");
}

void loop() {
  WiFiClient client;
  Serial.println("Connecting to host");
  if(!client.connect(host, port)){
    Serial.println("...connection failed!");
    Serial.println("Retrying in 5 seconds...");
    delay(5000);
    return;
  }
  client.print("A");
  Serial.println("...TCP message fired!");
  delay(2000);
}

In your Client sketch you are setting the IP address of your host to "192.168.4.1", but in your Server sketch you never set an IP address, so how do you expect the connection to be established?
There are multiple libraries for ESP8266, without clarifying which one you are using there is not much we can do about this...

This is the default IP. As I said connecting to this IP through telnet, netcat and packetsender works but no from the client ESP

And as I said, without knowing which library you are using we cannot help because in the library I was opening to solve your issue the default IP is 192.168.0.1.

The library is #include <ESP8266WiFi.h> isnt that visible through the sketch code? I'm gonna try to not rely on a default IP mybe that works.

That is an header file, not a library. The same header file is defined in at least 11 libraries I was able to find online...

https://github.com/esp8266/Arduino sorry this lib

The problem was this missing piece
WiFi.mode(WIFI_STA);
If omitted  it seems the WiFi is starting in Station & AP mode - so I was able to connect to the other AP but not to connect to the host because of reasons.

If the server has a default IP address of 192.168.0.1 and the client has an IP address of 192.168.4.1 my guess is they won't be able to talk because you are using a 24 bit mask.
The subnet mask defines the number of bits that makes up the subnet, so if you were using the two addresses above and had a mask of 255.255.255.0 or 24 bits then the subnets you were using would be 192.168.0 and 192.168.4.  To cross subnets you need some form of routing process (usually a router, switch that can route, etc).
So you need to either change the mask or, stick both devices on the same subnet.
(Don't rely on defaults, when they change your code breaks)

your reasoning is correct and possibly applicable, I'm commenting here just because you inverted the IP addresses of client and server... In the client firmware he is opening a connection toward192.168.4.1, so that's the expected server address... Also I don't think he ever sets the client address to 192.168.0.1, that was a statement from me, but I was probably looking at the wrong lib.

@RobertoLoGiacco - I wasn't awake, I've only just started work, I have to get 3 hours in before I can read :)

authors: ชิณท์ณภัทร ผลจันทร์


text:
How avoid TCP packet fragmentation?
I'm using an Arduino Uno with an Ethernet Shield and the arduino.cc Ethernet library for a custom TCP-based message-exchanging chat-like protocol. Specifically I'm using the Client class with its print()
and println() methods. It works.
But on each single print() or println() call a whole TCP packet is sent. Also if just one byte is printed, a whole TCP packet is sent over the IP layer. I mean there's a lot of TCP packets with very few data inside. In other words there's a big overhead.
For example take this message that my Arduino successfully sends and my server successfully receives:
i-am EEEEEEEE-EEEEEEEE-EEEEEEEE-EEEEEEEE\r\n

The code is the following:
stream.print("i-am");
stream.print(' ');
for (byte i = 0 ; i < SERIAL_CODE_LENGTH ; i++){
  if (  i % 4 == 0 && i != 0 ){
    stream.print('-');
  }
  if (serialCode[i] < 16){
    stream.print('0');
  }
  stream.print(serialCode[i], HEX);
}
stream.println();

All that EE are hexadecimal byte values from an array and they are fine. But I can see from Wireshark that those 42 bytes (that could be fit in a single packet) are sent in 22 TCP packets (one for each print call in my code)!
How can I avoid this fragmentation? Is there a way to use an hardware or software buffer to group data before to send (Nagle's algorithm)?
With other SDKs the data are buffered by default and they're sent when the buffer is full or when an explicit "push" or "flush" call occurs. I checked Client flush method and it looks to be a different beast...

Use a better Ethernet library.

Any suggestions for a better library, @IgnacioVazquez-Abrams?

It is possible to write an ethernet library that buffers directly in the W5100 and uses an efficient SPI interleaving algorithm for transfer. Please see the Cosa W5100/W5200 device drivers for example. https://github.com/mikaelpatel/Cosa/blob/master/libraries/W5100/W5100.hh

To be honest, at the point I'm now with the sketch quite finished, I'm already thinking to replace those stream.print() with a sort of bufferredPrint() and to finalise them with bufferFlush(). But I still ask to myself if there is a better and feasible way to use the hardware buffer of the Ethernet shield and to do not upset the entire sketch.

Have a look at the example sketch CosaShellTelnetServer; https://github.com/mikaelpatel/Cosa-Shell/blob/master/examples/CosaShellTelnetServer/CosaShellTelnetServer.ino You can use this to check the performance difference.

Finally I managed to derive the EthernetClient class to override the write method and to add a sendNow method. In this way I still can:

Use any print method version simply by inheritance;
Pass the BufferedEthernetClient objects to function taking generalized Stream references (functions that can be used also with Serial, Wire, SD...).

Code
#define BUFFER_SIZE 64

class BufferedEthernetClient : public EthernetClient {
  public:
    BufferedEthernetClient();
    virtual size_t write(const uint8_t *buf, size_t size);
    virtual void sendNow();
  private:
    byte buffer[BUFFER_SIZE];
    byte bufferCount;
};

BufferedEthernetClient::BufferedEthernetClient(){
  bufferCount = 0;
}

size_t BufferedEthernetClient::write(const uint8_t *buf, size_t size){
  for (size_t i = 0; i < size; i++){
    buffer[bufferCount] = *(buf + i);
    bufferCount++;
    if (bufferCount >= BUFFER_SIZE){
      sendNow();
    }
  }
  return size;
}

void BufferedEthernetClient::sendNow(){
  if (bufferCount){
    bufferCount -= EthernetClient::write(buffer, bufferCount);
  }
}

Example
I use it in this way:
void printSerialCode(Stream & stream){
  for (byte i = 0 ; i < SERIAL_CODE_LENGTH ; i++){
    if (  i % 4 == 0 && i != 0 ){
      stream.print('-');
    }
    if (serialCode[i] < 16){
      stream.print("0");
    }
    stream.print(serialCode[i], HEX);
  }
}

BufferedEthernetClient client;
...
client.print("i-am");
client.print(' ');
printSerialCode(client);
client.println();
client.sendNow();

I suspect its stream.print() that is causing the problem.  Write the data into a string and then use a SINGLE call to stream.print() to send the data.  It looks like it is trying to send it as soon as possible to prevent delays and this is what is causing fragmentation..

Yes indeed. Anyway I prefer a byte buffer so I do not fear to send zeros (C-style string terminator). I posted my final solution in my answer.

Instead of this, you can join strings into one string by separating with a sign (i.e."-") and then split it into array elements

This is just a duplicate of Code Gorilla's answer from a year and a half earlier.

It will a better answer is you added a code sample.


text:
How do I convert a program made on Notepad to my Arduino on Proteus
I had the Arduino IDE but I accidentally deleted it. I have no internet connection, so I could not download it again. I do not currently possess the Arduino hardware itself but I do have Proteus and the Arduino library in it.
So I want to program my Arduino. Previously I would simply write the sketch and compile it and go to where I compiled it and simply add it on my Proteus Arduino and run it. Since I don't have the Arduino IDE, I tried using Notepad and tried to save it as a .hex file and run it on Proteus and there was an error created saying Error reading hex file.
So how can I program my Arduino on Proteus with the given materials (Notepad, Proteus)? Can it be done? Or is there any other way?

If you don't have an Internet connection how did you post this question?

@Transistor This is on my iPhone so I could not download it on my iPhone there is no wifi or LAN cable so simply my internet on my iPhone. What I meant to say was that there is no internet for me to download the Arduino on my PC.

Create WiFi hotspot on your iPhone and share the internet.

@BenceKaulics  I tried it and it keeps saying that my connection is limited.

Download the IDE on your phone, then create a WiFi hotspot on your phone. Connect your PC to your phone wirelessly, then transfer the IDE from your phone to your computer.

Besides displaying source code and letting you edit it, the IDE uses avr-gcc (and half a dozen other avr- utilities, like avr-objcopy, avr-ar, avr-nm) to compile and link the code and convert it to an elf or hex form, then uses avrdude to download it.  Using proteus, you can get by without  avrdude, but not without a suitable compiler and linker.
If you have a micro-SD slot on your phone, perhaps you can download the IDE to a card and then move the card to your computer to install the IDE.


text:
Arduino Uno outputs 8V when pin is set to HIGH
I am doing the following in setup:
 pinMode(13,OUTPUT);
 digitalWrite(13, HIGH);

When I check with the multimeter, I get an output voltage of 8V rather than 5V. What may be the problem and how do I troubleshoot it?.

You have a badly calibrated multimeter? Try it on something where you know what the voltage should be, such as a 9V battery and see what it reads.

@Majenko : You were right. My DMM battery is low, hence its showing some wrong values :). I will replace it with a new one.

Is the code as shown what you actually have?  pinMode(13, HIGH); is invalid.  Perhaps you meant digitalWrite(13, HIGH);

You need to show more code. Your posted code doesn't do a digitalWrite, and even if it did, if it wrote HIGH and then LOW in quick succession you may get an unexpected reading.

You have a badly calibrated multimeter.
Try it on something where you know what the voltage should be, such as a 9V battery and see what it reads.

Yes, the meter should be suspect, but, I'd expect a "9v" battery to read anything from zero to close to ten volts with a calibrated meter, depending on chemistry, cell count, and condition.  Probably better to measure the circuit's supply and describe its source.

@ChrisStratton Yes, but if it is the multimeter at fault then I'd expect the 9V battery to read something like 12V or more to be inline with what the Arduino is measuring at. That can't happen with a 9V battery no matter how much charge it has left.