ATMEGA4809 family chips

[GCBASIC]

Anyone interested in helping to get the ATMEGA4809 family of AVR supported?

Let me know.

---

The megaAVR-0 chip family offers lots of features and peripherals. The ATmega4809 can be found in products like the Arduino Uno WiFi Rev2 and the Arduino Nano Every. Key features include multiple serial ports, SPI and i2c interfaces, built-in programmable logic, up to 16 analog input pins, and an analog comparator with a built-in programmable voltage reference and hysteresis and much more!

The work will address the ATmega4809, ATmega4808, ATmega3209, ATmega3208, ATmega1609, ATmega1608, ATmega809 and ATmega808.

Compared to older AVR families they also have more advanced and accurate internal oscillators which can provide base frequencies of 16 and 20 MHz. These can then be divided down internally to reduce the processor speed and power consumption. This means in most applications an external clock is not needed.

---

Actually, posted by Anobium/Evan using the generic SF account

[Anobium]

AVRDx library develoment status @01/10/2024 - Completed

The compiler changes are now complete. Adding the AVRDx to the libraries is now needed. The following table shows the status.

Functionality	Status	Comments
OSC	Completed	Demo published, see GitHub
PIN Operations	Completed	Demo published, see GitHub
Serial/USART	Completed	Completed library completed demos. Interrupt driven Serial Buffer Ring works.
Interrupts	Completed	Serial, PIN, Timerverified. PWM and ADC WIP - demos published.
RTC	Completed	Demo published. Shows setup and interrupt handler.
Timers	Completed	Demos published
millis()	Completed	The AVRDX implementation of mills() is much improved for the AVRDX. The range of frequencies is from 24mHz to 1mHz
TWI/I2C	Completed	Implemented and demos published.
Memory DATA	Completed	This is ability to add DATA blocks and read them with ProgramRead(). Demo written.
Memory PROGMEM	Completed	This self write capability/methods to write/read to PROGMEM using PROGRAMWRITE(). Demo written.
Memory EEPROM	Completed	This self write capability/methods to write/read to EEPROM; Demo published.
Tables	Completed	No changes required.
Tables Stored in EEPROM	Completed	Demo written.
PWM	Completed	Demos published
Sleep	Completed	Demos published

For published demos - see https://github.com/GreatCowBASIC/Demonstration_Sources/tree/main/TestSolutions/AVRDX_implementation/mega4809

NotS - Not Started
ASM - ASM provided
ERVBack - In Evan's Backlog
WIP - Work In Progress
DONE - Done!
Cribcat - Item assigned to Greg

[Christos]

cant help a lot (out of testing) however if work for a new family is decided AVR DB (or DA etc) should make more sense

[stan cartwright]

Sounds nice device. If gcb could use a rpi's gpio pins then gcb would be used by more people.
Christos has a point as https://sourceforge.net/p/gcbasic/discussion/chipfileforum/thread/9d814a60a7/
Evan's lgt328 stuff is brill. I sent him a 32 bit arduino board but no reply.
GCB on rpi would take rpi users by storm. We don't just learn python or C.
There's freebasic but what a complicated basic with the wiring pi to use rpi gpio.

[Christos]

32 bit arduino's are not 8bit netierh avr nor pic, they are arm mcu's
so rewriting compiler is a huge job
moving to same cpu with some changes is easier

[Chris Roper]

I had that problem with one of my contracts.
Half way through the design process they decided to switch from PIC16 to PIC32.
They then got upset that I couldn't just recompile to the faster Device.
I finally got them to accept that the PIC32 was a MIPS core and it was effectively a new contract if they wanted me and my team to start over on a new architecture.
In the end we did port the code from MASM to C++ with a bit of custom ASM work but we went way out of pocket have never accepted another contract from them.

[stan cartwright]

Oh dear. I use a rpi to use 8bit retro games so thought gcb could make rpi a fake pic.
Evan did a good job supporting the lgt328. It seems faster than even the new pics supported.
You may like one, the 32 clock makes it twice as fast as mega328 and it shows when using glcd on a spi display.
Your millis works on lgt328.
I'm going to check logic green tech to see what's new, like if there's a lgt mega2560. That would be so cool.

[Domenic Cirone]

I have ordered some samples, I should be able to help.

[Anobium]

See New parts supported - ATMega80n, ATMega160n, ATMega320n and ATMega480n

https://sourceforge.net/p/gcbasic/discussion/579125/thread/2f8291ab02/?limit=250#d207

[Angel Mier]

Available on DEV 1.01.143 and scheduled for mainstream on 08/17/2024

