text:
Can I use analogReadResolution() on an Uno or Leonardo?
I am trying to get a spectrum analyser up and running. I found the following code on Galileo GEN2 Project - Real-Time Audio Spectrum Analyzer1:
/*
 *
 * Galileo GEN2 Project - Real-Time Audio Spectrum Analyzer
 * https://communities.intel.com/docs/DOC-23406
 *
 *
 * ERROR: analogReadResolution() ???
 *
 */

#include <stdint.h>  //For New Arduino
#include "PCD8544.h"
#define pin_adc 0
#include "fix_fft.h"
char im[128];
char data[128];
int analog_value[128];
int i=0;
PCD8544 nokia = PCD8544(3, 4, 5, 7, 6);
// pin 7 - Serial clock out (SCLK) connects Dig3
// pin 6 - Serial data out (DIN) connects Dig4
// pin 5 - Data/Cmd. selct. (D/C) connects Dig5
// pin 4 - LCD reset (RST) connects Dig6
// pin 3 - LCD chip select (CS) connects Dig7
void setup() {
  nokia.init();
  nokia.command(PCD8544_DISPLAYCONTROL | PCD8544_DISPLAYNORMAL);
  nokia.clear();
  analogReadResolution(8);
}

void show_big_bars(char *spektrum) {
    int spek_for_draw;
    nokia.drawline(10, 15, 10, 39, BLACK);
    for (byte i = 1; i < 64; i++){ // Skip 0 Channel
      // Serial.print(spektrum[i],BYTE);
      spek_for_draw = 1.5*(spektrum[i]); // 0/2.5 ~ 255/2.5
      if (spek_for_draw > 39) spek_for_draw = 39;
      nokia.drawline(i+10, 39 - spek_for_draw, i+10, 39, BLACK);
    }
    //nokia.drawstring(5, 5, "0 09 22 36 49");
    nokia.drawstring(5, 5, "0");
    nokia.drawstring(21, 5, "4");
    nokia.drawstring(37, 5, "8");
    nokia.drawstring(48, 5, "12");
    nokia.drawstring(67, 5, "18");
    nokia.drawstring(5, 0, "Spectrum");
    nokia.drawstring(5, 1,"* 0.1KHz");
    nokia.display(); // Update Screen
    nokia.clear(); // Clear Screen for the animation
}
void loop(){
  static long tt;
  int val;
  if (i < 128){
      analog_value[i] = analogRead(pin_adc);
      i++;
   }
   else{
        for (i=0; i< 128;i++){ //Prepare data for FFT
            data[i] = analog_value[i] - 128;
            im[i] = 0;
        }
   //this could be done with the fix_fftr function without the im array.
        fix_fft(data,im,7,0);
   // I am only interessted in the absolute value of the transformation
        for (i=0; i< 64;i++)
             data[i] = sqrt(data[i] * data[i] + im[i] * im[i]);
   //do something with the data values 1..64 and ignore im
        show_big_bars(data);
        i=0;
   }
}

When I attempt to compile the above code, I get the error
Arduino: 1.6.5 (Mac OS X), Board: "Arduino Micro"

fft_galileo.ino: In function 'void setup()':
fft_galileo:31: error: 'analogReadResolution' was not declared in this scope
'analogReadResolution' was not declared in this scope

When I search for the location of analogReadResolution() on Google, I repeatedly get the information that it is only available for the Due and Zero. From Arduino - AnalogReadResolution:

analogReadResolution() is an extension of the Analog API for the
  Arduino Due and Zero.

I was wondering if I needed to add an #include statement but all of the code examples that I found do not have any specific #include for the Analogue library.
Also, thinking maybe it is board specific (as the video Arduino Due error: 'analogReadResolution' was not declared in this scope suggests), I selected the Duemilanove board (as the Due is not on offer in my "Board" menu), but I still get the same error. I have even tried the Arduino NG or older Board menu item, but with the same results.
So, how do I get rid of this compile time error? Or, more poignantly, how can I compile this code for my Uno or Leonardo board.  Should I just comment it out? If I do comment the line out then the code does compile, so does this mean that analogReadResolution() is not required any longer?
If it isn't required, then why does this Uno specific example, How to Use ADC in Arduino Uno?, state:

As default we get the maximum board ADC resolution which is 10bits,
  this resolution can be changed by using instruction
  (“analogReadResolution(bits);”). This resolution change can come in
  handy for some cases.

How can the resolution be changed if the method has, indeed, been deprecated?
Also, why do I not have a "Due" in my Board menu?

1 For completeness fix_fft.h and fix_fft.cpp can be found on TJC's github and here is the PCD8544 Arduino library for Nokia 5510 LCD library. The password for decompressing Intel_Nokia5110.rar file is 406.

It's a Uno, not a UNO. It's not an acronym. Arduino is naming their boards Zero Uno Due Tre - that is Zero One Two Three.

@NickGammon - Thanks for pointing that out. Not sure where, or why, I got the wrong idea. Feel a bit of a fool now. I have made some bad edits in that case :-(

Don't worry about it. Your edits have been good. I've restrained myself from correcting UNO to Uno, because I wanted you to have the credit for making the edit. :)

@NickGammon - I wish you had corrected them though, as I do appear to have sprayed UNO all over the shop. I think that I must have picked up the capitalisation of the Arduino website as they seem to put caps on everything, not sure. BTW, I think that you can make subsequent edits, when reviewing, as many of my edits get revised across SE (I'm not too sure of the procedure). Don't worry about letting me have the credit, I just want to see nice clean posts... ;-) Thx again.

There is no point to having analogReadResolution() on AVR devices since that function only exists to provide/ensure backwards compatibility with the fixed 10-bit ADC that is found in AVR devices. If you want higher or lower resolution then you will need to perform the appropriate actions manually.
You don't have a Due entry because you haven't installed Atmel SAM support in the Board Manager.

Also, why do I not have a "Due" in my Board menu?

See:

Then:

I selected the Duemilanove board (as the Due is not on offer in my "Board" menu) ...

The Duemilanove and the Due are completely different boards, with different processors.


text:
Can't get software serial to work
So I have two Arduinos (Arduino Nano) and I'm trying to get them to communicate via SoftwareSerial.  I have the 'sending' Arduino's D10 pin connected to the 'recieving' Arduino's D11 pin, and vice versa.  On my sending Arduino, I have the following code:
#include <SoftwareSerial.h>
SoftwareSerial mySerial(10, 11);

void setup() {
  pinMode(2, OUTPUT);
  mySerial.begin(9600);
}

void loop() {
  if (mySerial.isListening()){
    digitalWrite(2, HIGH);
  }
  mySerial.write(5);
}

and on my receiving Arduino, I have:
#include <SoftwareSerial.h>
SoftwareSerial mySerial(11, 10);

void setup() {
  pinMode(2, OUTPUT);

  Serial.begin(9600);

  mySerial.begin(9600);
}

void loop() {
  mySerial.listen();
  if (mySerial.available()>0) {
    digitalWrite(2, HIGH);
    char inByte = mySerial.read();
    Serial.write(inByte);
  }
  digitalWrite(2, LOW);
}

(with D2 being hooked up to an LED for both).
I can't get it to read anything.  Nothing seems to be available for the receiving Arduino (the LED is off).  What am I doing wrong?

Sender:
SoftwareSerial mySerial(10, 11);  // Rx, Tx

Receiver:
SoftwareSerial mySerial(11, 10);  // Rx, Tx

I have the 'sending' Arduino's D10 pin connected to the 'receiving' Arduino's D11 pin, and vice versa.

So you have the sending Arduino's Rx connected to the receiving Arduino's Rx. Therefore it won't work. You need to connect Rx to Tx.

  mySerial.listen();

You don't need that in this simple example.

I agree with Nick above but want to add this simplify your code like this:

if (mySerial.available()) {
    digitalWrite(2, HIGH);
    Serial.write(mySerial.read());
  }

I have had to catch serial data from a printer feed before and this turned out to be the best way to catch all the data if you place it in a variable first it has to change the variable every time that you receive a byte but this way it places all in a buffer then sends it out
BTW I had to save to a F-RAM device and that worked the same way but instead of sending it I had it saved to a variable while using ReadString() in stead of read().

Re “if you place it in a variable first it has to change the variable every time that you receive a byte”: A local variable, used like in the original post, will be allocated by the compiler to a CPU register. What you are proposing is not more efficient.

like i said in the answer at the bottom I used a variable but nothing else and that is what made it work for simplifying the code to get it to work on the first go use the simplest version you can get then build on that.

I don't quite understand what you are writing, but the sentence starting with “if you place it in a variable first” sounds like you imply that using a temporary variable is a cause of inefficiency. If that is what you mean, it is wrong. If it's not what you mean, then you should edit the answer in order to clarify the sentence.

no maybe my language is really letting me down
to put it in simplest terms you should try to minimize the processes happening on a serial event and you should keep away from delays and all of that and if you are purely trying something out do it in the simplest way available being the one i suggested (i believe but could be wrong)  and then build on to that
it just makes debugging a breeze and not a schlep

as for the variable I found it to be a good solution by itself having nothing else keeping the mcu busy while receiving data not saying that is the only function that your MCU should have but rather in the data receive event that should be kept to the minimum and that you should not even try something like a delay in there and once again keep your code simple and straight forward

Lots of words and still not getting clearer. Please, answer this simple question: Are you, yes or no, implying that char inByte=mySerial.read();Serial.write(inByte); is less efficient (i.e. it keeps the MCU more busy) than Serial.write(mySerial.read());?

well you are for one putting the data in a variable and then sending it out so you tell me
I am only giving my opinion and as far I know keeping it simple makes it work

Let us continue this discussion in chat.

Yeah never Agree with someone hey

source: Stack Exchange

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

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

sort: votes


text:
Arduino Robot. a function-definition is not allowed here before '{' token
The code is very messy. We have an L293D circuit which has two enable pins always on. We also have an LDR light sensor with two light resistors, one on the left and one on the right.
We are trying to make a line following robot
We are ambitious high school students.
// Use this code to test your motor with the Arduino board:

// if you need PWM, just use the PWM outputs on the Arduino
// and instead of digitalWrite, you should use the digitalWrite command

