Pls. note that Pin B2 is also the Int0 input pin. V-USB seems to use this interrupt. So if you connect the USB D+ data line to another pin, you have to figure out which interrupt can be used by v-usb. In your case you connect D+ to B3 and therefore you must enable PCINT3 and provide v-usb with the corresponding irpt vector number. But this is clearly described in usbconfig.h -- pls. read the comments!
Here are the relevant entries for usbconfig.h:
Code: Select all
#define USB_CFG_IOPORTNAME B
#define USB_CFG_DMINUS_BIT 4
#define USB_CFG_DPLUS_BIT 3
#define USB_INTR_CFG PCMSK
#define USB_INTR_CFG_SET (1 << PCINT3)
#define USB_INTR_CFG_CLR 0
#define USB_INTR_ENABLE GIMSK
#define USB_INTR_ENABLE_BIT PCIE
#define USB_INTR_PENDING GIFR
#define USB_INTR_PENDING_BIT PCIF
#define USB_INTR_VECTOR PCINT0_vect
Note that you should avoid using interrupts of a higher priority than PCINT0.
Thanks Volker for your response. I am in the midst of changing the pin mapping and see that the existing code uses firmware INT0, which is dedicated to pin7 (PB2) on the tinyx5, which we will need for the SPI clock signal.
I see that we have pin change interrupt 0 (firmware PCINT0; another interrupt unique from INT0), and that there are four clock cycles latency on the pin change interrupt.
The timing is already tight within the usb implementation and I do not understand whether this is pushing it too far. Any advice on this is welcome, preferably with analysis. I've looked at the 16.5MHz assembly code, but still don't understand it. We are going against the comments in usbconfig.h here which states:
"Please note that D+ must also be connected to interrupt pin INT0!"
which means the hardware interrupt0 rather than the PCINT0 I guess, so we are beyond proper behavior here, but this is an opportunity to learn. Volker's comments and example code suggest that we can get this working!
To me the proper method of porting over the EasyLogger code to the SPI implementation should be done carefully. There are several intermediate steps to a methodical implementation. First we've got to disable the ADC and KeyPress code to free up PB5 and PB3. This means generating some fake keypress report, at which point my own code is spitting out quite a bit of junk, so I've got some more work to do just to get through this stage.
I do see that eventually we would have the nicety of a host hooked up to both the parallel port(SPI) and the USB port(v-usb firmware), and this could be an invaluable debugging implementation even for the code we are possibly going to implement here. The next step will be to get away from the keyboard HID, which I only barely appreciate just yet.
Again, if this can work then this is a minimalist implementation that could become a programmer or a stdio channel. Minimal parts/pin count...
So I hope to draw somebody else into this. This is potentially a good project.