What helped you the most when learning AVR/Atmel Studio?

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

If the moderators feel this has been covered a million times of course please delete my post.

 

What is the one thing many of you new users and long time professionals/enthusiasts learned that for one reason or another - really helped you speed up your projects or your learning process?

 

For me it was a few nights ago after struggling to learn to make USI work as an i2C slave for over a week. I was at another amazing fellows site who spends an inordinate amount of time sharing their experience and knowledge. I'm looking at the screen shots in his video for AVR Studio 6 or something and I see this panel called I/O. 

 

I haven't had as much time as I would have liked as I have been looking after my terminally ill mother singlehandedly for the past year until recently. I can't really understand how I A)  had never seen it before,  B) never found it myself, C) not mentioned very often - is it that obvious? 

 

For me this was like a live, real, applicable window into the datasheets. LOL maybe the people that come here asking for help before reading a datasheet don't know about the I/O window either.

 

Anyways I would love to hear from others what may seem absolutely obvious to them now was a revelation to learn?

 

Cheers.

 

 

 

 

 

 

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

Rediron wrote:

What is the one thing ... that ... really helped you speed up your ... learning process?

Reading the data sheets over and over and over and .....

 

--Mike

 

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

avr-mike wrote:
Reading the data sheets over and over and over and .....

+1
Also, see my .sig below. Especially the bit about reading and writing. To wit, read these (and other) fora, and answer questions which stretch your knowledge and abilities.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Having used micros for more than 20 years before using the AVRs helped!! But I remember spending over 6 months of lunchtime and after hours exercises trying to understand the Motorola 6800 PIA (6821). Remember that what you have now inside a $1 chip used to be a PCB full of chips.

 

Along with that I always had use of a monitor program to load and debug code for different types of micros and a proper debugger for National and Motorola micros. So using Studio was just another way of debugging AVRs, the same ideas are used in a monitor program or a hardware ICE.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:
I remember spending over 6 months of lunchtime and after hours exercises trying to understand the Motorola 6800 PIA (6821).
+1000 lunches

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Arduino, Actually.

I'd read the datasheets, bought or otherwise acquired STK-200, STK-500, Butterfly, a home-built tiny-11 programmer, assorted chips, and built a couple of very small projects.  But it wasn't till I started playing with Arduino, that I really started getting involved.   It gave me:

 

  1. A less complex (trivial) IDE.  That ran on my chosen (Mac) desktop.
  2. plug-and-play loading into the board, without rigging up a PC, programmer boards, power supplies, serial converters, parallel port funnies, etc.
  3. A wide body of existing code to look at, touching more peripherals than I had used.  Some if it of questionably quality and/or philosophy, to look at and say to myself "that's not how I would have done it.  I would have ... oh wait, that wouldn't quite work.  But if..."
  4. An existence proof that the ATmega48's that I'd bought shouldn't be considered a "big memory" microcontroller.
  5. things that needed to be done!
  6. a broad "audience" to appreciate (and/or criticize/improve) my efforts.

 

