I was successful at uploading sketches using ATTinyCore but the usb only lived for a few seconds before it disappears. i.e.:
If I plug the usb to the mac and directly run the command :
% system_profiler SPUSBDataType
USB:
USB 3.0 Bus:
Host Controller Driver: AppleUSBXHCISPTLP
PCI Device ID: 0x9d2f
PCI Revision ID: 0x0021
PCI Vendor ID: 0x8086
Vendor-Specific Device:
Product ID: 0x0753
Vendor ID: 0x16d0
Version: 2.02
Speed: Up to 1.5 Mb/s
Location ID: 0x14100000 / 43
Current Available (mA): 500
Extra Operating Current (mA): 0
USB 3.1 Bus:
Host Controller Driver: AppleUSBXHCIAR
PCI Device ID: 0x15d4
PCI Revision ID: 0x0002
PCI Vendor ID: 0x8086
Bus Number: 0x00
but after a few seconds (under a minute) if i ran the command again it disappears:
If I disconnect and connect again the same behavior occurs.
I was hoping that since I'm using micronucleus as the bootloader I'd get vusb capabilities from the sketches i uploaded?
But is the vusb features unstable when using attiny88 connected to macos 12.2.1. Montrey?
I realy need a way to debug and see the serial output of the attiny88 via the usb because i only have the micro usb cable with me available at the moment, don't have any isp programmer etc.
Have a read of the GitHub documentation and make sure you are using the latest version and it’s uploader
I spotted this , might mean something …
“ The bootloader allows uploading of new firmware via USB. In its usual configuration it is invoked at device reset and will identify to the host computer. If no communication is initiated by the host machine within a given time, the bootloader will time out and enter the user program, if one is present.”
Thanks hammy for the response. I think what it meant by the firmware in that regard is the sketch. CMIIW to burn a new bootloader in this case micronucleus would require an isp?
I read on another thread that one reason for this premature death is due to thee use of an adapter between the usb and type-c at the macos end. I'm trying to get my hand on a direct micro usb to type-c cable and hope for a more stable connection.
Hopefully my local mobile shop has them.
I think it is just as it says , during booting, whilst the bootloader runs the USB is available for a short while ( for uploading ) emulated in software by the bootloader , then the boot-loader switches to try and run any installed sketch by running at its start location - so the USB part Is over , gone forever . If you want USB at that time your sketch needs to emulate it .
You could make your own bootloader or just program it without it ( over write it ) via ICSP or whatever ( not looked at this processor ) .
Or bin it and use something else !
Yes I noticed this behavior also after looking at the micronucleus code while comparing it to the vusb examples. It get's complicated fast considering the amount of assembly work used by the bootloader with the USB_handler function, optimization or timing requisites? if it's the latter i hope it would be forgiving for not doing the timing down to the tick.
I'll try to use the custom_class example code inside the setup section of the sketch for a starteer and hope for the best, will also make the cli to capture the outputs:
odDebugInit();
DBG1(0x00, 0, 0); /* debug output: main starts */
usbInit();
usbDeviceDisconnect(); /* enforce re-enumeration, do this while interrupts are disabled! */
i = 0;
while(--i){ /* fake USB disconnect for > 250 ms */
wdt_reset();
_delay_ms(1);
}
usbDeviceConnect();
LED_PORT_DDR |= _BV(LED_BIT); /* make the LED bit an output */
sei();
DBG1(0x01, 0, 0); /* debug output: main loop starts */
for(;;){ /* main event loop */
DBG1(0x02, 0, 0); /* debug output: main loop iterates */
wdt_reset();
usbPoll();
}
EDIT: On second note, actually micronucleus already handled usbFunctionSetup method to handle vusb initialization; is there any way to override that?