[cribcat]

Glad to see support for the newer AVR chips, I would like to help out if possible. I program mainly in ASM so i am familiar with the new avr-0 and avr-1 asm syntax, BUT: I keep getting an Error: No chip data file found for MEGA4809. Do the xxxxxxxx.DAT files need to be created or do you have a separate download? Version 1.76.2 Release 23074

[Angel Mier]

Hi, you need to change the update channel to Developers Preview, a few simple steeps:

Go to settings panel by pressing the wrench icon.

Select "dev preview" on Update Channel

Restart GC Studio, you will get an update with the supported chips, enjoy.

Angel

[Anobium]

@Cribcat / @PerPlexd ( you are the same person ? :-) )

Do as Angel shows. Load the DEV channel - this will test and prove that the new build with all the components for AVRDX are complete. They, hopefully, you can compile.

---

As you are an ASM person this is very good. Just what is needed!

GCBASIC and ASM: GCBASIC is like the digital embodiment of ASM knowledge, wrapped up in libraries. It’s a powerful way to express low-level operations without having to deal with all the intricacies of raw assembly for the average user. The compiler obediently follows your instructions—no more, no less.

I will share and document for you.

Secret Development Tricks

o Custom Libraries: You can load your own library files, replacing standard ones during development. This way, you tailor the libraries to your development needs.
o Silence the DAT File: Silence those verbose messages during development. Sometimes, the compiler can be chatty!.
o Debugging Levels: Adjust the debug verbosity. Sometimes you want a whisper; other times, you need a lot of information.. the compiler can be very chatty!.
o ASM Verification: Generate GCBASIC ASM and assemble it using AVRASM2. Cross-checking the ASM is a great way to validate progress.
o Redirect Calls: Make implementing new AVRDX methods easy by redirecting calls

Library Functions: Priorities

o Serial/USART: Critical for communication. Start with USART1; the others can follow suit.
o ADC Operations: Reading analog values—essential for sensors and inputs.
o Interrupts: Framework exists, but we need those interrupt bits per interrupt. The handler can do all the heavy work.
o Timers and millis():Implement timers and get that millis() working.
o I2C: Inter-chip communication.
o Memory (EEPROM and PROGMEM): Read, write operations.
o PWM: Pulse-width modulation.

ATXMega

I recommend we leave these on the back burner for now. First, let’s conquer AVRDX. ATXMega can wait patiently in the wings.

This journey is like assembling a complex circuit: one connection at a time. If you have any specific questions or need further guidance, just holler—I’m here to assist!

[cribcat]

Hello Angel, Hello Anobium,
"@Cribcat / @PerPlexd ( you are the same person ? :-) )"
indeed, I am the same person may change that back to avoid confusion.
Updated and configured compiler after I watched Angel's YouTube vids. Was viewing the gc.bas code earlier. Very interesting. I must say, the development environment is impressive... Your team has done a great job since I last looked at GCBasic!

I am familiar with Atmel Studio 4.19 and the newer Atmel Studio/Microchip Studio 7 and a tiny bit with the MPLAB X IDE.
I mainly worked with the mega328P but also use tiny2313A, tiny84A, tiny85 and now tiny1616 mega4809. I do have a couple AVR128DA48 and AVR128DB48 (some not on breakout boards yet). I do also have some of the simpler Pic like 12F683, 16f628A which were my entry into "embeded" ASM.
Thank You both for the information! I need to get my bearings now...lol.

[Anobium]

Thanks - the IDE is very smart.

With your help, every line of code you write shapes GCBASIC. And when you encounter a tricky problem, just call out. It is like summoning ancient spirits, but grumpier, with better answers. 😄

The USART is a good place to start with that 4809 you have.

So, @Cribcat, will you join our fellowship? Together, we’ll build solutions that work across all high-five across continents.

[cribcat]

The project is huge! I need to learn how to crawl before walking in this environment. Where is the broom?... I can probably "sweep the floors and empty the trash". Where do I start?

I read something about scripts in GCBASIC Maintenance and Development in the GCBASIC documentation. I am also reading various posts in the forum area and familiarizing myself with GCBASIC commands/syntax.

As far as USART(rs232) for the 4809, I have working code in assembler to reference. From what you said, USART1 is the preferred com device, correct ? Not USART0 ? Switching them is easy enough.

You must be busy... Thanks for your time!

[Anobium]

The project seems a lot of work but small steps gets the job done.

‐--------

If you have working usart code that send one byte of data, and, you have the setup of the registers then create a small program to show this. The program send a character every 25 ms.

