Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-17 Thread R0b0t1
On Wed, Aug 16, 2017 at 11:32 PM, R0b0t1  wrote:
> Hello again, I believe I have cause to bring this thread back to life.
>
> On Sun, Aug 6, 2017 at 11:50 AM,   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
>>
>
> This is with a NUCLEO-L432KC, an STM32 development board:
>
> [1817074.986238] usb usb3-port14: unable to enumerate USB device
> [1817075.429167] usb 3-14: new low-speed USB device number 50 using xhci_hcd
> [1817075.586133] usb 3-14: device descriptor read/64, error -71
> [1817075.847136] usb 3-14: device descriptor read/64, error -71
> [1817076.110100] usb 3-14: new low-speed USB device number 51 using xhci_hcd
> [1817076.267102] usb 3-14: device descriptor read/64, error -71
> [1817076.527036] usb 3-14: device descriptor read/64, error -71
> [1817076.790003] usb 3-14: new low-speed USB device number 52 using xhci_hcd
> [1817076.790470] usb 3-14: Device not responding to setup address.
> [1817076.994569] usb 3-14: Device not responding to setup address.
> [1817077.201986] usb 3-14: device not accepting address 52, error -71
> [1817077.357969] usb 3-14: new low-speed USB device number 53 using xhci_hcd
> [1817077.358525] usb 3-14: Device not responding to setup address.
> [1817077.562503] usb 3-14: Device not responding to setup address.
> [1817077.769930] usb 3-14: device not accepting address 53, error -71
> [1817077.769959] usb usb3-port14: unable to enumerate USB device
> [1817080.134131] usb 3-5: USB disconnect, device number 29
>
> Admittedly, I cut apart a USB cable and am using socketed pin headers
> to attach it to the development board (I'd like to keep it looking
> nice). However, this same board properly identifies as a USB CDC
> device to Windows.
>
> There may be an issue with the kernel driver, Meino. I'm going to see
> how I should follow up on this. Can you test your ATtiny85 with
> Windows?
>

The fix was switching USB D+ and D-. My USB cable had them backwards
(green is supposed to be D+, but there is a popular StackExchange
answer with it reversed).

[1826600.135854] usb 3-14: New USB device found, idVendor=0483, idProduct=5740
[1826600.135855] usb 3-14: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[1826600.135856] usb 3-14: Product: STM32 Virtual ComPort
[1826600.135857] usb 3-14: Manufacturer: STMicroelectronics
[1826600.135857] usb 3-14: SerialNumber: 001A
[1826600.136272] cdc_acm 3-14:1.0: ttyACM0: USB ACM device

Notice how it registers as a fullspeed device. Device detection relies
on how D+ and D- are used. It seems this isn't applicable to your
device then, but it's something to check.

What is strange is if this is wired improperly it shows up on some
Windows hardware. I need to check again.

R0b0t1.



Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-16 Thread R0b0t1
Hello again, I believe I have cause to bring this thread back to life.

On Sun, Aug 6, 2017 at 11:50 AM,   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
>

This is with a NUCLEO-L432KC, an STM32 development board:

[1817074.986238] usb usb3-port14: unable to enumerate USB device
[1817075.429167] usb 3-14: new low-speed USB device number 50 using xhci_hcd
[1817075.586133] usb 3-14: device descriptor read/64, error -71
[1817075.847136] usb 3-14: device descriptor read/64, error -71
[1817076.110100] usb 3-14: new low-speed USB device number 51 using xhci_hcd
[1817076.267102] usb 3-14: device descriptor read/64, error -71
[1817076.527036] usb 3-14: device descriptor read/64, error -71
[1817076.790003] usb 3-14: new low-speed USB device number 52 using xhci_hcd
[1817076.790470] usb 3-14: Device not responding to setup address.
[1817076.994569] usb 3-14: Device not responding to setup address.
[1817077.201986] usb 3-14: device not accepting address 52, error -71
[1817077.357969] usb 3-14: new low-speed USB device number 53 using xhci_hcd
[1817077.358525] usb 3-14: Device not responding to setup address.
[1817077.562503] usb 3-14: Device not responding to setup address.
[1817077.769930] usb 3-14: device not accepting address 53, error -71
[1817077.769959] usb usb3-port14: unable to enumerate USB device
[1817080.134131] usb 3-5: USB disconnect, device number 29

Admittedly, I cut apart a USB cable and am using socketed pin headers
to attach it to the development board (I'd like to keep it looking
nice). However, this same board properly identifies as a USB CDC
device to Windows.

There may be an issue with the kernel driver, Meino. I'm going to see
how I should follow up on this. Can you test your ATtiny85 with
Windows?