// --------------------------------------------------------------------------- Setup
void setup() {
{Serial.begin(9600);

// --------------------------------------------------------------------------- Motors
int motor_left[] = {2, 7};
int motor_right[] = {10, 15};
int LDR = 0;     //analog pin to which LDR is connected, here we set it to 0 so it means A0
int LDRValue = 0;      //that’s a variable to store LDR values
int light_sensitivity = 500;    //This is the approx value of light surrounding your LDR
int LDR2 = 0;     //analog pin to which LDR is connected, here we set it to 0 so it means A0
int LDR2Value = 0;      //that’s a variable to store LDR values
int light_sensitivity2 = 500;    //This is the approx value of light surrounding your LDR
int i;
for(i = 0; i < 2; i++){
pinMode(motor_left[i], OUTPUT);
pinMode(motor_right[i], OUTPUT);
LDRValue = analogRead(LDR);
    Serial.println(LDRValue);

    if (LDRValue < light_sensitivity);
    Serial.println("wat");

}
// --------------------------------------------------------------------------- Loop

// --------------------------------------------------------------------------- Drive

void motor_stop(){
digitalWrite(motor_left[0], LOW);
digitalWrite(motor_left[1], LOW);

digitalWrite(motor_right[0], LOW);
digitalWrite(motor_right[1], LOW);
delay(25);
}

void drive_forward(){
digitalWrite(motor_left[0], HIGH);
digitalWrite(motor_left[1], LOW);

digitalWrite(motor_right[0], HIGH);
digitalWrite(motor_right[1], LOW);
}

void drive_backward(){
digitalWrite(motor_left[0], LOW);
digitalWrite(motor_left[1], HIGH);

digitalWrite(motor_right[0], LOW);
digitalWrite(motor_right[1], HIGH);
}

void turn_left(){
digitalWrite(motor_left[0], LOW);
digitalWrite(motor_left[1], HIGH);

digitalWrite(motor_right[0], HIGH);
digitalWrite(motor_right[1], LOW);
}

void turn_right(){
digitalWrite(motor_left[0], HIGH);
digitalWrite(motor_left[1], LOW);

digitalWrite(motor_right[0], LOW);
digitalWrite(motor_right[1], HIGH);
}
void loop() {
drive_forward();
delay(1000);
motor_stop();
Serial.println("1");

drive_backward();
delay(1000);
motor_stop();
Serial.println("2");

turn_left();
delay(1000);
motor_stop();
Serial.println("3");

turn_right();
delay(1000);
motor_stop();
Serial.println("4");

motor_stop();
delay(1000);
motor_stop();
Serial.println("5");
}

I copied your code into the question, to save everyone having to go to Pastebin to get it. Please copy and paste the actual error message. Inside it is a line number which will tell us which line it is failing at.

You need to look more closely at your braces. Use the auto-format tool (Ctrl+T) to help you. For example:
void setup() {
{Serial.begin(9600);

// --------------------------------------------------------------------------- Motors
int motor_left[] = {2, 7};
int motor_right[] = {10, 15};
int LDR = 0;     //analog pin to which LDR is connected, here we set it to 0 so it means A0
int LDRValue = 0;      //that’s a variable to store LDR values
int light_sensitivity = 500;    //This is the approx value of light surrounding your LDR
int LDR2 = 0;     //analog pin to which LDR is connected, here we set it to 0 so it means A0
int LDR2Value = 0;      //that’s a variable to store LDR values
int light_sensitivity2 = 500;    //This is the approx value of light surrounding your LDR
int i;
for(i = 0; i < 2; i++){
pinMode(motor_left[i], OUTPUT);
pinMode(motor_right[i], OUTPUT);
LDRValue = analogRead(LDR);
    Serial.println(LDRValue);

    if (LDRValue < light_sensitivity);
    Serial.println("wat");

}   // <------------------------------------ HERE

// --------------------------------------------------------------------------- Loop

// --------------------------------------------------------------------------- Drive

void motor_stop(){

Where I marked "HERE" you are closing the for loop but you should also be closing setup.
You also have two opening braces here:
void setup() {
{Serial.begin(9600);

Proper indentation is very helpful for sorting out these sorts of issues.

authors: ประสิทธิ์ เกิดนอก

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


text:
Does int array[100] = {0} construct work on Arduino?
I'm compiling my code in Arduino IDE. I have an array that I want to 0-initialize. I know memset works on Arduino, but I'm used to this way from my desktop C++ programming practice:
int array[100] = {0};

I couldn't find any info on whether or not this construct works on Arduino. I think it should since it uses GCC compiler. Even though it may be modified, I still expect it to remain C and C++-compliant. Still, can you confirm for me that this standard-compliant C/C++ construct works on Arduino?

Have you tried it? What were the results?

@Majenko: It seems to: the program is much larger with = {0} that without it, so the compiler is definitely doing something. On the other hand, in my test the array was all 0s both with and without = {0}. Problem is, that proves nothing. It doesn't guarantee that it will work on some other compiler with some other settings. The testing would only be conclusive if it demonstrated that this code does not work.

It's not the compiler that does it (and the = {0} does nothing by the way) but the CRT (initialization code). Maybe this will explain: https://en.wikipedia.org/wiki/.bss

@Majenko: a) if it does nothing then Arduino IDE compiler is broken: http://stackoverflow.com/a/629063/634821
b) how does it do nothing when it increases code size by a couple hundred bytes?

The = {0} may have prevented an otherwise unused variable from being optimized out of the code.

@Majenko: it was very much used, I was printing it to Serial in setup().

Maybe it changed how it was initializing it to zero - explicitly clearing that memory block rather than just relying on BSS being cleared already. So it may change the behaviour but not the end result - and ends up just needlessly increasing the size of your program.

you can actually try it and see it by printing on the serial monitor :)

@Manav: I did, see my first comment to Majenko. It proves nothing if it appears to be working right. Only a negative result would be conclusive.

You should start from the premise that the Arduino uses standard C++ (however exceptions are disabled by a command-line switch). If something is standard C++ then it will work. You don't need to worry about proving it.

I'm used to this way from my desktop C++ programming practice:
int array[100] = {0};

I couldn't find any info on whether or not this construct works on Arduino.

The = {0} has no actual effect. It is the same as:
int array[100];

Uninitialized static / global variables, and variables explicitly initialized to 0, are placed in the .bss section of memory.
This section is initialized to 0 by the CRT (C Runtime) code (the startup code for the system).
The compiler is responsible for placing these variables in the .bss, but it is the job of the startup (CRT) code to initialize it to zero.
This is standard C operation and is not likely to ever change since it would break all sorts of things.
Note: this does NOT apply to local variables allocated on the stack. These must be initialized to 0 if you want them to start as 0.

Very well, thanks for the explanation. I have no habit of relying on C default-initializing POD types (because it usually doesn't) and hence prefer doing it explicitly, but then, I also have no habit of using global or static data a lot. Didn't know the global variables are guaranteed to be default initialized (or zero-initialized? I always confuse these two terms). The main point of = {0} is that it also works for local arrays.

This construct does work in Arduino IDE. In fact, = { 0 } is one of the iconic idioms of C language. It can be used to zero-initialize an object of any type in C. In C++ things are a bit more complicated. It will work for an int [100] array, but in general case you might be better off with = {} initializer to achieve the same effect where applicable.
It is not clear why the accepted answer claims that this construct "has no actual effect" though. This is, of course, incorrect. More precisely, this initializer is redundant ("has no effect") on variables with static storage duration, since such variables are default-initialized anyway (zero-initialized for int [100]), even if you don't request it explicitly. But for a local variable declaration the effect of = { 0 } is undeniable and obvious: it will zero-initialize the array (which wouldn't've been initialized without it).
Note that even though the 0 in the = { 0 } initializes the first element of the array, this initializer ultimately triggers zero-initialization if the entire array.

The GNU cross compilers for Arduino use C/C++ front-ends and meet some version the language specs. (Although that is a moving target, you can expect a recent IDE version will be compliant with a reasonably recent language spec.)
"Arduino language" is a misnomer. The Arduino IDE will try to assist new programmers by, for example, automagically discovering library references and inserting the required #includes for you, but the resulting code is C++ and will be presented to a C++ compiler. The IDE provides a main() function that calls setup() and loop() (and serialEventRun() if you provide one) thereby reminding the programmer to initialize whatever needs to be initialized before expecting things to work right. However you can write proper C++ and get what you've come to expect. You'd have to go 'behind the IDE's back' as it were, to suppress the automatically-supplied main() function, but the toolchain doesn't care, as long as there is one and only one, main().
I tested this this trivial program:
    int array[100];

    void setup() {
      // put your setup code here, to run once:
       for(uint8_t i = 0; i < sizeof(array); ++i)
          array[i] = i;
    }

    void loop() {
      // put your main code here, to run repeatedly:

    }

with both the Arduino IDE and Sloeber - Eclipse with the EclipseArduino plugin, which routinely provides a basic memory map after compilation - and with and without the initialization expression = {0}. I found no difference in the size of the output in either environment, with or without the initialization. In all four cases, the .bss was 209 bytes, 200 bytes larger than without the global array.

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


text:
Connect an mp3 player to an Arduino?
I have been looking for a good way to play sounds using an Arduino.  I started to consider just buying a cheap mp3 player and replacing the player's buttons with optical switches, which connect to an Arduino.  I wanted to know if anyone has done this before and if there was a good mp3 player for this (one that may have some sort of control port / ir sensor.)

It's probably going to be very challenging to select the desired track, and it will have start up delay.  You can play lower fidelity digital audio directly from an Arduino or related chips, or comparable with add-ons - though there is a challenge in storing the clips uncompressed unless you opt for an sdcard.  What sorts of things do you want to play?

Yes, people have done this before, and they have documented it on their own blogs and similar sites.  Maybe you should have asked Google first before you came here?  You'd most likely have ended up on instructables, where someone has documented exactly what you want to do and how to do it. and saved yourself this entire step.


text:
Freeze with VCNL 4000 Proximity Sensor
I've the VCNL 4000 Proximity Sensor I use some sample code and at the very beginning
the following code hangs (never finishes)
 readVCNLByte(0x81); is called

Can this problem be caused because the contact of the pin isn't very good.
I only but the part with pins in the sensor without to solder it.
Is it likely that this may be the problem ? I have not many experince with solder and the sensor is really small so i'd like to avoid it for first tests ;)
Here the code. The last output in the Serial window is "pre product"
  Serial.println("VCNL");
  Wire.begin();
  Serial.println("pre product");
  uint8_t rev = read8(VCNL4000_PRODUCTID);
   Serial.println("post product");
  if ((rev & 0xF0) != 0x10) {
    Serial.println("Sensor not found :(");
    while (1);
  }

Try applying some lateral force to the connection. Or just solder the headers. It's not that hard to desolder them, if you remove the black plastic, before desoldering.

You really can't expect this to work unsoldered. The contacts will be at best intermittent, and poor contact. Even a 'dry joint' where the pin is mostly surrounded by solder doesn't work well, these are the ultimate examples! You could however use an edge-connector, if you can find one; not something you see often nowadays.

Sorry .. my answer comes late ..
I had the same issue, this has nothing to do with bad connexion between wires (not only at least).
But by playing with some parameter (current value > 60mA) I noticed that the module begin to freeze more often.
To fix that :
You need to add a small delay within your readbyte function after a i2c.stop()
I found that an issue had been written about that : https://github.com/adafruit/VCNL4000/issues/1
They recommand a 170us delay
I'm testing myself at full current and max speed (an since 30min it didn't freeze)... Before it could freeze in a second.
Hope it helps ;)

EDIT :
In order to better understand where the freeze comes from, I re-write a simple I2C library. I could get rid of the freeze by simple add a small delay in the i2c_start function (that send the start condition along with the slave address)
uint8_t i2c_start(uint8_t i2c_slave_address){
       //reset TWI control register
       TWCR = 0;
       //transmit start condition
       TWCR = (1<<TWINT) | (1<<TWSTA) | (1<<TWEN);
       //wait for end of transmission
       while((TWCR & (1<<TWINT))==0){
              _delay_us(75); // <-- here is the trick
       }
       if( (TWSR & 0xF8)!= TW_START ){
              return -1;
       }
       // load slave address into data register
       TWDR = i2c_slave_address;
       //start address transmission
       TWCR = (1<<TWINT) | (1<<TWEN);
       //wait for transmission
       while ( (TWCR & (1<<TWINT))==0 );
       //check if the slave did acknoledge the Read/Write mode
       uint8_t twst = TW_STATUS & 0xF8;
       if ( (twst != TW_MT_SLA_ACK) && (twst != TW_MR_SLA_ACK) ){
               return -1;
       }
       return 0;
}

you will need to add these libraries :
util/twi.h (for the macro TW_STATUS .. TTW_MT_SLA_ACK and so on)
util/delay.h
stdlib.h (for the uint8_t way of typing variable ..not actually 100% sure)
I'm still not fully satisfy by this solution, but it is still more effective that the one that adafruit propose.
I suggest you write you own i2c library (5 functions : init / start / read / write / stop) you now have the start already .. so 4 left ;)
If you're still to much afraid : in twi.c ( .\arduino\avr\libraries\Wire\utility\twi.c) and twi_readFrom(...) function.
On line 155 and 159 you will see that arduino send the start condition, but do not wait / take care that the transmission as been done... you can add a while function as previously describe to ensure it.

MASTER EDIT :
My previous solution didn't solve the issue neither...
Actually reading the application note (Designing VCNL4000 into an Application : google that)
gives the solution (page 7)
after you send the command to perform a single measurement, you need to wait.
I put a delay of 500ms and have none anywhere else. This works like a charm.
But for energy efficiency I recommend to put the uC in sleep mode for that period of time.


text:
Why does avrdude error appear when interfacing GLCD with arduino uno in ubuntu
I want to interface a GLCD with arduino uno. The GLCD is JHD12864E.   The connections are as shown in this image
I downloaded the OpenGLCD library and uploaded HelloWorld program from it.
I got the error:
        stk500_recv() : programmer is not responding
Then I googled it and also tried to upload using ISP using another arduino. The program uploaded successfully, but i did not get any output on GLCD.
I am not getting this error when uploading any other sketches. Can anyone explain to me why do we get this error? And what is the solution to it?

Have you read the 'reset function note' here http://playground.arduino.cc/Code/GLCDks0108? It may desribe your problem.

@DaveP Yes i have followed it.


text:
How to reset Arduino Uno over BLE?
I'm working on wireless uploader for Arduino over BLE.
I've managed to make it working for Arduino Mega 2560 using GPIO and HM-10 AT commands to control GPIO pins. I'm using pretty the same schematics to perform reset just like for USB is done (wire GPIO to capacitor, resistor and MCU reset pin). The problem that it does work for Mega 2560 and it does not work for Uno.
Here is log file for Mega 2560:
2015-09-05 14:53:01.055 xctest[59735:7704704] [DEBUG  ] [   ]: BleSerialDevice: open()
2015-09-05 14:53:01.055 xctest[59735:7704704] [DEBUG  ] [   ]: Connecting to service=0xFFE0, rx=0xFFE1, tx=0xFFE1
2015-09-05 14:53:01.055 xctest[59735:7704704] [INFO   ] [   ]: Start discovering peripherals ...
2015-09-05 14:53:01.056 xctest[59735:7704704] [DEBUG  ] [   ]: Waiting for peripheral to be discovered ...
2015-09-05 14:53:01.326 xctest[59735:7704747] [INFO   ] [   ]: Found peripheral: <CBPeripheral: 0x100407e30 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-05 14:53:01.326 xctest[59735:7704747] [DEBUG  ] [   ]: Stop scanning
2015-09-05 14:53:01.326 xctest[59735:7704747] [INFO   ] [   ]: Connecting to <CBPeripheral: 0x100407e30 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-05 14:53:01.548 xctest[59735:7704747] [DEBUG  ] [   ]: Connected to peripheral <CBPeripheral: 0x100407e30 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-05 14:53:01.551 xctest[59735:7704747] [TRACE  ] [   ]: Discovered services for peripheral <CBPeripheral: 0x100407e30 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-05 14:53:01.551 xctest[59735:7704747] [DEBUG  ] [   ]: Discovered service <CBService: 0x10020d510>
2015-09-05 14:53:01.692 xctest[59735:7704747] [TRACE  ] [   ]: Discovered characteristics for service <CBService: 0x10020d510>
2015-09-05 14:53:01.693 xctest[59735:7704747] [TRACE  ] [   ]: Discovered characteristic <CBCharacteristic: 0x1001076a0>
2015-09-05 14:53:01.693 xctest[59735:7704747] [DEBUG  ] [   ]: Tx characteristic supports WriteWithResponse: NO
2015-09-05 14:53:01.693 xctest[59735:7704747] [TRACE  ] [   ]: Subscribing to Rx value
2015-09-05 14:53:01.704 xctest[59735:7704704] [INFO   ] [   ]: Connected successfully
2015-09-05 14:53:01.705 xctest[59735:7704704] [DEBUG  ] [   ]: WiringProtocol:open: releasing DTR/RTS
2015-09-05 14:53:01.705 xctest[59735:7704704] [TRACE  ] [   ]: Waiting until subscribed to Rx value ...
2015-09-05 14:53:02.932 xctest[59735:7704747] [DEBUG  ] [IN ]: Updated notifications state for RX characteristic: isNotifying=YES
2015-09-05 14:53:02.971 xctest[59735:7704704] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-05 14:53:02.972 xctest[59735:7704704] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 1 [0x31]
2015-09-05 14:53:02.972 xctest[59735:7704704] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 14:53:03.027 xctest[59735:7704704] [DEBUG  ] [   ]: WiringProtocol:open: asserting DTR/RTS
2015-09-05 14:53:03.027 xctest[59735:7704704] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-05 14:53:03.028 xctest[59735:7704704] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 0 [0x30]
2015-09-05 14:53:03.028 xctest[59735:7704704] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 14:53:03.083 xctest[59735:7704704] [DEBUG  ] [   ]: Draining for 300 ms ...
2015-09-05 14:53:03.083 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.341 xctest[59735:7704746] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 1 [0x31]
2015-09-05 14:53:03.341 xctest[59735:7704747] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 0 [0x30]
2015-09-05 14:53:03.385 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.385 xctest[59735:7704704] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 14:53:03.385 xctest[59735:7704704] [DEBUG  ] [IN ]: Drained 18 bytes
2015-09-05 14:53:03.386 xctest[59735:7704704] [DEBUG  ] [OUT]: Sending 7 bytes
2015-09-05 14:53:03.386 xctest[59735:7704704] [TRACE  ] [OUT]: Send: . [0x1B] . [0x01] . [0x00] . [0x01] . [0x0E] . [0x01] . [0x14]
2015-09-05 14:53:03.386 xctest[59735:7704704] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 7
2015-09-05 14:53:03.387 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.387 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.453 xctest[59735:7704747] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-05 14:53:03.453 xctest[59735:7704747] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-05 14:53:03.454 xctest[59735:7704746] [TRACE  ] [IN ]: Rx value received 17 bytes: . [0x1B] . [0x01] . [0x00] . [0x0B] . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.455 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.455 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x1B]
2015-09-05 14:53:03.456 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 17 bytes
2015-09-05 14:53:03.456 xctest[59735:7704704] [TRACE  ] [IN ]: 16 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.456 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.456 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x01] . [0x00] . [0x0B] . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52]  ... +6 bytes
2015-09-05 14:53:03.457 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.457 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.457 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x01]
2015-09-05 14:53:03.457 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 16 bytes
2015-09-05 14:53:03.458 xctest[59735:7704704] [TRACE  ] [IN ]: 15 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.458 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.458 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x00] . [0x0B] . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49]  ... +5 bytes
2015-09-05 14:53:03.459 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.459 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.459 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x00]
2015-09-05 14:53:03.459 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 15 bytes
2015-09-05 14:53:03.460 xctest[59735:7704704] [TRACE  ] [IN ]: 14 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.460 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.460 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x0B] . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53]  ... +4 bytes
2015-09-05 14:53:03.460 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.461 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.461 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x0B]
2015-09-05 14:53:03.461 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 14 bytes
2015-09-05 14:53:03.461 xctest[59735:7704704] [TRACE  ] [IN ]: 13 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.462 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.462 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x0E] . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50]  ... +3 bytes
2015-09-05 14:53:03.462 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.462 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.462 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x0E]
2015-09-05 14:53:03.463 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 13 bytes
2015-09-05 14:53:03.463 xctest[59735:7704704] [TRACE  ] [IN ]: 12 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.463 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.463 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x01] . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F]  ... +2 bytes
2015-09-05 14:53:03.463 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.463 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.464 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x01]
2015-09-05 14:53:03.464 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 12 bytes
2015-09-05 14:53:03.464 xctest[59735:7704704] [TRACE  ] [IN ]: 11 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.464 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.464 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x00] . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32]  ... +1 bytes
2015-09-05 14:53:03.465 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.465 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.465 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x00]
2015-09-05 14:53:03.465 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 11 bytes
2015-09-05 14:53:03.465 xctest[59735:7704704] [TRACE  ] [IN ]: 10 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.466 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.466 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: . [0x08] A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.466 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.466 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.466 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: . [0x08]
2015-09-05 14:53:03.466 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 10 bytes
2015-09-05 14:53:03.467 xctest[59735:7704704] [TRACE  ] [IN ]: 9 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.467 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.467 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: A [0x41] V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.467 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.467 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.468 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: A [0x41]
2015-09-05 14:53:03.468 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 9 bytes
2015-09-05 14:53:03.468 xctest[59735:7704704] [TRACE  ] [IN ]: 8 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.468 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.468 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: V [0x56] R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.469 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.469 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.469 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: V [0x56]
2015-09-05 14:53:03.469 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 8 bytes
2015-09-05 14:53:03.469 xctest[59735:7704704] [TRACE  ] [IN ]: 7 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.469 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.470 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: R [0x52] I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.470 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.470 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.470 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: R [0x52]
2015-09-05 14:53:03.470 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 7 bytes
2015-09-05 14:53:03.471 xctest[59735:7704704] [TRACE  ] [IN ]: 6 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.471 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.471 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: I [0x49] S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.471 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.471 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.472 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: I [0x49]
2015-09-05 14:53:03.472 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 6 bytes
2015-09-05 14:53:03.472 xctest[59735:7704704] [TRACE  ] [IN ]: 5 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.472 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.472 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: S [0x53] P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.472 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.473 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.473 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: S [0x53]
2015-09-05 14:53:03.473 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 5 bytes
2015-09-05 14:53:03.473 xctest[59735:7704704] [TRACE  ] [IN ]: 4 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.473 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: P [0x50] _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: P [0x50]
2015-09-05 14:53:03.474 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 4 bytes
2015-09-05 14:53:03.474 xctest[59735:7704704] [TRACE  ] [IN ]: 3 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.475 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.475 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: _ [0x5F] 2 [0x32] t [0x74]
2015-09-05 14:53:03.475 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.475 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.475 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: _ [0x5F]
2015-09-05 14:53:03.476 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 3 bytes
2015-09-05 14:53:03.476 xctest[59735:7704704] [TRACE  ] [IN ]: 2 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.476 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.476 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: 2 [0x32] t [0x74]
2015-09-05 14:53:03.476 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.477 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.477 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: 2 [0x32]
2015-09-05 14:53:03.477 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-05 14:53:03.477 xctest[59735:7704704] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-05 14:53:03.477 xctest[59735:7704704] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 14:53:03.477 xctest[59735:7704704] [TRACE  ] [IN ]: Having current receive buffer: t [0x74]
2015-09-05 14:53:03.478 xctest[59735:7704704] [TRACE  ] [IN ]: Start reading
2015-09-05 14:53:03.478 xctest[59735:7704704] [TRACE  ] [IN ]: Finish reading
2015-09-05 14:53:03.478 xctest[59735:7704704] [TRACE  ] [IN ]: Receive: t [0x74]
2015-09-05 14:53:03.478 xctest[59735:7704704] [DEBUG  ] [IN ]: Read 1 bytes, actually received 1 bytes
2015-09-05 14:53:03.478 xctest[59735:7704704] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 14:53:03.479 xctest[59735:7704704] [DEBUG  ] [   ]: Found programmer: 'PGMTYPE_AVRISP'

