Consider my previous posts to be using a computer named "A". I've tested it out on 3 computers now, and they all work at least some of the time. In case you're going to ask, yes, I'm changing the timing of the blinking sketch each time so that I can confirm "runs with old sketch" or "runs with new sketch", because obviously it will boot up and run its old program with the USB power even if it's not doing anything with data. This is the shield on the digispark.
Here are the most important specs of the different computers:
- Comp A: 64-bit Windows 7, a 64-bit machine, desktop
- Comp B: 32-bit Windows 7, a 32-bit machine, netbook
- Comp C: 32-bit Windows XP, a 64-bit machine, desktop
To summarize my hypothesis, A had problems with both the connection and software. Like I outlined, there were two hangup points that still occur, and I think this is connection, and then software, but I leave it open for others to disagree with me. The thing never worked with a passive USB extension cord and I was still jiggling it a lot when it was plugged directly into the back.
With
Comp B, the netbook, I put the software on the computer, I ran the Windows driver exe, I opened up my program, changed the programmer and board preferences, hit the "compile & send" button, plugged in my digispark - RGB shield, and then it runs the old sketch. The dialogue in the editor
still said "Plug in device now...". A strange thing is that it gives the Windows 7 popups that it installed the driver and it works. It doesn't give the messages (like Comp A) that it failed, then worked, then failed, etc.
So I restarted, and then after another try or two it seems to have worked.
With
Comp C I followed the same song and dance and similarly, it seems to be working now. Here, I used a powered hub.
Again, I got the software, ran the Windows driver exe, started the editor, fixed the settings, loaded my sketch, changed the timing, hit the "compile & run" button, got the message to plug it in, plugged it in, and I got this:
At this point, with the found hardware wizard, from a QA standpoint we have a fork. First, I try canceling. The editor doesn't really change or see anything. However, I do hear the windows sound for a new hardware being found. In fact, this sound repeats over and over again. I observed the same thing many times with Comp A. For what it's worth, it does run the old sketch.
So canceling doesn't work. Now, we say that we want to specify the location to get the driver from and get Windows to install it. I specify the Windows driver folder. It installs, or at least it thinks it does.
Click Finish, and the editor starts to do stuff at last. But now I hit on something that I think reflects the second problem I had with Comp A. The editor outputs something very nasty, similar to what I posted from my first try with Comp A. It gets long so I'm not posting it right now.
So that didn't work. Now I try it a second time. This time it works. This is the output I get.
Binary sketch size: 984 bytes (of a 6,010 byte maximum)
Running Digispark Uploader...
Plug in device now...
> Please plug in the device ...
> Press CTRL+C to terminate the program.
> Device is found!
connecting: 20% complete
connecting: 23% complete
connecting: 27% complete
connecting: 30% complete
connecting: 34% complete
connecting: 40% complete
> Device looks like ATtiny85!
> Available space for user application: 6010 bytes
> Suggested sleep time between sending pages: 8ms
> Whole page count: 94
> Erase function sleep duration: 752ms
parsing: 40% complete
parsing: 60% complete
> Erasing the memory ...
erasing: 60% complete
[--CLIPPED--]
erasing: 80% complete
> Starting to upload ...
writing: 80% complete
[--CLIPPED--]
writing: 99% complete
writing: 100% complete
>> Micronucleus done. Thank you!
Now it runs the new sketch.
I should summarize I guess. Here are my major hypotheses that are non-intuitive:
- There's some kind of driver recognition that has to happen in Windows when you first plug it in, and this is in addition to running the driver install stuff.
- Even if you get that, the sketch is never sent correctly the first time. Sometimes you can try again and it'll work and sometimes it will after restart.
- There's another cause for hangups unrelated to the above two, and I think it's likely to be hardware. Plugging it in directly to the tower doesn't eliminate this problem. Everyone (including myself) seems to not have this problem with a powered hub, and my netbook also never showed signs of this problem. It's likely an issue with the construction of the ports. With my Comp A it still gets thrown into strange loops of Windows trying to recognize the device even though the driver works occasionally.
