Tips for learning avr programming

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

So its been few weeks since i started learning AVR programming.It has been a great pleasure to learn AVR programming. Although i've done Arduino before,AVR seems like a real thing.For atleast 1 more year i will stick to avr programming to gain some experience.I want to ask all the experienced people out there, what is the best way to learn avr as efficiently as possible(learning more in less time)? What are the mistakes i should avoid in long term while learning? How did your avr programming journey started ? Please give me some tips regarding the questions i've mentioned.Thanks!angel

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

I'm sure many people here could write a book on this topic.  I'll just give you two ideas that come to mind.

 

1) Learn how to use interrupts sooner rather than later, because you'll have to learn eventually.  That includes keeping your ISRs short and fast, and that includes learning how to share data between ISR and main code, without any possibility of the data being corrupted.

 

2) Use the right data type for each piece of data.  If your data can never go below zero, used unsigned, not signed.  If your data can fit in 8 bits, use e.g. uint8_t, not int (which is 16 bits).  And in most cases, you won't need floating point - judicious use of 16 or 32-bit integers will usually suffice, and result in code that is faster and shorter.

 

I have a little mantra:

 Don't use floating point if integers will do

 Don't use 32 bits if 16 bits will do

 Don't use 16 bits if 8 bits will do

 Don't use signed if unsigned will do

 

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

Don't use floating point if integers will do

 Don't use 32 bits if 16 bits will do

 Don't use 16 bits if 8 bits will do

 Don't use signed if unsigned will do

Will remember this! Appreciate your response!

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

Take some time to learn about SIMPLE state machine concepts...don't bother with complexity, just the bare bones state machines (if/then elif style)..you will find even the simplest style can be quite powerful & efficient  for logical program control.

A book on digital logic design (state machines) is a very good place to understand the underlying (non programming) concepts.  The processor makes it a lot easier that using a bunch of gates & flip-flops. 

 

Take some time to appreciate atomic operations (do a search)

If learning interrupts & high language, learn about volatile in C.

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

How did your avr programming journey started ?

It started with the Motorola 6800 in the mid 70s (then 6809, 6802, 6805) , followed by a lot of Signetic 2650, 8080, 8085, NSC800, 68HC11 and then AVR about 20+ years ago, it was a singe!

 

What I'm trying to say is don't get fixated on the chip itself, learn how to learn.

 

From the very early stages the old chips had "monitor programs", switching from that to an IDE was not a big deal around 30 years ago when I got a full development system for the 68HC11 (very primitive compared to Atmel Studio).

 

Learn how to debug, breakpoints, looking at memory locations and registers, single stepping code, all this stuff existed 40+ years ago, now it may look different but the principles are the same.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Do you suggest programming in assembly ? I do know some assembly language but only from the books. Never programmed a microcontroller with assembly.

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

Do you suggest programming in assembly ? I do know some assembly language but only from the books. Never programmed a microcontroller with assembly.

Of course you should do a little to get the feel of what goes on under the hood & to appreciate things the compiler has to deal with...but in reality you will probably be doing most work in C or some higher language; then many of the details are locked away.  If your program deal with hardware (rather than an AVR program to calculate square roots), then you will likely need to know more details about the chip specific peripherals, like ADC, timers, etc.  Even some of that might be hidden away with high level libraries or packages that you can use.

You turn on the TV, adjust the channel & volume & don't see what is going on inside there; just enjoy the show.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Rishi_kesh wrote:

Do you suggest programming in assembly ? I do know some assembly language but only from the books. Never programmed a microcontroller with assembly.

Perhaps a few simple learning programs, including timers and interrupts, but beyond that, no.  You should know enough assembly to understand the compiler output.

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

Rishi_kesh wrote:
what is the best way to learn avr as efficiently as possible(learning more in less time)?

Well it's all up to you. But first I'd say make your learning environment more supportive. Less distractive. Just so you don't burn out real fast. Like a good chair, so your body is at ease, helping you to read more, do more. Etc etc. Things like these are never really looked upon, but can make a tremendous difference in your learning ability.

 

