Electronic – arduino – How to develop software for the Arduino

I understand the best way would be to show them. But some things need to be explained before that.

I disagree, unless you have to pitch the Arduino over a phone. A small kit is portable enough that it can be brought to any meeting or chat, and even set up and played with on a small table with enough room for lunch for a lunch meeting. In fact you can bring a model than illustrates each point I'm going to make below, and it'll all still fit in a small box, lay out completely on a small table, powered by batteries, and be durable enough to be handled without breaking by the person you are pitching to.

A pitch is a conversation that is largely one-way due to you anticipating and answering all their needs and issues before they voice them, and often before they even know they have that need.

You have two audiences, technical people, and schools. You're going to have to understand their needs before you can develop the pitches, and while there will be some overlap, you'll find that the pitches will focus on fundamentally different needs/issues.

For technical friends:

• Arduino is FUN
• Arduino is EASY
• Arduino is FAST
• Arduino is CHEAP

Hobbyists are, above all, in it for the fun. Show them that it's fun to build with arduino, and the reason it's fun is that it's easy and fast. They are concerned about price, but most are willing to pay a bit more if it makes it easy to build something with complex behavior.

For schools:

• Arduino is ROBUST
• Arduino is EASY AND FUN TO LEARN
• Arduino teaches important TECHNOLOGY
• Arduino is EASY TO TEACH
• Arduino is CHEAP

Schools are not as concerned about cost as they say they are. Check out the science catalogs to see that educational products are more expensive, partly because they are more robust (last longer in a student environment) and partly because they are built into a curriculum so the teachers can spend more time teaching and less time preparing to teach.

So the school needs to know that it's hard for a student to break an arduino (intentionally or not), they need to know that it's easy for the students to learn, which is helped by the fact that it's fun. They need to know that important skills students absolutely need in the future will be taught by the process of learning about the arduino. They need to know that it's easy to teach - they don't have to send teachers to a training course, non-technical teachers will be able to solve most arduino problems (or there's a good community that will support the teacher), and that the curriculum is already in place with the suggested parts and kits. Lastly, it still has to be cheap.

Unfortunately, the arduino fails rather spectacularly at two of these tasks, and is complicated by a few others:

It's not robust. Place a stray wire between one of the pins set to output high and ground, and you may fry a single port. It might not be caught, but could 'spoil' the results of later student projects for months or years before it's noticed, diagnosed, and repaired. Damage needs to be very difficult, and when it occurs it needs to be instantly noticeable, and easily and cheaply repairable.

It's not easy to teach. There's no established curriculum. Any teacher doing this will need to make their own curriculum up as they go, which means they need to be at an advanced level of understanding with the Arduino, which requires training. Teaching may be a labor of love, but it's also a job, and the school isn't going to pay for them to learn it on school time, and they aren't going to spend their free time to learn it. There isn't enough support to get a new, untrained teacher going even if the curriculum was already set. They would constantly be stymied by small problems and would lose days trying to diagnose problems and get students re-started on their projects because they can't call a mentor (or technical support) and get an instant diagnosis and fix.

Forming a curriculum is hard, but making it teach technology principles that are general and arguably useful for the average student is very difficult work to do well. Then you have to add fun and interesting on top of it so students actually learn the principles, rather than just following instructions, getting the expected results, and moving on having gained no significant knowledge.

This doesn't even begin to touch infrastructure issues - computer lab use, safety issues, dealing with IT for the software and drivers that need to be installed, etc.

The point should not be to train them to use arduino (ie, rote memory or mere knowledge). The point should be to increase their ability to understand a system/principle (analysis), and then leap from there to new thoughts, ideas, and concepts (synthesis).

It's not trivial work. But you have to start somewhere, and showing them a 6 month cirriculum in a 5 minute presentation on a table during lunch is going to be your best bet.

Wow, you're certainly rebuilding your project the hard way.

There is a single click (or keystroke) solution to rebuilding any changed files, and programming the mcu with the new binary. You're looking for the "run" command, which is F5 in a default install. You can also access it from the debug menu, you want the "continue" command (no, I don't know why it's named that).

You can also hit the green "play arrow" (in the blue box) on The toolbar to rebuild and launch with the debugger attached. It's the shortcut to the run command. The Non-filled "play" arrow (in the red box) will rebuild and launch your project without the debugger attached.

Re: Tooltips - The Green arrow's tooltip is Start Debugging. It should probably really be
Start *with* debugger. The Green arrow outline's tooltip is Start without debugging, which is more clear.
I suspect a lot of this is behaviour inherited from Visual Studio, which Atmel Studio is built on. If you're familiar with one, the other becomes a lot more predictable.