AS6 Comprehensive Reference?

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

Hi all,

 

I have been using Atmel Studio for about a year with success. Everything I know about is based on various bits and pieces of tutorials and whatever I can figure out on my own. While that has allowed me to get some reasonably sophisticated projects completed, but I feel that there is always a cool new trick around every corner that I am missing out on. In general, I have quilted knowledge that I am hoping to refine past what google searches and youtube videos can offer. Much of what I need to learn goes beyond the IDE - study of the compiler/linker, etc, but I will focus this discussion on the IDE and the associated toolchain and plug-ins. In the end, I want to be able to lead a team and not be in my own weird self-taught world. 

 

Does anyone have any resource suggestions for complete reference or courses on AS6 and/or the various toolchain options? I am specifically not looking for tutorials that cover how open a file, but rather a structured approach from beginner to advanced that will help me better understand how to approach larger projects and team projects. For example, debug tools are a mystery so far and I can only partially understand the toolchain properties. Many of the tutorials I have found simply explains what buttons to push or what to type in a field without explaining the concepts. 

 

I am more than willing to pay money and put in the time, but I have not yet found much. Of course I also feel like I barely know what questions to ask since I don't even know what I don't know. Hoping to learn, please share if you have any good ideas. Thank you.

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

debug tools are a mystery so far

Debug tools are not Atmel Studio specific, if you know how to use a debugger or from any  company then you will pick up the Atmel debugger with ease.

 

I learned debugging with a "monitor" program which was built into the chip, that was around 35 years ago, since then I have used many brands of debuggers without issue.

 

I guess this may still be taught at college/uni as part of a programming course.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

If you want to learn about debugging in an IDE just use the simulator. You can set breakpoints, single step and so on. 

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

Thank you gentlemen for the notes on debugging. I had listed those specifically. 

 

To further define the problem is that I don't seem to know the entire problem. When I was getting started in design and manufacturing in the mid-90's [mechanical only at that time] I was first searching for a CAD software package. There were many to choose from, but thankfully I chose SolidWorks which has risen to be a great mechanical design tool over the years. I took a short class to get started and I was able to design and build many successful and sophisticated commercial designs. About ten years into SolidWorks, I considered myself to be an expert but still wondered what I never learned. I took another advanced class and the most important lesson I learned is that I doing many things the "hard way". Ten years of doing repetitive tasks the hard way most likely added up to a MASSIVE waste of hours. That is not even mentioning to compromised designs because I thought something was impossible or at least very difficult. 

 

Since that moment, I have been dedicated to learning tools and software from the ground up and never stopping the learning process. As my business and myself have transitioned into EE [my first career choice], I have found myself in the same situation I was ten years after "learning: SolidWorks, I know enough to be dangerous and even get some things done - but I don't really know the ATMEL STUDIO tool and would like to get educated before another ten years of hacking go by. 

 

Maybe focusing on the IDE is the wrong place to start as well and I would be interested in hearing from anyone that may better understand the sequence of education for someone like me trying to build from fundamentals to advanced development of embedded systems using AVR. Taking the fragmented "tutorial" approach is great but only if I know what knowledge I should be seeking in the first place. For example, I recently learned the basics of how break up my code into a a re-usable library which is a giant benefit that I did not even know to ask about early on - simply stumbled upon a tutorial that looked interesting. In the case of SolidWorks, there are many books and online courses that go end-to-end in addition to focused tutorials. What I am after is the education solution that will best ensure I don't end up with fragmented knowledge. 

 

Are there any books or online courses that cover AVR development that may explain the concepts and significance of the various tools invloved? I took a course in C, but it was generic fundamentals of syntax and basic structure of programs. Very useful indeed, but of course I see tons of cool and interesting programming tricks that are targeted at embedded development that would be hard to extract out of a C course. 

 

More examples of things I don't really understand: Not really looking for answers directly, but rather looking for the place to look for those answers. 

Atmel Software Framework - It seems cool and handy, but not sure how to integrate that resource. 

What exactly is the GNU toolchain and how does AS6 integrate that?

