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 [EMAIL PROTECTED] "Pessimist: The glass is half empty. Optimist: The glass is half full. Engineer: The glass is twice as big as it needs to be." _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
