On Mon, 7 Aug 2017 12:10:30 -0500 R0b0t1 <r03...@gmail.com> wrote: > 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. Yes, but USB uses a variant ("Non-return-to-zero space") where every n Bits (6 for USB) a Zero (Level change) is inserted to synchronize clocks. At least thats what the Wikipedia says.
> 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. Might just be that the connection is not used most of the time. Maybe i can even fix it if i send some data every few seconds. Damn, never thought about it that way oO > >> 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. > No, didnt meant to. But it usually works under "common" circumstances. Wouldnt recommend it for production use :D
pgpvnoliMx_KO.pgp
Description: OpenPGP digital signature
