On Sunday, December 1, 2019, Aleksandar Markovic < aleksandar.m.m...@gmail.com> wrote:
> Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c >> (similarly with the macros) would be enough Aleksandar? >> >> On Thursday, November 28, 2019, Michael Rolnik <mrol...@gmail.com> wrote: > >> I will rename them. >> > > AVR is the name of a microcontroller lineup, and Atmel is the name of the > company that started producing them. Atmel was recently acquired by > Microchip, so thw word Atmel now does not even exist in new specs. > > Taking this into account, I don't think renaming > > hw/char/avr_usart.c -> hw/char/atmel_usart.c > > is not appropriate. > > I meant to say the renaming is not appropriate. Sorry for confusion. > > > Renaming macros, too. The current names are fine, for now. > > A separate but related naming question will show up later in future, when > we, let's say, want to implement two different version of a peripheral > (let's say USART), one as specified for older microcontrollers, and one for > newer. > > But, OK, let's leave that for future. > > Regards, > Aleksandar > > > >> On Thu, Nov 28, 2019 at 3:41 PM Aleksandar Markovic < >> aleksandar.m.m...@gmail.com> wrote: >> >>> >>> >>> On Thursday, November 28, 2019, Philippe Mathieu-Daudé < >>> phi...@redhat.com> wrote: >>> >>>> On 11/28/19 2:25 PM, Michael Rolnik wrote: >>>> >>>>> 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 < >>>>> aleksandar.m.m...@gmail.com <mailto:aleksandar.m.m...@gmail.com>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> On Thursday, November 28, 2019, Michael Rolnik <mrol...@gmail.com >>>>> <mailto:mrol...@gmail.com>> wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic >>>>> <aleksandar.m.m...@gmail.com >>>>> <mailto:aleksandar.m.m...@gmail.com>> wrote: >>>>> >>>>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik >>>>> <mrol...@gmail.com <mailto:mrol...@gmail.com>> 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. >>>>> >>>> >>>> If I understand Aleksandar correctly, the naming is incorrect because >>>> too generic to AVR family, why Sarah only modeled the Atmel implementation. >>>> >>>> Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c >>>> (similarly with the macros) would be enough Aleksandar? >>>> >>>> >>> >>> Some renaming could help, perhaps not quite like the one above, but my >>> point (which I find hard to believe I can't explain to you) is that >>> peripherals inside the chip evolved over time, as starkly opposed to >>> external peripherals that are set in stone... >>> >> >> >> -- >> Best Regards, >> Michael Rolnik >> >
