Closed sdmeijer closed 10 years ago
According to the comments in UsbConfig.h connecting the 2.2k resistor to a pin, enables a connect and disconnect-option in the firmware. When connecting this resistor directly to ground this functionality won't be available. Are we going to use it????
This should also mean that when not using usbConnect and usbDisconnect in the code, the defined pin won't be triggered at all. So if we ommit the use of usbDeviceConnect() and usbDeviceDisconnect(), it won't be triggered. Already tried the original ShrimpKey-code without these two functions and the first tests show that the ShrimpKey can work without it.
-----comments from UsbConfig.h--------- /* If you connect the 1.5k pullup resistor from D- to a port pin instead of
Commented out this part and the ShrimpKey still works:
// // Clear interrupts while performing time-critical operations // cli(); // // Force re-enumeration so the host will detect us // usbDeviceDisconnect(); // delayMs(250); // usbDeviceConnect(); // // // Set interrupts again // sei();
Also added pin 5 (issue #1) to the list of pins and this pin also works.
Yeah, I've seen discussion of using this to reset the device to overcome latent bugs, but assuming everything is stable I don't see why we need a disconnect operation. Worst case you can disconnect and reconnect physically by hand, (or possibly just reset) if it's temporarily and inexplicably weird. If there's a systematic issue, we may need to reassign a pin and lose one of the inputs, but assuming the Shift Register game works in the end, that's not really too much of an issue. Might be worth testing if hard reset of the whole Shrimp is enough.
Until now I didn't had any problems. A physical disconnect and connect shouldn't be a problem for people (it's just 'behavior by design)...
Pin7 is now used for USB, the 2.2k resistor is still connected to +5V.
Connect the 2.2k resistor to VCC, so pin7 is free. Prevent accidentally use of USB_CFG_PULLUP_BIT in Usbconfig.h