UnoArduSimV1.7.

2 Full Help

Table of Contents

Overview

Program Pane, Preferences, and Edit/View

Code Pane

Preferences

Edit/View

Variables Pane and Edit/Track window

Lab Bench Pane

The Uno

I/O Devices
Serial Monitor (SERIAL)
Software Serial (SFTSER)
SD Disk Drive(SD_DRV)
Shift Register Slave (SRSLV)
Configurable SPI Slave (SPISLV)
Two-Wire I2C Slave (I2CSLV)
Stepper Motor (STEPR)
DC Motor (MOTOR)
Servo Motor (SERVO)
Digital Pulser (PULSER)
One-Shot (1SHOT)
Analog Function Generator (FUNCGEN)
Piezoelectric Speaker (PIEZO)
Push Button (PUSH)
Slide Switch Resistor (R=1K)
Coloured LED (LED)
Analog Slider

Menus
File menu commands:
Load INO or PDE Prog (ctrl-L)
Edit/View (ctrl-E)
Save
Save As
Next (#include) file
 Previous
Exit
Find menu commands:
Find Next Function/Var
Find Previous Function/Var
Set Search Text (ctrl-F)
Find Next Text
Find Previous Text
Execute menu commands:
Step Into (F4)
Step Over (F5)
Step Out Of (F6)
Run To (F7)
Run Till (F8)
Run (F9)
Halt (F10)
Reset
Animate
Slow Motion
Options menu commands:
Step Over Structors/Operators
Register-Allocation Modelling
Error on Uninitialized
Added loop() Delay
Configure menu commands:
I/O Devices
Preferences
VarUpdates menu commands:
Allow Auto (-) Collapse
Allow Reduction
Minimal Updates
HighLight Updates
Windows menu commands:
Serial Monitor
Restore All
Prompt
Pin Digital Waveforms
Pin Analog Waveform
Help menu commands:
Quick Help File
Full Help File
Bug Fixes
Change/Improvements
About

Modelling
Intro

Timing

I/O Devices
 Sounds

Limitations and Unsupported Elements

Included Files
Dynamic Memory allocations and RAM
Flash Memory Allocations
Strings
Arudino Libraries
Pointers
Classes and Structs
Scope
Unsigned Const, Volatile, Static
Compiler Directives
Arduino-language elements
C/C++-language elements
Function Templates
Real-Time Emulation

Release Notes
Bug Fixes
V1.7.2– Feb. 2017
V1.7.1– Feb. 2017
V1.7.0– Dec. 2016
V1.6.3– Sept. 2016
V1.6.2– Sept. 2016
V1.6.1– Aug. 2016
V1.6– June 2016
V1.5.1– June 2016
V1.5 – May 2016
V1.4.3 – Apr. 2016
V1.4.2 – Mar. 2016
V1.4.1 – Jan. 2016
V1.4 – Dec. 2015
V1.3 – Oct. 2015
V1.2 – Jun 2015
V1.1 – Mar 2015
V1.0.2 – Aug 2014
V1.0.1 – June 2014
V1.0 -- first release May 2014
Changes/Improvements
V1.7.2– Feb. 2017
V1.7.1– Feb. 2017
V1.7.0– Dec. 2016
V1.6.3– Sept 2016
V1.6.2– Sept 2016
V1.6.1– Aug 2016
V1.6 – June 2016
V1.5.1 – June 2016
V1.5 – May 2016
V1.4.2 – Mar 2016
V1.4 – Dec 2015
V1.3 – Oct 2015
Version 1.2 June 2015
V1.1 – Mar 2015
V1.0.1 – June 2014
 V1.0 -- first release May 2014

Overview
UnoArduSim is a freeware real-time (see Modelling for Timing restrictions) simulator tool that I have developed for
the student and Arduino enthusiast. It is designed to allow you to experiment with, and to easily debug, Arduino
programs without the need for any actual hardware. It is targeted to the Arduino Uno board, and allows you to
choose from a set of virtual I/O devices, and to configure and connect these devices to your virtual Uno in the
LabBench Pane. -- you don't need to worry about wiring errors, broken/loose connections, or faulty devices messing
up your program development and testing.

UnoArduSim provides simple error messages for any parse or execution errors it encounters, and allows debugging
with Reset, Run, Run-To, Halt, and flexible Stepping in the Code Pane, with a simultaneous view of all global and
currently-active local variables, arrays, and objects in the Variables Pane. Run-time array-bounds checking is
provided, and ATmega RAM overflow will be detected (and the culprit program line highlighted!). Any electrical
conflicts with attached I/O devices are flagged and reported as they occur.

When an INO or PDE program file is opened, it is loaded into the program Code Pane. The program is then parsed,
and "compiled" into a tokenized executable which is then ready for simulated execution (unlike Arduino.exe, a
standalone binary executable is not created) Any parse error is detected and flagged by highlighting the line that failed
to parse, and reporting the error on the Status Bar at the very bottom of the UnoArduSim application window. An
Edit/View window can be opened to allow you to see and edit a syntax-highlighted version of your user program.
Errors during simulated execution (such as mis-matched baud rates) are reported on the Status bar, and via a pop-up
MessageBox.

UnoArduSim V1.7.0 is a substantially complete implementation of the Arduino Programming Language V1.6.6 as
documented at arduino.cc.'s Language Reference web page, and with additions as noted in the version's Download
page Release Notes. Although UnoArduSim does not support the full C++ implementation that Arduino.exe's
underlying GNU compiler does, it is likely that only the most advanced programmers would find that some C/C++
element they wish to use is missing (and of course there are always simple coding work-arounds for such missing
features). In general, I have supported only what I feel are the most useful C/C++ features for Arduino hobbyists and
students -- for example, enum's and #define's are supported, but function-pointers are not. Even though user-defined
objects (classes and structs) and (most) operator-overloads are supported, multiple-inheritance is not.

Because UnoArduSim is a high-level-language simulator, only C/C++ statements are supported, assembly language
statements are not. Similarly, because it is not a low-level machine simulation, ATmega328 registers are not
accessible to your program for either reading or writing, although register-allocation, passing and return are emulated
(it you choose that under the Options menu).

As of V1.7.0, UnoArduSim has built-in automatic support for a limited subset of the Arduino provided libraries, these
being: Stepper.h, SD.h, Servo.h, SoftwareSerial.h, SPI.h, Wire.h, and EEPROM.h (version 2). For any #include'd
user-created libraries, UnoArduSim will not search the usual Arduino installation directory structure to locate the
library; instead you need to copy the corresponding header (.h) and source (.cpp) file to the same directory as the
program file that your are working on (subject of course to the limitation that the contents of any #include'd file(s)
must be fully understandable to UnoArduSim's parser).

I developed UnoArduSIm in Microsoft Visual C++, and it is currently only available for Windows TM. Porting to Linux or
MacOS, is a project for the future.! UnoArduSim grew out of simulators I had developed over the years for courses I
taught at Queen's University, and it has been tested reasonably extensively, but there are bound to be a few bugs still
hiding in there. If you would like to report a bug, please describe it (briefly) in an email to [email protected] and
be sure to attach your full-bug-causing-program Arduino source code so I can replicate the bug and fix it. I will
not be replying to individual bug reports, and I have no guaranteed timelines for fixes in a subsequent release
(remember there are almost always workarounds!).

Cheers,
Stan Simmons, Ph.D, P.Eng.
Associate Professor (retired)
Department of Electrical and Computer Engineering
Queen's University
Kingston, Ontario, Canada
Program Pane, Preferences, and Edit/View

Code Pane

The Code Pane displays your user program, and highlighting tracks its execution.
After a loaded program is successfully parsed, the first line in main( ) is highlighted, and the program is ready for
execution. Note that main( ) is implicitly added by Arduino (and by UnoArduSim) and you do not include it as part of
your user program file. Execution is under control of the Execute menu and associated toolbar icons and keyboard
shortcuts.

After stepping execution by one (or more) instructions,

the next-to-be executed program line is then highlighted
(the highlighted line is always the next line ready to be
executed using , , , or ).

Similarly, when a running program hits a (temporary

Run-To) breakpoint, execution is halted and the
breakpoint line is highlighted (and is then ready for
execution). When a program is running, UnoArduSim
periodically highlights the current program line so you
can see that some activity is happening. This
highlighting will cause the Code Pane window contents
to scroll to the keep highlighted line visible.

If program execution is currently halted, and you click in

the Code Pane window, the line you just clicked
becomes highlighted. This does not, however, change
the current program line as far as program execution is
concerned. But you can cause execution to progress up
to the line you just highlighted by then clicking the
RunTo toolbar button. This feature allows you to
quickly and easily reach specific lines in a program so
that you could subsequently step line-by-line over a
program portion of interest.

If your loaded program has #include'd files, you can move between them using the File menu items FileàPrev File
and FileàNext File for this, or by using the associated left and right blue arrow toolbar buttons , .

The Find menu (with shortcuts PgDn and PgUp or and ) allows you to quickly jump between functions in the
Code Pane (but you must first click a line inside the Code Pane to give it focus). Or you can jump to specified text
(after first using Find->Set Search text, or ) with the menu's text-search commands, or, more simply, the and
toolbar icons.

Preferences

ConfigureàPreferences allows users to set program

options and viewing preferences (that a user will
normally wish to adopt at he next session). These can
therefore be saved and loaded from a myArduPrefs.txt
file that resides in the same directory as the loaded Uno
program ( myArduPrefs.txt is auto-loaded if it exists)

This dialog allows a choice between two mono-spaced

fonts and three typeface sizes, as well as other
miscellaneous user prferences.
Edit/View

By double-clicking on any line in the Code Pane (or using the File menu), an Edit/View window is opened to allow
changes to your program file, with the Code Pane's currently selected line highlighted.

This window has full edit capability with dynamic syntax-highlighting (different highlight colours for C++ keywords,
comments, etc.), optional bold syntax highlighting, and automatic indent-level formatting (assuming you have selected
that using the ConfigureàPreferences dialog). You can also conveniently select built-in function calls (or pre-
#define'd constants) to be added into your program from the provided ListBox (just double-click on the desired
ListBox item to add it to your program at the current caret position – function-call variable types are just for information
and are stripped out (leaving dummy placeholders) when added to your program).

The window has Find (use ctrl-F) and Find/Replace capability (use ctrl-H). The Edit/View window has UnDo (ctrl-Z),
and ReDo (ctrl-Y) buttons, so you can sequentially undo/redo any changes you have made since. All changes made
on the same program line count as a single undo/redo, as do any Replace-All operations.

To discard all changes you made since you first opened the program for editing, click the Cancel button. To adopt the
current state, click the Adopt button and the program is automatically re-parsed (and downloaded if no errors are
found) and the new status appears in the main UnoArduSim window Status Bar.

A new Compile (ctrl-R) button (plus an associated Parse-Error message box as seen in the image above) has been
added to allow testing of edits without needing to first close the window. A new Save (ctrl-S) button has also been
added as a shortcut (equivalent to an Adopt plus a later separate Save from the main window).

On either Cancel or Adopt with no edits made, the Code Pane current line changes to become the last View/Edit
caret position, and you can use that feature to jump the Code Pane to a specific line (possibly to prepare to do a Run-
To), You can also use ctrl-PgDn and ctrlPgUp to jump to the next (or previous) empty-line break in your program –
this is useful for quickly navigating up or down to significant locations (like empty lines between functions). You can
also use ctrl-Home and ctrl-End to jump to the program start, and end, respectively.

Tab-level auto-indent-formatting is done when the window opens if you have left that set in the Configureà
Preferences dialog. You can also add or delete tabs yourself to a group of pre-selected consecutive lines using right-
arrow or left-arrow – but autoformat must be off to avoid losing your own tab levels.

And to help you better keep track of your contexts and bracing, clicking on a '{' or '}' brace highlights all text
between that brace and its matching partner.
Variables Pane and Edit/Track window
The Variables pane is located just below the Code Pane. It shows the current values for every user-global and active
(in-scope) local variable/array/object in the loaded program. As your program execution moves between functions, the
contents change to reflect only those local variables accessible to the current function/scope, plus any user-
declared globals. Any variables declared as 'const' or as PROGMEM (allocated to flash memory) have values that
cannot change, and to save space these are therefore not displayed. Servo and SoftwareSerial object instances
contain no useful values so are also not displayed.

The Find menu (with shortcuts PgDn and PgUp or and ) allows you to quickly jump between variables in the
variables Pane (but you must first click a line inside the Pane to give it focus). Or you can jump to specified text (after
first using FindàSet Search text or ) with the menu's text-search commands, or, more simply, the and
toolbar icons.

Arrays and objects are shown in either un-expanded or expanded format, with either a trailing plus (+) or minus(-)
sign, respectively. The expanded/un-expanded symbol for an array x shows as x[]. To expand it to show all elements
of the array, just single-click on x[](+) in the Variables pane. To collapse back to an unexpanded view, click on the
x[](-). The un-expanded default for an object p1 shows as p1(+). To expand it to show all members of that class or
struct instance, single-click on p1(+). in the Variables pane. To collapse back to an un-expanded view, single click on
p1(-).

If you single-click on any line to highlight it (it can be simple variable, or the aggregate (+) or (-) line of an array
or object, or an single array element or object-member), then doing a RunTill will cause execution to resume and
freeze at the next write-access anywhere inside that selected aggregate, or to that selected single variable location.

When Step-ping or Run-ning, updates to displayed variable values are made according to user settings made under
the VarUpdates menu – this allows a full range of behaviour from minimal periodic updates to full immediate updates
(reduced or minimal updates are useful to reduce CPU load and may be needed to keep execution from falling behind
real-time under what would otherwise be excessive Variables Pane window-update loads). When Animate is in effect,
or if the Highlight Changes VarUpdates menu option is selected, changes to the value of a variable during Run-ning
will result in its displayed value being updated immediately, and it becomes highlighted-- this will cause the Variables
Pane to scroll (if needed) to the line that holds that variable, and execution will no longer be real-time!.

When execution freezes after Step, RunTo, RunTill, or Run-then-Halt, the Variables Pane highlights the variable
corresponding to the address location(s) that got modified (if any) by the very last instruction during that
execution (including by variable-declaration initializations) . If that instruction completely filled an object or array, the
parent (+) or (-) line for that aggregate becomes highlighted. If, instead, the instruction modified a location that is
currently visible, then it becomes highlighted. But if the modified location(s) is(are) currently hiding inside an un-
expanded array or object, that aggregate's parent line gets a dashed outline as a visual cue that something inside it
was written to – clicking to expand it will then cause its last modified element or member to become highlighted.

This window also gives you the ability to track any variable s value during execution, or to change its value in
the middle of (halted) program execution (to test what would be the effect of continuing on ahead with that new
value). Halt execution first, then left-double-click on the variable whose value you wish to track or change:
To simply monitor the value during program execution, you leave the dialog open and then do Run, RunTo, RunTill,
or one of the Step commands – its value will be updated in Edit/Track according to the same rules that govern
updates in the Variables Pane. To change the variable's value, fill in the right-hand Edit box, and Adopt the new
value. Continue program execution (using any of the Step or Run commands) to use that new value from that point
forward (you can Revert to the previous value f you change your mind before then)

On program Load or Reset note that all un-initialized value-variables are reset to value 0, and all un-initialized
pointer-variables are reset to 0x0000.

Lab Bench Pane

The Lab Bench Pane shows a 5-volt Uno board which surrounded by a set of I/O devices that you can
select/customize, and connect to your desired Uno pins.

The Uno

This is a depiction of the Uno board and its onboard LEDs. When you load a new program into UnoArduSim, if it
successfully parses it undergoes a "simulated download" to the Uno that mimics the way an actual Uno board
behaves– you will see the serial RX and TX LED's flashing (along with activity on pins 1 and 0 which are hard-wired
for serial communication with a host computer). This is immediately followed by a pin 13 LED flash that signifies board
reset and (and UnoArduSim automatic halt at) the beginning of your loaded program's execution. You can avoid this
display and associated loading lag by deselecting Show DownLoad from the ConfigureàPreferences dialog.

The window allows you to visualize the digital logic levels on all 20 Uno pins ('1' on red for HIGH, '0' on blue for LOW,
and '?' on grey for an undefined indeterminate voltage), and programmed directions ('I' for INPUT, "O" for OUTPUT).
For pins that are being pulsed using PWM via analogWrite( ), or by Tone( ), or by Servo.write( ), the
colour changes to purple and the displayed symbol becomes '^'.

Note that Digital pins 0 and 1 are hard-wired through 1-kOhm resistors to the USB chip for serial
communication with a host computer.
ASIDE: Digital pins 0-13 appear as simulator pins 0-13, and analog pins 0-5 appear as A0-A5 . To access an analog
pin in your program, you can refer to the pin number by one of two equivalent sets of numbers: 14-19; or A0-A5 (A0-
A5 are built-in-in const variables having values 14-19). And only when using analogRead( ), a third option is made
available – you can, for this one instruction, drop the 'A' prefix from the pin number and simply use 0-5. To access pins
14-19 in your program using digitalRead( ) or digitalWrite( ), you can simply refer to that pin number, or
you may instead use the A0-A5 aliases.

Clicking on any of the Uno's pins can be done to open (or add to) either a Pin Digital Waveforms window or a Pin
Analog Waveform window – both display the past one-second's worth of activity on that pin, as described next.
Left-clicking on any Uno pin will open a Pin Digital Waveforms window that displays the past one-second's worth of
digital-level activity on that pin. You can click on other pins to add these to the Pin Digital Waveforms display (to a
maximum of 4 waveforms at any one time).

To ZOOM IN and ZOOM OUT (zoom is always centered on the ACTIVE cursor), use the mouse wheel, or
keyboard shortcuts CTRL-up_arrow and CTRL-down_arrow.

cursor backward- cursor forward-

to- edge (or use to-edge (or use
L-arrow key) R-arrow key)

activate wave
delete wave

activate activate
BLUE cursor RED cursor

sense rising sense falling

edges edges
click to page view left or right, or use keys Home, PgUp, PgDn, End

One of the displayed waveforms will be the active pin waveform, indicated by its "Pin number" button being shown as
depressed (for example Pin 6 is active in the above Pin Digital Waveforms screen capture). You can select a
waveform by clicking its Pin number button, and then select the edge-polarity of interest by clicking the appropriate
rising/falling edge-polarity selection button, , or , or by using the shortcut keys uparrow and downarrow.You can
then jump-position the active cursor (either blue or red cursor lines with their delta time shown) backward or forward to
the chosen-polarity digital edge of this active pin waveform by using the forward/backward-to-edge arrow buttons ( ,
and , depending on activated cursor), or the keyboard shortcuts leftarrow and rightarrow.

To activate a cursor, click its coloured activation button (shown above) – this also jump-scrolls the view to that cursor's
current location. Alternatively, you can quickly alternate activation between cursors (with their respectively-centred
views) using the shortcut TAB key.

You can jump-position the currently activated cursor by left-clicking anywhere in the on-screen waveform view
region. Alternatively, you can select either the red or blue cursor line by clicking right on top of it (to activate it), then
drag it to a new location, and release. When a desired cursor is currently somewhere off-screen, you can right-click
anywhere in the view to jump it to that new on-screen location. If both cursors are already on-screen, right-clicking
simply alternates between activated cursor.
Doing instead a right-click on any Uno pin opens a Pin Analog Waveform window that displays the past one-
second's worth of analog-level activity on that pin. Unlike the Pin Digital Waveforms window, you can only display
one pin's worth of analog activity at any one time.

You can jump-position blue or red cursor lines to the next rising or falling "slope point" by using the forward/backward
arrow buttons ( , or , , again depending on activated cursor, or leftarrow or rightarrow) in concert with the
rising/falling slope selection buttons , (the "slope point" occurs where the analog voltage passes through the
ATmega pin's high-digital-logic-level threshold). Alternatively, you can again click-to-jump, or drag these cursor lines
similar to their behaviour in the Pin Digital Waveforms window

I/O Devices

A number of different devices surround the Uno on the perimeter of the Lab Bench Pane. "Small" I/O devices (of
which you are allowed up to 16 in total) reside along the left and right sides of the pane. "Large" I/O devices (of which
you are allowed up to 8 in total) have "active" elements and reside along the top and bottom of the pane. The desired
number of each type of available I/O device can be set using the Configureà I/O Devices menu selection.

Each IO device has one or more pin attachments shown as a two-digit pin number (00, 01, 02, … 10,11,12, 13 and
either A0-A5, or 14-19, after that) in a corresponding edit box.. For pin numbers 2 through 9 you can simply enter the
single digit – the leading 0 will be automatically provided, but for pins 0 and 1 you must first enter the leading 0. Inputs
are normally on the left side of an I/O device, and outputs are normally on the right (space permitting). All I/O devices
will respond directly to pin levels and pin-level changes, so will respond to either library functions targeted to their
attached pins, or to programmed digitalWrite( )'s (for "bit-banged" operation)
.
You can connect multiple devices to the same ATmega pin as long as this does not create an electrical conflict. Such
a conflict can be created either by an Uno OUTPUT pin driving against a high-drive (low-impedance) connected device
(for example, driving against a FUNCGEN output, or a DCMOTOR encoder output), or by two connected devices
competing with each other (for example both a PULSER and a PUSH-button attached to the same pin). Any such
conflicts would be disastrous in a real hardware implementation and so are disallowed, and will be flagged to the user
via a pop-up message box)

The Configureà IO Devices menu item can be used to open a dialog to allow the user to choose the type(s), and
numbers, of desired I/O devices. From this dialog you can also Save I/O devices to a text file, and/or Load I/O devices
from a previously saved (or edited) text file (including all pin connections, and clickable settings, and any typed-
in edit-box values)

Note that as of version 1.6, the values in the period, delay, and pulse-width Edit boxes in the relevant IO
devices can be suffixed with the letter 'S' (or 's') to indicate that they should be “Scaled” according to the
position of a global I/O Values-Scaler slider that appears on the Main window's toolbar. With that slider fully to
the right, the scale factor is 1.0 (unity), and with the slider fully to the left the scale factor is 0 (subject to minimum
values enforced by each particular I/O device). You can scale more than one edit box value simultaneously using this
slider. This feature allows you to drag the slider while Running to easily emulate changing pulse widths, periods and
delays for those attached I/O devices.

The remainder of this section provides descriptions for each type of device.
Serial Monitor (SERIAL)

This I/O device allows for ATmega hardware-mediated Serial input and output (through the Uno's USB chip) on Uno
pins 0 and 1. The baud rate is set using the drop-down list at its bottom -- the selected baud rate must match the
value your program passes to the Serial.begin( ) function for proper transmission/reception. The serial
communication is fixed at 8 data bits, 1 stop bit, and no parity bit.

To send keyboard input to your program, type one or more characters in the upper (TX chars)
edit window and then hit Enter. (characters become italicized to indicate transmissions have
begun) – or if already in progress, added typed characters will be in italics. You can then use
the Serial.available( ) and Serial.read( ) functions to read the characters in the
order in which they were received into the pin 0 buffer (the leftmost typed character will be sent
first). Formatted textual and numeric printouts, or unformatted byte values, can be sent to the
lower console output (RX chars) window by calling the Arduino print( ), println( ), or
write( ) functions.

Additionally, a larger window for setting/viewing TX and RX characters can be opened by double-clicking (or
right-clicking) on this Serial device. This new window has a larger TX chars edit box, and a separate "Send" button
which may be clicked to send the TX characters to the Uno (on pin 0). There is also a check-box option to re-interpret
backslash-escaped character sequences such as \n or \t for non-raw display

Software Serial (SFTSER)

This I/O device allows for library software-mediated, or ,alternatively, user "bit-banged", serial input and output on any
pair of Uno pins you choose to fill in (except for pins 0 and 1 which are dedicated to hardware Serial communication).
Your program must have an #include <SoftwareSerial.h> line near the top if you wish to use that library's
functionality. As with the hardware-based SERIAL device, the baud rate for SFTSER is set using the drop-down list at
its bottom -- the selected baud rate must match the value your program passes to the .begin( ) function for proper
transmission/reception. The serial communication is fixed at 8 data bits, 1 stop bit, and no parity bit.

Also, as with the hardware based Serial, a larger window for TX and RX setting/viewing
can be opened by double-clicking (or right-clicking) on the SFTSER device.

Note that unlike Serial's hardware implementation, there are no provided TX or RX buffers
supported by internal ATmega interrupt operations, so that read( )'s and write( )'s are
blocking (that is, your program will not proceed until they are completed).

SD Disk Drive(SD_DRV)

This I/O device allows for library software-mediated (but not "bit-banged") file input and output operations on the Uno
SPI pins (you can choose which CS* pin you will use). Your program can simply #include <SD.h> line near the
top, and you can use <SD.h> functions OR directly call SdFile functions yourself.

A larger window displaying directories and files (and content) can be opened by double-
clicking (or right-clicking) on the SD_DRV device. All drive content is loaded from an SD
sub-directory in the loaded program's directory (if it exists) at SdVolume init(), and is
mirrored to that same SD sub-directory on file close(), remove(), and on makeDir() and
rmDir().
A yellow LED flashes during SPI transfers, and DATA shows the last SD_DRV response byte.
All SPI signals are accurate and can be viewed in a WavePane.
Shift Register Slave (SRSLV)

This I/O device emulates a simple shift-register device with an active-low SS* ("slave-select") pin controlling the drive
on its Dout output pin (when SS* is high, Dout is not driven). Your program could use the functionality of the built-in
SPI Arduino object and library. Alternatively, you may choose to create your own bit-banged data and clock signals to
drive this device.

The device senses edge transitions on its CLK input which trigger shifting of its register – the
polarity of sensed CLK edge may be chosen using a radio-button control. On every CLK edge
(of the sensed polarity), the register captures its Din level into the least-significant-bit (LSB)
position of the shift register, as the remaining bits are simultaneously shifted left one position
toward the MSB position. Whenever SS is low, the current value in the MSB position of the shift
register is driven onto Dout.

Configurable SPI Slave (SPISLV)

This I/O device emulates a mode-selectable SPI slave with an active-low SS* ("slave-select") pin controlling the drive
on its MISO output pin (when SS* is high, MISO is not driven). Your program must have an #include <SPI.h> line
if you wish to use the functionality of the built-in SPI Arduino object and library. Alternatively, you may choose to create
your own bit-banged data and clock signals to drive this device.

The device senses edge transitions on its CLK input according to the selected mode (MODE0,
MODE1, MODE2, or MODE3), which must be chosen to match the programmed SPI mode of
your program.

By double-clicking (or right-clicking) on the device you can open a larger companion
window that instead allows you to fill in 32-byte-maximum buffer (so as to emulate SPI devices
which auto-return data), and to see the last 32 received bytes (all as hex pairs).

Two-Wire I2C Slave (I2CSLV)

This I/O device emulates a slave-mode-only Two-Wire device. The device may be assigned an I2C bus address using
a two-hex-digit entry in its Addr edit box (it will only respond to I2C bus transactions involving its assigned address).
The device sends and receives data on its open-drain (pulldown-only) SDA pin, and responds to the bus clock signal
on its open-drain (pulldown- only) SCL pin. Although the Uno will be the bus master responsible to generating the SCL
signal, this slave device will also pull SCL low during its low phase in order to extend (if it needs to) the bus low time to
one appropriate to its internal speed (which can be set in its Clock edit box).

Your program must have an #include <Wire.h> line if you wish to use the functionality of
the TwoWire library to interact with this device. Alternatively, you may choose to create your
own bit-banged data and clock signals to drive this slave device.

A single byte for transmission back to the Uno master can be set into the Send edit box, and a
single (most-recently-received) byte can be viewed in its (read-only) Recv edit box.

By double-clicking (or right-clicking) on the device you can open a larger companion window that instead
allows you to fill in a 32-byte-maximum FIFO buffer (so as to emulate TWI devices with such functionality), and to view
(up to a maximum of 32) bytes of the most recently received data (as a two-hex-digit display of 8 bytes per line). The
number of lines in these two edit boxes corresponds to the chosen TWI buffer size (which can be selected using the
Config->Preferences menu dialog). This has been added as an option since the Arduino Wire.h library uses five
such RAM buffers in its implementation code, which is RAM memory expensive. By editing the Arduino installation
Wire.h file to change defined constant BUFFER_LENGTH (and also editing the companion utility/twi.h file to
change TWI_BUFFERLENGTH ) both to be instead either 16 or 8, a user could significantly reduce the RAM memory
overhead of the Uno in a targeted hardware implementation --. UnoArduSim therefore mirrors this real-world
possibility through a Preferences menu option.

Stepper Motor (STEPR)

This I/O device emulates a 6V bipolar or unipolar Stepper motor with an integrated driver controller driven by either
two (on P1,P2) or four (on P1,P2,P3,P4) control signals. The number of steps per revolution can also be set. You can
use the Stepper.h functions setSpeed()and step() to drive the Stepper. Alternatively, STEPR will also
respond to your own digitalWrite( )-created bit-banged drive signals.

The motor is accurately modelled both mechanically and electrically. Motor-driver voltage
drops and varying reluctance and inductance are modeled along with a realistic moment of
inertia with respect to holding torque. The motor rotor winding has a modeled resistance of
R=6 ohms, and an inductance of L=6 milli-Henries which creates an electrical time constant of
1.0 millisecond. Because of the realistic modeling you will notice that very narrow control pin
pulses do not get the motor to step – both due to the finite current rise time, and the effect of
rotor inertia. This agrees with what is observed when driving a real stepper-motor from an Uno
with, of course, an appropriate (and required) motor driver chip in between the motor wires
and the Uno!.

An unfortunate bug in the Arduino Stepper.h library code means that at reset the Stepper motor will not be in Step
position 1 (of four steps). To overcome this, the user should use digitalWrite() in his/her setup() routine to
initialize the control pin levels to the step-1 levels appropriate to 2-pin (0,1) or 4-pin (1,0,1,0) control, and allow the
motor 10 msecs to move to the 12-o'clock reference initial desired motor position.

DC Motor (MOTOR)

This I/O device emulates a 6-volt-supply 100:1 geared DC motor with an integrated driver controller driven by a pulse-
width-modulation signal (on its Pwm input), and a direction control signal (on its Dir input). The motor also has a wheel
encoder output which drives its Enc output pin. You can use analogWrite( ) to drive the Pwm pin with a 490 Hz
(on pins 3,9,10,11) or 980 Hz (on pins 5,6) PWM waveform of duty cycle between 0.0 and 1.0 (analogWrite values 0
to 255). Alternatively, DCMOTOR will also respond to your own digitalWrite( )-created bit-banged drive signals.

The motor is accurately modeled both mechanically and electrically. Accounting for motor-
driver transistor voltage drops and realistic no-load gear torque gives a full speed of
approximately 2 revs per second, and stall torque of just over 5 kg-cm (occurring at a steady
PWM duty cycle of 1.0), with a total motor-plus-load moment of inertia of 2.5 kg-cm. The motor
rotor winding has a modeled resistance of R=2 ohms, and an inductance of L=300 micro-
Henries which creates an electrical time constant of 150 microseconds. Because of the
realistic modeling you will notice that very narrow PWM pulses do not get the motor to turn –
both due to the finite current rise time, and the significant off-time after each narrow pulse.
These combine to cause insufficient rotor momentum to overcome the gearbox's spring-like
lashback under static-friction. The consequence is when using analogWrite( ), a duty cycle below about 0.125 will
not cause the motor to budge – this agrees with what is observed when driving a real gear-motor from an Uno with, of
course, an appropriate (and required) motor driver module in between the motor and the Uno!.

The emulated motor encoder is a shaft-mounted optical-interruption sensor that produces a 50% duty cycle waveform
having 8 complete high-low periods per wheel revolution (so your program can sense wheel rotational changes to a
resolution of 22.5 degrees).
Servo Motor (SERVO)

This I/O device emulates a position-controlled PWM-driven 6-volt-supply DC servo motor. Mechanical and electrical
modeling parameters for servo operation will closely match those of a standard HS-422 servo. The servo has a
maximum rotational speed of approximately 60 degrees in 180 msecs.

Your program must have an #include <Servo.h> line before declaring your Servo
instance(s) if you choose to use the Servo library functionality , e.g. Servo.write( ),
Servo.writeMicroseconds( ) Alternatively, SERVO also responds to
digitalWrite( ) bit-banged signals. Due to UnoArduSim's internal implementation, you
are limited to 5 SERVO devices.

Digital Pulser (PULSER)

This I/O device emulates a simple digital pulse waveform generator which produces a periodic signal that can be
applied to any chosen Uno pin.

The period and pulse widths (in microseconds) can be set using edit boxes—the minimum
allowed period is 50 microseconds, and the minimum pulse width is 10 microseconds. The
polarity can also be chosen: either positive-leading-edge pulses (0 to 5V) or negative-leading-
edge pulses (5V to 0V).

Pulse and Period values are scalable from the main toolbar I/O Values Scaler slider control by
suffixing either one (or both) with the letter 'S” (or 's').

One-Shot (1SHOT)

This I/O device emulates a digital one-shot that can generate a pulse of chosen polarity and pulse-width on its Out pin,
occurring after a specified delay from a triggering edge received on its Trg (trigger) input pin. Once the specified
triggering edge is received, timing begins and then a new trigger pulse will not be recognized until the Out pulse has
been produced (and has completely finished).

One possible use of this device is to simulate ultrasound ranging sensors that generate a
range pulse in response to a triggering pulse. It can also be used wherever you wish to
generate a pin input signal synchronized (after your chosen delay) to a pin output signal created
by your program.

Pulse and Delay values are scalable from the main toolbar I/O Values Scaler slider control by
suffixing either one (or both) with the letter 'S” (or 's').

Analog Function Generator (FUNCGEN)

This I/O device emulates a simple analog waveform generator which produces a periodic signal that can be applied to
any chosen Uno pin.

The period (in microseconds) can be set using the edit box—the minimum allowed period is 100
microseconds. The waveform it creates can be chosen to be sinusoidal, triangular, or sawtooth
(to create a square wave, use a PULSER instead). At smaller periods, fewer samples per cycle
are used to model the produced waveform (only 4 samples per cycle at period=100 usecs).

The Period value is scalable from the main toolbar I/O Values Scaler slider control by suffixing it
with the letter 'S” (or 's').
Piezoelectric Speaker (PIEZO)

This device allows you to "listen" to signals on any chosen Uno pin, and can be a useful adjunct to
LED's for debugging your program's operation. You can also have a bit of fun playing ringtones by
appropriately tone( ) and delay( ) calls (although there is no filtering of the rectangular
waveform, so you will not hear "pure" notes) .

You can also listen to a connected PULSER or FUNCGEN device by hooking a PIEZO to the pin that device drives.

Push Button (PUSH)

This I/O device emulates a normally-open momentary OR latching single-pole-single-throw (SPST)

push-button with a 10 k-ohm pull-up (or pull-down) resistor. If a rising-edge transition selection is
chosen for the device, the pushbutton contacts will be wired between the device pin and +5V, with a
10 k-Ohm pull-down to ground. If a falling-edge transition is chosen for the device, the pushbutton
contacts will be wired between the device pin and ground, with a 10 k-Ohm pull-up to +5V.

By left-clicking on the button, you close the push-button contact. In momentary mode it stays closed
for as long as you hold down the mouse button, and in latch mode (enabled by clicking on the latch
button) it stays closed (and a different colour) until you click the button again.

Slide Switch Resistor (R=1K)

This device allows the user to connect to an Uno pin either a 1 k-Ohm pull-up resistor to +5V, or a 1
k-Ohm pull-down resistor to ground. This lets you simulate electrical loads added to a real hardware
device. By left-clicking on the slide switch's body you can toggle your desired pull-up or pull-down
selection. Using one, or several, of these devices would allow you to set a single (or multi)-bit "code"
for your program to read and respond to.

Coloured LED (LED)

You can connect an LED between the chosen Uno pin (through a built-in hidden series 1 k-Ohm
current-limiting resistor) to either ground or to +5V -- this gives you the choice of having the LED light
up when the connected Uno pin is HIGH, or instead, when it is LOW.

The LED colour can be chosen to be either red (R), yellow (Y), green (G) or blue (B) using its edit
box.

Analog Slider

A slider-controlled 0-5V potentiometer can be connected to any chosen Uno pin to produce a static
(or slowly changing) analog voltage level which would be read by analogRead( ) as a value
from 0 to 1023. Use the mouse to drag, or click to jump, the analog slider.
Menus

File menu commands:

Load INO or PDE Prog (ctrl-L) Allows the user to choose a program file having the selected
extension. The program is immediately parsed

Edit/View (ctrl-E) Opens the loaded program for viewing/editing.

Save Save the edited program contents back to the original program file.

Save As Save the edited program contents under a different file name.

Next (#include) file Advances the CodePane to display the next #include'd file

Previous Returns the CodePane display to the previous file

Exit Exits UnoArduSim after reminding user to save any modified

file(s).

Find menu commands:

Find Next Function/Var Jump to the next Function in the Code Pane (if it has the active
focus), or to the next variable in the Variables Pane (if instead it has
the active focus).

Find Previous Function/Var Jump to the previous Function in the Code Pane (if it has the active
focus), or to the previous variable in the Variables Pane (if instead it
has the active focus).

Set Search Text (ctrl-F) Activate the toolbar's Find edit box to define your next-to-be-
searched-for text (and adds first word from the currently highlighted
line in the Code pane or Variables pane if one of those has focus).

Find Next Text Jump to the next Text occurrence in the Code Pane (if it has the
active focus), or to the next Text occurrence in the Variables Pane (if
instead it has the active focus).

Find Previous Text Jump to the previous Text occurence in the Code Pane (if it has the
active focus), or to the previous Text occurrence in the Variables
Pane (if instead it has the active focus).
Execute menu commands:

Step Into (F4) Steps execution forward by one instruction, or into a called
function.

Step Over (F5) Steps execution forward by one instruction, or by one

complete function call.

Step Out Of (F6) Advances execution by just enough to leave the current
function.

Run To (F7) Runs the program, halting at the desired program line -- you
must first click to highlight a desired program line before
using Run To.

Run Till (F8) Runs the program until a write occurs to the variable that had
the current highlight in the Variables Pane (click on one to
establish the initial highlight).

Run (F9) Runs the program.

Halt (F10) Halts program execution (and freezes time).

Reset Resets the program (all value-variables are reset to value 0,

and all pointer variables are reset to 0x0000).

Animate Automatically steps consecutive program lines with added

artificial delay and highlighting of the current code line. Real-
time operation and sounds are lost.

Slow Motion Slows time by a factor of 10.

Options menu commands:

Step Over Structors/Operators Fly right through constructors, destructors, and operator
overload functions during any stepping (i.e. it will not stop
inside these functions).

Register-Allocation Modelling Assign function locals to free ATmega registers instead of to

the stack (generates somewhat-reduced RAM usage).

Error on Uninitialized Flag as a Parse error anywhere your program attempts to

use a variable without having first initialized its value (or at
least one value inside an array).

Added loop() Delay Adds 200 microseconds of delay every time loop() is
called (in case there are no other program delay()'s
anywhere) – useful to try avoiding falling too far behind real-
time.
Configure menu commands:

I/O Devices Opens a dialog to allow the user to choose the type(s), and numbers, of
desired I/O devices. From this dialog you can also Save I/O devices to a text
file, and/or Load I/O devices from a previously saved (or edited) text file
(including all pin cpnnections and clickable settings and typed-in values

Preferences Opens a dialog to allow the user to set preferences including auto-indent-
formatting of source program, allowing Expert syntax, choice of font typeface,
opting for a larger font size, enforcing of array bounds, permitting of logical
operator keywords, showing program download, choice of Uno board version,
and TWI buffer length (for I2C devices).

VarUpdates menu commands:

Allow Auto (-) Collapse Allow UnoArduSIm to collapse displayed expanded arrays/structs/objects
when falling behind real-time.

Allow Reduction Allow reduced frequency of display updates in the Variables Pane to avoid
flicker or reduce CPU load when falling behind real-time– then values shown
are only updated periodically, but also whenever the program is halted.

Minimal Updates Only refresh the variables Pane display 4 times per second.

HighLight Updates Highlight the last-changed variable value (can cause slowdown).

Windows menu commands:

Serial Monitor Connect a Serial IO device to pins 0 and 1 (if none) and pull up a larger Serial
monitor TX/RX text window.

Restore All Restore all minimized child windows.

Prompt Left-Click or Right-Click an Uno Pin to create a Waveform window:

Pin Digital Waveforms Restore a minimized Pin Digital Waveforms window.

Pin Analog Waveform Restore a minimized Pin Analog Waveform window.

Help menu commands:

Quick Help File Opens the UnoArduSim_QuickHelp PDF file.

Full Help File Opens the UnoArduSim_FullHelp PDF file.

Bug Fixes View significant bug fixes since the previous release..

Change/Improvements View significant changes and improvements since the previous release.

About Displays version, copyright.

Modelling

Intro

The Uno and attached I/O devices are all modelled electrically, and you will be able to get a good idea at home of how
your programs will behave with the actual hardware.
.
Timing

UnoArduSim executes rapidly enough on a PC or tablet that it can (in the majority of cases) model program actions in
real-time, but only if your program incorporates at least some small delay() calls or other calls that will naturally
keep it sync'd to real time (see below).

To accomplish this, UnoArduSim makes use of a Windows callback timer function, which allows it to keep accurate
track of real-time. The execution of a number of program instructions is simulated during one timer slice, and
instructions that require longer execution (like calls to delay( ) ) may need to use multiple timer slices. Each iteration
of the callback timer function corrects system time using the system hardware clock so that program execution is
constantly adjusted to keep in lock-step with real-time. The only times execution rate must fall behind real-time is
when the user has created tight loops with no added delay, or I/O devices are configured for operation with very-high
I/O device frequencies (and/or baud rate) which would generate an excessive number of pin-level-change events and
associated processing overload. UnoArduSim copes with this overload by skipping some timer intervals to
compensate, and this then slows down program progression to below real-time.

In addition, programs with large arrays being displayed, or again having tight loops with no added delay can cause a
high function call frequency and generate a high Variables Pane display update load causing it to fall behind real-time–
this can be circumvented by allowing update reductions in the VarUpdates menu, or by selecting Minimal Updates
there when necessary.

Accurately modelling the sub-millisecond execution time for each program instruction or operation is not done – only
very rough estimates for most have been adopted for simulation purposes. However, the timing of delay( ), and
delayMicroseconds( ) functions, and functions millis( ) and micros( ) are all perfectly accurate, and as
long as you use at least one of the delay functions in a loop somewhere in your program, or you use a function
that naturally ties itself to real-time operation (like print( ) which is tied to the chosen baud rate), then your
program's simulated performance will be very close to real-time (again, barring blatantly excessive high-frequency pin-
level-change events or excessive user-allowed Variables updates which could slow it down).

In order to see the effect of individual program instructions when running, it may be desirable to be able to slow things
down. A time-slowdown factor of 10 can be set by the user under the Execute menu.

I/O Devices

These virtual devices receive real-time signaling of changes that occur on their input pins, and produce corresponding
outputs on their output pins which can then be sensed by the Uno -- they are therefore inherently synchronized to
program execution. Internal I/O device timing is set by the user (for example through baud rate selection or Clock
frequency), and simulator events are set up to track real-time internal operation.

Sounds

Each PIEZO device produces sound corresponding to the electrical level changes occurring on the attached pin,
regardless of the source of such changes. To keep the sounds synchronized to program execution, UnoArduSim starts
and stops playback of an associated sound buffer as execution is started/halted, and when falling behind real-time
(and when catching back up). Note that each stop and restart of the sound playback causes an unavoidable
audible click , even though the Piezo's pin level has not actually changed. Multiple PIEZO's are accommodated,
and the DirectSoundTM API is used to look after all sound mixing. Minor sound glitches can occur due to variable
response delays intrinsic to the WindowsTM operating system.
Limitations and Unsupported Elements

Included Files

Bracketed-file #include's <Servo.h>, <Wire.h>, <SoftwareSerial.h>, <SPI.h> <EEPROM.h> and <SD.h>

are supported but are only emulated --the actual files are not searched for; instead their functionality is directly "built
into" UnoArduSim, and are valid for the fixed supported Arduino version.

Any quoted-file #include's (like "supp.ino" , "myutil.cpp", or "mylib.h") are supported but all such files
must reside in the same directory as the parent program file that #include's them (there is no searching done
into other directories). The "#include" feature can be useful for minimizing the amount of program code shown in the
Code Pane at any one time. Header files which are #include'd (i.e. those having a ".h" extension) will additionally
cause the simulator to attempt including the same-named file having a ".cpp" extension (if it also exists in the parent
program's directory).

Dynamic Memory allocations and RAM

Operators 'new' and 'delete' are supported, as are native Arduino String objects, but not direct calls to
malloc( ) , realloc( ) and free( ) that these rely on.

Excessive RAM use for variable declarations is flagged at parse time, and RAM memory overflow is flagged during
program execution. An option allows you to emulate the normal ATmega register allocation as would be done by the
AVR compiler, or to model an alternate compilation scheme that uses the stack only (as a safety option in case a bug
pops up in my register allocation modelling). If you were to use a pointer to look at stack contents, it should accurately
reflect what would appear in an actual hardware implementation.

Flash Memory Allocations

Flash memory 'byte', 'int' and 'float' variables/arrays and their corresponding read-access functions are
supported. As for String's, F() Flash-macro'd String's are supported, but the only supported flash-memory String
direct-access functions are strcpy_P( ) and memcpy_P( ), so to use other functions you will need to first copy
the Flash String to a normal RAM String, and then work with that RAM String. When you use the PROGMEM
variable-modifier keyword, it must appear in front of the variable name, and that variable must also be declared as
'const'.

Strings

The native String library is almost completely supported with a few very (and minor) exceptions .

The String operators supported are +, +=, <, <=, >, >= , == , != , and []. Note that: concat( ) takes a
single argument which is the String, or char, or int to be appended to the original String object, not two
arguments as is mistakenly stated on the Arduino Reference web pages).

Arudino Libraries

Only Stepper.h, SD.h, Servo.h, SoftwareSerial.h, SPI.h, Wire.h, and EEPROM.h for the Arduino V1.6.6
release currently are supported in UnoArduSim . Trying to #include the .cpp and .h files of other as-yet
unsupported libraries will not work as they will contain low-level assembly instructions and unsupported directives
and unrecognized files!
Pointers

Pointers to simple types, arrays, or objects are all supported. A pointer may be equated to an array of the same type
(e.g. iptr = intarray), but then there would be no subsequent arrays bounds checking on an expression like
iptr[index].

Functions can return pointers, or 'const' pointers, but any subsequent level of 'const' on the returned pointer is
ignored.

There is no support for function calls being made through user-declared function-pointers.

Classes and Structs

Although polymorphism, and inheritance (to any depth), is supported, classes and structs can only be defined to have
at most one base class (i.e. multiple- inheritance is not supported). Base-class constructor initialization calls (via
colon notation) in constructor declaration lines are supported, but not member-initializations using that same colon
notation. This means that objects that contain non-static 'const' or reference-type variables are not supported (those
are only possible with specified construction-time member-initializations)

Copy-assignment operator overloads are supported along with move-constructors and move-assignments, but user-
defined object-'conversion' ("cast-like") functions are not supported.

Scope

There is no support for the 'using' keyword, or for namespaces, or for 'file' scope. All non-local declarations are by
implementation assumed to be global.

All typedef's, and all named struct's and class'es (i.e. that may be used for future declarations), must be declared
at global scope (local declarations of such items inside a function are not supported).

Unsigned Const, Volatile, Static

The 'unsigned' prefix works in all the normal legal contexts. The 'const' ke'yword, when used, must precede the
variable name or function name or typedef name that is being declared -- placing it after the name will cause a Parse
error. For function declarations, only pointer-returning functions can have 'const' appear in their declaration.

All UnoArduSim variables are 'volatile' by implementation, so the 'volatile' keyword is simply ignored in all
variable declarations. Functions are not allowed to be declared 'volatile', nor are function-call arguments.

The 'static' keyword is allowed for normal variables, and for object members and member-functions, but is explicitly
disallowed for object instances themselves (classes/structs), for non-member functions, and for all function arguments.'

Compiler Directives

#include's and regular #define's and are supported, but not macro #defines. The #pragma directive and
conditional inclusion directives (#ifdef, #ifndef, #if, #endif, #else and #elif) are also not supported.
The #line, #error and predefined macros (like _LINE_, _FILE_, _DATE_, _TIME_) are also not supported.

Arduino-language elements

All native Arduino language elements are supported with the exception of the dubious "goto" instruction (the only
reasonable use for it I can think of would be as a jump (to a bail-out and safe shutdown endless-loop) in the event of
an error condition that your program cannot otherwise deal with)
C/C++-language elements

Bit-saving "bit-field qualifiers" for members in structure definitions are not supported.

Union's are not supported.

The oddball "comma operator" is not supported (so you cannot perform several expressions separated by commas
when only a single expression is normally expected, for example in while( ) and for( ; ; ) constructs).

Function Templates

User-defined functions that use the keyword "template" to allow it to accept arguments of "generic" type are not
supported.

Real-Time Emulation

As noted above, execution times of the many different individual possible Arduino program instructions are not
modelled accurately, so that in order to run at a real-time rate your program will need some sort of dominating delay(
) instruction (at least once per loop( ) ), or an instruction that is naturally synchronized to real-time pin-level
changes (such as, pulseIn( ), shiftIn( ), Serial.read( ), Serial.print( ), Serial.flush( ) etc.)

See Modelling and Sounds above for more detail on limitations.

Release Notes

Bug Fixes

V1.7.2– Feb. 2017

1) Interrupts on pin 2 were also being (inadvertently) triggered by signal activity on pin 3 (and vice-versa).
V1.7.1– Feb. 2017
1) Function delayMicroseconds( ) was producing a delay in milli-seconds.(1000 times too large)
2) Explicit casting of an unsigned variable to a longer integer type yielded an incorrect (signed) result.
3) Hex literals greater than 0x7FFF are now 'long' by definition, and so so will now generate long resulting
arithmetic expressions in which they become involved.
4) A bug inadvertently introduced by V1.7.0 prevented alternate C++-style casting of numeric literals (for example,
'(long)1000*3000' was not accepted)
5) Serial no longer takes up its many bytes in Uno RAM if it is never needed by the user program.
6) User-declared global variables no longer take up space in Uno RAM if they are never actually used.
7) Single variables declared as 'const', 'enum' members, and pointers to string literals no longer take up space in
Uno RAM (to agree with Arduino compilation),
8) RAM bytes required for #include'd builtin libraries now closely match Arduino's conditional-compilation results.
9) Using 'new' on a pointer's actual declaration line had failed (only a later 'new' assignment to the pointer worked).
10) Fixed a bug where a “pending” show of an SD disk directory could cause a program hang.

