AVR Freaks

Given that the 4809 have ports with:

/* I/O Ports */
typedef struct PORT_struct
{
    register8_t DIR;  /* Data Direction */
    register8_t DIRSET;  /* Data Direction Set */
    register8_t DIRCLR;  /* Data Direction Clear */
    register8_t DIRTGL;  /* Data Direction Toggle */
    register8_t OUT;  /* Output Value */
    register8_t OUTSET;  /* Output Value Set */
    register8_t OUTCLR;  /* Output Value Clear */
    register8_t OUTTGL;  /* Output Value Toggle */
    register8_t IN;  /* Input Value */
    register8_t INTFLAGS;  /* Interrupt Flags */
    register8_t PORTCTRL;  /* Port Control */
    register8_t reserved_0x0B;
    register8_t reserved_0x0C;
    register8_t reserved_0x0D;
    register8_t reserved_0x0E;
    register8_t reserved_0x0F;
    register8_t PIN0CTRL;  /* Pin 0 Control */
    register8_t PIN1CTRL;  /* Pin 1 Control */
    register8_t PIN2CTRL;  /* Pin 2 Control */
    register8_t PIN3CTRL;  /* Pin 3 Control */
    register8_t PIN4CTRL;  /* Pin 4 Control */
    register8_t PIN5CTRL;  /* Pin 5 Control */
    register8_t PIN6CTRL;  /* Pin 6 Control */
    register8_t PIN7CTRL;  /* Pin 7 Control */
    register8_t reserved_0x18;
    register8_t reserved_0x19;
    register8_t reserved_0x1A;
    register8_t reserved_0x1B;
    register8_t reserved_0x1C;
    register8_t reserved_0x1D;
    register8_t reserved_0x1E;
    register8_t reserved_0x1F;
} PORT_t;

I do kind of wonder why it wouldn't have simply used:

PORTF.OUTTGL = (1 << 5);

 

Brian, does the drag and drop programming technique really work for the ATtiny416 Xplained Nano?
 
The ATmega4809-NANO document talks about the virtual disk, but the manual for the ATtiny416 Xplained Nano (which has a DAC which I want to use) mentions only the on-board debugger and the virtual COM port.

 

Thanks!

Just curious:

Is that file system write only, or can you also read from it?

 

With micro Python ( or circuit Python) there is often something similar, note that Python is an interpreter, not a compiler.

The workflow is to fire up your favourite editor, open the source file from your "mass storage device" and start programming.

Each time you save the file, the Python Device restarts with the new file.

 

With such an interpreter I can understand the benefit, especially if your "mass storage device" is implemented robust enough that it "always just works".

But once you have to go through the pain of compiling and linking a bunch of source files the elegance is already gone and for me, using an external programmer seems more convenient than struggling with a bootloader.

 

About that reliability issue:

DFU (Device Firmware Update) is a standarized protocol.

I got (slightly) aquainted with it with my Logic Analyser, which uses a Cypress CY7C68013A.

This chip has no FLASH, only ram. Every time it is plugged into USB it requests for firmware, and the driver on the PC is supposed to provide it via the DFU protocol.

(I think firmware can also be read from an external I2C EEPROM).

 

On my Linux Box I have vague memories that for some Atmel device (Can't remember which) a custom DFU driver was neccasarry, because Atmel thought itself smarter then the rest of the world and had to change a few bits here and there so the standard DFU did not work any more with Atmell stuff. Yuch.

Then I guess you haven't seen this in action. Say you have built three AVR programs blinky.hex, alarm.hex, adc_test.hex what simpler way could there be than drag/drop each in turn onto the "AVR drive" and it just starts running a very short while later. Digging out your programmer and then coming up with some tortuous avrdude command to achieve the same will never feel as "slick".

 

Almost as slick is an SD based bootloader I did. You just plug in the SD card with the hex you want to use. Turn on the AVR and it reads/programs/starts the new program - again no messy / convoluted avrdude commands. The only caveat here is that the name of the file on the card has to be set to a higher number than the code already loaded into the AVR.