## Getting started ATtiny 1 & 0 series / Application Notes

32 posts / 0 new
Author
Message

Hi all,

Because I think there is a big lack of knowledge of the new ATtiny 1 series and 0 series about in topics likes timers (TCA, TCB , TCD) ,ADC , DAC,TWI...etc. I saw recently that MC has updated some application notes on "How to get started", I thought its a good idea to post the links here so it can help beginners to look up for these notes themselves and after that if there is any questions they can share it in freaks, the notes has has some basic source codes that can be adapted to any mcu from tiny 1 and tiny 0 series.

so here it is:

These are just links to the Appnotes, so its just a copy/paste. I posted it here because i noticed many of the new attiny users overlook these notes which might be helpful, althought i havent tested the whole source codes but so far it all compiled. with small changes you can also adapt it to any part in the tiny 1 & 0 series.

*Source: Microchip

Regards,

Moe

EDIT:

15/05/2019: Added getting started with FreeRTOS with megaAVR 0-series (Also valid for ATtiny 1 series).

21/05/2019: Added getting started with core independant peripherals (valid for ATtiny 1 & 0 series).

19/07/2019: Added getting started with writing C-Code for XMEGA (valid for ATtiny 1 & 0 series).

24/07/2019: Added getting started with Events in the tinyAVR 1-series (valid for ATtiny 1 & 0 series).

Last Edited: Wed. Jul 24, 2019 - 11:51 AM

Interesting - just looked at the ADC one - note that it (and presumably others?) ends with a link to the example code on Github such as:

https://github.com/MicrochipTech...

https://github.com/MicrochipTech

where a search for "TB32" proves useful.

clawson wrote:

Interesting - just looked at the ADC one - note that it (and presumably others?) ends with a link to the example code on Github such as:

https://github.com/MicrochipTech...

https://github.com/MicrochipTech

where a search for "TB32" proves useful.

indeed, thats a useful tip, thanks.

Thanks, this stuff is useful and I hadn't seen it yet.

El Tangas wrote:

Thanks, this stuff is useful and I hadn't seen it yet.

Welcome, hope it helps.

Source codes in appnote for ADC looks little bit confusing. They dont contain VREF settings and corresponding selection of sampling capacitor (5pF for references over 1V). And especially they clears RESRDY flags twice ! Datasheet claims that flag RESRDY is cleared by writing 1 or reading ADC.RES (verified that works) ... examples do both of them. (Why ?) Also missing informations about precise timing (inter conversion delay in ADC.CTRLD), sampling time (SAMPCTRL) - expected in free ruinning mode.

If anyone from Microchip is reading this, a "Getting started with programming UPDI yourself" and a "Getting started with Sleep mode" are the obvious missing documents in the set.

as you said, google search will return you mostly with attiny85...

From the datasheet : When the USART is set in one-wire mode, the transmitter and receiver share the same RxD I/O pin

From the app-note : When the USART is set in one-wire mode, the transmitter and receiver share the same TxD I/O pin

Did Microchip/Atmel spend any effort at all on their documentation.  I'll let you know which is right in a few hours !!

Yes it's the TxD pin !   Thanks Microchip, that means my board needs a respin as no-way to program around this :-(

Last Edited: Mon. Feb 25, 2019 - 10:54 PM

Incredible. This is a serious mistake in the datasheet. In fact, in all AVR 0/1 datasheets, since they are all copy/pasted, it seems.

I've tried everything to get TXdata onto the RxD pin as per the datasheet and nothing works.

It also looks like the line needs a pullup resistor as the waveform is anything but square even at 9600 baud

Last Edited: Mon. Feb 25, 2019 - 11:25 PM

I guess from now on I will just assume these appnotes are the real datasheets.

Well I never got TCB waking up from sleep mode working properly yet

Hi again everybody,

So here is what I think, from the XML description in attiny404:

  <module id="I2108" name="USART">
<instance name="USART0">
<signals>
</signals>

This leaves no doubt that the RxD is ported to PA2 and PB3, TxD is ported to PB2/PA1.

What this crap datasheet says is totally contradicting their own XML implementation. Mike i doubt if it works for you as per the datasheet says

EDIT:

http://ww1.microchip.com/downloa...

Last Edited: Tue. Feb 26, 2019 - 08:18 AM

Thanks - the appnote is most helpful as it mostly confirms what I found last night, though the order in which you write to registers seems to be important as well but isn't spelled out in this note.  I'm just rewiring by board to tidy up the mess from last night's experiments.   Another key point is to write to USART0_CTRLB once and then never touch it again or you'll need to start all over again.