Here is Uno log file:
2015-09-05 15:51:34.667 xctest[60180:7754033] [DEBUG  ] [   ]: BleSerialDevice: open()
2015-09-05 15:51:34.667 xctest[60180:7754033] [DEBUG  ] [   ]: Connecting to service=0xFFE0, rx=0xFFE1, tx=0xFFE1
2015-09-05 15:51:34.667 xctest[60180:7754033] [INFO   ] [   ]: Start discovering peripherals ...
2015-09-05 15:51:34.668 xctest[60180:7754033] [DEBUG  ] [   ]: Waiting for peripheral to be discovered ...
2015-09-05 15:51:35.411 xctest[60180:7754082] [INFO   ] [   ]: Found peripheral: <CBPeripheral: 0x1003335d0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-05 15:51:35.412 xctest[60180:7754082] [DEBUG  ] [   ]: Stop scanning
2015-09-05 15:51:35.412 xctest[60180:7754082] [INFO   ] [   ]: Connecting to <CBPeripheral: 0x1003335d0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = disconnected>
2015-09-05 15:51:35.676 xctest[60180:7754084] [DEBUG  ] [   ]: Connected to peripheral <CBPeripheral: 0x1003335d0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-05 15:51:35.678 xctest[60180:7754084] [TRACE  ] [   ]: Discovered services for peripheral <CBPeripheral: 0x1003335d0 identifier = D92ECAAB-51A5-44D5-8C6C-536CD797867E, Name = "BleIos", state = connected>
2015-09-05 15:51:35.678 xctest[60180:7754084] [DEBUG  ] [   ]: Discovered service <CBService: 0x10011fff0>
2015-09-05 15:51:35.836 xctest[60180:7754084] [TRACE  ] [   ]: Discovered characteristics for service <CBService: 0x10011fff0>
2015-09-05 15:51:35.836 xctest[60180:7754084] [TRACE  ] [   ]: Discovered characteristic <CBCharacteristic: 0x10040b8f0>
2015-09-05 15:51:35.836 xctest[60180:7754084] [DEBUG  ] [   ]: Tx characteristic supports WriteWithResponse: NO
2015-09-05 15:51:35.837 xctest[60180:7754084] [TRACE  ] [   ]: Subscribing to Rx value
2015-09-05 15:51:35.846 xctest[60180:7754033] [INFO   ] [   ]: Connected successfully
2015-09-05 15:51:35.846 xctest[60180:7754033] [TRACE  ] [   ]: DTR/RTS supported by Serial, resetting
2015-09-05 15:51:35.846 xctest[60180:7754033] [TRACE  ] [   ]: Waiting until subscribed to Rx value ...
2015-09-05 15:51:36.655 xctest[60180:7754082] [DEBUG  ] [IN ]: Updated notifications state for RX characteristic: isNotifying=YES
2015-09-05 15:51:36.682 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-05 15:51:36.682 xctest[60180:7754033] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 1 [0x31]
2015-09-05 15:51:36.682 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 15:51:36.735 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 8 bytes
2015-09-05 15:51:36.736 xctest[60180:7754033] [TRACE  ] [OUT]: Send: A [0x41] T [0x54] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] 0 [0x30]
2015-09-05 15:51:36.736 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 8
2015-09-05 15:51:36.788 xctest[60180:7754033] [DEBUG  ] [   ]: Draining for 300 ms ...
2015-09-05 15:51:36.788 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.053 xctest[60180:7754082] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 1 [0x31]
2015-09-05 15:51:37.053 xctest[60180:7754082] [TRACE  ] [IN ]: Rx value received 9 bytes: O [0x4F] K [0x4B] + [0x2B] P [0x50] I [0x49] O [0x4F] 2 [0x32] : [0x3A] 0 [0x30]
2015-09-05 15:51:37.093 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading
2015-09-05 15:51:37.093 xctest[60180:7754033] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 15:51:37.093 xctest[60180:7754033] [DEBUG  ] [IN ]: Drained 18 bytes
2015-09-05 15:51:37.094 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-05 15:51:37.094 xctest[60180:7754033] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-05 15:51:37.094 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 2
2015-09-05 15:51:37.095 xctest[60180:7754033] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 15:51:37.096 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.450 xctest[60180:7754084] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-05 15:51:37.450 xctest[60180:7754084] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-05 15:51:37.450 xctest[60180:7754084] [TRACE  ] [IN ]: Rx value received 2 bytes: . [0x14] . [0x10]
2015-09-05 15:51:37.452 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading
2015-09-05 15:51:37.452 xctest[60180:7754033] [TRACE  ] [IN ]: Receive: . [0x14]
2015-09-05 15:51:37.452 xctest[60180:7754033] [DEBUG  ] [IN ]: Read 1 bytes, actually received 2 bytes
2015-09-05 15:51:37.453 xctest[60180:7754033] [TRACE  ] [IN ]: 1 bytes in incoming buffer remaining for next receive
2015-09-05 15:51:37.453 xctest[60180:7754033] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 15:51:37.454 xctest[60180:7754033] [TRACE  ] [IN ]: Having current receive buffer: . [0x10]
2015-09-05 15:51:37.454 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.454 xctest[60180:7754033] [TRACE  ] [IN ]: Finish reading
2015-09-05 15:51:37.455 xctest[60180:7754033] [TRACE  ] [IN ]: Receive: . [0x10]
2015-09-05 15:51:37.455 xctest[60180:7754033] [DEBUG  ] [IN ]: Read 1 bytes, actually received 1 bytes
2015-09-05 15:51:37.455 xctest[60180:7754033] [TRACE  ] [IN ]: Ble clear buffer
2015-09-05 15:51:37.455 xctest[60180:7754033] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-05 15:51:37.456 xctest[60180:7754033] [TRACE  ] [OUT]: Send: A [0x41] . [0x81]   [0x20]
2015-09-05 15:51:37.456 xctest[60180:7754033] [TRACE  ] [OUT]: BLE sending bytes range from 0 length 3
2015-09-05 15:51:37.457 xctest[60180:7754033] [DEBUG  ] [IN ]: Reading 1 bytes ...
2015-09-05 15:51:37.457 xctest[60180:7754033] [TRACE  ] [IN ]: Start reading
2015-09-05 15:51:37.701 xctest[60180:7754084] [TRACE  ] [IN ]: Rx value received 1 bytes: . [0x00]
2015-09-05 15:51:37.701 xctest[60180:7754084] [TRACE  ] [IN ]: Ignoring single 0x00 char
2015-09-05 15:51:38.451 xctest[60180:7754082] [TRACE  ] [IN ]: Rx value received 5 bytes: h [0x68] e [0x65] l [0x6C] l [0x6C] o [0x6F]

