ATMEGA4809 family chips

[cribcat]

I will re-check my code and get back to you. I took me many days to figure it out. I've made many mistakes. The code could be wrong.

if your intent is to write the to page buffer(in the code above) there is no need to use the byte address by shifting left and effectively doubling it. We are addressing this as if it were ram even though it is flash when writing a page to this "imaginary" page buffer... (but I don't know if that is what you are trying to do).

[Anobium]

Thanks.

The fuses were causing the Status error. But, still no joy.

The explicit use case is - change on byte on a valid page in Program memory. This implies caching/reading the page and changing the byte. That is the functionality needed, this can be expanded to support many other use cases.

I will post a video soon, of my lack of progress.

[cribcat]

I will attach another Flash Write program.
With my setup, it seems to work... I change the Test Byte from 0xaa to 0xbb to 0xcc and it fills the Flash Memory. Reads DATA using LPM or LD. The Timer interrupt blink works. Getting consistent flash writes.
I assume You're using the nano... is there any issues with the debugger or a bootloader? ... Shouldn't be.
Sounds like you are doing what is needed to get byte granularity... which is not easy.
The Write Flash process is tricky. As long as the BOOTEND fuse is not Zero, it should write Flash regardless of interrupt capability... I think.

Attached a reworked Flash Write with BOOTEND at 8 and APPEND at 16 .

[cribcat]

This is the same program as above . It reads the flash before Flash Write, Prints to USART, puts it in ram, modifies a byte in ram, writes to Flash, reads the modified re- written flash and sends to USART. This works on the 0X1288 BOOTEND 8 : 0X1287 APPEND 16 Fuse settings

[cribcat]

@Anobium: compiled some code fragments that You provided:

Sram variables are 1 byte in size and word(2 bytes)need to be reserved for some of these
unless the compiler is only using LOW byte IDK?? Possibly because
we are not going over 256 bytes for a page write?.

.EQU ADDRESS=10240 ; 0x2800
.EQU CCOUNT=10241 ; 0x2801
.EQU CHIPMAPPED_PROGMEM_START=10242 ; 0x2802
.EQU CHIPPROGMEM_PAGE_SIZE=10243 ; 0x2803
.EQU DDATA=10244 ; 0x2804
.EQU XMEMDATA=10245 ; 0x2805
.EQU XMEMDATA_H=10246 ; 0x2806

seems like the compiler is treating the 16bit addresses like 8 bit addresses
The 0x4000 is not added to the pointer ?
flash in Data Space starts at 0x4000 (16384 decimal)

The X register is counting up only on the low byte --- good, but the XH register is zero
Which means it isn't pointing anywhere in Sram or flash and is trying to write to CPU or something.

At minimum we need 0x4000 + address = (16384 + APPDATA(or APPCODE if using The bootloader section )

address being the section (APPCODE or APPDATA (depending)) that you want to write to.
Also depends on the fuse values.

A NOTE ON FUSES:
The BOOT SECTION is in low FLASH unlike ATMEGA328P type chips where the Bootloader is somewhere close to the end of high FLASH.

Assuming BOOTEND and APPEND are set the same:
You will have only two sections in this case.
BOOT Section and APPDATA Section

APPDATA starts at APPEND +1
( if APPEND fuse is set to 1 : 1 * 256 = 256 : 256-1 = 255 = APPEND : APPDATA starts 256)
( if APPEND fuse is set to 2 : 2 * 256 = 512 : 512-1 = 511 = APPEND : APPDATA starts 512)
( if APPEND fuse is set to 4 : 4 * 256 = 1024 : 1024-1 = 1023 = APPEND : APPDATA starts 1024)
EG.
if BOOTEND is 4 and APPEND is 4, then 0 to 1023 is BOOT section and 1024 to 49151 is APPDATA section.

to make interrupts work, you will need to move the interrupt Jump table or move the Interrupt vectors to the boot section... but don't worry about that until we get the chip Writing Flash.

Not sure I have an accurate idea of what's going on because I only have code fragments do not know if the compiler understands me? I'm not good with high level languages.
Still working on this.

[cribcat]

@Anobium: compiled some code fragments that You provided:

Sram variables are 1 byte in size and word(2 bytes)need to be reserved for some of these
unless the compiler is only using LOW byte IDK?? Possibly because
we are not going over 256 bytes for a page write?.

.EQU ADDRESS=10240 ; 0x2800
.EQU CCOUNT=10241 ; 0x2801
.EQU CHIPMAPPED_PROGMEM_START=10242 ; 0x2802
.EQU CHIPPROGMEM_PAGE_SIZE=10243 ; 0x2803
.EQU DDATA=10244 ; 0x2804
.EQU XMEMDATA=10245 ; 0x2805
.EQU XMEMDATA_H=10246 ; 0x2806

seems like the compiler is treating the 16bit addresses like 8 bit addresses
The 0x4000 is not added to the pointer ?
flash in Data Space starts at 0x4000 (16384 decimal)

The X register is counting up only on the low byte --- good, but the XH register is zero
Which means it isn't pointing anywhere in Sram or flash and is trying to write to CPU or something.

At minimum we need 0x4000 + address = (16384 + APPDATA(or APPCODE if using The bootloader section )

address being the section (APPCODE or APPDATA (depending)) that you want to write to.
Also depends on the fuse values.

A NOTE ON FUSES:
The BOOT SECTION is in low FLASH unlike ATMEGA328P type chips where the Bootloader is somewhere close to the end of high FLASH.

Assuming BOOTEND and APPEND are set the same:
You will have only two sections in this case.
BOOT Section and APPDATA Section

APPDATA starts at APPEND +1
( if APPEND fuse is set to 1 : 1 * 256 = 256 : 256-1 = 255 = APPEND : APPDATA starts 256)
( if APPEND fuse is set to 2 : 2 * 256 = 512 : 512-1 = 511 = APPEND : APPDATA starts 512)
( if APPEND fuse is set to 4 : 4 * 256 = 1024 : 1024-1 = 1023 = APPEND : APPDATA starts 1024)
EG.
if BOOTEND is 4 and APPEND is 4, then 0 to 1023 is BOOT section and 1024 to 49151 is APPDATA section.

to make interrupts work, you will need to move the interrupt Jump table or move the Interrupt vectors to the boot section... but don't worry about that until we get the chip Writing Flash.

Not sure I have an accurate idea of what's going on because I only have code fragments do not know if the compiler understands me? I'm not good with high level languages.
Still working on this.

[Anobium]

Re

.EQU CHIPMAPPED_PROGMEM_START=10242 ; 0x2802
.EQU CHIPPROGMEM_PAGE_SIZE=10243 ; 0x2803

That is an error in the compiler or my use of it. These are meant to be constants so I need to look why the compiler is not treating as a constant. The latest DAT file and compiler may be needed to support these specific constants ( they come from the DAT file).

---

I took a break from PROGRAMWRITE. I will restart today using your great insights!

[Anobium]

Resolved! I was using an incorrect Constant! Once I spotted that.. it worked!

ARGHHHHHHHHHHHHHHHHHHHHHHHH!

You code was correct!

GCBASIC syntax is PROGRAMWRITE ( address, byte ). This will cache the page and update the single byte. Sounds, so easy!

Evan

---

I will put up two videos and a new complete build tomorrow then you can have a look at progress.

[Anobium]

@cribcat I have edited your words posted. I will include in programs I am publishing.

If you have time. Please correct/edit etc.

Thanks

---

Details of writing data into program memory on AVR microcontrollers using GCBASIC.

Writing Data to Program Memory in AVR Microcontrollers

1. **Background:**
- When working with AVR microcontrollers, understanding the fuses and their impact on writing to program memory is crucial.
- The AVRDX (ATmegaDX) series differs from ATmega328P-type chips in terms of memory organization.

2. **BOOT Section and APPDATA Section:**
- The BOOT section resides in low FLASH memory locations. In contrast, ATmega328P-type chips typically place the bootloader close to the end of high FLASH memory.
- GCBASIC loads the user program into low memory starting at location 0x00.
- The top of the bootloader (or, in the case of GCBASIC, that is the top of the user program) is referred to as BOOTEND.

3. **Fuses Configuration:**
- The BOOTEND and APPEND fuses play a critical role:
    - **BOOTEND**: Determines the end address of the BOOT section.
    - **APPEND**: Sets the starting address of the APPDATA section.
- The following relationship holds: APPDATA starts at APPEND + 1.

4. **Calculating APPDATA Start Address:**
- Let's break down the calculation:
    - If the APPEND fuse is set to 1:
    - APPEND = 1 * 256 = 256
    - APPDATA starts at address 256.
    - If the APPEND fuse is set to 2:
    - APPEND = 2 * 256 = 512
    - APPDATA starts at address 512.
    - If the APPEND fuse is set to 4:
    - APPEND = 4 * 256 = 1024
    - APPDATA starts at address 1024.

5. **Example:**
- Suppose BOOTEND is set to 4, and APPEND is also set to 4.
- The memory layout:
    - 0 to 1023: BOOT section
    - 1024 to 49151: APPDATA section

Remember that the fuses must be configured appropriately to support the write operation. If the self-write capability of the AVRDX is used, it cannot write to memory locations designated as the bootloader (i.e., within the BOOT section).

Feel free to ask if you need further clarification or have additional questions via the GCBASIC Forum

[Anobium]

An example PROGRAM write/read .. writes a byte.

I have created four demos - write byte, write word, write string and write data block.

/*

    This program writes a BYTE to PROGRAM memory. 
    The source BYTE is shown below, the result is shown on a serial terminal via the USART.

    ***********************************************************************************************************************************************

    Details of writing data into program memory on AVR microcontrollers using GCBASIC.

    Writing Data to Program Memory in AVR Microcontrollers

    1. **Background:**
    - When working with AVR microcontrollers, understanding the fuses and their impact on writing to program memory is crucial.
    - The AVRDX (ATmegaDX) series differs from ATmega328P-type chips in terms of memory organization.

    2. **BOOT Section and APPDATA Section:**
    - The BOOT section resides in low FLASH memory locations. In contrast, ATmega328P-type chips typically place the bootloader close to the end of high FLASH memory.
    - GCBASIC loads the user program into low memory starting at location 0x00.
    - The top of the bootloader (or, in the case of GCBASIC, that is the top of the user program) is referred to as BOOTEND.

    3. **Fuses Configuration:**
    - The BOOTEND and APPEND fuses play a critical role:
        - **BOOTEND**: Determines the end address of the BOOT section.
        - **APPEND**: Sets the starting address of the APPDATA section.
    - The following relationship holds: APPDATA starts at APPEND + 1.

    4. **Calculating APPDATA Start Address:**
    - Let's break down the calculation:
        - If the APPEND fuse is set to 1:
        - APPEND = 1 * 256 = 256
        - APPDATA starts at address 256.
        - If the APPEND fuse is set to 2:
        - APPEND = 2 * 256 = 512
        - APPDATA starts at address 512.
        - If the APPEND fuse is set to 4:
        - APPEND = 4 * 256 = 1024
        - APPDATA starts at address 1024.

    5. **Example:**
    - Suppose BOOTEND is set to 4, and APPEND is also set to 4.
    - The memory layout:
        - 0 to 1023: BOOT section
        - 1024 to 49151: APPDATA section

    Remember that the fuses must be configured appropriately to support the write operation. If the self-write capability of the AVRDX is used, it cannot write to memory locations designated as the bootloader (i.e., within the BOOT section).

    Feel free to ask if you need further clarification or have additional questions via the GCBASIC Forum

*/
#chip mega4809            //  Declare the Target Processor and Speed
#option explicit          //  Require Explicit declaration of Variables

#DEFINE USART3_BAUD_RATE 9600
#DEFINE USART3_TX_BLOCKING
#DEFINE USART3_DELAY OFF

'*****************************************************************************************************

// Main program commences here.. everything before this is setup for the board.
// Now assumes Serial Terminal is operational

HserPrintCRLF 1
HSerPrintStringCRLF "Change/set a byte in PROGRAM memory", 1

// Variables
Dim index, Value, DataOffset, Address as Word 
Dim newValue as Word


    // This is the address in PROGRAM memory.
    // Can be any valid PROGRAM memory as determined by the FUSES.
    Address = 0xB000
    Value = 0x55

    // Write the byte
    ProgramWrite( Address , value )

    // Show results by reading the PROGRAM memory and send to a terminal via the USART
    HserPrintCRLF
    HserPrint "Byte value written to PROGRAM memory = 0x"
    // Get the value of the byte written, set newvalue to 0 and use a new variable to prove this is a valid result
    newvalue = 0
    ProgramRead ( Address  , newvalue )          
    HserPrint Hex(newvalue)
    HserPrintCRLF

    // Show any error - a non zero value for NVMCTRLStatusCounter will be an error. 
    If NVMCTRLStatusCounter <> 0 Then

        // Bit 2 – WRERROR Write Error
        // This bit will read '1' when a write error has happened. A write error could be writing to different sections before doing
        // a page write or writing to a protected area. This bit is valid for the last operation.
        // Bit 1 – EEBUSY EEPROM Busy
        // This bit will read '1' when the EEPROM is busy with a command.
        // Bit 0 – FBUSY Flash Busy
        // This bit will read '1' when the Flash is busy with a command.

        HserPrint "NVMCTRL Error Status = " 
        HserPrintStringCRLF ByteToBin( NVMCTRLStatusCounter )  //~ Just shows the bits 2+1+0 of the status register
    End If

    Do

    Loop

End

[Anobium]

Video for users for PROGRAMWRITE() and PROGRAMREAD()

Enjoy

[Anobium]

@cribcat et al.

Latest patch build is here: https://1drv.ms/u/s!Ase-PX_n_4cvhYNY1VP0Ztcl4FYRAg?e=z5TEd8

Download and test.

Evan

---

I am next going to sort the Interrupt Vectors in the DAT file. I will use the information you provided and I will validate.

Evan

[Anobium]

I have made changes to the software that Gens the DAT file. It now is adding the interrupt vectors to the DAT.

If you get some time. Can you review the ASM attached? Why is the interrupt not firing? I must have missed BIT somewhere. Your eyes may save me days!

Thank you for being here.

[cribcat]

The cause of the interrupts not firing is likely because of changing the fuse settings. It is unavoidable with these chips. You have to move the Interrupt JUMP table OR change the IVSEL to the BOOT Section. I will send two examples of how to fix.

As far as my understanding of fuses, I have many days/weeks tied up in trying to understand them. I think I have a handle on it but...Who Knows?

As far as the .DAT file: This is what prompted me to ask how far are we taking the functionality. We have the TCA timer That also has a split mode. It supports two PWM channels with interrupts(If I Recall Correctly). I have a program that runs TCA split mode with 6 PWM outputs as well.
We also have CCL which has the capability of adding gates to the input/ output circuitry. We have an event system which does something? There is AC/ADC Vref Select code that should be addressed, PORTMUX ...etc. These are all icing on the cake and you may want to wait to get them implemented... but many of them have (multiple) interrupt(s). I didn't know how to handle in the .DAT file.
I use the bit Mask( _bm) VS. the bit Position(_bp) usually. The .DAT file seems to use only bit Position(_bp)... is this correct? Are there other factors? I'm sure you'll keep me posted.

Currently working on trying to get a READ on an I2C 24LC64/24LC256 EEPROM for the past 2 weeks.
I will check the demos /explanations you wrote.
G

[Anobium]

I use the bit Mask( _bm) VS. the bit Position(_bp) usually. The .DAT file seems to use only bit Position(_bp)... is this correct? Are there other factors? I'm sure you'll keep me posted.

Should have been resolved in build 1427. If these are not available please let me know.

[Anobium]

@cribcat - You genius! I wasted many hours on this. I must learn to ask you first!

I changed the Fuses and it worked immediately!

#Chip mega4809
#option Explicit

/*
This demo sets the LED on and off when the interrupt happens.

------------PORTA---------------
    Bit#:  -7---6---5---4---3---2---1---0---
    IO:    ---------------------------------
    IO:    ---------------------------------

        ------------PortF----------------
    Bit#:  -7---6---5---4---3---2---1---0---
    IO:    -----SW-LED----------------------
*/

#DEFINE SW PINF.6
DIR SW In
    // set the PULLUP for this specific port.pin
    PortF_PIN6CTRL.3 = 1

#DEFINE LED PORTF.5
DIR LED Out
LED = 1

On Interrupt PortFChange call ISR
    PORTF_PIN6CTRL = 0x03;

Do
Loop

Sub ISR
    LED = !LED
    wait 10 ms
End Sub

This should help explain the GCBASIC ( therefore my approach to the generic interrupts ).

Handling generic interrupts. A generic interrupt is where the interrupts listed in the Help are supported. Like PORTFCHANGE -this means the any interrupt on the port will the specified interrupt handler.

Handling non-generic or all interrupts. Let me caled them non-specific. A usermust write a interrupt handler called INTERRUPT. GCBASIC will handle the caching of the context but this means ANY interrupt of any source can be handled.

#Chip mega4809
#option Explicit

/*
This demo sets the LED on and off when the interrupt happens.

        ------------PortF----------------
    Bit#:  -7---6---5---4---3---2---1---0---
    IO:    -----SW-LED----------------------

*/

#DEFINE SW PINF.6
DIR SW In
    // set the PULLUP for this specific port.pin
    PortF_PIN6CTRL.3 = 1

#DEFINE LED PORTF.5
DIR LED Out
LED = 1

// Set the pullup
PORTF_PIN6CTRL = 0x03;

Do
Loop

Sub INTERRUPT
    If PORTF_INTFLAGS.6 = 1 Then
        // handle a specific interrupt
        LED = !LED
        wait 10 ms
        PORTF_INTFLAGS.6 = 1
    End If
End Sub

This gens this ASM, these are segments.

All vectors are to the user defined Interrupt()

;Vectors
;Interrupt vectors
    .ORG    0
    rjmp    BASPROGRAMSTART ;Reset
    .ORG    2
    rjmp    INTERRUPT ;CRCSCAN_NMI
    .ORG    4
    rjmp    INTERRUPT ;BOD_VLM
    .ORG    6
    rjmp    INTERRUPT ;RTC_CNT
    .ORG    8
    rjmp    INTERRUPT ;RTC_PIT
    .ORG    10

the actual Interrupt() is topped and tailed by GCBASIC with the context save and restore. The context handler is smart and saves what is needed to be saved/restored..

;Source: 171_MEGA4809_NonSpecific_Interrupt_operations.gcb (41)
INTERRUPT:
    rcall   SysIntContextSave
;If PORTF_INTFLAGS.6 = 1 Then
    lds SysBitTest,PORTF_INTFLAGS
    sbrs    SysBitTest,6
    rjmp    ENDIF1
;handle a specific interrupt
;LED = !LED
    clr SysTemp1
    lds SysBitTest,PORTF_OUT
    sbrc    SysBitTest,5
    inc SysTemp1
    com SysTemp1
    lds SysValueCopy,PORTF_OUT
    cbr SysValueCopy,1<<5
    sbrc    SYSTEMP1,0
    sbr SysValueCopy,1<<5
    sts PORTF_OUT,SysValueCopy
;wait 10 ms
    ldi SysWaitTempMS,10
    ldi SysWaitTempMS_H,0
    rcall   Delay_MS
;PORTF_INTFLAGS.6 = 1
    lds SysValueCopy,PORTF_INTFLAGS
    sbr SysValueCopy,1<<6
    sts PORTF_INTFLAGS,SysValueCopy
;End If
ENDIF1:
INTERRUPTDONE:
    rjmp    SysIntContextRestore

This will handle all cases.

[Anobium]

@cribcat - two things. ISRs and Buld 1428 ( this has interrupt in DAT files and a tweek to the compiler).

Regarding ISR Vectors and FUSES.

I will, somehow, resolve automatically. The fuses can be read by a program therefore the program knows the fusese are non zero values. Then, as you have provided, change the vectoring.

Seems to me that ATMEL designed a chip for bootloaders as the key focus and they just confused the standard use case.

---

Build 1428 - https://1drv.ms/u/s!Ase-PX_n_4cvhYRZX6QjCzv3CKdcYw?e=f1KfXP

This has all the new DAT file and the latest compiler. This does not have FUSES related ISR vectoring - I need to think on this! A lot.

---

High level state of play. Not much more to complete!!!

[cribcat]

In the "C" language (AVR-GCC) they put a structure that sets the fuses and lets the compiler know where everything is. AVR-GCC also goes by a linker file and has a little more flexibility as well as Complexity. E.G.

#include <avr/io.h>

FUSES = {
    .WDTCFG = 0x00, // WDTCFG {PERIOD=OFF, WINDOW=OFF}
    .BODCFG = 0x00, // BODCFG {SLEEP=DIS, ACTIVE=DIS, SAMPFREQ=1KHZ, LVL=BODLEVEL0}
    .OSCCFG = 0x02, // OSCCFG {FREQSEL=20MHZ, OSCLOCK=CLEAR}
    .TCD0CFG = 0x00, // TCD0CFG {CMPA=CLEAR, CMPB=CLEAR, CMPC=CLEAR, CMPD=CLEAR, CMPAEN=CLEAR, CMPBEN=CLEAR, CMPCEN=CLEAR, CMPDEN=CLEAR}
    .SYSCFG0 = 0xF6, // SYSCFG0 {EESAVE=CLEAR, RSTPINCFG=UPDI, CRCSRC=NOCRC}
    .SYSCFG1 = 0xFF, // SYSCFG1 {SUT=64MS}
    .APPEND = 0x7c, // APPEND
    .BOOTEND = 0x7c, // BOOTEND
};

AVR-ASM doesn't have a linker , but would a user statement of the Fuses (BOOTEND, APPEND) do the trick? ... I know we're trying to avoid complexity for the user though, Just a thought.

[cribcat]

A little extra information I found...
This is from CURTVM on the AVRFREAKS forum and deals with writing flash:
https://www.avrfreaks.net/s/topic/a5C3l0000003jtrEAA/t390218

"The datasheet is confusing for BOOTEDN/APPEND, but if you read one of their app notes- When BOOTEND is zero, the entire Flash is considered to be boot section, the value in APPEND is ignored, and it is not possible to write to Flash.

When BOOTEND is non-zero, the default location of the interrupt vector table pointer will be written to the start of the application code section by default. If no bootloader is used and the interrupt vector is not moved, it is possible to overwrite this by changing the IVSEL bit in the CPUINT_CTRLA register. If the IVSEL bit is changed, the interrupt vector will be pointed to the start of the bootloader section

Which seems to match what I see in a tiny3217- if BOOTEND is 0, it does not matter what APPEND is as the whole flash is a boot section so no writing. When you want APP DATA only, setting BOOTEND and APPEND to the same value (0x7C) gets you a BOOT section of 0x7C*256, an APP CODE section of 0 length, and an APP DATA section length of 0x400. Although there is no APP CODE section, the interrupt vectors are still placed according to the APPEND fuse value so unless IVSEL is set the hardware will route vectors to the APP DATA section. "

this explains a lot for me.

[Anobium]

Good analysis.

GCBASIC already supports this! Amazingly, when I tested just now. The following happens.

Chip has fuses of BOOTEND = 0. In GCBASIC not change required.
Chip has fuse of BOOTEND = n. In GCBASIC requires #OPTION BOOTLOADER n*256/2,

If BOOTEND is 0x02 add #OPTION BOOTLOADER 0x100.

#chip mega3217
#option Explicit
#option Bootloader 0x0100

ASM where

;Vectors
;Interrupt vectors
    .ORG    256
    rjmp    BASPROGRAMSTART ;Reset
    .ORG    258
    reti    ;CRCSCAN_NMI
    .ORG    260
    reti    ;BOD_VLM
    .ORG    262
    reti    ;RTC_CNT
    .ORG    264

If only I remembered all this the other day!

So, I we have a solution within GCBASIC. If a user changes the Fuses then then need to use #OPTION BOOTLOADER n*256/2.

Makes sense? and, will this work?
I just tested the theory - it works!! I have attached a working demo.

[Anobium]

I am considering adding this to the Help. Have a hack/edit this.

Evan

---

AVRDX microcontrollers, the BOOTEND and APPEND fuses, and their impact on interrupt vectors.

AVRDX Microcontrollers:

The AVRDX microcontrollers represent the latest and highest-spec 8-bit AVRs available.

Interrupt Vectors Overview:

Interrupt vectors are predefined memory locations that point to interrupt service routines (ISRs) for various events.

By default, the lowest addresses in the program memory space are reserved for the Reset Vector and the Interrupt Vectors.

The complete list of vectors includes RESET (highest priority), followed by INT0 (External Interrupt Request 0), and others. See the datasheet.

BOOTEND and APPEND Fuses:

These fuses are specific to the AVRDX microcontrollers and impact memory layout, program memory write operations and interrupt handling.

BOOTEND Fuse:

The BOOTEND fuse determines whether the Reset Vector and the Interrupt Vectors are located at the start of the Boot Flash section or not.

APPEND Fuse:

The APPEND fuse controls whether the interrupt vectors are appended to the end of the application section in flash memory.

This can be useful for certain bootloader scenarios.

GCBASIC and Bootloader support:

In GCBASIC, if the BOOTEND fuse is non-zero, the GCBASIC compiler will relocate the vectors using the #option bootloader nn directive.

Here, nn represents the BOOTEND value multiplied by 256 and divided by 2.

This ensures that the vectors align correctly with the bootloader behavior.

Safe Fuses and Interrupt Vectors:

When setting fuses, consider safety and usability:
Safe fuses to set include CODESIZE/BOOTSIZE or APPEND/BOOTEND fuses. These prevent unexpected behavior when uploading to a board that previously had a different bootloader (e.g., Optiboot).

Remember, understanding these fuses and their impact on interrupt vectors is crucial when designing firmware for AVRDX microcontrollers.

[Anobium]

I have tested and validated Software TWI/I2C. This just uses the existing I2C library. All the TWI/I2C is done in software with hardware dependency - therefore it always slower.

I have posted two SWTWI demos. One a discovery program - this shows the I2C device(s) on the I2C bus, and the other is a demon of test, graphics etc.

Result - it works. So, another thing ticked off the list.

Just need the same for hardware TWI/I2C.

:-)

[cribcat]

Looks Good, Excellent work !... That's Good News.

I am not overly familiar with I2C Hardware . What does that entail? I've written a BIT BANG I2C for M328P chips but neve have done hardware. Don't have a good idea of what that looks like.

I wrote an INTERRUPT ONLY driven twi driver last January and it's the only thing I can get to work with my 24LC64 eeprom device. It will write 32 bytes and then read them back .

I can't seem to get hardware going with user software polling interaction. Must be something I don't understand. I do think I'm close though.

Now that I have the interrupt only code working (I think) Should be able to " reverse engineer " to get working code. Hopefully it will translate into viable master and slave code for two MCUs.
G

[Anobium]

I am finalising the ADC routines. The approach is a merge of GCBASIC and ASM but the user just calls ReadADC( AINn ). Should be completed in next few days. It will keep me busy.

[Anobium]

@cribcat

The. I2C library's are included in the installation. They support a large set of I2C hardware and they support software and hardware I2C/TWI.

The architecture is three layers. User API, hardware specific library and then the communication layers. This means the comms layers is chip specific and as long as the basics work the solutions can be built upon that layer.

This is not my architecture design but Hugh's.