I am an 80-year old who has been struggling with Arduino for two years. I have had some success with driving steppers and following the excellent Paul McWhorter online tutorials up to number 7 . I have bought several books on Arduino but cannot find answers to the following simple questions:
How can I save a sketch and transfer it to other computers? Ideally keeping the colours? I have a collection of archived sketches.. but would like to back them up.
How can I print out a sketch for study? I am using a PC with Windows 11.
I have a sketch I wrote last year archived with the name sketch_sep23a . Will it be overwritten this year if I write a sketch on September 23rd? I do not understand why the Arduino sketch names do not include the year.
Your sketches are saved (by default) into your sketchbook folder in a folder of their own. Simply copying your sketchbook folder will copy the sketches within them
select the sketch contents inside the IDE (select all ctrl-A) and paste it into a text file which you can print.
You can name a sketch to whatever you want, but nothing ever gets overwritten without confirmation.
In Arduino IDE, in menu File is item Preferences, click it, it opens dialog, where the base directory for all your sketches is shown. Remeber it and close the dialog.
Go to this directory, each sketch is in its own subdirectory. Copy this subdirectory to another computer under Arduino base directory and your sketch is right there.
The sketch are text files (name.ino and maybe others) and it can be opened as text file and printed in any program which is able print. (Or even better, Ctrl+A Ctrl+C in Arduino IDE, CTRL+V in Word, notepad, ... so the other program does not try overwrite yous sketch with "better format")
Arduino IDE will ask you under which name to save this sketch, so simply use different name. It is the same, as when you create and save two new sketches in one day
Thank you, Deva. I have checked and all three of your answers work perfectly and help me a great deal. People of my age tend to need to print and read in order to learn, so these basic operations are crucial to folk like me.
Thank you Tigger. I will try Arduino Cookbook. I find it amazing that there is no mention of printing one's sketches in either 'Arduino for Dummies' by Nussy or 'Programming Arduio' by Monk or the Banzi & Shiloh book. Maybe it is all obvious to the young..... Like the original Tigger, I hope you never hurt yourself when you jump down from trees.
Very helpful advice! Thank you! I have checked and see that I do get a warning of the danger of overwriting. I now feel confident enough to salvage my sketches from four or five years of attempts at Arduino. I just wish the books had given more prominent warnings that you cannot download anything that you have uploaded into the Arduino board, not even the name of the sketch it contains.... so punctilious record-keeping is essential unless you have an unusually infallible memory. Thank you to all you kind folk who have answered my questions so quickly!
Yes, I just tried following the advice of Deva and Tigger: I now have beautiful Word printouts ready for my colour printer. May you long continue: as I hope to do... Brad
But I did fall out of the loft.
Very painful, had to learn to walk again.
The great thing about Arduino is that you can do as much or as little as you like.
And it's good brain exercise.
Give your sketches a name that describes the program.
Add a prefix for the latest version.
Example: MotorStepper_Ver01
Starting a new project
I start with making a preliminary schematic of what hardware I think is needed.
This schematic usually goes through many iterations before being finalized. During this stage I also try to identify critical signals, power requirements, timing-sensitive sections, communication interfaces, and possible expansion points for future features.
Before writing code, I try to break the project into functional blocks or subsystems.
Examples might include user interface handling, communications, sensor processing, control logic, data logging, safety monitoring, and diagnostics. Defining these blocks early helps prevent the software from turning into one large monolithic program.
I often sketch out the expected flow of operation using simple state diagrams or flowcharts.
This helps identify startup conditions, normal operating modes, fault handling, timeout recovery, and how different states transition from one to another.
I try to define the interfaces between software modules early in the design.
This includes deciding what data each module owns, how information is exchanged, and which modules should remain independent of hardware details.
Timing considerations are planned early.
I identify which operations are time critical, which can run periodically, and which should be event driven. This helps determine whether a blocking or non-blocking design approach is appropriate.
Over the years I’ve made software tool sets which contain examples of code blocks that always seem to be needed.
These are generic in nature and cutting and pasting them into a new project works well for me.
My reusable code blocks often include things such as:
Non-blocking timers
State machine frameworks
Serial command interfaces
SPI/I2C communication handlers
Debug logging utilities
Fault detection and watchdog handling
EEPROM/Flash storage helpers
Input debouncing
Startup self-tests
Hardware abstraction layers
I usually add debugging capability very early in development.
Having visibility into internal states, timing, events, and fault conditions can save enormous amounts of debugging time later. Logic analyzer outputs, serial diagnostics, event counters, and trace markers are often worth planning from the beginning.
I try to separate experimental code from production code.
Temporary test routines and hardware experiments are useful during development, but keeping them isolated prevents long-term maintenance problems.
I keep hardware assumptions documented inside the code.
Pin assignments, timing requirements, voltage limits, communication settings, and expected signal behavior are all easier to maintain when documented close to the code that depends on them.
I usually create a basic bring-up plan before hardware arrives.
This includes deciding how power rails will be verified, how clocks and communication buses will be tested, and what minimum firmware is needed to confirm the hardware is alive.
Error handling is designed intentionally instead of being added later.
I try to determine what should happen if sensors fail, communication is lost, invalid data appears, or power interruptions occur.
I prefer building and testing projects incrementally.
Getting small sections fully working before adding complexity usually produces more stable systems and simplifies troubleshooting.
Naming conventions and code organization matter more as projects grow.
Consistent file structure, module naming, and documentation make future modifications much easier, especially months or years later.
I try to leave room for future diagnostics and expansion.
Extra test points, spare I/O pins, unused debug channels, and modular software interfaces often become valuable later in the project lifecycle.
AI is becoming a good way of asking for ideas, opinions, and reviewing work.
It can often suggest alternative approaches, point out possible design weaknesses, explain unfamiliar concepts, and help evaluate tradeoffs between different implementation methods.
AI can also help generate starting templates for code, state machines, communication handlers, and test routines.
Even when the generated code is not used directly, it can accelerate brainstorming and reduce development time.
AI tools can be useful for reviewing schematics, debugging strategies, timing logic, and software architecture decisions.
Sometimes simply explaining a problem to an AI system helps clarify the problem itself.
AI is also useful for creating documentation, generating comments, improving code readability, and helping organize large projects.
This can make long-term maintenance easier, especially for projects revisited after long periods of time.
AI should still be treated as an assistant rather than a final authority.
Generated answers, code, and design suggestions should always be reviewed, tested, and validated against real hardware and project requirements.
You've got me by 10 or 11 years and I dunno what you did before. I was a programmer who knew enough tech to get by and get better.
When you open the IDE, also open your web browser and set up a tab with that Main Arduino Learn page on it. Open more tabs for every help page you need, make the text AS BIG AS YOU NEED, this is the new book, the new paper, it's easier than the old way with stacks of manuals to flip and flop through, at least for me with a 40" HDMI screen 3 feet from my face. If you have a laptop, see if it doesn't have an HDMI port.. mine does and my RPi does too.
It's a feast of useful topics, many cropping up here and I have confidence in the way he goes through everything.
And screens too. No longer a luxury, but a necessity. 23" monitor adequate enough.
An optician told me quite a few years ago, "you'll need glasses by 45" and so it turned out.
Jewellers magnifiers, illuminated magnified work lamp, daylight colour LED lamps.
Had the luxury of a stereo microscope at work plus a Versatronics robotic arm for PCB prototyping.
I am 84 and have been involved with electronic hardware and then software since 1959. Worked for IBM up to the staff level, then Chief Programmer for a major company, then owned my own Consulting company with two other employees. High school tech grad, lots of IBM and other courses. Arduino self-taught with mega help from this forum.
Post 15 is a university-level course outline, and post 16 gives you the best links I know of. All I will add is that you will also learn a lot from reading and doing the projects in the 'Arduino Cookbook'.
I, too, am 'old school' and like printed output. I searched and found a printing plugin for the IDE as shown below, but seldom use it. Almost everyone uses a screen today, even though the screen is wrong way round, it would be much more usable in portrait mode (long, vertical). Some folks use a 24" 4/5k display and use 2 up so 2 full pages are visible. That is what I call a win-win, right way round and 2 of them!
I see the publication date of "Arduino for Dummies" is 2013, and that of "Getting Started with Arduino" 2014. At that time, we were in the 1.x version series of Arduino IDE. At that time, Arduino IDE had a built-in printing capability, so anyone who felt the need to inflict their code on the corpse of a tree could do so in the standard manner by simply selecting File > Print from the Arduino IDE menus. So the authors probably didn't see the need to provide instructions for doing this.
I see the 3rd edition of "Programming Arduino" was published in 2022, shortly after the first production release of the complete rewrite of the Arduino IDE application that is the 2.x series. However, I see the cover says "Fully revised for Arduino IDE 1.8", so it appears that the 3rd edition was not written for Arduino IDE 2.x users (which is understandable considering Arduino IDE 2.x was surely still in the beta development phase at the time of writing). And of course previous editions of Programming Arduino were written prior to the time of Arduino IDE 2.x.
If you would like to add a printing capability to Arduino IDE 2.x, you can follow the instructions shared here:
