1 |
On Mon, Aug 7, 2017 at 11:29 AM, Stefan Mark <mark@××××××××.de> wrote: |
2 |
> On Mon, 7 Aug 2017 08:48:50 -0500 |
3 |
> R0b0t1 <r030t1@×××××.com> wrote: |
4 |
> |
5 |
>> On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark <mark@××××××××.de> wrote: |
6 |
>> > On Sun, 6 Aug 2017 19:04:09 -0500 |
7 |
>> > R0b0t1 <r030t1@×××××.com> wrote: |
8 |
>> > |
9 |
>> >> On Sun, Aug 6, 2017 at 11:50 AM, <tuxic@××××××.de> wrote: |
10 |
>> >> > When I plug in such a little board into my PC, demesg |
11 |
>> >> > reports: |
12 |
>> >> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using |
13 |
>> >> > ohci-pci [ 1429.965142] usb 7-4: device descriptor read/64, error |
14 |
>> >> > -62 [ 1430.203151] usb 7-4: device descriptor read/64, error -62 |
15 |
>> >> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using |
16 |
>> >> > ohci-pci [ 1430.569151] usb 7-4: device descriptor read/64, error |
17 |
>> >> > -62 [ 1430.803174] usb 7-4: device descriptor read/64, error -62 |
18 |
>> >> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using |
19 |
>> >> > ohci-pci [ 1431.456157] usb 7-4: device not accepting address 17, |
20 |
>> >> > error -62 [ 1431.582204] usb 7-4: new low-speed USB device number |
21 |
>> >> > 18 using ohci-pci [ 1432.000209] usb 7-4: device not accepting |
22 |
>> >> > address 18, error -62 [ 1432.000244] usb usb7-port4: unable to |
23 |
>> >> > enumerate USB device |
24 |
>> >> |
25 |
>> >> > |
26 |
>> >> > My first thought was: The micronucleus bootloaed is missing or |
27 |
>> >> > is defective... |
28 |
>> >> > |
29 |
>> >> > But plugging in the board into my Android tablet (the tablet runs |
30 |
>> >> > Lollipop and is nothing special at all beside being rooted) via |
31 |
>> >> > an OTG cable and using lsusb after that, it shows |
32 |
>> >> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark |
33 |
>> >> > |
34 |
>> >> |
35 |
>> >> What the dmesg output is saying is that your USB hardware has |
36 |
>> >> reported a communication error to the driver. It is my guess that |
37 |
>> >> the ATtiny85 is not meeting the timing requirements for USB. |
38 |
>> >> |
39 |
>> >> Looking at the board there does not seem to be a crystal oscillator |
40 |
>> >> which most people would consider necessary for doing USB |
41 |
>> >> communication. This is an oversight on DigiStump's part and it is |
42 |
>> >> very likely you will not be able to fix the communication issues. |
43 |
>> >> You should contact them and tell them that your computer will not |
44 |
>> >> recognize their device and that you suspect it is because the |
45 |
>> >> clock is too inaccurate. |
46 |
>> >> |
47 |
>> >> > |
48 |
>> >> > What can I do to make this Digispark being correctly recognized? |
49 |
>> >> > |
50 |
>> >> > Thank you VERY much for any help in advance! |
51 |
>> >> > |
52 |
>> >> |
53 |
>> >> Three things: |
54 |
>> >> |
55 |
>> >> 1) Return the one you bought and get a new one. The ATtiny85's |
56 |
>> >> internal oscillator might be at the end of the bell curve but |
57 |
>> >> within manufacturer tolerance, which isn't enough to produce a USB |
58 |
>> >> signal close enough to the specified frequency. Expect the seller |
59 |
>> >> to pay for return shipping. |
60 |
>> >> |
61 |
>> >> 2) You can calibrate the oscillator using instructions in this |
62 |
>> >> application note: |
63 |
>> >> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf. |
64 |
>> >> This process still might not get you close enough. |
65 |
>> >> |
66 |
>> >> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to |
67 |
>> >> use the oscillator. You will need to recompile the firmware if the |
68 |
>> >> crystal is a different frequency from the internal oscillator. |
69 |
>> >> |
70 |
>> >> It might work on your phone and not your desktop because of |
71 |
>> >> differences in the USB hardware (your phone's serial decoder in the |
72 |
>> >> USB hardware performs clock recovery but your PC does not) or |
73 |
>> >> because there are multiple things on a USB hub in your PC and the |
74 |
>> >> ATtiny85 is less accurate than those already present devices. |
75 |
>> >> Admittedly I'm surprised it gets most of the way to registering as |
76 |
>> >> a device and then fails, but I don't think the problem is with the |
77 |
>> >> drivers or your kernel. |
78 |
>> > USB uses a variant of non-return-to-zero for clock synchronisation, |
79 |
>> > that should™ take care of timing issues. |
80 |
>> > Actually, using microcontrollers without crystal for soft-usb is |
81 |
>> > fairly common (i have a bunch myself). As far as i understand (but |
82 |
>> > im no expert), trouble usually arises more from the improvised |
83 |
>> > level shifters than timing issues. |
84 |
>> > Anyway, i neither think there is a driver problem, i had a fair bit |
85 |
>> > of the messages myself, usually fixed by fixing the level shifter. |
86 |
>> |
87 |
>> An NRZ signal is part of the reason USB is so finicky. With USB the |
88 |
>> clock has to be within some tolerance of the bus speed (the |
89 |
>> justification being that there are multiple devices on the bus that |
90 |
>> need to read the bus at all times) and this is fairly inflexible. With |
91 |
>> other protocols, like most USART transceivers, the hardware can |
92 |
>> recover the sender's frequency and compensate if it is wrong. |
93 |
> As far as i had understand it, the idea of NRZ is to compensate minor |
94 |
> drifts between the two clocks. If not that, what its then for? |
95 |
> Strangely, i had often trouble with uart when i dont used crystal. The |
96 |
> connection always failed after a while. Never had that with vusb. |
97 |
> |
98 |
|
99 |
NRZ just means that every time period of your signal indicates a |
100 |
value. You don't spend any time resting between bits. Because you |
101 |
don't spend any time resting and every time period contains a value, |
102 |
you need to have an accurate clock to read the data from the signal. |
103 |
|
104 |
I can usually get a crystalless UART to work at room temperature in a |
105 |
habitable room. That isn't really enough for me to assume it would |
106 |
work anywhere else. I think you are seeing problems with your serial |
107 |
communication because you are doing more of it and it contains no |
108 |
built in error correction. I expect VUSB retries failed packets, and |
109 |
USB packets are themselves very short. |
110 |
|
111 |
>> The level shifters might be causing timing problems, seeing as some |
112 |
>> hardware does recognize the ATtiny85 and the levels might be right. It |
113 |
>> seems less likely that a voltage difference would be OK between two |
114 |
>> pieces of hardware to me. |
115 |
>> |
116 |
>> There's a lot of old advice related to microcontrollers that says you |
117 |
>> need to use crystals when you actually don't with modern parts, so I |
118 |
>> think it reasonable that your advice will work. I hope Meino gets back |
119 |
>> to us. |
120 |
>> |
121 |
> I have build (or helped building) at least 20 littlewires |
122 |
> (attiny85 based, no crystal). They work :) |
123 |
|
124 |
As above, this isn't really enough to assume that this works in |
125 |
general. Circuits usually work at room temperature. USB, even low |
126 |
speed USB, is a very technically demanding specification to implement |
127 |
because of the timing requirements (the specification being nearly |
128 |
incomprehensible is a separate matter). There's very little reason you |
129 |
can't theoretically make an RC network accurate enough to do USB |
130 |
communication, but typically, cheap microcontrollers are made on |
131 |
cheaper, larger, and less accurate IC processes that have looser |
132 |
tolerances. |
133 |
|
134 |
R0b0t1. |