text:
Arduino Ethernet Client crashes after obtaining values from string
My Ethernet server keeps crashing after pulling the RGB values from the string. It remains connected if I'm just toggling a pin, but whenever the string has the rgb values in it, the RGB values are pulled, the LED changes but then the server crashes and won't take any more requests. Do I need to restart the server after it plucks the RGB values for another read? If so, how would I go about doing this?
Thanks, James :)
Example HTTP request that causes the crash: /?LED=B233+G011+R133&t=T HTTP/1.1
    #include <SPI.h>
    #include <Ethernet.h>
    #include <string.h>

    byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
    byte ip[] = {192, 168, 0, 102 };
    byte gateway[] = {192, 168, 0, 1 };
    byte subnet[] = {255, 255, 255, 0 };
    EthernetServer server(84);
    ;

    char* redstring={0};
    String blue1;
    String green1;
    String red1;
    String testString = "0123456789";

    int blue;
    int green;
    int red;
    int been=0;
    int b=0;
    int g=0;
    int r=0;
    //////////////////////

    void setup(){

    pinMode(11, OUTPUT);
    pinMode(9, OUTPUT);
    pinMode(7, OUTPUT);
    pinMode(6, OUTPUT);

    //start Ethernet
    Ethernet.begin(mac, ip, gateway, subnet);
    server.begin();

    //enable serial data print
    Serial.begin(9600);
    Serial.println("SERVER RUNNING HTTP / GET");
    }

    void loop(){
     ////////////////////////////////////////
     EthernetClient client = server.available();
if (client) {
while (client.connected()) {
  if (client.available()) {
    char c = client.read();

    //read char by char HTTP request
    if (sizeof(redstring) < 100) {

      //store characters to string
      redstring += c;
      //Serial.print(c);
    }

    //if HTTP request has ended
    if (c == '\n') {

      ///////////////////////////////////////////

      Serial.println(redstring);

      client.println("HTTP/1.1 200 OK");
      client.println("Content-Type: text/html");
      client.println();
      client.println("");
      client.println("<link rel=\"shortcut icon\" href=\"data:image/x-icon;,\" type=\"image/x-icon\">");
      client.println("");
      client.println("<TITLE>Arduino GET</TITLE>");
      client.println("");
      client.println("");

      client.println("
HTML GET
");
      //change ip back if not local
      client.println("<FORM ACTION=\"http://192.168.0.102:84\" method=get >");

      client.println("JQUERY: <INPUT TYPE=TEXT NAME=\"LED\" VALUE=\"\" SIZE=\"25\" MAXLENGTH=\"50\">
");

      client.println("<INPUT TYPE=SUBMIT NAME=\"t\" VALUE=\"T\">");

      client.println("</FORM>");

      client.println("
");

      client.println("");
      client.println("");

      delay(1);
      //stopping client
      client.stop();
      /////////////////////
      //readString = Character.toUpperCase(readString);
      for (int i = 1; i < sizeof(redstring); i++) {
        if (strchr(redstring, 'B') && && redstring[i+1] > -1) {
          blue=redstring[i+1, i+4];
          analogWrite(11, blue);
          delay(1000);
                      }

        if (strchr(redstring, 'G') && redstring[i+1] > -1) {
          green=redstring[i+1, i+4];
          analogWrite(9, green);
          delay(1000);
                      }

        if (strchr(redstring, 'R')&& redstring[i+1] > -1) {
          red=redstring[i+1, i+4];
          analogWrite(7, red);
          delay(1000);
                      }

      }

      //clearing string for next read
           redstring="";
          (redstring, "0", sizeof(redstring));
        }
      }
    }
  }
}

When you compile this program with Arduino IDE, what does it tell you about the amount of memeory used? It looks your program uses a lot of SRAM and it may quickly happen that memory gets exhausted during runtime.

It complies fine and just says the typical: Binary sketch size: 16,688 bytes (of a 258,048 byte maximum). It only appears to crash when I use RED, blue and green are fine and I can execute it as many times as I want, as soon as it finds red it crashes.

It seems you have an Arduino Mega, right? When I was talking about memory, I was referring to SRAM (data), not Flash (code). This is where you can have an issue (8KB limit on Mega). But more improtant: avoid using String as it is a source of this kind of crashes, due to memory heap fragmentation.

Yeah, I'm using the Mega.
How would I check the SRAM usage?
Hmm, what would you suggest using except string? Or would you suggest doing this another way?

Arduino IDE shows the amount od SRAM used for data after compilation. I got it on 1.5.7; I'm not sure this also works on 1.0.5 though.

I have tried compiling your program on my own Aduino IDE 1.5.7 for Arduino MEGA; it claims 946 bytes are used for SRAM (11% of 8K available on Mega). Normally that should be enough, but I think those String variable definitely make the difference (they use dynamic memory allocation / deallocation, which can quickly lead to heap fragmentation). In general it is preferrable to use C string style, i.e. char* or char xxx[SIZE], and stick with standard C string functions like strchr, strstr or strtok for what you do.

Ah, okay! Thank you so much for your help! I'll give that a go! :)

It's still crashing even when using char instead of string. As soon as it reads and sets the 3 colours, it crashes. This also happens if it reads and sets two numbers, the first is fine and the second causes it to crash.

Could you edit your question and add the following info: example HTTP request that makes the program crash. Also you say chaging String to C string style still has issues, could you please add the updated program with C-strings to your post? I ask because using C string style is not as straightforward as String and if not done properly can lead to crashes (but here, those are due to programming errors, not memory exhaustion).

Changing String into char* won't do the trick, there is much more rework required than that; sicne we start to have many comments I think I will post that as an answer.

As a first order approximation, redstring += c; does not do anything you want it to.

Using String, which uses dynamic allocation/deallocation on the heap is not advised in embedded platforms, as this can quickly lead to heap fragmentation, eventually leading to memory exhaustion, heap/stack collision...
First off, you should try to replace all String usage, everywhere in your program, with C-tyle strings, i.e. char* or char xxx[...] along with dedicated C functions to deal with them: strchr, strstr, strcpy, strcat, strtok, atoi...
Second, you can avoid using global variables and use the stack for many of them.
void loop() {
    ...
    if (client) {
        char readString[101];
        const int READ_STRING_SIZE = sizeof(readString) - 1;
        int readIndex = 0;
        while (client.connected()) {
            if (client.available()) {
                char c = client.read();
                if (readIndex < READ_STRING_SIZE) {
                    readString[readIndex++] = c;
                }

                if (c == '\n') {
                    // Terminate the read string
                    readString[readIndex] = 0;
                    Serial.println(readString);

                    // Prepare for next reeading
                    readIndex = 0;

                    client.println("HTTP/1.1 200 OK");
                    ...
                    client.stop();

                    // convert readString to all uppercase
                    for (i = 0; i < strlen(readString); i++)
                        readString[i] = toupper(readString[i]);

                    bool b = false;
                    bool r = false;
                    bool g = false;
                    int blue, red, green;

                    // Look for 'B' value
                    char* bb = strchr(readString, 'B');
                    if (bb != 0 && isdigit(bb[1]) {
                        blue = atoi(&bb[1]);
                        analogWrite(11, blue);
                        delay(500);
                        b = true;
                    }
                    // Same for 'G' and 'R' value
                    ...
                    if (b && r && g) {
                        Serial.print("CHANGING RED TO: ");
                        Serial.println(red);
                        Serial.print("CHANGING GREEN TO: ");
                        Serial.println(green);
                        Serial.print("CHANGING BLUE TO: ");
                        Serial.println(blue);
                    }
                }

                if (strstr(readString, "PIN6") != 0) {
                    digitalWrite(6, !digitalRead(6));
                    ...
                }
            }
        }
    }
}

In this sample code, we have completely removed dynamic memory allocation.

Thank you so much for all your help!
How would I clear the C-String? It keeps looping and doesn't toggle the pin, rather just makes it flash.

See my edit: I had forgotten to reset readIndex once a whole string has been read. Now it should work properly.

ah okay, thanks!
Another issue I found is that the code breaks the string when it hit's a 'B' but doesn't get the next 3 numbers, but instead copys the http request from the string and tries to make it an int and set the LED, but it just returns a 0. How would I replicate the blue = redstring[i + 1, i + 4]; (to get the 3 numbers after the 'B' like mine?)

Oops, my mistake, see my edit: atoi(&bb[1]) instead of atoi(bb).

Ah okay, thank you!
The same issue is occuring, as soon as I pass three colours, the server disconnects and won't take any more requests. Could this be a problem with the way I have set my server up?

I checked my code and realised it wasn't exactly like your example, with the help of your example I can now do multiple colours but as soon as I switch on PIN6 after setting the RGB LED, it crashes again.

Before we go further, could you clarify the "it crashes" statement. It would be useful to know if the MCU really crashes (eg memory problems) or if the program is in an infinite loop, in the latter case it would be useful to know exactly where this loop is.

I'm not exactly sure what the issue is, the webpage will become unresponsive and the lights indicating the Ethernet connection turn off. From what I have tested from the serial monitor, it appears the program is not looping but unexpectedly quitting. Furthermore, each statement (PIN6 & RGB) can be repeated infinitely as long as I don't mix the two statements and only execute one or the other.

I would suggest to ask another question with the latest code you have, and detail the observed problem, otherwise it will become very difficult to follow this Q&A thread. You can refer to this question from the new one just so that people can get some context about previous discussions if they want to.


text:
bitRead() gives wrong answer Arduino UNO R3
I am trying to read from a quadrature rotary encoder using an Arduino UNO R3. This is done by connecting the encoder's channel A pin to the Arduino interrupt 0 pin (digital IO pin 2). Inside the interrupt routine I then read the value of channel B (connected to digital IO pin 8) to determine the direction of rotation.
I am able to read the correct value of channel B using the digitalRead() function, but when I use bitRead() it always gives me a 0. As far as I know digital IO pin 8 is mapped to PORTB bit 0, so I am using bitRead(PORTB, 0) to read the bit. I also tried to read all of the other pins, but all of them show 0, except the LED at pin 13, which shows 0s and 1s when it gets toggled (It is also the only pin defined to be an OUTPUT pin, whereas the encoder uses INPUT pins).
Below is my code:
int channelA = 0;
int channelB = 8;
volatile int rotateNumber = 0;
volatile boolean interrupted = false;

void setup() {

    Serial.begin(115200);

    attachInterrupt(channelA, rotate, RISING);
    pinMode(channelB, INPUT);
}

void loop() {
   if(interrupted){
       Serial.println(rotateNumber)
       interrupted = false;
   }
}

void rotate(){
  if(bitRead(PORTB, 0) == 1)
     rotateNumber++;
  else
     rotateNumber--;

  interrupted = true;
}

PORTx is the latched value last written there. The external value is found in PINx.

So I won't be able to use bitRead if my pins are inputs?

You're using bitRead() on the wrong variable.

Oh now I understand, I should just use PINB instead of PORTB. Thanks for the help :)

source: Stack Exchange

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

sort: votes


text:
How can I run two loops simultaneously on an Arduino Uno?
I'm new to Arduino and I have two devices that I'm trying to control:

A RGB LED light strip that can change colors
A light sensor that can detect the ambient light level

What I'd like to do is have the LED strip continuously cycle through a rainbow of colors, and the light sensor will adjust the brightness of the LED strip based on the ambient light level. Here are the two pieces of code by themselves, which I've tested in isolation and confirmed that they work properly:
LED strip:
j = (j + 1) % 256; // current iteration of the light cycle

// set the strip color
for(int i=0; i< strip.numPixels(); i++) {
  strip.setPixelColor(i, Wheel(((i * 256 / strip.numPixels()) + j) & 255));
}

// display the new colors and wait 20ms before the next cycle
strip.show();
delay(20);

Light sensor:
sensors_event_t event;
tsl.getEvent(&event); // get a light measurement
strip.setBrightness(event.light); // set the brightness of the LED strip

The problem is that the light sensor takes anywhere from 100ms to 600ms to get a reading, and tsl.getEvent(&event) is a blocking call, so the end result is that the LED strip updates way too slowly. I would need to run the two side by side so that the light sensor read does not block the LED strip update. Any idea how I can accomplish this?

what library is "tsl" coming from?

100 to 600ms is excessive. Is it just for a LDR connected to an analog input?

@BrettM I think he is using the TSL2561 I2C light sensor.

You can make the sensor return data faster by lowering it's accuracy.
tsl.setIntegrationTime(TSL2561_INTEGRATIONTIME_13MS);      /* fast but low resolution */

You can also modify the library to not power-down the sensor after each reading. Just open TSL2561.cpp, find the getFullLuminosity function, and comment out the line reading disable(); and the 12 lines reading switch (_integration){ ... }
Another solution is, to have the pixels update every 20ms using a timer. You can have the timer, interrupt the main loop every 20ms and update the pixel values.
(I can't really help you with timers, as I myself set the registers for my timers, and ISRs directly, which isn't for beginners. But there are probably libraries for it, to make it more user friendly.)

http://playground.arduino.cc/code/timer1 this library should help make timers easier

See my edit above for negating the need for any delay, by leaving the tsl2561 on, all the time.

The arduino is not a multithreaded or multi-tasking device. You have to write your different functions to "play nice" with each other. Blocking code is death for this sort of multitasking. You might need to rewrite your code that reads the light sensor to be non-blocking.
If you can get that code to be non blocking then Visual Micro's post is the way to go.

Setup a 'state server' in your loop(). Put simply this means keeping track of the next command for each task, then doing one thing in each task per loop().
If one task needs to run at a faster speed than another task you can use a timer in your loop to decide what to do next.
If a task needs a pause then save the "Last Run" millis() to a global variable and ignore the task until the correct amount of time has passed. Do not use a delay(), always let the loop() run.
The idea is that the loop() runs as often as possible but you do one thing each time it runs.
It takes a while to get the hang of this way of working but it leaves the Arduino processor free to process all jobs evenly.
int task1Status=0;
int task2Status=0;

void loop()
{
  doOneThingOfTask1();
  doOneThingOfTask2();
}

//10 things to light the leds, but only do one
void doOneThingOfTask1()
{
  if (task1Status==10)
    task1Status=0;

  switch (task1Status)
  {
    case 0:
       //start doing a new process

    case 1:
       //do something

    case 9:
       //do the last thing

  }
}

I was going to post something similar, then I noticed that the OP said that the code for taking light measurements is blocking code.

@Duncan C Oh! Good point. I will leave the answer because I think it describes a way of working that avoids the same issue elsewhere in code. Also it might be that by examining the library call to getEvent() the same solution can be applied to reduce the delay. Obviously this means changing the library code but one can copy the library into the sketch folder and hack it as local source. a Lib change would certainly help but local source and a little hacking might produce a solution. Thanks :)

Your first, biggest problem is

the light sensor takes anywhere from 100ms to 600ms to get a reading, and tsl.getEvent(&event) is a blocking call,

You need non-blocking access to the light sensor. Look at the library code to see what it is doing when it blocks. Chances are it waits for the sensor to set a 'done' bit. If so, you'll need to modify the library, either by

adding a boolean .isDone() function that tests the done bit, and don't let your main program call for a reading until isDone() == TRUE; or
making .getEvent() a non-blocking such that it immediately returns an obviously invalid reading (such as -1) instead of blocking if the sensor isn't ready yet.

That leaves your main program free to service whatever needs doing and is ready to do without holding up everything for the slow sensor.

There are libraries that allow multitasking, for instance my library arduOS.
This should work:
#include <arduos16.h>
#include <arduos_core.h>
#include <roundscheduler.h>

SYS_enable_preemptive; // do NOT forget this!!!
void setup()
{
    auto sched = new SYS::RoundScheduler(2);
    sched->add(&loop1); // those 2 are functions.
    sched->add(&loop2);
    SYS::start();
}

But keep in mind that actual multitasking can be rather tricky, with very obscure bugs. (but you can find them).

This OS looks easier to use than your average arduino OS

1.Use two arduino's and have them talk to each other via serial or i2c.
Probably the simplest option (but not the cheapest - though you can get clone arduinos from US$4 ).
2.Find a light sensor that updates faster. Tried an ldr(light dependent resistor)/photocell ?  Then could use analog read.
Could also switch from using arduino to c, but thats a lot more work and you are still going to hit similar problems.

Switching to C would do nothing, really, for this issue.

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


text:
Is `millis()` affected by long ISRs?
I have a project that uses timers and interrupts frequently. A lot of CPU time is spent handling ISRs over an extended period of time.
Would this affect code inside the main loop that relies on the millis() function since a significant amount of time is spent processing the ISRs?

Also, anything based on millis() will also fail?
I think the (new softwarebased) servo library and maybe even softwareserial(?) may also get timing issues? Though I'm not sure if they're both based on that.

After some digging around in the core, it seems like Arduino updates millis() with a 8 bit timer: it uses overflow with a prescaler value of 64. In simpler terms, it has it set up so a certain piece of code (the ISR) is run approximately once per millisecond on a 16MHz system (and proportionately less frequently on slower clocked systems).
When that ISR is ran, it increments a variable that is used by the millis() function.
So, even if some non-interruptable code is being ran for a fraction of a millisecond, it won't matter since the bit for that interrupt vector will still remain set.
However, there is a problem when the ISR is ran less often than it should be triggered. This may be a result of using noInterrupts() for an extended period of time or when too many other interrupts are being ran and there is not enough CPU for all of the tasks. If a lot of the other ISRs have a higher interrupt priorities, it is possible that the code for the millis() may never be ran. In this case, you would have more serious issues than this, but it is something to keep in mind when you're writing code.
The general rule of thumb of ISRs still apply: keep it short!!!
Note: if you require extreme accuracy, the built in function isn't the best choice. A RTC is a good idea for long term time keeping.

I think you can have interrupts, interrupting other interrupts-routines (by calling sei() inside the ISR). But it's a slippery slope. E.g. memory overflows can occur a lot faster.

micros() appears to have the same issue, and in my test gave the same wrong time as millis().

The issue is not limited to ISRs. The write() function in Adafruit's TLC59711 library disables interrupts for possibly many milliseconds, causing my initial attempt to time this function using micros() to fail.

@UlrichStern, Tehee, adafruit makes you think their library is super fast, by pausing your "timing benchmark" ;D

@Paul, when timing Adafruit's library, the return value of micros() still increased enough that the runtime was not obviously wrong and I got fooled for a while.  :)  (Adafruit did not disable interrupts to fool me, I think, see my library's Wiki.)

Would this affect code inside the main loop that relies on the millis() function since a significant amount of time is spent processing the ISRs?

To put a figure on it for you ...

Frequency of the Timer 0 overflow ISR being called
The code called by the (default) Timer 0 overflow interrupt vector (TIM0_OVF_vect) is used by millis and micros to help return their results. Its purpose is to count Timer 0 overflows.
To get accurate results this ISR must not miss an overflow. The timer is configured to tick every 4 µs on a 16 MHz system (because of the prescaler of 64: 64 * 62.5 ns = 4000 ns) and overflow every 1.024 ms (1024 µs) - because it overflows after 256 ticks ( 4 µs * 256 = 1024 µs ).
Since there is only one overflow flag, if the ISR misses an overflow then both millis and micros will be out by 1.024 ms (or more, if it misses multiple overflows).
To be certain of catching that overflow, the ISR therefore has to be called within 1.024 ms (probably slightly less because of the time taken to enter the ISR, so say: 1 ms).

Interrupt priority
On the Atmega328P (such as used in the Arduino Uno) these are the interrupt vector priorities:
 1  Reset
 2  External Interrupt Request 0  (pin D2)          (INT0_vect)
 3  External Interrupt Request 1  (pin D3)          (INT1_vect)
 4  Pin Change Interrupt Request 0 (pins D8 to D13) (PCINT0_vect)
 5  Pin Change Interrupt Request 1 (pins A0 to A5)  (PCINT1_vect)
 6  Pin Change Interrupt Request 2 (pins D0 to D7)  (PCINT2_vect)
 7  Watchdog Time-out Interrupt                     (WDT_vect)
 8  Timer/Counter2 Compare Match A                  (TIMER2_COMPA_vect)
 9  Timer/Counter2 Compare Match B                  (TIMER2_COMPB_vect)
10  Timer/Counter2 Overflow                         (TIMER2_OVF_vect)
11  Timer/Counter1 Capture Event                    (TIMER1_CAPT_vect)
12  Timer/Counter1 Compare Match A                  (TIMER1_COMPA_vect)
13  Timer/Counter1 Compare Match B                  (TIMER1_COMPB_vect)
14  Timer/Counter1 Overflow                         (TIMER1_OVF_vect)
15  Timer/Counter0 Compare Match A                  (TIMER0_COMPA_vect)
16  Timer/Counter0 Compare Match B                  (TIMER0_COMPB_vect)
17  Timer/Counter0 Overflow                         (TIMER0_OVF_vect)
18  SPI Serial Transfer Complete                    (SPI_STC_vect)
19  USART Rx Complete                               (USART_RX_vect)
20  USART, Data Register Empty                      (USART_UDRE_vect)
21  USART, Tx Complete                              (USART_TX_vect)
22  ADC Conversion Complete                         (ADC_vect)
23  EEPROM Ready                                    (EE_READY_vect)
24  Analog Comparator                               (ANALOG_COMP_vect)
25  2-wire Serial Interface  (I2C)                  (TWI_vect)
26  Store Program Memory Ready                      (SPM_READY_vect)

You can see from that list that TIMER0_OVF_vect is number 17 on that list, so any earlier priority interrupt would take precedence, for example external interrupts, pin change interrupts, the other timers (however not SPI / Serial / ADC / I2C).
If an overflow had just happened then you would have practically 2 ms of grace (because you have 1 ms before the next and then another 1 ms before you need to notice it). However if the overflow is about to happen then you only have the 1 ms grace period.
I mention this because if you have an external interrupt 0 event (INT0_vect) and the ISR takes 500 µs, and then external interrupt 1 event (INT1_vect) during that time (so another ISR will be serviced) then the timer interrupt might be blocked for a while.
That is why all ISRs should be short. It isn't good enough that some of them are.

Re-enabling interrupts
I strongly recommend against this. The libraries are not designed to be re-entrant, and once you start enabling interrupts in one ISR you may find that it itself is called again when it is half-way through being called the first time. You may also conceivably interrupt a library function (eg. memcpy) that was not designed for it.
And, of course, if you are re-enabling interrupts inside an ISR because the ISR takes a long time: well, that is the exact situation when you may trigger this re-entrancy.

More information:

Interrupts
Timers
Millis overflow

The timer interrupt can even disrupt measurement of pulses using micros() from an on change interrupt.  The timer interrupt takes around 6.5us on Arduino Uno or mega.  If a change interrupt takes place just after the timer interrupt, then the change interrupt will be delayed by up to 6.5us until the timer interrupt completes.  In addition, the microsecond count is only updated once every 4us, introducing further uncertainty up to 4us.
So the measurement may be up to 10.5us out.  This should be considered when measuring pulse lengths.

ABSOLUTELY
any ISR that is long will prevent millis() from incrementing. It can be dubiously slow skew of this clock.
The ISR function always start off with blocking interrupts with the cli() command at start and finish by enabling them with the sei() command. Blocking other ISR's along with Timer0's OverFlow interrupt which is used for increamenting the millis counter.
Any extended use of noInterrupts() or cli() or implied use with ISR's should be carefully short in duration. There is no general harm in executing either of interrupts() or sei() with in the ISR, as to allow interrupts again.
Example:
in the VS1053 library I have Data Request on an INT pin. Which's ISR may read from the SdCard, which can take a very long time. So I re-enable the interrupts() before reading the SdCard, but still in the ISR.

In you example the main loop is never resumed during that long interrupt routine, right? So that's a downside. Good to know enabling interrupts inside other interrupts isn't as "dangerous" as I though.

I think only an ISR (or chain of ISR's) longer than a millisecond will prevent it form interrupting. You can block it 0.5ms and it will update as the very next thing to do (interrupt).

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


text:
Creating a product with arduino bootloader
If you have a prototype with arduino and you wish to create a real product can you do it or the fact that it contains the arduino bootloader prevents you?
BTW, i dont have a product ready. I am thinking options though. Or maybe i will have to go find a job

screw a job, i'm making a product right now :)

but srsly, a one millisecond google search found this: http://forum.arduino.cc/index.php?topic=104149.0

Getting a programmer means never having to worry about the bootloader. Unless you want it field-upgradeable, in which case you probably want one of the encrypted bootloaders Atmel provides anyways.

A quick google search found this info on the Arduino Forum which a user kindly shows the rules relating to this stuff.
The Optiboot bootloader is not actually an Arduino 'product'. Boards you design and software you write using Arduino IDE and libraries does not need to be disclosed to anybody, other than having the objects available (probably in a hidden part of your product's support website, in a "firmware" sub section) for some reason relating to being able to build the source against newer versions of Arduino.
I am currently making a product which I intend to use Arduino libraries and IDE and bootloader for fast development, but the board, schematics, and essentially the application code except for the libraries from Arduino will be mine. If you copy or build stuff specifically for/from Arduino hardware, you must(?) release certain source/schematics etc.


text:
A good place to begin with Arduino?
So I bought the Arduino starter kit a few weeks ago and I've done a few of the projects in the book supplied with the set. Unfortunately the book is quite poor, with inaccurate explanations and sometimes no explanation behind what they want you to do in the projects.
So I'd like to know what people would reccomend? I found 2 well reviewed books; Arduino for Dummies and Arduino Workshop, but I'm torn which to take. So I'm asking in here in hope that I can save time and money on buying and reading a good book from the start.
I'm a programmer by profession and also know a bit of physics, but have little experience with electronics.

Try to come up with a project you can make that is useful in your life, and just make it. Just like programming; you'll learn the most by just doing, running into problems and finding solutions. Book are overrated.

I got some ideas of what I'd like to do, but I know already they will be complicated projects, so I'd like to build up some basic knowledge before I begin.

Try spitting them into sub-problems. E.g. you project requires a lcd display. Try to get an lcd display working. Your project needs to sound a buzzer when some condition is met. You need to read light levels; try getting a LDR or phototransistor to work.

I'd guess that with your background, you could find some useful tutorials online, from which you could build a couple of projects and learn while you're doing it. Since you have a goal - or at least a direction - in mind, you can direct your searches toward features you think you'll need.

could you please say which starter kit you have? Some of them are very good, some are not so good. The one I have is very clear, all the experiments worked, and the purpose was well understood - it is shown in this video review where I gave it a good rating... https://www.youtube.com/watch?v=pf4qosqpv3A

@Jasmine Sorry Jasmine, I hadn't considered that. It's the official starter kit sold on Arduinos own website.

There is some good discussion going on here but I'm going to have to close this question as it's "primarily opinion based" and there is no correct answer. The arduino chat would be a better place for something like this. http://chat.stackexchange.com/rooms/8489/pin-13

@sachleen Fair enough.

I have read a lot of materials, watched many videos and completed lots of searching to find great stater Arduino lessons. By far the best place I found was
opensourcehardwaregroup.com
Free to start learning Arduino site
Free initial course and if you like the lessons you can pay a small fee to get to the advanced course. You will learn a lot!


text:
Using an Arduino for learning embedded C programming
I'm a computer systems engineering student and was planning to buy an Arduino to learn embedded C programming. After researching I found mention that an Arduino may not be a good choice for a beginner that wants to learn about programming embedded systems using C.
I'm not sure if that is true, can an Arduino be programmed in C without using C++ and the other included class libraries? I'd prefer to learn how to program things at a fairly low level and not rely on libraries that hide details of the underlying hardware. Can the Arduino be used as a general AVR / microcontroller development platform to learn embedded C programming?

Well my programming and electronics skills are quite good (i'm third year student Computer system engineering) got good knowledge in computer architecture, but no experience in embedded systems.So i want to do projects which would teach me about them and how to code for them.

The format of ee.se is more like a wiki than a forum. The aim is to develop a set of good, specific, questions, which can have fact or evidence based answers. So the usual approach is to update the question with extra information in response to comments. Unfortunately, your question still seems vague, and hence answers would be based on opinion, which is a poor fit to ee.se. Questions of the form, "I want to make an XYZ, my experience is ..., I plan to use an Arduino and an ABC, I have researched the web, found http... and http... however, I still need help with ..." is a better fit.

I had a bit of a problem following the title at first, but by "Type-C" do you mean something that can run C code for learning embedded systems? If so let me know and I might be able to edit the question into something more answerable.

yeah , it's for c language

Yes, an Arduino can be programmed in ordinary C - use of the IDE and the quasi-C++ libraries is entirely optional, one is free to treat the hardware as an ATmega development board and use avr-gcc (or similar) directly, using either the arduino style (optiboot or whatever) bootloader or some other method (ISP, etc) to load the results into the chip.

Seconding Chris Stratton's comment, noting also that the avr-gcc compiler allows you to specify the input-language.

The Arduino is a great place to start embedded C programming. You can use both C and CPP. There are tons of tutorials online and there are a bunch of books available. In addition there are lots of libraries available on GIT HUB for interfacing with all types of hardware like RF24 Wireless Transceivers.
If you want to go into more low level programming, you can. For example, you can set all Port B pins to Output:
// the setup routine runs once when you press reset:
void setup() {

  // initialize the digital pins as an output.
  DDRB = 0xff;
}

[Not sure who's listening, as this is a 4 year old question posted by someone who no longer seems to have an account here, but... ]

... can an Arduino be programmed in C
  without using C++ and the other included class libraries?

You absolutely can use either C or C++, and make use of class libraries or write your own functions for either or both of computing tasks and managing your external hardware.

Can the
  Arduino be used as a general AVR / microcontroller development
  platform to learn embedded C programming?

Yes, for the reasons above, and more. Embedded systems differ from other computing systems by having deadlines the must meet. These can be soft deadlines (try to keep visible delays to a minimum so you don't annoy the user/operator) or hard deadlines (if you miss one, something could fail or someone might die). They come in different scales: my home thermostat could be capably run by an Attiny "with one pin tied behind its back". :) Other systems might contain many large-scale chips or a mix of both, networked internally to one another. A mid-scale example of this is an automobile engine controller. It runs your signals, entertainment system, ABS brakes and traction control, and more, all while opening and closing injector valves and firing spark plugs with precise timings, at up to 125 times per second. And that is for a pretty normal, family-car, "street" engine.
The Atmega328p (Uno's MCU) is sufficiently over-engineered to tolerate occasional misuse, being over-clocked or supplied a lower than spec'd voltage, has several ways to update/replace its program, is easy to hand-build into a custom micro-controller board, and after all that abuse, is cheap enough to replace if you do manage to damage one.
Documentation is readily available as are online communities like this one, to help with beginners questions, unusual questions, esoteric uses that maybe only a handful of people have tried or know about.
So, tl;dr: yes, I'd call it an ideal platform for everything you asked about.


text:
Getting a long avrdude error while uploading a simple sketch to arduino uno
This is the error which shows up after the sketch is compiled and starts uploading.
Is there some sort of fix to this problem?
There are no shields connected to it, not even I/O pins are being used, just trying the simple Blink sketch.
NOTE : It was working find before and then it started acting crazy
    Binary sketch size: 1,084 bytes (of a 32,256 byte maximum)
C:\Program Files (x86)\Arduino\hardware/tools/avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -carduino -P\\.\COM3 -b115200 -D -Uflash:w:G:\Temp\build5658632448223358877.tmp\Blink.cpp.hex:i

avrdude: Version 5.11, compiled on Sep  2 2011 at 19:38:36
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware/tools/avr/etc/avrdude.conf"

         Using Port                    : \\.\COM3
         Using Programmer              : arduino
         Overriding Baud Rate          : 115200
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Send: 0 [30]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
         AVR Part                      : ATMEGA328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

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

         Programmer Type : Arduino
         Description     : Arduino
avrdude: Send: A [41] . [80]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [81]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [98]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
         Hardware Version: 3
         Firmware Version: 4.4
avrdude: Send: A [41] . [84]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [85]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [86]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [87]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [89]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [03]
avrdude: Recv: . [10]
         Vtarget         : 0.3 V
         Varef           : 0.3 V
         Oscillator      : 28.800 kHz
         SCK period      : 3.3 us

avrdude: Send: A [41] . [81]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: A [41] . [82]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [04]
avrdude: Recv: . [10]
avrdude: Send: B [42] . [86] . [00] . [00] . [01] . [01] . [01] . [01] . [03] . [ff] . [ff] . [ff] . [ff] . [00] . [80] . [04] . [00] . [00] . [00] . [80] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: E [45] . [05] . [04] . [d7] . [c2] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: P [50]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: AVR device initialized and ready to accept instructions

Reading | avrdude: Send: u [75]   [20]
avrdude: Recv: . [14] . [1e] . [95] . [0f] . [10]
################################################## | 100% 0.00s

avrdude: Device signature = 0x1e950f
avrdude: Send: V [56] . [a0] . [03] . [fc] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [03] . [fd] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [03] . [fe] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: Send: V [56] . [a0] . [03] . [ff] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [00]
avrdude: Recv: . [10]
avrdude: reading input file "G:\Temp\build5658632448223358877.tmp\Blink.cpp.hex"
avrdude: writing flash (1084 bytes):

Writing | avrdude: Send: U [55] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [0c] . [94] a [61] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] . [9d] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [00] . [00] . [00] . [00] $ [24] . [00] ' [27] . [00] * [2a] . [00] . [00] . [00] . [00] . [00] % [25] . [00] ( [28] . [00] + [2b] . [00] . [00] . [00] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
#####avrdude: Send: U [55] @ [40] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] # [23] . [00] & [26] . [00] ) [29] . [00] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [02] . [02] . [02] . [02] . [02] . [02] . [03] . [03] . [03] . [03] . [03] . [03] . [01] . [02] . [04] . [08] . [10]   [20] @ [40] . [80] . [01] . [02] . [04] . [08] . [10]   [20] . [01] . [02] . [04] . [08] . [10]   [20] . [00] . [00] . [00] . [07] . [00] . [02] . [01] . [00] . [00] . [03] . [04] . [06] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [11] $ [24] . [1f] . [be] . [cf] . [ef] . [d8] . [e0] . [de] . [bf] . [cd] . [bf] . [11] . [e0] . [a0] . [e0] . [b1] . [e0] . [ea] . [e3] . [f4] . [e0] . [02] . [c0] . [05] . [90] . [0d] . [92] . [a2] 0 [30] . [b1] . [07] . [d9] . [f7] . [11] . [e0] . [a2] . [e0] . [b1] . [e0] . [01] . [c0] . [1d] . [92] . [ab] 0 [30] . [b1] . [07] . [e1] . [f7] . [0e] . [94] . [0c] . [02] . [0c] . [94] . [1b] . [02] . [0c] . [94] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [80] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [80] . [91] . [00] . [01] ` [60] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [08] . [95] . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] y [79] . [01] . [08] . [95] . [1f] . [92] . [0f] . [92] . [0f] . [b6] . [0f] . [92] . [11] $ [24] / [2f] . [93] ? [3f] . [93] . [8f] . [93] . [9f] . [93] . [af] . [93] . [bf] . [93] . [80] . [91] . [06] . [01] . [90] . [91] . [07] . [01] . [a0] . [91] . [08] . [01] . [b0] . [91] . [09] . [01] 0 [30] . [91] . [0a] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] # [23] / [2f] - [2d] _ [5f] - [2d] 7 [37]   [20] . [f0] - [2d] W [57] . [01] . [96] . [a1] . [1d] . [b1] . [1d]   [20] . [93] . [0a] . [01] . [80] . [93]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [c0] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [06] . [01] . [90] . [93] . [07] . [01] . [a0] . [93] . [08] . [01] . [b0] . [93] . [09] . [01] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [80] . [93] . [02] . [01] . [90] . [93] . [03] . [01] . [a0] . [93] . [04] . [01] . [b0] . [93] . [05] . [01] . [bf] . [91] . [af] . [91] . [9f] . [91] . [8f] . [91] ? [3f] . [91] / [2f] . [91] . [0f] . [90] . [0f] . [be] . [0f] . [90] . [1f] . [90] . [18] . [95] . [9b] . [01] . [ac] . [01] . [7f] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] f [66] . [b5] . [a8] . [9b] . [05] . [c0] o [6f] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [7f] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [86] . [0f] . [91] . [1d]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [00] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [a1] . [1d] . [b1] . [1d] b [62] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] j [6a] . [95] . [d1] . [f7] . [bc] . [01] - [2d] . [c0] . [ff] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [e6] . [b5] . [a8] . [9b] . [05] . [c0] . [ef] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [ff] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [8e] . [0f] . [91] . [1d] . [a1] . [1d] . [b1] . [1d] . [e2] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] . [ea] . [95] . [d1] . [f7] . [86] . [1b] . [97] . [0b] . [88] ^ [5e] . [93] @ [40] . [c8] . [f2] ! [21] P [50] 0 [30] @ [40] @ [40] @ [40] P [50] @ [40] h [68] Q [51] | [7c] O [4f] ! [21] . [15] 1 [31] . [05] A [41] . [05] Q [51] . [05] q [71] . [f6] . [08] . [95] x [78] . [94] . [84] . [b5]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] @ [40] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [82] ` [60] . [84] . [bd] . [84] . [b5] . [81] ` [60] . [84] . [bd] . [85] . [b5] . [82] ` [60] . [85] . [bd] . [85] . [b5] . [81] ` [60] . [85] . [bd] . [ee] . [e6] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [e8] . [f0] . [e0] . [10] . [82] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [e0] . [e8] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [eb] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [e0] . [eb] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [ea] . [e7] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [80] . [81] . [80] h [68] . [80] . [83] . [10] . [92] . [c1] . [00] . [08] . [95] . [cf] . [93] . [df] . [93] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [86] V [56] . [9f] O [4f]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [80] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [fc] . [01] 4 [34] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] . [84] . [91] . [88] # [23] i [69] . [f1] . [90] . [e0] . [88] . [0f] . [99] . [1f] . [fc] . [01] . [e8] Y [59] . [ff] O [4f] . [a5] . [91] . [b4] . [91] . [fc] . [01] . [ee] X [58] . [ff] O [4f] . [c5] . [91] . [d4] . [91] f [66] # [23] Q [51] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [89] # [23] . [0b] . [c0] b [62] 0 [30] a [61] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [83] + [2b] . [88] . [83] / [2f] . [bf] . [06] . [c0] . [9f] . [b7] . [f8] . [94] . [8c] . [91] . [83] + [2b] . [8c] . [93] . [9f] . [bf] . [df] . [91] . [cf] . [91] . [08] . [95] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [82] U [55] . [9f] O [4f] . [fc] . [01] $ [24] . [91] . [ca] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [c0] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] . [80] F [46] . [86] V [56] . [9f] O [4f] . [fc] . [01] . [94] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] 4 [34] . [91] 3 [33] # [23] . [09] . [f4] @ [40] . [c0] " [22] # [23] Q [51] . [f1] # [23] 0 [30] q [71] . [f0] $ [24] 0 [30] ( [28] . [f4] ! [21] 0 [30] . [a1] . [f0] " [22] 0 [30] . [11] . [f5] . [14] . [c0] & [26] 0 [30] . [b1] . [f0] ' [27] 0 [30] . [c1] . [f0] $ [24] 0 [30] . [d9] . [f4] . [04] . [c0] . [80] . [91] . [80] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [80] . [00] . [8f] } [7d] . [80] . [93] . [80] . [00] . [10] . [c0] . [84] . [b5] . [8f] w [77] . [02] . [c0] . [84] . [b5] . [8f] } [7d] . [84] . [bd] . [09] . [c0] . [80] . [91] . [b0] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [b0] . [00] . [8f] } [7d] . [80] . [93] . [b0] . [00] . [e3] / [2f] . [f0] . [e0] . [ee] . [0f] . [ff] . [1f] . [ee] X [58] . [ff] O [4f] . [a5] . [91] . [b4] . [91] / [2f] . [b7]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [00] . [02]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: d [64] . [00] < [3c] F [46] . [f8] . [94] f [66] # [23] ! [21] . [f4] . [8c] . [91] . [90] . [95] . [89] # [23] . [02] . [c0] . [8c] . [91] . [89] + [2b] . [8c] . [93] / [2f] . [bf] . [08] . [95] . [cf] . [93] . [df] . [93] . [0e] . [94] > [3e] . [01] . [0e] . [94] . [97] . [00] . [c0] . [e0] . [d0] . [e0] . [0e] . [94] . [80] . [00]   [20] . [97] . [e1] . [f3] . [0e] . [94] . [00] . [00] . [f9] . [cf] . [f8] . [94] . [ff] . [cf] . [0d] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
### | 100% 0.27s

avrdude: 1084 bytes of flash written
avrdude: verifying flash memory against G:\Temp\build5658632448223358877.tmp\Blink.cpp.hex:
avrdude: load data flash data from input file G:\Temp\build5658632448223358877.tmp\Blink.cpp.hex:
avrdude: input file G:\Temp\build5658632448223358877.tmp\Blink.cpp.hex contains 1084 bytes
avrdude: reading on-chip flash data:

Reading | avrdude: Send: U [55] . [00] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [0c] . [94] a [61] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] . [9d] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [0c] . [94] ~ [7e] . [00] . [00] . [00] . [00] . [00] $ [24] . [00] ' [27] . [00] * [2a] . [00] . [00] . [00] . [00] . [00] % [25] . [00] ( [28] . [00] + [2b] . [00] . [00] . [00] . [00] . [00]
avrdude: Recv: . [10]
#####avrdude: Send: U [55] @ [40] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: # [23] . [00] & [26] . [00] ) [29] . [00] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [04] . [02] . [02] . [02] . [02] . [02] . [02] . [03] . [03] . [03] . [03] . [03] . [03] . [01] . [02] . [04] . [08] . [10]   [20] @ [40] . [80] . [01] . [02] . [04] . [08] . [10]   [20] . [01] . [02] . [04] . [08] . [10]   [20] . [00] . [00] . [00] . [07] . [00] . [02] . [01] . [00] . [00] . [03] . [04] . [06] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [00] . [11] $ [24] . [1f] . [be] . [cf] . [ef] . [d8] . [e0] . [de] . [bf] . [cd] . [bf] . [11] . [e0] . [a0] . [e0] . [b1] . [e0] . [ea] . [e3] . [f4] . [e0] . [02] . [c0] . [05] . [90] . [0d] . [92] . [a2] 0 [30] . [b1] . [07] . [d9] . [f7] . [11] . [e0] . [a2] . [e0] . [b1] . [e0] . [01] . [c0] . [1d] . [92] . [ab] 0 [30] . [b1] . [07] . [e1] . [f7] . [0e] . [94] . [0c] . [02] . [0c] . [94] . [1b] . [02] . [0c] . [94] . [00] . [00]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [80] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [80] . [91] . [00] . [01] ` [60] . [e0] . [0e] . [94] . [b8] . [01] h [68] . [ee] s [73] . [e0] . [80] . [e0] . [90] . [e0] . [0e] . [94] . [e5] . [00] . [08] . [95] . [80] . [91] . [00] . [01] a [61] . [e0] . [0e] . [94] y [79] . [01] . [08] . [95] . [1f] . [92] . [0f] . [92] . [0f] . [b6] . [0f] . [92] . [11] $ [24] / [2f] . [93] ? [3f] . [93] . [8f] . [93] . [9f] . [93] . [af] . [93] . [bf] . [93] . [80] . [91] . [06] . [01] . [90] . [91] . [07] . [01] . [a0] . [91] . [08] . [01] . [b0] . [91] . [09] . [01] 0 [30] . [91] . [0a] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] # [23] / [2f] - [2d] _ [5f] - [2d] 7 [37]   [20] . [f0] - [2d] W [57] . [01] . [96] . [a1] . [1d] . [b1] . [1d]   [20] . [93] . [0a] . [01] . [80] . [93]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [c0] . [00]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [06] . [01] . [90] . [93] . [07] . [01] . [a0] . [93] . [08] . [01] . [b0] . [93] . [09] . [01] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [80] . [93] . [02] . [01] . [90] . [93] . [03] . [01] . [a0] . [93] . [04] . [01] . [b0] . [93] . [05] . [01] . [bf] . [91] . [af] . [91] . [9f] . [91] . [8f] . [91] ? [3f] . [91] / [2f] . [91] . [0f] . [90] . [0f] . [be] . [0f] . [90] . [1f] . [90] . [18] . [95] . [9b] . [01] . [ac] . [01] . [7f] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] f [66] . [b5] . [a8] . [9b] . [05] . [c0] o [6f] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [7f] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [86] . [0f] . [91] . [1d]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [00] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [a1] . [1d] . [b1] . [1d] b [62] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] j [6a] . [95] . [d1] . [f7] . [bc] . [01] - [2d] . [c0] . [ff] . [b7] . [f8] . [94] . [80] . [91] . [02] . [01] . [90] . [91] . [03] . [01] . [a0] . [91] . [04] . [01] . [b0] . [91] . [05] . [01] . [e6] . [b5] . [a8] . [9b] . [05] . [c0] . [ef] ? [3f] . [19] . [f0] . [01] . [96] . [a1] . [1d] . [b1] . [1d] . [ff] . [bf] . [ba] / [2f] . [a9] / [2f] . [98] / [2f] . [88] ' [27] . [8e] . [0f] . [91] . [1d] . [a1] . [1d] . [b1] . [1d] . [e2] . [e0] . [88] . [0f] . [99] . [1f] . [aa] . [1f] . [bb] . [1f] . [ea] . [95] . [d1] . [f7] . [86] . [1b] . [97] . [0b] . [88] ^ [5e] . [93] @ [40] . [c8] . [f2] ! [21] P [50] 0 [30] @ [40] @ [40] @ [40] P [50] @ [40] h [68] Q [51] | [7c] O [4f] ! [21] . [15] 1 [31] . [05] A [41] . [05] Q [51] . [05] q [71] . [f6] . [08] . [95] x [78] . [94] . [84] . [b5]
avrdude: Recv: . [10]
######avrdude: Send: U [55] @ [40] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [82] ` [60] . [84] . [bd] . [84] . [b5] . [81] ` [60] . [84] . [bd] . [85] . [b5] . [82] ` [60] . [85] . [bd] . [85] . [b5] . [81] ` [60] . [85] . [bd] . [ee] . [e6] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [e8] . [f0] . [e0] . [10] . [82] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [e0] . [e8] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [e1] . [eb] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [e0] . [eb] . [f0] . [e0] . [80] . [81] . [81] ` [60] . [80] . [83] . [ea] . [e7] . [f0] . [e0] . [80] . [81] . [84] ` [60] . [80] . [83] . [80] . [81] . [82] ` [60] . [80] . [83] . [80] . [81] . [81] ` [60] . [80] . [83] . [80] . [81] . [80] h [68] . [80] . [83] . [10] . [92] . [c1] . [00] . [08] . [95] . [cf] . [93] . [df] . [93] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [86] V [56] . [9f] O [4f]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [80] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [fc] . [01] 4 [34] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] . [84] . [91] . [88] # [23] i [69] . [f1] . [90] . [e0] . [88] . [0f] . [99] . [1f] . [fc] . [01] . [e8] Y [59] . [ff] O [4f] . [a5] . [91] . [b4] . [91] . [fc] . [01] . [ee] X [58] . [ff] O [4f] . [c5] . [91] . [d4] . [91] f [66] # [23] Q [51] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [89] # [23] . [0b] . [c0] b [62] 0 [30] a [61] . [f4] / [2f] . [b7] . [f8] . [94] . [8c] . [91] . [93] / [2f] . [90] . [95] . [89] # [23] . [8c] . [93] . [88] . [81] . [83] + [2b] . [88] . [83] / [2f] . [bf] . [06] . [c0] . [9f] . [b7] . [f8] . [94] . [8c] . [91] . [83] + [2b] . [8c] . [93] . [9f] . [bf] . [df] . [91] . [cf] . [91] . [08] . [95] H [48] / [2f] P [50] . [e0] . [ca] . [01] . [82] U [55] . [9f] O [4f] . [fc] . [01] $ [24] . [91] . [ca] . [01]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [c0] . [01]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] . [80] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [86] V [56] . [9f] O [4f] . [fc] . [01] . [94] . [91] J [4a] W [57] _ [5f] O [4f] . [fa] . [01] 4 [34] . [91] 3 [33] # [23] . [09] . [f4] @ [40] . [c0] " [22] # [23] Q [51] . [f1] # [23] 0 [30] q [71] . [f0] $ [24] 0 [30] ( [28] . [f4] ! [21] 0 [30] . [a1] . [f0] " [22] 0 [30] . [11] . [f5] . [14] . [c0] & [26] 0 [30] . [b1] . [f0] ' [27] 0 [30] . [c1] . [f0] $ [24] 0 [30] . [d9] . [f4] . [04] . [c0] . [80] . [91] . [80] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [80] . [00] . [8f] } [7d] . [80] . [93] . [80] . [00] . [10] . [c0] . [84] . [b5] . [8f] w [77] . [02] . [c0] . [84] . [b5] . [8f] } [7d] . [84] . [bd] . [09] . [c0] . [80] . [91] . [b0] . [00] . [8f] w [77] . [03] . [c0] . [80] . [91] . [b0] . [00] . [8f] } [7d] . [80] . [93] . [b0] . [00] . [e3] / [2f] . [f0] . [e0] . [ee] . [0f] . [ff] . [1f] . [ee] X [58] . [ff] O [4f] . [a5] . [91] . [b4] . [91] / [2f] . [b7]
avrdude: Recv: . [10]
######avrdude: Send: U [55] . [00] . [02]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]
avrdude: Send: t [74] . [00] < [3c] F [46]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [f8] . [94] f [66] # [23] ! [21] . [f4] . [8c] . [91] . [90] . [95] . [89] # [23] . [02] . [c0] . [8c] . [91] . [89] + [2b] . [8c] . [93] / [2f] . [bf] . [08] . [95] . [cf] . [93] . [df] . [93] . [0e] . [94] > [3e] . [01] . [0e] . [94] . [97] . [00] . [c0] . [e0] . [d0] . [e0] . [0e] . [94] . [80] . [00]   [20] . [97] . [e1] . [f3] . [0e] . [94] . [00] . [00] . [f9] . [cf] . [f8] . [94] . [ff] . [cf] . [0d] . [00]
avrdude: Recv: . [10]
### | 100% 0.20s

avrdude: verifying ...
avrdude: 1084 bytes of flash verified
avrdude: Send: Q [51]   [20]
avrdude: Recv: . [14]
avrdude: Recv: . [10]

avrdude done.  Thank you.

Did you try turning verbose output off?

Actually that did work, Thanks ;) But is there something wrong with the arduino and what does the verbose mean ? THanks

I see no error in this output. I can just that avrdude was called with -v -v -v -v which tells it to be very verbose. You have to remove that option (IIRC you can do this in Arduino IDE preferences dialog, otherwise you can take a look at avrdude.conf file , find this option and change it)

This is not an error. AVRDude is running with the Verbose flag on. Verbose in English means:

using or expressed in more words than are needed.

In the Arduino IDE:


text:
Turn Arduino on only by double tapping switch?
I don't have much experience with electronics. I was wondering if it is possible to create a push button switch, which will turn on the device only if it is tapped twice in quick succession?
If it is tapped only once, then the device should behave as if nothing happened (i.e. tapping the switch again after a specified duration should have no effect).

Create something which uses an interrupt to wake from sleep on a single button press, and return to sleep if a second is not detected within a short window of time.

You can use something like the ATtiny25/45/85 then have a button cell battery to power it, make it a sleeper that listens to the button, and when clicked it activates the Arduino.
The Arduino is then turned on keeping a capacitor alive holding a transistor active, then add another button that drains the capacitor, thus closing the transistor and turning the Arduino off. Or you can program the ATtiny to drain the capacitor if the button is held down.
A button cell on an ATtiny in sleepmode should last around a year or so.
Just some information to get you going further:
http://playground.arduino.cc/Learning/arduinoSleepCode : The sleeper code, it is power saving using interrupts.
http://www.instructables.com/id/Program-an-ATtiny-with-Arduino/ : How to burn an ATtiny using Arduino. Fairly simple, did it myself a few times.

The ATtiny isn't necessarily needed - it should be possible to get either the ATmega328p or the 16u2 to do the low-power wakeup role, and keep the other asleep until needed.

Yes, it would be the same principle, but he specifficly stated that the arduino would be turned off and then turned on, and not put in some kind of sleep mode. So thats what i went with.
Ofcause i could have elaborated other posibilities, but since the feedback from the questioneer was lacking i didn't think i should spend more time on this question :)

Thanks! I don't know what any of this means. But i will try it!

@John feel free to ask questions i have a little experience in the ATTiny's mostly blink examples and sirens made of used 8ohms speakers. But a bit more in burning the chip, it can be a bit tricky but follow the guides and it will get you far!


text:
How can I program an arduino in pure C/C++?
I am a beginner and I want to learn AVR C/C++. Can I do this using an Arduino?  (I'm asking this because I already have one).
If so, could someone tell me using which IDE can I write code in pure C/C++ and then flash it to the Atmega328P on the Arduino?  Or, should I get an AVR and a programmer instead?
I've searched all over the internet and I'm really confused by all the terminology. Could someone explain it to me?

So in order to program the 328 I believe you need to install atmel studio to compile your code and then use the command line command avrdude to put your compiled code onto the arduino.

@Treesrule14 that's a possibility, but not the only one, so it's untrue to say that it is necessary.  If the Arduino IDE is installed, then so is the avr-gcc compiler on which it depends.

@Treesrule14 I have the atmel studio installed. I just cannot find any resources that might help me flash a program to the chip on the arduino using a bootloader (without a programmer). Is this even possible?

I believe you need a programmer. : (

You don't need any IDE. You can compile and upload using the toolchain that comes with Arduino. Look at Arduino.mk for example.

@Treesrule14 - wrong again, you do not need a programmer.  Avrdude will talk to the bootloader on the arduino just as readily to upload a hex file compiled from a stand alone C program as it will to upload one built by the Arduino IDE.

@ChrisStratton totally didn't see your first post sorry about that. Have you tried programming with avr-gcc over usb?

avr-gcc is a compiler, not a download tool. But anyone who has every used to the Arduino IDE with a USB-connected arduino has done so, yes.  And I and many others have done it with plain C programs built from the command line with avr-gcc and flashed from the command line with avrdude (which is, after all, what the Arduino IDE quietly does on behalf of its user).  There are many writeups online, it's a task beyond trivial summary in an SO answer.

Yes, get an AVR programmer instead.
1) You can flash your arduino board with avrdude/avr-gcc. Install these tools, find the datasheet of atmega328 (google it), use the board pinouts to connect to your programmer (stk500v2/ISP) and voila!
2) Keep in mind that by "manually" flashing your atmaga on arduino board you're removing bootloader that is needed to load your sketches from ARDUINO IDE.
3) Use your favourite C/C++ IDE

you should be able to find and reflash the bootloader for the arduino look here http://arduino.cc/en/Hacking/Bootloader?from=Tutorial.Bootloader

No! You do not need a programmer, or to remove the bootloader.  The Arduino bootloader has zero dependence to the IDE or libraries - you are every bit as free to use it with stand alone C programs as with Arduino sketches.  Doing it that way is not only cheaper, but lets you use the same board for both styles of development with no configuration changes.

The author wanted to learn AVR in pure C. He didn't ask - hey guys, how to play with arduino IDE or someth. but how to reuse the atmega on board he already has.

@ChrisStratton since you disagree with the other answers Submit an Answer please

If you're a beginner, I suggest you write C in the Arduino IDE. The libraries are very useful and I think the Arduino/Wiring/Processing environment will cover all your needs.
Check out the Lightblue Bean (http://punchthrough.com/bean/) it is a good example of the power of that platform. Even experienced embedded programmers can use it, since the underlying register are still accessible.
I am now programming on the Ti MSP430, and while I can appreciate the possibilities, I miss the simplicity of Arduino; much easier to get started with Arduino.
Go to http://arduino.cc/en/main/software to download the 1.0.6. IDE software, plug your Arduino, go to Tools->Board to select your Arduino, select the appropriate "tty" port in the Tools->Serial_Port.
Then write in pure C and download. There are tons of examples included with the IDE.

An Arduino is programmed in C/C++. There is a common misconception that Arduino has its own language. See this link C++ vs. The Arduino Language? for a full discussion on Arduino being C/C++ and the simplifications Arduino offers. Further more, you can see the Arduino core code here.
From the Arduino website:

Can I program the Arduino board in C?
In fact, you already are; the Arduino language is merely a set of C/C++ functions that can be called from your code. Your sketch undergoes minor changes (e.g. automatic generation of function prototypes) and then is passed directly to a C/C++ compiler (avr-g++). All standard C and C++ constructs supported by avr-g++ should work in Arduino. For more details, see the page on the Arduino build process.

Arduino offers an easy learning curve for beginners through to experts. So simply download the latest Arduino IDE, install it and enjoy.

Another common misconception is that C is a subset of C++. Arduino core library is written in C++, so it's impossible to program in C using it.

I think this is the answer.

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


text:
How do I connect this display to an Arduino Uno
I am completely new to this, and a novice when it comes to electronics but I want to learn.
Can someone pls tell me how I would connect the display in the photo here with an Arduino Uno (which I have ordered).  The plan is to interface my car with this transparent display to produce a form of HUD.
I have done some searching but to no avail so far, would appreciate being pointed in the right direction.
many thanks

What do you know about this display? Do you have a datasheet, a make/model, any information to go on? We really can't tell you much from a picture.

Thank you. Not yet but I will try to find out.  This was the only transparent display that I could find available for purchase.

Can can always scrap the electronics and drive the LCD yourself. But you need quite a few IO pins, looking at that ribbon cable. Also it's not really a beginners project.

You don't need a transparent display. You can project a bright LED up to the windshield and it will be reflected in your line of sight, you will have to deal with projecting a flipped image so it appears correct to the observer.

You're in for a lot of work. Everything on the PCB is useless to you, so you'd have to interface the raw panel to the Arduino.
The first matter is to remove the panel from the board. You will need to desolder all of the connections, and then solder either some sort of rigid connector or individual wires to the large ribbon connector. The only advice I can give you is "be prepared to fail".
Once you've done that, you will need to read AVR340 in order to learn how to drive the panel. Note that the Uno itself does not have enough pins to drive the panel directly, so you will need to get an I/O expander or two for this.
Did I mention that you're in for a lot of work? Well, I'm mentioning it again. Good luck though.

Thank you. I suspected it wouldn't be straightforward. This is the info I was looking for - somewhere to start.

@DrT Do you have an update on how the project went. I'm interested in whatever, even if it failed, as I learn a lot from HOW / WHY things fail.


text:
Advisability of Using Bit Fields in Structs
I have to track a large amount of data (for an Arduino) in a program while taking care of a fair amount of other business.
I started with a struct like this:
struct MyStruct
{
   // note: these names might as well be foo bar baz
   uint8_t color;
   boolean state;
   uint8_t area;
   uint8_t number;
   uint8_t len;
};

I have an array of 800 of these. At 5 bytes each, that's 4Kb, or half the ram on the Arduino Mega.
I changed to a struct like this:
struct MyStruct
{
   uint8_t color : 3; // max value 7
   // uint8_t state : 1; *** moved, thanks Ignacio ***
   uint8_t area : 5; // m.v. 31
   uint8_t number;
   uint8_t len : 5; // m.v. 31
   uint8_t state : 1; // m.v. 1
};

I understand this reduces the size of each instance to 3 bytes, for a total of 2.4Kb in my array.
I have read that in some implementations / chipsets using bit fields in structs can lead to less efficient execution. Obviously this is a more efficient use of memory, but my question is:
How does the Arduino handle bit fields? Will it be better, worse, or negligibly different in terms or speed when iterating through an array of bit field structs? Is there a good way to test this?

That order will use 4 bytes. Get that 1-bit field out from between the other 8.

@Ignacio Amazing... you just shaved another 9% off my total memory usage.

The reason bit fields in structs can lead to less efficient execution is because of word alignment restrictions. E.g. if they cross the natural 32/64 alignment, causing multiple accesses. This should not be a problem for the ATmega

The question you need to ask yourself is if you are most worried about running out of RAM, program memory, or CPU cycles - this is a situation where you can optimize quite a bit for one at cost of another and some impact on the third.  At a certain point you should also ask if an ATmega-based Arduino is really the right platform.

I was able to restructure the program to use the array index where I was using the 8 bit number, so down to 2 bytes per struct, another 9% shaved. It looks like I can spare the cycles. I iterate through the 800 structs every 50 milliseconds while also handling intermittent http requests. No problems. I've been pushing the ATmega limits with this one, but I seem to be coming in well under.

Here's some further reading I happened upon later: http://www.catb.org/esr/structure-packing/

What you are facing is the classic time-memory tradeoff.  The bit fields will be smaller in memory,  but will take more time to operate on.  You can count that no matter what processor, the bit fields will be slower.
You use the word efficient, but that word has no certain meaning without a metric for what is good or bad.  When you only have 8 k of RAM, using memory is bad, time may be cheap.  If you have real time constraints, then using time is bad and memory may be cheap.  In general, you can only buy your way out of this tradeoff.  In other words, when you find both time and memory bad, spend cash and use a bigger chip.  There is no single answer for what is good or bad.  This is part of why there are so many choices for microcontrollers, people fit the chip to the application and application to the chip.
Populating the bits of a bit field will be slower than filling of complete bytes.  Take for example
x = 5;
...
asimplestruct.len = x;
// vs
abitfield.len = x;

The first simple case will just:

load value of x to a register
store it to the byte for len

The second does something like:

loads the current value of abitfield
loads a mask
clears the bits for len
loads current value of x
loads a mask
clears off unused bits of x
shifts the bits of x
or's x with the abitfield
stores the current value back to memory

If all your operations are packing data into the bit field, or unpacking out of the bitfield, you should expect slower execution.  Bit fields are a type of compression - they cost ticks.
But moving around bit fields will be faster because there are less bytes to load and store.  If you where sorting this array, the smaller byte count could be an advantage.  If you where transferring them over a serial port, the compressed size of the bitfield might be a winner.
So with respect to your question:

Is there a good way to test this?

The only good way to test this is to write test cases for both approaches using a pattern that closely matches your application.  It really matters what mix of operations you perform to decide whether the difference is negligible or significant.
When doing this sort of optimization experiment, definitely use source control on your project.  You can create a local GIT or Mercurial repository with just a few clicks.  Keeping a chain of checkpoints allows you to tear up your code exploring the effects of different implementations.  If you take a wrong turn, the repository allows you to simply go back to the last good point and try another path.
(Side note:  This time memory tradeoff exists in the opposite direction also.  If you look through the compiler options for desktop class processors, you will find something called structure packing.  This option allow you to add blank bytes between single byte fields such that they stay aligned at word or double word boundaries.  This may seem crazy to throw away RAM on purpose, but on processors with 16 or 32 bit wide registers and buses, so called word or dword aligned memory operations can be faster than byte wise operations.)

A discussion of bit-fields wouldn't be complete without mentioning that:

Structures with bit-fields may be used as a portable way of attempting to reduce the storage required for a structure (with the probable cost of increasing the instruction space, and time, needed to access the fields), or as a non-portable way to describe a storage layout known at the bit level.

[Kernighan & Ritchie, The C Programming Language, Second Edition, Appendix A-8.3]
Other posters, including yourself, have addressed the space/time tradeoff. But what is sometimes missed (possibly not relevant to your application - ?) is the complete implementation-dependence of the storage layout. This matters when applications share this data with another process: Reading or writing hardware, whose register bit-assignments are necessarily fixed; communicating the data to another system (via network or storage device doesn't matter); or to another application on the same system, that may have been compiled with a different compiler or version of the compiler.

A little tip - I see that the struct is not a 1B aligned for 8bit CPU. At the end of your struct you can add padding 2bit length or rethink increase of the size of state.
struct MyStruct
{
   uint8_t color : 3; // max value 7
   // uint8_t state : 1; *** moved, thanks Ignacio ***
   uint8_t area : 5; // m.v. 31
   uint8_t number;
   uint8_t len : 5; // m.v. 31
   uint8_t state : 1; // m.v. 1
   uint8_t padding : 2;
};

Adding the padding does not change the dynamic memory at compile time. Forgive my ignorance here, but it seems like the compiler takes care of the padding. Or is something happening at runtime to compensate if I don't include the padding?

That's true. In this case is more like a good practice.


text:
How do send sketch updates to devices without the editor?
I'd like to update the sketch of a device that a friend out of state is testing. I could have them install the full editor and send the source code but I'd rather not require them to do something so technical.
Is there a way to compile the firmware binary and push that out to a device over the COM port more directly?

In general, yes.
The compile routine creates a .hex file in a temporary directory that contains the flash image for the device. One can use AVRDUDE to upload this .hex file to the Arduino from the command line. It is simply a matter of getting the command arguments correct in order to tell it where and how to upload the image. Enabling verbose output in the IDE will tell you both exactly where the .hex file is located and what arguments are required for the board selected.

As a side note, latest openwrt version for the yun bundles reflash through http upload: you enter yun's webpanel, select the .hex to upload and click


text:
How can I stop SoftwareSerial from receiving data and re-enable it at some other point?
My project involves and RFID reader connected to an Arduino Pro Mini (5V, 16MHz) and an Adafruit CC3000 breakout WiFi chip. The device reads RFID tags and sends them to my web service. I am using Software Serial to read the RFID device data.
After I scan something, the Arduino tries to send the value that was read to the web service. This obviously causes a delay and the program only continues execution (i.e. next iteration of the loop() function) after the data has been sent.
My problem is simple. While the value is being sent, the serial buffer is can still accept scans from the RFID reader and on subsequent iterations, because there is data in the buffer the device attempts to send data again.
My question is how can I stop the software serial port from receiving data while I am trying to send data to the web service? Then when the data is sent successfully, how can I re-enable the software serial port from accepting data?

Beware the when you re-enable receiving from an asynchronously transmitter source, you will have a high chance of seeing the tail end of a message which began while you were disabled, so you will probably need logic to discard incoming characters until you see the start of a new, valid message.

Call serial.end() to stop receiving.
Then call serial.begin(...) again when you want to start listening again.

According to the docs, SoftwareSerial doesn't support .end(), so Gerben's answer won't work here, I think.
It's hacky, but you could exploit the fact that only one SoftwareSerial can receive data at a time, and create a second one, activating it with SoftwareSerial.listen().  Then .listen() again on your original SoftwareSerial, when you want to resume listening.
Or, you could do as Marty Grogan says, and flush the read buffer before starting a new read.  Again, I don't think SoftwareSerial supports a flush method as such, so you'd need to just .read() until there's nothing .available().

SoftwareSerial doesn't support .end() - it does now, maybe it did not before. @Gerben linked to the source which shows the exact lines of code. They turn off the pin-change interrupts for that pin, thus (that instance of) SoftwareSerial will no longer react to incoming data.

Again, I don't think SoftwareSerial supports a flush method as such - again, it does now, as the source code shows. You may wish to edit your answer, to keep it up to date... :-)

Whether or not the serial data becomes available really does not matter.  If you flush the port before every read rather than consuming the data, let 'er rip.  If you are using interrupts, toggle interrupts on the serial pin.

The important parts are the GPS.end() which removes the interrupt routine and effectively stops listening to input although the data continues and the GPS.begin(baud) which reinstates the interrupt routine.  The other statements are program specific and could be anything that you want to do while the input data processing is off.
I am using it on a project where I smooth scroll time/date on an LED matrix but the SoftwareSerial interrupt routine makes the scrolling jerky.  I have reduced the NMEA sentences to just one but it still takes a noticeable amount of time to process it.  So the GPS is always on and sending but I only listen 4 times per hour by doing an ss.begin() for 5 second (or until valid data), save it then do the ss.end().  Problem solved.  I get mildly jerky scrolling for 5 seconds but it is rarely noticed and my time is always right.
I will post the routine on my web site, ILikeTheInternet.com, in a few days.

If you could post the routine in your answer that would be useful, as links tends to die after a period of time. Also Iliketheinternet.com doesn't appear to respond to http requests currently.

I have successfully used two Software Serial interfaces by using the .listen() method.
SoftwareSerial swSerial1(4,5);
SoftwareSerial swSerial2(6,8);

swSerial1.begin(9600);
swSerial2.begin(9600);

At this point the Arduino is listening to swSerial2 because it was defined last. If I wanted to use swSerial1 in the loop I would call
swSerial1.listen();

And switch back with
swSerial2.listen();

This avoids the significant overhead of ending and re-beginning software serial connections.

Just a guess but I believe the current version of SoftSerial actually uses PCINT to detect the individual bits. I believe if that were disabled you would stop reception. It will take some work to get it to work without problems. This is just a guess.

I had the same problem with reading GPS-Data on Port 11 while sending APRS-Data out. This code worked for me:
GPS.end();

aprs_send();
while (afsk_busy());

GPS.begin(GPS_BAUDRATE);

Should the two lines in the middle be ran right after GPS.end() or right before GPS.begin()? What do they do?


text:
How to wait for next n bytes in I2C exchange?
I'm trying to get data from a sensor, but don't see how I can get data back. I'm looking at the data on the I2C bus with a logic analyzer, and I'm sending what I expect, but I seem to cut off the slave before he can respond.  My understanding from the datasheet is that I need to send this command to wake it up and request a measurement:
0xD8 0x30 0x0A
and then I need to send this command to get the data:
0xD8 0x06 0xD9
#define HEARTBEAT_PIN            (13)

#define 7BIT_ADDR                (0x6C)
#define ADDR_WRITE               (0xD8)
#define ADDR_READ                (0xD9)

#define MAX_NUM_RX_BYTES         (8)
#define MAX_NUM_TX_BYTES         (8)

static uint8_t tx_buffer[MAX_NUM_TX_BYTES];
static uint8_t rx_buffer[MAX_NUM_RX_BYTES];
static uint8_t new_rx_data;

void setup(void) {
  // Clear any module memory
  memset(tx_buffer, 0, MAX_NUM_TX_BYTES);
  memset(rx_buffer, 0, MAX_NUM_RX_BYTES);
  new_rx_data = false;

  Wire.begin();
}

void loop(void) {
  RequestMeasurement();
  delay(10);
  GetData();
  delay(500);
}

void RequestMeasurement(void) {
  // MR: 0xD8 0x30 0x0A
  // Internal (to IC) register address?
  tx_buffer[0] = 0x30;
  // Request-measurement command
  tx_buffer[1] = 0x0A;
  Wire.beginTransmission(7BIT_ADDR);
  Wire.write(tx_buffer, 2);
  Wire.endTransmission(true);
}

void GetData(void) {
  // GD: 0xD8 0x06 0xD9 0x?? 0x?? 0x?? 0x?? 0x?? (0x?? => slave data)
  // Slave address + 'write' indication bit
  // Internal (to IC) register address?
  tx_buffer[0] = 0x06;
  // Slave address + 'read' indication bit
  tx_buffer[1] = ADDR_READ;

  Wire.beginTransmission(7BIT_ADDR);
  Wire.write(tx_buffer, 2);
  Wire.endTransmission(true);

  // HOW DO I LEAVE THE BUS OPEN LONG ENOUGH
  // FOR THE SLAVE DEVICE TO RESPOND WITH THE DATA?
  //Wire.requestFrom(7BIT_ADDR, 3, true);
}

Ensure pullups (see datasheet for min acceptable resistance) are on I2C lines.
What I didn't understand at first was where the Wire library would bit shift and add read/write indication bits.  And those start/stop booleans.  After some testing and a closer read of the docs, I got this to work:
#include "Wire.h"

#define BAR_7BIT_ADDR         (0x6C)
#define MAX_NUM_RX_BYTES      (5)
#define MAX_NUM_TX_BYTES      (3)
#define FIRST_TEMP_BYTE_INDEX (3)

uint8_t new_rx_data;
uint8_t tx_buffer[MAX_NUM_TX_BYTES];
uint8_t rx_buffer[MAX_NUM_RX_BYTES];

void setup(void) {
  Serial.begin(57600);
  Wire.begin();
}

void loop(void) {
  // If new data is available
  if (new_rx_data) {
    new_rx_data = false;

    // Process the data in the background
    PrintRxData();
  }

  BAR_RequestMeasurement();
  BAR_GetData();

  // This is a bit of a hack to get this function to execute.
  // After attempting to register this function as a callback with
  // the Wire.onReceive() method the function wouldn't execute.
  BAR_OnDataReceived(0);

  // Wait a tit, then do it again
  delay(500);
}

void RequestMeasurement(void) {
  // MR: 0xD8 0x30 0x0A
  // Internal (to IC) register address
  tx_buffer[0] = 0x30;
  // Request-measurement command
  tx_buffer[1] = 0x0A;
  Wire.beginTransmission(BAR_7BIT_ADDR);
  Wire.write(tx_buffer, 2);
  Wire.endTransmission(true);
}

void GetData(void) {
  // GD: 0xD8 0x06 0xD9 response from slave
  // Internal (to IC) register address
  tx_buffer[0] = 0x06;
  Wire.beginTransmission(BAR_7BIT_ADDR);
  Wire.write(tx_buffer, 1);
  Wire.endTransmission(false);
  Wire.requestFrom(BAR_7BIT_ADDR, 5, true);
}

void OnDataReceived(int num_bytes) {
  uint8_t i = 0;
  while (Wire.available() && i < MAX_NUM_RX_BYTES) {
    rx_buffer[i++] = Wire.read();
  }

  // Indicate to the background that there is new rx data
  new_rx_data = true;
}

void PrintRxData(void) {
  Serial.print("Pressure [kPa]: ");
  Serial.print(ToKpa(rx_buffer));
  Serial.print("\r\n");

  Serial.print("Temperature [C]: ");
  Serial.print(ToCelsius(&rx_buffer[FIRST_TEMP_BYTE_INDEX]));
  Serial.print("\r\n");
}

// Returns the pressure in kPa given raw binary data
float ToKpa(uint8_t* raw_data) {
  // example: raw_data[3] = {0x63, 0x6C, 0xBB}; => 101.81kPa
  // return ((float)((((uint32_t)raw_data[0]) * 65536) |
  //                  (((uint32_t)raw_data[1]) * 256)  |
  //                  (((uint32_t)raw_data[2]) * 1))) / 64.0 / 1000.0;
  return ((float)((
                  (((uint32_t)raw_data[0]) << 16) |
                  (((uint32_t)raw_data[1]) << 8)  |
                  (((uint32_t)raw_data[2]) << 0)
                  ) >> 6)) / 1000.0;
}

// Returns the temperature in Celsius given raw binary data
float ToCelsius(uint8_t* raw_data) {
  // example: raw_data[2] = {0x18, 0xE6}; => 24.90C
  // return ((float)(((uint32_t)raw_data[0]) * 256) + (((uint32_t)raw_data[1]) * 1)) / 256.0;
  return ((float)(
                 (((uint32_t)raw_data[0]) << 8) |
                 (((uint32_t)raw_data[1]) << 0)
                 )) / 256.0;
}

First off; when talking about I2C bus, an important point to clarify: did you connect pullup resistors to both SDA and SCL lines (A4 and A5 respectively)? Without those, the I2C bus will not work properly.
Next, I2C protocol is quite low-level and a bit complex; but fortunately, the Wire library that comes with Arduino helps a lot and hides some of this complexity.
When using Wire library, there is a first point to keep in mind:
The device address is 7 bits only, the 8th bit is used to define the direction of data (read or write). You don't need to care about this direction bit as Wire deals with it for you.
In your situation, the device address is 0x6C, ie 1101100 in binary.
The commands you mentioned that you want to send to the device, 0xD8 0x30 0x0A and 0xD8 0x06 0xD9 already include the device address and the write bit (0):
0xD8 is 1101 1000 ie 1101100 plus the 0 direction bit at the end.
Please note that 0xD8 0x06 0xD9 is made of 2 commands actually:

0xD8 0x06 is a write command to tell the device hich register we want to read
0xD9 is just the device address followed by the read bit (1): this is the way the I2C master tells a slave that the former will now wait for data sent from the latter.

It is important to split this command in 2 because each will use a specific API from Wire library.
Writing to your device with the Wire library will be done this way:
// First command: start measurement
Wire.beginTransmission(0x6C);
Wire.write(0x30);
Wire.write(0x0A);
Wire.endTransmission();

// Second command: tell the device what register we want to read
Wire.beginTransmission(0x6C);
Wire.write(0x0A);
Wire.endTransmission();

Then you can start reading from your device with a different API:
Wire.requestFrom(0x6C, 3);
byte b1 = Wire.read();
byte b2 = Wire.read();
byte b3 = Wire.read();
// Now rebuild value from the 3 bytes just read...

Note that Wire.requestFrom(0x6C, 3); will send the 0xD9 that is calculated from the device address 0x6C and the read bit. SO you don't have (and you should not) send 0xD9 yourself, Wire doesit for you.
Please note that I use Wire.endTransmission() without the stop argument. Not sure if this is mandatory, but it worked fine on my I2C experiments.

In the diagram there is a S after sending 0x60. You first write to the device, letting it you want to read, and then you start reading.
I think you need to do something like
void GetData(void) {
  Wire.beginTransmission(7BIT_ADDR);
  Wire.write(0x06);
  Wire.endTransmission(false);//don't terminate connection

  Wire.requestFrom(7BIT_ADDR, 3);//this will send the 0xD9
  pressure = ( (uint32_t) i2cread() << 16) | ( i2cread() << 8 ) | i2cread();//or something

}

But I've never used I2C.