As you say, the datasheets are absolutely misleading.  But then again the TCB appnote doesn't work as suggested either - I still haven't got TCB to run a one-shot sleep then stop.  Everything I do seems to set it up to interrupt every second which isn't what I want.   It's as though the counter doesn't reset when the timer is started and stopped but carries on cycling around.

Also interesting to note they seem happy with running one-wires into each other here but in the UPDI programming they always recommend a series resistor 'just in case' ;-)

Last Edited: Tue. Feb 26, 2019 - 10:13 AM

Hi,

dunno if it works, but try something like this:

#include <avr/io.h>

void Config_TCB(void);

int main(void)
{

Config_TCB();
while (1)
{

}
}

void Config_TCB(void)
{
PORTA.DIR |=1<<5; // TCB(PA5) as output in ATtiny404

TCB0.CTRLB = TCB_CNTMODE_PWM8_gc | TCB_CCMPEN_bm; // (0x07<<0 | 1<<4) 8-bit PWM mode,CCMPEN
TCB0.CCMPL = 250; // period of one PWM cycle
TCB0.CCMPH = 125; // ON time
TCB0.CTRLA =TCB_ENABLE_bm; //(1<<0) enable
}


Does this solve the issue ?

Last Edited: Tue. Feb 26, 2019 - 10:15 AM

