On 08/07 08:48, R0b0t1 wrote: > On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark <m...@unserver.de> wrote: > > On Sun, 6 Aug 2017 19:04:09 -0500 > > R0b0t1 <r03...@gmail.com> wrote: > > > >> On Sun, Aug 6, 2017 at 11:50 AM, <tu...@posteo.de> wrote: > >> > When I plug in such a little board into my PC, demesg > >> > reports: > >> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using > >> > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error > >> > -62 [ 1430.203151] usb 7-4: device descriptor read/64, error -62 > >> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using > >> > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error > >> > -62 [ 1430.803174] usb 7-4: device descriptor read/64, error -62 > >> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using > >> > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17, > >> > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number > >> > 18 using ohci-pci [ 1432.000209] usb 7-4: device not accepting > >> > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to > >> > enumerate USB device > >> > >> > > >> > My first thought was: The micronucleus bootloaed is missing or > >> > is defective... > >> > > >> > But plugging in the board into my Android tablet (the tablet runs > >> > Lollipop and is nothing special at all beside being rooted) via > >> > an OTG cable and using lsusb after that, it shows > >> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark > >> > > >> > >> What the dmesg output is saying is that your USB hardware has reported > >> a communication error to the driver. It is my guess that the ATtiny85 > >> is not meeting the timing requirements for USB. > >> > >> Looking at the board there does not seem to be a crystal oscillator > >> which most people would consider necessary for doing USB > >> communication. This is an oversight on DigiStump's part and it is very > >> likely you will not be able to fix the communication issues. You > >> should contact them and tell them that your computer will not > >> recognize their device and that you suspect it is because the clock is > >> too inaccurate. > >> > >> > > >> > What can I do to make this Digispark being correctly recognized? > >> > > >> > Thank you VERY much for any help in advance! > >> > > >> > >> Three things: > >> > >> 1) Return the one you bought and get a new one. The ATtiny85's > >> internal oscillator might be at the end of the bell curve but within > >> manufacturer tolerance, which isn't enough to produce a USB signal > >> close enough to the specified frequency. Expect the seller to pay for > >> return shipping. > >> > >> 2) You can calibrate the oscillator using instructions in this > >> application note: > >> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf. > >> This process still might not get you close enough. > >> > >> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to > >> use the oscillator. You will need to recompile the firmware if the > >> crystal is a different frequency from the internal oscillator. > >> > >> It might work on your phone and not your desktop because of > >> differences in the USB hardware (your phone's serial decoder in the > >> USB hardware performs clock recovery but your PC does not) or because > >> there are multiple things on a USB hub in your PC and the ATtiny85 is > >> less accurate than those already present devices. Admittedly I'm > >> surprised it gets most of the way to registering as a device and then > >> fails, but I don't think the problem is with the drivers or your > >> kernel. > > USB uses a variant of non-return-to-zero for clock synchronisation, > > that should™ take care of timing issues. > > Actually, using microcontrollers without crystal for soft-usb is fairly > > common (i have a bunch myself). As far as i understand (but im no > > expert), trouble usually arises more from the improvised level shifters > > than timing issues. > > Anyway, i neither think there is a driver problem, i had a fair bit of > > the messages myself, usually fixed by fixing the level shifter. > > An NRZ signal is part of the reason USB is so finicky. With USB the > clock has to be within some tolerance of the bus speed (the > justification being that there are multiple devices on the bus that > need to read the bus at all times) and this is fairly inflexible. With > other protocols, like most USART transceivers, the hardware can > recover the sender's frequency and compensate if it is wrong. > > The level shifters might be causing timing problems, seeing as some > hardware does recognize the ATtiny85 and the levels might be right. It > seems less likely that a voltage difference would be OK between two > pieces of hardware to me. > > There's a lot of old advice related to microcontrollers that says you > need to use crystals when you actually don't with modern parts, so I > think it reasonable that your advice will work. I hope Meino gets back > to us. >
I think any modifications on that board is beyond my scope of abilities regarding soldering a clearly seeing what I doing there... these SMD thingies are THAT tiny that I fear to inhale that stuff... than I will be part of the resistance... ;) I ordered a similiar board yesterday, with a more reasonable setup: ATmega32u4 and a attached sdcard slot for the flash memory. The ATmega32u4 has a fully fledged USB 2.0 stack (is it called a "stack"?) and does not bitbang the whole stuff but "talks USB natively". I have gathered some hope so far, that this thingy will a) work with USB < 3.0 b) is more stable and more versatile Cheers Meino
