Getting started ATtiny 1 & 0 series / Application Notes

Go To Last Post
44 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 4

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:

- TB3229 - Getting Started with GPIO

- TB3209 - Getting Started with ADC

- TB3210 - Getting Started with DAC

- TB3211 - Getting Started with AC

- TB3212 - Getting Started with TCD

- TB3213 - Getting Started with RTC

- TB3214 - Getting Started with TCB

- TB3215 - Getting Started with SPI

- TB3216 - Getting Started with USART

- TB3217 - Getting Started with TCA

- TB3218 - Getting started with CCL

- AN3007 - Getting Started with FreeRTOS on megaAVR 0-series

- AN2451 - Getting Started with Core Independent Peripherals on AVR Microcontrollers

- AVR1000: Getting Started with Writing C-Code for XMEGA

- AVRAPPS-1544:Getting Started with Events on the tinyAVR 1-series

 

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.

------------------------------------------------------------------------------------------------------------------------------------

C Codes:

 

- Getting started with GPIO

- Getting started with TWI -> See the attachment

 

This code includes: Blinking a LED, Long and short Button press, Wake up on Button Press

 

- Discussion about USART Github example can be found in this thread:

https://www.avrfreaks.net/forum/...

 

- Discussion about Power consumption "Power Down" mode with PIT can be found in this thread:

https://www.avrfreaks.net/forum/...

 

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

19/08/2019: Added links to Micochip repository with examples to: Blinking a led, Long and short Button press, Wake up on Button Press.

22/08/2019: Added link to other thread discussing about the USART in ATtiny404 (similar to 1 & 0 series)

27/08/2019: Added attachment to Getting started with TWI, "C Codes" section

07/10/2019: Added application note "Getting started with GPIO"

17/10/2019: Added link to thread about Power consumption with PIT and Power Down mode

 

Attachment(s): 

Last Edited: Thu. Oct 17, 2019 - 08:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

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

 

The parent of that is this page:

 

https://github.com/MicrochipTech

 

where a search for "TB32" proves useful.

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

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

 

The parent of that is this page:

 

https://github.com/MicrochipTech

 

where a search for "TB32" proves useful.

 

indeed, thats a useful tip, thanks.

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

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

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

El Tangas wrote:

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

Welcome, hope it helps.

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

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.

 

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

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.

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

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

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

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

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

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

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

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

Hi again everybody,

 

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

 

  <module id="I2108" name="USART">
          <instance name="USART0">
            <register-group address-space="data" name="USART0" name-in-module="USART" offset="0x0800"/>
            <signals>
              <signal field="PORTMUX.CTRLB.USART0" function="USART0_ALT" group="RXD" pad="PA2"/>
              <signal field="PORTMUX.CTRLB.USART0" function="USART0" group="RXD" pad="PB3"/>
              <signal field="PORTMUX.CTRLB.USART0" function="USART0_ALT" group="TXD" pad="PA1"/>
              <signal field="PORTMUX.CTRLB.USART0" function="USART0" group="TXD" pad="PB2"/>
              <signal field="PORTMUX.CTRLB.USART0" function="USART0_ALT" group="XCK" pad="PA3"/>
              <signal field="PORTMUX.CTRLB.USART0" function="USART0" group="XCK" pad="PB1"/>
              <signal field="PORTMUX.CTRLB.USART0" function="USART0_ALT" group="XDIR" pad="PA4"/>
              <signal field="PORTMUX.CTRLB.USART0" function="USART0" group="XDIR" pad="PB0"/>
            </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:

 

Please check this appnote

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

 

Last Edited: Tue. Feb 26, 2019 - 08:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)

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

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)

 

Well, the answer to your question is:

They dont care.

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

In addition to reading the datasheets, have a look

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

 

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

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.

 

edit : Atmel Studio 7 - Device Pack Manager

 

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

Last Edited: Tue. Feb 26, 2019 - 07:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

edit : Atmel Studio 7 - Device Pack Manager

 

 

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

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

Well, the answer to your question is:

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  

 

Add :

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

Last Edited: Wed. Feb 27, 2019 - 08:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:

Well, the answer to your question is:

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  

 

Add :

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.

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

avr-mike wrote:

In addition to reading the datasheets, have a look

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

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

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.

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

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.

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

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 
to the read-while-write section or the non-read-while-write section.

\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 
linker file or Toolchain->AVR/GNU Linker->Memory Settings in STUDIO. 
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
*-Z(CODE)BOOTLOADER_SEGMENT=7e00-7FFF* to the linker file


\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 
operation has completed. All Flash read and write functions address 
the Flash using byte addresses.

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
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

 

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

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

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

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:

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

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

 

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

Update for " TB3216 - Getting Started with USART ":

 

I guess they somehow optimized the code:

 

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

 

 

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

Update 03/04/2019:

 

AN3007 - Getting Started with FreeRTOS on megaAVR 0-series

 

I will add it to the main thread.

 

Regards,

Moe

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

Update 19/08/2019 :

 

Github - Getting started with GPIO

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

Those “getting started” examples are very minimalistic, bare-metal code. No “Start”, no “ASF”...
Very nice; a welcome addition!

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

Anything similar for the MegaAVR 0-Series? Not sure where I would look to find things like this.

 

Hmmmmm, sorry, when I look at the ADC one, it says MegaAVR 0-Series right at the top. Will give the whole list a good review.

 

Thanks.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Aug 19, 2019 - 10:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Where is "Getting Started with TWI" ?

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

Yes, however I opened an issue on that code. I think the way they use &= and |= to clear/set PORT bits is sub-optimal because the PORTx registers are not within range of sbi/cli. That's why these chips have PORTx SET/CLR/TGL registers.

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

That's why these chips have PORTx SET/CLR/TGL registers.

Also VPORTx...

 

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

GermanFranz wrote:
Where is "Getting Started with TWI" ?

We are still waiting for that one....

  However a freak provided this awhile back, see attached zip file

Jim

 

Attachment(s): 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

Herr Franz,

GermanFranz wrote:

Where is "Getting Started with TWI" ?

 

usually in modern times/also old times they add "please" at the end when you ask this kind of questions.

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

ki0bk wrote:

GermanFranz wrote:
Where is "Getting Started with TWI" ?

We are still waiting for that one....

  However a freak provided this awhile back, see attached zip file

Jim

 

Thanks Jim!

Last Edited: Tue. Aug 20, 2019 - 01:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Update 27/08/19:

 

added attachment for TWI (From Jim).

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

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

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

 

added to the main thread, thanks gchapman!