And the big question for me is why don't it get changed, when it's clear for the one that did the app-note know that the data sheet is wrong (or perhaps he knew that using TX is the only logic way so he didn't read the datasheet)

sparrow2 wrote:

And the big question for me is why don't it get changed, when it's clear for the one that did the app-note know that the data sheet is wrong (or perhaps he knew that using TX is the only logic way so he didn't read the datasheet)

They dont care.

through the chip-specific include file that avr/io.h

pulls in.  These tend to be almost error-free (but

you may find a few things wrong).  Grab the latest

version(s) of the device packs from Microchip.com

first.

--Mike

avr-mike wrote:
Grab the latest

version(s) of the device packs from Microchip.com

first.

via Atmel Studio

IIRC, Atmel Packs might be a step behind.

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

Last Edited: Tue. Feb 26, 2019 - 07:11 PM

gchapman wrote:

avr-mike wrote:

Grab the latest

version(s) of the device packs from Microchip.com

first.

via Atmel Studio

IIRC, Atmel Packs might be a step behind.

I always had this problem with AS7 device pack....dunno why its not working, It keeps saying "Update available" even after I update to the latest version..

They dont care.

But why do they then care making app. notes then? (The info about a chip should be only one place)

I know Atmel was bad, but I experted microchip to be more professional

Someone at microchip can pm me if they need some help!

Last Edited: Wed. Feb 27, 2019 - 08:19 AM

sparrow2 wrote:

They dont care.

But why do they then care making app. notes then? (The info about a chip should be only one place)

I know Atmel was bad, but I experted microchip to be more professional

Someone at microchip can pm me if they need some help!

I suspect the issue is like this, so they have different teams for documentation of datasheets, this is done by outsourcing to another company maybe. While the appnote is mostly written by highly expert engineers from Atmel/MC themselves. so thats why the quality is different.

avr-mike wrote:

through the chip-specific include file that avr/io.h

pulls in.  These tend to be almost error-free (but

you may find a few things wrong).  Grab the latest

version(s) of the device packs from Microchip.com

first.

--Mike

Yes and No, these also are highly misleading in ATtiny series 1 & 2, for example in the library of iotn212.h (ATtiny212) version 1.3.229 (Latest device pack!), you can find the following lines for EVSYS:

typedef enum EVSYS_ASYNCCH2_enum
{
EVSYS_ASYNCCH2_OFF_gc = (0x00<<0), /* Off */
EVSYS_ASYNCCH2_CCL_LUT0_gc = (0x01<<0), /* Configurable Custom Logic LUT0 */
EVSYS_ASYNCCH2_CCL_LUT1_gc = (0x02<<0), /* Configurable Custom Logic LUT1 */
EVSYS_ASYNCCH2_AC0_OUT_gc = (0x03<<0), /* Analog Comparator 0 out */
EVSYS_ASYNCCH2_TCD0_CMPBCLR_gc = (0x04<<0), /* Timer/Counter D0 compare B clear */
EVSYS_ASYNCCH2_TCD0_CMPASET_gc = (0x05<<0), /* Timer/Counter D0 compare A set */
EVSYS_ASYNCCH2_TCD0_CMPBSET_gc = (0x06<<0), /* Timer/Counter D0 compare B set */
EVSYS_ASYNCCH2_TCD0_PROGEV_gc = (0x07<<0), /* Timer/Counter D0 program event */
EVSYS_ASYNCCH2_RTC_OVF_gc = (0x08<<0), /* Real Time Counter overflow */
EVSYS_ASYNCCH2_RTC_CMP_gc = (0x09<<0), /* Real Time Counter compare */
EVSYS_ASYNCCH2_PORTC_PIN0_gc = (0x0A<<0), /* Asynchronous Event from Pin PC0 */
EVSYS_ASYNCCH2_PORTC_PIN1_gc = (0x0B<<0), /* Asynchronous Event from Pin PC1 */
EVSYS_ASYNCCH2_PORTC_PIN2_gc = (0x0C<<0), /* Asynchronous Event from Pin PC2 */
EVSYS_ASYNCCH2_PORTC_PIN3_gc = (0x0D<<0), /* Asynchronous Event from Pin PC3 */
EVSYS_ASYNCCH2_PORTC_PIN4_gc = (0x0E<<0), /* Asynchronous Event from Pin PC4 */
EVSYS_ASYNCCH2_PORTC_PIN5_gc = (0x0F<<0), /* Asynchronous Event from Pin PC5 */
} EVSYS_ASYNCCH2_t;


This is completly wrong as there is no PORTC in this chip. this brings up again to one question, what is the most reliable source to have information about the lower pin chips of Attiny 1 & 0 series ?

I have no idea. because:

1- The device header is just a copy/paste.

2- The datasheet is a copy/paste.

3- Sources in appnotes compiles but doesnt do what is described.

Now sometime ago when I started using one of these chips, the thread discussing tiny series 1 and 0 were quite few, appnotes were not there (These appnotes published beginning of this year 2019). but right now i see more and more people coming forward with much expertise in this. So this forum was quite helpful.

Regards,

Moe

In short stay away form attiny-0 -1 chips until someone get the act together, the old tiny's works, and we are many in this forum that has used them for many years.

Thanks,

has anyone seen or got an example of using the eeprom peripheral to store (e.g. configuration) persistent data? This might be called "User Row" - the datasheet is somewhat difficult in describing the functions of the NVRAM controller.

markxr wrote:

Thanks,

has anyone seen or got an example of using the eeprom peripheral to store (e.g. configuration) persistent data? This might be called "User Row" - the datasheet is somewhat difficult in describing the functions of the NVRAM controller.

Maybe you can give a look at this Application note:

Writing to Flash and EEPROM on the tinyAVR 1-series

Example code from START:

https://start.atmel.com/#applica...

In the example try to check the doxygen files for the NVMCTRL, it might help you as well. I found this information there:

The **NVMCTRL Basic** driver provides basic NVM programming functionality,
that is:
- Read and write to EEPROM
- Read and write to Flash

The NVMCTRL Basic driver has two modes of operation:
- Blocking (polled) writing to EEPROM
- Non-blocking (interrupt-driven) writing to EEPROM

NVMCTRL Basic functions writing to flash are always blocking: Program
execution waits until write has completed, regardless of writing

\section doc_driver_nvmctrl_basic_configuration Driver Configuration

The NVMCTRL Basic driver is configured using START. The user can
choose from the two modes of EEPROM operation (polled/IRQ).
START also allows the user to select other device-dependent features
such as setting Boot Lock bits etc.

START allows the user to select whether or not to place Flash functions
in a separate segment. Some devices (e.g. Mega328PB) require the Flash
write functions to be located in a section separate from the section
being written. For these devices, the Flash write function should be
located in the *Boot Loader Section (BLS)*, while the data being programmed
should be in the *Application Section*. By placing flash write functions
in a separate segment, it is easy to locate this segment in the BLS.
The size of the BLS is device-dependent, and can often be controlled
by fuses (typically called BOOTSZ), see the device datasheet.

By ticking the "Place Flash Functions in Separate Segment" check box
in START, all Flash write functions are placed in a segment called:

- For the GCC compiler: .bootloader
- For the IAR compiler: BOOTLOADER_SEGMENT

For the GCC compiler, the segment must be given a location in the
Example: For a device with 32kb flash and 512 bytes BLS, write
*.bootloader=0x3f00* in the *FLASH segment* box in Memory Settings
in STUDIO.

For the IAR compiler, the segment must be described in the linker file.
Example: For a device with 32kb flash and 512 bytes BLS, add

\section doc_driver_nvmctrl_basic_functional Functional Description

\subsection doc_driver_nvmctrl_basic_polled Blocking/Polled EEPROM write

In this mode, EEPROM writes of a byte or a block is performed in
a blocking way, the write function does not return until all bytes
have been written.

\subsection doc_driver_nvmctrl_basic_sync Non-blocking/IRQ-driven EEPROM write

In this mode, EEPROM writes of a byte or a block are performed by an ISR.
The ISR is called whenever the EEPROM is ready for another EEPROM write.
The EEPROM byte or block write function returns immediately after setting
up the data structures necessary for controlling the ISR. The application
can then proceed to do other things (or go to sleep) while the EEPROM
write is being performed. A polling function <component_name>_is_EEPROM_ready()
is provided to check when the EEPROM write has completed.

If an EEPROM write-function is called before the previous EEPROM
write-function has completed, the newest EEPROM write function will block
until the previous write has completed.

If an EEPROM read-function is called before the previous EEPROM
write-function has completed, the EEPROM read function will block
until the previous write has completed.

If the driver is configured to be Non-blocking, a function
<component_name>_register_callback() is provided. This function allows
registering a callback function to be called when all EEPROM writes
triggered by a call to an EEPROM write command have completed.

\subsection doc_driver_nvmctrl_basic_flash Flash write

All Flash write functions are blocking: They don't return until the

There may be device-dependent limitations on where the Flash write functions
may be located in Flash, see \ref doc_driver_nvmctrl_basic_configuration.
In most devices, reading the Flash while it is being programmed will cause
instruction execution to freeze until the write has completed. This will
impact interrupt resonse time during Flash programming to the Application
Section, since the interrupt vectors are located in the Application Section.

Most flash write functions have an input parameter *uint8_t *ram_buffer*.
This is a pointer to a buffer in RAM that must be at least as large as
a Flash page. This buffer is used when doing read-modify-write operations
on flash: One Flash page is read from Flash into this buffer, then the
buffer is modified as desired, before the Flash page is erased and
written with the contents of the buffer. In some devices such as Tiny817
the Flash page buffer is memory mapped. In the NVMCTRL Basic driver for
these devices, the *ram_buffer* parameter is unused, but kept for API
compatibility with other devices. When calling the Flash write functions
for these devices, the *ram_buffer* parameter is unused by the functions
and NULL can be passed as argument when calling them.

A streaming flash write function is included, intended to be used in
devices where a lot of data is to be written contiguously to flash, and:

- RAM resources are too limited to afford a buffer needed by the write
and erase page functions
- performance needs and code size concerns leaves the byte write and block
write functions too expensive

\section doc_driver_nvmctrl_basic_hardware Hardware Dependencies

The NVMCTRL Basic driver uses the NVM controller hardware available
on all AVR devices. The driver does not use any I/O pins.

The configuration options in START displays options that are
dependent on the hardware used to implement the NVMCTRL driver.
For example, an option may allow setting the Boot Lock Bit
inhibiting writes to the BLS.

\section doc_driver_nvmctrl_basic_software Software Dependencies

The interrupt-driven configuration use the interrupt functionality
of the underlying NVMCTRL hardware. Make sure that global interrupts
are enabled (using sei()) and that the Interrupt Controller, if
present, is configured so that any interrupts are serviced
correctly.
Last Edited: Mon. Mar 25, 2019 - 06:35 AM

It's alright - I've worked it out.

#include <avr/eeprom.h>

void eeprom_read_block (void *__dst, const void *__src, size_t __n);
void eeprom_update_block (const void *__src, void *__dst, size_t __n);


These functions work fine for me.

The pointer to eeprom addresses, starts at zero, i.e. it's ok to pass (void *) 0 to these functions, and the block will be written / read from the start of eeprom. The actual eeprom address is something like 0x1400, but don't pass that as the argument.

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

I had a quick look at the code and have to ask :

Don't microchip have any internal guidelines about C style ?

This make me sad to see next to each other:

{
while (!(USART0.STATUS & USART_DREIF_bm))
{
;
}
}

status_t waitSendConfirmation(void)
{
sendingStatus = SENDING;
/* Will change inside RXC interrupt handler */
while(sendingStatus == SENDING);
return sendingStatus;
}

Update for " TB3216 - Getting Started with USART ":

I guess they somehow optimized the code:

https://github.com/MicrochipTech...

Update 03/04/2019:

AN3007 - Getting Started with FreeRTOS on megaAVR 0-series