Click to view our Accessibility Statement or contact us with accessibility-related questions
Showing 1 of 1922 conversations about:
fisofo
0
Sep 4, 2013
bookmark_border
Thanks cub.uanic! Where do you want to field questions/troubleshooting? I ask because I loaded yours up, but found that my ergodox slowed to a crawl typing and couldn't keep up. When I hit the bootloader switch directly on the teensy, it took a good 10 to 20 seconds to register I hit the button and allow me to load Ben's back on.
cub.uanic
15
Sep 5, 2013
bookmark_border
fisofoNot sure what is going on in your case.<br /><br />Please try to build from cub_layout branch, using "cd keyboard/ergodox && make -f Makefile.pjrc cub". Do you experience same problems?<br /><br />As last resort, here is binary that I use: https://github.com/cub-uanic/tmk_keyboard/releases/download/e6ad104/ergodox_pjrc.hex
fisofo
0
Sep 5, 2013
bookmark_border
cub.uanicI tried doing the build that way, and using your binary, and they both result in a very slow to respond ErgoDox; just hitting the button on the teensy takes 15 seconds for it to respond. This is very odd!<br /><br />For reference, the firmware that works fine for me (forked from Ben's) is built from here: https://github.com/fisofo/ergodox-firmware
cub.uanic
15
Sep 7, 2013
bookmark_border
fisofoNo, but may be @benblazak can guess something?<br /><br />I can agree that on TMK it works a little bit slower, but far far away to what you said. My guess that this is related to ACTION_TAP* features, because firmware need to distinguish tap and press. This aspect can be tweaked by adjusting TAPPING_TERM in config.h - try to play with it.<br /><br />But if you really disabled ALL extra features and it's still slow, then I'm out of ideas :(
benblazak
27
Sep 7, 2013
bookmark_border
cub.uanicI really don't understand either.. Sorry, haven't even had a chance to really look at the code. My prime suspect for slowness is usually I2C though... Is it still slow if you unplug the left hand? What if you comment out all I2C related code, so that the left hand is being ignored?
cub.uanic
15
Sep 7, 2013
bookmark_border
benblazakBen, all code related to I2C works exactly as in your FW.<br />I took your code almost as is, just changed to it use "I2C (TWI) Master Software Library".<br />And so I think it can't work differently than yours.<br />May be the difference is under the hood of TWI library?
fisofo
0
Sep 7, 2013
bookmark_border
cub.uanicHere's the build options I'm testing: <br />#BOOTMAGIC_ENABLE = yes # Virtual DIP switch configuration(+1000)<br />#MOUSEKEY_ENABLE = yes # Mouse keys(+5000)<br />EXTRAKEY_ENABLE = yes # Audio control and System control(+600)<br />#CONSOLE_ENABLE = yes # Console for debug<br />#COMMAND_ENABLE = yes # Commands for debug and configuration<br />SLEEP_LED_ENABLE = yes # Breathing sleep LED during USB suspend<br />#NKRO_ENABLE = yes # USB Nkey Rollover(+500)<br />#PS2_MOUSE_ENABLE = yes # PS/2 mouse(TrackPoint) support<br />INVERT_NUMLOCK = yes # invert state of NumLock led<br /><br />With only those set, the teensy key only takes 7 seconds to respond (versus 2 with Ben's, or 15 with everything enabled).<br /><br />adjusting TAPPING_TERM to 100 had a noticeable impact on key speed, it didn't feel quite so sluggish, so that's definitely something there. Teensy button still takes 7 seconds.<br /><br />Unplugging the left hand has a huge improvement to key speed, so that seems a likely culprit as well, but the function keys also stopped working at that point, so maybe that's just a result of tapping no longer working? For what it's worth the teensy button still takes 7 seconds with left-hand unplugged (I don't really care about this speed, just including it in case it helps. Key speed is the biggest thing).<br /><br />tl;dr: Maybe I'm just more sensitive to the slowness the tapping introduces. I'm definitely willing to do more testing though; Ben, not sure where to comment out I2C, but point me in the right direction and I can take a shot at it.
cub.uanic
15
Sep 7, 2013
bookmark_border
fisofoTo disable I2C, you can apply this patch:<br /><br />-------------------------------------------------<br />diff --git a/keyboard/ergodox/ergodox.c b/keyboard/ergodox/ergodox.c<br />index 8aed78e..53718f2 100644<br />--- a/keyboard/ergodox/ergodox.c<br />+++ b/keyboard/ergodox/ergodox.c<br />@@ -74,6 +74,8 @@ void init_ergodox(void)<br /> uint8_t init_mcp23018(void) {<br /> uint8_t err = 0x20;<br /> <br />+ return err;<br />+<br /> // I2C subsystem<br /> if (i2c_initialized == 0) {<br /> i2c_init(); // on pins D(1,0)<br />-------------------------------------------------<br />This should have (almost) same effect as not connected left hand half.<br /><br />But before trying this, please try to uncomment NO_ACTION_TAPPING in config.h - does it help?
benblazak
27
Sep 7, 2013
bookmark_border
cub.uanicDo you think it could possibly be an interaction between the TWI library and the tapping code? As in, are multiple scans done for each key (or are multiple scans performed at all) before sending the report when tapping is enabled? A scan of the right hand should take next to no time, but the left hand probably takes something like 1-2 ms.<br /><br />Another thing to consider might be... I read a thread a while ago where they were talking about detecting presses and releases only when a certain number of consecutive scans yielded the same value (as opposed to using a fixed debounce time, like mine does). I got the impression that Hasu's firmware might be using that technique. If so, TWI probably breaks the assumption that individual scans complete quickly (even when the left hand is unplugged?).<br /><br />I feel like I should apologize again... school is really crazy for me this week (more than usual) and so I can't really do more than throw ideas out there for the moment. Wish I could help more!
fisofo
0
Sep 7, 2013
bookmark_border
cub.uanicUncommenting NO_ACTION_TAPPING does improve the lag, but it is still noticeably slower than Ben's.<br /><br />So I saved that text to a file and tried running "patch --strip=3 -i patchfile.patch", but it comes back with: <br />-----------<br />patching file `ergodox.c'<br />patch: **** malformed patch at line 6: uint8_t init_mcp23018(void) { <br />-----------<br /><br />This project is my first working with C, so I'm probably doing something wrong!
cub.uanic
15
Sep 8, 2013
bookmark_border
fisofoI created two branches for you:<br />https://github.com/cub-uanic/tmk_keyboard/tree/no_i2c<br />https://github.com/cub-uanic/tmk_keyboard/tree/disable_all<br /><br />Please try them both and let me know the difference between each of them and Ben's FW.
cub.uanic
15
Sep 8, 2013
bookmark_border
benblazak@benblazak, @fisofo:<br /><br />Just to let you know - seems all problems with TMK for Ergodox were solved, please check my posts on GH: http://geekhack.org/index.php?topic=48106.0
Related Products
Drop Refurbished
Like-new products you can trustDrop Rewards
Get $5 for every 500 points you earn! Learn more
Drop Keyboard Club
Become a member and expand your keycap collectionCollaborate With Us
For Brands & DesignersFollow Drop