tinyAVR and megaAVR 0/1/2-series support

[maltaisn]

I'm interested in adding support for the new AVR chips, 0/1/2-series tinyAVR and megaAVR, that have been released in the past few years. While overall the cores look a lot like classic AVR cores, there are a few major changes that I'm not sure will currently work with simavr. A few highlights:

• Unified memory map: registers, flash, SRAM and EEPROM are all contained within a 64 kB memory map, and they are all accessible with the LD/ST instructions.
• The registers are mapped to the 0x0000-0x10ff range, which means a maximum of 4352 registers vs. the current 280. There are more registers than classic cores, but registers are also a lot more sparse.
• PORT, PIN, DDR, PCMSK become DIR, DIRSET, DIRCLR, DIRTGL, OUT, OUTSET, OUTCLR, OUTTGL, IN, PINnCTRL. I/O pins can be individually inverted and have separate interrupt flags.
• A few instructions have a different latency.
• Most peripherals interacting with I/O pins can be switched to use another set of pins.
• Explicit software reset.
• New peripherals:
  • Event system
  • RTC
  • CCL (4 configurable LUTs)
  • DAC (1&2-series only)

I won't go into the peripherals details because I don't know much about them, but I believe each peripheral have at least a few differences from classic AVR. More info at: https://github.com/SpenceKonde/megaTinyCore, or just the datasheets.

I don't know much about simavr, but it seems to me like there would be a lot of changes involved. There seems to be relatively few tests so I would be afraid to break something. Could this all be supported without major changes? Should it be supported, or would it be preferable if I forked the project? What do you think?

[gatk555]

I have also looked at this and even written some code. There are at least two other differences: the new processors have different interrupt handling, more flexible, and all interrupts are effectively level-triggered; the CPU registers are not mapped in the data-space.

My view is that the peripherals are sufficiently different that it makes sense to create new implementations, rather than trying to rewrite the existing ones. That should also minimise the risk of breakage.

What I have so far: support for optional mapping of CPU registers in data space; simplification of sim_interrupt.[ch] with improved support for level-triggered interrupts; a skeleton of a new-style GPIO port implementation.

The interrupt changes have been used to fix some bugs with level-triggered interrupts on the supported devices, but also remove the interrupt-specific IRQs. They can be put back.

These changes are unpublished as there is not enough there to test, other than for regressions. They are also tangled with my other changes. If you are interested it may be possible to pull them out onto a branch based on upstream. Otherwise, I have no plans to revisit before winter in Europe.

[maltaisn]

Sorry for the late reply. I made a fork simavrxt to work on this eventually. xt because these cores all use the avrxt variant as described in the instruction set manual. Also, it seems that the AVR-Dx parts have a very similar architecture, it might be relevant to include them eventually.

I looked into peripherals and I agree that it would be best to rewrite them. This does feel like a major undertaking though. I'm just beginning to get familiar with simavr so I expect it will take even more time than I think. In any case, I'll probably won't have much time to look into this before at least November.

[gatk555]

The interrupt and register/memory map changes are now in the "main" branch of my fork. No peripheral code so far. All the tests and examples for existing cores seems to work.

[maltaisn]

Thanks for working on it. Personally I gave up register level emulation for my project, I'm doing simulation at a higher level and it works fine. I didn't really have the time to work on simavr, sorry!