On Mon, Aug 7, 2017 at 11:29 AM, Stefan Mark <m...@unserver.de> wrote: > On Mon, 7 Aug 2017 08:48:50 -0500 > R0b0t1 <r03...@gmail.com> 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. > As far as i had understand it, the idea of NRZ is to compensate minor > drifts between the two clocks. If not that, what its then for? > Strangely, i had often trouble with uart when i dont used crystal. The > connection always failed after a while. Never had that with vusb. >
NRZ just means that every time period of your signal indicates a value. You don't spend any time resting between bits. Because you don't spend any time resting and every time period contains a value, you need to have an accurate clock to read the data from the signal. I can usually get a crystalless UART to work at room temperature in a habitable room. That isn't really enough for me to assume it would work anywhere else. I think you are seeing problems with your serial communication because you are doing more of it and it contains no built in error correction. I expect VUSB retries failed packets, and USB packets are themselves very short. >> 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 have build (or helped building) at least 20 littlewires > (attiny85 based, no crystal). They work :) As above, this isn't really enough to assume that this works in general. Circuits usually work at room temperature. USB, even low speed USB, is a very technically demanding specification to implement because of the timing requirements (the specification being nearly incomprehensible is a separate matter). There's very little reason you can't theoretically make an RC network accurate enough to do USB communication, but typically, cheap microcontrollers are made on cheaper, larger, and less accurate IC processes that have looser tolerances. R0b0t1.