Multi monitor setup. A second monitor is very helpful, if you don't have one.

You will be reading the datasheet a lot. A nice monitor with Adobe Acrobat Reader DC showing the MCU Datasheet is useful. With Adobe reader you can jump to sections quickly or even bookmark them. Pretty neat.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan

Last Edited: Sun. Aug 1, 2021 - 10:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I suggest getting a kit of common sensors like this one: https://www.ebay.com/itm/2317575...

Then, for each interesting sensor, download one or more of the Arduino libraries available for that sensor.  Study the source code.  Downloadable library code ranges from very simple to very complex.

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

 download one or more of the Arduino libraries available for that sensor.  Study the source code

 

I'd be careful not get too caught up in just "studying" code or using libraries, that can become a cut and paste dependency. 

Of course it is useful to glean a few ideas & tips.  It is good exercise to write code & persevere through the trials and tribulations. 

If you want to learn how to shoot pool, you need to actually shoot pool, not just watch someone else play pool.

Be careful you don't live on the sidelines.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Rishi_kesh wrote:
what is the best way to learn avr as efficiently as possible

The same way as you learn anything: start with the basics; build solid foundations; take one small step at a time; practice. Don't leap straight in to some over-complex project.

 

eg, see: https://www.avrfreaks.net/commen...

 

If you're planning on programming in C, then it's probably easiest (certainly more comfortable) to learn the C programming language on a PC - away from all the added complications & restrictions of a small embedded microcontroller.

Then, once you have an understanding of the language itself, you can move on to applying that on an AVR .

Again, it's about starting with basics, laying foundations, and then building on them.

 

Here are some C learning & reference materials - including a free online textbook:

 

https://blog.antronics.co.uk/201...

 

ADDENDUM

 

Typically, a project with a small microcontroller like an AVR is not just about "programming" - you will also have to deal with the external hardware around the microcontroller.

 

So you will also need at least a working understanding of electronics.

 

Take a look at Tip #6 in my signature, below:

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Aug 2, 2021 - 08:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you're planning on programming in ASM, then it's probably most uneasy at the beginning.

Later on, it will become the pleasure, for you will be the master-owner over each register and each bit of AVR.

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

grohote wrote:
you will be the master-owner over each register and each bit of AVR.

That is, indeed, both the blessing and the curse of writing in assembler

 

A blessing - because you have complete control, with nothing to get in your way;

 

A curse - because you have to do absolutely everything yourself in minute detail, there's nothing to hold your hand or do the "housekeeping" for you.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A blessing and a curse, how true.
Most of all, the burden, once taken you do not wish to reduce or release.

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


Rishi_kesh wrote:

Do you suggest programming in assembly ? I do know some assembly language but only from the books. Never programmed a microcontroller with assembly.

I'd approach that the other way round. Learn C first as it is generic and the control structures you learn there can be applied to any micro you later work on (though the specific of SFRs and control  bits will obviously differ). But what you can do is take a look at the Asm that the C compiler generates to slowly get familiar with the assembler language. This way you get to learn "read only" before you may later attempt to start to write some of your own.

 

For example, if you write:

 

then because  this option is usually on by default:

 

 

when you build it will create a listing file that has the C and Asm mixed:

 

 

and that file contains:

 

 

so here you get to learn a few of the AVR regularly used opcodes. For the C line:

DDRB = 0xFF;

you will see that the compiler generated:

LDI R24, 0xFF
OUT 0x04, R24