R0b0t1.



Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-08 Thread Stefan Mark
On Mon, 7 Aug 2017 12:10:30 -0500
R0b0t1  wrote:

> On Mon, Aug 7, 2017 at 11:29 AM, Stefan Mark  wrote:
> > On Mon, 7 Aug 2017 08:48:50 -0500
> > R0b0t1  wrote:
> >  
> >> On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark 
> >> wrote:  
> >> > On Sun, 6 Aug 2017 19:04:09 -0500
> >> > R0b0t1  wrote:
> >> >  
> >> >> On Sun, Aug 6, 2017 at 11:50 AM,   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 

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread R0b0t1
On Mon, Aug 7, 2017 at 10:41 AM,   wrote:
> Hi,
>
>
> On 08/06 07:04, R0b0t1 wrote:
>> 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.
>
>   I have no oscilloscope nor a frequency counter.
>   That is above my financial possibilities...
>

I forgot to mention, one (or more) of the timers can be used as a
frequency counter (in multiple ways). My searching turned up a related
application note, you might want to look at the code associated with
http://www.atmel.com/Images/doc2563.pdf (application note AVR054) if
you want to get your ATtiny85s working.



Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread R0b0t1
On Mon, Aug 7, 2017 at 11:29 AM, Stefan Mark  wrote:
> On Mon, 7 Aug 2017 08:48:50 -0500
> R0b0t1  wrote:
>
>> On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark  wrote:
>> > On Sun, 6 Aug 2017 19:04:09 -0500
>> > R0b0t1  wrote:
>> >
>> >> On Sun, Aug 6, 2017 at 11:50 AM,   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 

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread R0b0t1
Hello,

Your posts are kind of hard to reply to, sorry if I miss something.
I'll try to get everything into this message.

On Mon, Aug 7, 2017 at 10:41 AM,   wrote:
> Hi,
>
>
> On 08/06 07:04, R0b0t1 wrote:
>> On Sun, Aug 6, 2017 at 11:50 AM,   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.
>
> The above is the only part of the dmesg log regarding this usb
> "device"...
>
> If I plug it into a usb-port, it "works"... (read: will be recognized
> according to dmesg, but still the udev rules dont get triggered, so
> I still get nothing under /dev/...
>

You should look more closely at the dmesg output, though admittedly
some of this might not be obvious without reading the USB
specification. The computer being unable to read a descriptor or the
device failing to accept an address are things that will prevent the
device from properly registering on the bus. The initial handshake
fails to complete.

>
>> 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.
>
> ...the board is a thumbnail thing:
> http://digistump.com/products/1
>
> No crystal. It is not an original digistum and had cost me less than 1
> EUR...so not such a painful loss...
>
>
>> >
>> > 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.
>
>   Returning the board does cost more than the board and I haven't
>   any hope that this will change anything: I have six of them and none
>   works. "The design can be improved..." to be friendly.
>
>
>> 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.
>
>   I have no oscilloscope nor a frequency counter.
>   That is above my financial possibilities...
>
>> 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.
>
>   There is not enough space on the board.
>

Well, if you can't do any of those and if the board doesn't have level
shifters that might be affecting the signal then you probably won't be
able to use the board. If you send the hardware developer a message
that the board has failed to work with a device you will be doing them
a favor.


On Mon, Aug 7, 2017 at 10:51 AM,   wrote:
> 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 

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread Stefan Mark
On Mon, 7 Aug 2017 08:48:50 -0500
R0b0t1  wrote:

> On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark  wrote:
> > On Sun, 6 Aug 2017 19:04:09 -0500
> > R0b0t1  wrote:
> >  
> >> On Sun, Aug 6, 2017 at 11:50 AM,   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.

> The level shifters might be causing timing 

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread Stefan Mark
On Mon, 7 Aug 2017 17:44:31 +0200
tu...@posteo.de wrote:

> On 08/07 11:29, Stefan Mark wrote:
> > On Sun, 6 Aug 2017 19:04:09 -0500
> > R0b0t1  wrote:
> >   
> > > On Sun, Aug 6, 2017 at 11:50 AM,   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.  
> 
> 
> Level shifters? What level shifters??? ;)
Oh, i see. Then i have to correct me, it seems that your board runs on
3v3 anyway (Which means i did not know those, only ones that look much
alike). A level shifter wont be necessary then.


pgpDHhkuI2fdO.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread Stefan Mark
On Mon, 7 Aug 2017 17:53:35 +0200
tu...@posteo.de wrote:

> On 08/07 11:21, Stefan Mark wrote:
> > On Sun, 6 Aug 2017 18:50:07 +0200
> > tu...@posteo.de wrote:
> >   
> > > Hi,
> > > 
> > > sorry, this will become a little longish...
> > > 
> > > Background: To program an ATMEL ATtiny85 via USB
> > > without a dedicated USB chip there is a bootloader
> > > called "micornucleys", which bitbangs the USB protocoll.
> > > This mechanism is used in Digistupms Digispark ATTtiny
> > > developmnent board (http://digistump.com/products/1).
> > > 
> > > So far so nice?
> > > 
> > > 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
> > > 
> > > or similiar. lsusb does not show anything related at all.
> > >   
> > That usually happens when the improvised USB is not good enough.
> > Try a different port, maybe put a USB Hub between. Check if the
> > resistors and diodes for the level shifting are the right ones
> > (measure the resistors, especially if you are not using 5% types).
> > If that does not work, try a different diode/resistor combination
> > (For example, usbasp uses 5v6 zener and 68/2k2 resistor, littlewire
> > 3v6 zener and 27/1k2 resistor. I have seen others too. I had at
> > least one which never worked with my laptop).  
> 
> The board is THAT tiny (http://digistump.com/products/1) that even
> a single proble will short circuit one half of the board... :)
Yeah, i know them. You need a smaller probe ;)
But i can understand that, i would not like to change parts on those.
Then better try other Ports :)


pgpEaF_puh301.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread tuxic
On 08/07 11:21, Stefan Mark wrote:
> On Sun, 6 Aug 2017 18:50:07 +0200
> tu...@posteo.de wrote:
> 
> > Hi,
> > 
> > sorry, this will become a little longish...
> > 
> > Background: To program an ATMEL ATtiny85 via USB
> > without a dedicated USB chip there is a bootloader
> > called "micornucleys", which bitbangs the USB protocoll.
> > This mechanism is used in Digistupms Digispark ATTtiny
> > developmnent board (http://digistump.com/products/1).
> > 
> > So far so nice?
> > 
> > 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
> > 
> > or similiar. lsusb does not show anything related at all.
> > 
> That usually happens when the improvised USB is not good enough. Try a
> different port, maybe put a USB Hub between. Check if the resistors and
> diodes for the level shifting are the right ones (measure the
> resistors, especially if you are not using 5% types). If that does not
> work, try a different diode/resistor combination (For example, usbasp
> uses 5v6 zener and 68/2k2 resistor, littlewire 3v6 zener and 27/1k2
> resistor. I have seen others too. I had at least one which never
> worked with my laptop).

The board is THAT tiny (http://digistump.com/products/1) that even
a single proble will short circuit one half of the board... :)

> 
> > As recommended on related pages on the internet, I installed
> > dedicated udev rules to show the needed ttyACM device. But 
> > since the kernel itsself fails to accept the device, the best
> > udev rules will not work.
> > 
> > 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
> Some ports are more forgiving than others. These soft-usb-thingies tend
> to be a bit rough, especially the level conversion seems to be a bit
> icky :)
> I have a usbasp which works always and everywhere i tested it just
> perfectly. One of my littlewires is a bit wonky (it sometimes looses
> connection and needs a few tries until it works again). Another one
> works fine, but not on every device.





Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread tuxic
On 08/07 08:48, R0b0t1 wrote:
> On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark  wrote:
> > On Sun, 6 Aug 2017 19:04:09 -0500
> > R0b0t1  wrote:
> >
> >> On Sun, Aug 6, 2017 at 11:50 AM,   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 

Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread tuxic
On 08/07 11:29, Stefan Mark wrote:
> On Sun, 6 Aug 2017 19:04:09 -0500
> R0b0t1  wrote:
> 
> > On Sun, Aug 6, 2017 at 11:50 AM,   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.


Level shifters? What level shifters??? ;)
This board is THAT tiny...even the voltage regulator is bigger
than the MCU (http://digistump.com/products/1).

I am not that confident into my soldering-fu to rearrange 
anything on this board :)








Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread tuxic
Hi,


On 08/06 07:04, R0b0t1 wrote:
> On Sun, Aug 6, 2017 at 11:50 AM,   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.
 
The above is the only part of the dmesg log regarding this usb
"device"...

If I plug it into a usb-port, it "works"... (read: will be recognized
according to dmesg, but still the udev rules dont get triggered, so 
I still get nothing under /dev/...


> 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.

...the board is a thumbnail thing:
http://digistump.com/products/1

No crystal. It is not an original digistum and had cost me less than 1
EUR...so not such a painful loss...


> >
> > 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.

  Returning the board does cost more than the board and I haven't
  any hope that this will change anything: I have six of them and none
  works. "The design can be improved..." to be friendly.


> 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.

  I have no oscilloscope nor a frequency counter. 
  That is above my financial possibilities...

> 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.

  There is not enough space on the board.

> 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. It's also not very likely to be a problem with the USB code
> unless it was reimplemented for DigiStump's product (check against
> these libraries
> http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__alternative_stacks.html).
> 
> R0b0t1.
> 




Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread R0b0t1
On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark  wrote:
> On Sun, 6 Aug 2017 19:04:09 -0500
> R0b0t1  wrote:
>
>> On Sun, Aug 6, 2017 at 11:50 AM,   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.



Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread Stefan Mark
On Sun, 6 Aug 2017 19:04:09 -0500
R0b0t1  wrote:

> On Sun, Aug 6, 2017 at 11:50 AM,   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.


pgpDVV8T7N82C.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-07 Thread Stefan Mark
On Sun, 6 Aug 2017 18:50:07 +0200
tu...@posteo.de wrote:

> Hi,
> 
> sorry, this will become a little longish...
> 
> Background: To program an ATMEL ATtiny85 via USB
> without a dedicated USB chip there is a bootloader
> called "micornucleys", which bitbangs the USB protocoll.
> This mechanism is used in Digistupms Digispark ATTtiny
> developmnent board (http://digistump.com/products/1).
> 
> So far so nice?
> 
> 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
> 
> or similiar. lsusb does not show anything related at all.
> 
That usually happens when the improvised USB is not good enough. Try a
different port, maybe put a USB Hub between. Check if the resistors and
diodes for the level shifting are the right ones (measure the
resistors, especially if you are not using 5% types). If that does not
work, try a different diode/resistor combination (For example, usbasp
uses 5v6 zener and 68/2k2 resistor, littlewire 3v6 zener and 27/1k2
resistor. I have seen others too. I had at least one which never
worked with my laptop).

> As recommended on related pages on the internet, I installed
> dedicated udev rules to show the needed ttyACM device. But 
> since the kernel itsself fails to accept the device, the best
> udev rules will not work.
> 
> 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
Some ports are more forgiving than others. These soft-usb-thingies tend
to be a bit rough, especially the level conversion seems to be a bit
icky :)
I have a usbasp which works always and everywhere i tested it just
perfectly. One of my littlewires is a bit wonky (it sometimes looses
connection and needs a few tries until it works again). Another one
works fine, but not on every device.


pgpN2HgJhMlGY.pgp
Description: OpenPGP digital signature


Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-06 Thread R0b0t1
On Sun, Aug 6, 2017 at 11:50 AM,   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. It's also not very likely to be a problem with the USB code
unless it was reimplemented for DigiStump's product (check against
these libraries
http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__alternative_stacks.html).

R0b0t1.



Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-06 Thread Mick
On Sunday 06 Aug 2017 18:50:07 tu...@posteo.de wrote:
> Hi,
> 
> sorry, this will become a little longish...
> 
> Background: To program an ATMEL ATtiny85 via USB
> without a dedicated USB chip there is a bootloader
> called "micornucleys", which bitbangs the USB protocoll.
> This mechanism is used in Digistupms Digispark ATTtiny
> developmnent board (http://digistump.com/products/1).
> 
> So far so nice?
> 
> 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
> 
> or similiar. lsusb does not show anything related at all.
> 
> As recommended on related pages on the internet, I installed
> dedicated udev rules to show the needed ttyACM device. But
> since the kernel itsself fails to accept the device, the best
> udev rules will not work.
> 
> 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
> 
> dmesg reports for this device to use the modyle xhci_hcd.
> 
> I loaded that module by hand on my Gentoo PC and reinserted
> the Digispark: Nothing...same errors as before.
> 
> What can I do to make this Digispark being correctly recognized?
> 
> Thank you VERY much for any help in advance!
> 
> Cheers
> Meino

Did you compare the Android kernel and loaded modules with your Gentoo kernel?

Did you compare lsusb and lshw for other related modules and drivers?  What 
I'm saying is there may be other modules needed like UART, serial over usb and 
what not.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.


[gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

2017-08-06 Thread tuxic
Hi,

sorry, this will become a little longish...

Background: To program an ATMEL ATtiny85 via USB
without a dedicated USB chip there is a bootloader
called "micornucleys", which bitbangs the USB protocoll.
This mechanism is used in Digistupms Digispark ATTtiny
developmnent board (http://digistump.com/products/1).

So far so nice?

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

or similiar. lsusb does not show anything related at all.

As recommended on related pages on the internet, I installed
dedicated udev rules to show the needed ttyACM device. But 
since the kernel itsself fails to accept the device, the best
udev rules will not work.

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

dmesg reports for this device to use the modyle xhci_hcd.

I loaded that module by hand on my Gentoo PC and reinserted
the Digispark: Nothing...same errors as before.

What can I do to make this Digispark being correctly recognized?

Thank you VERY much for any help in advance!

Cheers
Meino