Here is arduino sketch used for Uno:
void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
  Serial.print("hello");

  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);
}

void loop() {
  // put your main code here, to run repeatedly:

}

You can see Uno's bootloader skips waiting for upload commands and goes right to sketch (see 'hello' in incoming buffer).
Is it Uno's bootloader feature? Can i walkaround it by wiring GPIO directly to USB's DTR?
Update: can i wire HM-10 GPIO directly to pin 13 of USB's ATmega's (see schematics) to make HM's GPIO act exactly like USB's DTR?
Update2:
if uploading to Uno over USB if goes further after Send: A [0x41] . [0x81]   [0x20]:
2015-09-06 15:47:10.452 xctest[1042:33659] [TRACE  ] [OUT]: Send: 0 [0x30]   [0x20]
2015-09-06 15:47:10.453 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.592 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.592 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.592 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.592 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-06 15:47:10.592 xctest[1042:33659] [TRACE  ] [OUT]: Send: A [0x41] . [0x81]   [0x20]
2015-09-06 15:47:10.592 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.596 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.596 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.596 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x04]
2015-09-06 15:47:10.596 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.596 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.597 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 3 bytes
2015-09-06 15:47:10.597 xctest[1042:33659] [TRACE  ] [OUT]: Send: A [0x41] . [0x82]   [0x20]
2015-09-06 15:47:10.597 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.600 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.600 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.601 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x04]
2015-09-06 15:47:10.601 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.601 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.601 xctest[1042:33659] [DEBUG  ] [   ]: STK500:initialize: n_extparms = 4
2015-09-06 15:47:10.601 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 22 bytes
2015-09-06 15:47:10.601 xctest[1042:33659] [TRACE  ] [OUT]: Send: B [0x42] . [0x86] . [0x00] . [0x01] . [0x00] . [0x01] . [0x01] . [0x01] . [0x03] . [0xFF] . [0xFF] . [0xFF] . [0xFF] . [0x00] . [0x80] . [0x04] . [0x00] . [0x00] . [0x00] . [0x80] . [0x00]   [0x20]
2015-09-06 15:47:10.602 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.604 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.604 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.605 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.616 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 7 bytes
2015-09-06 15:47:10.617 xctest[1042:33659] [TRACE  ] [OUT]: Send: E [0x45] . [0x05] . [0x04] . [0xD7] . [0xC2] . [0x00]   [0x20]
2015-09-06 15:47:10.617 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.621 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x14]
2015-09-06 15:47:10.621 xctest[1042:33659] [DEBUG  ] [IN ]: Receiving 1 bytes
2015-09-06 15:47:10.621 xctest[1042:33659] [TRACE  ] [IN ]: Received: . [0x10]
2015-09-06 15:47:10.621 xctest[1042:33659] [DEBUG  ] [OUT]: Sending 2 bytes
2015-09-06 15:47:10.622 xctest[1042:33659] [TRACE  ] [OUT]: Send: P [0x50]   [0x20]


