I2C Library Problems with ATtiny817

Go To Last Post
57 posts / 0 new

Pages

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

Hello,

 

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! 

 

 

Attachment(s): 

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

Any suggestions on what to try to fix the problem?

Rewrite the library for the T817 and then, when it's all working, share it with us. wink

 

Very early still for anyone but Atmel to have any working code, the TWI seems to be a lot more complicated in the T817.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I just had a quick glance at the datasheet, and it looks very similar to the XMega TWI I once wrote a driver for at work. I remember that it was miles away from the normal Mega TWI peripheral.

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

The structure of the IO's etc on a 817 don't match normal AVR's, the port things needs to be checked.

 

I have not looked to close, but the VPORT things seems to have a layout that match an "normal" PORT

 

I don't know the lib, but if it use instruction timing some things needs to be checked.  

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

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!).

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

Thank you for the replies, everyone! Sounds like I've got some exciting days ahead of me either finding an XMEGA i2c lib or writing my own i2c library (*shudders*). 

 

Out of curiosity, any ideas on why the T817 seems like a tiny/mega hybrid? 

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

mjcar2016 wrote:
Out of curiosity, any ideas on why the T817 seems like a tiny/mega hybrid?

 

It's kinda like a Platypus.  Made up of leftover peripherals, and is a mystery as to its true application.

 

 

JMO

 

Jim

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

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

jgmdesign wrote:
It's kinda like a Platypus. Made up of leftover peripherals, and is a mystery as to its true application.

Hope it doesn't lay an egg.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

mjcar2016 wrote:
why the T817 seems like a tiny/mega hybrid?
You mean tiny/Xmega hybrid?

 

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).

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

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

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

js wrote:
Very early still for anyone but Atmel to have any working code, ...
Appears to be in Atmel START.

http://start.atmel.com/static/help/index.html?GUID-DC086BFD-7DA2-43E8-8AE0-457F2351FF4C (Atmel Start, Change Log, 2016 - November)

http://start.atmel.com/

Browse Examples

Board : ATtiny817 Xplained Mini

select AVR42780 Temperature Logger

Open Selected Example

Add Software Component

Expand Drivers

Select I2C

Add component(s)

(transparency - did not proceed further to read the source code)

 

Atmel START appears to be functional for a custom board (create new project, tiny816 in SOIC, TWI, etc)

 

Edits : typo, custom board

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Nov 18, 2016 - 05:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
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)

 

"Dare to be naïve." - Buckminster Fuller

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

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. 

Attachment(s): 

Last Edited: Fri. Nov 18, 2016 - 06:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just told you that in another thread which just proves exactly why cross posting is such a bad idea!

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

Update: I've gotten the code to successfully compile and build (yay!), but when I try to run the program, I get an Atmel Studio error (boo): 

 "Failed to launch. Missing file C:\Users\Mike\Documents\Atmel Studio\7.0\headphones\headphones\headphones.elf"

 

Any insight into what causes this and what could fix it? 

 

Thanks! 

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

So is there a file of that name in that location?

 

It seems unlikely because Studio normally builds "Debug" or "Release" and the .elf file is usually in a sub-directory of that name. I see neither "Debug" nor "Release" in the pathname you quoted.

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

There is a file called headphones.cproj in the headphones\headphones location. There is also a Debug folder in that location that contains a headphones.elf file as well as several other files. 

 

**Edit: How do I change the location that it looks for the .elf file in? 

Last Edited: Fri. Nov 18, 2016 - 07:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it helps, here is the Build output from Atmel Studio: 

