Re: [Simulavr-devel] Multiple CPU - Architecture discussion

[Knut Schwichtenberg]

Michael Hennebry wrote:
> On Sun, 7 Sep 2008, Knut Schwichtenberg wrote:
>
> Is there a reason simulavrxx could not be used on Windows?
> The phrase god-awful pain in the ass comes to mind,
> but not impossible.
> Does it have to do with shared objects?
Some issues:
- In the way avrdude/avrice have windows specifics we need to have that too
- It has to be defined if the GUI should run on CYGWIN TCL or OpenState TCL -> 
Visual C vs. gcc
- Some body has to do it
> At least one thing will have to be
> done manually for every processor:
> the determination of what, if anything,
> needs to be overridden by hand.
Yes that's were it will end up.
> > 3. Incomplete / unspecific function
> > As described above and as one could see in the development of avr-libc the
> > peripheral components have changed their function but have kept their names. So
> > based on the name one can not distinguish if it is for example the Watchdog of
> > the '128 or a newer one! This have to be added manually! (At the moment there is
> > no complete overview of all CPUs and all peripherals and the specific function
> > available - hope ATMEL knows it...)
>
> It also means that we will need different names for them, e.g.
> Watchdog0 and Watchdog1 or Watchdog128 and Watchdog168.
Yes, also true!
> > As another alternative of input instead of the Partdescription files we could
> > use the avr-libc header files. With the exception of a more compressed
> > information and not need to learn XML it is a derived source of the
> > Partdescription files. The License issue is handled but point 2 and 3 of the
> > list above remain unchanged.
> >
> > While writing some examples based on Atmels AP-Notes I saw that bit assignments
> > in suimulavrxx are hard coded, such as MPCM = Bit 0 in UCSR* of the M128. I
> > think that it might be necessary to check if ATMEL HW-designer have moved some
> > bits around...
> >
> > So here are my questions to the group:
> >
> > - Has anyone checked if functional identical bits kept their locations
> > across all device families Tiny, Mega, XMega,..?
>
> I'm pretty sure they haven't.
> I've read complaints about that elsewhere.
:-( That sounds that we need a kind of register matrix per CPU in program 
readable format...
> > - Are there any ideas of other sources for the CPU configuration? (I'm thinking
> > of a automated process. Manually is always an alternative for volunteers!)
> >
> > - What are benefits / limitations for a "Hardcoded" architecture?
> >
> > - What are benefits / limitations for a configuration file architecture?
> >
> > - Is there an alternative to these both architectures?
>
> I suspect that there will have to be some hardcoding,
> so we will end up with something in between.
> The hard-coding probably can be done on a
> per-family rather than a per-processor basis.
> E.g., from a simulation point of view atmegas
> 48, 88, 168 and 328 are a lot alike.
Here it would be really helpful if Atmel has a family overview.
> > Specially for the configuration file implementation:
> > - XML or Config-File what seems to be best?
> > (For the config-file are of course PD-implementations around so no need to use 
> > M$)
>
> We'll need two kinds of information:
> CPU, name -> number, port name or function name
> and named functions.
> The latter will be in .c files.
> The former is simple enough for a Config-File.
>
> I'd suggest at least two Config-Files:
> one generated by a tool, the other manual.
> The manual file could override the generated one.
>
>
> IIRC there is a way to get gcc to read
> a file and emit all the generated #defines.
> These could be used directly or fed to another tool.
Do you mean the "-E" were all includes are extracted?
> How fancy do we want to get with interpreting a configuration file?
> There are more registers associated with a 168's
> timer than there are with a 128's timer.
> We could use that to infer what functions to call.
> Do we want to?
> I'm not sure how many different kinds of timers AVRs have.
> I suspect that manual entry, especially if it can be
> done on a per-family basis might be less prone to error.
>
>
> If Atmel's XML files have useful information not in the libc header files,
> we should try to find a way to use the former.
> The libc header files are derived from Atmel's XML files.
> There must have been a first use, i.e. a direct use.
> What was the rule that allowed it?
That's the best question for today. Jörg Wunsch always mentions the license 
issue. I reinstalled the AVRStudio to get the license. The license to agree is 
"thin" and to me as a none native speaker it says nothing special - but decide 
on your own...

--------------------------------
Welcome to AVR Studio from Atmel Corporation.

AVR Studio is a Development Tool for the AVR family of microcontrollers. The AVR
Studio is free of charge and may be freely copied and distributed in its
original form.

AVR Studio enables the user to fully control execution of programs on the AVR
In-Circuit Emulator or on the included AVR Instruction Set Simulator. AVR Studio
supports source level execution of Assembly and C/C++ programs assembled with
the Atmel Corporation's included AVR Assembler or tools from 3rd party vendors.

AVR Studio runs under Microsoft Windows 98, Windows NT, Microsoft Windows 2000,
Windows XP, Windows XP 64 and Windows Vista (usb support for 32 bit only).

AVR Studio is continously developing. In order to get latest upgrades of AVR
Studio, please visit our web site

        www.atmel.com

and check out the AVR page.


[Licenses]

The new elf/dwarfparser component uses modified versions of the LGPL licensed
libraries libelf and libdwarf. Patches for the libraries are put in
[Installationdir]\Avr Tools\Parsers\doc together with the GNU Lesser General
Public License



Copyright  ATMEL Corporation. All rights reserved.

AVR and AVR Studio are trademarks of ATMEL Corporation Windows is a trademark of
Microsoft Corporation
-------------------------------------
Maybe Jörg can clarify.