SPI interrupt code

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

Hi guys I am trying to learn the SPI interrupt coding between ATMEGA328P (master) and ATMEGA2650 (slave). 

I did refer to various tutorials but I could not establish a communication between the 2 MCUs.

Attached are my codes.  Appreciate if you could give me some hints.  Thank you Sirs.

//SPI Interrupt code for the master ATMEGA328P

#include <avr/io.h>
#define F_CPU 1000000
#include <util/delay.h>
#include <avr/interrupt.h>


void SPIinit()
{
    SPCR=(1<<SPE)|(1<<MSTR)|(1<<SPR0)|(1<<SPIE);
    sei();
}

int main(void)
{
    DDRB=0x2C;				//set MOSI, SCK and SS as output 
    PORTB|=(1<<2);				//set SS High
    DDRC=0x00;                      //set as input
    
    SPIinit();
    
    while (1)
    {
    }
}

ISR(SPI_STC_vect)
{
    {
        if(PINB&(1<<0))
        {
            (SPDR=(0xFF));		
        }
        else
        {
            (SPDR=(0x00));
        }
    }
    
    {
        if(PINC&(1<<4))
        {
            (SPDR=(0xF8));		
        }
        else
        {
            (SPDR=(0x07));
        }
    }
}



//SPI Interrupt code for the slave ATMEGA2560

#include <avr/io.h>
#define F_CPU 16000000
#include <util/delay.h>
#include <avr/interrupt.h>

void SPIinit()
{
    SPCR=(1<<SPE)|(1<<SPIE);
    sei();
}

int main(void)
{
    DDRB=0xF8;					//set as output MISO, PB6 and PB7
    SPIinit();
    
    while (1)
    {
    }
}

ISR(SPI_STC_vect)
{
    {
        if (SPDR==(0xFF))
        {
            PORTB|=(1<<6);
            PORTB&=~(1<<7);
        }
        else if (SPDR==(0x00))
        {
            PORTB&=~(1<<6);
            PORTB|=(1<<7);
        }
    }
    {
        if (SPDR==(0xF8))
        {
            PORTB|=(1<<5);
            PORTB&=~(1<<4);
        }
        else if (SPDR==(0x07))
        {
            PORTB&=~(1<<5);
            PORTB|=(1<<4);
        }
    }
}

 

 

 

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

Slave select is an important feature. You seem to have neglected it.

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

Kartman wrote:

Slave select is an important feature. You seem to have neglected it.

 

I connected the slave SS to GND.  When I use polling mode for both master and slave it's working.  Not sure what is wrong with the interrupt code.

Also I have a question is it possible to use interrupt code for the master and polling for the slave?

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

It is working by pure luck then. SS is used to synchronise both sides.

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

Kartman wrote:

It is working by pure luck then. SS is used to synchronise both sides.

I read several tutorials where most slave SS lines were just directly connected to GND while master SS is set to output. Why are the 2 MCUs not communicating if I do it this way?
Also what is your recommendation? Tie the SS together? Then how to configure SS of both sides?

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

ryan2019 wrote:
I read several tutorials where most slave SS lines were just directly connected to GND
Can you give links to those so we can build a list here of "total crap found on the internet" ?

 

There's only one real way to use SS. The master should have one SS line for every SPI device it is connected to. It pulls it low when it intends to communicate with a particular device. It sets it high again when it is finished. It is the high low transition seen by the slave that causes it to resynchronize its clock. Apart from anything else this prevents problems where noise has missed or crates glitches, read as spurious clock pulses, on SCK.

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

clawson wrote:

ryan2019 wrote:
I read several tutorials where most slave SS lines were just directly connected to GND
Can you give links to those so we can build a list here of "total crap found on the internet" ?

 

There's only one real way to use SS. The master should have one SS line for every SPI device it is connected to. It pulls it low when it intends to communicate with a particular device. It sets it high again when it is finished. It is the high low transition seen by the slave that causes it to resynchronize its clock. Apart from anything else this prevents problems where noise has missed or crates glitches, read as spurious clock pulses, on SCK.