(I suppose it doesn't help much WRT learning "Atmel Studio."   Although the *contrast* between the two IDEs is somewhat educational...)

 

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

One tool I think is essential for embedded development is a decent scope, preferably one with a logic analyzer function.  You're just working in the dark if you can't see your inputs and outputs.

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

avr-mike wrote:
Reading the data sheets over and over and over and .....

+1 

"When all else fails, read the directions"

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

I'll second the 'scope idea. Or, even, a plain logic analyzer. I got a Saleae unit about 2 years ago, and it helped solidify understanding of the IO immensely. Yes, there are really cheeeep Chinese knockoffs, but, ethically, I would still choose Saleae even if it costs a bit more. The Saleae can also function as a (very) limited capability scope and I have used that feature a couple of times.

 

That said, there is nothing, right now, that beats the spec sheet and the manufacturer's app notes. For example, I am pretty familiar with the SPI module (it is actually one  of the  simpler peripherals). But, I could not remember if operation as a master was permissible with the SPI clock running at FCPU/2 (could not find any restriction, there, while it DOES mention clock restrictions as a slave). So, rather than reading for memorizable factoids, I suggest reading it for understanding device function and document organization. And, if you don't have a good PDF reader, invest in the software to do it.

 

I should add that we seem to be getting a stream of queries about relatively abstract internal details, such as how "one instruction per clock cycle" is actually achieved. I suspect that these are mostly from students but, for most of us, they are details that never impact how we use the AVR mcu products. Your time is better spent understanding principles rather than internal details. There IS one of those internal details that is really critical, however. That is the workings of the clock system and what is meant by "crystal", "resonator", "external oscillator", and "internal oscillator". 

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Sun. Dec 30, 2018 - 11:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for all the answers so far. Mr. Samperi's comment about spending 6 months learning the 6800, et al. was nice to hear. I don't think I've ever done anything quite so satisfying and yet at the same time makes me feel so utterly thick in my life.

 

It was the Arduino that got me hooked as well, and then I bought Make: AVR Programming by Ellioit Williams and holy cats I was really hooked. I really liked the Arduino as the 1 device that made me fall in love with electronics after a lifetime of being insulated in the world of software alone. 

 

Yes reading the datasheets over and over and over again - I'm starting to get that there is no avoiding that. I guess if your extremely high functioning and I know there are a ferw here that can probably do it on one or two reads. I'm in the I'd have to take my socks off to count that high category...

 

Jim and others have been very kind in this regard as when you're brand new datasheets can be absolutely intimidating and quite honestly until you've found some of the many  projects that many here have shared, or utube, etc.  I think datasheets are a waste of time unless your willing to follow one persons project who leads you through using a data sheet, reading many of the excellent posts here, this freaking group is better than a University Education and I would be willing to bet on that.

 

I bought a Saleae as well and I second Jim's opinion on that as well. Sure if you are utterly poor - go ahead and get a Chinese knockoff. If you do though what you should do is not use the Saleae software and just use it for the FPGA and use SigRock, etc. If your a keener - contribute. What a great project!

 

There is no way in the world you can really learn and enjoy this hobby without a cheap oscope and Logic Analyzer. At least not without driving all the people nuts that do have an oscope and a logic analyzer.  I'm very glad I invested in these two things. Perhaps I will outgrow my scope, it's a Hantek, seems ok to me so far. I've learned much from it so in that regard its paid for itself.

 

Anyways I would love to hear more stories from people about their journey in this hobby and any more tips and tricks for us unashamed and perhaps over talkative noobs.

 

Cheers,

Rod

 

 

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

Was it Confucius who said every journey starts with a single small step? I don't think there's any way to "fastrack" this. You become a skilled embedded engineer by learning each small item one at a time. So to learn AVR peripherals you'd devise experiments to use each feature of each peripheral in turn and so on.

 

EDIT actually it was Lao Tzu, not Confucius cheeky

Last Edited: Mon. Dec 31, 2018 - 10:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi. I hope I wasn't giving that impression. I've learned enough complicated things in this life to know anything of note doesn't come easily. 

 

I was more after little things experienced folks do, and know, that may seem innocuous to them but huge boons to us of us new to the profession\hobby.

 

For example. It may seem obvious to you and others more familiar with embedded programming that the most important place to start is reading whatever dependent file the io.h file pulls in for the MCU that you happen to be working on. I'm sure it has been said a thousand and one times here and I'm sorry I never actually read a post where that was pointed out explicitly (yet). 

 

If you take that file, the io window, the spec sheets, an empty code window, a huge coffee pot and start pushing buttons - you'll learn how the damn thing works eventually. 

 

When Jim kindly suggested the attiny1616 I had no idea, lol, that it was so new and this new guy was going to be navigating a chip that didn't have a lot of example code. I know the peripherals are the same but there are, as you know, subtle differences syntactically as well as mechanically among some of these chips (all?). How many people actually write a hardware abstraction layer, like Arduino, in professional situations I have no idea. I would think it wouldn't happen that much but I'm just guessing.  

 

P.S

I got to thinking I guess the folks who really do this at a high level do probably have hardware abstraction layers and use intermediate parsing tools, Lex like parsing tools. Something that is likely a complete waste of time if someone is only making one of something. Anyways as an outsider I would be curious to know what the high level pros working, where millions of widgets are made, how they abstract these little MCU's?

 

As a 30 year player of Go I thought it would be a fun project to mimic the virtual Chess board someone just made that allows you to play with real pieces. Much easier to teach an arm to move a rook or what have you, than to pick up 20 stones caught in a ladder, etc. I thought fun side project, until I thought about picking up all those GO stones. I'll stick to my main one and leave this one to someone younger and more ambitious than I.

 

Cheers,

Rod

 

Last Edited: Wed. Jan 9, 2019 - 12:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When I first started learning the AVR, I printed out the register

map of the mega 328.  You find the map near the end of the

datasheet along with the instruction set.

 

Then as I read about each peripheral, SPI, USART, etc., I made

sure I knew what each bit of every register did and crossed them

off.  Any which weren't understood completely got highlighted so

I would know to go back later and reread the section.

 

I repeated this with the mega 2560, which is actually very similar

to the 328, just more of everything.  Then the tiny 84 and 85,

and the mega 32u4.  Learning the specifics of all these different

chips gives a sense of the "abstraction" you mentioned.

 

I'm still not completely done with this.  There is the weird 10-bit

timer in the 32u4 which I skipped, and the USB stuff.  Also the

USI in the tiny.  Someday I hope to finish....

 

--Mike

 

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

Rediron wrote:
I got to thinking I guess the folks who really do this at a high level do probably have hardware abstraction layers and use intermediate parsing tools, Lex like parsing tools. Something that is likely a complete waste of time if someone is only making one of something.

 

The General Problem

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Is that your work? Very Dilberty and pretty funny.

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

Mike great advice. Really great advice. Coloring in each section keeps you honest as to whether or not you know it fairly throughly or not... I’m working on the event system of the attiny16 right now even though I’m unlikely to use it in this particular application.

Cheers,
Rod

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

Rediron wrote:
Is that your work? Very Dilberty and pretty funny.
Nope.  It's XKCD.  Click the image to visit the website.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Just adding some random things.  Know, with absolute certainty, what your real clock rate is.  Send out a square wave of known CPU cycles on an output pin and observe it on a scope.  Also, dedicate at least one output pin to a debug LED, which can also be observed on a scope for more info content.  If you can, also dedicate an input to debugging, or use some configuration switch or other input for that purpose if needed, only while using added debugging code.

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

Dunno about anyone else but when I work with a new micro the first thing I concentrate on is the UART. I get it to the point where it can display a short "menu" and act upon input key presses. Then you can start to build a test harness with entries like:

 

1) flash LED