I can then explain how this can be moved into a set of subs and functions that integrate with the existing library.

Essentially, send a byte via serial is the basis of all serial operations. It is called HSerSend().

You can use any sub naming you like as I will explain the integration.

:-)

[cribcat]

Perfect,
I have attached the asm code for the routine outlined above. It works on Realterm and Putty over a USB serial device (CP2104 ). I have taken out the byte retrieval receive portion. Baud rate is set for 9600 ...easily changed. Hope it's adequate.

[Anobium]

Thank you.

I now create a GBASIC program of the your code.

It will there for support all the GCBASIC capabilities: BPS at any frequency, any delay etc.
I will also document how you can hack away in the GCBASIC libraries but no break things: Makes making changes a lot easier.

Whilst I do this. Do you have asm for receive byte? To receive and send a byte.

---

Updates

8/17: 08:00 Well... it seems that I have missed all the _gc bits/masks from the DAT file. So, I will add them to the converter. Then, we can address those bits directly from GCBASIC.
Your ASM has saved me days of work. I mean days. I would have to learn all these registers etc. Most grateful here.

I will post a new DAT file and sample GCBASIC program by Sunday AM, London time.

[cribcat]

I should have left the receive stuff in. It is best used with a buffer(IMO) but I do not have working code for a buffer in this example yet. I think GCBasic has working buffers. I am very pleased this could be of some use to someone in .ASM form. There is a ton of code in C but not nearly as much in assembler.

[Anobium]

Thanks again.
Can we get on a call? I need advice on the way forward. So, many questions and I hope you can clarify. Zoom, whatsapp, or a other method - any time. Let me know.

[Anobium]

The challenge.

I want to ensure the AVRDx chips can compile using GCASM and AVRASM2. That is the similar challenge to PIC using GCASM and PIC-AS.

For PIC-AS I wrote a huge routine in the compiler to complete a reverse lookup for every register and register.bit in the MPLAB-IDE chip specific XML. This resolved any naming change between MPASM and PIC-AS. That works well.

For AVRDx. A new challenge creating ASM that works for GCASM and AVRASM2.

