profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/fivdi/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

fivdi/onoff 1073

GPIO access and interrupt detection with Node.js

fivdi/i2c-bus 266

I2C serial bus access with Node.js

fivdi/epoll 77

A low-level Node.js binding for the Linux epoll API

fivdi/lcd 54

Node.js Hitachi HD44780 LCD driver

fivdi/mcp-spi-adc 54

MCP3002/4/8, MCP3202/4/8 and MCP3304 SPI analog to digital conversion with Node.js

fivdi/gpio-button 19

Hardware momentary push-buttons the Linux way

fivdi/pi-io 14

Raspberry Pi IO Plugin for Johnny-Five

fivdi/linux-io 13

Extensible Linux IO Plugin for Johnny-Five

fivdi/avr-io 10

Control an ATmega328P via I2C

fivdi/bme280 7

Node.js I2C driver for the BME280 humidity, pressure and temperature sensor

startedfivdi/onoff

started time in 3 hours

push eventWeActTC/MiniSTM32H7xx

zhuyix

commit sha 1e2d0f0dc2af3013c21d8134dca88af640e811e2

upgrade openmv firmware to v4.0.1

view details

push time in 4 hours

startedfivdi/pigpio

started time in a day

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

I basically understand what you are asking me, but it seems I need deeper knowledge of how the library works. The example is certainly not showing how to do this. Where can I look for more information ?

The report representation format (which byte for which usage) is detailed in report descriptor. HID parser is very complicated (most complicated descriptor of USB), and TinyUSB basically cannot parse it all. It currently only provide a very simple parser to parse usage_page and usage of each report ID. For more than that, application have to parse it themself, the report descriptor is available with the tuh_hid_mount_cb()

For mouse and keyboard, we can actually use boot interface which guarantee to work on all mouse/keyboard. For boot support, I will do it later on when having time. If you want to understand more about HID, check out the USB HID specs, it is rather short and simple.

For now, I will wrap up my work here with the double buffered. Others are unrelated issue, and should be addressed separately.

dshadoff

comment created time in a day

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

@hathach @dshadoff I created #483 about the connection problem with Logitech USB receiver. Please comment if there are any problems.

dshadoff

comment created time in 2 days

issue openedraspberrypi/pico-sdk

Logitech USB receiver connection failure

Split from #422.

Logitech USB receiver connection failed for the second time. When using a Logitech USB receiver with tinyUSB cdc_msc_hid example. The first connection was okay, but the second connection was PANIC.

Board: Raspberry Pi pico SDK: version 1.2.0 tinyUSB: host-rp2040-double-buffer

The serial log is as follows CFG_TUSB_DEBUG=1 LV1_logitech_pico_log_20210612.txt

CFG_TUSB_DEBUG=3 LV3_logitech_pico_log_20210612.txt

The test scenario followed the steps below. 1.Connect Logitech receiver. 2.Power ON 3.Type 123456790 on the keyboard 4.Press and release the left mouse button. 5.Press and release the right mouse button. 6.Disconnect Logitech receiver 7.Connect Logitech receiver

If you need any other information about this issue, please request it.

created time in 2 days

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

Looking at the reports at the LOG=1 level, I have determined the following:

Simple wired mouse (like RPi standard mouse): byte 0 = buttons (8-bit, bitmask) byte 1 = X (8-bit value, signed) byte 2 = Y (8-bit value, signed) byte 3 = scroll (8-bit value, signed) bytes 4-7 = apparently unused

My example Wired mouse with side buttons: byte 0 = literal value of 01 hexadecimal byte 1 = buttons (8-bit, bitmask) byte 2 / 3 = X (16-bit value, LSB followed by MSB) byte 4 / 5 = Y (16-bit value, LSB followed by MSB) byte 6 = scroll (8-bit value, signed) byte 7 = apparently unused

Logitech mouse: byte 0 = literal value of 02 hexadecimal byte 1 = buttons (8-bit, bitmask) byte 2 = apparently unused (or perhaps unused buttons ?) byte 3 = X (LSB of 12-bit value) byte 4 = Y least-significant nybble + X most-significant nybble (i.e. 0x1F: Y = 1, X is negative) byte 5= Y (MSB of 12-bit value) byte 6 = vertical scroll (8-bit value, signed) byte 7 = horizontal scroll (8-bit value, signed) ** The 12-bit encoding is hard to explain, but if X=-3 and Y = 3, this would show as bytes 3/4/5 = FD 3F 00

But I would like to know: a) how to differentiate between which one to parse b) where to obtain these values as raw data so that I can map them properly c) why the mouse report uses only 8-bit variables for X/Y if reported values from the mouse can be larger... or are there perhaps multiple mouser report structures I should be aware of ?

dshadoff

comment created time in 2 days

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

I have tried the new version and it is now reacting to the Logitech mouse, but there are two items:

  1. In the same way as my earlier report about the wired mouse with side buttons, the X/Y data is offset (although it is different here). Log level 1 of this :
    logitech_pico_log_20210612.txt