How do I best deal with revision control in AS6?

"Export project as Extension"? Why is that a good thing?

What are all the output files for? .HEX, .LSS, .EEP, .SREC??

What are the compiler Symbols?

 

Again....all rhetorical questions. Just wanted to provide a little insight into what I am thinking as I sit trying to figure out a project - clearly missing some basics. 

 

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

rx8pilot wrote:
Maybe focusing on the IDE is the wrong place to start as well ...
Indeed; consider the history of Atmel Studio.  Be flexible with how Atmel rolls.  At one time Atmel was under a, IIRC, a hostile offer so any corporation may die or be phoenixed.  May want to identify IDEs that are open source (iow a free(dom)-and-open copyright) with a large enough operator population and a large enough developer population; the concept of the cathedral versus the bazaar.  wrt AVR some either like, very much like, or "love" Eclipse, Code::Blocks, NetBeans (more?).

If willing to consider commercial, Atmel and IAR have been teamed since during the later part of the creation of AVR; IAR EWAVR, IAR EWAVR32, IAR EWARM can each target Atmel MCUs.

Several to near numerous other commercial IDEs for AVR.

rx8pilot wrote:
... and I would be interested in hearing from anyone that may better understand the sequence of education for someone like me trying to build from fundamentals to advanced development of embedded systems using AVR.
Jack Ganssle is one of a number of embedded systems gurus.

How to Become an Embedded Systems Geek by Jack Ganssle.

There's a bit about AVR on his web site.

rx8pilot wrote:
... simply stumbled upon ...
Excellent; a combination of intuition and synchronicity.

When one leads with one's intuition (love, heart) then enables with one's mind (thought, brain) one will be creative.

rx8pilot wrote:
Are there any books or online courses that cover AVR development that may explain the concepts and significance of the various tools invloved?
Consider this.

Take Michael Barr's embedded C book and go deep into it except using your preferred AVR.

My experience doing that was with an embedded x86 job; now some AVR could do that job's task on a coin cell!

I concur with Jack Ganssle's listing of that book of Michael Barr's.

Online course - wasn't aware of the University of Texas embedded systems course on edX; not AVR but may be worth a peek.

http://users.ece.utexas.edu/~valvano/Volume1/E-Book/

[plug]

Austin Texas has some fun!

[/plug]

Tools for Embedded Systems by Jack Ganssle.

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Sep 19, 2014 - 04:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are there any books or online courses that cover AVR development that may explain the concepts and significance of the various tools invloved?

Is it the Chinese civil service that (apocryphally!) has a one question entrance  exam that says "Write down everything you know..."

 

What you are asking seems too broad like "how do I learn everything about software engineering and MCUs?". There just isn't a way to learn all that from one source or even 50 sources. At the top of the tiny/mega forum here we have a "Newbie? .. Start here!"sticky thread that has tried to collate links to a lot of (good!) learning resources but to be honest I think you just have to ask the questions as you come to them. I know you said:

Not really looking for answers directly, but rather looking for the place to look for those answers. 

but here goes anyway - I will simply answer them rather than link as I think most can be answered in a sentence or two and finding suitable links would take longer...

Atmel Software Framework - It seems cool and handy, but not sure how to integrate that resource. 