V1.7.0– Dec. 2016

0) A number of problems with the handling of user interrupts have now been fixed:
a) Interrupts 0 and 1 edges that occurred during an Arduino function that blocks while waiting (like
pulseIn(), shiftIn(), spiTransfer(), flush(), and write()) had caused a fault in execution flow
at interrupt return

b) Multiple copies of the local variables of any interrupted function had been appearing in the Variables Pane
(one copy per interrupt-return) and this was fixed in V1.6.3, but the other interrupt issues remained).

c) Function delayMicroseconds() was not creating any delay if called from inside a user interrupt routine.

d) Calls to blocking functions like pulseIn() from inside an interrupt routine had not been working.

1) A bug introduced in V1.6.3 caused loss of value-updating in the Variables Pane while Running when values actually
were changing (this happened only after two or more Halt or VarUpdates-menu user actions). In addition, when a
RunTo was done after 'Reduced-Updates' had been triggered, the Variables Pane occasionally did not redraw (so old
values/local-variables may have appeared there until the next Step).

2) The CodePane-highlighting behaviour of the StepOver command could appear misleading in if()-else chains –
that has now been fixed (although the actual stepping functionality was correct).

3) Function pulseIn() had improperly set the timeout in milliseconds instead of microseconds -- it also was
improperly re-starting the timeout when the transitions to inactive and active levels were first seen.

