[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers
From: |
Aleksandar Markovic |
Subject: |
Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers |
Date: |
Thu, 28 Nov 2019 11:20:44 +0100 |
On Thursday, November 28, 2019, dovgaluk <address@hidden> wrote:
Aleksandar Markovic писал 2019-11-28 12:28:
On Thursday, November 28, 2019, Philippe Mathieu-Daudé
<address@hidden> wrote:
Add famous ATmega MCUs:
- middle range: ATmega168 and ATmega328
- high range: ATmega1280 and ATmega2560
Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
---
Philippe, hi.
Thank you for the impetus you give us all.
However, is this the right direction?
Let's analyse some bits and pieces.
Starting from the commit message, the word "famous" is used, but I
really don't see enumerated CPUs/MCUs are any special in Atmel lineup.
Other than we often used the doc describing them (cited several times
in our discussions) as our reference, but that doesn't make them
"famous". Ofcourse, there other docs for other Atmel CPUs/MCUs, of at
lest equivalent significance. For example, "tiny" ones are at least as
famous as "mega" ones.
Then, you introduce the term MCU, without proper discussion with
others on terminology. In parlance of QEMU, ATmega168 at al. are CPUs
(we all know and assume that that are some peripherals in it). I am
not against using the term MCU, but let's first sync up on that.
The added terminology trouble is that MCUs, as you defined them, have
in array atmega_mcu[] a field called "cpu_type" - why is that field
not called "mcu_type"? *Very* confusing for any future reader. And
then, similar terminology conundrum continues with macro
AVR_CPU_TYPE_NAME().
MCU is a system-on-chip which includes CPU core and peripheral devices.
Separating this is better that including everything into the machine.
E.g., different MCUs may have different IO addresses for USART.
Pavel,
Do you know how is this resolved for other platforms?
How other platfirms organize and use terms "soc", "mcu", "cpu", "core", "cpu core"? And what is the relation between each of them and QEMU command line options "-cpu" and "-machine"? Is thar organization the same accross all platforms?
(I am asking you as you most likely have much wider experience in the topic, sincr mine i limited to mips emulation)
Yours, Aleksandar
All of the above is far less important than this question: What are we
achieving with proposed CPU/MCU definitions? I certainly see the value
of fitting the complex variety of AVR CPUs/MCUs into QEMU object
model. No question about that. However, is this the right moment to do
it? There are still some unresolved architectural problems with
peripheral definitions, as I noted in yhe comment to Michael's last
cover letter. This patch does not solve them. It just assumes
everything is ready with peripherals, let's build CPUs/MCUs. The
machines based on proposed CPUs/MCUs are not more real that machine
based on Michael's "sample" machine. At least Michal says "this is not
a real machine". If we used proposed CPUs/MCUs from this patch, the
resulting machine is as "paper" machine as yhe "sample" machine. We
would just live in a la-la lend of thinking: "wow, we model real
hardware now".
I would rather accept into QEMU a series admitting we are still far
from modelling real machine or CPU/MCU, than a series that gives an
illusion that we are modelling real machine or CPU/MCU.
As far as utility of this patch for Michael's series, it looks to me
they add more headake than help (not saying that the help is not
present) to Michael. He would have anotter abstraction layer to think
of, at the moment he desperately needs (in my opinion) to focus on
providing the as solid as possible, and as complete as possinle
foundations. This patch looks like building castles in the air. Again,
I am not claiming that the patch is not helpful at all.
In summary, I think that this patch is premature.
Pavel Dovgalyuk
- [PATCH 02/10] target/avr: Remove unused include, (continued)
- [PATCH 02/10] target/avr: Remove unused include, Philippe Mathieu-Daudé, 2019/11/27
- [PATCH 03/10] target/avr: Add missing definitions, Philippe Mathieu-Daudé, 2019/11/27
- [NOTFORMERGE PATCH 04/10] target/avr: Fix IRQ count, Philippe Mathieu-Daudé, 2019/11/27
- [RFC PATCH 05/10] hw/char/avr: Reduce USART I/O size, Philippe Mathieu-Daudé, 2019/11/27
- [RFC PATCH 07/10] hw/avr: Add few Arduino boards, Philippe Mathieu-Daudé, 2019/11/27
- [PATCH 08/10] tests/acceptance: Keep multilines comment consistent with other tests, Philippe Mathieu-Daudé, 2019/11/27
- [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers, Philippe Mathieu-Daudé, 2019/11/27
- Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers, Philippe Mathieu-Daudé, 2019/11/28
[RFC PATCH 09/10] tests/acceptance: Use the ATmega2560 board, Philippe Mathieu-Daudé, 2019/11/27
[NOTFORMERGE PATCH 10/10] hw/avr: Remove the 'sample' board, Philippe Mathieu-Daudé, 2019/11/27
Re: [RFC PATCH 00/10] hw/avr: Introduce the Arduino board, Michael Rolnik, 2019/11/28