------ Build started: Project: headphones, Configuration: Debug AVR ------
Build started.
Project "headphones.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "C:\Users\Mike\Documents\Atmel Studio\7.0\headphones\headphones\headphones.cproj" (target "Build" depends on it):
    Task "RunCompilerTask"
        Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
        C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 4 --output-sync 
        Building file: .././twi_master_driver.c
        Invoking: AVR/GNU C Compiler : 4.9.2
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.1.102\include"  -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny817 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.1.102\gcc\dev\attiny817" -c -std=gnu99 -MD -MP -MF "twi_master_driver.d" -MT"twi_master_driver.d" -MT"twi_master_driver.o"   -o "twi_master_driver.o" ".././twi_master_driver.c" 
        Finished building: .././twi_master_driver.c
        Building file: .././main.c
        Invoking: AVR/GNU C Compiler : 4.9.2
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe"  -x c -funsigned-char -funsigned-bitfields -DDEBUG  -I"C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.1.102\include"  -O1 -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -g2 -Wall -mmcu=attiny817 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.1.102\gcc\dev\attiny817" -c -std=gnu99 -MD -MP -MF "main.d" -MT"main.d" -MT"main.o"   -o "main.o" ".././main.c" 
        Finished building: .././main.c
        Building target: headphones.elf
        Invoking: AVR/GNU Linker : 4.9.2
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe" -o headphones.elf  main.o twi_master_driver.o   -Wl,-Map="headphones.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=attiny817 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.1.102\gcc\dev\attiny817"  
        Finished building target: headphones.elf
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "headphones.elf" "headphones.hex"
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "headphones.elf" "headphones.eep" || exit 0
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "headphones.elf" > "headphones.lss"
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "headphones.elf" "headphones.srec"
        "C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "headphones.elf"
           text       data        bss        dec        hex    filename
            310          0          0        310        136    headphones.elf
    Done executing task "RunCompilerTask".
    Using "RunOutputFileVerifyTask" task from assembly "C:\Program Files (x86)\Atmel\Studio\7.0\Extensions\Application\AvrGCC.dll".
    Task "RunOutputFileVerifyTask"
                Program Memory Usage     :    310 bytes   3.8 % Full
                Data Memory Usage         :    0 bytes   0.0 % Full
    Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "headphones.cproj".
Target "PostBuildEvent" skipped, due to false condition; ('$(PostBuildEvent)' != '') was evaluated as ('' != '').
Target "Build" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Avr.common.targets" from project "C:\Users\Mike\Documents\Atmel Studio\7.0\headphones\headphones\headphones.cproj" (entry point):
Done building target "Build" in project "headphones.cproj".
Done building project "headphones.cproj".

Build succeeded.
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

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

Appears to be in Atmel START.

Last night I tried one of the example in START (GETTING_STARTED_ATtiny817.atzip) and could not make any head or tail EVEN by looking at the .S file and .lss file.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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!

 

 

Attachment(s): 

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

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.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Okay, that would be great. Thank you. 

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

js wrote:

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): 

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

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? 

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

Dumb question time....
Do you have pullup resistors on the SCL and SDA lines? If not 4.7k will do the trick.

Jim

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

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

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

I'm interfacing with a Sparkfun magnetometer breakout board that has 4.7k pullup resistors on the SCL and SDA lines on its end.

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

Ok. Thats good.

Another dumb question....are you powering the sparkfun board from the same supply as your AVR? If not do you have the grounds tied together?

Just making sure the hardware ia setup.

Jim

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

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Tue. Nov 22, 2016 - 06:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

was it the AVR42780 Temperature Logger example project?

That's the one.

to PA1 and PA2 (SDA and SCL, respectively)

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)

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

jgmdesign wrote:

Ok. Thats good.

Another dumb question....are you powering the sparkfun board from the same supply as your AVR? If not do you have the grounds tied together?

Just making sure the hardware ia setup.

Jim

 

Yep, I'm using the ATtiny817 Xplained Mini board and powering the sparkfun board from the 3.3V and ground from that. 

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

js wrote:

to PA1 and PA2 (SDA and SCL, respectively)

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. 

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

Hi, 

 

I am using the USART and TWI at the same time and I am able to use the primary SDA/SCL pins on PB1/PB0.

I have some basic, hard fought code, to get the TWI interface going on the 817 (write only/single master). It does not use any library. It is on the computer at home, I can post later if you wish.

I am not saying it's perfect but it is reliably working.

 

Cheers,

P

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

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.

 

#define F_CPU 3330000UL

#include <avr/io.h>
#include <avr/interrupt.h>
#include <stdio.h>
#include <stdlib.h>
#include <util/delay.h>
#include <atmel_start.h>
#include <twi_master.h>

#define MAG_ADDR 0x0E
#define F_CPU 3330000UL
#define CPU_SPEED 3330000
#define BAUDRATE 100000
#define true 1
#define false 0

 

/* TWI Master */
TWI_Master_t twi_master;
TWI_t inst;

void init_MAG(void){
    uint8_t data[2];
    data[0] = 0x11;
    data[1] = 0x80;
    
    TWI_MasterWrite(&twi_master, MAG_ADDR, data, 2);
    
    _delay_ms(15);

    data[0] = 0x10;
    data[1] = 0x01;
    
    TWI_MasterWrite(&twi_master, MAG_ADDR, data, 2);
}