4) Using HEX literals between 0x8000 and 0xFFFF in assignments or arithmetic with 'long' integer variables gave
incorrect results due to un-checked sign-extension.

5) Passing, or returning, to a 'float' from any 'unsigned' integer type having a value with MSB=1 gave incorrect results
due to a faulty SIGNED interpretation.
6) bit_( ) functions now also accept operations on long-sized variables, and UnoArduSIm tests for invalid bit positions
(that would fall outside the variable's size).

7) An invalid input to the Pulse (width) edit box on a PULSER I/O Device caused corruption of the Period value (until
fixed by the next user Period edit entry).

8) Deleting a PULSER or FUNCGEN I/O device using the Configure menu was not removing its periodic signal from
the pin that it had been driving (a Reset is no longer required).

9) The ability to initialize a 1-D char array with a quoted string was missing, (e.g. char strg[] = “hello”; ) .

10) Hex display in the expanded Serial or SoftSerial Monitor windows showed the incorrect most-significant-character
for byte values greater than 127.

11) The Waveform windows were not reflecting user programmatic changes made by analogWrite() when the a
new value was either 0% or 100% duty-cycle.

12) The implementation of Serial.end() has now been fixed.

13) A myUnoPrefs.txt file with more than 3 words on one line (or spaces in the IODevs file name) could cause a crash
due to a faulty internal pointer.

