avg gcc and new ATTINY 816, 817, 1616, 1617...

Log in or register to post comments
Go To Last Post
10 posts / 0 new
Author
Message
fgras78
fgras78's picture
Level: Rookie
Joined: Sat. May 30, 2015
Posts: 20 View posts
#1
Posted by fgras78: Mon. Nov 6, 2017 - 01:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

 

it seems that AVR GCC doen't support the new ATTINY 816, 817 !

At least not completely.

For example the <avr/eeprom.h>

the functions eeprom_read_byte, write_byte, etc.. doesn't work.

Neither the EEMEM allocation to declare eeprom variables/constants in eeprom.

 

I am writing the subroutines for using NVMCRTL for read byte and write byte,but

- does anybody knows how to declare variable in eeprom like EEMEM ?

- Do you know when the full support for these new amazing attiny will be implemented in AVR GCC?

 

Thanks and best regards.
FGRAS78

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98338 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Nov 6, 2017 - 01:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

EEMEM is really nothing more than a section attribute to collect all such data together in one rebaseable place anyway.
.
avr-gcc/AVR-LibC is a user developed collaboration so perhaps the support for EEPROM in those devices will be complete when YOU put it there. This is the way open software grows. It's as and when a user needs a feature and are then generous enough to assign their copyright back to the project.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98338 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Nov 6, 2017 - 01:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

PS I imagine Atmel have probably already developed EEPROM support for those devices anyway but it's probably buried deep in the guts of their own ASF rather than being "open" in <avr/eeprom.h> but just to be sure, it is Atmel's own build of GCC and not the generic one you are using?

Last Edited: Mon. Nov 6, 2017 - 01:27 PM
Top
fgras78
fgras78's picture
Level: Rookie
Joined: Sat. May 30, 2015
Posts: 20 View posts
Posted by fgras78: Mon. Nov 6, 2017 - 03:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use the GCC present by default in Atmel Studio, simply.

 

 

 

EEMEM (and PROGMEM) are very important and I am surprised that nobody needed these instructions in these new devices.

Maybe somebody know how to replace EEMEM in standard C langage ?

The target is that the arrays and variables are burned into the device during the flash UPDI progamming. 

And the arrays and variable have names with assigned addresses to be handled by the program.

 

 

 

 

 

Top
meolsen
meolsen's picture
Level: Site Admin
Joined: Wed. Jul 27, 2011
Posts: 3444 View posts
Location: Microchip, Arizona
Posted by meolsen: Mon. Nov 6, 2017 - 04:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The eeprom functions (and all other device-specific) functions used by avr-libc is implemented in the DFPs. So, are you using DFPs or are you using something else?

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

Top
fgras78
fgras78's picture
Level: Rookie
Joined: Sat. May 30, 2015
Posts: 20 View posts
Posted by fgras78: Mon. Nov 6, 2017 - 10:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The DFP is up-to-date = 1.3.132

the iotn1616.h, iotn816.h ... are defined and contain all the bit masks and bit groups, that's OK and that's not the problem.

 

The avr/eeprom.h is not implemented at all for these new devices, even if the NVMCRTL functions looks like xmega's ones.

 

Using Atmel.start sources, I tried to write eeprom functions :

 

- to replace eeprom_read_byte :

uint8_t FLASH_0_read_eeprom_byte(uint16_t eeprom_adr)
{
return *(uint8_t *)(EEPROM_START + eeprom_adr);
}

 

- to replace eeprom_write_byte :

uint8_t FLASH_0_write_eeprom_byte(uint16_t eeprom_adr, uint8_t data)
{
while (NVMCTRL.STATUS & NVMCTRL_EEBUSY_bm);

/* Clear page buffer */
CCP = 0x9D;
NVMCTRL.CTRLA = NVMCTRL_CMD_PAGEBUFCLR_gc; //ccp_write_spm((void *)&NVMCTRL.CTRLA, NVMCTRL_CMD_PAGEBUFCLR_gc);
*(uint8_t *)(EEPROM_START + eeprom_adr) = data;  /* Write byte to page buffer */
CCP = 0x9D;
NVMCTRL.CTRLA = NVMCTRL_CMD_PAGEERASEWRITE_gc; //ccp_write_spm((void *)&NVMCTRL.CTRLA, NVMCTRL_CMD_PAGEERASEWRITE_gc);   /* Erase byte and program it with desired value */

return 1;
}

 

