Adding VIA support to Ducky One2mini

[elfmimi]

I'm testing VIA support in one of my keyboards, Z70 Pro, powered by Nuvoton NUC123. and I thought sharing how-to might be helpful for users of some other keyboards with NUC123, like Ducky One2mini.

I squeezed what's needed into keymaps/via directory of my experimental branch : ducky-one2mini-via

How to build: make ducky/one2mini:via or qmk compile -kb ducky/one2mini -km via

Use Remap-keys.app to see how it works. You'll need to manually specify ducky-one2mini.json every time you make a new connection.

Followings are what I'd like to discuss here.

• Custom EEPROM driver

  Above example is using eeprom_transient.c as its backend. so it's volatile. NUC123 port in ChibiOS-Contrib currently lacks SPI driver. I'm still researching how to implement it, but I feel it will take long time to find out how to do it properly. on the other hand SPI peripheral is relatively simple and it will be easy to implement a board specific custom EEPROM driver which directly interface with SPI peripheral. This is what I will recommend at this point.

• Bi-directional USB endpoints

  There are something I don't fully understand about this. usb_descriptor.h has two modes of endpoint number allocating strategies. one is to choose different number for in-endpoint and out-endpoint. another is to assign a same number for both in and out. this is controlled by a define symbol STM32_USB_USE_OTG1. Current USB LLD of NUC123 is assuming the latter mode in use. hence we have to define STM32_USB_USE_OTG1 for NUC123 target as well. otherwise it will immediately run out of available endpoints. The point is that STM32_USB_USE_OTG1 is an awful name to be used universally. So I want to change something but I don't know how or where.

I'm not planning to create a pull-request for Ducky One2mini myself. I'll leave it to someone do own an actual device.

inviting: @fishman @tzarc

[tzarc]

I can verify any attempts, but I don't have the bandwidth to tackle this as well as all other things going on with QMK I'm afraid.

[fishman]

I’ll take a look at it next week

On Sun, Aug 15, 2021 at 12:11 Nick Brassel @.***> wrote:

I can verify any attempts, but I don't have the bandwidth to tackle this as well as all other things going on with QMK I'm afraid.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qmk/qmk_firmware/issues/14016#issuecomment-898992597, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEFT4BTQOVOUOWXG6EEKLT44467ANCNFSM5CFYA35A .

[elfmimi]

Update. Two things.

I found a SPI flash memory chip hanging around my desk. W25Q128JVSIQ . and started testing with it. so far so good.

I found a SPI flash memory driver for W25X20CL in OpenAnnePro's fork of QMK. eeprom_w25x20cl.c . I think this one will serve as a good reference for us.

What I'm still looking for is the upper layer code to make a byte-wise programmable device on top of block erase memory.

[sigprof]

usb_descriptor.h has two modes of endpoint number allocating strategies. one is to choose different number for in-endpoint and out-endpoint. another is to assign a same number for both in and out. this is controlled by a define symbol STM32_USB_USE_OTG1.

Looks like ChibiOS does not provide any abstraction for this aspect of the USB device controller functionality — the ChibiOS USB API just pretends that all endpoints can be bidirectional, and any device-specific restrictions are implemented inside the usb_lld_init_endpoint() function implemented by the low-level driver in the form of osalDbgAssert() on unsupported configurations. Apparently the assumption is that the code using ChibiOS should know the capabilities of the hardware it runs on, therefore if that code needs to be generic, it would need either externally supplied configuration options, or hardware specific #ifdefs (like that STM32_USB_USE_OTG1).

And, BTW, it seems that even the STM32_USB_USE_OTG1 check is not correct there, because the older non-OTG USB device controllers on STM32 chips apparently also support bidirectional endpoints (with the only restriction that isochronous endpoints cannot be bidirectional). E.g., the STM32F103 reference manual says:

This dedicated memory is sized to 512 bytes and up to 16 mono-directional or 8 bidirectional endpoints can be used

(One endpoint is always used for the mandatory control endpoint 0, so you end up with 7 bidirectional endpoints, although using all of them in the bidirectional mode might not be possible because of the packet buffer memory requirements).

[elfmimi]

So, the bottom line is?

[sigprof]

What I'm still looking for is the upper layer code to make a byte-wise programmable device on top of block erase memory.

Recently some code like that was added to https://github.com/qmk/qmk_firmware/blob/master/tmk_core/common/chibios/eeprom_stm32.c, but it does not have a proper flash access abstraction below it. Maybe it could be possible to make that code truly generic (at least for flash devices where the write unit is not larger than 2 bytes — W25Q128JVSIQ apparently can write even single bytes, but some flash implementations with ECC support only 4 or 8 byte writes, and they would need different code).

ChibiOS has some abstraction layer for flash access, and even some SPI flash drivers (but apparently only for some Macronix and Micron chips, and those drivers seem to have the manufacturer ID validation and use some device-specific commands, so they won't be usable with your Winbond chip). However, implementing the SPI flash driver on the QMK level might be preferred.

[stale[bot]]

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

[stale[bot]]

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.