• the DAT file in GCBASIC has historically ( before today ) has the register and register bits defined .... not register bit masks
• GCBASIC has historically used register.bit aliases ( like TXEN, that then would map to USART1_CTRLB.TXEN

So, if I created a DAT file with register.bit aliases ( like USART1_CTRLB.TXEN ) then this would compile in GCASM but not compile in AVRASM2.

So, if I created a DAT file with only the bit mask .bit ( like USART_TXEN_bm ) then this would NOT compile in GCASM but would compile in AVRASM2. Unless I made huge changes to the GCASM which is NOT going to happen as this is way to risky.

The way forward

I have manually adapted the DAT file to have a new section. This new section can be sourced from the chip specific MPLAB INC file. The new section would have all the bit masks.

Here is a the DAT file ( partial ). This is lifted directly from the INC file, so, very simple and reliable to source the data.

[AVRMasks]
USART_NORMAL_PMODE_DISABLED_gc = (0x00<<4) ; No Parity
USART_NORMAL_PMODE_EVEN_gc =(0x02<<4) ; Even Parity
USART_NORMAL_PMODE_ODD_gc= (0x03<<4) ; Odd Parity
USART_NORMAL_SBMODE_1BIT_gc= (0x00<<3) ; 1 stop bit
USART_NORMAL_CHSIZE_8BIT_gc= (0x03<<0) ; Character size: 8 bit

This is new section of the DAT is processed by the compiler and these masks are then available in GCBASIC. An example:

GCBASIC source

//~ Set some bits
USART1_CTRLC = USART_NORMAL_PMODE_DISABLED_gc | USART_NORMAL_SBMODE_1BIT_gc | USART_NORMAL_CHSIZE_8BIT_gc  ; async 8bit no parity with one stop bit 

GCBASIC then generates valid ASM where GCASM and AVRASM2 works.

ASM generated is:

;USART1_CTRLC = USART_NORMAL_PMODE_DISABLED_gc | USART_NORMAL_SBMODE_1BIT_gc | USART_NORMAL_CHSIZE_8BIT_gc  ; async 8bit no parity with one stop bit
    ldi SysValueCopy,3
    sts USART1_CTRLC,SysValueCopy

This clearly is good approach. And, is mandated.

---

This leaves the dilemma of register.bit.

Hisorically, users have been able to use USART1_CTRLB.TXEN = 0|1. As this is the actual register.bit name as shown in page 301 of the datasheet.

Example GCBASIC

USART1_CTRLB.TXEN = 1

ASM generated... compile using GCASM but fails in AVRASM2

;USART1_CTRLB.USART_TXEN = 1
    lds SysValueCopy,USART1_CTRLB
    sbr SysValueCopy,1<<USART_TXEN
    sts USART1_CTRLB,SysValueCopy

I think ( please verify ) that we have to ignore the datasheet. As there is NO method to make AVRASM2 compile.

Therefore, as GCBASIC has a design principle of being able to access raw asm for the target microchip controller and that principle means that using the naming conventions in target assembler.

For AVRDx then the _bp needs to be supported.

Example GCBASIC

USART1_CTRLB.TXEN_bp = 1

ASM generated... compiles using GCASM ( assume the DAT file has the correct entry ) and in AVRASM2.

;USART1_CTRLB.USART_TXEN_bp = 1
    lds SysValueCopy,USART1_CTRLB
    sbr SysValueCopy,1<<USART_TXEN_BP
    sts USART1_CTRLB,SysValueCopy

---

Summary

My thoughts.

1. Adapt the DAT generator to have new [AVRMasks] section and to add all the register.bits with _bp and _bm
2. Change the compiler to read the new section of the DAT file ( already done as I need to prove my thinking). ( All this does is expose the AVRDx masks to GCBASIC).
3. The compiler needs to support AVRDx bit masks ( as sourced from the INC file ).
4. The compiler needs to handle register.bit with _bp and _bm

---

I knew this would not be easy!

Your thoughts? Is this a good way forward?

Evan

---

Example GCBASIC program will look like this....#

Sub INITUSART_AVRDx

    // Set the default value for USART handler - required when more than one USART
    Dim comport as Byte
    comport = 1

    // Set baud rate
    USART1_BAUDL = UBRRL_TEMP       //~ store low fBAUD in BAUD register
    USART1_BAUDH = UBRRH_TEMP     //~ store high fBAUD in BAUD register

    // Set some bits
    USART1_CTRLC = USART_NORMAL_PMODE_DISABLED_gc | USART_NORMAL_SBMODE_1BIT_gc | USART_NORMAL_CHSIZE_8BIT_gc  ; async 8bit no parity with one stop bit 

    // Enable TX and RX
    USART1_CTRLB = USART_RXEN_bm | USART_TXEN_bm      

End Sub

ASM

;Source: MEGA4809_USART_TX .gcb (26)
INITUSART_AVRDX:
;Set the default value for USART handler - required when more than one USART
;Dim comport as Byte
;comport = 1
    ldi SysValueCopy,1
    sts COMPORT,SysValueCopy
;Set baud rate
;USART1_BAUDL = UBRRL_TEMP      //~ store low fBAUD in BAUD register
    ldi SysValueCopy,3
    sts USART1_BAUDL,SysValueCopy
;USART1_BAUDH = UBRRH_TEMP     //~ store high fBAUD in BAUD register
    ldi SysValueCopy,1
    sts USART1_BAUDH,SysValueCopy
;Set some bits
;USART1_CTRLC = USART_NORMAL_PMODE_DISABLED_gc | USART_NORMAL_SBMODE_1BIT_gc | USART_NORMAL_CHSIZE_8BIT_gc  ; async 8bit no parity with one stop bit
    ldi SysValueCopy,3
    sts USART1_CTRLC,SysValueCopy
;Enable TX and RX
;USART1_CTRLB = USART_RXEN_bm | USART_TXEN_bm
    ldi SysValueCopy,192
    sts USART1_CTRLB,SysValueCopy
    ret

[Anobium]

Some files. You can try to compile the ASM in AVRASM2. As you do not have the compiler, yet.

I am not 100% on the BPS yet. But, a code review would be great.

:-)

[Anobium]

Here is a more advanced program. Supports up to 5 USARTs ( this does assume that all USARTs have similar naming but this is easily fixed even if they are different ).

This is a whole lot more error handling, scripts etc.

But!! this works on the 4809 here on USART1 and USART3!

[Anobium]

I am done for today.

Thiss final version works across 5 USARTs, optimising the code if one one USART is used, suppprts 1.25mHz to 20 mhz ( tested ) at 9600bps.

Seems to work great. Tomorrow, I will add the send routine you posted and I will post for you the new compiler and DAT file.

I have reposted. This is the correct file.

This supports USART0 to USART4 which is the 5 USARTs. The addressing is sorted. So, HserPrintStringCRLF "Some string", 1 will send to USART1 which sort of makes sense!