People here have mixed views about ASF. I wouldn't consider myself a "fan". The fact is that when you buy complex silicon these days (mainly ARM as they have pretty much cornered the market) the devices have some extremely complex peripherals. While the datasheet ill explain the buts and bolts of "this bit in this register achieves this..." what they never tell you is why you actually might want to get interested in that particular bit. It's also the case that the peripherals try to be all things to all people so some bit in some register is probably only intended for Eskimos in Outer Mongolia on every third Tuesday but only so long as they have their left leg stuck out the window. While some bits are a case of "if you don't set this bit all bets are off". You, he reader cannot tell what's important and what isn't. The many who knows is the man who designed that UART or SPI or timer or DMA or whatever so if you could get him to write a "demo program" to show how he actually intended for the FOO and BAR bits to be used it would be far more useful than a 1,000 pages in a dry manual. And that's what ASF (and other libraries from other silicon vendors fopr their own chips) attempt to do. But Atmel's variant (ASF) has some shortcomings. First off it is of almost no use to users of tiny or mega AVRs. It's generally considered that the peripherals in those chips are all so simple you can just work it out by reading about the three registers (or whatever) in the datasheet. So atmel have added virtually nothing to ASF for those chips. It's only their more complex chips like Xmega, UC3 and ARM that they have any significant amount of support for but they've kind of made the mistake there of trying to make it "all things for all people". I said there were some bits that were vital and some that only worried Eskimos. Well ASF tries to wrap software around everything including the right legged Eskimos. As such it's overly complex and if you drill down into it to see how even the simplest "light the LED" call works you find 5 or 10 layers of mind numbing complexity. I guess if you are always happy to light your LED using that top level call this probably doesn't matter to you. But if you are interested in drilling down into it and seeing how it works under the hood it is almost more complex than just going back to the dry datasheet. (what happened to "couple of sentences"?).

What exactly is the GNU toolchain and how does AS6 integrate that?

Well GNU is "GNU Not Unix" (a recursive acronym!). It's a bunch of programmers that wanted to make an "open" version of the Unix operating system. To build it they also needed a compiler for they wrote one. It's called GCC (GNU Compiler Collection - originally GNU C Compiler). It's the C compiler that Linux is built on. It's possibly the most heavily engineered C compiler in the world. Because it's geeks who use it and because the source is open when some geek somewhere says "hey, wouldn't it be cool of the compiler could do ..." that person can pull the source, develop the feature they wanted then publish their changes back. If the "steering committee" think it's a feature others would like they then agree for it to be added to the main tree. Over time the compiler therefore just gets better and better. Now it's a compiler originally developed for things like PDP/11 and then Intel x86 and more recently ARM with AVR coming to it very (relatively) late. So the main development work tends to be in making the x86 and ARM compilers the best they can be. Often the AVR build also benefits from features added there but sometimes it actually gets worse for AVR. But on the whole avr-gcc is one of the top 3 compilers for AVR. And it's free. And it's open.

 

Now Atmel wrote and provided a free assembler for their AVRs but have never developed a C compiler. In Studio 4 (that already contained 2 versions of their assembler) they wrote a plugin that meant a user could get a copy of Studio 4 and a copy of avr-gcc built for Windows (usually a distribution called WinAVR) and put the two together and Studio would then recognise that the 3rd party compiler was present and offer to launch it from within the Studio IDE. There were plugins for other compilers developed that allowed those to be used from Studio 4 too.

 