volatile uint8_t readReg(uint8_t regAddr){
    volatile uint8_t data = 0;
    volatile uint8_t result = 0;
    uint8_t array[1];
    array[0] = regAddr;
    TWI_MasterWrite(&twi_master, MAG_ADDR, array, 1);
    
    _delay_us(5); //delay 5 microseconds
    
    result = TWI_MasterRead(&twi_master, MAG_ADDR, 1);
    
    if(result == true){
        data = twi_master.readData[0];
    }
    
    return data;
}

volatile uint16_t readMagValue(uint8_t msb_reg, uint8_t lsb_reg){
    volatile uint16_t val_low = 0;
    volatile uint16_t val_high = 0;
    volatile uint16_t out_val = 0;
    
    val_high =     readReg(msb_reg);
    
    //_delay_us(2); //delay 2 microseconds
    
    val_low = readReg(lsb_reg);
    
    out_val = (val_low | (val_high << 8));
    return out_val;
}

//Read z-axis magnetometer data
volatile uint16_t read_z(void){
    return readMagValue(0x05, 0x06); //z-axis data is in mag registers 0x05, 0x06
}

int main(void)
{
    volatile uint8_t result = 0;
    inst = TWI0;
    
    //PORTMUX.CTRLB |= PORTMUX_TWI0_ALTERNATE_gc;
    volatile uint8_t baud_rate = (CPU_SPEED/(2*BAUDRATE) - 5);
     
    TWI_MasterInit(&twi_master, &TWI0, (TWI_RIEN_bm | TWI_WIEN_bm), baud_rate);
    
    sei(); 
    
    init_MAG();
    
    while (1) 
    {
        result = read_z();
        
        if(result > 1000){
            PORTC.OUTSET |= (1<<0);
        }
        else{
            PORTC.OUTCLR |= (1<<0);
        }
        
        _delay_ms(100);
    }
}

ISR(TWI0_TWIM_vect)
{
    /* Needed for the TWI to complete transactions */
    TWI_MasterInterruptHandler(&twi_master);
}

 

 

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

What??

#define F_CPU 3330000UL TWICE??

.

.

#define F_CPU 3330000UL
#define CPU_SPEED 3330000
#define BAUDRATE 100000

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

 

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.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Look at Table 5-1. PORT Function Multiplexing in the datasheet.

You can use USART on PB0, PB1 or PA1, PA2 and TWI on PB2, PB3.

 

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.

 

Farnell do not have the XMINI-817 in stock yet.   So I do not have this board.

 

David.

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

Farnell do not have the XMINI-817 in stock yet.   So I do not have this board.

So did you miss out on the free giveaways? http://www.avrfreaks.net/comment...

 

Got an email from DHL, looks like I'm getting something on Monday wink

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I do not like being held to ransom by DHL.

 

Especially for an £8 evaluation board.   I will buy one from Farnell when they get stock.

 

Anyway,  I had not contributed to that particular thread (with the giveaways).

 

David.

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

softpdx wrote:

 

I am using the USART and TWI at the same time and I am able to use the primary SDA/SCL pins on PB1/PB0.

I have some basic, hard fought code, to get the TWI interface going on the 817 (write only/single master). It does not use any library. It is on the computer at home, I can post later if you wish.

I am not saying it's perfect but it is reliably working.

 

 

That would be awesome if you could post it. It would be helpful to have something else to look at, and maybe extend to being able to do reads as well. 

 

js wrote:

What??

#define F_CPU 3330000UL TWICE??

.

.

#define F_CPU 3330000UL
#define CPU_SPEED 3330000
#define BAUDRATE 100000

 

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. 

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

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.

 

 

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

softpdx wrote:

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. 

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

Okay, again, I am super new at this as well but I think I may see what the problem is...

Looking at your readReg routine below, it looks like you are setting the slave address every time which might be causing a new start signal every time.

 

I think you need to send the address the first time (TWI_MasterRead) which probably send a start signal and just do reads (data = twi_master.readData[0]) on all subsequent reads until you are done.

Then do a stop signal.

 

 

volatile uint8_t readReg(uint8_t regAddr){
    volatile uint8_t data = 0;
    volatile uint8_t result = 0;
    uint8_t array[1];
    array[0] = regAddr;
    TWI_MasterWrite(&twi_master, MAG_ADDR, array, 1);
    
    _delay_us(5); //delay 5 microseconds
    
    result = TWI_MasterRead(&twi_master, MAG_ADDR, 1);
    
    if(result == true){
        data = twi_master.readData[0];
    }
    
    return data;
}

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

As promised my code, it is write only not read like you need but maybe it will help.

The code is for a 4725 DAC chip.

 

// TWI (Twin Wire) Interface (BASIC)

