kcuzner / led-watch Goto Github PK

The URL link for the project show a 404 Not Found page. Can you check the URLs in the blog? I take this opportunity to thank you for sharing your projects.

Can you create a boot loader for Debian?
Or how can I?

The wristwatch.py script function 'find_device' starting at line 64 cannot connect to an attached watch. It is looping over all the detected HID devices that match the VID/PID for the watch and then checking for the correct Manufacturer/Product pair. However, this information is not present in the HID objects being generated by the hid.enumerate() function. If you print one of these objects you get this ::

{'path': b'3-2:1.0', 'vendor_id': 5824, 'product_id': 1500, 'serial_number': '', 'release_number': 17, 'manufacturer_string': '', 'product_string': '', 'usage_page': 0, 'usage': 0, 'interface_number': 0}

...so you can see that the Manufacturer/Product entries are null values. This makes sense since the MANUFACTURER='kevincuzner.com', PRODUCT='LED Wristwatch' values that are being searched for don't appear in the STM32 project code. The USB descriptor defined for the watch in the usb_desc.c file is ::
/**

• Device descriptor
  */
  static const USB_DATA_ALIGN uint8_t dev_descriptor[] = {
  18, //bLength
  1, //bDescriptorType
  0x00, 0x02, //bcdUSB
  0x00, //bDeviceClass (defined by interfaces)
  0x00, //bDeviceSubClass
  0x00, //bDeviceProtocl
  USB_CONTROL_ENDPOINT_SIZE, //bMaxPacketSize0
  0xc0, 0x16, //idVendor
  0xdc, 0x05, //idProduct
  0x11, 0x00, //bcdDevice
  1, //iManufacturer
  2, //iProduct
  0, //iSerialNumber,
  1, //bNumConfigurations
  };
  ...so as can be seen here, iManufacturer and iProduct don't point to a string. To get around this issue I am simply disabling the checks for Manufacturer/Product and just returning the first object found matching the correct VID/PID which should already be unique enough as it is. But I'm left curious though as to how this code could have ever worked initially.

The hidapi library crashes attempting to open the object returned by the wristwatch.py script's find_device() function ::

Traceback (most recent call last):
File "/home/perfecta/Downloads/led-watch-master/host/bootloader", line 68, in
main()
File "/home/perfecta/Downloads/led-watch-master/host/bootloader", line 54, in main
with open_bootloader(args.timeout) as dev:
File "/home/perfecta/Downloads/led-watch-master/host/device/wristwatch.py", line 40, in enter
self.open_path(self.path)
File "hid.pyx", line 157, in hid.device.open_path
OSError: open failed

If you check the file name and line number reported for hid.pyx you'll see this function ::

def open_path(self, bytes path):
    """Open connection by path.

    :param path: Path to device
    :type path: bytes
    :raises IOError:
    """
    cdef char* cbuff = path
    if self._c_hid != NULL:
        raise RuntimeError('already open')
    self._c_hid = hid_open_path(cbuff)
    if self._c_hid == NULL:
        raise IOError('open failed')
    self._close = weakref.finalize(self, _closer.wrap(self._c_hid).close)

...and I verified that the 'path' parameter is this object :: {'path': b'3-2:1.0'}. In order to raise the IOError then there must have been a failure of the hid_open_path() function call, but how to troubleshoot this further is unclear as I don't know how to reconstruct the 'cdef char* cbuff = path' line when trying to do these things step by step via running the Python interpreter directly.

Hello- been porting this code and compiling under Segger Embedded Studio for ARM 7.12 (I care about the bootloading, not the watch functionality, as a point of reference). This generates a compile error in debug.c line 55, the line itself is 'movs r1, lr'. The error given is:

invalid instruction, any one of the following would fix this:
instantiated into assembly here
operand must be an immediate in the range [0,255]
instantiated into assembly here
operand must be a register in range [r0, r7]
instantiated into assembly here

Since I noticed that the original source looked to be compiled as a project for Atollic Studio which is now part of ST's CubeMX IDE, I compiled this under Cube as well and happened to get this same error. This code is included as part of the replacement Hard Fault handler, so I looked at the default handler provided by Segger and saw it was virtually identical. So replacing the 'movs' with 'mov' as Segger uses addressed the problem. Note that this doesn't ensure the code is functionally correct, it just removes a compilation error. The complete section is as follows:
movs r0, #4
movs r1, lr,
test r0, r1
I believe the 's' suffix tells the ALU status bits to update after the operation. So if the test command is checking these ALU bits based on the move from the link register, then this will be incorrect, but I don't know how to rewrite this to remove the compilation error and still get the same result of updating the status bits. It could also be that the test command does not rely on the status bits from the previous two instructions, in which case they can both be replaced with 'mov' (Segger has 'movs' then 'mov') but I haven't done a thorough investigation of what is happening to the processor in this sequence.