text:
How to precisely control servo motor by changing duty cycle?
I developed a PWM using timer1,using arduino uno and digital output, and identified that when I send a wave with duration of 0.6ms in High level, the motor goes to 0º. If I send 2.1ms, it goes to 180º. I tried to make a relationship between these scales to send the angle and change the time period in order to achieve that angle and it did not work.
I would like to move with a precision of 1 degree, is that possible? Just adjusting the time period.
The model of the motor is mg996r.
Maybe I am missing something.
My code just generates an interrupt over 50 microsencods and I use this to set the frequency of 50Hz and the duty cycle in ms using digitalWrite associated with pin 9.
#include <TimerOne.h>

double t = 0.0;

double period = 0;

void setup()
{
  t = 0;
  Serial.begin(9600);

  pinMode(9, OUTPUT);
  Timer1.initialize(50);
  Timer1.attachInterrupt( timerIsr ); // attach the service routine here
}

void loop()
{
  // Main code loop
  // TODO: Put your regular (non-ISR) logic here
  if (Serial.available() > 0) {
    float grau = Serial.parseFloat();

    // receive data as angle
    if (grau > 180) grau = 180;
    if (grau < 0) grau = 0;

    // set period for that angle
    // relationship developed between angle and period in ms
    //set it to period
    period = (0.00833*grau + 0.6)*1E-3;
  }

}

/// --------------------------
/// Custom ISR Timer Routine
/// --------------------------
void timerIsr()
{
    t += 50E-6;
    if (t <= period) {
      digitalWrite(9, HIGH);
    }
    else if (t < 20E-3) { // periodo max de 20ms -> 50Hz
      digitalWrite(9, LOW);
    }
    else {
      t = 0;
    }
}

UPDATE:
I just got it working by creating a timer1 interrupt on CTC mode with a frequency of 100kHz and counting the necessary time to get increments (~ 10us each) of around 1 degree on my servo motor.
More info here.

The relationship is like a map between 0.6 ms -> 2.1ms and 0 -> 180 angle degrees. It works, but the problem is that it does not work for a precision of 1 angle degree as Arduino Servo Library does...

For a precision of one degree, you need a minimum timer increment of 8.33us, which is optimistic. Your current 50us period gives you a resolution of ~6 degrees.

I tried a resolution of 1us but it didn't work, the motor did not move. Can I achieve this using timer1?

I found that it has a dead band of 5us. So it won't move until the width changes by 5us.

The best is to use 10us Period, instead of 50us.
That precision will be close to 1°

Thanks, @Mathsman, I got it working, you were right! Just created a timer1 interrupt using CTC mode and then generated an output signal with a frequency of 100kHz that I could increment the angle by approximately 1 degree.

Your welcome. I recommended this as I have already tried it.

It has precision of 1.1to 1.2 degrees.


text:
16u2 programming
How does one go about programming the 16u2 on an Uno? I have the isp header (for the 16u2) hooked up to another Uno programmed as ArduinoISP I'm not talking about DFU or USB->UART, I'm talking about using it like a standalone chip (Like, say, a Leonardo or Yun [the 32u4, not the Linux, obviously])

Do you want to use it for something else, or do you want to extent the current firmware on it? I've done the latter to duplicate the reset-output to one of the JP2 headers, so I could use the uno board to program and external atmega over serial. I used DFU to upload, but if you don't care about this DFU bootloader you can use an Arduino-as-ISP to program it. To use the arduino IDE you'd have to create a new board. You can probably copy all/most of it from an ATMega32u4 board.

First you need to write a program for it. There is no Arduino core for the 'XU2, so you will need to write it out longhand. Then you compile it. Then you upload it using ISP. Then you run it. Note that the only pins you have access to on the board are the UART pins, the two on the LEDs, and the 3 on the ISP header.

Plus 4 on jp2, making 9 easily usable gpios, plus 2 status LEDs. And how would I go about making a program, and uploading?

As the OP said, with the ISP, it costs a few bucks on eBay.
Or you can google on how to use one Arduino to program another. That might work too.

@AlexanderM: You use the correct tool.

It doesn't appear to have a linux build. Will try with wine, though.

Uh-Oh, it failed, alternatives?

There's no need to use atmel studio for this - the same compiler installed with the Arduino suite will work - see the source of the existing firmware in the Arduino repositories for an example.  However, that does not mean that the chip will be supported in the IDE or the Arduino libraries, unless you find a version which someone has extended for this.

True, but getting USB and QTouch working is much easier with AS than trying to get the standalone libraries to work with standalone GCC.


text:
How to make the Yun allow access to a resource
I have replaced /www folder on the Yun (backing it up first), how do I make it so the Yun will redirect to the new index.html? It, right now, gives Access to this resource is forbidden when I go to yun-name-here.local
Edit: I guess it's relevent to add I can do it fine with yun-name-here.local/index.html meaning it works. The real question is how to make it so I don't need to type /index.html (HURRAY LAZINESS!)
Edit II: It's Kittens game

Did you try editing the web server configuration?

web server config?

@IgnacioVazquez-Abrams I think I borked it... I replaced /etc/config/uttpd with it's backup after modifying and now I can't connect

fixed the borkedness

Which web server did you install on it?

@IgnacioVazquez-Abrams manly face Kittens Game manly face fail

That sounds like a web application, not a web server.

@IgnacioVazquez-Abrams It's both. I downloaded it from the git repository, and moved it to /www directory

Nothing in that repository is a web server.

The question still stands, though


text:
Lightblue Bean BTLE tinkering
How does one modify the Bluetooth settings, like services or pincode, on a light blue bean?
Ps I'm on Android
http://legacy.punchthrough.com/bean/ if you don't know what I'm talking about


text:
Arduino I2C via USB Serial cable?
An Arduino UNO is given.
I want to establish an I2C communication channel between Arduino UNO and a Linux Machine which have only USB ports available to communicate with peripherals.
Currently I can communicate with Arduino board via USB Serial cable (TXD and RXD which are on pins D0 and D1).
My question is: is there any way to use those pins as SCL/SDA to communicate via I2C with Arduino Board?
I am thinking that the only way to accomplish this is to buy an USB to I2C Adapter and connect to A4 (SDA) and A5 (SCL); but maybe I'm wrong.
I have also seen that way: https://gist.github.com/kraftb/8c0bbcc35a9778608d74. Basically to use an intermediate Arduino board.

@LookAlterno Because it's faster?

What about Serial port speed? USB speed is not limited by Serial speed from Arduino UNO?

Because the Uno uses an actual UART between its main and USB chips, you'll only get high data rates over USB if you find a high baud rate that works for both.  On an actual Uno they are both closely related ATmegas running from comparable clock sources, so divider inaccuracies at least won't be an issue.

This seems like it might be an XY problem - do you really want I2C, or do you just want to move data faster?

I'm voting to close this abandoned question because it arises from a misconception

With SoftwareI2CLibrary you can specify other pins, I haven't tested it with RX and TX.
I would recommend the USB serial interface is fast (2M baud) in perspective to that we are discussing a Arduino with a speed of 16MHz.

The Arduino contains a USB to UART adaptor (made from an ATMega16U2) which then connects to the UART pins 0/1. If you want a different protocol you will need a different adaptor that works with your desired protocol.

This may somewhat miss the point - even if you reprogram both chips on the Uno, you'd have to bit-bang I2C between them, which is certainly slower than using their hardware UARTs.  Now if you could do some surgery to connect their I2C pins it might be a different story.  But theoretically their UARTs can run faster than I2C's faster mode.

