Compile support for attiny1614

[vslinuxdotnet]

Hello,
Is possible to support the attiny1614 more (ram/flash) ?

I get errors in make because the "USB_INTR_PENDING_BIT":
sbdrv/asmcommon.inc: Assembler messages:
usbdrv/asmcommon.inc:99: Error: constant value required
usbdrv/asmcommon.inc:114: Error: constant value required
usbdrv/asmcommon.inc:46: Error: invalid operands (ABS and .text sections) for <<' usbdrv/asmcommon.inc:62: Error: invalid operands (*ABS* and .text sections) for <<'
usbdrv/usbdrvasm12.inc:379: Error: invalid operands (ABS and .text sections) for `<<'

Is possible to handle USB on this IC? any help?
Thank you

[ArminJo]

Hello,
it is almost impossible, since the CPU has a different architecture and lacks the "Performing Page Erase by SPM" capability.
Some differences from the ATtinies may eventually be able to handle, but this is a showstopper.
Since the CPU has a dedicated boot section maybe you can find an ported optiboot bootloader.

[SpenceKonde]

megaTinyCore includes optiboot for the tinyAVR 0-series and 1-series parts (and has for ages) .

Why is page erase via SPM critical, as opposed to writing 0x01 (page erase) to NVMCTRL.CTRLA or - after filling the page buffer - 0x03 (erase and write page buffer)?

[ArminJo]

it is almost impossible,

@SpenceKonde Impossible for micronucleus to support this CPU, of course not impossible for you 😀

[SpenceKonde]

Ah, yeah, boot.h only supports parts with SPM for writing to program memory. Not hard to work around that - 5 macros, most of which are one-liners (writing to flash, frankly, is easier now than it was)
And only two references to hardware registers outside of the config file, too...
A bit of work to deal with the bootloader being before the code instead of after....

Making it compile is easy-peasy compared to the real challenge in making micronucleus work on the tinyAVR 0/1-series, megaAVR 0-series, and the new Dx series: This whole thing is built on a bunch of timing-critical assembly. And the instruction timing of a few instructions is different!
There are 117 places where the assembly code would need to be modified (approx) across the 9 assembly files, of those 88 are uses of an an instruction which is now faster; these can be fixed (with a sledgehammer) via regex replacement at max cost of 1 instruction word of flash; in many cases timing on those can be maintained with less; the remaining 30 are lds instructions which now take 3 clocks instead of 2 (oh fuck!). Of that 29, 7 are for USB_COUNT_SOF - which looks like is never defined to 1 in the configurations I see there? So those are OK. And 4 of them are immediately preceded by a dummy/timing instruction, and 3 are right next to a push which got 1 cycle faster. One of them is conditional on interupt flags being outside of IO space, but VPORTx.INTFLAGS isn't that (nor does it seem to be the case on most classic AVRs), so it uses IN instead, no problem. and 4 more are always followed by an sbi in the routine they jump to - and that got 1 cycle faster, so those wash out too. Leaves 10 remaining lds's that can't be dealt without some level of pain thought and consideration...

Eh, I'll try to throw together boards for it next time I make PCBs so I could test my code if I have a chance to do this. I often get in the mood where I end up compulsively looking at assembly lately - might as well devote that time to something that is actually useful! I imagine people would like boards like this, considering the way people seem to go crazy for VUSB boards... shrug I can't say I particularly care for VUSB on principle, but people seem to love it, and a board based on it would probably sell well...

[vslinuxdotnet]

@SpenceKonde I also stopped in assembly macros, if you have good news please share.

[vslinuxdotnet]

@SpenceKonde VUSB solved and worked! see this page: https://github.com/12oclocker/V-USB_TinyAvr