Publish on crates.io #1
Comments
|
Wow, nice to hear! As for the release, I'd like to have Additionally, |
|
Hi! I now have a keyboard using this driver! (same address) Any news on publishing? the stm32ral PR should be now OK. Thanks for the driver :-) |
|
Sadly while stm32ral 0.3.0 has been created, I can't publish it to crates.io because it's over the crate file-size limit. I've emailed crates.io to ask if we can increase it, and if not, we'll have to think of something to make the crate size a bit smaller. But I guess that's blocking releasing this. |
|
@adamgreig thanks for the feedback! |
|
stm32ral v0.3.1 is now on crates.io 🎉 |
|
@adamgreig thank you! |
|
Published v0.1.0 🎉 |
|
Thanks! @Disasm now I need stm32f4xx-hal integration, do you want I take care of it using your fork, or do you want to do it? |
|
@TeXitoi I can integrate the driver into stm32f4xx-hal in a day or two. If you have time to help with the clock setup part, please do it. |
|
do you have any pointers on what you have already looked on the clock setup? I'll try to look at it this weekend. |
|
The patch from my fork works, but the upstream repo has changed since then and now this patch can't be ported easily. Specifically, I'm talking about this change: stm32-rs/stm32f4xx-hal@44ec5ab It's difficult (and sometimes impossible) to have precise both sysclk and PLL48 frequencies, so I think that PLL48 frequency should be more "important" when it's requested by user. |
|
OK, I'll try to look at it. |
Replaced endpoint descriptors stack and read/write/configure with delegation to the existing endpoint implementations. Added some weird code to pretend the local endpoint RX buffers are &'static mut memory since the endpoint buffer code should only get executed while the current peripheral bus is allocated. The code is still in a state where a device can identify itself to a Linux host where I've tested a HID device at endpoint stm32-rs#1. So far I have not succeeded with sending over a HID report to the host though.
One reason I couldn't get any communications to transmit on nonzero endpoints was that I forgot to allocate the TX FIFO size/start address for endpoint stm32-rs#1 which the existing implementation does correctly. Also, there was a huge indentation problem in the poll method where the IEP handler and OEP buffer stuff were only getting run when RXFLVL was nonzero. I can now get a device to identify itself on Linux as a HID. I have not successfully pressed a key yet but it has sent HID reports over the line but I am not sure why they aren't being processed.
One reason I couldn't get any communications to transmit on nonzero endpoints was that I forgot to allocate the TX FIFO size/start address for endpoint stm32-rs#1 which the existing implementation does correctly. Also, there was a huge indentation problem in the poll method where the IEP handler and OEP buffer stuff were only getting run when RXFLVL was nonzero. I can now get a device to identify itself on Linux as a HID. I have not successfully pressed a key yet but it has sent HID reports over the line but I am not sure why they aren't being processed. Either way it's looking a lot closer to the original bus implementation at this point and the device has become much more reliable at handling plug/unplug events. One thing I'm not sure about is how the USB interrupt is basically flooding even when I believe every event is being handled and there is no time left over for the idle task.
Fix for incorrect poll rate on isochronous endpoints
Hi!
To let you know, I've ported my keyboard using this crate successfully: https://github.com/TeXitoi/keyberon-f4
Let me know if you need any help to publish this crate.
The text was updated successfully, but these errors were encountered: