Hello.
Is it possible to change pin for one wire? I try made changes in firmware/main.c

define DATA_PIN 2 to #define DATA_PIN 0 or any other

Firmware compilled, but host cant read temerature from ds18b20. When use pin 2 - all works fine.

Are the examples using libusb 0.1 or -1.0? I can't compile any of the examples I get the following errors:
In file included from blink.c:14: In file included from ../library/littleWire.h:36: ../library/opendevice.h:33:23: error: unknown type name 'usb_dev_handle' int usbGetStringAscii(usb_dev_handle *dev, int index, char *buf, int buflen); ^ ../library/opendevice.h:44:19: error: unknown type name 'usb_dev_handle' int usbOpenDevice(usb_dev_handle **device, int vendorID, char *vendorNamePattern, int productID, cha... ^ In file included from blink.c:14: ../library/littleWire.h:105:9: error: unknown type name 'usb_dev_handle' typedef usb_dev_handle littleWire; ^ 3 errors generated.

Thanks

Hello,

When I select "LittleWire - AVR Programmer and More" in Device Manager and try to Update Driver Software with the Windows driver from this GitHub I get the following error.

"Windows found driver software for your device but encountered an error while attempting to install it. Windows cannot verify the digital signature for the drivers required for this device. A recent hardware or software change might have installed a file that is signed incorrectly or damaged, or that might be malicious software from an unknown source. (Code 52)"

I'm on Windows 7 64bit. I brief look shows that running unsigned drivers seems to be non-trivial. Is there a signed version of the LittleWire Windows drivers or another process to install Windows drivers?

Hi Ihsan,

This is mainly a cosmetic issue. When looking at the USB traffic of littlewire (for my µ-wire experiment, you already noticed it :) ) I noticed that the littlewire library always uses this call to send out commands to the client:

usb_control_msg(lwHandle, 0xC0, command, (d2<<8)|d1, (d4<<8)|d3, rxBuffer, 8, USB_TIMEOUT);

So it always requests 8 bytes from the client. Most functions do not send anything back. However even in that case, empty data packets are transmitted via USB and the host has to reply with another empty data packet that has to be acknowledged. (see http://www.beyondlogic.org/usbnutshell/usb4.shtml). Due to the nature of V-USB this freezes the device for 2-3 ms and the USB communication will bug out when interrupts are disabled. This is why littlewire needs delays in all kind of odd places with disabled irq. This problem can be fixed somewhat by using zero length SETUP/DIR_HOST_TO_DEVICE messages. A delay is still needed though...

Just that.

I'm opening another can of worms here:

At the moment the library is a very thin wrapper around libusb. I was amazed that one can get away with so little code :-). The main problem with the is the lack of detailed, user-friendly feedback when problems occur.

Here two examples (I'm running everything on Linux):

• Running the provided examples, like ./blink provids the unhelpful message 'Little Wire could not be found!'. Runnign the same with 'sudo' works. Looking at the code it looks like the original message was 'permission denied', already much closer to the actual problem.
• There seem to be no error feedback at all from the library. Again, running the 'blink' example, it starts fine, but when I unplug the littleWire 'blink' continues happily with no error message !

When I wrote a daemon, I could not find a way to query the status of the device. I'd like at least to properly bail out with an explaining message, when I detect that my littleWire device is no longer there...

I bricked 3 Little Wires by using the bootloader (long story) and HVSP'd them with the combined 1.1 firmware. They work fine using the example programs from the 1.1 code (e.g. adc).

The problem is when I run the version 1.0 'adc' program against a firmware 1.1 device that has just been plugged in, I consistently get 0's for the analogue value. When I run the 1.1 version, I get the expected data. If I then run the 1.0 version again it works fine.

I suspect that the 1.1 firmware requires some init routines that are not present in the 1.0 library, and that upgrading to the 1.1 firmware could stop existing code from working correctly.

It would be very useful, if the internal pull-ups could be enabled. You would not need an external pullup resistor to connect a button. One (bad) example is the button.c same program. It works fine, but with nothing connected it thinks the button is pressed.

I have the following code (Using the library from the v1.1 beta software)

using System;
using littleWireLib;

namespace LittleWireIO
{
    class MainClass
    {
        public static void Main (string[] args)
        {
            littleWire lw = new littleWire ();
            if (lw.connect () == 0) {
                Console.Out.Write ("[*] Connection failed.\n");
                Environment.Exit(-1);
            } else {
                Console.Out.Write("[*] Connection OK.\n");
            }
            lw.digitalWrite(4, 1);

        }
    }
}

The connection always fail, even when running mono as root. The C blink example application works flawless (but only when run as root).

I am running Ubuntu 12.10 and Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-5ubuntu1)

Any else experiencing this/tried this?

Is there a 1.3 release tag available?

Littlewire does not work on my laptop with USB 3 ports, when I put a simple unpowered USB hub between it it works perfectly. Might be handy to put this as a tip in the documentation. Would require more testing though. I have only one USB 3 host device in my vicinity, so I can not test more at this moment.

As you ported the cdc232 firmware to the attiny85 (which I am truly thankful for!) do you have any specifications available? (speed).

I don't know how much porting was actually done but it might be nice to open a dedicated github for that. I am interested in using it as a low cost alternative to a FTDI-like usb-to-232 chip to do some UARTing (burning sketches, serial communication) with an Arduino.

I built the latest Little Wire and flashed it along with the latest Micronucleus. I then built the examples and they segfault. The device is found so not sure what else to check on my end. I'm on Ubuntu 14.04. I can try flashing the binary directly as well if that makes sense. Not exactly sure what Micronucleus provides here.

$ ./blink
----------------------------------------------------------
> 1 Little Wire device is found with serialNumber: 0
----------------------------------------------------------
Segmentation fault (core dumped)
``

Increasingly I'm wanting to have several littlewire's attached to my computer which can be individually specifically addressed by programs on my computer. This presents a problem, as it should not matter which port each device is connected to. So I have a simple proposal:

Add two capabilities to the USB protocol - writing and reading of the LittleWire device's eeprom. Once this is added, it would also be great if the eeprom was referenced for the device's "Serial Number" string in USB enumeration. In this way a unicode string could be written by the host computer in to the start of eeprom, and then in the future the device would enumerate with this string in it's Serial and could be easily addressed by host software.