I am working with the ATtiny817 on a Atmel Xplained Mini evaluation board. I am trying to use Peter Fleury's software I2Cmaster library to interface with a magnetometer. I know that the ATtiny817 has a TWI hardware module, but it seems to use different register names than the ATmega TWI hardware modules, which makes using any sort of library a pain.

Anyways, when I try to build my project in Atmel Studio 7, I get the errors in the attached image. As you can see in the image, I have added the i2cmaster.h and i2cmaster.S to the project. I am not using the makefile included in Peter Fleury's i2c .zip file because when I tried to build the project using that makefile, I received an error about changing the MCU name in the makefile to attiny817 (apparently it couldn't find the device/file). I have included the location of the i2cmaster library to the Directories Include Path under Project->Project Properties->Toolchain->AVR/GNU C Compiler (not sure if I need to do that, but I didn't think it would hurt).

Any suggestions on what to try to fix the problem? Thanks for any help!

As others have said the 817 series are more akin to Xmega than tiny/mega (in another thread someone (Sparrow?) suggested "Xtiny"). As such I would ditch Fleury - it's not going to help. You may get more mileage by finding a lib for Xmega-TWI and trying to adapt that. Because Xmega are not as popular as tiny/mega there's not a lot of 3rd party library code so the closest thing you may find is TWI for Xmega in Atmel's own ASF. (good luck with THAT!).

About the only "tiny" thing about this at all is the price. In every other sense it's much more a "cut down" Xmega than anything else. That process already kind of started with the E5 series of Xmega which are like a low-end/cut-down Xmega and then continued onto this. The name "Tiny" in it is just plain misleading. I think the suggestion of Xtiny is the best suggestion so far. In the sense that "Tiny" is a cut down "Mega" so this "Xtiny" is a cut-down "Xmega" (or at least it seems to owe more to the Xmega design than it does to any tiny/mega design).

After looking at the TWI section of the Datasheet I wonder how hard it would be to modify Peter Fleury's code as a spin off for this part. I give Micromel/Atchip credit for the very detailed explanation of how I2C works in the section as well.

My Tiny817 XPLAIN arrived the other day. Maybe I could take a try at Peter's library over the weekend. Worst case is it lays an egg. I'll ask Lee for some bacon.

JIm

Note: "Micromel/Atchip" is the Intellectual property of another Freak, and has been reproduced, copied and published without written or spoken permission from the owner of said IP.

If you want a career with a known path - become an undertaker. Dead people don't sue! - Kartman

In every other sense it's much more a "cut down" Xmega than anything else. That process already kind of started with the E5 series of Xmega which are like a low-end/cut-down Xmega and then continued onto this.

Feature-wise, the base XMEGA is XMEGA D (no DMA, ADC is not pipelined, no DAC, etc)

XMEGA E is a capable MCU (DMA, 16b mode for ADC, DAC, ...)

tiny81X may have been created in lieu of a 5 volt XMEGA D and to add AVR to a 5 volt PIC fab (increasing the fab's production)

I'm currently working on adapting the XMega TWI library, and have attempted to scale it way down to just simple init, start transmission, write, and read functions without using interrupts (which I may add back in, but I thought starting with the bare minimum would be a good starting place). However, Atmel Studio is not recognizing the use of ATtiny817 TWI register names found in the datasheet (such as MBAUD, MDATA, MADDRESS, etc). As the datasheet also references them sometimes as TWI.MBAUD, I've tried prefixing the name with TWI, but it still doesn't work. What is the correct way to reference these registers? I've included my main.c and TWI_master_driver.c files, please let me know if any more information would be helpful.

**Edit: Never mind, I think I found the solution. I tried using TWI0.regname and it worked.

Ok, I've fixed my previous problems and actually got my code to compile. However, the pins that I think should be the SDA and SCL for the TWI module are not outputting anything. I've attached my code, which right now is just a main.c file. I've read many times through relevant parts of the ATtiny817's datasheet (TWI, IO Pin Setup) and I would say that I am about 50% confident that I am initializing and using the TWI module correctly. I haven't implemented anything with interrupts yet, as I wanted to check the base functionality of my TWI 'library' before fully committing to interrupts. I would greatly appreciate it if someone that has experience with TWI on other boards would be able to look through my code and hazard a guess as to where I might be going wrong. Thank you!

There is a sample project in AVR Start tha has a TWI driver in C, I'll point it out when I get back to my computer later on tonight.

I believe I found the sample project that you were referring to, was it the AVR42780 Temperature Logger example project? If so, I downloaded it and restructured my code to use the twi_master library that came with it. However, the code still does not result in any signals being driven to PA1 and PA2 (SDA and SCL, respectively). I've attached my new main.c file. Also, the compiler throws a warning that "F_CPU not define for <util/delay.h>", even though I've included the following at the top of my main.c file:

#ifndef F_CPU

#define F_CPU 20000000UL
#endif

Any thoughts on why SDA and SCL aren't showing any signal, or on the F_CPU error?

Attachment(s):

Also, the example project uses the equation (F_CPU/(2*F_SCL) - 5) (found in the at30tse75x.c file) for calculating the baud rate to feed into the TWI_MasterInit function. However that is not the baud rate calculation found in the datasheet. According to the ATtiny817 datasheet, that equation (rearranging the f_SCL equation found on page 395) should be BAUD = ((F_CPU/F_SCL)-10-F_CPU*T_RISE)/2. I'm assuming the datasheet equation should be right, so why the inconsistency in the at30tse75x.c equation? Can the F_CPU*T_RISE term be neglected?

Where did you get that from? The TWI pins are on PB1 (SDA) and PB0 (SCL) by default, PA1 and PA2 are only usable if you use the alternate pin function for which you have to write to some register I guess. (look at the tp at the bottom)

Where did you get that from? The TWI pins are on PB1 (SDA) and PB0 (SCL) by default, PA1 and PA2 are only usable if you use the alternate pin function for which you have to write to some register I guess. (look at the tp at the bottom)

I am writing to the alternate pin function register to enable PA1 and PA2 being used for the TWI pins. I'm doing this because I'm also using the ATtiny for UART communication with a bluetooth module and PB1 and PB0 are used for XCK and XDIR for the USART0. Although this brings up a question: I'm not actually using XCK and XDIR for UART communication, but I assumed that if I enable the USART0 communication, those pins would automatically be assigned to XCK and XDIR functions. Can I overwrite those pins and use them instead as TWI pins? I just wasn't sure what would happen if you had two modules that were enabled and used some of the same pins.

Update: I got the TWI communication working (kind of) using the PB1 and PB0 pins (although I didn't have the USART0 module enabled so we'll see what happens when I add that in). My code is structured in the following way:

1-Write several initialization values to magnetometer

2-Main loop:

a. Write to magnetometer, requesting data from reg 0x5

b. Read data from magnetometer

c. Write to magnetometer, requesting data from reg 0x6

d. Read data from magnetometer

e. Perform processing on data

So far, I've determined (using a logic analyzer) that the initialization process (1) and the first request for data (2a) are being sent from the ATtiny817 and being acknowledged by the magnetometer. However, the first data read (2b) never happens. The logic analyzer shows that the first request for data just keeps repeating, as if there's some event that needs to happen to allow it to move on to the data read (2b). I've looked through the twi_master.c code and don't think I've missed anything. Can anyone help me pinpoint what could be happening here? I've copy-pasted my code below.

Oops, I added in the #define F_CPU at the top after I kept getting errors about F_CPU not being defined, but I forgot to take it out after the #includes.

[quote = js]

And how do you get a 3.3MHz clock? And a BAUDRATE of 100Kbits??

As stated on page 76 of the datasheet, the clock is automatically set to 3.33MHz after a reset (CLK_MAIN is 20MHz, prescaler is 6). Unless I'm mistaken, the standard baudrate for TWI (or I2C) is 100Kbits?

[quote = js]

The USART only uses 2 pins TxD and RxD on PB2 and PB3 by default.

As it seems that you may not have a lot of experience (..and I may be wrong here) I would suggest making life a bit simpler and use the standard pins to start with.

Ok, thank you. You aren't wrong, I am a university electrical engineering student working on a group project, and getting a bit too deep in computer engineering for what I'm used to. But I'm slowly figuring it out, and I really appreciate everyone's input and help.

david.prentice wrote:

All the same, it is easy to bit-bash a TWI Master. You only really need the hardware TWI for Slave.

Likewise, it is east to bit-bash a USART TX. Not easy at all for a RX.

Since the new MCU has got lots of hardware goodies, you might just as well use them. i.e. select your pin budget and find out how to set up and use each Peripheral.

Thanks for the input, David. I might just resort to bit-bashing, as trying to sort out the twi_master library is taking me down a rabbit hole... not sure I'll ever surface again.

I see you are no longer using the alternative pins, which is good, keep it simple until the basics work.

Okay, I am super new at this too. I have not used the twi_master.h include for my project and I haven't looked at that code.

But if you are seeing data resent over and over again from the slave, it must not be seeing an ACK from your side. Make sure bit 9, the Ack/Nak, bit is set low back to the slave otherwise the slave will think something got messed up and resend. Do you have a scope or just a logic analyzer? If you have a scope you can see the 9th bit and what it is doing and other timing issues. It took me hours to figure this stuff out.

I see you are no longer using the alternative pins, which is good, keep it simple until the basics work.

Okay, I am super new at this too. I have not used the twi_master.h include for my project and I haven't looked at that code.

But if you are seeing data resent over and over again from the slave, it must not be seeing an ACK from your side. Make sure bit 9, the Ack/Nak, bit is set low back to the slave otherwise the slave will think something got messed up and resend. Do you have a scope or just a logic analyzer? If you have a scope you can see the 9th bit and what it is doing and other timing issues. It took me hours to figure this stuff out.

My issue isn't with data being resent over and over from the slave, it's with data being resent over and over from the master (the ATtiny). I do have a scope, and I can see the slave (magnetometer) Ack-ing whenever I write to it, but for some reason, after the slave Acks, my code just skips over the read transmission, and returns to the same write transmission. I'm thinking it may have something to do with the TWI interrupts and/or interrupt flags not being cleared appropriately, so that's what I'm looking into right now.