#define P_TWI_ERROR      0x2
#define P_TWI_WAIT      0x1
 
char volatile Buffer_TWI[5];
int8_t volatile Buf_Start_Ptr = 0;
int8_t volatile Buf_End_Ptr = 0;
int8_t volatile Stop_TWI = false;
uint8_t volatile error_TWI = false;

// Check for wait condition or error on TWI
int8_t pi2c_check(void)
{
  int8_t mstatus = TWI0.MSTATUS;
  if (mstatus & (TWI_BUSERR_bm | TWI_ARBLOST_bm | TWI_RXACK_bm)) {  // TWI_RXACK_bm is actually flag for NAK
        error_TWI = true;
        return P_TWI_ERROR;
  }
  if  (!((mstatus & 3) | TWI_BUSSTATE_IDLE_gc)) { return P_TWI_WAIT; }  // Wait until not busy
  return 0;
}

ISR (TWI0_TWIM_vect)
{
  int8_t status;
  if (Buf_Start_Ptr <= Buf_End_Ptr) {
        if (!error_TWI) {
          TWI0.MDATA = Buffer_TWI[Buf_Start_Ptr];
          pi2c_check();
        }
        Buf_Start_Ptr++; 
  } else {
        TWI0.MCTRLB = TWI_MCMD_STOP_gc;
        do {
      status = pi2c_check();                                          // Get wait or error status
    } while ((status != P_TWI_ERROR) & (status == P_TWI_WAIT));
        Stop_TWI = true;
  }
}

 

//Initiate TWI communication

int8_t pi2c_start_w(uint8_t addr)
{
//  TWI0.DBGCTRL = 0;
  TWI0.MBAUD   = 0;                                                                // Set the TWI baud to as fast as possible
  TWI0.MCTRLA  = TWI_WIEN_bm + TWI_ENABLE_bm;            // Activate SDA/SCL + write interrupts
  TWI0.MSTATUS |= TWI_BUSSTATE_IDLE_gc;                        // Set the BUS state to idle
  TWI0.MADDR   =  addr << 1;                                            // Set the slave's address shifted left one / Bit 0 off = write
  if (pi2c_check() == P_TWI_ERROR) { return 0; }    // 0 is an error
  return 1;                                                                                // It worked!
};

#define DAC_ADDRESS 0x62

// Control DAC voltage - Permanent sets in the chip EEPROM
void set_dac_voltage(int volts, int8_t ispermanent)
{
  volts = (volts << 2);
  uint8_t upbyte  = volts >> 8;
  uint8_t lowbyte = (volts & 0xFF);
  error_TWI = false;
  Stop_TWI  = false;
  if (ispermanent) {                                  // Two different formats to send DAC voltage
        upbyte  = volts >> 4;                          // one is three bytes the other is 2
        lowbyte = (volts & 15) << 4;
        Buffer_TWI[0] = 0x60;
        Buffer_TWI[1] = upbyte;
        Buffer_TWI[2] = lowbyte;
        Buf_Start_Ptr = 0;
        Buf_End_Ptr   = 2;
  } else {
        Buffer_TWI[0] = upbyte;
        Buffer_TWI[1] = lowbyte;
        Buf_Start_Ptr = 0;
        Buf_End_Ptr   = 1;
  }
  int8_t cnt = 0;
  // try twice to open the dac
  do {
        error_TWI = !pi2c_start_w(DAC_ADDRESS);
        ++cnt;
  } while ((cnt < 2) & (error_TWI != 0));
  
  while ((!Stop_TWI) & (!error_TWI)) {
    _delay_loop_1(1);
  }
  TWI0.MCTRLA = 0; // Disable TWI
}  

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

the clock is automatically set to 3.33MHz after a reset (CLK_MAIN is 20MHz, prescaler is 6).

Thank you. See? I learned something new from you.wink Yet another strange thing we have to get used to using this family of chips.

 

the standard baudrate for TWI (or I2C) is 100Kbits?

I see, you are referring to the TWI baud rate. May want to rename it as you will also have a  baudrate for the USART so it will get confusing and will get errors.

The Atmel lib expects baud_rate so maybe you can change that to TWI_baud_rate in the lib and your code??

 

Also you may want the check the 16/20MHz fuse just in case it is set for 16Mhz.

 

I should get my board next week so I will be able to know a bit more.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I should get my board next week so I will be able to know a bit more.

With all these shenanigans I am not sure that I am looking forward to next Monday's delivery...

 

Ross McKenzie ValuSoft Melbourne Australia

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

C'mon Ross, it will be good for your brain, look at the fuses, aren't they interesting?