ATtiny417 / ATtiny814 / ATtiny816 / ATtiny817

Go To Last Post
285 posts / 0 new

Pages

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

ok I get it 

 

But as #148 if no speed needed (init) just make a simple loop. (using st z+,r24) 

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

You need to change the links in #1, Atmel has updated

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

No,  I have not looked at your datasheet.

 

You can normally turn pullups on or off via the VPORTx register.   Just like on an regular AVR PORTx.

 

Since you have a real chip and a real AS7 installation,  you can inspect the PORTx register structure as you manipulate individual VPORTx registers.

I suppose that I could do it in the Simulator since I do not have your hardware.

 

OTOH,   I doubt if you would believe the Simulator (even though it is supposed to be built from the Silicon design files)

 

You can do the same exercise on an Xmega.   i.e. manipulating OUT register or the steering registers.

 

Has anyone built an 8kB application yet?

And observed how long it takes for UPDI to upload the Flash from the ELF file compared to an XMINI with debugWIRE.

 

David.

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

If you want to use the built-in mEDBG virtual com port, remember to use a terminal program that sets DTR. That had me running around in circles for a while.

For reference, here is a small testprogram, that repeatedly sends "Hello world" on the serial port:

 

#define F_CPU 20000000UL
#define BAUDRATE 115200UL
#define CALC_BAUD  ((64 * F_CPU + 8 * BAUDRATE) / (16 * BAUDRATE))

#include <stdio.h>
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <util/delay.h>

static int uart_putchar(char c, FILE *stream)
{
    if (c == '\n')
        uart_putchar('\r', stream);
    while ((USART0.STATUS & USART_DREIF_bm) == 0) {}
    USART0.TXDATAL = c;
    return 0;
}

static FILE mystdout = FDEV_SETUP_STREAM(uart_putchar, NULL, _FDEV_SETUP_WRITE);

int main(void)
{
    // Disable prescaler, run at 20 MHz
    _PROTECTED_WRITE(CLKCTRL_MCLKCTRLB, 0);

    // Init USART
    PORTB.OUTSET = PIN2_bm;
    PORTB.DIRSET = PIN2_bm;
    PORTB.DIRCLR = PIN3_bm;
    USART0.CTRLA = USART_RS485_OFF_gc;
    USART0.CTRLC = USART_CMODE_ASYNCHRONOUS_gc | USART_PMODE_DISABLED_gc | USART_SBMODE_1BIT_gc | USART_CHSIZE_8BIT_gc;
    USART0.BAUD = CALC_BAUD;
    USART0.DBGCTRL = USART_DBGRUN_bm;
    USART0.CTRLB = USART_RXEN_bm | USART_TXEN_bm | USART_RXMODE_NORMAL_gc;

    // Redirect stdout to USART
    stdout = &mystdout;

    // Main loop
    while (1)
    {
        _delay_ms(1000);
        printf_P(PSTR("Hello world\n"));
    }
}

Edit: Fixed USART0.CTRLB register

Last Edited: Sun. Nov 20, 2016 - 01:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
allow multiple pins to be pulled up
clawson wrote:
Not using VPORTs then?

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

I still don't see how pullups can be turned on on multiple pins at the same time like the old PORTx=0xFF, please provide a page in the datasheet showing this.

 

I can only see things like

7.6.4. Pin Configuration
The Pin n Configuration register (PORT.PINnCTRL) is used to configure inverted I/O, pullup, and input
sensing of a pin
.

.

Pullup of pin n is enabled by writing a '1' to the Pullup Enable bit (PULLUPEN) in PORT.PINnCTRL

but that's 1 pin at a time.

 

I don't see that writing PORTx=0xFF to the VPORT.OUT will turn on pullups like it used to.

(edited DDRx=0xFF to PORTx=0xFF and VPORT.OUT) and by the way I don't have the real chip yet.smiley

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Sun. Nov 20, 2016 - 08:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just checked in the simulator and:

    VPORTB_DIR = 0x00;
    VPORTB_OUT = 0xFF;

 

don't set the pull up bit, so I guess it's a no go (as expected).

So I tried this :

uint8_t *temp=(uint8_t *)0x430 ;