2) write data using SPM

3) take ADC reading

 

so you can work on individual "modules" (IO, SPM/NVM, ADC, etc) in the code and get each sub-part working. When you have the complete "toolbox" then you can start to bolt the pieces together to form your overall solution.

 

Actually, the step before this is perhaps the most important one and has nothing to do with writing C/C++ code (directly). It's the point where you spend some time (differs according to complexity but could even be weeks or months!) actually DESIGNING the thing first. Almost every post we see on this board is because someone has thrown together some solution and then "organically grown" it to the point where the complexity has flawed things completely. The true engineering design process is to draw up requirements ("the device will show a voltage reading on an LCD") then to plan the implementation from the highest level "interrupt sampling ADC, main loop will display on LCD and also look for user input to change display format". In turn this leads to the fact that you are going to need modules for ADC, LDC and buttons. You then add increasing detail to this to say things like what mode the ADC will be run in (what reference and so on), will the LCD be 4 bit or 8 bit or perhaps even on an I2C link, how will the button reading work - direct polling of pins or (more likely) a time interrupt to sample the button states over time for debounce.

 

Continue in this vein - keep adding more detail. Over on the micro that you are now starting to run "prototype experiments on" first implement that UART menu then see if you can get it to trigger your ADC reading module and work on the detail of (guided in your implementation by the design specification)

 

The worst possible way to design embedded (or any other) software is to start your C editor and type:

int main(void) {
    ... ummm what do I put here??
}

Don't just make it up as you go along. Design it first then implement in a modular (and hence individually testable) fashion.

 

People these days marvel at "Arduino" because it's "so quick to implement a solution" but that works because it is just a "bolt together heavily tested modules". You can write your own C/C++ like this too. Also if you do it in a modular way then the next time you need UART or ADC or something you can probably re-use a lot of the uart.c/uart.h or adc.c/adc.h you already have.

 

In the "Agile" software development world a further trend is "unit testing". This is an additional step in the design process where you actually use the requirements to first define the tests that will prove that a module like ADC or UART or whatever is working. THEN you implement the UART/ADC/... module to deliver the interface that the test code will try to use and will check for correct operation.

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

clawson wrote:

int main(void) {
    ... ummm what do I put here??
}

 

Obviously:

 

int main(void) {
    setup();
    
    while (1) {
        loop();
    }
}

 

 

--Mike

 

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

Thanks for that clawson. What is the protocol here for making up a sticky? Is it ok form for me to collect the best of what everyone says and put it in the first message? Is that frowned upon here?

 

I think I was doing TDD before it was a thing - lol. Long before I retired, if you will from software the first time. When we were coding the OSI protocol stack back in the day, Stroustrup has just added templates and the internet was soon to be a thing.  Coding that stack properly there was no way that it was going to happen unless each and every part of it had test code written against it. 

 

I'm not sure what the ratio in the real world is today of test code to working code but I bet we were 70% test code, 30% working ratio. Nonetheless the code worked. I'm gazing lovingly at my bookshelf of a time gone by. Grady Booch,  Object Oriented Design, Stroustrup ARM, Design Patterns, UML and patterns, Algorithms, etc.

 

I would bet 95% of the people new to coding and design would come here with projects that are not engineered on paper as it were first - before they started. Paraphrasing you liberally, coding without a thought in the head. lol.

 

I'm nothing compared to all of you working chaps here but back in the day I could do a little coding..

 

Cheers,

Rod

 

 

 

 

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

“Without requirements or design, programming is the art of adding bugs to an empty text file.” - Louis Srygley

EDIT:  Hmm.  Seems I've mentioned it before ;-)

https://www.avrfreaks.net/comment/1628016#comment-1628016

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Sat. Jan 12, 2019 - 07:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avr-mike wrote:

Obviously:

 

int main(void) {
    setup();
    
    while (1) {
        loop();
    }
}

 

You're giving away our secrets.  We've been telling people that embedded programming is HARD.