mouse report format can be different from mouse, the example only parse using the boot mouse format. Which is common used enough. If it does not match, you should look at its report descriptor (hidrd), test its report sent to PC and parser accordingly. i.e hid_mouse_report_t is not always correctly mapped to all mouse report.

I basically understand what you are asking me, but it seems I need deeper knowledge of how the library works. The example is certainly not showing how to do this. Where can I look for more information ?

  1. as @v9938 mentioned, removing the receiver and reconnecting it, it recognizes the receiver but does not reconnect to the mouse. Log level 1 of this:
    logitech_pico_log_20210612_disconnect_reconnect.txt
dshadoff

comment created time in 2 days

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

try to run with LOG=1, or 0, too much printf can somehow cause some issue. If it still exists, it is entirely new bug, and should be filed as separated issue.

dshadoff

comment created time in 2 days

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

@hathach @dshadoff Thanks for the nice support. I have tried changing the sample to 'CFG_TUH_HID = 4'.

I found that there is still one problem.

  1. HID_Open problem fixed.
  2. 1st-time connection has no problem.
  3. After the second time connection, USBH DEVICE ATTACH and REMOVE are repeated.

The debug log as follows. logitech_pico_log_20210612.txt

The test scenario followed the steps below.

  1. Connect Logitech receiver.
  2. Power ON [LOG L1-]
  3. Type 123456790 on the keyboard [LOG L743-]
  4. Press and release the left mouse button.[LOG L1023-]
  5. Press and release the right mouse button.[LOG L1053-]
  6. Disconnect Logitech receiver [LOG L1083-]
  7. Connect Logitech receiver [LOG L1092-]
dshadoff

comment created time in 2 days

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

@dshadoff @v9938 ah this one is simple, the logitech dongle has 3 HID interfaces, the example only configure to work up to 2. I have increased CFG_TUH_HID = 4 in example. Please try again.

@dshadoff mouse report format can be different from mouse, the example only parse using the boot mouse format. Which is common used enough. If it does not match, you should look at its report descriptor (hidrd), test its report sent to PC and parser accordingly. i.e hid_mouse_report_t is not always correctly mapped to all mouse report.

dshadoff

comment created time in 2 days

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

@hathach thank you for your progress ! I git-cloned the host-rp2040-double-buffer branch of tinyusb and built from that (it includes a few more updates than just PR 891).