When Atmel got in league with the devil (sorry that should have read "made a deal with Microsoft) they decided to make a new IDE based on Microsoft Visual Studio 2010. They still didn't have a compiler of their own so they employed a team in India to take the generic avr-gcc that was available then make some "Atmel tweaks" to it - mainly to add support for new models of tiny, mega and Xmega and then they decided to actually include this avr-gcc with Studio 6 so the user no longer had to get Studio (4) and WinAVR separately but one install package from Atmel would put both Studio 6 (as the editor / builder/ debugger) and avr-gcc (as the C / C++ compilers and associated assembler + tools) into one conglomerate package. In fact it goes further than this. For AVR32 there already was a development of gcc called avr32-gcc and that gets packed to. Then for ARM there's been arm-gcc for many years and because Atmel wanted Studio 6 to also support ARM/Cortex they included arm-gcc too. So you actually get three copies of GCC in Studio 6: AVR, AVR32 and ARM. Also each contains TWO compilers (C and C++) so there are 6 compilers. Each of the three variants has its own assembler (both C and C++ just convert source to Asm then pass it to an assembler). So there's three GNU assemblers in there too.

How do I best deal with revision control in AS6?

First pick which one you want to use. The popular choice is probably between SVN and Git. At least for SVN (not sure about Git) Studio 6 then has an add-on package called AnkhSVN which adds SVN UI within the IDE. (personally I use SVN but don't bother integrating into the IDE - I just use TortoiseSVN along side AS6).

"Export project as Extension"? Why is that a good thing?

I think the plan is that you can then start new projects based on your own personal "template" with compiler/linker options set the way you want them. I've never used the facility so I'll leave someone else to justify its existence.

What are all the output files for? .HEX, .LSS, .EEP, .SREC??

You realise that's just a subset? The funny thing is that the old AVR Freaks used to have a dreadful Wiki but on it was this which I always thought was very good:

 

 

(boy you don't know how complex it was to find that now that the old Wiki is no longer accessible?). One file that doesn't show is the .lss. That is a disassembler listing that is produced by "objdump" using the ELF (and .c source files) as input. The .eep file is a second .hex file (they are both Intel Hex format internally). Way back when someone just chose to call it ".epp" to distinguish it (EEPROM contents) from flash contents.

 

As for .SREC - that is (generally) of no relevance to AVRs - the encoded binary format of choice for AVR is Intel Hex.

What are the compiler Symbols?

Everything in a C program has a name. You have variables and you give each a name. You have function and you give each a name. "Symbols" is just a collective term for all those names. One way of looking at it is that anything that is given a memory address either in RAM or flash has a name - those names are the "symbols". Again another file type not shown in that picture is ".MAP" this is a file output from the "Linker" stage. It sets out a list of address and symbol names so you can look up where anything might have been located in RAM or flash.

 

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

clawson wrote:
As such it's overly complex ...

http://www.atmel.com/Images/Atmel-42370-Optimizing-ASF-Code-Size-to-Minimize-Flash-and-RAM-Usage_ApplicationNote_AT08569.pdf

has one mention of AVR; the bulk of that app note is for ARM Cortex-M.

"Dare to be naïve." - Buckminster Fuller

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

Holy crap Batman....great information. I really appreciate the time you took to offer some wisdom. 

 

gchapman wrote:

Jack Ganssle is one of a number of embedded systems gurus.

 

I spent hours last night digging through his info. Excellent resource, thank you.

 

gchapman wrote:

Be flexible with how Atmel rolls.

 

I see the wisdom in that now. Looking at various commercial options that may serve me better as I move through the various hardware options. Probably best not to get too fixated on the Atmel way - although they have a great offering of solutions. 

 

gchapman wrote:

[plug]

Austin Texas has some fun!

[/plug]

 

I am from Houston, spent lots of time in Austin as well - the Los Angeles of Texas ;-)

 

clawson wrote:

What you are asking seems too broad like "how do I learn everything about software engineering and MCUs?"

 

I totally get it and I am trying to stick to the reasonably narrow topic of the AS6 IDE. One of my problems to solve is better understanding where the IDE education stops and where the study of C, Compilers, AVR peripherals, etc, etc starts. My goal is to segment my efforts into logical categories. It seems that to fully understand the various options and features an IDE offers - I need to have a broader knowledge of C, AVR, and whatever compiler is being used. when I first put my machine shop together I spent about $16k on software to program the machine. At first the software made no sense because I had not yet learned to art and science of being a machinist. The problem was that I couldn't machine much without knowing the software and the software didn't make sense because I was not a machinist. I eventually got past the challenge and purchased numerous 5 axis machines - but it took a few years off of my life. 

 

clawson wrote:

You realise that's just a subset? The funny thing is that the old AVR Freaks used to have a dreadful Wiki but on it was this which I always thought was very good:

 

Wow, a picture is worth a thousand words [or more]. That chart is really a great way to see the process from a high altitude. thank you digging that out of the archives. 

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

To learn about IDEs I'd just get one for writing PC programs on a PC and learn about the use of an IDE there. They're all pretty similar and ultimately offer similar facilities. When you move to Studio 6 it will then feel "familiar". The advantage of PC development is that there's no fiddling about with ISP programmer's and JTAG debuggers, everything just happens on your PC and you see instant results. But breakpoints, watches, single stepping and all that "feel" exactly the same as for AVR development. 

 

Also read Morten's online manual for AS6.