ATtiny417 / ATtiny814 / ATtiny816 / ATtiny817

Go To Last Post
413 posts / 0 new

Pages

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

>But where did the pin info for uarts COME from?

 

Datasheets- I/O Multiplexing and Considerations, PORTMUX.

 

>Does a build normally have any access to the .atdf files? 

 

I haven't touched them.

 

I have 2 avr's- tiny416 and mega4809, and lot of code is compatible between the two, but there are differences and pins are one of them of course. I don't use the io header files either, except as a reference when something in the datasheet seems odd. Moving around in the same series with same pin count is easy enough, and probably not too bad moving to another pin count either.

 

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

westfw wrote:

 

Does a build normally have any access to the .atdf files?  I guess they're in the Atmel Pack directories, but they don't seem to make it into a typical non-AS gcc installation...

 

 

The answer is NO.  GCC has no way of interpreting the XML .atdf files.  They are only useful for "generator" programs to extract data from. 

 

Pin information would be very handy to have in headers.  There is a bunch of info in the .atdf files that is not exposed in the headers, like these pin numbers.

I am working on a much better generator for headers than microchip are using and than is currently available in avr-libc, so if anyone has a suggestion for a useful way to emit this pin information for use by the C program let me know a format and I can embed it in my generator.

It already emits Assembler field definitions that match the enums used by C, but can't be used by ASM.  Something the official headers sorely lack.

 

Unfortunately there is no specification for .atdf files that i have ever been able to find, and its usage isn't 100% consistent across all chips.  So processing the data isn't completely straight forward.

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

strontiumdog wrote:

if anyone has a suggestion for a useful way to emit this pin information for use by the C program let me know a format and I can embed it in my generator.

 

Had a quick look, and a very straightforward way would be to define pins

#define PB0 (0)

#define PB1 (1)

etc.  (Something I already do in my latest code i am working on, because it is completely inconsistent in avr-libc and not present at all in atmel/microchip generated headers.  So it's missing for newer chips.

 

And then for other signals I could emit:

#define ADC0 (PB0)

#define ADC1 (PB1)

 

etc.  But is this actually useful? Its possible to cross correlate the data in the .atdf and generate data from the complex interrelationship between modules and peripherals, so if this isn't useful but some other information would be, then I would be happy to try and extract it.

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

@strontiumdog

 

Something like this (extracted from atdf file), approximating the pin mux table in datasheet.  Alternate pins have been withheld.  Could be useful?

 

ATtiny1617
AVR8X
have pinouts

[Pins-QFN24]
1,PA2,ADC2,LUT0_IN2,EVOUTA,MISO
2,PA3,ADC3,EXTCLK,SCK,TCA0_WO3,TCB1_WO
3,GND
4,VDD
5,PA4,ADC4,ADC1_ADC0,LUT0_OUT,X0,Y0,SS,TCA0_WO4,TCD0_WOA
6,PA5,AC0_OUT,AC1_N0,ADC5,ADC1_ADC1,X1,Y1,TCA0_WO5,TCB0_WO,TCD0_WOB,VREFA
7,PA6,AC0_N0,AC1_P1,AC2_P0,ADC6,ADC1_ADC2,DAC0_OUT,X2,Y2
8,PA7,AC0_P0,AC1_P0,AC2_N0,ADC7,ADC1_ADC3,LUT1_OUT,X3,Y3
9,PB7,AC1_N1,AC2_P3,ADC1_ADC4
10,PB6,AC0_P3,AC2_N1,ADC1_ADC5
11,PB5,AC0_P1,AC2_P2,ADC8,CLKOUT,X12,Y12
12,PB4,AC0_N1,AC1_P3,ADC9,X13,Y13
13,PB3,AC1_OUT,TOSC1,RXD0
14,PB2,AC2_OUT,TOSC2,EVOUTB,TCA0_WO2,TXD0
15,PB1,AC0_P2,ADC10,X4,Y4,TCA0_WO1,SDA,XCK0
16,PB0,AC1_P2,AC2_P1,ADC11,X5,Y5,TCA0_WO0,SCL,XDIR0
17,PC0,ADC1_ADC6,X6,Y6,TCD0_WOC
18,PC1,ADC1_ADC7,X7,Y7,TCD0_WOD
19,PC2,ADC1_ADC8,EVOUTC,X8,Y8
20,PC3,ADC1_ADC9,LUT1_IN0,X9,Y9
21,PC4,ADC1_ADC10,LUT1_IN1,X10,Y10
22,PC5,ADC1_ADC11,LUT1_IN2,X11,Y11
23,PA0,ADC0,LUT0_IN0,RESET,UPDI
24,PA1,ADC1,LUT0_IN1,MOSI

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

GCC has no way of interpreting the XML .atdf files.

Well, I knew that gcc doesn't access them.  I was wondering whether given a standard makefile that knows the root binary directory, whether an additional user program could find the atdf files to extract additional info.

I guess if I have Atmel "Packs" installed, they have the .atdf files and a standard location.

 

 

I am working on a much better generator for headers than microchip

 

Over in Optiboot land (where I'm hoping to implement the bootloader for 4809 and Tiny0/1, in as general a way as possible  "make atmega4809 UART=1"), I was speculating that it might make sense to extract the information in the opposite direction.

 

If you start with UART0, you still need PINMUX and PIN that aren't accessible from the .h files.  But if you start with TXPIN, then that immediately implies specific values for which UART and which PINMUX.  A sort of bottom-up vs top-down way of looking at things.  (I think you could encompass the SAMD SERCOM UARTS as well, if you start with both RXPIN and TXPIN...)

 

I guess the "n" in USARTn definitions is essentially useless information.  USARTPB6 would be better...  (and derivable from the atdf.)

 

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

Product Change Notification - SYST-26CXMI943 - 28 Aug 2019 - Data Sheet - ATtiny416/417/814/816/817 Automotive Data Sheet

...

 

Description of Change: Updated the document status and the following sections:

[numerous]

...

 

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

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

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

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


On sale this month at -15% of 23USD.

Water Tolerant 2D Touch Surface Development Kit

[Features tab]

  • Surface Sensor: 5x6 Surface diamond pattern with dedicated driven shield
  • Two Self-Capacitance Touch buttons
  • ATtiny1617 8-bit AVR Microcontroller - 20 MHz, 16 Kbytes Flash, 2 Kbytes RAM,128 bytes of EEPROM
  • Debugging and Programming: mEBDG with CDC UART
  • LEDs to indicate position and mode
  • LED Driver: MCP23017

 

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

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

Ross McKenzie ValuSoft Melbourne Australia

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

These are moving to Microchip Philippines.

Product Change Notification - KSRA-12MQWI134 - 10 Oct 2019 - CCB 3743 Final Notice: Qualification of MPHL as a new final test site for selected Atmel products of ATTINY416 and ATTINY816 device families available in 20L QFN (3x3x0.9mm) packages.

...

 

Affected CPNs:

ATTINY816-MNR

ATTINY416-MBT-VAO

ATTINY816-MBT-VAO

ATTINY816-MFR

ATTINY416-MZT-VAO

ATTINY816-MZT-VAO

 

...

 

Estimated First Ship Date:
November 7, 2019 (date code: 1945)

 

...

 

October 10, 2019: Issued final notification. Attached the qualification report. Provided estimated first ship date to be on November 7, 2019. Corrected Pre change site from ASE9 to ASCL.

 

...

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

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

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

Pages