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

[Michael Hennebry]

On Sun, 7 Sep 2008, Knut Schwichtenberg wrote:

> The main question is: Where do we get the input to create the files (either
> Hardcoding or Configuration Files)? My first idea are the "Partdescription
> Files" from Atmel's AVRStudio. These are XML-files describing twice(!) several
> CPU specific information per file. There are some drawbacks in using these 
> files:
>
> 1. License
> Direct use of these files is only allowed in the context of the AVRStudio. 
> That
> might be funny for Windows-users, but they will not / can not use simulavrxx. 
> So

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?

> a translation / conversion is necessary.
>
> 2. Incomplete Pin assignment
> The Partdescription files do not have an assignment from functions to a 
> Port-pin
> (OC1A -> PORTB Pin5). To solve this problem by software the "pin 
> configuration"
> needs to be available as a table - not part of the ATMEL CPU documentation 
> :-(.
> The pin assignment has to be added manually!

If one really wanted, it could be gotten by reading the text
around the pin-assignment diagrams near the front of Atmel's pdfs.
I wouldn't want to write that code.
Even so, associating a CPU with a pdf would have to be done by hand.

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.

> 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.

> 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.

> - 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.

> 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.

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?


-- 
Michael   address@hidden
"Pessimist: The glass is half empty.
Optimist:   The glass is half full.
Engineer:   The glass is twice as big as it needs to be."