Tiny4-5-9-10 and a couple of others like tiny104-204 not going to happen, or should I say unsupported by GCB. These devices use only 16 data registers as opposed to the normal 32. So, major? library rework required to assign variables and temp variables to 0-15 data space for these type of tinys.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
but they are supported :)
anyway i know it has some restrictiosn, original is "is there an alternative" ?
i.e. any other way to choose between two variables in tiny9 ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GCBasic uses temp variables for reusability, and if one happens to be out of range, then unexpected things will probably happen or fail. This assembly from a attiny10 program stores those temps in r22, r21, and r0.
What idea?
Based on kemt research its true that tiny9 has only r15-31 so its logic with r0 in ise mot to work
Simple tweaking in yasmyasmaea possible but if certain limitation exis
I believe rhey should mention in docs
For example "in tiny9" condition with variables is not
Last edit: Christos 2020-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK. Kent is not on the same compiler. He has a much older compiler - probably years old.
I am on the latest. The only versiion that will get fixed.
So, when you are online and able to test - we may want to get you on the latest to ensure you have the latest. See me a Personal Message with your email address and I will send you a download URL to the development code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From my notes here. Yep .. I keep a record of almost everything...
The tiny4-5-9-10 and tiny102-104 should be a different family code from the other tiny's. Only 16 GPR's from r16-r31 and only 54 instructions. Can easily overflow the GPR's with system variables and no compiler warning when they go below r16.
I kept a note if this as it was the identification of an issue that had no resolution.
I have this written under the information above. But, I don't know who wrote this originally.
When I began the ATtiny10 dat sheet development, there still was a tn10def.inc available from Studio. Between that, and using a limited free pdf to text conversion utility by Zamzar, I was also attempting to pick out maxmhz, package info, and pins from the Device Summary pdf. All very rough, not all put together or even finished using Python36.
Going forward it looks like attention will have to be paid by these series designations like attiny series 0 and series 1, mega series 0 and so forth.
So, it looks like we need a new sub chip family and some variable constraints checking in the compiler... and, a good look at the dat file to understand why the compiler was not throwing a message.
Last edit: Anobium 2020-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The issue is these ATtiny4_5_9_10, ATTiny20_40, and ATtiny102_104 devices have only 16 General Purpose Registers, as opposed to all other AVR devices? that have 32. So when the compiler starts assigning system variables to these registers, it thinks it has 32. The dat files should reflect GPR=16 and new family code.
An exception needs to be created or an #ifdef GPR=16? for these devices to limit the range from r16-r31, when aggregating and/or assigning system variables. If there is an overflow, then start placing in RAM?
The ATTiny104 dat file was handcrafted from the data sheet way back from previous post.
OK, you beat me to the post :-)
Your note was apparently my wording. Ooof... can't remember if those ATtiny4_5_9_10, ATtiny20_40 were mine or not. I definetely remember the ATtiny104 though because I have the ATtiny104-XNano.
Well it is not going to get resolved unless I have clarity,
The issue is these ATtiny4_5_9_10, ATTiny20_40, and ATtiny102_104 devices have only 16 General Purpose Registers, as opposed to all other AVR devices? that have 32. So when the compiler starts assigning system variables to these registers, it thinks it has 32. The dat files should reflect GPR=16 and new family code.
Is the what you are saying. Cus, I have not really understood the questions.
ATtiny4_5_9_10, ATTiny20_40, and ATtiny102_104 devices require a new chip family, or, sub chipfamily. A new AVR class.
This new AVR class of chips will only support 16 registers.
Is the #ifdef GPR=16 a solution? As I do not understand the question.
And, registers available are r16 to r31 then you refer to an overflow. Can you explain? Is the overflow the C register overflow or some other overflow? and, why would this overflow cause the writimg in RAM.
Re the ATTINT104. OK. Keep it here until I get to creating these formally. I have everything under change control and this will mess things up here.
Yep. probably you wording but I I never go to understanding the issue. Maybe I should now. :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't answer that question. But presumably the class is defined by how many, or which assembly instructions are available? Could be a subclass of the other tinys?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi
calling
If variable then ..
is NOT working with tiny9
is there an alternative way to check variabels in tiny9 ?
Tiny4-5-9-10 and a couple of others like tiny104-204 not going to happen, or should I say unsupported by GCB. These devices use only 16 data registers as opposed to the normal 32. So, major? library rework required to assign variables and temp variables to 0-15 data space for these type of tinys.
but they are supported :)
anyway i know it has some restrictiosn, original is "is there an alternative" ?
i.e. any other way to choose between two variables in tiny9 ?
You could use True/False?, in GCB True is 255.
If myvar True Then...
if var2 true Then
does not compile for any avr
if var2=true then
if var2=1 then etc
do not execute inside tiny9 for a reason
if PORTB.1 then
it DOES execute, so i guess can not compare variables
Post your asm file then we can have a look.
GCBasic uses temp variables for reusability, and if one happens to be out of range, then unexpected things will probably happen or fail. This assembly from a attiny10 program stores those temps in r22, r21, and r0.
and SYSTEMP1 is used in a do loop which would be a fail because of the out of range general purpose register r0.
I had a great idea... https://start.atmel.com/#project
But, they (Microchip) dont support this chips!!
What idea?
Based on kemt research its true that tiny9 has only r15-31 so its logic with r0 in ise mot to work
Simple tweaking in yasmyasmaea possible but if certain limitation exis
I believe rhey should mention in docs
For example "in tiny9" condition with variables is not
Last edit: Christos 2020-06-01
Did you follow the link? That was my idea but I could not find the chip.
But, what are trying to do? this works here.
Var1=1
If var1 then
The above compiles correct but do not work in chip
While compiling for emg tiny85 does work ok on
Last edit: Christos 2020-06-01
What version of the compiler?
Look at the top of the ASM file for the version
Will test afternoon but must latestg downloaded full
@Christos. I am not sure that you reviewed the code I posted. I posted different code to your code.
will gen differerent asm from the code below. I think this is your approach which is working but not as you think
I have try
If var1= true then
As i relpiied to kent to post 5 and this one works in tiny 85 bit not in tiny9 note that it compiles without
OK. Kent is not on the same compiler. He has a much older compiler - probably years old.
I am on the latest. The only versiion that will get fixed.
So, when you are online and able to test - we may want to get you on the latest to ensure you have the latest. See me a Personal Message with your email address and I will send you a download URL to the development code.
98.06 but still springs error.
ATtiny10 ASM:
tiny104 ASM:
Last edit: kent_twt4 2020-06-01
ATTiny104. Do I have configuration control issue? Have I lost that chipfile?
I get same variable in latest build.
Help me understand the issue and how any workaround fixes the issue then I can look at fixing the compiler.
From my notes here. Yep .. I keep a record of almost everything...
The tiny4-5-9-10 and tiny102-104 should be a different family code from the other tiny's. Only 16 GPR's from r16-r31 and only 54 instructions. Can easily overflow the GPR's with system variables and no compiler warning when they go below r16.
ATtiny10 and script constants.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gcbasic/discussion/596084/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
I kept a note if this as it was the identification of an issue that had no resolution.
I have this written under the information above. But, I don't know who wrote this originally.
When I began the ATtiny10 dat sheet development, there still was a tn10def.inc available from Studio. Between that, and using a limited free pdf to text conversion utility by Zamzar, I was also attempting to pick out maxmhz, package info, and pins from the Device Summary pdf. All very rough, not all put together or even finished using Python36.
Going forward it looks like attention will have to be paid by these series designations like attiny series 0 and series 1, mega series 0 and so forth.
So, it looks like we need a new sub chip family and some variable constraints checking in the compiler... and, a good look at the dat file to understand why the compiler was not throwing a message.
Last edit: Anobium 2020-06-01
The issue is these ATtiny4_5_9_10, ATTiny20_40, and ATtiny102_104 devices have only 16 General Purpose Registers, as opposed to all other AVR devices? that have 32. So when the compiler starts assigning system variables to these registers, it thinks it has 32. The dat files should reflect GPR=16 and new family code.
An exception needs to be created or an #ifdef GPR=16? for these devices to limit the range from r16-r31, when aggregating and/or assigning system variables. If there is an overflow, then start placing in RAM?
The ATTiny104 dat file was handcrafted from the data sheet way back from previous post.
OK, you beat me to the post :-)
Your note was apparently my wording. Ooof... can't remember if those ATtiny4_5_9_10, ATtiny20_40 were mine or not. I definetely remember the ATtiny104 though because I have the ATtiny104-XNano.
Well it is not going to get resolved unless I have clarity,
Is the what you are saying. Cus, I have not really understood the questions.
ATtiny4_5_9_10, ATTiny20_40, and ATtiny102_104 devices require a new chip family, or, sub chipfamily. A new AVR class.
This new AVR class of chips will only support 16 registers.
Is the #ifdef GPR=16 a solution? As I do not understand the question.
And, registers available are r16 to r31 then you refer to an overflow. Can you explain? Is the overflow the C register overflow or some other overflow? and, why would this overflow cause the writimg in RAM.
Re the ATTINT104. OK. Keep it here until I get to creating these formally. I have everything under change control and this will mess things up here.
Yep. probably you wording but I I never go to understanding the issue. Maybe I should now. :-)
@kent_twt4
Which is the basline family of which these are sub-class?
And, are they all therefore the same sub-class? If I define a sub-class.
I want to use the existing ChipFamily to reduce the impact. Hence, these questions.
@kent_twt4
As a test, I have adapted the compilter to constrain the registers to r16 to r31. See the attached asm. Do this look correct?
If this is correct then this is a very simple series of code changes to make this work and finally be fixed.
No, the .DEF SYSBITTEST=r5 is still wrong, but much better.
I can't answer that question. But presumably the class is defined by how many, or which assembly instructions are available? Could be a subclass of the other tinys?