14) The final line of an I/O Devices file was not accepted if it did not end with a line-feed.

15) Adding more than four Analog Sliders caused a silent bug that overwrote LED I/O device pointers

16) Starting with V1.6.0, analog waveform samples for the first half of each triangle waveform were all zero (due to a
bug in the waveform-table computation).

17) Doing a repeated RunTo when on a breakpoint line no longer requires multiple clicks per advance.

18) Passing address expressions to a function array parameter was not accepted by the Parser.

19) Recursive functions that returned expressions containing pointer or array de-references gave incorrect results due
to un-reset ”ready” flags on those component expressions.

20) Calling class member-functions through any object pointer variable or pointer expression was not working.

21) User functions that returned objects by-value only successfully returned their value on their very first function call
IF they returned a nameless constructed object (like 'String("dog")' -- on subsequent calls the return was skipped due
to a stuck ”ready” flag.

22) There had been no safeguard to prevent the View->USB Serial menu command from adding a new Serial device
when there was actually no room for it.

23) If adding a fixed-pin device (like SPISLV) caused a pin conflict popup message, the PlayField redraw could show a
duplicate “ghost” device overlaying the rightmost I/O device (until the next redraw).

24) Fixed some issues with unreliable Piezo sounds for non-periodic pin signals.

25) PROGMEM variables must also now be explicitly declared as 'const' to agree with Arduino.