So I just need to connect SS from both sides and that's it? I suppose the codes are fine. I will try this later. Thank you Sir.

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

ryan2019 wrote:
I am trying to learn the SPI ... establish a communication between the 2 MCUs.

Never start by trying to do both ends of the link - any link - at once!

 

The trouble with that is that you have no way to tell whether problems are at the Master end, or the Slave end - or both!

 

So always start with just one end of the link - and use a known-good reference at the other.

 

With SPI (and I2C), by far the commonest use case is for the microcontroller to be the Master - so I would strongly suggest that you start by developing your master code first, using some standard, well-known slave(s).

 

eg:  https://www.avrfreaks.net/comment/2282151#comment-2282151

 

So first get your Master working and thoroughly tested & debugged.

 

As well as just getting the code to work, you should practice using debug & test tools - you should know what "good" signals look like on the line.

 

And don't just concentrate on the "working" case - investigate what happens in common failure cases; eg,

  • No slave connected;
  • Wrong slave connected;
  • clock line disconnected;
  • 1 or more data lines disconnected;
  • etc, etc, ...

 

Think about how you can detect these conditions in your code, and give useful & meaningful error indications.

 

Then, when you have a good, solid, working Master implementation - try making a slave for it to talk to...

 

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

 

#OneEndAtATime

 

#DevelopingComms

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: Fri. Jan 31, 2020 - 10:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

ryan2019 wrote:
I am trying to learn the SPI ... establish a communication between the 2 MCUs.

Never start by trying to do both ends of the link - any link - at once!

 

The trouble with that is that you have no way to tell whether problems are at the Master end, or the Slave end - or both!

 

So always start with just one end of the link - and use a known-good reference at the other.

 

With SPI (and I2C), by far the commonest use case is for the microcontroller to be the Master - so I would strongly suggest that you start by developing your master code first, using some standard, well-known slave(s).

 

eg:  https://www.avrfreaks.net/comment/2282151#comment-2282151

 

So first get your Master working and thoroughly tested & debugged.

 

As well as just getting the code to work, you should practice using debug & test tools - you should know what "good" signals look like on the line.

 

And don't just concentrate on the "working" case - investigate what happens in common failure cases; eg,

  • No slave connected;
  • Wrong slave connected;
  • clock line disconnected;
  • 1 or more data lines disconnected;
  • etc, etc, ...

 

Think about how you can detect these conditions in your code, and give useful & meaningful error indications.

 

Then, when you have a good, solid, working Master implementation - try making a slave for it to talk to...

 

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

 

#OneEndAtATime

 

#DevelopingComms

Thano you for the very good tip. Would that mean I cam use interrupt for the master and polling for the slave?

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

Please don't block-quote the entire post like that - it just clogs the thread with unnecessary repetition.

 

See this tutorial on how to do replies in the forum: https://www.avrfreaks.net/forum/...

 

EDIT - Oops, hit the wrong button!

 

ryan2019 wrote:
Would that mean I cam use interrupt for the master and polling for the slave?

 

It's entirely unrelated but, yes - of course you can do that.

 

 

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: Fri. Jan 31, 2020 - 11:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

BTW just to make the observation that while a slave might well use an ISR for SPI (because it might be busy with other stuff when the master starts to communicate) a master would almost never use it - SPI is so quick that you can be ready to send the next byte in a tight sending loop faster than it takes to get through the overhead of entering an ISR.

 

I very much agree with Andy though - don't try and develop SPI (or any two station comms) working on both ends at the same time. I'd start with the master and some well known SPI device (maybe an SPI flash/eeprom or how bout and RTC?) and develop master code to communicate with that. When that works you know the master code is complete, tested and fully reliable. Now you can begin to work on the slave knowing that any problems from this point on can only be in the slave code.

 

if you work on both at the same time there are "too many unknowns" - of something doesn't work you can't tell which end is at fault (and worse it could be both but you don't realise)

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

 

clawson wrote:
I'd start with ...  some well known SPI device (maybe an SPI flash/eeprom or how bout and RTC?)

Indeed - the board I suggested includes both of those!

 

laugh

 

 

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

 

@ryan2019 and this is not just some airy-fairy theory; I recommend that board because I do have one (and the I2C version) and it is exactly what I do use whenever I am getting started with the SPI (or I2C) on an unfamiliar target!

 

 

EDIT

 

Sorry, it has no RTC !

 

blush

 

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: Fri. Jan 31, 2020 - 11:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

It's entirely unrelated but, yes - of course you can do that.

 

 

 

Thank you for the tip.

I was able to make the slave interrupt work.  However the master is not working.   

Do you see what is wrong with the code?


//master spi interrupt code

#include <avr/io.h>
#define F_CPU 1000000
#include <util/delay.h>
#include <avr/interrupt.h>


void SPIinit()
{
	SPCR=(1<<SPIE)|(1<<SPE)|(1<<MSTR)|(1<<SPR0);
	sei();
}


int main(void)
{
	DDRB=0x2C;						//set MOSI, SCK and SS as output 
	DDRC=0x00;                      //set as input
	
	SPIinit();
	
	while (1)
	{
	}
}

ISR(SPI_STC_vect)
{
	{
		if(PINB&(1<<0))
		{
			SPDR=(0xFF);			
		}
		else
		{
			SPDR=(0x00);
		}
	}
	
	{
		if(PINC&(1<<4))
		{
			SPDR=(0xF8);			
		}
		else
		{
			SPDR=(0x07);
		}
	}
}

 

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

ryan2019 wrote:
the master is  not working.   

What, exactly, do you mean by that?

 

  • What did you intend it to do ?
  • What is it actually doing ?
  • What investigation / testing / debugging have you done to account for the difference ?

 

And, of course, how do you know that the problem is (just) in the Master ?

 

Also, take a look at this tutorial on how to reply in the forum - including doing quotes:

 

https://www.avrfreaks.net/forum/...

 

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: Fri. Jan 31, 2020 - 03:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

What, exactly, do you mean by that?

 

  • What did you intend it to do ?
  • What is it actually doing ?
  • What investigation / testing / debugging have you done to account for the difference ?

 

And, of course, how do you know that the problem is (just) in the Master ?

 

 

 

Sorry I did no make a clear statement.  Basically what I am trying to do is to connect 2 MCUs using SPI link.  Master is the ATMega328P and slave is ATMega2560.

I will toggle pins from the master MCU and the slave MCU shall respond by enabling its output ports.  In this code, master MCU pins PB0 and PC4 shall enable slave MCU ports PB6, PB7, PB4 and PB5.

Initially I did the polling code and both are working fine.  Then next is I replaced the slave polling code with the interrupt code and still working fine.  I checked the clock signals and the data lines.  However when I replace the master polling code with the interrupt code I do not see any clock signals anymore and the slave outputs do not respond when I toggle the master MCU pins.  This is the way I know the master interrupt code is not working.

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

Since it takes so little time to send 8 bits, why have the overhead of an ISR for this simple function?

Jim

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

again, please see the tutorial on how to do replies in the forum.

 

It's hard to follow when you just copy & paste stuff - there's no distinction between the copied text, and your text.

 

ryan2019 wrote:
when I replace the master polling code with the interrupt code I do not see any clock signals anymore

 

So what  investigation / testing / debugging have you done to  find out why that happens ?

 

Have you looked at examples?

 

Have you studied the datasheet & application notes?

 

EDIT

 

Hint: think about what causes the clock to be generated.

 

Where, in your code, do you do anything that would causes a clock to be generated ... ?

 

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: Fri. Jan 31, 2020 - 03:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

Since it takes so little time to send 8 bits, why have the overhead of an ISR for this simple function?

Jim

 

Yes this is a simple function but my intention is to learn interrupt for SPI.  

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

ryan2019 wrote:
interrupt for SPI.  

Are you already familiar with interrupts in general?

 

And SPI in general ?

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

Are you already familiar with interrupts in general?

 

And SPI in general ?

Yes in general though I am just starting with SPI.
Still trying to figure out what went wrong on the master interrupt code. Thanks for all the hints I will read more samples.

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

ryan2019 wrote:
Thanks for all the hints 

 

Apply the hints to the code you posted:

 

I wrote:
think about what causes the clock to be generated.

 

Where, in your code, do you do anything that would cause a clock to be generated ... ?

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

ryan2019 wrote:
Do you see what is wrong with the code?

Yes, you have a SPI Serial Transfer Complete ISR(), but you never initially send anything out the SPI, so the interrupt never happens.

Once you send the first byte, then the rest will happen after the byte is sent as that will trigger another send....

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

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

I wrote:

where, in your code, do you do anything that would cause a clock to be generated ... ?

 

ki0bk wrote:
you never initially send anything out the SPI

 

That!

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

ki0bk wrote:

ryan2019 wrote:
Do you see what is wrong with the code?

Yes, you have a SPI Serial Transfer Complete ISR(), but you never initially send anything out the SPI, so the interrupt never happens.

Once you send the first byte, then the rest will happen after the byte is sent as that will trigger another send....

 

Jim

 

 

Thank you for the hint.  I tried putting the data on the main loop.  I see some outputs now however it does not react according to the input.

Like for this instance the output would only react on PINB input.  The PINC input does not give me any output at all.  What could be the problem?

//Master interrupt code

#include <avr/io.h>
#define F_CPU 1000000
#include <util/delay.h>
#include <avr/interrupt.h>

volatile data;

void SPIinit()
{
    SPCR=(1<<SPIE)|(1<<SPE)|(1<<MSTR)|(1<<SPR0);
    sei();
}


int main(void)
{
    DDRB=0x2C;						//set MOSI, SCK and SS as output (1<<3)|(1<<5)|(1<<2)
    DDRC=0x00;

    SPIinit();
    
    while (1)
    {
        SPDR=data;	
    }
}

ISR(SPI_STC_vect)
{	
    {
        if(PINB&(1<<0))
        {
            
            SPDR=(0xFF);		
        }
        
        else
        {
        
            SPDR=(0x00);
        }
    }
    
    {
        if(PINC&(1<<4))
        {
            
            SPDR=(0xF8);			
        }
        else
        {
            
            SPDR=(0x07);
        }
    }
    
    
    
}

 

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

ryan2019 wrote:
I tried putting the data on the main loop.

You seem to be just randomly throwing 'C' statements into your editor, instead of thinking about how this works and what you need to do, and designing your code accordingly.

 

 

    while (1)
    {
        SPDR=data;
    }

Read the datasheet description of how the SPI works

  • What happens when you write to SPRD ?
  • When does the interrupt occur ?
  • Your code simply re-writes the value of data into SPRD immediately, again and again - is that going to work ... ?

 

Again, this is all very well-worn stuff; it is explained in the datasheet, and there are plenty of examples, application notes, etc to illustrate it

 

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

 

Read the datasheet description of how the SPI works

  • What happens when you write to SPRD ?
  • When does the interrupt occur ?
  • Your code simply re-writes the value of data into SPRD immediately, again and again - is that going to work ... ?

 

Again, this is all very well-worn stuff; it is explained in the datasheet, and there are plenty of examples, application notes, etc to illustrate it

 

 

Do you have sample codes that I can refer to?

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

Spi is dead simple - read the datasheet carefully and you too will come to this conclusion. The code is basically two lines.

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

You need to read that tutorial on posting replies again!

 

 

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

ryan2019 wrote:
Do you have sample codes that I can refer to?

Go on - there are code examples in the datasheet itself!

 

Again, have you actually studied the datasheet ?

 

Have you looked at the Application Notes ?

 

Go to the Product Page for the chip:

 

https://www.microchip.com/wwwproducts/en/ATmega328p

 

On the 'Documents' tab, you will find the datasheet, Application Notes, etc, etc

 

 

EDIT

 

You said in #3 that you had polling working.

 

The basic operation with the interrupt is no different - so you should be able to answer the questions!

 

EDIT 2

 

How To Find The Product Page: https://www.avrfreaks.net/commen...

 

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. Feb 3, 2020 - 03:02 PM