simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] fab feature deprecated


From: ThomasK
Subject: Re: [Simulavr-devel] fab feature deprecated
Date: Thu, 06 Mar 2014 06:53:21 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5

Hi,

to close (I hope) this discussion: I've analyzed, what's to find in the XML files from AVR studio. (ok, I had files from version 6.0, but I know, that the change in 6.1 isn't so big)

The XML files in AVR studio are debugger centric, e.g. it contains mainly information about memory (address and size) and IO register (there address, size and which bits inside). Starting from version 6.1 there are also a description of available interrupts.

This is one part to describe a controller for simulavr, but the stuff to connect peripherals together and to ports is missed, even a information about version of a dedicated peripheral isn't inside. So this have to be added manually to a configuration file, if we want to get a (whatever "mostly" means, this is also part of evolution) mostly complete simulavr controller.

With that, what's easier? What's less erroneous? What's better to maintain? XML configuration (and on build time!) generate controller or hard-coded c++-source files?

I like the idea to generate the most controller from a configuration (maybe as first shot to integrate a new controller to simulavr) on build time. (that was also the way, Onno implemented this!) But in the moment we haven't good configuration sources - and to add/generate all by hand is PITA. (and maybe a source of many new bugs)

So I'll remove it but set a tag (like for libbfd/libiberty) to mark the point where this is removed. (or the point, where this was in the last time)

cu, Thomas


Am 01.03.2014 20:13, schrieb Markus Hitter:
Am 01.03.2014 19:29, schrieb Michael Hennebry:
Duplicating all the timer data for atmega48s,
'88s, '168s and 328s would be a bad thing.

Uhm. I think we talk here not about the stuff inside the AVR but how
it's connected to virtual devices.


Markus




reply via email to

[Prev in Thread] Current Thread [Next in Thread]