When you initially set the fuses, there are bytes to set up the APPEND, BOOTEND
which control the size of your main code section, your bootloader section, and your APPDATA section. I think I've gotten the sizes wrong in the fuses, so my MCU will not trigger any interrupts unless I put in the following code:
I have not seen any issues or mention of moving the vectors like this on forums so I'm assuming that I'm missing something. Maybe it is necessary. I program exclusively in ASM and people in the forums use "C" almost exclusively. The AVR-GCC compiler does things that you will never know about unless you look in the assembly listing... maybe that code is in there?
Your boards probably come with all fuses set as well as a debugger/UPDI chip as a working unit . I buy the chips and solder them to breakout boards, no debugger so the chips have default factory settings. This is a problem I'm working on, but I have no answers at this point. If it works is ultimately all I care about. I don't know if the above code is required or not. The new AVR-0 / 1 chips aren't like the older AVRs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The answer maybe for you to set the .org above the interrupt vectors. What you are describing looks the same as legacy AVR an LGTs. Have a look at set your org the same as the as the GCBASIC org, and, take all the vector stuff. Does that resolve?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will try it again. Since I started working on AVR-0/1 chips, I have spent days on this issue... which may not even be an issue except for my understanding of the basic MCU function. I might have to put in a ticket with Microchip. It wouldn't hurt to test it on your hardware to see what works for you, for now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
O.K. think I have it. The 0x1288 BOOTEND FUSE was set to 2 and I have no bootloader... anyway
I changed your Loopback demo from USART3 to USART1 , set it to 57.6K, compiled it and ran it on the 4809. it seems to echo exactly what is typed after the (Splash Screen) message. It's good to see results ! Also thanks for the Honorable mention on your video.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The compiler successfully updated. Anything pressing that you need worked on? or shall I just press on?. Trying to work the most used peripherals first. You have Timer Counter A and B in PWM, Timer Counter B as a periodic interrupt. Is there anything with USART serial we need to address? I'll continue, Let me know if I need to switch gears.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@cribcat re the question about what needs to be worked on - this may help.
Ask any questions.
NotS - Not Started
ASM - ASM provided
ERVBack - In Evan's Backlog
WIP - Work In Progress
DONE - Done!
Cribcat - Item assigned to Greg
Functionality
Status
Comments
OSC
Completed
Demo published
PIN Operations
Completed
Demo published
Serial/USART
Evan WIP
Completed library. Now ensuring Serial Buffer Ring works.
Interrupts
ASM;ERVBACK
Use the Serial, PIN, PWM and Timer ASM to verify handler
Timers
ASM;ERVBACK
NotS
millis()
NotS
This is an implementation of mills() at 16mHz ( I dont think the internal clock at 20mHZ will support millis(). This is essentially Timer0 interrupy every millsecond. See millis.h for implementation.
I2C
Cribcat
Basic Init/Start/Send & Receive/End
Memory DATA
ERVBack
This is ability to add DATA blocks to ASM. Currently NO AVR is supported!
Memory PROGMEM
Cribcat
This self write capability/methods to write/read to PROGMEM
Memory EEPROM
Cribcat
This self write capability/methods to write/read to EEPROM; and, for of EEPROM as defined in ASM
@evanvennn : That list will do fine. Thank You. As far as what you already have... I've made a directory to put copies of all sent items , we can cross check if necessary. I see you have put them on github... good.
The problem with moving the Vectors on my chip seems to have been solved by writing the correct fuse byte to BOOTEND. You can delete or comment out the move_vectors routine .
I used Bret Mulvey 's delay loop calculatorfor my delays in my code. we should probably replace the delay loops with GCbasic assembled ones or give Bret credit?
the website is now :http://darcy.rsgc.on.ca/ACES/TEI4M/AVRdelay.html
I can do that if need be .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Evan,
What is this code supposed to do? I'm curious:
"Memory DATA: This is ability to add DATA blocks to ASM. Currently NO AVR is supported!"
I have a GitHub account but I can not edit/add documents on your GitHub. I have attached a little blurb for the delay loop webpage I mentioned yesterday. I don't publish on GitHub... so I'm ignorant of how it works.
I will re post the " MEGA4809_32K_OSC_TCB_PWM.asm " updated code.
So, the format/structure that I need to implement for AVR is needed not an ASM example, and, validate the max value of PROGMEM ( 16f for example has a max number of 14bit/0x3FFF whereas the 18F has 16bit/0xFFFF. ).
Currently, this is the state of play. GCBASIC is generating the ASM shown below.
#chipmega4809DATADataSet1asByte3,2,0x4000EndDATA
gives ASM generated
; DATA blocks. DATA blocks are contiguous and may, or may not, overlap page boundary(ies).
DATASET1:
dw 0x0003, 0x0002, 0x4000
This looks ok, but, I think this all wrong. dw?, lable looks ok, is AVR 14bit ? So 0x4000 would be OK ?
Any insights you can provide will help me update that bit of the compiler to ensure the ASM / HEX generated works!
:-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Here is Timer Counter A Splitmode PWM. Splits the 16bit timer to function as two 8 bit PWMs.
Last edit: cribcat 2024-08-21
@cribcat ( I have added you to the DEV group, so, you should get a message to alert you).
Greg,
Can you explain ? I do not understand. What needs to be supported?
Evan
When you initially set the fuses, there are bytes to set up the APPEND, BOOTEND
which control the size of your main code section, your bootloader section, and your APPDATA section. I think I've gotten the sizes wrong in the fuses, so my MCU will not trigger any interrupts unless I put in the following code:
I have not seen any issues or mention of moving the vectors like this on forums so I'm assuming that I'm missing something. Maybe it is necessary. I program exclusively in ASM and people in the forums use "C" almost exclusively. The AVR-GCC compiler does things that you will never know about unless you look in the assembly listing... maybe that code is in there?
Your boards probably come with all fuses set as well as a debugger/UPDI chip as a working unit . I buy the chips and solder them to breakout boards, no debugger so the chips have default factory settings. This is a problem I'm working on, but I have no answers at this point. If it works is ultimately all I care about. I don't know if the above code is required or not. The new AVR-0 / 1 chips aren't like the older AVRs.
The answer maybe for you to set the .org above the interrupt vectors. What you are describing looks the same as legacy AVR an LGTs. Have a look at set your org the same as the as the GCBASIC org, and, take all the vector stuff. Does that resolve?
That's a good suggestion, I have cut and pasted the Vector list from one of your demo's assembly listings a few days ago with no positive results.
I will try it again. Since I started working on AVR-0/1 chips, I have spent days on this issue... which may not even be an issue except for my understanding of the basic MCU function. I might have to put in a ticket with Microchip. It wouldn't hurt to test it on your hardware to see what works for you, for now.
O.K. think I have it. The 0x1288 BOOTEND FUSE was set to 2 and I have no bootloader... anyway
I changed your Loopback demo from USART3 to USART1 , set it to 57.6K, compiled it and ran it on the 4809. it seems to echo exactly what is typed after the (Splash Screen) message. It's good to see results ! Also thanks for the Honorable mention on your video.
So, I can document. Is BOOTEND = 0, and APPEND = 0 ?
I will pull out and document the FUSES for the Microchip board.
The compiler successfully updated. Anything pressing that you need worked on? or shall I just press on?. Trying to work the most used peripherals first. You have Timer Counter A and B in PWM, Timer Counter B as a periodic interrupt. Is there anything with USART serial we need to address? I'll continue, Let me know if I need to switch gears.
Here's some pin operations to set and clear the pullup resistors and setting/clearing a pin with OUTSET/OUTCLR.
An outstanding work you and Evan are doing!
Congratulations and keep the good work.
Angel
Thanks Angel,
step by step we will get there.
Here is an example of a pin interrupt.
@cribcat re the question about what needs to be worked on - this may help.
Ask any questions.
NotS - Not Started
ASM - ASM provided
ERVBack - In Evan's Backlog
WIP - Work In Progress
DONE - Done!
Cribcat - Item assigned to Greg
For published demos - see https://github.com/GreatCowBASIC/Demonstration_Sources/tree/main/TestSolutions/AVRDX_implementation/mega4809
I will add your ASM to GitHub - as a great reference!
Have I missed anything / any ASM I have?
Evan
Last edit: Anobium 2024-08-25
@evanvennn : That list will do fine. Thank You. As far as what you already have... I've made a directory to put copies of all sent items , we can cross check if necessary. I see you have put them on github... good.
The problem with moving the Vectors on my chip seems to have been solved by writing the correct fuse byte to BOOTEND. You can delete or comment out the move_vectors routine .
Thanks
Greg
:-)
I used Bret Mulvey 's delay loop calculatorfor my delays in my code. we should probably replace the delay loops with GCbasic assembled ones or give Bret credit?
the website is now :http://darcy.rsgc.on.ca/ACES/TEI4M/AVRdelay.html
I can do that if need be .
Great point.
If you have time and you have access to GitHub you should attribute to the author. That would be the best solution.
MEGA4809_32K_OSC_TCB_PWM.asm Line 36 "|CLKCTRL_CLKOUT_bm" needs to be edited out . the line should be
ldi tmp, CLKCTRL_CLKSEL_OSCULP32K_gc
CLK OUT could pop something on your chip or damage whatever is connected to it if hooked up directly.(worst case scenario)
Can you re issue that demo? Then, I know I have it right.
Evan,
What is this code supposed to do? I'm curious:
"Memory DATA: This is ability to add DATA blocks to ASM. Currently NO AVR is supported!"
I have a GitHub account but I can not edit/add documents on your GitHub. I have attached a little blurb for the delay loop webpage I mentioned yesterday. I don't publish on GitHub... so I'm ignorant of how it works.
I will re post the " MEGA4809_32K_OSC_TCB_PWM.asm " updated code.
Thanks for the TXT. I will upload.
"Memory DATA: This is ability to add DATA blocks to ASM. Currently NO AVR is supported!"
This is relatively simple. This is a block of PROGMEM that starts with a label.
Here is the Help page - https://gcbasic.sourceforge.io/help/_data.html
So, the format/structure that I need to implement for AVR is needed not an ASM example, and, validate the max value of PROGMEM ( 16f for example has a max number of 14bit/0x3FFF whereas the 18F has 16bit/0xFFFF. ).
Currently, this is the state of play. GCBASIC is generating the ASM shown below.
gives ASM generated
This looks ok, but, I think this all wrong.
dw
?, lable looks ok, is AVR 14bit ? So 0x4000 would be OK ?Any insights you can provide will help me update that bit of the compiler to ensure the ASM / HEX generated works!
:-)
Here is the updated " MEGA4809_32K_OSC_TCB_PWM (updated).asm "
I have uploaded to GitHub. Thanks.
And here is a sleep demo. It's not on the work list, you may have already done it.
Great addition. I have basic SLEEP only.
Thanks.
Here's my thoughts on Memory DATA.
it got a little long so see the attached text.