26) "No heap space" was incorrectly flagged as an execution error when an SD.open() could not find the named file,
or an openNextFile() reached the last file in the directory.

27) A Parser bug had been improperly accepting an out-of-place close-brace '}'.

28) A bug with Variables Pane removals upon member-object-constructor return has been fixed (the bug applied only
for objects that themselves contain other objects as members).
V1.6.3– Sept. 2016
1) The local variables of any interrupted function were not getting removed from the Variables Pane on interrupt
function entry, leading to multiple copies appearing there on interrupt-function return (and a possible eventual
execution error or a crash).

2) The Waveform windows were not reflecting programmatic changes in analogWrite() to a new duty cycle of
either 0% or 100% .

3) Hex display in the expanded Serial or SoftSerial Monitor window showed the incorrect MSB character for byte
values greater than 127.

V1.6.2– Sept. 2016

1) Function calls made with the wrong number or type of arguments had not generated an appropriate Parse error
message (only the generic “not a valid identifier” message appeared).

2) The toolbar reset button now works identically to the Uno board's reset button.

3) Parse-error text no longer cuts off after 16 characters without showing an ellipsis.

V1.6.1– Aug. 2016

1) In V1.6 an Uno board version in the myArduPrefs.txt file that differed from the default version 2 value caused an
exception at startup (due to an uninitialized pin 13 event).

