I don't see why you say that the peripherals are inside the chip, there
is CPU within target/avr directory and then there are some
peripherals in hw directory, CPU does not depend on them. what am I missing?
On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic
<address@hidden <mailto:address@hidden>> wrote:
On Thursday, November 28, 2019, Michael Rolnik <address@hidden
<mailto:address@hidden>> wrote:
On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
<address@hidden
<mailto:address@hidden>> wrote:
On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
<address@hidden <mailto:address@hidden>> wrote:
>
> This series of patches adds 8bit AVR cores to QEMU.
> All instruction, except BREAK/DES/SPM/SPMX, are
implemented. Not fully tested yet.
> However I was able to execute simple code with functions.
e.g fibonacci calculation.
> This series of patches include a non real, sample board.
> No fuses support yet. PC is set to 0 at reset.
>
I have a couple of general remarks, so I am responding to
the cover
letter, not individual patches.
1) The licenses for Sarah devices differ than the rest -
shouldn't all
licenses be harmonized?
Sarah,
do you mind if use the same license I use for my code?
2) There is an architectural problem with peripherals. It is
possible
that they evolve over time, so, for example, USART could not
be the
same for older and newer CPUs (in principle, newer peripheral is
expected to be o sort of "superset" of the older). How do
you solve
that problem? Right now, it may not looks serious to you,
but if you
don;t think about that right now, from the outset, soon the
code will
become so entangled, ti woudl be almost very difficult to
fix it.
Please think about that, how would you solve it, is there a
way to
pass the information on the currently emulated CPU to the code
covering a peripheral, and provide a different behaviour?
Hi Aleksandar,
Please explain.
My concern is about peripherals inside the chip, together with the core.
If one models, let's say an external (in the sense, it is a separate
chip) ADC (analog-to-digital converter), one looks at specs,
implement what is resonable possible in QEMU, plug it in in one of
machines thst contains it, and that's it. That ADC remains the same,
of course, whatever the surrounding system is.
In AVR case, I think we have a phenomenon likes of which we didn't
see before (at least I don't know about). Number of AVR
microcontrollers is very large, and both cores and peripherals evolved.
For cores, you handle differences with all these AVR_FEATURE macros,
and this seems to be working, no significant objection from my side,
and btw that was not an easy task to execute, all admiration from me.
But what about peripherals inside the chip? A peripheral with the
same name and the same general area of functionality may be
differently specified for microcontrollers from 2010 and 2018. By
the difference I don't mean starting address, but the difference in
behavior. I don't have time right now to spell many examples, but I
read three different specs, and there are differences in USART
specifications.
I am not clear what is your envisioned solution for these cases.
Would you such close, but not the same, flabors of a peripheral
treat as if they are two completely separate cases of a peripheral?
Or would you have a single peripheral that would somehow configure
itself depending on the core it is attached to?
I hope I was clearer this time.
Aleksandar
I don't see any problem from CPU's perspective.
as for the sample board is just a sample, I hope other people
will create real models or real hw.
there was no way I could provide a CPU alone, that's why there
is sample.