Studio 4.12 wishlist.

Go To Last Post
76 posts / 0 new

Pages

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I realize this is a bit late (as the RC1 of 4.12 is out), but still:

1) Studio does not remember what toolbars one has selected from one run to another. As it is now, I get two rows of toolbars and screen real estate is always a scarse resource. EEither You could see to it that Studio actually remembers what toolbars are chosen, or just change the default state of the Trace toolbar to off (the latter would at least give one row of toolbars if running Studio covering full screen @ 1280 pixels width). (What's the TraceBar used for anyway. It has no function when programming assembly and no function with AVR-GCC as fat as I can see?))

2) Whenever I press F10 (as in Step over) the File menu head gets toggled as well. Maybe minor, but not pretty...

3) The 4.12 RC1 help has broken links: Go to the release notes, and to the links at the end of it. The links to AVR GCC IDE User guide, and Simulator User guide are broken.

Hats off fort the AVR-GCC integration, though!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In addition to the post above, I cannot seem to be able to watch any SRAM location: I always get the "Not in scope" message.

Another wish of mine -and not alone I guess- is a major part-update of this very useful little executable, the "AVRprog.exe".

Thank you in advance,
Giorgos.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The avr-gcc documentation should be accessible from Help->AVR GCC plug-in help when the plug-in is active.

I am not sure, but I think the broken help links have been fixed and that the AvrStudio4setup.exe file at www.atmel.no/beta_ware has been silently updated.

Torleif.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Giorgos_K wrote:
In addition to the post above, I cannot seem to be able to watch any SRAM location: I always get the "Not in scope" message.

Please provide some more details (like a sample program, etc). It works for me (with gcc). Also be aware that optimization may cause surprises -- turn optimization off when debugging..
Giorgos_K wrote:
IAnother wish of mine -and not alone I guess- is a major part-update of this very useful little executable, the "AVRprog.exe".

Sorry, we haven't supported that program for 4 years I think. You may try to contact our main support e-mail address avr@atmel.com if you have questions regarding this.

--
roland

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Again this maybe late and I have not tested on the most recent version, but I have reported this to an FAE. I was asked to give specific situations in which this bug presents itself but I have never been able to isolate the bug and duplicate it on command.

Situation:
I have a mix of different types of variables in the watch window (including arrays).

I have the code running in debug and hit Break.

The watch window goes "crazy". It flickers like it's attempting to refresh at an insane rate.

I have found only 3 paths to correct/work around this bug:
1. I have to right click extremely fast and try to catch the pop-up, I hit the "Remove All Items" option. All the variables are removed and the flickering stops.

2. I have also switched watch window tabs, then I can use the remaining watch windows. But the flickering watch window remains flickering when I select that tab.

3. Restart AVR Studio.

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello Roland.

I am sorry it took me so long to reply. I just had to make sure to read every AVR Studio help topic, and to try every possible program configuration before responding.

rkruse wrote:
Giorgos_K wrote:
In addition to the post above, I cannot seem to be able to watch any SRAM location: I always get the "Not in scope" message.

Please provide some more details (like a sample program, etc). It works for me (with gcc). Also be aware that optimization may cause surprises -- turn optimization off when debugging.

Well, either creating a new AVR Assembler project or reopening an older one, the AVR Studio v4.12.45x Watch window would accept any IO, SRAM or EEPROM label or definition, only if it had been assembled using the v1.x or the v2.0.31 assembler.

Using the (more flexible?) v2.1.0 assembler, the Watch window could not accept the same IO, SRAM or EEPROM definitions/labels, though they had been successfully registered in the generated .map file. It gave me the "Not in scope" value, even for the standard, ZL for instance, register definitions.
Can this behavior be considered as a bug?

Moreover, creating a new AVR Assembler project, the program did not allow spaces in the project name, giving me the "Space in project name is not supported" warning. Unless I checked the "Create initial file" checkbox, or had included a period to the filename.
What am I doing wrong?

I have an additional question regarding the Watch window. During an AVR Assembler project simulation, how can I watch a multibyte variable? The expressions r1:r0 (or r0:r1) or XL+1 are not accepted.

rkruse wrote:
Giorgos_K wrote:
Another wish of mine -and not alone I guess- is a major part-update of this very useful little executable, the "AVRprog.exe".

Sorry, we haven't supported that program for 4 years I think. You may try to contact our main support e-mail address avr@atmel.com if you have questions regarding this.

As for the "AVRprog.exe" I hoped that it would be updated to support the new AVR generations, as it happened there https://www.avrfreaks.net/index.p... to support the newer m169 (and the m162 consequently).
Though I can understand your company's policy regarding obsoletions, I still find it to be a very handy tool, specifically for the bootloading procedure since it requires a smaller and more simple bootloader than the STK500 v2.0 Protocol does.

Thank you for your time,
George Kolovos.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Giorgos_K wrote:
Well, either creating a new AVR Assembler project or reopening an older one, the AVR Studio v4.12.45x Watch window would accept any IO, SRAM or EEPROM label or definition, only if it had been assembled using the v1.x or the v2.0.31 assembler.