2) Changing the value of a variable by double-clicking in the Variables Pane could cause faulty "no memory
allocation" error popups (for programs with user-defined classes).

3) SoftwareSerial did not allow access to write(char* ptr) and write(byte* ptr, int size)
functions because of a faulty function-overload detection.

4) Fixed issue with automatic inclusion of the corresponding .cpp file for an isolated .h "library-type" #include.

V1.6– June 2016

1) In V1.5 Edit/View's auto-TAB-indent-on-Enter (when entering a new line) feature had been lost.
2) Detection of pin conflicts with attached high-drive external IO devices has now been added on Serial pin 1, on SPI
pins SS, MOSI, and SCK, on I2C pins SCL and SDA (all when the corresponding begin() is called), and on any
declared SoftwareSerial txpin.

V1.5.1– June 2016

1) In V1.5 the new theme-adaptable Syntax Highlight colours were not properly reset each time Edit/View was
opened, and so (with a white-background theme) were only correct every second time.

2) Interrupt RISING and FALLING sensitivities had been opposite to the actual triggering edge polarity.

V1.5 – May 2016

1) A bug introduced in V1.4.1 prevented passing bare string literals to String member functions that expected a
'String' object, as in 'mystring1.startsWith("Hey")'.

2) A bug in UnoArduSim's original SD implementation only allowed SD access using calls to read() and write()
(access via Stream or Print functions was prevented).

3) Slide switches were not being redrawn properly when the slider was moved.

4) 'Cancel' in the Confirm-Save file dialog should have prevented application exit.
5) A missing close-quote or close-bracket on a user-file #include would cause a hang.

6) Fixed a bug in syntax highlighting of 'String' and user classes/structs, and extended highlighting to include
constructor function calls.

7) Fixed minor issues in Edit/View with text changes/highlighting and the Undo button.

V1.4.3 – Apr. 2016

1) Using ConfigàIODevs to add new devices, and then to subsequently remove one of those newly added devices
could cause a crash at reset, or for another device to stop working.

2) Modifying a String variable bydouble-clicking in the Variables Pane failed (the new String was read improperly).

3) Pin changes on FuncGen and Pulser I/O devices were not recognized until a reset was first done.

V1.4.2 – Mar. 2016

1) V1.4.1 had INTRODUCED an unfortunate Parse bug which prevented assignments involving any class objects
(including String objects).
2) An incomplete bug fix made in V1.4.1 caused unsigned-char values to print as ASCII characters rather than as their
integer values.

3) Complex member-expression function call arguments were not always recognized as valid function-parameter
matches.

4) ALL integer literals and expressions were sized too generously (to 'long') and therefore execution did not reflect the
actual overflows (to negative) that can occur in Arduino on add/multiply operations involving 'int' sized values.

5) Expressions involving a mix of signed and unsigned integer types were not always handled properly (the
signed value would be improperly seen as unsigned).

6) In pin-conflict cases, 'value =' error messages could show stale pin values even after a Reset from a previous
conflict that the user had already cleared.

V1.4.1 – Jan. 2016

1) Calls to print(char) now print properly as ASCII characters (rather than numeric values).
2) Interrupt response is now enabled by default when attachInterrupt() is called, so there is no longer any need in
your setup() to call the enabling function interrupts().
3) Multiple #include’s of user-files from within one file are now handled properly.

V1.4 – Dec. 2015

1) A LONG-STANDING bug incorrectly flagged a DIVIDE-BY-ZERO condition when dividing by a fractional value less
than unity.

2) Fixed SoftwareSerial (which was inadvertently broken by an added class-member validation check in V1.3
releases).

3) End-of-line function calls with a missing semicolon were not caught, and caused the Parse to skip the next line.

4) A badly formatted IODevs text file gave an improper error message.

5) Parse Error highlighting of the incorrect (adjacent) line in multi-line expressions and statements has been fixed

6) Logical testing of pointers using the 'not' ( ! ) operator was inverted.

V1.3 – Oct. 2015
1) Improper internal handling of scratchpad variables caused occasional "maximum scratchpad nesting depth
exceeded" Parse errors.

2) Single-quoted brackets, braces. semicolons, brackets inside quoted strings, and escaped characters were
improperly handled.

3) An Array with an empty dimension and no initialization list caused a RESET hang, and arrays with only a single
element were not disallowed (and caused their faulty interpretation as an invalidly-initialized pointer).

4) Parse errors sometimes would sometimes highlight the wrong (adjacent) line.

5) Passing a pointer-to-a-non-const to a function accepting a pointer-to-a-const had been disallowed (instead of the
other way around)

6) Initializer expressions were improperly inheriting PROGMEM qualifiers from the being-initialized variable.

7) PROGMEM declared variables had their byte-size incorrectly counted TWICE against their Flash memory allocation
during Parse.

8) Typing into an I2CSlave 'Send' edit box would sometimes cause a crash due to sscanf bug.

9) Loading a new program having a new IODevs file in its directory could cause irrelevant pin conflicts with OLD pin
directions.

10)Escaped-Serial-character handling was improperly applied to received, rather than transmitted, character
sequences in the (larger) Serial Monitor buffers window.

11) while() and for() loops with completely empty bodies, such as "while(true);" or "for(int
k=1;k<=100;k++);" passed Parse (with a warning message) but failed at execution time..

V1.2 – Jun 2015

1) The very simplest of user functions that made calls to either digitalRead() or to analogRead() or bit()
could have corrupted their (very first) declared local variable (if any) due to insufficient allocated function scratchpad
space (if only two scratchpad bytes got allocated at the very start of the function's stack) . Any numeric expression
at all inside a function is sufficient to cause a 4-byte scratchpad allocation, and so avoids this issue. This
unfortunate bug has been around since the original release V1.0.
2) Void functions with an early explicit return, and non-void functions with more than one return statement, would
see execution fall-through at the closing brace (if it was reached).
3) Return statements in un-braced if( ) contexts led to a faulty return-to-caller target.

4) Pulser and FuncGen pulsewidths/periods of 0 could cause a crash (0 is now disallowed).

5) 'else' continuations after an if() did not work following unbraced 'break', 'continue', or 'return's.

6) When multiple user enum's were declared, only constants defined in the very first enum did not generate faulty
"enum mismatch" Parse errors (the bug got introduced in V1.1).
7) A null identifier for the very last parameter of a function prototype caused a Parse error.
8) Run-To breakpoints set on complex lines were not always handled properly (and so could be missed).
9) HardwareSerial and SoftwareSerial used a private implementation TXPending buffer that did not get
cleaned out on Reset's (so leftover characters from last time could appear).
10) Parse failed to check for illegal bit-flipping of float's, and pointer arithmetic attempted with illegal operators.
V1.1 – Mar 2015

1) Array indices that were byte or char sized variables caused incorrect array offsets (if an adjacent variable
contained a non-0 high-byte).

2) Logical testing of pointers tested the pointed-to value for non-zero rather than the pointer value itself.

3) Return statements embedded inside for() or while() loops were mishandled.

4) Aggregate-initialization lists for arrays of objects, or objects containing other objects/arrays, or completely empty
initialization lists, were not being handled properly.

5) Access of enum member values using an " enumname." prefix was not supported.

6) Declaration-line initialization of a char[ ] array with a quoted string literal was not working.

7) An array being passed to a function without prior initialization was improperly flagged with a "used but not initialized"
error.

8) Pointer expressions involving array names were mishandled.

9) Function parameters declared as const were not accepted.

10) The Pin Analog Waveform window did not display PWM signals (servo.write() and analogWrite()).

11) Member functions accessed through an object-pointer gave faulty member accesses.

12) Waveforms were not being updated when a RunTo breakpoint was reached.

13) Register allocation modelling could fail when a function parameter was hen used directly as an argument to
another function call

V1.0.2 – Aug 2014

Fixed ordering of A0-A5 pins on the perimeter of the Uno board .

V1.0.1 – June 2014

Fixed bug that truncated edit "paste"'s that were longer than three times the number of bytes in the original
program.

V1.0 -- first release May 2014

Changes/Improvements

V1.7.2– Feb. 2017

1) The colour choice blue (B) has been added for LED devices.

V1.7.1– Feb. 2017

1) Suffixes 'L' and/or 'U' are now accepted on the end of numeric literal constants (to define them as 'long' and/or
'unsigned'), and (0b-or 0B-prefixed) binary constants are now also accepted. Any all-decimal numeric constant
beginning with a '0' is now considered to be an octal value. (to agree with Arduino).
2) When executing in a tight loop from which there is no escape (for example 'while(x); x++;' where x is always
true), clicking Halt a second time now ensures program execution actually halts (and on that faulty program line).

V1.7.0– Dec. 2016

1) A new ToolBar feature has been added that shows free RAM bytes during program execution (accounting for the
total bytes used by global variables, heap allocations, and local stack variables).

2) User interrupt functions may now also themselves call blocking Arduino functions like pulseIn() (but this should
only be used with caution, since the interrupt function will not return until the the blocking function is complete).

3) User interrupts are no longer disabled during blocked Stream-read operations, so behaviour now matches actual
Arduino stream-read operation.

4) You can now step into and out of blocking Arduino functions that can be interrupted (like delay( ) and
pulseIn( )) , and Status-Bar messages have been augmented to show when you have hit an interrupt breakpoint
inside such a function (or when you click-Halt when execution is currently inside such a function).

5) A new RunTill Execute menu command (and toolbar item) has been added - single-click on any Variables Pane
variable (it can be simple, an aggregate array or object, or an array element or object-member) to highlight it, then do
RunTill -- execution will freeze at the next write-access inside that aggregate variable ,or to that single location.

