Updating Arduino Software Question

[Electro Fan]

I have a pretty old version of the Arduino software (1.0.5).

I noticed that I'm about .6 rev's behind - looks like 1.6.6 is the current version.

I'm on Windows 10.  Is it ok to just download 1.6.6 and install over the old version or is it necessary or preferred to uninstall the old version before installing the new version?  Thanks

[Electro Fan]

All the sketch files were in a different direction so I just uninstalled the earlier version and then installed the new version - figured that was easiest/best.  Seems to work fine.  New version provides some useful info on sketch size and the Uno's remaining capacity.

[westfw]

I'm about .6 rev's behind

You're not as far behind as you think.
1.0.x was the "shipping" version for quite a while, and 1.5.x was the "beta" version of the much enhanced (included ARM) IDE.
So assuming that you wouldn't have done the beta, or "nightly" builds, you're only 0.0.6 behind.
The full list of "releases" is here: https://www.arduino.cc/en/Main/OldSoftwareReleases#previous
(On the minus side, the 1.6.x "increments" have been pretty substantial compared to the 1.0.x increments.)

[Electro Fan]

I'm about .6 rev's behind

You're not as far behind as you think.
1.0.x was the "shipping" version for quite a while, and 1.5.x was the "beta" version of the much enhanced (included ARM) IDE.
So assuming that you wouldn't have done the beta, or "nightly" builds, you're only 0.0.6 behind.
The full list of "releases" is here: https://www.arduino.cc/en/Main/OldSoftwareReleases#previous
(On the minus side, the 1.6.x "increments" have been pretty substantial compared to the 1.0.x increments.)

roger that

One thing I noticed was that a fairly large sketch that fit in 1.0 now doesn't fit in 1.6.  Seems like something in 1.6 is taking up some of the memory that was previously available for the sketch.  The program storage space is fine but the dynamic memory seems to have less room for global variables, I think.  On the plus side 1.6 is pretty specific/informative - it says the maximum dynamic memory for local variables is 2,048 Bytes.

[westfw]

the dynamic memory seems to have less room for global variables, I think.

This should be relatively easy to analyze (using avr-nm.)  On a couple of smallish programs, they looked pretty comparable (so it's not something "obvious" like doubling the size of serial buffers.)

[kripton2035]

if you want to develop with recent arduino like boards, you need 1.6.x or + version (for example the famous esp8266...)

[Electro Fan]

Ok, everyone here probably knows this but if you upgrade from an Arduino Uno to an Arduino Mega 2560 it's pretty straightforward.  Other than noting the change of board and com ports in the IDE the only slight wrinkle was that the sketches that I used with I2C didn't work until I replugged from A4 and A5 on the Unos and move to SDA and SCL on the Mega 2560s.  I had expected that A4 and A5 on the Mega 2560 would behave the same way (effectively operating as SDA and SCL) but they didn't - but when I moved to the designated SDA and SCL headers on the Mega 2560 everything worked fine.  The reason I moved from the Uno to the Mega 2560 was to get more memory capacity and sure enough a sketch that was at about 97% came down to 24%.

[Electro Fan]

Back to the original mission - trying to understand/learn about I2C and trying to decode it on a MSO2072A.

Where the Unos maxed out at 50 lines, with the Mega 2560s I am able to easily transmit 100 wire.write lines, each with 32 Bytes such as this:

      Wire.beginTransmission(5);
      Wire.write("Help This Scope Operate 12345001");
      Wire.endTransmission();
      Wire.beginTransmission(5);
      Wire.write("ABCD EFG HIJK LMNOPQR STUVW002");
      Wire.endTransmission();
      .
      .
      .
      .
      Wire.write("Help This Scope Operate 12345097");
      Wire.endTransmission();
      Wire.beginTransmission(5);
      Wire.write("ABCD EFG HIJK LMNOPQR STUVW098");
      Wire.endTransmission();
      Wire.beginTransmission(5);
      Wire.write("Help This Scope Operate 12345099");
      Wire.endTransmission();
      Wire.beginTransmission(5);
      Wire.write("ABCD EFG HIJK LMNOPQR STUVW0100");
      Wire.endTransmission();
 
The Mega 2560 Master and Mega 2560 Slave are happy to speak to one another at 9600 baud for the entire transmission/reception of the 3,200 Bytes.

The data set was captured at 5 ms and reviewed at 10 us.

With acquisition set to 700k points the record function captures the entire data set across 5 segments.  With the TimDiv set to 5 ms the entire data set appears on the screen across less than 4 Divs.  With the trigger set one Div from the left of the screen edge this leaves over 10 Divs empty (available on the screen).

The scope is able to decode the I2C data accurately into Hex, Decimal, Binary, and ASCII simultaneously on both analog channels and digital channels.  Further, the decoder boxes align bit for bit with the analog waveform throughout the data set to the end of the data set. Unfortunately, it doesn't appear that the decoder boxes are aligning with the waveforms on the digital channels.  Not sure why this is just yet, but I'm looking into it further.

With the ceiling on capacity raised by the Mega 2560 I'll try larger data sets and continue to try to figure out what is happening with the MSO2072A on the digital channels.

EF

[Electro Fan]

Successfully transmitted 32 Bytes per line x 200 lines = 6,400 Bytes total. 

IDE says global variables are using 6,792 bytes (sic) (82%) of dynamic memory, leaving 1,400 bytes (sic) for local variables.  Maximum is 8,1982 bytes (sic)".

The scope recorded the data set across 9 segments and each full segment of decoder data has a duration of about 70 ms.  Overall the scope functions the same as described above.  The analog and digital channel waveforms appear to be pretty closely aligned.  All Bytes decoded properly on the analog channels and the digital channels.  The decoder boxes are aligned with the waveforms on the analog channels but the decoder boxes are not aligned with the waveforms on the digital channels.  The digital channel decoder boxes are ahead of the waveforms by about 52 us in each segment.  Hard to say exactly with cursors but the error is in this ballpark.  My guess is that where programming decoders is not too difficult (1s and 0s either map to the Hex, Decimal, Binary, or ASCII codes or they don't), something happened with the pixel math when coding the location of the decoder boxes relative to the waveforms on the digital channels.  I think it's probably a math issue that became a coding problem in the firmware but it's a little strange that Rigol got it right with the analog channels and not the digital channels.