The first (as you'll read in the alphabetically listed: http://ww1.microchip.com/downloa... ) is "Load Immediate" and means load the value that is encoded in this very opcode (0xFF) into register 24. (as you'll see the C compiler is quite keen on using R24 out of the thirty registers R0..R31). The next opcode is OUT which is a write to memory but unlike the ST/STS opcodes (which you will likely also see in various C to Asm test) this writes to a special area of "RAM" that can be more quickly accessed using the OUT opcode. So it writes to location 0x04 in that memory space (which is actually location 0x24 in true RAM memory space - but that's something you would learn about later). That location happens to be where the direction registerfor port B (ie DDRB) is located.

 

Something very similar is done to write the 0xAA initial value to the PORTB location.

 

In the while() loop my main instruction is:

PORTB ^= 0xFF;

which is using C's exclusive-OR operation to mean "flip all the bits, 1's to 0's and 0's to 1's). The actual code generated for that is:

  82:	85 b1       	in	r24, 0x05	; 5
  84:	80 95       	com	r24
  86:	85 b9       	out	0x05, r24	; 5

This shows the RISC (Reduced Instruction Set) nature of the AVR CPU. It does not have a single opcode to say "invert all the bits at the location of the PORTB register". Instead it must break the operation down into smaller steps. So it starts with IN which is just the opposite of OUT and this time reads the value that is at location PORTB (0x04 in I/O space) into the register 24. It then executes the COM opcode which (again as the manual will tell you) is the COMplement bits operation. That does exactly what is required and just switches all the bits between 0's and 1's. So the value 0xAA will become the value 0x55. Finally the OUT operation writes it back.

 

Finally an RJMP (Relative jump) implements the while(1) loop. That means "go back and do it all over again". In this case it is "RJMP .-8" which means "go back 8 words". The disassembler that is used to show this Asm code has helpfully commented this to say that it will be jumping back to location "82:" which is the IN opcode. So it will repeatedly do the IN, COM, OUT, RJMP sequence for all eternity.

 

So, as you can see, it's easy to start to pick up a little AVR assembler by seeing what the C compiler comes up with for some simple C operations.

 

Another example might be:

 

This is an example to see how the compiler might handle simple addition of a 16 bit variable. A 16 bit variable can't be held in one (bye wide) location so it has to be split between two 8 bit registers. The compiler generates:

 

    while (1) {
        var = var + 5;
  8a:	80 91 00 01 	lds	r24, 0x0100	; 0x800100 <__DATA_REGION_ORIGIN__>
  8e:	90 91 01 01 	lds	r25, 0x0101	; 0x800101 <__DATA_REGION_ORIGIN__+0x1>
  92:	05 96       	adiw	r24, 0x05	; 5
  94:	90 93 01 01 	sts	0x0101, r25	; 0x800101 <__DATA_REGION_ORIGIN__+0x1>
  98:	80 93 00 01 	sts	0x0100, r24	; 0x800100 <__DATA_REGION_ORIGIN__>
  9c:	f6 cf       	rjmp	.-20     	; 0x8a <main>

Again the book will tell you that LDS is "Load from Storage" and will read a value from some memory location into a register. The location being read is 0x100 which is where the "var" variable has been placed in RAM. In fact, because it is 16 bits wide, it is location 0x100 and 0x101. But the AVR can only make 8 bit reads so it does two LDS to read locations 0x100 and 0x101. It reads the value into registers R25:R24 which make up a pair. R25 will be the "high byte" and R24 the low byte.

 

Because I am only adding 5 each time in the example the compiler can make use of the ADIW opcode which is a 16 bit wide ADD operation that works on some register pairs (either R24:R24, R27:R26, R29:R28 or R31:R30). In the Asm language that the C compiler happens to use (which is a bit different to the one documented in the opcode manual!) you just have to name the lower register of the pair. So in this case the opcode is "ADIW R24". That manual would have shown this as "ADIW R25:R24" in fact. There is a small argument to say that the Atmel Assembler is "better" in this case as it makes it clearer that there are two registers involved and which ones they are. The avr-as assembler that the avr-gcc compiler generates code for just uses one of the pair in the opcode.

 

After the addition two STS (Store to Storage) opcodes are used to write the modified R25:R24 value back to memory. Finally, like before, a single RJMP opcode makes this into a while(1) loop.

 

Now, because the ADIW opcode can only handle adding 0 to 63 if my addition were a larger value:

int main(void)
{
    while (1) {
        var = var + 123;
    }
}

The compiler would have to find some other way to do the addition:

int main(void)
{
    while (1) {
        var = var + 123;
  8a:	80 91 00 01 	lds	r24, 0x0100	; 0x800100 <__DATA_REGION_ORIGIN__>
  8e:	90 91 01 01 	lds	r25, 0x0101	; 0x800101 <__DATA_REGION_ORIGIN__+0x1>
  92:	85 58       	subi	r24, 0x85	; 133
  94:	9f 4f       	sbci	r25, 0xFF	; 255
  96:	90 93 01 01 	sts	0x0101, r25	; 0x800101 <__DATA_REGION_ORIGIN__+0x1>
  9a:	80 93 00 01 	sts	0x0100, r24	; 0x800100 <__DATA_REGION_ORIGIN__>
  9e:	f5 cf       	rjmp	.-22     	; 0x8a <main>

I'll bet that surprised you? One way it could have done this would have been something like:

    LDI R26, 123
    LDI R27 0
loop:
    LDS R24, 0x100
    LDS R25, 0x101
    ADD R24, R26
    ADC R25, R27
    STS 0x100, R24
    STS 0x101, R25
    RJMP loop

but this would use more registers. Because the 123 value is fixed at compile time it can just encode that into an opcode. So you might have hoped that instead of a ADD/ADC there might be ADDI/ADCI opcodes that allow 123 to be built into the actual opcode but if you scour through the AVR opcode manual you will not find an Immediate version of ADD/ADC but there are immediate versions of SUB/SUBC. So the compiler uses subtraction not addition to add 123. Now how do you do addition using a subtraction opcode? Well +123 is the same as -(-123). That is two minuses make a plus. So if you subtract negative 123 you actually add 123. 

 

Without going into a whole maths lesson about 2's complement numbers just take it as read that -123 is 0xFF85 (if you really want to know try 0xFF85 - 0x10000). So:

  92:	85 58       	subi	r24, 0x85	; 133
  94:	9f 4f       	sbci	r25, 0xFF	; 255

will actually add 123 to the value in the R25:R24 pair.

 

Oh and if you wonder about ADD/ADC or SUB/SUBC and why two different opcodes you once again have to remember that for the most part the AVR is limited to 8 bit operations (in fact ADIW is one of very few exceptions) so to do a 16 bit addition you actually need to add the lower digits, then if there is a carry, add the higher digits PLUS the carry bit. Think about decimal. If I asked you to do:

 17
+25
===

you would do that same thing. Add the 7 and 5. That comes to 12 so you write down 2 and carry 1. When you add the higher digits (1 + 2) you also add the carry so it's 1 + 2 + 1 (carried) so the complete some is 42. Well it's the same in binary addition. You add the low bytes and then add the high byte but also bringing in any CARRY. The AVR CPU has a bit in the SREG status register called the carry flag. So when ADD or SUB is performed if there is a carry that bit will be set. Then you can use ADC/SUBC to do the next addition but bring the generated carry (if any) into the further calculation.

 

Anyway, tat's maybe enough to give you a taste of how you can start to learn the Asm if you already know the C for any CPU. 

 

What's great with this (and I generally always use it if I move to working with some new CPU) is that the C code remains the same, but if I built this for PIC or MSP430 or 8051 or ARM or Intel x86 the actual Asm generated would be quite different. So I would be able to learn how the new CPU operates by looking at the generated Asm and reading its opcode manual.

 

What's more, with AVR you are really spoiled because in the Studio 7 IDE you even have a simulator and one you can switch between C and Asm mode as you are examining code. So you can not only get to see the Asm generated but you can then step the program one opcode at a time and see what affect it is having in the registers, the flags and in memory:

 

 

In this I have already let two lots of +123 (ie -(-123)) happen so the variable at 0x100/0x101 in the memory window currently holds 0x00F6 (that is 246) but the yellow arrow in the disassembly shows I have now stepped just the SUBI but not the SBCI of the next +123 step. In this case the processor status shows the C bit in SREG has been cleared so when I then step over the SBCI :

 

 

So the combined value in R25:R24 is now 0x0171 (369 which is three lots of 123). If I now continue to let the two STS happen the 0x00F6 in locations 0x100, 0x101 now becomes:

 

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

Rishi_kesh wrote:
Although i've done Arduino before, AVR seems like a real thing

You do realise that the microcontroller in the most common Arduino boards is an AVR ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One very important concept, is that most languages are not exactly like algebra

 

say B=20 & C =5 

then you do 

A = B + 3 * C

 

Ok , A must be  35, right?  very good!!

 

Now B become 23 ,so now what is A?

easy, A is 38 , right? 

WRONG (in a  terminator voice) !!

A is 35, still

 

This trips up countless students!

 

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

avrcandies wrote:
WRONG (in a  terminator voice) !!

 

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan

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

Before getting into the details about the advantages of one type of programming versus another (such as C vs. assembler), you should ask more general questions:

      What am I going to do with my microcontroller skills?  

      Am I going to use it primarily as a hobby? 

      Will I be using my designs and projects on "around-the-house" things? 

 

  Or,

      Will I be designing items that will be offered for sale? 

      In what quantities?  Will I eventually be making ten or so units of each my complex AVR designs, or 10,000 units of the best design? 

 

  The one question that is the most important:

      Am I going to be paid for the microcontroller work that I do?

      If so, then by who?, how much?, and how often (i.e. is this a real job, or a one-time, one-payment contract?)

      Is this going to be my primary source of income for supporting a family?

 

Generally, in the 21st century, [or -now- ]  vs. the 20th century (where everyone who will be giving advice on this site learned and earned):

 

     If you want to do one-off cool-and-interesting projects, then master a single microcontroller family like the AVR.  Become an expert on all of it.  Learn to read 300-page datasheets like they were comic books. But don't expect to make much money at it.   There are a million other AVR experts who can and will do the project for cheaper because they can live in a cheaper part of the world and can export their finished code to anywhere in the world through the web and get paid through PayPal.

 

    If you want to get paid and paid regularly, don't master a single microcontroller.  Instead master a Hardware Abstraction Language like Arduino.  That way you can go from one microcontroller family to another according to your client's requirements.   So you can use an AVRtiny on one job, a 32-bit WiFi CPU like ESP32 a month later, and an ARM with Digital Signal Processing for the next client.   Work fast, work dense, work cheap... it's the only way to be a microcontroller designer in a modern global marketplace.

 

Last Edited: Mon. Aug 2, 2021 - 03:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if we collect and print all the contents of this Forum, that will be a Book to create virtually anything ^ ^

work in progress...

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

Simonetta wrote:
a Hardware Abstraction Language (sic?)  like Arduino. 

But Arduino isn't a language - is it?

 

The language is just C++

 

So, yes: learn a portable language like C or C++; understand the principles of how microcontrollers work in general - a CPU; RAM and ROM; Special Function Registers (SFRs) providing access to peripherals; etc, etc ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 So you can use an AVRtiny on one job, a 32-bit WiFi CPU like ESP32 a month later, and an ARM with Digital Signal Processing for the next client

That's good advice---there is a wide variety to apply to varied projects, and the floodgate of new devices keeps growing. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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



But Arduino isn't a language - is it?

No, it's an old Italian family name cheeky

 

Also an expensive coffee machine that doesn't have any Arduinos in it.

 

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Since you know some Arduino stuff, and want to learn AVR, one possibility is to examine and modify the "Arduino Core" source code.
For example:

 

  1. digitalWrite() has a reputation of being very slow.  Why?  Can you make it faster?  There are various faster implementations; how do they work?  What do they give up?
  2. The UART interrupt code is pretty sucky too.  How do you improve that?
  3. Instead of starting an ADC conversion each time someone calls analogRead(), modify the core to sample continuously at a configurable rate, and return the "most recent" value immediately.
  4. There are over 200 open "issues" described at https://github.com/arduino/Ardui... What are they talking about?  Can you fix any of them?  (Whether the fix is "good enough" to be incorporated into the actual Arduino core is a separate question, that you need not worry about.)
  5. What changed in between the official Arduino core. and, say, the megaTinyCore or miniCore?  Can you write a new core (or any part of a new core) for some processor that doesn't have one yet?  (say, the 8u2 and 16u2, which are pretty obscure and mostly only recognized as usb/serial converters.)

 

It's sort-of key to find projects that are hard enough to stretch your knowledge without being "impossible."

 

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

awneil wrote:
Don't leap straight in to some over-complex project.

westfw wrote:
It's sort-of key to find projects that are hard enough to stretch your knowledge without being "impossible."

Indeed.

 

To be fair, it can be hard for a beginner to gauge what constitutes an "over-complex" or "impossible" project - often, what seems "simple" from the outside is actually complex on the inside.

 

USB is a case in point.

 

As the old saying goes, "it takes a great deal of effort to make something appear effortless".

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I'd probably walk round the AVR peripherals and do some kind of projects that make use of each one individually (I2C, SPI, UART, timers, ADC etc) then start to see if you can combine the knowledge by putting some of the things together. So reporting ADC values over the UART and so on. Just keep building up the complexity from there.

 

For each one I'd start by learning to use it in polled mode. but as mentioned above it's important to understand interrupts as soon as you can can. So once you have something worked in synchronous/polled mode then trade up to doing it asynchronously with interrupts.

 

(oh, and if you don't know what words like polled, synchronous, asynchronous mean then that might be a good pace to start doing some Google research to learn those fundamental concepts).

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

clawson wrote:
I'd probably walk round the AVR peripherals and do some kind of projects that make use of each one individually (I2C, SPI, UART, timers, ADC etc)

+1

 

I'd suggest:

 

GPIO first - blink some LEDs

 

UART next - because it can connect straight to a PC, with no other equipment required (other than a USB-to-UART converter) and because its invaluable for debug & testing in everything you do next

 

Also, get one of the XPlained or Curiosity boards with built-in debugger (and USB-to-UART) and practice using the debugger.

 

See: https://www.avrfreaks.net/commen...

 

Example: https://www.avrfreaks.net/forum/xplained-mini-mega328pb

 

For getting started with SPI and I2C, you'll need something to talk to; here's some useful starter boards:

 

https://www.avrfreaks.net/commen...

 

 

EDIT

 

As suggested in #20 - #23, this can be a good general approach - not just limited to AVR ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Aug 4, 2021 - 10:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


There's actually an argument for doing (polled) UART first because that allows you to implement some kind of "monitor" so you can then interact wit the following experiments on the other peripherals (and it can also act as the debug back channel if you don't have an ICE).

 

I often think that some of those Arduino peripheral kits you can get on Amazon/eBay/Banngood/AliExpress from the likes of EleGoo are a pretty good idea so you not only get to "play" with peripherals inside the AVR but to attach a whole bunch of external peripherals and learn about those too.

 

This kind of thing:

 

https://www.amazon.co.uk/ELEGOO-...

 

 

But I'd learn the internal peripherals first (in fact you kind of have to as you may need I2C and SPi (especially) to connect to many of these - of course they also give you "something to talk to" when actually starting with SPI/I2C too).

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

clawson wrote:
There's actually an argument for doing (polled) UART first because that allows you to implement some kind of "monitor"

Indeed.  Although I'd still suggest that blinking an LED comes before that.

 

EDIT: in fact, you'll need that to be sure you get the baud rate right - as noted in both of our signatures

 

Quote:
learn the internal peripherals first (in fact you kind of have to

Absolutely.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Aug 4, 2021 - 10:20 AM