6) When execution freezes after a Step, RunTo, RunTill, or Run-then-Halt action, the Variables Pane now highlights
the variable that corresponds to the address location(s) that got modified (if any) by the very last instruction
during that execution -- if that location is currently hidden inside an un-expanded array or object, clicking to expand it
will then cause that last-modified element or member to become highlighted.

7) The user can now keep a special watch on the value of a specific Variable Pane variable/member/element while
executing -- double-click on that line in the Variables Pane to open the Edit/Track Variable Value window, then do
one of the Run or Step commands -- the value shown will be updated during execution according to the same rules
that govern updates in the Variables Pane. After halting execution, .you are allowed to enter a new value and Adopt it
before resuming execution (and can Revert to the pre-Adopt value if you change your mind before then).

8) Accelerator keys F4-F10 have been set to match the Execute-menu toolbar commands (from left to right).

9) In addition to double-clicking on them, right-clicking on SERIAL, SOFTSER, SPISLV , I2CSLV I/O devices will now
also pop up a larger-sized TX/RX bytes/chars window (and on SD_DRV, a files-monitoring window).

10) The TX edit box in SERIAL or SOFTSER is no longer disabled during an active character transmission (so you can
now append-to or replace what is there), but a carriage-return (or Send button click in the associated SerialMonitor
child window) will be ignored until the transmission returns to the idle state once again (characters are now shown in
italics when transmission is ready to begin, ot is active). In addition, the user is now warned at a serial stream
begin() if they had already started earlier the attached device 's (now in-progress) transmissions , as there would
then be no framing synchronization, leading to reception errors.

11) The default added loop() delay has been increased from 250 microseconds to one millisecond so as not to fall
quite so far behind real-time when the user neglects to include some delay() (explicit or natural) somewhere inside
loop() or inside a function that it calls.

12) Arrays and simple types have now been added to the support for the heap-allocating 'new' instruction.

13) More extensive checks (and associated error messages) have been added for user program out-of-bounds
address accesses (i.e. outside of Uno RAM, or outside of Flash for PROGMEM accesses).

14) Pointer values in the Variables Pane now more closely resemble actual Arduino pointer values.

15) The user myArduPrefs.txt file is now loaded at every File->Load, not just at UnoArduSIm launch.

16) A Parse error is now flagged when trying to attachInterrupt( ) to a user function that is not void return, or
which has function parameters, or which has not been declared somewhere before attachInterrupt( ).

17) Static member-variables are now displayed at the top of the Variables Pane as globals, rather than appearing
inside each instance of an (expanded) object.

18) Function availableForWrite() has been added to the implementation of Serial.

19) All special PROGMEM typedef's like 'prog_char' and 'prog_int16' have now been removed (they have been
deprecated in Arduino).

20) Improved error messages for Parse errors caused by mis-spelled or invalid declaration types.

21) The maximum allowed program size has been increased.

V1.6.3– Sept 2016

1) Added an improved parse error message when attachInterrupt() refers to an interrupt-function that was
not prototyped earlier.

2) Added an improved Parse error message for multi-dimensional array initialization lists.

V1.6.2– Sept 2016

1) Added a Find-Text edit control to the toolbar to streamline searching for text (in the Code Pane and Variables
Pane)

2) The toolbar Reset button now works identically to the Uno board's Reset pushbutton.

V1.6.1– Aug 2016

Added a check to avoid duplicate loading and parsing of already previously-#include'd files,.

V1.6 – June 2016

1) Added a new OneShot I/O Device which generates a pulse after a chosen delay from a tigger signal edge of
selected polarity.

2) Added a new feature to make I/O device edit box values easily scalable during execution by dragging a global
I/O Values Scaler slider on the main toolbar (just type a single letter 's' or 'S' after a value to indicate scaling).

V1.5.1 – June 2016

1) Support has been now been added for EEPROM library functions update(), put() and get(), and for
byte access via array notation, e.g. EEPROM[k].

2) Allow Auto (-) Collapse has been added to the VarUpdates menu to allow explicit control over whether or
not expanded arrays/structs/objects will be auto-collapsed when execution is falling behind real-time.

3) A String variable's characters can now also be accessed via array notation, e.g. mystring[k].
V1.5 – May 2016
1) View/Edit now has shortcut ctrl-E, and has a new button for Compile (ctrl-R), plus a built-in Parse-error box, to
allow testing of edits without needing to close the window.

2) View/Edit now now also supports Redo's, and has a new Save (ctrl-S) button (equivalent to Adopt plus a later
main-window Save), and now gives a choice of TAB size (a new preference that can be saved using the
Configure->Preferences dialog).

3) All writable edit boxes now follow the chosen Windows OS theme colours, and for contrast all READ-only
RECV edit boxes use white text on black background. View/Edit's background and syntax-highlight colours
now also adapt to the chosen theme.

4) UnoArduSim now allows a choice of typeface -- that choice, and typeface sizing, have been moved to the
Preferences Dialog (so can be saved in the myArduPrefs.txt file).

5) Arduino pre-defined binary literal values (like B01011011) are now allowed.

6) Escaped hex, octal, and 4-digit Unicode quoted character sequences can now be used as numeric literals.

7) After making an initial mouse-click on a PushButton IO device's push-pad, the user can then instead use a
key-press (any key) to depress the Pushbutton's contacts.

8) View/Edit now releases its temporary initial read-only state (and removes the highlighting of the initial selected
line) after a brief visual flash cue.

9) UnoArduSim now checks for multiple Stepper and Servo pin conflicts, i.e. faulty user program attempts to
attach to pins already attached to earlier Stepper/Servo variables.

10) A Parse error caused by a missing left-hand or right-hand side to an operator (missing a LHS or RHS
expression or variable) now generates a clear error message.

11) The unused String class 'flags' member variable has been removed to agree with Arduino V1.6.6. A
String object now occupies 6 bytes (plus its characters' heap allocation).

V1.4.2 – Mar 2016

1) Forward-defined functions (i.e. those with no prototype declaration before their first call) now only generate
warnings (not parse errors) when the later function definition return-type mismatches the type inferred from
their first use.

2) Arrays having a dimension equal to 1 are no longer rejected (in order to agree with standard C++ rules)..

3) Edit boxes are no longer set to black on white background – they now adopt the palette set by the Windows
OS theme in use.

4) SERIAL, SOFTSER, SPISLV, and I2CSLV I/O device expanded Monitor windows (opened by double-clicking)
now adopt the background colour of their parent IO Device.

V1.4 – Dec 2015

1) Stepper.h library functionality and associated I/O devices have now been added..

2) All IO Device settings and values (in addition to its selected pins) are now also saved as part of the chosen
user IODevs text file for later reload.

3) LED I/O device colour can now be set as either red, yellow or green using an edit box on the device.

4) .Variable declaration initializers are now allowed to span multiple lines.

5) Array indices are now allowed to themselves be array elements.

 6) The ConfigàPreferences dialog now includes a checkbox to permit 'and','or','not' keywords to be used in
place of the C-standard &&, ||, and ! logical operators.

7) 'Show Program Download' has been moved to the ConfigàPreferences dialog

V1.3 – Oct 2015

1) PushButton's now have a push-like checkbox labeled "latch" to make them 'latching' (instead of 'momentary'),
that is, they will latch in the closed position (and change colour) when pressed until pressed again to release
them.

2) Full capability SPI Slave devices (SPISLV) have been added with node selection (MODE0, MODE1, MODE2,
or MODE3). Double-clicking opens a TX/RX buffers window where upcoming REPLY (TX) bytes may be
defined, and for viewing of past received (RX) bytes. The previous version's simple-shift-register slave device
has been renamed to become an 'SRSLV' device.

3) Bold typeface can now be chosen for the CodePane and Variables Pane (from the Options menu), and bold
highlighting of keywords and operators can now be toggled on/off in View/Edit.

4) UnoArduSim now allows bool as a synonym for boolean .

5) For clarity in error reporting, variable declarations are no longer allowed to span multiple lines (except for
arrays having initializer lists).

6) Syntax colourization speed in View/Edit has been improved (this will be noticeable with larger programs)

7) An optional 200 microsecond overhead (Options menu)has been added to each call of loop()– this is to try
to avoid falling too far behind real-time in the case where the user program has no added delay() anywhere
(see Timing discussion under Modelling).

Version 1.2 June 2015

1) The SD library is now fully implemented and a (small) 8Mbyte SD Disk I/O device has been added (and
functionality tested against all Arduino sample SD programs).

2) Like Arduino, UnoArduSim will now automatically convert a function argument to its address when calling a
function expecting a pointer to be passed.

3) Parse error messages are now more appropriate when there are missing semicolons, and after unrecognized
declarations.

4) Stale Variables Pane line highlights now get removed on function call/return.

V1.1 – Mar 2015

1) The main window can now be maximized/re-sized to make the Code Pane and Variables Pane wider (for
larger screens).
2) A Find menu (and toolbar icons) have been added to allow quicker navigation in the CodePane and Variables
Panes (PgUp and PgDown, or text-search with up-arrow, down-arrow).
3) The View/Edit window now allows ctrl-PgUp and ctrl-PgDn navigation jumps (to next empty-line), and has
augmented Find/Replace functionality.
4) A VarUpdates menu item has been created to allow the user to select a computation-saving approach under
heavy Variables Pane update loads.
5) Uno pins and attached LED's now reflect any changes made to I/O devices even when time is frozen (that is,
even when execution is halted).
6) Other user functions can now be called from inside a user interrupt function (in accordance with update to
 Arduino 1.06).
7) A larger font can now be chosen from the Options menu.

V1.0.1 – June 2014

Waveform windows now label analog pins as A0-A5 instead of 14-19.

V1.0 -- first release May 2014