A previously non-working wireless mouse ( https://www.adafruit.com/product/1738 ) is now working, however as @v9938 stated, the Logitech one is still not yet working. Logs attached. logitech_pico_log_20210611.txt

P.S. no change to the wired mouse with side-buttons, but I expect this is not yet a focus.

dshadoff

comment created time in 3 days

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

@hathach Some of the problems were solved. But a new problem occurred. HID open fails. I have attached the debug.log

Please let me know if there is any other information needed.

dshadoff

comment created time in 3 days

issue commentraspberrypi/pico-sdk

host_hid mouse data displaced

@dshadoff https://github.com/hathach/tinyusb/pull/891 should fix issue with your logitech receiver, please check it out to see if that works for you. It is still WIP, and need more testing.

dshadoff

comment created time in 3 days

startedfivdi/epoll

started time in 3 days

push eventnodejs/nan

Calvin

commit sha 65b32af46e9d7fab2e4ff657751205b3865f4920

tests: use utf-16 string to fix alignment (#915)

view details

push time in 4 days

PR merged nodejs/nan

Use utf-16 string literal to fix alignment in `strings` test

Currently, the strings test in NAN can sometimes cause a performance DCHECK in v8 to fail. This is because the strings test passes UTF-16 string data as a normal string literal (i.e. const char*), meaning what is eventually interpreted as an unsigned char16_t may not have the correct alignment.

To be clear, the DCHECK in question seems to only be there for efficiency/correctness of calling code and there is code in place right after it to handle misaligned string data anyway. However, that doesn't stop the test from failing (when v8 is built with DCHECKs on) if the assembler decides to misalign what it thinks is const char* data.

I'm upstreaming this change from a patch we made in :electron: Electron recently to fix this since we build with DCHECKs on and started running into this problem when running NAN's test suite. 😊

+1 -1

1 comment

1 changed file

clavin

pr closed time in 4 days

pull request commentnodejs/nan

Use utf-16 string literal to fix alignment in `strings` test

Good catch, nobody has pointed this out in 8 or so years.

clavin

comment created time in 4 days

PR opened nodejs/nan

Use utf-16 string literal to fix alignment in `strings` test

Currently, the strings test in NAN can sometimes cause a performance DCHECK in v8 to fail. This is because the strings test passes UTF-16 string data as a normal string literal (i.e. const char*), meaning what is eventually interpreted as an unsigned char16_t may not have the correct alignment.

To be clear, the DCHECK in question seems to only be there for efficiency/correctness of calling code and there is code in place right after it to handle misaligned string data anyway. However, that doesn't stop the test from failing (when v8 is built with DCHECKs on) if the assembler decides to misalign what it thinks is const char* data.

I'm upstreaming this change from a patch we made in :electron: Electron recently to fix this since we build with DCHECKs on and started running into this problem when running NAN's test suite. 😊

+1 -1

0 comment

1 changed file

pr created time in 4 days

startedkarolpiczak/ESC-50

started time in 4 days

pull request commentnodejs/nan

tests: adapt for v8 8.9

🚀 🚀 🚀

Flarna

comment created time in 4 days

startedjasonrandrews/Corstone-300-hello

started time in 4 days

push eventnodejs/nan

Gerhard Stöbich

commit sha e54794191bc81b77e3816ad6f6f433e74f40c15b

tests: adapt for v8 8.9 (#910) V8 API for ScriptOrigin constructor has changed. Adapt test to compile with v8 8.9. Currently only `ScriptOrigin` instances are consumed by NAN therefore no adaptions in the NAN API are needed to keep build/tests working.

view details

push time in 4 days

PR merged nodejs/nan

tests: adapt for v8 8.9

V8 API for ScriptOrigin constructor has changed. Adapt test to compile with v8 8.9.

Currently only ScriptOrigin instances are consumed by NAN therefore no adaptions in the NAN API are needed to keep build/tests working.

fixes: #909

+5 -0

7 comments

1 changed file

Flarna

pr closed time in 4 days

issue closednodejs/nan

nan is affected by the update to V8 8.9 in Node.js

See https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/2639/nodes=fedora-latest-x64/testReport/junit/(root)/citgm/nan_v2_14_2/

closed time in 4 days

targos

issue commentraspberrypi/pico-sdk

scanvideo.c fails to compile with enhanced compiler checking enabled

This probably belongs at https://github.com/raspberrypi/pico-extras/issues ?

Memotech-Bill

comment created time in 4 days

issue openedraspberrypi/pico-sdk

scanvideo.c fails to compile with enhanced compiler checking enabled

In trying to resolve a problem with one of my programs I added the command

add_compile_options(-Werror -Wall -Wextra -Wnull-dereference)

to my CMakeLists.txt file. This results in a number of warnings for scanvideo.c

/home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c: In function 'scanline_id_after': /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c:418:13: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] if (tmp < video_mode.height - 1) { ^ /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c: In function 'default_scanvideo_scanline_repeat_count_fn': /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c:1045:65: error: unused parameter 'scanline_id' [-Werror=unused-parameter] static uint default_scanvideo_scanline_repeat_count_fn(uint32_t scanline_id) { ^~~~~~~~~~~ /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c: In function 'video_24mhz_composable_adapt_for_mode': /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c:1594:75: error: unused parameter 'program' [-Werror=unused-parameter] bool video_24mhz_composable_adapt_for_mode(const scanvideo_pio_program_t *program, const scanvideo_mode_t *mode, ^~~~~~~ /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c: In function 'video_default_adapt_for_mode': /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c:1650:66: error: unused parameter 'program' [-Werror=unused-parameter] bool video_default_adapt_for_mode(const scanvideo_pio_program_t *program, const scanvideo_mode_t *mode, ^~~~~~~ /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c:1650:99: error: unused parameter 'mode' [-Werror=unused-parameter] bool video_default_adapt_for_mode(const scanvideo_pio_program_t *program, const scanvideo_mode_t *mode, ^~~~ /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c:1651:45: error: unused parameter 'modifiable_instructions' [-Werror=unused-parameter] uint16_t *modifiable_instructions) { ^~~~~~~~~~~~~~~~~~~~~~~ /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c: In function 'scanvideo_default_configure_pio': /home/pi/pico/pico-extras/src/rp2_common/pico_scanvideo_dpi/scanvideo.c:1655:67: error: unused parameter 'offset' [-Werror=unused-parameter] void scanvideo_default_configure_pio(pio_hw_t *pio, uint sm, uint offset, pio_sm_config *config, bool overlay) { ^~~~~~

While I can, for now remove the -Werror option to get the build to complete, the code should ideally be free of warnings, see the discussion in https://www.raspberrypi.org/forums/viewtopic.php?f=33&t=312978

created time in 4 days

pull request commentnodejs/nan

tests: adapt for v8 8.9

I use latest NAN release since a while without issues. But there are for sure areas of NAN I don't use there.

But it would be still nice if this PR could be merged (or a variant of it) to get node/citgm green again and early hints for future issues like moving to v8 9.1 or in node 17.

Flarna

comment created time in 4 days

pull request commentnodejs/nan

tests: adapt for v8 8.9

Thanks, @kkoopa, that makes sense. I'll aim to try it and report back.

Flarna

comment created time in 4 days

pull request commentnodejs/nan

tests: adapt for v8 8.9

I have not tested or looked into it, but if it builds without errors originating from NAN itself, everything should be good.

On June 10, 2021 12:43:14 AM GMT+03:00, "Hélène Martin" ***@***.***> wrote:

Thanks for pushing this forward, @Flarna and @kkoopa! I've landed here following a dependency chain that needs updating. Do you know whether non-test updates will be needed to support V9.0 which ships with Node 16?

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/nodejs/nan/pull/910#issuecomment-858122220

Flarna

comment created time in 4 days