AVR SPI without the ASF files

Go To Last Post
54 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all,

 

I am trying to interface a sensor with AVR controllers through SPI. AVR is new for me and when I looked into the API  it its confusing with the ASF files . It has drivers, then services ,then configuration files and then the examples given. IS it better to understand those files or start writing my own code from setting up the SPCR register ?

 

Thanks

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

Forget ASF.

 

Read the datasheet for your processor. Lots easier that way.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

SPI.h

 

// SPI driver header file

#include <avr/io.h>

void spi_write(uint8_t temp);
void spi_init (void);

SPI.c with some settings for 14.7456 MHz crystal

 

// SPI driver

#include "spi.h"

void spi_write (uint8_t temp)
{
	SPDR = temp;
	while(!(SPSR & (1<<SPIF)));
}

void spi_init (void)
{
//Set up SPI, MSB first, Master, mode 0, clock fck/128 115K@14.7456 MHz
//	SPCR |= (1<<SPE | 1<<MSTR | 1<<SPR1 | 1<<SPR0);

//Set up SPI, MSB first, Master, mode 0, clock fck/16 922K@14.7456 MHz
//	SPCR |= (1<<SPE | 1<<MSTR | 1<<SPR0); OK

//Set up SPI, MSB first, Master, mode 0, clock fck/8 1.843MHz@14.7456 MHz
//	SPCR |= (1<<SPE | 1<<MSTR | 1<<SPR0);
//	SPSR |= (1<<SPI2X);

//Set up SPI, MSB first, Master, mode 0, clock fck/4 3.68MHz@14.7456 MHz
//	SPCR |= (1<<SPE | 1<<MSTR ); OK

//Set up SPI, MSB first, Master, mode 0, clock fck/2 7.3728MHz@14.7456 MHz
	SPCR |= (1<<SPE | 1<<MSTR);
	SPSR |= (1<<SPI2X);

}

you can simply turn the spi_write into a read/write routine by adding a line to return SPDR. Remember that in order to read the SPI you MUST send something out (garbage usually 0xFF)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Fri. Jun 23, 2017 - 02:33 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks a lot !! It is now clear :) is it necessary to write interrupts /ISR , for write and read operation? As the sensor is programmable, first I just want to write and read a simple data to it. Just to establish communication.

Last Edited: Fri. Jun 23, 2017 - 08:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SPI is possibly the easiest thing an AVR can do. On the whole there's no point introducing the complexity of interrupts or anything like that. Just a short function to configure it then an equally simple function to send and receive a byte and that's it.

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

Okay. That is really a good news for me. http://www.robotshop.com/media/f... this is my data sheet.  According to it clock spped is 16 Mhz? or is this the highest setting possible ?



//Set up SPI, MSB first, Master, mode 0, clock fck/2 8Mhz@16 MHz
	SPCR |= (1<<SPE | 1<<MSTR);
	SPSR |= (1<<SPI2X);
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's an Arduino so, yes, it will have a 16MHz crystal and will be running at that speed. 

 

BTW is it really necessary to communicate at 8MHz? Can you really process data that quickly? 

Last Edited: Fri. Jun 23, 2017 - 02:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My code :

 

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

void spi_master_int (void)
{

	DDRB = (1<<2) | (1<<1);  //PB2=MOSI ,PB1=SCK as output
	SPCR = (1<<SPE)| (1<<MSTR) | (1<<CPHA) ; //spi enabled master mode, spi_mode 1,prescalar :fosc/4, MSB first

 }

char spi_send (char r_data)
{
	SPDR = r_data;
	while(!(SPSR & (1<<SPIF) ));
	return (SPDR);
}

int main(void)
{
    spi_master_int();

    //while (1)
    {
		spi_send(0x01); //power on
		spi_send(0x11); //write opcode
		spi_send(0x54);// address to be written
		spi_send(0xBA); // data to be writtten
		_delay_ms(100);
		spi_send(0x21); // read opcode
		spi_send(0x54); // from  address to be read
		char result = spi_send(0xFF); returning the read value

    }
}

 

I simply read and write so i thought data processing is  possble. The sensor freq was 20mhz. My boards is Atmega256 ,not arduino .

 

Datasheet here : http://www.atmel.com/Images/Atme...

I have ICE debugger.

 

Is my pogram right ? bcos the JTAG debugger says:  result    Unable to evaluate the expression.     

 

I just changed cpu to 1 Mhz, but no luck!

Last Edited: Fri. Jun 23, 2017 - 02:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pika wrote:
#define F_CPU 1000000UL
Defining the F_CPU does NOT change the uC clock frequency. The frequency is determined by fuses including both clock source (CKSEL bits) and initial prescale divisor (CKDIV8)  and whether the prescaler select bits have modified that initial prescale setting (CLKPS bits in CLKPR) as well as the crystal (if the fuses select it).

David (aka frog_jr)

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

so , #define F_CPU 1000000UL can be #define F_CPU 16000000UL . Am I right ? But I do not see any values in the debugger.

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

pika wrote:
But I do not see any values in the debugger.
Make 'result' a global (and perhaps even volatile) variable.

Stefan Ernst

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

I haven't seen what sensor you are trying to access mentioned... What is it?

Does it require a chip select to be accessed?

 

Edit: typo

David (aka frog_jr)

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

sternst wrote:
Make 'result' a global (and perhaps even volatile) variable.

 

Thanks a lot, it is executing but it says nothing other than 0x00. Just  a basic doubt, How is MISO working here. I understand that its pin value is 0,hence its input. So, I read value only from the SPDR? Is there no connections of MISO here?

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

BTW: You must make SS an output.

Stefan Ernst

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

Hello,
I tried it..but nothing's changed. I have attached the sensor datasheet. Kindly look at it.

Attachment(s): 

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

pika wrote:
Is my pogram right ? bcos the JTAG debugger says: result Unable to evaluate the expression.
The reason for that is that nothing uses "result" after your line:

	char result = spi_send(0xFF); returning the read value

so the compiler won't create the variable (there's no point). If you want to say to the compiler " but this variable MUST exist" then the word is "volatile":

	volatile char result = spi_send(0xFF); returning the read value

Now you should be able to examine "result" in the JTAG debugger.

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

I am sorry that I did not mention it .I changed to volatile. It is able to evaluate but it says only zero. I want to read my wriiten value. If you just look at  pg.64, there is a flow chart for communication test,i just tried it. BTW ofcourse I changed the OPCODES accordingly. Pg 40.,there is a simple I2C test, I am trying exactly the same with same opcodes on SPI interface.

 

0x90  -writing

0x47 -address

0xFF -data

and so on..

 

EDIT:flowchart pg:74

Last Edited: Mon. Jun 26, 2017 - 10:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all,

 

my code still - does not work. During the debugging of the code, the values I send here :

 

char spi_send (char r_data)
{
	SPDR = r_data;
	while(!(SPSR & (1<<SPIF) ));
	return (SPDR);
}

that is the values passed to r_data is not put in the SPDR register. What could be the reason. ?

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

pika wrote:
During the debugging of the code, the values I send here

that is the values passed to r_data is not put in the SPDR register.

Never tried it (no Atmel-Studio installed), but I would guess that you never see in the debugger what was written to SPDR. It shows you what you would read from it, which is not what was written to it, but what was received last. Very likely you are barking up the wrong tree.

Stefan Ernst

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

sternst wrote:
It shows you what you would read from it, which is not what was written to it, but what was received last. Very likely you are barking up the wrong tree.

 

so how can I debug the code? I mean there is no reply from the sensor, so what can I do in this case. Could someone suggest me anyother sensor which I can work with using SPI interface - with commands  It would be really very helpful

 

 

 

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

pika wrote:
Could someone suggest me anyother sensor
Very likely your software is the problem, not the sensor. You never showed us the current (the modified) code.

Is SS an output now?

Is there a proper CS handling now?

 

Stefan Ernst

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

Best debugging tool for SPI in my opinion is a DSO or Logic Analyser. Watch the wires - faults will very quickly become apparent.

 

(the software side of SPI (apart maybe from the CPOL/CPHA selection) is so trivial it is difficult to get that bit wrong)

 

((oh except for the SS thing Stefan mentions - that's the common "gotcha"))

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

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

volatile char result ;
void spi_master_int (void)
{

	DDRB = 0x07 ;  //PB2=MOSI ,PB1=SCK as output ,PB0 =SS as output
	SPCR = SPCR = (1<<SPE) | (1<<MSTR) | (1<<CPHA) ; //spi enabled master mode, spi_mode 1,prescalar :fosc/16

 }

int main(void)
{
    spi_master_int();

   while (1)
    {
		//spi_send(0x7E);
		spi_send(0xA1);
		spi_send(0x47);
		spi_send(0xBA);
		spi_send(0x21);
		spi_send(0x47);
		result = spi_send(0xFF);

    }
}

my spi.h file:

 


void spi_master_int (void);
uint8_t spi_send (uint8_t r_data);

uint8_t spi_send (uint8_t r_data)
{

	SPDR = r_data;
	while(!(SPSR & (0x80) ))
	{};
	return (SPDR);
}

These are the modified codes. And what is the difference between CS and SS ? is both not the same?

 

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

Still no CS handling whatsoever. No wonder you don't get any data from the sensor if you never select it.

pika wrote:
And what is the difference between CS and SS ?
SS is the pin at the master, CS at the slave (can be called differently, eg. CE, EN, SEL, ...).

Stefan Ernst

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

If you have connected the SS from the uC to the sensor SSN, there is no control of the SS signal in the above code.

David (aka frog_jr)

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

It's called SSN, and is active low according to the DS.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
DDRB = 0x07

According to the data sheet , if i set the directon pin as 1,it is output, that is my PORT B's last pin is SS.

PB0= 1 // SS

PB1=1  // SCK and so on.

 

If you have connected the SS from the uC to the sensor SSN, there is no control of the SS signal in the above code.

Yes the controller is connected to the SS of the slave. What should I do to control/select it?

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

Page 2-17 of your data says the signal called "SSN_PG0" is active low. So you should get the AVR (driving out through its SS pin that then connects to SSN_PG0) to take that GPIO line low just before you start to communicate and then high afterwards.

 

It serves two purposes.

 

1) When not selected the device should relinquish lines it may be controlling - this allows the AVR to operate more than one SPI device if necessary.

 

2) The act of selecting the device (signal goes low) causes the device to reset its internal SPI shift register. So if it missed any clock pulse (or saw some glitch as an extra one) this gives it the chance to get back into line with the AVR.

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

I am very sorry that I have attached a different datasheet . My apologies. But the pins and config was all same.I just noted it when clawson told me the pg number. I am really sorry

 

http://www.atmel.com/Images/Atme...

 

This is my datasheet.

 

In this Pg:365,the SS pin can be configured as  input or I really I dont understand how should I control it ? As I did not use interrupt or used the SPIE register.

 

 

I feel bad for making such a trouble for the easiest interface. :(

Last Edited: Fri. Jun 30, 2017 - 02:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So you are talking about one AVR talking to another AVR using SPI? yet the thread started with

pika wrote:
I am trying to interface a sensor with AVR controllers through SPI.
Which of the two AVRs here is the "sensor" ?

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

NO NO ...Its between sensor (datasheet from post number: 15) and the AVR. The mistake is the datasheet of AVR was interchanged. This is trhe right one :

http://www.atmel.com/Images/Atme...

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

The SS pin is NOT controlled by the AVR SPI hardware, you have to manipulate it yourself.

Set SS high when not doing SPI, set low just prior to SPI read/write, set high again after read/write completes for each SPI access (although some slave devices can operate with SS always low).

David (aka frog_jr)

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

Thanks for the clarity. But My second value doesnot go into the bus at all. . . . I am not sure if this is a good/bad

question

 

 void spi_select()
{
	DDRB = 0x06;
}

void spi_deselect()
{

 DDRB = 0x07;
}

//inside main - this while loop after initialising

while (1)
    {
        spi_select();
        spi_send(0xA1);
        spi_send(0x47);

        spi_send(0xBA);

        spi_send(0x21);

        spi_send(0x47);

        result = spi_send(0xFF);
        spi_deselect();
    };

   

This is my updated code. I made a breakpoint at result. But the program is held at the never ending loop during the transfer of the second value.

In the following code,it is held at the while(!(SPSR));

uint8_t spi_send (uint8_t r_data)
{

	SPDR = r_data;
	while(!(SPSR & (0x80) ))
	{};
	return (SPDR);
}

how can this be cleared?

Last Edited: Fri. Jun 30, 2017 - 05:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
while(!(SPSR & (0x80) ))

Why hard code numbers like 0x80 here? Now we all have to scurry off to our datahseets to see which bit that is.

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

oops . It is while(!(SPSR &(1<<SPIF)));

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

Well that not occuring is usually a symptom of SS having being pulled low as an input. Are you sure you are using the designated SS pin as the chip select to the device. Whatever you do with that SS pin it CANNOT be left as a floating input or worse, an input that is externally pulled to ground. If that happens the MSTR switches to slave operation and writing SPDR does not create SCK pulses so SPIF never becomes set.

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

According to the datasheet,

 

if any,

DDRBx = 0 : PinPBX= input

DDRBx=1; pinPBx=output

According to this post,

 

Set SS high when not doing SPI, set low just prior to SPI read/write, set high again after read/write completes for each SPI access

while initialising, I have made PB0 ,the only chipselect pin present , PB0 as 1;

 

in the function select () : it is made to PB0=0 (DDRB = 0x06)

in the function deselct (): it is made toPB0= 1 (DDRB = 0x07)

 

 

 

 

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

pika wrote:
in the function select () : it is made to PB0=0 (DDRB = 0x06)

in the function deselct (): it is made toPB0= 1 (DDRB = 0x07)

Err, no!

DDRB = 0x06 does not make PB0=0, it makes PB0 an input.

DDRB = 0x07 does not make PB0=1, it makes PB0 an output.

 

PB0 has to be an output all the time. And you have to make that output low to select the sensor, and you have to make that output high to deselect.

Stefan Ernst

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
 void spi_select()
 {
	PORTB &=(~ 1<< PB0);
 }

 void spi_deselect()
 {

	 PORTB |=(~ 1<< PB0);
 }

Thank you all for the clear explanations and guidance. I will use this above code and let u know the results soon

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

pika wrote:
PORTB &=(~ 1<< PB0);
  Nope...

    PORTB &= ~(1 << PB0);
// or
    PORTB |= (1 << PB0);

 

David (aka frog_jr)

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

Hello all,

 

I made the chnages with

 

void spi_select()
 {
	PORTB &= ~( 1<< PB0);
 }

 void spi_deselect()
 {

	 PORTB |= (1<< PB0);
 }

The values are sent and updated . But the result register always remains zero (post 33). What could be the problem ?

Last Edited: Fri. Jul 7, 2017 - 10:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From Post #33

pika wrote:

while (1)
    {
        spi_select();
        spi_send(0xA1);
        spi_send(0x47);

        spi_send(0xBA);

        spi_send(0x21);

        spi_send(0x47);

        result = spi_send(0xFF);
        spi_deselect();
    };

Just what are you sending and expecting here?

 

I would think:

uint8_t data = 0;
uint8_t address = 0;
uint8_t result;

// Write (and read) data to SRAM of the PCapØ1Ax-0301 (from diagram on page 6-6 of datasheet)

spi_select();
spi_send(0x88); // Reset the PCapØ1Ax-0301
spi_deselect();

while (1)
    {
        spi_select();
        spi_send(0x90); // Write to SRAM @ address
        spi_send(address);
        spi_send(data++); // Write data and increment
        spi_deselect();

        spi_select();
        spi_send(0x10);  // Read SRAM @ address and increment to next address 
        spi_send(address++);
        result = spi_send(0xFF);  // Read data
        spi_deselect();
    };

 

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
int main(void)
{
    spi_master_int();
	
	spi_select();
	
	spi_send(0x88); //turn on
	
	spi_deselect();	
		
	while (1)
	{	
		spi_select();
		spi_send(0x90); //wrte
		
		spi_send(0x47); //address
		
		spi_send(0xBA); //data
		
		spi_deselect();
		
		spi_select();
		spi_send(0x10); //read
		spi_send(0x47); //address
		result = spi_send(0xFF); //reading back data
		spi_deselect();
   };

This is my code . From pag 4-4 ,I am trying to do the same that is happening in i2c with SPI. I expected to get the data ' BA' to be read in the result register

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

I find this thread very confusing but if the SPI device that is being interfaced with is still the item in post #15 then the key section of the datasheet is:

 

Like Frog I wonder, therefore, what the intention of:

        spi_select();
        spi_send(0xA1);
        spi_send(0x47);

        spi_send(0xBA);

        spi_send(0x21);

        spi_send(0x47);

actually is. It would seem that anything starting 0xA1 is a "Write OTP" command. That sounds VERY DANGEROUS to me!! OTP = One Time Program. You are only going to get one chance to do that. It is hardly the very first thing you should be attempting when first trying to get the interface to work because if you screw up you may have damaged he chip irrevocably in your One Time chance of programming it.

 

If it were me I think I'd be looking around the table in section 5.1 of the data to see if the device has any unmistakably identifiable data pattern in any of its registers then use a 0x10 (read RAM) command to see if you can read that and verify that what comes back is the expected bit pattern - then you know the SPI works.

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

pika wrote:

int main(void)
{
    spi_master_int();
	
	spi_select();
	
	spi_send(0x88); //turn on
	
	spi_deselect();	
		
	while (1)
	{	
		spi_select();
		spi_send(0x90); //wrte
		
		spi_send(0x47); //address
		
		spi_send(0xBA); //data
		
		spi_deselect();
		
		spi_select();
		spi_send(0x10); //read
		spi_send(0x47); //address
		result = spi_send(0xFF); //reading back data
		spi_deselect();
   };

This is my code . From pag 4-4 ,I am trying to do the same that is happening in i2c with SPI. I expected to get the data ' BA' to be read in the result register

 

Thanks a lot for your time and pointing out the points.So fine,it is clear . I think I will have to deal with the hardware first.  This is the program (that I have quoted )I have written. Let us assume, the chip is not damaged.

 

If the chip is normal,is my expectation of ' reading the  value (BA) in result register' right?

For now, I am not doing any measurements but just trying to do what is in pg 4-4 via SPI. Am I procedding the right way?

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

How do you have the IIC_EN pin on the PCapØ1Ax-0301 configured?

(High for I2C, Low for SPI.)

 

In post #8 you set SCLK and MOSI as output.

I have not re-read entire thread, but do you set SS as output?

How about posting complete code as currently implemented.

 

Also, for others looking at this thread, the PCapØ1Ax-0301 cannot share the SPI interface with other slaves as it does not place MISO in a high impedance state (see datasheet page 7-4).

 

Edit: Since you are not doing anything with result, it may be optimized away...but the value should be in SPDR after the transfer if using the debugger.

David (aka frog_jr)

Last Edited: Fri. Jul 7, 2017 - 01:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#define F_CPU 1000000UL
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include "spi_master.h"

volatile char result ;

void spi_select()
{
	PORTB &= ~ (1<< PORTB0);

}

void spi_deselect()
{
	PORTB |= (1<< PORTB0);

}
void spi_master_int (void)
{

	DDRB = 0x07 ;  //PB2=MOSI ,PB1=SCK as output ,PB0 =SS as output
	SPCR =  (1<<SPE) | (1<<MSTR) | (1<<CPHA) ; //spi enabled master mode, spi_mode 1,prescalar :fosc/16

 }

int main(void)
{
    spi_master_int();

	spi_select();

	spi_send(0x88);

	spi_deselect();	

	while (1)
	{
		spi_select();
		spi_send(0x90);

		spi_send(0x47);

		spi_send(0xBA);

		spi_deselect();

		spi_select();
		spi_send(0x10);
		spi_send(0x47);
		result = spi_send(0xFF);
		spi_deselect();
   };

}

 

 

//this spi_master.h

void spi_master_int (void);
uint8_t spi_send (uint8_t r_data);
void spi_select (void);
void spi_deselect(void);

uint8_t spi_send (uint8_t r_data)
{

	SPDR = r_data;
	while(!(SPSR & (1<<SPIF) ))
	{};
	return (SPDR);
}

This is my full present code. IIC_EN pin is connected to the ground. I am using the debugger,but I did not get any change in the value. As I added SPDR,result and r_data in the watch section. Each time the different datas are passed on it (each send invoked) and the r_data value changes,but no change in the SPDR and result. They are always 0x00.

EDIT : I want to make sure that there is no problem with the software /n programming part.

Last Edited: Fri. Jul 7, 2017 - 02:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pika wrote:
,but no change in the SPDR and result.
Look at SPDR in the SFR IO view not as a watch.

 

The best way to "debug" something like SPI is with a DSO or Logic Analyzer.

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

clawson wrote:
Look at SPDR in the SFR IO view not as a watch.

 

I was able to see the change in SPIF register  from 0x80 to 0x00.  But I cannot see change is the SPDR register.

 

The best way to "debug" something like SPI is with a DSO or Logic Analyzer.

Unfortunately I do not have a DSO.

 

pika wrote:
If the chip is normal,is my expectation of ' reading the value (BA) in result register' right? For now, I am not doing any measurements but just trying to do what is in pg 4-4 via SPI. Am I procedding the right way?

 

To achieve this ,is my program and approach proper ?

EDIT:

And if the 'result 'in my program is optimised. Then how will I be able to read the results if I am starting to do the measurements. In Pg 75 and 76 there are steps about reading the results. It is writing the opcodes and then reading the value, which is almsot the same as I do here. indecision

 

Last Edited: Fri. Jul 7, 2017 - 05:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The same sensor I tried writing and reading back with arduino ,and it worked. But with AVR, I do not know to handle it still. frown

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

pika wrote:
with arduino ,and it worked. But with AVR, I do not know
Well the good news is that Arduino *is* an AVR so what worked there will work "standalone" too. Other good news is that nothing in Arduino is "hidden" you can study the source code of all of it so you can see what every bit of the "working" solution is doing anyway.

Pages