Feature request?

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll apologize now if this is an inappropriate place to post this, I wasn't sure where it goes.

Anyone else think it would be nice to have AVR studio have some standard tables readily available and a rudimentary calculator? tables like hex to binary, ascii, stuff like that.

the calculator mainly for testing boolean binary logic, shifting, adding binary. seems more efficient than building and debugging code to see if you've done it correctly.

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

Since all of the MS Windows operating systems that AVR Studio runs under, already have a calculator program that does base conversions, it would redundant. Just open a calculator window and select the scientific view. I have found that I only ever need an ASCII table just briefly when developing some new programs. A HEX editor program has taken care of all my other ASCII needs. There are lots of other utilities that run under Windows. Windows is a multitasking OS, try it out :).

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

There is a feature I would like to see in the assembler.

Sometimes the LDS or STS op code will accidentally use an I/O equate from the wrong section of the include file:
I/O Register Definitions ($3F-$00)
instead of the correct:
Memory Mapped I/O Register Definitions ($FF-$60)

While the executable code generated has a valid address, it will end up in the wrong place, a really wrong place. All the while it is innocently disguised and looks like good code at first glance.

It would be nice to have an assembler directive that would be easy to turn on and easy to turn off. When on, it will flag any LDS or STS instruction that points to SRAM from $00 to $3F as a warning when you build. It would help the developer to spot check and separate the good LDS/STS instructions from any bad ones that used the wrong include name. While it would not flag all other possible abuses of the lower I/O register definitions, LDS/STS are a common replacement for IN/OUT when accessing the upper memory mapped I/O registers.

BTW, Linux is also a multitasking OS and I wish it had been the platform selected for AVR Studio :cry:.

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

Mike B wrote:

BTW, Linux is also a multitasking OS and I wish it had been the platform selected for AVR Studio :cry:.

Agreed. I'm just learning linux (actually Solaris) now.

BTW -- I had been using windows built in calc, just thought it would be a handy addition. Like incorporating a good text editor, which is a given. Same for the tables idea -- Help has links to tons of info, a simple table or two would be nice.

But I don't want to complain -- I'm more than satisfied with what I've seen so far, which is only 25% of what it probably does.

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

rlf, I will suggest you may be under utilizing your computer resource.

Software Development Environment (IDE) screens are big space eaters. It really helps if you have at least one 21 inch monitor. Its just more convenient to keep multiple windows (Studio IDE, calculator, terminal program, etc.) open together on a big desk top. If not, then there is always the task bar to switch with.

A long time ago, I remember what a revelation it was to get multitasking on my desktop through Unix (when nicer people owned UNIX) and that was with a 9600 baud ASCII terminal, not a Graphics User Interface (GUI). Now with a GUI and decades of software written for it, you should view your computer a big building block set that you fill with fun/useful blocks, however hard it may be to get some of them running correctly. Learn to use the tremendous flexibility that multitasking brings, mix and match for the task at hand. Be creative and you will not only solve lots of microcomputer development problems but have an easier time doing it. I have been down some of the more dimly lit paths in the past and it is soooo much easier nowadays.

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

hmm -- dual monitors. I didn't think of that. My computer does support that and I do have one sittng around..

I'll let you know how it turns out.

Would 1) 17" lcd and 1) 17" crt qualify as "at least one 21" monitor"? :D

Of course, I could always get a new one..... I love rationalizing irrational purchases --- drives my wife crazy though 8)

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

Mike B wrote:
There is a feature I would like to see in the assembler.

Sometimes the LDS or STS op code will accidentally use an I/O equate from the wrong section of the include file:
I/O Register Definitions ($3F-$00)
instead of the correct:
Memory Mapped I/O Register Definitions ($FF-$60)

While the executable code generated has a valid address, it will end up in the wrong place, a really wrong place. All the while it is innocently disguised and looks like good code at first glance.


I have noted your request, but would like to suggest that you may be able to fix this for yourself with some creative use of macros and conditionals. Something like this (untested):

; usage: InReg reg, addr
.macro InReg
    .if @1 < 0x40
        in @0, @1
    .elif @1 >= 0x60
        lds @0,@1
    .else
       .error "inReg: Invalid I/O register address"
    .endif
.endmacro

Then you may use InReg instead of both IN and LDS. I leave the corresponding OutReg macro as an exercise for the reader :)

hmmm... maybe we should provide an include file with this...

--
Roland Kruse
Atmel AVR Tools

Please don't report bugs in private forum messages.
--
Roland Kruse
Atmel AVR Tools

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

Kruse,

Excellent (soon to be tested) solution and much better than my feature want. Providing a standard include with the software package would help keep dummies like me :) from tripping on this memory management feature, well at least the ones that like assembler.

It appears I have been under utilizing my assembler macros :oops:. My only defense is its a brand new architecture and assembler for me (I'm still writing throwaway "learning" code with the mega128 data sheet as the main reference). I normally do not even begin to think about macros until its time to start writing real programs (assuming that I would have come with as elegant a solution anyway). Thanks for the solving the problem.

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

Mike B wrote:
Excellent (soon to be tested) solution

Note to /me:
Never, never, NEVER post code without testing it first. :oops:

In this case the code is OK but it uncovered a rather ugly bug in AVRASM2, causing basic .elif condtitionals to behave incorrectly. You may discover it if you test my suggested macro with avrasm2.

The macro will work OK in AVRASM 1.76, however. I have fixed the bug already, and may post a new AVRASM2 version here if you need it quickly (that will also fix the crash problem reported here earlier).

As someone said here recently (was it you?) : The joys of beta software... :)

Roland Kruse
Atmel AVR Tools

Please don't report bugs in private forum messages.
--
Roland Kruse
Atmel AVR Tools

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

Guilty as charged on the beta comment :). I would have voted for posting the update, but it was already posted when I got back. Besides, beta software people are update addicts anyway! BTW, do you have an even newer version......

Thanks for the update.