The development is underway to change the compiler to support the Series and DX chips.
Compiler Development: Work is in progress to update the compiler for supporting Series and DX microcontrollers, which require Direct Pin Configuration.
Migration Resource: A migration document from Microchip is being used as a guide.
Simplification Challenge: The goal is to simplify the complex process of setting ports on the new chips compared to the legacy ones.
Progress Update: See the video below to demonstrate the current progress, and further explanation on the architecture will be provided in an upcoming video.
These chips are different they use very different methods to set ports. Port setting required Direct Pin Configuration and the compiler needs a large update to support these chips.
Title: Exciting Progress on the ADVRX Project with ATTINY3217 and New AVRDX Chips
Hello fellow developers,
I'm excited to share with you some significant progress I've made on the ADVRX project. I've managed to adapt the GCBASIC instruction set to work with the ATTINY3217 and the new AVRDX chips.
The compiler now sets the internal frequency correctly, handles conventional instructions like DIR port IN|OUT, and set PORT values to use the new AVRDX instructions/registers. This is after three iterations of rewriting the compiler solution, I've found an approach that handles most cases effectively.
The demo code, shown below, showcases basic operations, but also includes the sequence to set the frequency and control the protected registers. My goal is to maintain a compatible GCBASIC instruction set while supporting the ASM of the new DX chips.
A key part of this work is the new ALIAS section in the chip DAT file. This section maps the GCBASIC AVR ports to the new AVRDX chips, providing a flexible configuration that isn't hard-coded and can be adapted across the range of new AVR chips.
This is still early code and there's a lot more work to be done beyond the compiler, such as the libraries. But I'm committed to completing the compiler changes to support these AVRDX chips.
For those who want to use the compiler, please note that you will need build 1396 or greater.
Resources:
- Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdf
- Migration from the megaAVR® to AVR® Dx Microcontroller Families.pdf
- ATtiny3216-17-DataSheet-DS40002205A.pdf
I guess I should add.... the demo code above flashes the LED 5 times then every 1 sec, forever.
This means.
1. The chip dat file is recognised and is being loaded
2. The initialisation of the frequency, as specified, is being handled appropriately, with the correct operation of the protected registers.
3.The ports are being initialisation to match GCBASIC operations
4. I will add a clear down of the RAM to 0 value ( same as the LGT chipset)
5. Then, the program set directions and handles basic port IO in the user program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now working as expected. There will be two DAT files one for each baseline frequency that can be selected in the Fuses. The two options are 20mHz and 16mHz baseline frequency. The two DAT file will be identical apart from the internal frequencies that can be selected.
**RAM Memory Initialisation to 0x00
This operates as expected. This required a new stack initialisation routine. But, what took hours to resolve was the ASM was working when using MPLAB Studio ( ASM generated by GCBASIC) was working in real silicon but a hex generated by GCASM was failing.
The root causes was
1) The DAT file RAM memory definition is one byte larger than the same PIC entry. So, a range of 0x3800 to 0x3FFF is incorrect. The correct specification for AVR is 0x3800 to 0x4000. Very annoying. I will document the DAT file as I progress.
This memory is caused the low(RAMEND) to return 0xFE ( should be 0xFF) and it was only by inspection of the MPLAB and GBASM disassembly was I able to figure out why the stack was falling over.
2) The clock frequency was working correctly when programmer from MPLAB but not GCASM. This was caused by the GCASM adding 32 to the target register address. In this specific case the clock frequency setting register is protected and adding 32 to the unlock register meant the new clock frequency was being ignored. A simple ifAVRDX() resolved this issue.
So, not much progrest but the Nano board has a flashing LED and you can program direct from GCSTUDIO.
The hex files generated by MPLAB and GCBASIC/GCASM are identical. This is a great verification that things are working correctly. A reminder: You can write a GBASIC program, use the ASM file within an AVR MPLAB project to walk the code in the MPLAB simulator, debug on real silicon using the MPLAB Debugger. You can program using GCSTUDIO, drag and drop the HEX on the CDC Nano board or program via UPDI from within the MPLAB project.
--‐-----
Now the basics work. I will expand these basic output focused IO tests to direct port setting and logical port setting. Then, I will move onto IO input testing.
Enjoy this report on progress.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new AVRDX have a wide range of internal frequencies. These are based on 20mHz or 16mHz divided by various scalers ( numeric values ).
As example is 20mHz / 48 = a number that is small and with a number of decimal places.
The issue using these frequencies is that users have to get the decimal value precisely correct to 7 decimal places. Not something that is realistic. The user frequency specified value has to precisely match the value in the DAT file.
**Solution
The compiler now supports division when specifying the frequency.
So, the following are now valid.
#chip Tiny3217, 20 / 48
#chip Tiny3217, 16 / 32
The compiler will show a calculation has been used for the frequency and if the frequency matches a valid frequency in the DAT file then the compiler will display 'Internal Oscillator'.
This new capability will work across all chips but very few have the 7 decimal frequency specification like the AVRDX chips.
Enjoy this update.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The megaAVR and AVR Dx families are not pin-to-pin compatible. Thus, the GPIO basic functionality is similar and is configurable using three registers for both families:
megaAVR AVRDX Description
MEGAAVR
AVRDX
Description
DDRx
PORTx.DIR
Data direction - controls the data direction (output driver)
PORTx
PORTx.OUT
Data out - controls the output driver level for each PORTx pin
PINx
PORTx.IN
Data in - shows the state of the PORTx pin
The following code snippets show how to configure the PORTA pin 7 as output-driven high for each family.
MEGAAVR - Port A, Pin 7 Configured as Output and Driven High
DDRA =0x80
PORTA =0x80
AVRDX - Port A, Pin 7 Configured as Output and Driven High
PORTA.DIR =0x80
PORTA.OUT =0x80
As you can see these are very different code segments to get the same thing to happen. In this case set a port.pin High.
This is a simple summary. The changes between the MEGAAVR and AVRDX is documented in the datasheet.
Direct Pin Configuration
The GPIO basic functionality is controlled using the three registers that reside in the extended I/O Register space. This space does not allow bit manipulation instructions, and the configuration update for one pin is done using the Read-Modify-Write instructions. The hardware Read-Modify-Write functionality ensures a safe and correct change of the drive values and/or input and sense configuration, but it is translated into three assembler instructions. The following code snippet shows the PA7 pin configuration as output:
The GPIO Basic Functionality and the Direct Pin Configuration need to be masked from the GCBASIC user code. In GCBASIC DIR sets the pin configuration and PORT.PIN sets the GPIO state ( High or Low ).
The major changes to the compiler is the translation from the GCBASIC instructions to the existing MegaAVR operations to the new AVRDX operations. See the post regarding AVRDX ALIASing for a detailed explanation of how this is implemented.
Exposing MegaAVR to AVRDX transformation
GCBASIC now handles the transformation from MegaAVR to AVRDX.
*Set Direction
An example: This example shows the instruction DIR PORTA IN
Notes:
- debug info IOAVRDX #1 is added to the ASM to show AVRDX transformation has been used
- the register is transformed from DDRA to PORTA_DIR
- the correct ASM instruction is used
MegaAVR
;DIR PORTA In
ldi SysValueCopy,0
out DDRA,SysValueCopy
AVRDX
;DIR PORTA In
ldi SysValueCopy,0
; IOAVRDX #1
sts PORTA_DIR,SysValueCopy
GPIO basic functionality
An example: This example shows the instruction PORTB = 8. This will set the PORTB.3 High.
Notes:
- debug info IOAVRDX #1 is added to the ASM to show AVRDX transformation has been used
- the register is transformed from PORTB to PORTB_OUT
- the correct ASM instruction is used
MegaAVR
;PORTB = 8
ldi SysValueCopy,8
out PORTB,SysValueCopy
To expose this key compiler information change the ini file entry as shown below.
[gcbasic]compilerdebug=32
As the compilerdebug entry is handled in a bitwise manner. A value of 32 will expose the AVRDX transformation information. As this is a bitwise value you can OR with other debug bits to expose other information.
Then search the ASM for for IOAVRDX. This appnote shows only operation IOAVRDX #1 there are others. Search for IOAVRDX to review.
Summary
This appnote is a simple overview of the complex operations to support AVRDX. The use of the debug capability will permit a deep understanding to the transformation operations and will enable easy support.
This appnote does not detail other operations completed by the transformations. Settings AVRDX IO registers is complex and the ASM generated can be reviewed in the ASM for a specific AVRDX chip.
Being able to expose the GCBASIC to AVRDX transformation is essential in ensuring the MegaAVR and AVRDX assembler is working correctly. Only will this type of information will users be assured that GCBASIC is generating valid ASM and HEX files.
Enjoy this information.
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quality checks against MegaAVR threw up some little duplicate ASM but no real progress.
The root cause is that GCASM does not support one specific ASM instruction. It happens to be the one instruction I need to use. The GCASM section was identified after six hours of debugging and reading disassembly of a Hex.
imagine the scene. GCBASIC generates an ASM file that work in Microchip Studio and in real silicon when programmed from Microchip Studio.... but, the real silicon does not operateas expected when programmed after passing through GCASM.
To find the issue required in depth knowledge of the hex code that relate to the ASM instruction in use.
In this specific case the instruction st z, syscopytemp was not working. I determined that by examination of the HEX files. But, to determine why was very hard.
In GCBASIC a support file called the CORE140.DAT file contains the ASM instruction set ( for this specific chip family). I could see the ASM was correct, I knew it worked from the tests in Microchip Studio, but, the GCASM disassembly was std z+, syscopyvalue!! Incorrect.
The root cause is that GCASM does not, it will soon!, support the four options of addressing when using Z indirect addressing. Actually, the four methods are no implemented at all and the interpretation from the ASM to the HEX is essentially random for this specific instruction ( this is the only error in GCASM I have ever seen).
So, what is this preventing ? and, the plan?
This lack of GCASM support prevents code like port.bit transformed to port.out = value when it an AVRDX IO registry like PORTA.OUT from working. As the onlymethods is to read the existing port status via indirect read, then, set the bit and an indirect write back.
The plan is change GCASM to support this insttuction. But, there be dragons within GCASM and to date I have never made any changes in this part of the compiler. But, there is always a first time... for everything.
Enjoy this update. A lost day really.
❤️
1
Last edit: Anobium 2024-07-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A sample program. I will post more as I progress through testing, compiler changes and validation.
This demo sets the LED on and off at a timed frequency.
- There are two different LEDs pulse.
- The first to show the chip has booted.
- The second to show that this chip is operating as expected.
The program also ensure the frequency is set correctly, the stack is initialised and the SFRs are operated as expected.
/*ThisdemosetstheLEDonandoffatatimedfrequency.-TherearetwosetsofLEDspulse.-Thefirsttoshowthechiphasbooted-Thesecondtoshowthatthischipisoperatingasexpected.Thedemoensurethefrequencyisset,thestackisinitialisedandtheSFRsareoperatedcorrectly.Thekeytests-isthetheDIR-isOUT/INoperateasexpectedusingexplicitassignments-frequencyoperatesasexpected-programusesexplicitportassignmentsONLY.EnjoyResources:Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdfMigrationfromthemegaAVR®toAVR®DxMicrocontrollerFamilies.pdfATtiny3216-17-DataSheet-DS40002205A.pdf------------PORTA---------------Bit#:-7---6---5---4---3---2---1---0---IO:----------------LED--------------IO:---------------------------------------------PORTB----------------Bit#:-7---6---5---4---3---2---1---0---IO:SW-------------------------------IO:--------------------------==-----------------PORTC----------------Bit#:-7---6---5---4---3---2---1---0---IO:---------------------------------IO:---------------------------------*/#CHIPTiny3217,20/48#optionExplicit#DEFINEOUTPORTPORTA#DEFINELEDBIT8// GPIO Basic Functionality DIRPORTAOut// Use the contstantsOUTPORT=LEDBITRepeat3OUTPORT=0Wait500msOUTPORT=LEDBITWait500msEndRepeatDoOUTPORT=0Wait50msOUTPORT=LEDBITWait450msLoop
The compilation message shows some new information in terms of oscillator determined ( in this case 0.4166667Mhz with the compiler calculating this frequency... so, see the #chip command). MegaAVRs never showed any information with respect to the oscillator - the assumption was that all MegaAVRs were using the frequency specified by the Fuses and that GCBASIC had no control over the frequency settings. LGTs have internal oscillator frequency control.
As part of the ADVDX implementation I have add a debug capability to GCASM.
Use the settings file as below, you will see the ASM, the binary encoded value and the HEX generated per ASM instruction/directive.
[gcbasic]compilerdebug=64
As with all compilerdebug this value is bitwise and it can be be ORed with other debug capabilities.
The picture shows the GCASM debug at the bottom and I have shown the resulting HEX in the top panel of GCCODE. You can see the relationship between the ASM-Hex value-result line in the HEX using the hilighted value of C03D. You can set the value swapped in the HEX ( see top ) on line 2.
With the new GCASM debug you can work out the relationship between the ASM, the CORE140.DAT file and the hex produced. Then, you een open the AVR Assembly Language PDF to understand how ASM is defined and how the HEX generated, per line of hex, relates to Instructions, Registers and other parameters.
Remember , when Hugh wrote most of this ... he was 14.
Last edit: Anobium 2024-07-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This differs from the first test program is this uses PORTn.PIN ( not PORTn = value ).
This tests a complety different part of the compiler to ensure PORTn.PIN is transformed into PORTn.OUT
/*ThisdemosetstheLEDonandoff.ThekeytestprogramisthethePORT.PINoperatesasexpected.TheGCBASICgeneratedASMcanalsobecompiledinMicrochipSTUDIO7.xthendebugged,programmedetc.EnjoyResources:Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdfMigrationfromthemegaAVR®toAVR®DxMicrocontrollerFamilies.pdfATtiny3216-17-DataSheet-DS40002205A.pdf------------PORTA---------------Bit#:-7---6---5---4---3---2---1---0---IO:----------------LED--------------IO:---------------------------------------------PORTB----------------Bit#:-7---6---5---4---3---2---1---0---IO:SW-------------------------------IO:--------------------------==-----------------PORTC----------------Bit#:-7---6---5---4---3---2---1---0---IO:---------------------------------IO:---------------------------------*/
#CHIPTiny3217,20/2
#optionExplicit
#DEFINEOUTPORTPORTA
#DEFINELEDBIT8// GPIO Basic Functionality DIRPORTAOut// This code should work as this was tested in 10_basic.. test programRepeat3OUTPORT=0Wait500msOUTPORT=LEDBITWait500msEndRepeat// The program is testing the port.bit assignment// 20 ( this program ) is a single port on and off assignment testDoOUTPORT.3=1Wait200msOUTPORT.3=0Wait2sLoop
AVRDX Transformation
The transformed ASM looks like this. The constant OUTPORT( PORTA) is transformed into PORTA_OUT, and, as this is not a low register the indirect register read and write is used with the correct bit being set in SysValueCopy.
;OUTPORT.3 = 1; IOAVRDX #2
ldi syscalctempb_u, low(PORTA_OUT)
ldi syscalctempb_e, high(PORTA_OUT)
ldi SysValueCopy, Z
sbr SysValueCopy,1<<3
st z+, SysValueCopy
This is a good step forward as many program uses PORTn.PIN
Enjoy
Last edit: Anobium 2024-07-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This uses another part of the compiler that handles logical statements like NOT.
This required two new sections of AVRDX transformation, but, it is getting easer for me as I know what to look for!
This uses OUTPORT.3 = !OUTPORT.3 which equates to PORT.3 = !PORTA.3. This required two sections of transformational code.
- 1. The source Portn.Pin - this is section AVRDX #3
- 2. The destination Portn.Pin- this is section AVRDX #4
To see the sections exposed in the ASM use the AVRDX debug bit.
/*ThisdemosetstheLEDonandoff.ThekeytestprogramisthethePORT.PINwithaNOToperatesasexpected.TheGCBASICgeneratedASMcanalsobecompiledinMicrochipSTUDIO7.xthendebugged,programmedetc.EnjoyResources:Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdfMigrationfromthemegaAVR®toAVR®DxMicrocontrollerFamilies.pdfATtiny3216-17-DataSheet-DS40002205A.pdf------------PORTA---------------Bit#:-7---6---5---4---3---2---1---0---IO:----------------LED--------------IO:---------------------------------------------PORTB----------------Bit#:-7---6---5---4---3---2---1---0---IO:SW-------------------------------IO:--------------------------==-----------------PORTC----------------Bit#:-7---6---5---4---3---2---1---0---IO:---------------------------------IO:---------------------------------*/
#CHIPTiny3217,20/2
#optionExplicit
#DEFINEOUTPORTPORTA
#DEFINELEDBIT8// GPIO Basic Functionality DIROUTPORTOut// This code should work as this was tested in 10_basic.. test programRepeat3OUTPORT=0Wait500msOUTPORT=LEDBITWait500msEndRepeat// The program is testing the port.bit assignment using a logical NOT statement// 30 ( this program ) is a single port on and off using logical NOTDoOUTPORT.3=!OUTPORT.3Wait100msLoop
AVRDX Transformation
The ASM below shows the transformation of OUTPORT ( PORTA) when reading the state as PORTA_IN and the transformation of OUTPORT ( PORTA) when setting the state as PORTA_OUT. It also shows the bit test and how SysValueCopy is used to set/clear the correct bit prior to the direct write.
This method does not use the Z register but uses direct read/write to the PORTA_IN/OUT registers.
This program sets the whole port off/on using logic NOT port state. This, again, flashes the LED but using the last method that I can think of.
/*ThisdemosetstheLEDonandoff.ThekeytestprogramisthethePORTwithaNOToperatesasexpected.TheGCBASICgeneratedASMcanalsobecompiledinMicrochipSTUDIO7.xthendebugged,programmedetc.EnjoyResources:Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdfMigrationfromthemegaAVR®toAVR®DxMicrocontrollerFamilies.pdfATtiny3216-17-DataSheet-DS40002205A.pdf------------PORTA---------------Bit#:-7---6---5---4---3---2---1---0---IO:----------------LED--------------IO:---------------------------------------------PORTB----------------Bit#:-7---6---5---4---3---2---1---0---IO:SW-------------------------------IO:--------------------------==-----------------PORTC----------------Bit#:-7---6---5---4---3---2---1---0---IO:---------------------------------IO:---------------------------------*/
#CHIPTiny3217,20/2
#optionExplicit
#DEFINEOUTPORTPORTA
#DEFINELEDBIT8// GPIO Basic Functionality DIROUTPORTOut// This code should work as this was tested in 10_basic.. test programRepeat3OUTPORT=0Wait500msOUTPORT=LEDBITWait500msEndRepeat// The program is testing the port.bit assignment using a logical NOT statement// 40 ( this program ) is a WHOLE port on and off using logical NOTDoOUTPORT=!OUTPORTWait100msOUTPORT=!OUTPORTWait250msLoop
AVRDX Transformation
This transformation is for a byte register to be read and inverted then written back.
The ASM tranformation requires two more methods. 1) If the DEST is an AVRDX IO register 2) If the SOURCE is an AVRDX IO register.
The OUTPUT constant is PORTA. The transformation is completed for the SOURCE and then to DEST registers. So, the LED flashes.
Next is 50. And, the last. As after this I think the compiler is sorted.
This sets the LED port.pin to the status of the input switch. This turns on the the LED when the switch is pressed.
The switch has the internal pullup set.
/*ThisdemosetstheLEDonandoff.ThekeytestprogramisthethePORT.PINoperatesasexpectedwhenthePINA.pinispressed.TheGCBASICgeneratedASMcanalsobecompiledinMicrochipSTUDIO7.xthendebugged,programmedetc.EnjoyResources:Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdfMigrationfromthemegaAVR®toAVR®DxMicrocontrollerFamilies.pdfATtiny3216-17-DataSheet-DS40002205A.pdf------------PORTA---------------Bit#:-7---6---5---4---3---2---1---0---IO:---------------------------------IO:---------------------------------------------PORTB----------------Bit#:-7---6---5---4---3---2---1---0---IO:---------------------------------IO:---------------------------------------------PORTC----------------Bit#:-7---6---5---4---3---2---1---0---IO:---------------------------------IO:---------------------------------*/
#CHIPTiny3217
#optionExplicit
#DEFINEOUTPORTPORTA
#DEFINELEDBIT8// GPIO Basic Functionality DIRPORTA.3OutDIRPORTB.7In// set the PULLUP for this specific port.pinPORTB_PIN7CTRL.3=1// This code should work as this was tested in 10_basic.. test programRepeat3OUTPORT=0Wait500msOUTPORT=LEDBITWait500msEndRepeat// The program is testing the port.bit assignment// 50 ( this program ) set LED to state of switchDo// b.7 switchPORTA.3=PINB.7Loop
Works well and compiles across all tools.
AVRDX Transformation
This transformation is for a register.bit to be read and then write to a register.bit.
The ASM tranformation requires two more methods. 1) If the DEST is an AVRDX IO register.bit 2) If the SOURCE is an AVRDX IO register.bit
The INPUT constant is PINB.7. The transformation is completed for the SOURCE and then to DEST registers. So, the LED flashes.
This is the completion of the compiler changes. The libraries will require updates by the users but many will require register updates to handle these new chips.
Do not post to this thread with issue with libraries. Start a new thread if one does not exist for the specific library.
Enjoy
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The revised compiler now supports AVRDX chips. The changes to support these chips is totally transparent to the user in terms of using GCBASIC.
The compiler will transform GCBASIC instructions to the new AVRDX registers and the compiler will handle this automatically.
The new AVRDX chips have many new features and all these are now available in GCBASIC. Examples are:
Register (Note)
Description
PORTx.DIRSEt
Writing a ‘1’ to any bit in this bit field will set the corresponding bit in PORTx.DIR, which will configure the corresponding pin as an output pin and enable the output driver
PORTx.DIRCLR
Writing a ‘1’ to any bit in this bit field will clear the corresponding bit in PORTx.DIR, which will configure the corresponding pin as an input-only pin and disable the output driver
PORTx.DIRTGL
Writing a ‘1’ to any bit in this bit field will toggle the corresponding bit in PORTx.DIR
PORTx.OUTSET
Writing a ‘1’ to any bit in this bit field will set the corresponding bit in PORTx.OUT, which will configure the corresponding pin to be driven high
PORTx.OUTCLR
Writing a ‘1’ to any bit in this bit field will clear the corresponding bit in PORTx.OUT, which will configure the corresponding pin to be driven low
PORTx.OUTTGL
Writing a ‘1’ to any bit in this bit field will toggle the corresponding bit in PORTx.OUT
Some of these are used in the transformation but all are available directly via GCBASIC.
ChipFiles
Chips files will be produced for all the chips in the AVRDX.
These chips will have a [ALIAS] section to support the new compiler.
Libraries
Many libraries will work, many will not. This is purely a function of the changes in the AVRDX chips in terms of registry name/register bit. Use the existing libraries as the basis and it will be easy to add any library functionality.
Enjoy the new capability.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Start with this post as AVRDx support is now released.
https://sourceforge.net/p/gcbasic/discussion/579125/thread/7b28c003d5/#34d4
Post from June 2024
The development is underway to change the compiler to support the Series and DX chips.
These chips are different they use very different methods to set ports. Port setting required Direct Pin Configuration and the compiler needs a large update to support these chips.
The resource I am using is this migration document. https://onlinedocs.microchip.com/pr/GUID-51D4F2DF-E4D3-4379-8E03-9AAF2593C7DA-en-US-3/index.html?GUID-FA83BA4E-77F9-481D-9D18-A19602979F71
See this video
This is not easy - changes the data model and some clever thinking has achieved the progress to date.
I am testing in a ATINT3217 if you want to follow along.
Ping me if you want to join in the fun.
Evan
Last edit: Anobium 2024-08-14
Title: Exciting Progress on the ADVRX Project with ATTINY3217 and New AVRDX Chips
Hello fellow developers,
I'm excited to share with you some significant progress I've made on the ADVRX project. I've managed to adapt the GCBASIC instruction set to work with the ATTINY3217 and the new AVRDX chips.
The compiler now sets the internal frequency correctly, handles conventional instructions like
DIR port IN|OUT, and setPORTvalues to use the new AVRDX instructions/registers. This is after three iterations of rewriting the compiler solution, I've found an approach that handles most cases effectively.The demo code, shown below, showcases basic operations, but also includes the sequence to set the frequency and control the protected registers. My goal is to maintain a compatible GCBASIC instruction set while supporting the ASM of the new DX chips.
A key part of this work is the new ALIAS section in the chip DAT file. This section maps the GCBASIC AVR ports to the new AVRDX chips, providing a flexible configuration that isn't hard-coded and can be adapted across the range of new AVR chips.
This is still early code and there's a lot more work to be done beyond the compiler, such as the libraries. But I'm committed to completing the compiler changes to support these AVRDX chips.
For those who want to use the compiler, please note that you will need build 1396 or greater.
Resources:
- Migration-from-megaAVR-to-AVR-DxMCU-Fam-DS00003731A.pdf
- Migration from the megaAVR® to AVR® Dx Microcontroller Families.pdf
- ATtiny3216-17-DataSheet-DS40002205A.pdf
Demo Code:
Looking forward to sharing more updates soon!
I guess I should add.... the demo code above flashes the LED 5 times then every 1 sec, forever.
This means.
1. The chip dat file is recognised and is being loaded
2. The initialisation of the frequency, as specified, is being handled appropriately, with the correct operation of the protected registers.
3.The ports are being initialisation to match GCBASIC operations
4. I will add a clear down of the RAM to 0 value ( same as the LGT chipset)
5. Then, the program set directions and handles basic port IO in the user program.
Progress today was slow.
**Chip frequency
Now working as expected. There will be two DAT files one for each baseline frequency that can be selected in the Fuses. The two options are 20mHz and 16mHz baseline frequency. The two DAT file will be identical apart from the internal frequencies that can be selected.
**RAM Memory Initialisation to 0x00
This operates as expected. This required a new stack initialisation routine. But, what took hours to resolve was the ASM was working when using MPLAB Studio ( ASM generated by GCBASIC) was working in real silicon but a hex generated by GCASM was failing.
The root causes was
1) The DAT file RAM memory definition is one byte larger than the same PIC entry. So, a range of 0x3800 to 0x3FFF is incorrect. The correct specification for AVR is 0x3800 to 0x4000. Very annoying. I will document the DAT file as I progress.
This memory is caused the low(RAMEND) to return 0xFE ( should be 0xFF) and it was only by inspection of the MPLAB and GBASM disassembly was I able to figure out why the stack was falling over.
2) The clock frequency was working correctly when programmer from MPLAB but not GCASM. This was caused by the GCASM adding 32 to the target register address. In this specific case the clock frequency setting register is protected and adding 32 to the unlock register meant the new clock frequency was being ignored. A simple ifAVRDX() resolved this issue.
So, not much progrest but the Nano board has a flashing LED and you can program direct from GCSTUDIO.
The hex files generated by MPLAB and GCBASIC/GCASM are identical. This is a great verification that things are working correctly. A reminder: You can write a GBASIC program, use the ASM file within an AVR MPLAB project to walk the code in the MPLAB simulator, debug on real silicon using the MPLAB Debugger. You can program using GCSTUDIO, drag and drop the HEX on the CDC Nano board or program via UPDI from within the MPLAB project.
--‐-----
Now the basics work. I will expand these basic output focused IO tests to direct port setting and logical port setting. Then, I will move onto IO input testing.
Enjoy this report on progress.
** Frequency setting
The new AVRDX have a wide range of internal frequencies. These are based on 20mHz or 16mHz divided by various scalers ( numeric values ).
As example is 20mHz / 48 = a number that is small and with a number of decimal places.
The issue using these frequencies is that users have to get the decimal value precisely correct to 7 decimal places. Not something that is realistic. The user frequency specified value has to precisely match the value in the DAT file.
**Solution
The compiler now supports division when specifying the frequency.
So, the following are now valid.
The compiler will show a calculation has been used for the frequency and if the frequency matches a valid frequency in the DAT file then the compiler will display 'Internal Oscillator'.
This new capability will work across all chips but very few have the 7 decimal frequency specification like the AVRDX chips.
Enjoy this update.
GPIO Basic Functionality
The megaAVR and AVR Dx families are not pin-to-pin compatible. Thus, the GPIO basic functionality is similar and is configurable using three registers for both families:
megaAVR AVRDX Description
The following code snippets show how to configure the PORTA pin 7 as output-driven high for each family.
MEGAAVR - Port A, Pin 7 Configured as Output and Driven High
DDRA =0x80
PORTA =0x80
AVRDX - Port A, Pin 7 Configured as Output and Driven High
PORTA.DIR =0x80
PORTA.OUT =0x80
As you can see these are very different code segments to get the same thing to happen. In this case set a port.pin High.
This is a simple summary. The changes between the MEGAAVR and AVRDX is documented in the datasheet.
Direct Pin Configuration
The GPIO basic functionality is controlled using the three registers that reside in the extended I/O Register space. This space does not allow bit manipulation instructions, and the configuration update for one pin is done using the Read-Modify-Write instructions. The hardware Read-Modify-Write functionality ensures a safe and correct change of the drive values and/or input and sense configuration, but it is translated into three assembler instructions. The following code snippet shows the PA7 pin configuration as output:
Assembler Code
The GPIO Basic Functionality and the Direct Pin Configuration need to be masked from the GCBASIC user code. In GCBASIC
DIRsets the pin configuration andPORT.PINsets the GPIO state ( High or Low ).The major changes to the compiler is the translation from the GCBASIC instructions to the existing MegaAVR operations to the new AVRDX operations. See the post regarding AVRDX ALIASing for a detailed explanation of how this is implemented.
Exposing MegaAVR to AVRDX transformation
GCBASIC now handles the transformation from MegaAVR to AVRDX.
*Set Direction
An example: This example shows the instruction
DIR PORTA INNotes:
- debug info IOAVRDX #1 is added to the ASM to show AVRDX transformation has been used
- the register is transformed from DDRA to PORTA_DIR
- the correct ASM instruction is used
MegaAVR
AVRDX
GPIO basic functionality
An example: This example shows the instruction
PORTB = 8. This will set the PORTB.3 High.Notes:
- debug info IOAVRDX #1 is added to the ASM to show AVRDX transformation has been used
- the register is transformed from PORTB to PORTB_OUT
- the correct ASM instruction is used
MegaAVR
AVRDX
Exposing AVRDX transformation(s)
To expose this key compiler information change the ini file entry as shown below.
As the
compilerdebugentry is handled in a bitwise manner. A value of 32 will expose the AVRDX transformation information. As this is a bitwise value you can OR with other debug bits to expose other information.Then search the ASM for for
IOAVRDX. This appnote shows only operation IOAVRDX #1 there are others. Search forIOAVRDXto review.Summary
This appnote is a simple overview of the complex operations to support AVRDX. The use of the debug capability will permit a deep understanding to the transformation operations and will enable easy support.
This appnote does not detail other operations completed by the transformations. Settings AVRDX IO registers is complex and the ASM generated can be reviewed in the ASM for a specific AVRDX chip.
Being able to expose the GCBASIC to AVRDX transformation is essential in ensuring the MegaAVR and AVRDX assembler is working correctly. Only will this type of information will users be assured that GCBASIC is generating valid ASM and HEX files.
Enjoy this information.
**GCASM discovery .. a lost day **
No progress really today.
Quality checks against MegaAVR threw up some little duplicate ASM but no real progress.
The root cause is that GCASM does not support one specific ASM instruction. It happens to be the one instruction I need to use. The GCASM section was identified after six hours of debugging and reading disassembly of a Hex.
imagine the scene. GCBASIC generates an ASM file that work in Microchip Studio and in real silicon when programmed from Microchip Studio.... but, the real silicon does not operateas expected when programmed after passing through GCASM.
To find the issue required in depth knowledge of the hex code that relate to the ASM instruction in use.
In this specific case the instruction
st z, syscopytempwas not working. I determined that by examination of the HEX files. But, to determine why was very hard.In GCBASIC a support file called the CORE140.DAT file contains the ASM instruction set ( for this specific chip family). I could see the ASM was correct, I knew it worked from the tests in Microchip Studio, but, the GCASM disassembly was
std z+, syscopyvalue!! Incorrect.The root cause is that GCASM does not, it will soon!, support the four options of addressing when using Z indirect addressing. Actually, the four methods are no implemented at all and the interpretation from the ASM to the HEX is essentially random for this specific instruction ( this is the only error in GCASM I have ever seen).
So, what is this preventing ? and, the plan?
This lack of GCASM support prevents code like
port.bittransformed toport.out = valuewhen it an AVRDX IO registry likePORTA.OUTfrom working. As the onlymethods is to read the existing port status via indirect read, then, set the bit and an indirect write back.The plan is change GCASM to support this insttuction. But, there be dragons within GCASM and to date I have never made any changes in this part of the compiler. But, there is always a first time... for everything.
Enjoy this update. A lost day really.
Last edit: Anobium 2024-07-18
A sample program. I will post more as I progress through testing, compiler changes and validation.
This demo sets the LED on and off at a timed frequency.
- There are two different LEDs pulse.
- The first to show the chip has booted.
- The second to show that this chip is operating as expected.
The program also ensure the frequency is set correctly, the stack is initialised and the SFRs are operated as expected.
The compilation message shows some new information in terms of oscillator determined ( in this case 0.4166667Mhz with the compiler calculating this frequency... so, see the #chip command). MegaAVRs never showed any information with respect to the oscillator - the assumption was that all MegaAVRs were using the frequency specified by the Fuses and that GCBASIC had no control over the frequency settings. LGTs have internal oscillator frequency control.
AVRDX Transformation
The program shows the assignment of PORTn = value. Where in this case that is PORTA =8 ( which sets the PORTA.3 bit on/off).
The program uses the constants OUTPORT = LEDBIT whcih equates to PORTA = 8.
The transformation PORTA to PORTA_OUT is shown with the correct write to the PORTA_OUT register.
This clearly is using the latest compiler build.
Enjoy
Last edit: Anobium 2024-07-19
For those that deep dive
As part of the ADVDX implementation I have add a debug capability to GCASM.
Use the settings file as below, you will see the ASM, the binary encoded value and the HEX generated per ASM instruction/directive.
As with all compilerdebug this value is bitwise and it can be be ORed with other debug capabilities.
The picture shows the GCASM debug at the bottom and I have shown the resulting HEX in the top panel of GCCODE. You can see the relationship between the ASM-Hex value-result line in the HEX using the hilighted value of
C03D. You can set the value swapped in the HEX ( see top ) on line 2.Enjoy.
Last edit: Anobium 2024-07-19
And, therefore...
With the new GCASM debug you can work out the relationship between the ASM, the CORE140.DAT file and the hex produced. Then, you een open the AVR Assembly Language PDF to understand how ASM is defined and how the HEX generated, per line of hex, relates to Instructions, Registers and other parameters.
Remember , when Hugh wrote most of this ... he was 14.
Last edit: Anobium 2024-07-19
Next program. This is file 20_basic_port_pin.gcb
This differs from the first test program is this uses PORTn.PIN ( not PORTn = value ).
This tests a complety different part of the compiler to ensure PORTn.PIN is transformed into PORTn.OUT
AVRDX Transformation
The transformed ASM looks like this. The constant OUTPORT( PORTA) is transformed into PORTA_OUT, and, as this is not a low register the indirect register read and write is used with the correct bit being set in SysValueCopy.
This is a good step forward as many program uses PORTn.PIN
Enjoy
Last edit: Anobium 2024-07-19
Next program is 30_logical_port_pin.gcb
This uses another part of the compiler that handles logical statements like NOT.
This required two new sections of AVRDX transformation, but, it is getting easer for me as I know what to look for!
This uses
OUTPORT.3 = !OUTPORT.3which equates toPORT.3 = !PORTA.3. This required two sections of transformational code.- 1. The source Portn.Pin - this is section AVRDX #3
- 2. The destination Portn.Pin- this is section AVRDX #4
To see the sections exposed in the ASM use the AVRDX debug bit.
AVRDX Transformation
The ASM below shows the transformation of OUTPORT ( PORTA) when reading the state as
PORTA_INand the transformation of OUTPORT ( PORTA) when setting the state asPORTA_OUT. It also shows the bit test and how SysValueCopy is used to set/clear the correct bit prior to the direct write.This method does not use the Z register but uses direct read/write to the PORTA_IN/OUT registers.
Enjoy
Next is 40
This program sets the whole port off/on using logic NOT port state. This, again, flashes the LED but using the last method that I can think of.
AVRDX Transformation
This transformation is for a byte register to be read and inverted then written back.
The ASM tranformation requires two more methods. 1) If the DEST is an AVRDX IO register 2) If the SOURCE is an AVRDX IO register.
The OUTPUT constant is PORTA. The transformation is completed for the SOURCE and then to DEST registers. So, the LED flashes.
Enjoy
Last edit: Anobium 2024-07-20
Next is 50. And, the last. As after this I think the compiler is sorted.
This sets the LED port.pin to the status of the input switch. This turns on the the LED when the switch is pressed.
The switch has the internal pullup set.
Works well and compiles across all tools.
AVRDX Transformation
This transformation is for a register.bit to be read and then write to a register.bit.
The ASM tranformation requires two more methods. 1) If the DEST is an AVRDX IO register.bit 2) If the SOURCE is an AVRDX IO register.bit
The INPUT constant is PINB.7. The transformation is completed for the SOURCE and then to DEST registers. So, the LED flashes.
This is the completion of the compiler changes. The libraries will require updates by the users but many will require register updates to handle these new chips.
Do not post to this thread with issue with libraries. Start a new thread if one does not exist for the specific library.
Enjoy
Change Summary
The revised compiler now supports AVRDX chips. The changes to support these chips is totally transparent to the user in terms of using GCBASIC.
The compiler will transform GCBASIC instructions to the new AVRDX registers and the compiler will handle this automatically.
The new AVRDX chips have many new features and all these are now available in GCBASIC. Examples are:
Some of these are used in the transformation but all are available directly via GCBASIC.
ChipFiles
Chips files will be produced for all the chips in the AVRDX.
These chips will have a [ALIAS] section to support the new compiler.
Libraries
Many libraries will work, many will not. This is purely a function of the changes in the AVRDX chips in terms of registry name/register bit. Use the existing libraries as the basis and it will be easy to add any library functionality.
Enjoy the new capability.
The GitHub URL to the test programs.
https://github.com/GreatCowBASIC/Demonstration_Sources/tree/main/TestSolutions/AVRDX_implementation/tiny3217
Also, already available on the GCB Demonstrations Pack for install/update at:
https://sourceforge.net/projects/gcbasic/files/GCStudio%20-%20Complete%20IDE%20and%20Toolchain%20for%20Windows/GCBdemonstrationsPack.exe/download
Or, click on "Install or Update the Demonstration Sources" in the GCstudio main panel:
This will install or update all demonstrations sources on your current GCstudio installation.
Last edit: Angel Mier 2024-07-20
An introduction to AVRDx ...
**It is a fast but fun video **
Click the word YOUTUBE to watch full screen.
This shows the basic operations - GCBASIC rocks.
Last edit: Anobium 2024-08-14
A deeper dive into AVRDx ...
*Some of the nuts and bolts of using AVRDx
Click the word YOUTUBE to watch full screen.
This shows the more of the operations - GCBASIC rocks.
Enjoy