(I'll restrict my reply just to the list.) As Knut Schwichtenberg wrote:
> Some issues: > - In the way avrdude/avrice have windows specifics we need to have > that too AVRDUDE has only one thing that is Windows-specific, this is the handling of the low-level IO. This is for both, serial IO (bitbang and RS-232), and direct access to the parallel port through IN/OUT instructions as Windows doesn't ship a driver that allows for a properly abstracted parallel port access. A simulator wouldn't have any need for that kind of stuff. The third transport layer is USB, and it's abstracted by libusb. Anything else in AVRDUDE is OS independent. AVaRICE is a different game: being written as a plain POSIX application straight from the beginning, it uses a number of POSIX-style OS services, namely fork() (without exec(), could probably be replaced by a thread-model abstraction), pipes between the parent and child processes, AF_INET sockets for the GDB connection, and the select() syscall to multiplex the GDB communication with the ICE communication. The serial and USB communication channels can easily be abstracted in the same way as AVRDUDE does, but the entire IO stream multiplexing would need a really good redesign in order to become OS independent. That's why AVaRICE currently can only be used in a Cygwin compilation. > -> Visual C vs. gcc It's not necessarily Visual C. MinGW could be used as well. It's a GCC compilation environment, but offers access to the native Win32 API rather than any kind of emulation (as Cygwin does). I'm not even sure whether AVRDUDE can really be compiled in Visual C or not. > >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. There has always been something like "AVR families" in the past, but they haven't been developed as "family devices" back then so nobody can tell whether these old devices are really the same. So for example, the ATmega64 and ATmega128 /look/ like two members of a family, but they actually aren't up to the deepest level of detail. One obvious difference between both that immediately springs to mind is that the BREAK instruction only works in the ATmega64 but not in the ATmega128 (so the latter cannot support software breakpoints in the JTAG ICE). For newer AVRs, the families are obvious since all family members share the same datasheet. > >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? -E -dM > >The libc header files are derived from Atmel's XML files. Not yet, at least not directly. But it's the ultimate goal. > >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. > The AVR Studio is free of charge and may be freely copied and > distributed in its original form. That's the point. The original Atmel XML files are only allowed for redistribution as part of the original AVR Studio installer. So if you take it to the letter, you aren't even allowed to have these files on a non-Win32 machine unless that machine could execute the Win32 installer... (A plain basic Wine installation crashes when trying to run it.) When asking for this, the response we always got is that it's not OK to store these files verbatim as part of an opensource project, but it is OK to extract whatever information is needed for our purpose, and then store that information as part of an opensource project. The avr-libc idea here is (dating back to Ted Roth's days) to convert the Atmel XML into an avr-libc internal XML form that is then used as the master to generate the header files. This offers us an additional advantage: any information that's /not/ in the Atmel files but which we want to have in our headers (like, for example, old names of IO registers that have been renamed later, or the old avr-libc SIG_XXX style interrupt vector names) can be maintained separately. But we aren't there yet (alas). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
