DigiKeyboard.h: No such file or directory

Yeah we don't include that library with the core. I'll say the same thing that I said to the last person who asked this same question for some different kind of VUSB libraries. The digistump core jumps through flaming hoops on one leg in the dark just to get any sort of functionality whatsoever - they compromise the functionality of the chip in every way with repercussions ranging from how pins are set (the normal digitalWrite() implementation is a no go) - that problem is that the only way you have even a prayer of native USB working is if interrupts are always enabled, because the VUSB device has to respond to messages within a timeout window that has just a couple of clockcycles left if the interrupt fires the instant the pin goes low, and interrupts aren't disabled and so on. Their implementations of the API functions are all different and are all worse because of these sacrifices. Even then' you're balanced on a knife edge. The only way they make it work reliably for the bootloader is that the bootloader is built around making this work - it has no timekeeping, so it doesn't have interrupts to worry about, and it actually polls the USB lines instead of using interrupts (which eliminates a considerable amount of latency, and gives them full control over it, and since they knew the USB protocol very well, they could make sure that the polling was done. Just GETTING TO THE START OF THE ISR from the time an interrupt is set (while no interrupt is running and interrupts are enabled) is going to take something like 22 clocks, or 24 clocks (to write C code in an interrupt, it needs to make sure the assumptions that gcc relies upon are true - that means at the start of every ISR not written as an ISR_NAKED in assembly, after it's already spent 8 clocks getting here, it then needs to push r1 and r0 to save their current values (you might have interrupted say a multiplication or division operation, such that the values in r1 isn't 0 and r0 contains important data), clear r1 to get a known zero assumed by gcc, in r0 0x3F (load SREG) , push r0 (save it's value - again, we could have interrupted between a comparison, and the point where the comparison

Many versions of the library I have found have not been working since GCC 4.3 and not even the easy parts have been fixed (like adding const in front of all the progmem declarations, because starting in GCC 5 we needed to declare PROGMEM variables const. (Arduino ships with AVR-GCC 7.3 now).

There is actually a REAL PROPER NATIVE USB AVR with the strictly better modern peripherals coming out, I believe as the next product family released, and it'll be in pincounts of14 (7 I/O pins and up to 3 or 4 simultaneous PWMs), 20 (13 I/O pins and up to 8 simultaneous PWM outputs), 28 (19 I/O pins, 8 PWM). 23 I/O pins, 8 PWM). Those numbers include neither the reset pin (which can be set as input) or the UPDI programming pin (which can be set qas gpio, though you need an HV IUPDI programmmer to reprogram

Addditionallsy see my response to the last guy

Yeah, exactly - that's what I was talking about, you want to have a sketch running that uses VUSB to pretend to be some sort of USB device That's what I'm talking about. It cannot work in an Arduino sketch context. The timing constraints are such that you cannot get something that approximates a USB device without throwing basically everything else overboard. You're writing straight C and probably assembly in time critical part. I attempted to make VUSB client devices work from the arduino context years ago, nothing fucking worked, it was a total shitshow, and and I worked off and on for a year or so - and then I finally pinned down someone who knew wtf he was talking about (Yeah, I found someone like that - it was a momentous occasion - people were dancing in the streets, setting off fireworks and popping champagne in celebration - until they heard what he had to say, and then they all put away the fireworks, chugged their champagne to dull the pain of the news, and shuffled sadly home because they wanted to make Arduino VUSB client devices too). Once I learned what the problem was, and through mathematics satisfied myself that on a classic AVR, it's never going to work well and working at all would require painful sacrifices to even kind of work. The timing constraints are just too demanding, AVRs The only way it would ever have a snowballs chance in hell is if you gunned serial, millis, and anything else that used interrupts and wrote it like they wrote micronucleus in terms of polling. And that's the the treasure at the end of the rainbow? Really?

I decided that directing further resources towards attempting anything other than a bootloader with VUSB, in light of the still-dismal best case scenario on a VUSB device, and the impending arrival of the DU-series (you'll be able to get 32-pin ones.... Of those pins, assuming you want both reset and UPDI, which most people do, those'll give you up to 23 gpio pins (and you can run the DU at any voltage between 1.8 and 5.5v while USB runs at 3.3v making interfacing with different voltages easy) and they run up to 24 MHz regardless of voltage, with a temperature range that (waterproofing issues aside) would be in spec if the board was sitting in a pot of boiling water (and that's not even the extended temp range parts - they're rated up to 125C. Same max clocks and all). That's the rated speed too to be clear - if the other Dx-series are a guide, you can probably overclock the bejeezus out of them too.

So yeah I've concluded that the quality of the best case results did not warrant the compromises and development resources to support acting as a VUSB device except for the bootloader. I came to that conclusion before I saw the DU-series product brief and became aware that there was an all new ass-whooping part on the way with native USB and tinyAVR-like pincounts.

DU-series is 14/20/28/32 pins)16/32k on the small pincounts 16/32/64k on the big ones, Dx-like SRAM progression (2k, 4k, 8k). I expect to see the 16k parts launch not far north of a buck, with 64k parts not more than $2 for the cheapest package of a given pincount (just my predictions). That these parts feature a dual USART raises the possibility of a 14-pin DU being used as a dual serial adapter. But even a single serial adapter based around an AVR has some magic, because AVRs can do things normal serial adapters can't, such as running in single wire mode, or sync mode (the S in USART, which nobody in their right mind uses), or 9-bit mode (which is such a nightmare that even the people who are out of their mind have the sense to avoid it). But yeah - with something like that coming (likely the next family of AVRs to be released - though I am not placing any bets on that, not since 16EB headers showed up in an ATpack first - though the EB is tiny-like, and headers for those have always come out further ahead of release than the Dx-like parts), with those specs, and with that kind of expected pricing (just based on what their new products have been launching at), I would have to be out of my mind to waste time (and this would be a BFD to attempt, with success uncertain) jury rig some way to make VUSB kind-of-work on these aging parts, unless I was being paid by the hour.

SpenceKonde / ATTinyCore

DigiKeyboard.h: No such file or directory #797

include "DigiKeyboard.h"`