I am posting this to get more input. We will need lots of it.
Kent and I are talking offline but WE WILL NEED YOUR HELP!
If you know about AVR MCUs and are willing to help read on
*BACKGROUND
We are adding new AVR MCUs to the software. This means that we need source MCU data and convert to the DAT file.
We have software that does this - this software supports AVR MCUs up to Studio 6. MCUs in later releases like the ATTINY404 are in later releases of Studio and are not compatible with the existing tooling.
Therefore, we need to update the tooling to handle the new MCUs.
SOME PRINCIPLES
We need to maintain a single tool that supports backward compatibility.
We need to use the same source for the tool, and, the new tool must be capable of recreating the 'older' DAT files.
PROGRESS
Some.
I have taken the 2007 source code and I have added the ADF (new data source) dataset handler.
I have then updated the tool (written in FREEBASC .to produce a new exe) with the goal of ree-creating the mega328p.dat - why? If we can produce this using the ADF as the datasource, compare to the original DAT file.... we have... a quality check.
See next post for the orginal and the new date file. The result is good. The new DAT file uses the new ADF I have adapted header to show the data source in the new DAT file. The differences are valid differences. I am happy that the new ADF can re-produce the existing DATs.
I have added a datasource priority to the tool. Meaning, the tool will try the following in this sequence.
1. Use Studio4 - uses a set of routines called V4
2. Use ADF - uses a set of routines called V7
3. Use Studio 6 (I have retained Studio for backwards compatibility) - uses a set of routines called V6
The tool can generate specific DAT files from specific datasource priority - with a command line parameter. So, we can produce an old dat file using the old V6 XML handler.
BUT
So, what happens when I try to produce a ATTINY404? The DAT file looks like a dat file.... but, it pretty empty, all the interrupts are being rejected by the tool and lots of missing information - see attached.
This is in the context that the SAME ADF files can produce a MEGA328P! So, the XML needs a lot more examination.
HELP NEEDED
Do you know the these new parts - like the ATTINY404 range? The interrupt vectors are a mystery to me and will need resolving.
Up for a challenge? Willing to help?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Shown below is the ATTINY404 DAT file generated from the same tooling. Something is not correct... there are no Interrupts - the tool is rejecting every interrupt.
Are the interrupts radically different (vectors, naming etc) on these new MCUs?
Tool did this.
219 files in total were processed - new or updated
38 new MCUs files add to the existing 181 MCUs we support
3 of the 38 new MCUs have the interrupt section and are therefore usable.
35 of the 38 new MCUs are unusable
Of the 219 new or updated
19 files supported by the Studio 4 method
1 file supported by the Studio 6 method
199 files supported by the ADF method
Visual checks of the updated files.... some look ok .. some do not in terms of the register addressess. Registers above location 32 look wrong comparing against old baseline versions...
Example... tiny9. CCP was 60 is now 28. Is it now correct? and, was wrong in the past? Or, does the AVR MCU handles in some way?
There is a huge risk that we make things worse unless we get some expert to advise.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am posting this to get more input. We will need lots of it.
Kent and I are talking offline but WE WILL NEED YOUR HELP!
If you know about AVR MCUs and are willing to help read on
*BACKGROUND
We are adding new AVR MCUs to the software. This means that we need source MCU data and convert to the DAT file.
We have software that does this - this software supports AVR MCUs up to Studio 6. MCUs in later releases like the ATTINY404 are in later releases of Studio and are not compatible with the existing tooling.
Therefore, we need to update the tooling to handle the new MCUs.
SOME PRINCIPLES
We need to maintain a single tool that supports backward compatibility.
We need to use the same source for the tool, and, the new tool must be capable of recreating the 'older' DAT files.
PROGRESS
Some.
I have taken the 2007 source code and I have added the ADF (new data source) dataset handler.
I have then updated the tool (written in FREEBASC .to produce a new exe) with the goal of ree-creating the mega328p.dat - why? If we can produce this using the ADF as the datasource, compare to the original DAT file.... we have... a quality check.
See next post for the orginal and the new date file. The result is good. The new DAT file uses the new ADF I have adapted header to show the data source in the new DAT file. The differences are valid differences. I am happy that the new ADF can re-produce the existing DATs.
I have added a datasource priority to the tool. Meaning, the tool will try the following in this sequence.
1. Use Studio4 - uses a set of routines called V4
2. Use ADF - uses a set of routines called V7
3. Use Studio 6 (I have retained Studio for backwards compatibility) - uses a set of routines called V6
The tool can generate specific DAT files from specific datasource priority - with a command line parameter. So, we can produce an old dat file using the old V6 XML handler.
BUT
So, what happens when I try to produce a ATTINY404? The DAT file looks like a dat file.... but, it pretty empty, all the interrupts are being rejected by the tool and lots of missing information - see attached.
This is in the context that the SAME ADF files can produce a MEGA328P! So, the XML needs a lot more examination.
HELP NEEDED
Do you know the these new parts - like the ATTINY404 range? The interrupt vectors are a mystery to me and will need resolving.
Up for a challenge? Willing to help?
Mega328p - using the new tooling for comparison.
There are two differences and these are updates to correct the register bits.
Means the new tooling can produce valid DAT from the new ADF files.
ATTINY404
An example of the insights you can provide.
Shown below is the ATTINY404 DAT file generated from the same tooling. Something is not correct... there are no Interrupts - the tool is rejecting every interrupt.
Are the interrupts radically different (vectors, naming etc) on these new MCUs?
Last edit: Anobium 2019-04-07
Some stats
I have just run the new tool - this is ONLY AVR
Tool did this.
219 files in total were processed - new or updated
38 new MCUs files add to the existing 181 MCUs we support
3 of the 38 new MCUs have the interrupt section and are therefore usable.
35 of the 38 new MCUs are unusable
Of the 219 new or updated
19 files supported by the Studio 4 method
1 file supported by the Studio 6 method
199 files supported by the ADF method
Visual checks of the updated files.... some look ok .. some do not in terms of the register addressess. Registers above location 32 look wrong comparing against old baseline versions...
Example... tiny9. CCP was 60 is now 28. Is it now correct? and, was wrong in the past? Or, does the AVR MCU handles in some way?
There is a huge risk that we make things worse unless we get some expert to advise.
Taking Evan and I conversation offline so as not to clutter Evans post.
What to help? And, we do need help!
Post here to this thread.