Updating Arduino Software Question - Page 1
Forum section: electronics / general

author: Electro Fan
author_rank: Super Contributor
timestamp: November 20, 2015, 05:02:51 am
content: 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

author: Electro Fan
author_rank: Super Contributor
timestamp: November 20, 2015, 05:21:57 am
content: 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.

author: westfw
author_rank: Super Contributor
timestamp: November 20, 2015, 05:56:03 am
content: QuoteYou'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.)

author: Electro Fan
author_rank: Super Contributor
timestamp: November 20, 2015, 06:12:39 am
content: Quote from: westfw on November 20, 2015, 05:56:03 amroger thatOne 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.

author: westfw
author_rank: Super Contributor
timestamp: November 20, 2015, 07:34:50 am
content: QuoteThis 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.)

author: kripton2035
author_rank: Super Contributor
timestamp: November 20, 2015, 07:58:52 am
content: if you want to develop with recent arduino like boards, you need 1.6.x or + version (for example the famous esp8266...)

author: Electro Fan
author_rank: Super Contributor
timestamp: November 21, 2015, 04:14:37 am
content: 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%.

author: Electro Fan
author_rank: Super Contributor
timestamp: November 21, 2015, 04:47:59 am
content: 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

author: Electro Fan
author_rank: Super Contributor
timestamp: November 21, 2015, 05:05:42 am
content: Successfully transmitted 32 Bytes per line x 200 lines = 6,400 Bytes total.IDE saysglobal 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.