A look at the aforementioned devices, lets call them tiny10 devices? and their general purpose register memory map and compare it to say the mega328P. See attachments from their data sheets.
PICs have the W register, AVR has the general purpose registers to play with, no?
I do not understand either, but somewhere in the compiler, libraries assign system temp variables. In AVR devices, at least some of those temp variables, they are being assigned to the AVR general purpose registers, which is a good thing, saves on RAM. Say for instance in the wait library GCB assigns .DEF DELAYTEMP=r25
For the tiny10 devices you would not want to assign a temp variable to general purpose registers r0-r15. Tiny10 devices do not have r0-r15 general purpose registers, I don't no how else to explain it.
Please ignore comment on overflow, not related to C or status.
OK
Hope it is more clear? but if not then I can try again.
It terms of the base registers it is now using r16-r31. This is goodness.
Q1. How much RAM do these chips have? 32 bytes at location 0x40 to 0x60. Is this correct?
Q2. The Registers are r16 to r32. But, the system registers take up 17 registers. That is the way Hugh architected the compiler. So, I have chosen to move SYSSIGNBYTE to RAM. Clearly, SYSSIGNBYTE is used when doing Integet maths. If there is a better SYSTEM variable to move to RAM then we have one chance of making this happen - now.
Q3. GPR, as stated in the dat file, does not seem to be used by the compiler, but does exist in the DAT file. And, this is set to 32 in ALL the TINY dat files. I could resolve this memory usafge issue by setting to GPR =16 and then assuming that GPRs start at r16. This way I do not need new class.
A new point. May not need a new class - see Q3.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Q2 Have no preference, so defer to Hugh or whoever. Your selection seems like a reasonable one, that SYSTEM VAR perhaps doesn't get used much, save some temp sensors and draw circles for glcds off the top of my head.
Q3 Good
EDIT:
Q1 tiny4_5_9_10 and tiny102_104 from data sheet, but wouldn't want to cheat an extra register if compiler handles it differently?
[FreeRAM]
40:5F
tiny20 [FreeRAM]
40:BF
tiny40 [FreeRAM]
40:13F
Last edit: kent_twt4 2020-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK Still getting clarity to ensure I get this correct.
Stil on same question.
Q1. So for the TINY10 we have 32 bytes of RAM plus the 16 GPRs? It is a Yes answer, or, a corrective answer. For the other I am assuming the following only have 16 GPRs.
4, 5,9,10, 102 and 104.
Not sure where the 10fs fit in this (if 10fs is a comment then ok)
Q2. I just tried the most simpliest of integer maths.. there is such a little amount of PROGMEM ... got an error re PROGMEM space. So, I will go with SYSSIGNBYTE
Q3. GPR=16 as shown above.
I can compile into 0.98.07 release 15. That is the next release candidate - we are awaiting Hugh to do some work then I will release as GA.
Testing needs to make sure the other AVR Tiny chips still work - this could be a compare of the ASM.
Testing needs to make sure these chips work as expected.
This needs to be done first...by the same person.... not as an after thought.
So, what is the detailed plan to get this tested ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PICs have the W register, AVR has the general purpose registers to play with, no?
For the tiny10 devices you would not want to assign a temp variable to general purpose registers r0-r15. Tiny10 devices do not have r0-r15 general purpose registers, I don't no how else to explain it.
Please ignore comment on overflow, not related to C or status.
Last edit: kent_twt4 2020-06-01
Progress and lots of question.
It terms of the base registers it is now using r16-r31. This is goodness.
Q1. How much RAM do these chips have? 32 bytes at location 0x40 to 0x60. Is this correct?
Q2. The Registers are r16 to r32. But, the system registers take up 17 registers. That is the way Hugh architected the compiler. So, I have chosen to move SYSSIGNBYTE to RAM. Clearly, SYSSIGNBYTE is used when doing Integet maths. If there is a better SYSTEM variable to move to RAM then we have one chance of making this happen - now.
Q3. GPR, as stated in the dat file, does not seem to be used by the compiler, but does exist in the DAT file. And, this is set to 32 in ALL the TINY dat files. I could resolve this memory usafge issue by setting to GPR =16 and then assuming that GPRs start at r16. This way I do not need new class.
A new point. May not need a new class - see Q3.
Good job with the registers!
Q1 Wikipedia https://en.wikipedia.org/wiki/ATtiny_microcontroller_comparison_chart but yeah 32 bytes of RAM for the most part. But considering the 16 GPRs, you are way better off than the older PIC 10fs.
Q2 Have no preference, so defer to Hugh or whoever. Your selection seems like a reasonable one, that SYSTEM VAR perhaps doesn't get used much, save some temp sensors and draw circles for glcds off the top of my head.
Q3 Good
EDIT:
Q1 tiny4_5_9_10 and tiny102_104 from data sheet, but wouldn't want to cheat an extra register if compiler handles it differently?
[FreeRAM]
40:5F
tiny20
[FreeRAM]
40:BF
tiny40
[FreeRAM]
40:13F
Last edit: kent_twt4 2020-06-01
OK Still getting clarity to ensure I get this correct.
Stil on same question.
Q1. So for the TINY10 we have 32 bytes of RAM plus the 16 GPRs? It is a Yes answer, or, a corrective answer. For the other I am assuming the following only have 16 GPRs.
4, 5,9,10, 102 and 104.
Not sure where the 10fs fit in this (if 10fs is a comment then ok)
Q2. I just tried the most simpliest of integer maths.. there is such a little amount of PROGMEM ... got an error re PROGMEM space. So, I will go with SYSSIGNBYTE
Q3. GPR=16 as shown above.
I can compile into 0.98.07 release 15. That is the next release candidate - we are awaiting Hugh to do some work then I will release as GA.
So, what is the detailed plan to get this tested ?
Q1 Yes is the answer. Don't forget GPR=16 for tiny20 and 40 too. 10f's comment only sorry, need to restrict commentary here.
Q3 GPR=16 is correct for these tiny10 type devices
Testing - I have the attiny104-XNano board for testing. That's it.
OK. I will update the release candidate tomorrow. My Tuesday.
Need to test on 104 and something else to ensure nothing got broken.
Is the list? 4, 5,9,10, 20, 40, 102 and 104. I need the list so I can update the .dat files.
Ping me a VM if you can help on this testing. Not you Kent.. you are the main man.
Yes that is the list for the .dat files.
Explain what "something else" means to you. Other tinys like the 13a, 44,85, 2313a ?(have those) or like 4-5-9-10, 20, 40,102? (Don't have).
I could order a 10 and 40 say if that is what you mean? Would take a week to 10 days with snail mail. I seem to be off the sample program.
EDIT: found a tiny10 on an OSHPark ATtiny10 Landing Pad
Last edit: kent_twt4 2020-06-01
I have updated the AVR chip database. Adding a new field per record. This new field is the GPR. The GPR was previously hard coded at 32.
The following are now set to 16.
Last edit: Anobium 2020-06-02