@ChrisStratton Personally I would use a direct USB connection to a suitable microcontroller. Especially as I now have my own modular USB stack for my favourite PIC32 microcontrollers...

This is a bit miss leading, an Arduino can have different USB to Serial IC chip.

A genuine Arduino made within the past few years has an ATMega16U2. If it doesn't then it isn't an Arduino. It's a clone, or a counterfeit device.

If you change your answer to a "Arduino UNO", then you are correct. And counterfeit? It is open hardware and the reality is that there is a lot of different "Arduino" USB-serial solutions out there.

Arduino is a brand. It is trademarked. While it is open source hardware the name isn't. Arduino Uno, Arduino Mega 2560, etc, are all made by Arduino and Arduino only. Or they have been counterfeited.

@Majenko, I have old Arduino originals with other USB-serial IC than the ATMega16U2!

Yes, old ones. Current ones have the ATMega16U2. I too have Uno R2 that has the 8U2. But the current version, the R3, that has been out years, uses the 16U2.

In case you hadn't noticed, the question specifically talks about Arduino UNO. Ergo the answer must be about the Arduino UNO. There are three classifications of "Arduino" device: Genuine (e.g., the Arduino UNO made in Italy), clones (devices based on the Arduino hardware but crucially not called Arduino) and counterfeit (devices that claim to be an Arduino UNO but aren't made by Arduino). The latter infringes the Arduino trademark and are actually illegal. Also they are usually of very inferior quality.


text:
ATmega328P and other chip sharing clock
I am moving my Arduino project to another platform, operating at 3.3V. (5V from USB not useable due to some 3.3V-only chips in the design) Having read about this it seems that 12MHz is a good speed to use, and my stock USB to UART converter, CH340G does call for a 12MHz crystal.
Now what is the best way to share this 12MHz clock between CH340 and ATmega328P, eliminating an extra crystal? Can I tap off XO pin from CH340 with crystal attached, and carry it to the XTAL1 pin of the ATmega?

EDIT

If sharing clock requires some fine tuning, what about building a reference clock out of 74LVC1G04 and 74LVC1G06 chips and clock both chips from this?

It is always a good idea to provide documentation for the devices in question.

All the documentation I have is in Chinese so not really helpful here. And the only interesting thing here is that it have the standard crystal across inverter clock circuitry.

Sharing a crystal between multiple devices is a very bad idea. The crystal is only a piece of the oscillator, the rest of it being a small bit of circuitry within the IC itself. Having multiple ICs connected to the same crystal will cause them to fight over who is driving it.
The datasheet for the CH340T/R, which I was able to find in English, says the following:

When CH340 chip is working normally, the outside must supply 12MHz clock signal to XI pin.

This seems to imply that you can feed an external 12MHz clock into the chip and it will work. So we take the clock from the '328P and pass it to the '340G.
Programming the CKOUT fuse on the '328P will cause the internal clock to be output on CLKO, which we then connect to XI of the '340G. This means that that you will lose PB0/D8, but no longer need a second crystal. This also means that you will be unable to use the prescaler since doing so will affect the clock output.

I am saying that I connect the crystal to '340G and tap off its XO pin to '328P.

Unlike clkout, crystal out is not meant to drive external loads - if it works or not depends on inplementation detail of the oscillators.  If you insist on trying, consider loose coupling via a large resistor or small capacitor.  Do you have timing needs which actually require a crystal? What about a 32u4 instead of an m328p plus distinct USB?

Or even living with the 8MHz from the internal oscillator.

Often is is possible. The range of the crystals signals' max swing are small. Where the XI pin needs to accept these small AC signal. Hence on the FUSE on the ATmega. Which also enables the XO as a Hard clamp to excite the crystal. The crystal dominates the voltage making it small. Additionally, it is important to have the proper parallel capacitance on both the input and output of the crystal. When the XO(0) is tied to the XI(1) along with the crystal and its parallel capacitor, noting that it is in the range of 10-40pf, the total parallel capacitance will be significantly increased. Where it may be possible to reduce the XO(0)'s parallel capacitor, if XI(1) does not add too much.
Anyone attempting this should really inspect the signal on an Oscilloscope to ensure the nature of the wave form is stable and stress its tolerances. Likely by changing the parallel capacitors to find the min and max's before failure. And varying VCC of both chips across is allowed ranges. As to determine the ranges is not unacceptable.
That said the datasheets refer to a version with a suffix T that have an CKO or Clock output on pin 1. That would be best and change the ATmega's FUSE for TTL input. Where Ignacio's answer is very valid and stable. Just the opposite direction.

I would point out that you will have the issue that 12MgHz is not a typically supported F_CPU speed in the code. I have toy'ed with changing the speed in the past, as to do just what you are attempting here, but with a different clock source. And found it requiring so many changes to the Arduino libraries, which are typically #IF'ed to either 8 or 16 so many places not using a nice formula, it was not worth its cost savings versus cost in maintenance. As a starter you may want to refer to SE: "Arduino at 11.0592MHz".


text:
Assuring an unsigned long int?
Basic question: How far do I have to go to assure that integer math is done correctly? For example, this is probably overdone:
unsigned long burnTime = 0UL;
unsigned long curBurnTime = 0UL;
// Do some stuff that sets the above variables to millis() at various times
// Later on...
unsigned long adjustedBurnTime = (unsigned long) ((burnTime + curBurnTime) / 1000UL);

Would the math be done correctly if I went to a more minimal last statement (since all the elements of the equation are unsigned longs)? Like this:
unsigned long adjustedBurnTime = ((burnTime + curBurnTime) / 1000UL);

Or even:
unsigned long adjustedBurnTime = ((burnTime + curBurnTime) / 1000);

Only one way to really find out! Compile them both and disassemble them.

@IgnacioVazquez-Abrams either that or read through the GCC compiler code. :) Printing output to serial is, of course, the easiest!

If argument of math operation is unsigned long then it should be calculated in long precision and potentially shortened when assigned. I.e.second case should be ok. But double checking in assembly is the best choice how to save time when provides strange results.

This issue is very relavent to time; check out http://playground.arduino.cc/Code/TimingRollover it outlines the same issue. Where I would agree with TMA, in that since all are casted the same, it is not needed. However, I always play it safe. In case the casting was changed.

Thanks for the thoughts. I'm not savvy enough to check the assembly code so I'll try the serial output route. @mpflaga, I agree better safe than sorry. I was just hoping to be (safely) a little less redundant in my code but why take a chance, I suppose. Since I'm tracking runtimes it will be an issue.

I compiled all three of the examples above and the result was three identical hex files. Unless I'm missing something it seems I've answered my question. ...Am I missing something?

No, your're not; the hex file exactly represents your code (plus some loading instructions). If two hex files are identical, and presented to the same loader, the results (the memory loads) have to be identical.

Any good C manual will tell you the result type for each basic math operation on given types. But briefly, the basic math operators return a result as wide as the widest operand, with the narrower operand being widened to match the wider one, if they differ. The same with assignment: assigning a result of a given type to a variable of the same type will not involve any conversion.
tl;dr: No, you're not missing anything. You don't need any casts in your example.
PS: One thing you do need to be aware of is whether any of your intermediate results will overflow the arithmetic type you're using. For example, the final result may be not exceed an unsigned long but the expressions (burnTime + curBurnTime) must also not exceed it. This is a greater concern with smaller data-types, of course.
PPS: Good on you for tackling fixed point arithmetic rather than just reaching for the floating-point library!

Thanks, that's a great answer because it explains not just whether but why. My uninformed guess would have been the opposite. Also very appreciative of the warning on intermediate results; it would have been just a matter of time until that bit me.


text:
Are there any Analog pins on the mega that can not be used as Digital?
I am using both Arduino nano and Arduino mega boards in my projects.  I got a nasty surprise the other day when I learned that, on the nano, Analog pins 6 and 7 can not be used as digital pins.
Are there any Analog pins on the mega that can not be used as Digital?

No, the ATmegaXXX0 has no analog pins without GPIO capability.
Additionally, the ATmegaXX8PB adds GPIO capability to the other analog pins plus a couple of the supply pins, so if you can convince someone to slip one of those on instead then you will gain two GPIOs (a respin will be required to access the ones on supply pins). Note that the core will also need to be modified, but it's only a couple of quick changes.

On https://www.arduino.cc/en/Main/ArduinoBoardNano it says:

Analog pins 6 and 7 cannot be used as digital pins.

There is no such corresponding statement on https://www.arduino.cc/en/Main/ArduinoBoardMega2560 and judging by the datasheet all of the analog pins can be used as digital pins.


text:
How to alter joystick values with Arduino Uno?
I'm trying to use an Arduino Uno to read values from a 2-axis joystick analogue input, and alter these values. Rather than the true joystick values, I arithmetically convert the values at neutral to range between 0 - 5, with 'neutral', i.e. when the joystick isn't being pushed, being at roughly 2.5 for each axis. These joystick values currently output to a live text file, to be graphed in real-time. One function I'm trying to implement is that when the joystick value is greater or less than a defined value (e.g. in the code, greater than 4.55, or less than 0.5)  that the Arduino sets that point to be the new 'neutral' position (i.e. 2.5), however my code at the moment isn't working and I'm not sure how to go about attempting this.
Any insight would be most appreciated!
Cheers
const int buttonPin = 2;
const int successPin = 13;

int buttonState = 0;

void setup()
{
// initialize serial communication at 9600 bits per second:
Serial.begin(9600);
pinMode (buttonPin, INPUT);
pinMode (successPin, OUTPUT);
while (digitalRead(buttonPin) == LOW) {};
}

void loop () {

int sensorValueY = analogRead(A0);
int sensorValueX = analogRead(A1);

//arithmetic operation that maps output values from 0 - 5 instead of 0 - 1023
float voltageX = sensorValueX * (5.0 / 1023.0);
float voltageY = sensorValueY * (5.0 / 1023.0);
Serial.print(voltageX);
Serial.print(" , ");
Serial.print(voltageY);

if (voltageX >= 4.55) {
  voltageX == 2.5;
  successPin==HIGH;
  delay(1);
  successPin==LOW;
}

if (voltageX <= 0.5) {
  voltageX ==2.5;
  successPin==HIGH;
  delay(1);
  successPin==LOW;
}

if (voltageY >=4.55) {
  voltageY == 2.5;
  successPin==HIGH;
  delay(1);
  successPin==LOW;
}

if (voltageY <= 0.5) {
  voltageY ==2.5;
  successPin==HIGH;
  delay(1);
  successPin==LOW;
}
Serial.println();

}