these functions seem to work...

but  I don't know how to implement the EEMEM attribute. The #define EEMEM __attribute__((section(".eeprom"))) doesn't work.

 

 

 

 

 

Last Edited: Tue. Nov 7, 2017 - 03:02 PM
Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98338 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Nov 7, 2017 - 11:36 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

fgras78 wrote:
The #define EEMEM __attribute__((section(".eeprom"))) doesn't work.
Tell me more about "doesn't work"

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 17634 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Tue. Nov 7, 2017 - 11:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

How to properly post source code: https://www.avrfreaks.net/comment...

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 oscillator: https://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...
Top
fgras78
fgras78's picture
Level: Rookie
Joined: Sat. May 30, 2015
Posts: 20 View posts
Posted by fgras78: Tue. Nov 7, 2017 - 09:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I receive this error :

 

Error recipe for target 'main.o' failed 

Error invalid conversion from 'uint8_t* {aka unsigned char*}' to 'uint16_t {aka unsigned int}' [-fpermissive] 

 

now I know it doesn't come from EEMEM.

EEMEM is OK (tested with a very simple program).

The problem comes from my routines 

FLASH_0_read_eeprom_byte
FLASH_0_write_eeprom_byte

and way to pass address...

 

here is the full code :

 

#include <avr/io.h>
#include <avr/eeprom.h>

uint8_t EEMEM val = 0x00 ;
const uint16_t val_adr = &val;

uint8_t FLASH_0_read_eeprom_byte(uint16_t eeprom_adr)
{
	return *(uint8_t *)(eeprom_adr);		//return *(uint8_t *)(EEPROM_START + eeprom_adr);
}

uint8_t FLASH_0_write_eeprom_byte(uint16_t eeprom_adr, uint8_t data)
{
	while (NVMCTRL.STATUS & NVMCTRL_EEBUSY_bm);		// is eeprom ready?

	/* Clear page buffer */
	CCP = 0x9D;
	NVMCTRL.CTRLA = NVMCTRL_CMD_PAGEBUFCLR_gc;		//ccp_write_spm((void *)&NVMCTRL.CTRLA, NVMCTRL_CMD_PAGEBUFCLR_gc);
	
	*(uint8_t *)(eeprom_adr) = data;  /* Write byte to page buffer */  //*(uint8_t *)(EEPROM_START + eeprom_adr) = data;
	CCP = 0x9D;
	NVMCTRL.CTRLA = NVMCTRL_CMD_PAGEERASEWRITE_gc;		//ccp_write_spm((void *)&NVMCTRL.CTRLA, NVMCTRL_CMD_PAGEERASEWRITE_gc);   /* Erase byte and program it with desired value */

	return 1;
}

int main(void)
{
	
		FLASH_0_write_eeprom_byte(val_adr, 0xBB);
		
		PORTA.OUT = FLASH_0_read_eeprom_byte(val_adr);
		
		
    return 0;
}

 

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 98338 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Wed. Nov 8, 2017 - 10:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

fgras78 wrote:
Error invalid conversion from 'uint8_t* {aka unsigned char*}' to 'uint16_t {aka unsigned int}' [-fpermissive]
You do know that this error message comes with a line number saying which line is causing it? When I build that code I get:

avr.c:5:26: warning: initialization makes integer from pointer without a cast [-Wint-conversion]
 const uint16_t val_adr = &val;
                          ^

So it's the use of the address-of operator on "val" that throws this error (line 5, column 26).

 

That's because you are assigning an address to a an int. I suggest that if this is really what you want to do then:

 const uint16_t val_adr = (uint16_t)&val;

But why do you even need "val_adr" anyway? Surely your functions should be:

uint8_t FLASH_0_read_eeprom_byte(uint8_t * eeprom_adr)
uint8_t FLASH_0_write_eeprom_byte(uint8_t * eeprom_adr, uint8_t data)

and then you use them as:

int main(void)
{
	
		FLASH_0_write_eeprom_byte(&val, 0xBB);
		
		PORTA.OUT = FLASH_0_read_eeprom_byte(&val);

(which is pretty much what the eeprom_*() functions in <avr/eeprom.h> use as an interface).

Top