Using the (more flexible?) v2.1.0 assembler, the Watch window could not accept the same IO, SRAM or EEPROM definitions/labels, though they had been successfully registered in the generated .map file. It gave me the "Not in scope" value, even for the standard, ZL for instance, register definitions.
Can this behavior be considered as a bug?


Yes, definetily! I have verified it and we will start fixing it first thing tomorrow. I'm sorry I didn't get it earlier, I was somehow under the impression that you worked with a gcc project (where it works).
Giorgos_K wrote:
Moreover, creating a new AVR Assembler project, the program did not allow spaces in the project name, giving me the "Space in project name is not supported" warning. Unless I checked the "Create initial file" checkbox, or had included a period to the filename.
What am I doing wrong?

Spaces are not allowed in project names in 4.12. It is a bug that it is allowed in some cases.
Giorgos_K wrote:
I have an additional question regarding the Watch window. During an AVR Assembler project simulation, how can I watch a multibyte variable? The expressions r1:r0 (or r0:r1) or XL+1 are not accepted.

I'm sorry, I don't think that can be done in assembler projects. Will check tomorrow to make absolutely sure.
Giorgos_K wrote:
As for the "AVRprog.exe" I hoped that it would be updated to support the new AVR generations, as it happened there https://www.avrfreaks.net/index.p... to support the newer m169 (and the m162 consequently).
Though I can understand your company's policy regarding obsoletions, I still find it to be a very handy tool, specifically for the bootloading procedure since it requires a smaller and more simple bootloader than the STK500 v2.0 Protocol does.

I'll check once more, but cannot promise anything.

Thank you for reporting these bugs. We will put out an updated version later this week.

--
Roland

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Roland.

I did not have the time yet to test a gcc project, since the assembler ones seem to me that utilize the AVR Studio's fundamentals.

Thank you -again- for your effort.
Giorgos.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Monsoon wrote:
Again this maybe late and I have not tested on the most recent version, but I have reported this to an FAE. I was asked to give specific situations in which this bug presents itself but I have never been able to isolate the bug and duplicate it on command.

Situation:
I have a mix of different types of variables in the watch window (including arrays).

I have the code running in debug and hit Break.

The watch window goes "crazy". It flickers like it's attempting to refresh at an insane rate.


Which version did you observe this in? Was it 4.11 or one of the 4.12 beta builds?

--
Roland

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

single key or combo to expand code editor to fill window and hide workspace panes, or collapse code editor back into workspace panes. Ctrl+space might be convenient if it can be trapped.

single-key to flip back from full-window code editor to IDE workspace, build, connect to programmer, and upload (quitting at 'build' if errors). ctrl-f7, shift-f7, or something similar might be nice.

hyperlinked errors (click on error message to jump to line in source) or visible indication of source lines with errors

option to continue up to 'n' times automatically, skipping intermediate breakpoints until the nth time the current breakpoint is reached, or execution reaches a ret, reti, or equivalent in the same scope as the current breakpoint (handy for loops from 0 to 255 where you don't need to have it stop again until it counts up to 254 or down to 1).

Tooltips for buttons without them.

seamless integration with CVS and visible indication of each file's status (local, changed, up to date, conflict), visual diff, etc. (admittedly, a huge project that's highly unlikely to happen).

There's no place like ~/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would also be nice if there were a way to simulate two chips (not necessarily the same model, nor running the same program code) simultaneously running in their own private debuggers, with one or more pin and/or bus connections between them. The hardest thing would be synchronizing all the virtual chips clocks so they proceed in lockstep (ie, when a breakpoint on one chip is reached, time freezes for all of them; as the chip being stepped advances, time advances by the same number of clock cycles on the other chips) so things that are timing-critical can still work.

For example, let's suppose we have two Mega168 chips connected via I2C, 1-wire, or SPI. Both begin from RESET simultaneously, advancing clock by clock in lockstep, perceiving the flow of time in their own parallel reality so everything seems to be taking place in realtime, until a breakpoint in one of them is reached. At that point, both chips' virtual clocks would be halted, and the debugger would show the next statement for both. Because both chips would perceive the passage of time as uninterrupted, even timing-sensitive communication via one of the major protocols works, as do even custom protocols that rely on bit-banging the raw pins and polling them for changes or reacting to interrupts.

Ideally, the mechanism for sync'ing up the two debugging sessions and passing messages between them would be public, so support for third-party interfaces could be added as well. Etherlinx comes to mind as a particularly apt candidate for such an interface (leeching the host machine's network connection and buffering responses received from the "outside world" when its virtual program counter was stopped while the other chip's code were stepped through).

This same framework could be used to simulate other peripherals, like a LCD connected to a virtual Mega169 or some other LCD connected via I2C or 1-wire.

Of course, this would be brutally hard to actually implement :shock:

There's no place like ~/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Suppose provision were made to allow up to two virtual AVR chips, plus an unlimited number of emulated (or real!) peripherals implementing a public Java interface. Each of the virtual AVR chips' would be given a name, as would each of the peripherals, and an xml file would be used to define the interconnections: