AVR Freaks

PsySc0rpi0n wrote:

Why the datasheet uses TWCR0 and PF code uses TWCR...

Many AVRs have just one TWI interface, the control register is called TWCR. (e.g. ATmega328P)

In AVRs with multiple TWI interfaces, they are TWCR0 and TWCR1. (e.g. ATmega328PB)

 

Edit: and looking at a recent datasheet (Atmel-42735A-ATmega328/P_Datasheet_Complete-06/2016), I see that they are mixing usages of TWCR and TWCR0 in several examples.

See page 270, Table 26-2, Example 5 the assembly code example uses TWCR, the C code TWCR0.

PsySc0rpi0n wrote:

Why the datasheet uses TWCR0 and PF code uses TWCR... One is addressing a single bit of the register the other uses the whole byte of the register! I

What are you going on about?  Why do you say TWCR0 addresses a single bit of a register?

 

Different models of AVR may well have more than one substantiation of a peripheral subsystem.  So otherwise similar/identical subsystems might need a qualifier.  Does TCNT0 address just one bit?  Or is it because that AVR might have TCNT0, TCNT1, TCNT2, ...

TWCR vs TWCR0

 

PF's code is written to work on many AVR's, some of them have more then one TWI, if so, then its called TWCR0, the second one would be TWCR1, and not a bit position as you thought.

Somewhere in the headers it equates TWCR to TWCR0 for your AVR model. I don't use GCC so you will have to find it or someone else will point out where.

 

Start vs Repeat Start

 

Again, PF's code is very flexible, so this function will work for both start and repeat-start.

 

Jim

Note the function description comments (e.g. i2cstart()):

/*************************************************************************
  Issues a start condition and sends address and transfer direction.
  return 0 = device accessible, 1= failed to access device
**********************************************************************
unsigned char i2c_start(unsigned char address) ...

 

If the function returns a 1 there is an error. If it returns (in the case of i2cstart) a 0 it means the device is available.

 

 

Edit: The key here is the word "might".

Notice how the i2c_start is used in the test_i2cmaster.c file:

    ret = i2c_start(Dev24C02+I2C_WRITE);       // set device address and write mode
    if ( ret ) {
        /* failed to issue start condition, possibly no device found */
        i2c_stop();
        PORTB=0x00;                            // activate all 8 LED to show error */
    }else {

So, if the device is not available the routine issues the i2c_stop then turns all LEDs on, indicating an error.

Have you ever thought of running the Peter Fleury code in the simulator, or better still, a real AVR with a debugger attached? That way you can follow it in to every last write to TWCR, TWAR, TWDR or whatever else it may be accessing. There's quite a difference between "dry reading" C code and trying to determine what it is going to do and the alternative of being able to actually watch it in action and see exactly what it is doing!

Looking at the (very confused) example in the datasheet (page 216) and the diagram of a typical transmission (Figure 22-10, page 214):

1. Write TWCR setting TWINT (clears any the interrupt flag (if present), initiates START condition), TWSTA (requesting START), and TWEN (enable TWI interface).
2. After the TWI transmits the START condition, TWINT will be set (by hardware), so wait for TWINT to go high
3. Check the Status (in TWSR) and if not equal to start, process as an error, else, load the slave address + write (SLA+W) into the TWDR and then write TWCR setting bits TWINT (to clear the existing interrupt flag) and TWEN (to enable the transmission)
4. Wait until the hardware sets the TWINT

and so on...

 

The hardware sets the TWINT flag. (making the bit 1)

Software writing a 1 to the TWINT bit clears the flag. (making the bit 0)

 

Edit: typos

Edit: This is referencing the ATmega48A/PA/88A/PA/168A/PA/328/P datasheet Atmel-8271J-AVR- ATmega-Datasheet_11/2015

Quite honestly,   you read the HTML documentation,   use the library according to the docs.

 

Treat any library as a Black Box.   i.e. obey the rules.   supply the input.   receive the output.

 

Yes,   when you have gained experience from using a library correctly,  you might want to study how the library works.

I would start by riding a bicycle before you start worrying about carbon-fibre,  bearings,  tyres, ...

 

You will see that every TWI command probably has the TWINT bit set.

This simply clears the TWINT flag (if it is set by some previous operation)

 

If the TWINT was not set,  clearing it makes no difference.

 

Seriously,   you don't need to worry about TWINT or any other low level TWI registers.    Just use the library.

 

David.

PsySc0rpi0n wrote:

Why is there the need for the 1st function?

If only Peter had written a user manual. Oh wait a minute...

 

http://homepage.hispeed.ch/peter...

 

Note the difference on that page between start() and start_wait(). Specifically the return value or lack of it. Also the fact that the _wait one does what it says on the tin - it waits.

 

Clearly the intended use is either i2c_start() to "sniff" whether a device is present and be able to take action if it isn't while i2c_start_wait() knows the device is there and will doggedly try to make the connection.

Quite honestly,   you read the HTML documentation,   use the library according to the docs.

 

Treat any library as a Black Box.   i.e. obey the rules.   supply the input.   receive the output.

 

Yes,   when you have gained experience from using a library correctly,  you might want to study how the library works.

I would start by riding a bicycle before you start worrying about carbon-fibre,  bearings,  tyres, ...

 

You will see that every TWI command probably has the TWINT bit set.

This simply clears the TWINT flag (if it is set by some previous operation)

 

If the TWINT was not set,  clearing it makes no difference.

 

Seriously,   you don't need to worry about TWINT or any other low level TWI registers.    Just use the library.

 

David.

PsySc0rpi0n wrote:

But I have never run the code using a debugger! I'm not very familiar with debuggers! If you can explain me how to do it, I can try!

I was going to say you just spend $50, get an Atmel ICE and go play but of course Microchip came along and doubled that $50 to $100.

Anyway if you have an ICE then it can be used as a simple ISP programmer like you probably already have but it has another trick up it's sleeve. It is a USB connected device just like your current programmer probably is but alongside programming it can also take control of an AVR as it runs. It can either make the AVR execute a single opcode at a time so you can run each in turn and see what is going on inside the AVR at every step or, more usually you can tag a line in C or Asm as a place you want it to stop (you can have several of these breakpoints) and you can just say "let the AVR run until it hits one of these". Whether stepping or breakpointing you arrive at a particular line in your program and it can then instantly show you what every variable is set to and what all the bits in all the AVR control registers are set to. So you can put a break on the point in the code where Fleury is making writes to TWXX registers and see the exact bit pattern (TWINT or whatever else) is about to be written so you can watch exactly what the code is doing.

 

While you can do the same in simulation without the real AVR the fact is that what the simulator will not simulate is the behaviour of the I2C device at the other end of the SDA/SCl wires. If you use a real AVR with a debugger it will really be talking to the 24LC08 or whatever it and you can see the way in which it responds (or the view the AVR has of that anyway).

 

My observation is that you tend to read too fast and miss critical things. This frustrates us as your responses show that you missed something critical. It also means these threads drag along and don't converge.

The twimaster.c code is very straightforward.

 

You asked about TWINT.   I think that this was explained to you.

The functions clear any TWINT flag,  issue a TWI command.    Wait for it to complete i.e. TWINT is set.

 

If you do not understand the difference between i2c_start() and i2c_start_wait(),   you have to sit down with a nice cup of tea and a biscuit.

 

I suggest that you quote a specific function and ask a specific question.

You will get a specific answer.

 

I still reckon that you should gain experience by usng a "Black Box" before dissecting any library code.

Of course your learning schedule might suit you better.

 

I had deliberately avoided this thread.   It did not seem to be going very well.

 

David.

Please do not put words in my mouth.  I intended no sarcasm at all.  If you think that I cannot help thinking that you are over sensitive and probably have personality problems.  I won't trouble any of your tiresome threads in future where I was simply trying to help you understand. Frankly you aren't worth the effort. 

Put yourself in my position. How could i possibly answer your question? Where are the missing lines?
Do i need to dig through the history to find them?
You want to learn - so start learning. Do your research and answer your own questions for once. You've got plenty of evidence to work from.

Fix the DDRB in #24. Then your code looks fine to me. i.e. the LEDs can be driven properly.
.
David.