Sorry, I read your post and the comment under @Nick Gammon's post but I couldn't understand what you are trying to achieve. Can you give some examples, for instance "i move the joystick all the way to the left: now it reads 0.1. I set this as new idle...." and so on? Otherwise it becomes very difficult to understand your needs..

Okay, so when the joystick moves all the way to the left, the analogue input value drops to 0, say. At neutral the value is roughly 2.5. What I want is the Arduino to then set the value of 0, when fully left, to 2.5, such that when the joystick physically returns to neutral, the value would read 5. Same would go for all the way up, for example, where the value would normally read 5. At near 5, I want the joystick to set to 2.5 (its starting value), such that when it physically returns to neutral i.e. not pushed, the value would then read 0. (Hope this makes a bit more sense!)

Ok... Now I understood ;) I can't understand the reason to do so though ;)

Anyway... When the joystick returns to neutral it'll be 0 again, so it will go back to 2.5 again...

if (voltageX >= 4.55) {
  voltageX == 2.5;
  successPin==HIGH;

The last two lines (and all similar ones later) are wrong. == is for comparing, = is for assigning. So change it to:
if (voltageX >= 4.55) {
  voltageX = 2.5;
  successPin = HIGH;

You did that in a lot of places, so fix that up and get back to us.

const int successPin = 13;
...
  successPin = HIGH;

Assuming you fix the compare to an assign you will get an error message here. You define successPin as 13, and then try to change it to 1 (which is what HIGH is defined as). Do you mean, to write to that pin? Like this?
digitalWrite (successPin, HIGH);

You will need to change all those as well. And if you are hoping to see an LED on the pin flash, 1 ms is quite a small interval.

For lots of the LEDs on Arduino boards, 1 ms is long enough to see an LED flash; for that matter, a few microseconds is long enough.

I didn't say he wouldn't see it flash. I warned him the flash would be short. :)

Thanks so much for the input! The issue I now have is that although the Arduino sets >4.55 and <0.5 to be the new 'neutral' point of 2.5, when the joystick physically returns to neutral, i.e. when the values are under the defined thresholds, then rather than going from 2.5 to 0, say, the values go from 2.5, back to 4.54 and then back to 2.5 at physical neutral again.
What I'm trying to have is that once set to the new threshold of 2.5, that value stays set, such that when the joystick physically returns to neutral it's idling somewhere around 0, relative to the new threshold. Cheers!

It seems to me that you want the map function (or write something similar yourself). You want, as far as I can see, to unconditionally map the joystick input to a new range.


text:
How does RXD/TXD request signal look betwen 16u2 and 328p on oscilloscope?
I have a broken Arduino Uno. The man tells that he connected power supply and USB at the same time.
I got the new 16u2 (empty) chip. then asked my friend to re-solder it. He was using an air soldering station, but that did not work out. Then I try do that by myself. After 6 or 8 time I was successful. I think.
With stk500v2 programmer thru ICSP I burned in the hardware called:
Arduino-COMBINED-dfu-usbserial-atmega16u2-Uno-Rev3.hex

which I found in Arduino "hardware" folder.
I then burned bootloader to 328p controller:
optiboot_atmega328.hex

That hardware also from Arduino folder.
The problem is that I can upload sketch
error: avrdude: stk500_getsync(): not in sync: resp=0x00

meaning that device not recognizing.
My PC founds Arduino in device manager. 328p with ICSP programmable and working. (checked with blinking.hex 13 pin)
When pressing reset button the 13 led turns of then blinks fast several times that means the boot loader installed property.
Right after pressing upload the Rx blinks 3 times after that I am getting error.
Strange isn't it?
So what I what to know:

I suppose the first must start blinking Tx led?
Can anyone show me how must look like rxd txd interrupts?
So about my assumption that I overheated 16u2 and it does strange things. What are you thinking about that?

You used both ICSP connectors, right?

yes. one to 16u2 near 16u2 another to 328p near 328p

Have you plugged an oscilloscope on RX and TX already? Could you post a picture of what you observed?

I cant put picture. but I can describe... I see 3 negative packets about to 1.7 V in 5ms. weight of packet about 3mm and its RxD scope.. on TxD I see only all line pushed  down about 0.3V for a moments... but I feel that its not that what I want. can anyone answer my question before? which first impulse I must see RxD or TxD because the impulse what I described is RxD.

See screenshot below. The Rx on the Uno (incoming data) should flash first.

The programmer sends STK_GET_SYNC and the board replies STK_INSYNC:
Sent: STK_GET_SYNC / CRC_EOP  (30/20)
Got: STK_INSYNC / STK_OK (14/10)

Afterwards you see the bigger blocks on the lower line as the programmer sends the hex code to the board. Then about half-way through the bigger blocks are on the top as the board sends back the verification data (by reading the flash back).
The little blips would be the other side acknowledging a packet of data.

For more details see What happens when code is uploaded using the bootloader?


text:
Pixel font resources in byte format
To write text on a dot-matrix or LC display with an Arduino you need to have a pixel font in byte format (i.e. typically 1 bit = 1 pixel).
On the Internet I have found surprisingly few resources for this.
Most of the results when searching for pixel fonts return true-type fonts (or similar) which are rather complicated to convert to obtain a satisfying result.
Also, most of the fonts are rather high resolution.
Any good resources I have missed?

Try looking at lcd libraries. Those have some fonts embedded in it. Or search for 5x7 fonts.

Mainly I am wondering if there is a site collecting a few pixel fonts to choose from, which would be quite useful. (I found a few fonts here and there, mostly in libraries. Unfortunately, all had only ASCII.)

What other characters do you need? Memory is limited, so it's a good idea to limit the amount of characters.

Umlaute :) 4321

Just an umlaut, or letters with umlaut? If the latter you need some additional pixels (height). You can't make an ä with only 5x7 pixels.

Well, actually I'd even prefer 8 pixel height.

The UTFT library has a SmallFont which is 8x12. Not sure whether this is too big for you, but it could be worth looking into. It is ASCII only, so you might want to add some characters yourself. But as someone mentioned, memory is limited, so add sparingly.

Moreover the creator of the library put online a tool to create new fonts starting from an image (here) and some other fonts made by other people (here)

Try the Dot Factory and The LCD Assistant. I'm happy with both. Let's you create any Windows font.

You could create the character data yourself. I've built a little script for a similar prospect a while ago that does translate a matrix of checkboxes to a bit-array: http://jsfiddle.net/qrsye920/


text:
Serial Monitor shows a continuous "word salad" without a loop
I have written a little program which should (at the end) host a little website. This is just my setup. But for some reason, it writes "srl?" endlessly onto the serial monitor. I just connected the ESP8266-01 to my Arduino UNO, using 115200 baud with the nodeMCU board. Using different boards results in an error telling me I should use nodeMCU.
As I have written in the title, I do not understand how it can produce an endless output without a loop with Serial.print/write in it.
#include <ESP8266WiFi.h>

const char* NAME = "x"; //ssid
const char* PWRT = "x"; //password

WiFiServer server(80);

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

  Serial.printf("connect with %s \n", NAME);
  WiFi.begin(NAME, PWRT);

  while (WiFi.status() != WL_CONNECTED) {
    delay(1000);
  }

  server.begin();
  Serial.printf("webserver open, access with %s\n", WiFi.localIP().toString().c_str());

}

void loop() {
  // put your main code here, to run repeatedly:

}

"I just connected the ESP8266-01 to my Arduino UNO, using 115200 baud with the nodeMCU board". What NodeMCU board? The ESP8266-01 is not a NodeMCU. How did you connect everything up? If your Arduino uses SoftwareSerial to communicate with the ESP8266-01 at 115200 baud, that will not work reliably. Use 9600 baud.

you have a reset loop

What do you mean @Juraj?

@StarCat like this https://virtuino.com/images/arduino_esp8266_connections.png but to RX and TX instead of Pin 2 and 3

Please post the actual serial output and how you connected arduino and esp

You need to show the actual output. "Word salad" could be anything. For example, are the words ""connect with" and "webserver open, access with" part of this salad?

A reset loop is where code starts to do something (like print a message) and then encounters an error condition, which causes it to crash and reset. Then it prints the message again, crashes again, and so on.

The ESP8266WiFi.h is for running on an ESP8266 host, but your are trying to use it on an Arduino Uno. This caused the crash of your sketch on Arduino Uno.
Based on the connection diagram you provided, you are using the ESP-01 as an wifi-shield and the ESP-01 by default is having an AT commands firmware. In order to use the ESP-01 as a wifi shield, you need an library like WiFiEspAT.


text:
Best strategy to parse 5 byte arrays to find a pattern
Ok here it goes, my first ever question posted to stackexchange! Please be gentle on me!
I am using an Arduino UNO (at the moment, will move to a faster micro later - but still use an Arduino sketch) to read in data as an SPI slave to extract the display data off of a commercial product that has no other exploitable data output that I can use. I am using a very generic sketch that Nick Gammon posted for the purpose of demonstrating the capability - and I can read the SPI data coming in ok. (Thanks Nick!)
The data is being pulled from a commercial product that has a 8 character, 5X7 dot matrix LED display that was specially made for this product and after exhaustive searches and emails to Broadcom/Avago - has no datasheet, but there are slightly similar products that I was able to use to get a bit of a handle on how the part works, I just went on the assumption that even if the interfaces are not the same, they probably didn't reinvent their command structure. However; the display doesn't have a nice driver chip embedded like your typical parallel LCD display.
I had to do a bit of reverse engineering using a logic analyzer to figure out:

It is SPI data at 4MHz.
The gist of the commands coming in and in what order
Used excel to convert the pixel mapping of the display to the font actually getting displayed on the device.
That the displayed font/text for each of the 8 characters is made up of 5 bytes - where the bit positions of those bites end up lighting a tiny LED in the display so the letter 'H' looks like 0x7F, 0x08, 0x08, 0x08, 0x7F. Each byte controls a column of 7 LEDs, ignoring a row.

Right now:

I am using a modified version of Nick's slave sketch to simply extract the first 44 bytes of the command string to display something on the display
all that is important to me is the 40 bytes after the first 4
because those bytes are what get displayed. I am taking 5 elements of the 44 byte array that I know correspond to a character and spitting them out on the serial monitor such as:
0x00, 0x01, 0x5F, 0x11, 0x00 // i
0x7F, 0x08, 0x08, 0x08, 0x7F // H
etc...

And now after a lengthy introduction - my actual question:
I need to parse the patterns of each of the 5 bytes that makes up a letter and convert it to ASCII text so that the actual word is displayed on the serial monitor.
Back when I used to use another programming language / environment on PICs we had things like LOOKUP and LOOKDOWN which made comparing patterns a bit more abstracted, which is weird considering Arduinos...
I need help coming up with a function that takes the 5 bytes that I need to build each letter from and maybe compares it to an array that represents each possible letter and then maybe passes the matching result to another function to build / concatenate the displayed word out of those characters? That method sounds wildly inefficient, but it's all my little brain can come up with and I'm drawing a blank on how to even do that... I don't need a lot of error checking because thus far the data I'm getting is spot on with what I see on the actual display - we are also talking one 8 character word (max) at a time and it is fairly static, no scrolling words or a lot of chatter - just a single word or some data that changes relatively infrequently. But the displayed data can be different enough than the last to make trying to match entire words out of the question unless it's a side feature to speed things up. I think work properly it needs to work on one character out of 8 - one at a time. Another thought is maybe summing the 5 bytes to determine if we have a match or not, but I'm not sure if two different characters might end up having the same sum? Math is not my strong suit. Thanks for any and all help.

i see no reason for such a lengthy post ... it appears that you want to decode the data going to a 5x7 dot matrix display and determine which character is being displayed ... the data arrives on SPI .... am I understanding it correctly?

How many different characters are likely to be displayed? 10? Can't you just use a lookup table?

So it is a 5x7 LED (so 35 different LEDs per character) and thus the 5 characters (at 8 bits each) would allow for 40 combinations, and so 5 are unused. Is this right so far? A lookup table of all the actual characters that arrive is probably the easiest, you could store that in PROGMEM.

Comparing all the bytes for every character may sound inefficient, but the MCU is pretty fast. So unless you have something else that requires a lot of computation, this will be plenty fast enough. Though you could indeed try to do some tricks, like adding the bytes (as you suggested), or XOR the five bytes. I like to use excel for these things. Put the 5 bytes in five columns. Put your formula in the last column. Then check if all calculated values are unique. You could also try using only certain pixel-columns.

If you post the pixel data for all the characters, I'm willing to do this for you, as it sounds like a fun exercise. Though as I stated, it's probably unnecessary.

If you have a large data set you could implement a tree search. The top of the tree is all the possible first bytes. The next layer is the possible second bytes following each possible first byte - etc. Or you could make a partial tree - where you have a number of arrays of bytes 2-5 (which could actually be a 32-bit integer) and those arrays are grouped by the first byte. If you have things in order you could also "divide and conquer" your data set instead of doing a linear search. There's plenty of algorithms to choose from.

Another thought: a 5x7 array of pixels gives you 35 bits of data. If you can find 3 pixels that never get turned on you could discard those and compress the data into 32 bits. That can be easily represented as a number the Arduino can handle and make searching easier. Especially if you were to use divide and conquer to narrow in on the data, since > and < is easier with a pure number.

XOR would be a bad choice for creating a "checksum". Symmetrical letters (of which there are plenty) will negate most of the XOR operation leaving you with just the value of the middle byte.

This is really a pure programming problem rather than an Arduino one, but to get you started, you could do a table lookup, like this:
#include <stdio.h>
#include <string.h>

// number of items in an array
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

unsigned char patterns [] [5] =
  {

    { 0x7F, 0x08, 0x08, 0x08, 0x7F },   // H

    // other byte patterns here

  };  // end of patterns

char patterns_converted [] =
  {

  'H',

  // other letter equivalents here

  };  // end of patterns_converted

char convert_pattern (unsigned char what [5])
  {
  for (int i = 0; i < ARRAY_SIZE (patterns_converted); i++)
    if (memcmp (what, patterns [i], 5) == 0)
      return patterns_converted [i];

  return '?';

  } // end of convert_pattern

int main ()
{

  unsigned char test1 [5] = { 0x7F, 0x08, 0x08, 0x08, 0x7F };
  unsigned char test2 [5] = { 0xAA, 0xBB, 0xCC, 0xDD, 0xEE };  // won't be found

  char x = convert_pattern (test1);

  printf ("Result for test1 is %c\n", x);

  x = convert_pattern (test2);

  printf ("Result for test2 is %c\n", x);

}

You would find out all your bit patterns and put them in the patterns array, and then put the equivalent letter in the patterns_converted array.
The function convert_pattern does a linear search of the table of patterns, returning the corresponding letter, or "?" if not found.
I coded that in pure C++, but since the Arduino IDE basically uses C++ you should be able to convert it for your use.

Thank you-Thank you! Nick Gammon saves the day yet again! I was able to convert your pure C++ to Arduino-C++ and build my lookup table and test cases and it works beautifully! Now I just have to add a little code to compare the last displayed data to new to keep it from needlessly updating. Sorry for all the words - I do have trouble with being concise.


text:
I'm planning on using 2 arduino boards for my project. Should I use 2 voltage regulators for project or use 1 for both?
For context, my first board would contain a motor circuit with an L298N motor driver while my second contains a controlled heating system that uses 2 relays with PTC heating elements, DHT11 sensor, I2C LCD display, and 1 12V exhaust fan.
My input would be a 12V DC power adapter and I'm going to use it to run the motor, the fan, and the 2 heating elements.
Since I want to minimize the chances of my boards from overheating, I want to reduce the input voltage for my board to around 7V, so I want to integrate a voltage regulator circuit.
Should I include 2 voltage regulator circuits or should just utilize 1 for both boards?

The Uno already has a voltage regulator. Can you clarify (perhaps with a diagram) what you are trying to do exactly?

I dont want to overheat my arduino boards and I've heard from a few sources 12V could potential do that even thought its within range

If you are that concerned with heat from the built in linear power supplies, consider using an external switching power supply.  However, the current draw of only the 2 processors is so low that this switch may not be noticeable.

Nick and st2000, OP writes in the question "I want to reduce the input voltage for my board to around 7V, so I want to integrate a voltage regulator circuit" (and it was not edited)

the Q is "Should I include 2 voltage regulator circuits or should just utilize 1 for both boards?" and the answers is 1 or 0

but why 12 to 7 and then 7 to 5? use a 12 V to 5 V converter and power the boards over the 5 V pin or USB connector.

If you want an external voltage regulator, one should be plenty. In that case I would regulate down to 5V (not 7V) and connect that to the 5V pin on the board.
An alternative might be to just run the 12V from the battery through a diode or two, thus dropping 0.7V for each diode. Use a diode that can handle a reasonable amount of current, eg. 1N4004. Then you would still connect it to the normal "power input" socket (not the 5V pin).
I assume that the heating, motors, etc., are not being powered by the Arduino board, but directly from the battery via some sort of switching, like a MOSFET or a relay.

I would use a buck or SEPIC regulator and feed Vin on each of the Arduino with about 7.5V from the one regulator. I prefer using Vin because of the additional filtering I get. Also be sure you are using appropriate drivers for your loads, such as relays or MOSFETs.
Consider replacing the L298N with a newer part, that will lose about 3V on the motor leads which is burnt up as heat in the device. There are many others that use MOSFET outputs which will drop less them 0.2 volts.


text:
Arduino UNO Power interruption
Do you have to upload the UNO after the applied power is disconnected?
Does the UNO retain the code without any power?
And when the power is disconnected, if the code is retained, will the timers retain their values?
Thanks

Do you have to upload the UNO after the applied power is disconnected?

No.

Does the UNO retain the code without any power?

Yes.

And when the power is disconnected, if the code is retained, will the timers retain their values?

No.

This answer simply add some detail to that provided by VE7JRO to make it more generally applicable but this does look rather like a school assignment.
Program code is stored in flash memory and this is retained after a power down.  It is not necessary to reload it. The registers which hold timer values or other data from a running program are stored in RAM memory and this is lost on power off. It is possible also to save some data from a running program in EEPROM (or in some cases flash memory) which also survives after a power down.


text:
Digispark: check if the USB host is connected
I am trying to detect if the digispark device is actually connected to a host (i.e. the USB line is "active") vs. just powered.
The issue: if I send a keypress while the data line is disconnected, the code hangs perpetually in sendKeyPress.
My theory is that it keeps looping in while waiting for USB to be ready, which makes sense.
    while (!usbInterruptIsReady()) {
      // Note: We wait until we can send keyPress
      //       so we know the previous keyPress was
      //       sent.
        usbPoll();
        _delay_ms(5);
    }

I tried to use the macro usbInterruptIsReady() before calling sendKeyStroke in the main, but with no success. I would expect to see a function that keeps track of this state, but apparently there is none.
Also: it doesn't seem like what I am trying to accomplish being extremely weird, so my expectation is that someone else could have stumbled upon this and figured out a reasonable workaround.
I would like to avoid setting up a watchdog timer.
Code below for example hangs when the device is powered but not connected to a PC.
Thanks
Background: https://hackaday.io/project/191762-automatic-workstation-locker
#include "DigiKeyboard.h"
#include "Arduino.h"

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  DigiKeyboard.update();

  DigiKeyboard.sendKeyStroke(0);
}

void loop() {
  static uint8_t bit = 0;
  bit = 1 - bit;
  digitalWrite(LED_BUILTIN, bit);
  DigiKeyboard.update();
  DigiKeyboard.sendKeyStroke(KEY_Q);
  delay(2000);
}

I've deleted all the comments which had descended into sledging. Please remember, comments under the question are for clarifying it, not attacking each other.

If you wish to complain about the way this site is working please raise an issue on our Meta site.

The question looks reasonable to me, however @Paperino you should not keep re-posting the same question. Try to salvage the original one where possible. As it is now deleted I suggest we run with this one.

The Digispark does not have a proper hardware USB implementation. It is possible that you simply can't do what you are attempting to do. A search I did indicated you are not the only person attempting to do this.
You may want to switch to one of the Arduinos that have a hardware USB interface like the Leonardo or Micro.
I should point out that the Digispark is not an Arduino, and it has its own forum where you may possibly get an answer from their own community.