for (uint8_t n=0;n<8;n++)
  *temp++=0x08;

  And it does the correct job , but the code is NOT as expected!!!

    for (uint8_t n=0;n<8;n++){
		*temp++=0x08;
  5c:	88 e0       	ldi	r24, 0x08	; 8
  5e:	80 93 30 04 	sts	0x0430, r24	; 0x800430 <__TEXT_REGION_LENGTH__+0x700430>
  62:	80 93 31 04 	sts	0x0431, r24	; 0x800431 <__TEXT_REGION_LENGTH__+0x700431>
  66:	80 93 32 04 	sts	0x0432, r24	; 0x800432 <__TEXT_REGION_LENGTH__+0x700432>
  6a:	80 93 33 04 	sts	0x0433, r24	; 0x800433 <__TEXT_REGION_LENGTH__+0x700433>
  6e:	80 93 34 04 	sts	0x0434, r24	; 0x800434 <__TEXT_REGION_LENGTH__+0x700434>
  72:	80 93 35 04 	sts	0x0435, r24	; 0x800435 <__TEXT_REGION_LENGTH__+0x700435>
  76:	80 93 36 04 	sts	0x0436, r24	; 0x800436 <__TEXT_REGION_LENGTH__+0x700436>
  7a:	80 93 37 04 	sts	0x0437, r24	; 0x800437 <__TEXT_REGION_LENGTH__+0x700437>

And this is even with -Os  stupid compiler! , that is code I would expect for -O3 , 34 bytes, for what could be done in 4 bytes on a tiny  (and with full bit control).

How to write the code so it make a loop? 

 

And here is a simple ASM code that do the same as a tiny (if that is the only bit set in PINnCTRL):

    ldi ZH,high(0x0430)
    ldi ZL,low(0x0430)
    ldi r24,0x55 // mask for the 8 bits
L0: ldi r25,0 // clr value
    lsr r24
    brcc L1
    ldi r25,0x08 //set value
L1: st z+,r25
    cpi ZL,low(0x0430+8)
    brne L0

 

 

 

 

Last Edited: Sun. Nov 20, 2016 - 10:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For 8 bits I would do it the same as the compiler output as it is faster but not a big deal I guess.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

So now that we have some confirmation that group pull up enable is not possible I have added pull up code.

 

However the simulator seems to be screwed up and even though the bits are set they are not reflected in the state of PORTA_IN.

 

Also I have used Vports for this version but don't know if it will work, the simulator is not skipping the next instruction if the port pin is high as it should.

"Set next statement" at the cursor is also broken, so back to AS4.18 for real work.

;***** STK500 LEDS and SWITCH demonstration 
.nolist
.include	"ATtiny817def.inc"
.list

.def	temp = r24			; temporary register 
.def	Delay = r17			; Delay variable 1 
.def	Delay2 = r18		; Delay variable 2 

.dseg
test_label:	.byte 1

.cseg
;***** Initialization 
RESET: 
	ser		temp 
	out		VPORTB_DIR, temp		; Set PORTB to output 

	ldi		temp, PORT_PULLUPEN_bm	; Pull up enable bit mask used
; All pins on PORTA with pullups
	sts		PORTA_PIN0CTRL, temp
	sts		PORTA_PIN1CTRL, temp
	sts		PORTA_PIN2CTRL, temp
	sts		PORTA_PIN3CTRL, temp
	sts		PORTA_PIN4CTRL, temp
	sts		PORTA_PIN5CTRL, temp
	sts		PORTA_PIN6CTRL, temp
	sts		PORTA_PIN7CTRL, temp

;**** Test input/output 
LOOP: 
	out		VPORTB_OUT, temp	; Update LEDS 
	sbis	VPORTA_IN, 0x00		; If (Port A, pin0 == 0) 
	inc		temp				; then count LEDS one down 
	sbis	VPORTA_IN, 0x01		; If (Port A, pin1 == 0) 
	dec		temp				; then count LEDS one up 
	sbis	VPORTA_IN, 0x02		; If (Port A, pin2 == 0) 
	ror		temp				; then rotate LEDS one right 
	sbis	VPORTA_IN, 0x03		; If (Port A, pin3 == 0) 
	rol		temp				; then rotate LEDS one left 
	sbis	VPORTA_IN, 0x04		; If (Port A, pin4 == 0) 
	com		temp				; then invert all LEDS 
	sbis	VPORTA_IN, 0x05		; If (Port A, pin5 == 0) 
	neg		temp				; then invert all LEDS and add 1 
	sbis	VPORTA_IN, 0x06		; If (Port A, pin6 == 0) 
	swap	temp				; then swap nibbles of LEDS 

	push	temp
	lds		temp, test_label
	subi	temp, -1
	sts		test_label, temp
	pop		temp

   ;**** Now wait a while to make LED changes visible. 
DLY: 
	dec		Delay 
	brne	DLY 
	dec		Delay2 
	brne	DLY
	rjmp	LOOP			; Repeat loop forever 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

sparrow2 wrote:
How to write the code so it make a loop?
Wonder if -fnounroll-loop might help?

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

Unless of course one must write to some register to move the ports into virtual space?? It doesn't look like as each I/O port can either be addressed as PORTx or VBPORTx?

 

Not clear to me.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

make sure that PORT_PULLUPEN_bm actually is 0x08 .

 

I could be wrong but I would not expect a pullup in the simulator to make the input high as default.

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

js wrote:
Unless of course one must write to some register to move the ports into virtual space??
That's certainly the way it works in Xmega. Sadly they only allowed for four VPORTS so you have to pick your four most used IO ports and then set registers to map those to VPORT for you might have something like 0=B, 1=C, 2=F, 3=E or similar. In Xmega this is achieved with VPCTRALA and VPCTRLB. Each register is two lots of 4 bits where the 16 possibilities of the 4 bits allow for 0000=A to 1111=R (no PORTI or PORTO). So my example might be:

VPCTRLA = 0b00100001; // 0=0001=B, 1=0010=C
VPCTRLB = 0b01000101; // 2=0101=F, 3=0100=E

 

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

Pull ups are enabled but nothing on PORTA_IN

 

 

manually turning on bits on PORTA_IN allows the code to skip the next instruction

 

 

and result of trying to "Set next statement" at the cursor

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

The VPORT's are fixed on this chip, (at least that is the way the I read the manual).

 

And with all this, and if the plan is to make more of this kind of "xtiny's" I really suggest that they get's there own forum.

 

The confusion will go both ways, when there start to come good things for the 817, "new" people can't get it to work on a tiny85 etc.  

Last Edited: Mon. Nov 21, 2016 - 10:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pull-ups and pull-downs on the simulator is a tricky thing, since we have no way of knowing if the pin is being driven or if it's unconnected. For simplicity it's designed to always assume an external active driver when the pin is configured as input.

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

sparrow2 wrote:
The VPORT's are fixed on this chip, (at least that is the way the I read the manual).
I wonder what makes them "virtual" then? Surely a VPORTx register is just a low mapped part of the PORTx registers ? It's not really "virtual" in any sense?

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

Again it's to avoid name conflict with the PORT.nnn block.

 

It make sense on a xmega, but not at all on a chip like this.

It's all in all a very bad use of SBI/CBI IN/OUT space, again don't really matter for a xmega with 128K flash (where there are to many things so it can't fit, so the .set .clr was made), but for the small chips it make a difference.

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

js wrote:
Pull ups are enabled but nothing on PORTA_IN
je_ruud wrote:
Pull-ups and pull-downs on the simulator ...

 

Agreed that the simulator doesn't know (or shouldn't assume) that internal pullup will pull the pin high.

 

But why did we get a response from an Atmel person on that, and not on whether the VPORTs are hard-mapped?

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

But why did we get a response from an Atmel person on that, and not on whether the VPORTs are hard-mapped?

It depends on the importance of the person asking the question.........cheeky

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Are there any one that know how good the temperature sensor is ? (I can't find anything in the datasheet)

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

The timers are of the type A, B and D , what does that mean ? (I can't find a reference, but guess it has something to do with some Xmega things)

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

And it has arrived :)

 

 

 

Problem is, I haven't even installed the new Atmel Studio version. What should I write for the ATtiny817? I have to think about it.

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

js wrote:
It looks like the 10pin 50mil header is the new programmer/debugger interface connector that directly interfaces with the Atmel ICE and Jtag Mk3.

Tag Connect

10-pin Cortex Ribbon Cable 4" length with 50 mil connectors

http://www.tag-connect.com/CORTEXRIBBON10

... to a target with a 10-pin 50mil FTSH style header. (The standard 10-pin Cortex header).

 

The default length is nominally 100mm  (4") but we can make it any length you like if you specify the desired length in the Comments section of the Checkout page and ...

 

The connectors fitted to this cable are Harwin M50-3300542 or equivalent and mate with e.g. Samtec FTSH family headers.

...


Atmel-ICE

Target Connectors Part Numbers

http://www.atmel.com/webdoc/GUID-DDB0017E-84E3-4E77-AAE9-7AC4290E5E8B/index.html?GUID-A0302E02-2F2B-4AED-B3B0-6150ED875E0F

Atmel-ICE

Spare Parts Kits

http://www.atmel.com/webdoc/GUID-DDB0017E-84E3-4E77-AAE9-7AC4290E5E8B/index.html?GUID-18FDC56F-A8BB-4304-9798-6C9F2BD75F69

https://octopart.com/search?q=ATATMEL-ICE-CABLE&avg_avail=(1__*)&start=0

 

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

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

Got my board today, thank you! laugh Surprisingly it survived the international postal services, the box was squashed but the board looks ok. At least the drivers installed successfully.

 

Now to have a play.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Is the board supposed to have any firmware in it and do something?? There seems to be just over 1k of code in it but the switches and LED do nothing.

 

I have just fitted "Arduino" style headers so that I can plug something in and try some of my firmware, I hope I can retrieve what ever is in it now if important.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

If you connect to the CDC (mEDBG Virtual Com Port) with 9600 baudrate you should get a text string every time the button is pressed. 

 

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

blush too late, we now have "ye' olde" flashing light happening. It helps a lot if one switches from Simulator to mEDBG when testing one's software blush

 

Where can I find the hex file for the initial program please?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

If you connect to the CDC

I don't see a new com port on the terminal program (uCon) when I plug the board in, is the mEDBG Virtual Com Port part of Studio? Never used it.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

I've attached the hex dump from a fresh kit. I'm not sure if we actually distribute the source for the shipped example anywhere - will check and get back on that. 

Attachment(s): 

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

js wrote:

If you connect to the CDC

I don't see a new com port on the terminal program (uCon) when I plug the board in, is the mEDBG Virtual Com Port part of Studio? Never used it.

 

It's a standard CDC port, but the drivers are installed when installing Atmel Studio. (C:\Program Files (x86)\Atmel\Studio\Drivers\inf\atmel_devices_cdc if you need to do a manual install)

 

Does it show up in the device manager at all ? 

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

Ok "Button Pressed" message now showing, thank you.

 

I will be wiring my standard USART and TWI headers on the board so that I can plug in my own stuff. I guess I can get away with keeping R206 and R207 mounted so that if I don't have anything plugged into my header I can still use the CDC port.

 

Or maybe I'll fit some jumpers in, I can see where I can connect the USART on the other side of the resistors.

 

Enough fun for the day.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Keep the resistors in. As long as you don't connect to the CDC port on the PC, DTR won't be set which will make the debugger stay away from the pins.

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

The USART pins are taken out to the "Arduino" header so that they can be used and anything on them will override the debugger chip, so it should be safe to leave them in.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

You're right. More of these chips are coming out very soon. They should have a separate forum or they should be on Xmega thread at least. Very confusing huh... wink

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

I say the temperature sensor on these parts are actually pretty decent. They are factory calibrated.

In Chapter 30 of the datasheet (ADC Chapter) there is a mention of the temperature sensor.

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

sparrow2 wrote:

The timers are of the type A, B and D , what does that mean ? (I can't find a reference, but guess it has something to do with some Xmega things)

 

These are indeed similar with the Xmega.

Timers A and B are both 16-bit Timers

Timer D is 12 bit Timer

 

The difference between TCA and TCB is that the TCB can use an external clock source.

More specific information on datasheet chapters 20-22 for each Timer/Counter

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

More of these chips are coming out very soon.

I thought you weren't going to spill the beans.......

They should have a separate forum or they should be on Xmega thread at least.

OK so Morten can change the header on the Xmega forum but you, being almighty and all and with some sort of influence cheeky, must convince the marketing department to rename the new chips (including the 817 family) to Xtiny817 etc.

 

We have an unanimous decision here at Avrfreaks on the Xtiny name, then the forum can be simply renamed to "Xmega and Xtiny".

 

At the moment we have Tiny84, Tiny85, Tiny87 etc. (standard Tiny) with Tiny814,Tiny816, Tiny817 with the new architecture, so yes very conusing.

 

Not so confusing if Xtiny814, Xtiny816, Xtiny817 etc.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

If it's true that there come more of this kind of "xtiny" parts, especial small Atmel (Microchip) please please make the 32 registers memory mapped again.

I don't care where and if it take 3 or 4 clk.

 

Now after 20 years we finally have AVR's where everything are memory mapped so there can be made general routines, but no the register aren't   :(

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

I thought you weren't going to spill the beans.......

LOL. Sorry, I'll hush now. wink

 

being almighty and all and with some sort of influence 

 

Oh no, no, I'm not that almighty outside this text box. I'm just a nerd working to make this world a better place. blush

I'm not sure the Marketing folks will even hear me out with this but Xtiny sounds good. 

 

the forum can be simply renamed to "Xmega and Xtiny".

 

 

if renamed, the forum name can be called  Xmega and TinyXA. laugh

 

 

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

js wrote:
We have an unanimous decision here at Avrfreaks on the Xtiny name, then the forum can be simply renamed to "Xmega and Xtiny".
(intention - to create contrast)

In line with the press release for it, an alternate name is New tinyAVR.

This is akin to Volkswagen Beetle and New Beetle cheeky

CIP is a highlight in the press release though it's been stated here that unified memory is a difference from classic tinyAVR.

Memory addressing is one of the features of a computer architecture.

New tinyAVR has 16-bit unified (code & data) memory addressing.

XMEGA AVR are 24-bit dual (code, data) memory addressing.

Will there be a New megaAVR?

(if yes, stunned I be)


https://www.microchip.com/pressreleasepage/microchips-new-gen-avr-mcus-with-CIPs

http://www.avrfreaks.net/forum/microchipatmel-vps-reading-how-bout-20mhz-12802560 by bobgardner

 

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

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

TinyXA

That would work also as long as the chips are officially known and stamped as such.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

 

TinyX should work... yes

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

Will there be a New megaAVR?

 

But there are already new Mega... the Xmega family wink

 

ATmega328PB family is new. yesyesyes

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

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

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

meolsen wrote:
Pinout in the debugger user guides are still on the pending list

http://www.atmel.com/Images/Atmel-42330-Atmel-ICE_UserGuide.pdf

(file size: 2.6MB, 61 pages, revision C, updated: 10/2016)

...

(page 18)

3.5. Connecting to a UPDI Target

...

http://www.atmel.com/tools/atatmel-ice.aspx?tab=documents 

 

http://www.atmel.com/Images/Atmel-42634-JTAGICE3_UserGuide.pdf

(file size: 2.3MB, 39 pages, revision B, updated: 10/2016)

...

(page 15)

3.7. Connecting to a UPDI Target

...

http://www.atmel.com/tools/jtagice3.aspx?tab=documents

 

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

Last Edited: Wed. Nov 30, 2016 - 03:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

 

Edits : XPRO EOL and Obsolete

 

Seems no one told Digikey, as they now show stocks (46) of XPRO  :)

 

 

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

Then tell them ;)

 

I had them to change the 817's Vcc from a 3.6V to 5.5V 

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

sydalmighty wrote:
TinyX should work... yes
TinyX and tinyX are in the Atmel-ICE manual.

With the planned growth of these, another proposed sub-fora named "AVR tinyX" that lines up next to "AVR XMEGA".


http://www.atmel.com/Images/Atmel-42330-Atmel-ICE_UserGuide.pdf

(file size: 2.6MB, 61 pages, revision C, updated: 10/2016)

...

(page 48)

4.4.17. TinyX-OCD (UPDI) Special Considerations

...

(page 57)

1.36

29.09.2016

Added support for UPDI interface

(tinyX devices)

...

http://www.atmel.com/tools/atatmel-ice.aspx?tab=documents

http://www.avrfreaks.net/forum

 

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

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

david.prentice wrote:

I have always thought that mEDBG is a false economy from Atmel's point of view.   The difference in chip cost (to Atmel) for using a m32u4 instead of a proper EDBG on a UC32 or ARM  chip is trivial.

All the same,   an XMINI is more attractive than an external ATMEL-ICE when you want to encourage customers to evaluate your new chips.    And it works pretty well.

The mEDBG makes sense if you do a filter search on all Atmel parts that support USB and 5V.
Putting a 100-pin BGA on a board like the XMINI and XNANO seems like overkill too.

Pages