Is strobe pin for keypad held low by default?

[kfmut]

Hi,

I had some time to check keypad plugin but immediatly run into problem with strobe pin held low. By rather old discussion https://github.com/terjeio/grblHAL/issues/202 I had impression that is should be held high by default. I'm experimenting with stm32f411 on blackpill devboard:

$I
[VER:1.1f.20210629:]
[OPT:VNSL2,35,1024,3,0]
[NEWOPT:ENUMS,RT+,TC]
[FIRMWARE:grblHAL]
[NVS STORAGE:*EEPROM]
[DRIVER:STM32F411]
[DRIVER VERSION:210705]
[BOARD:Custom BlackPill STMF411]
[PLUGIN:KEYPAD v1.00]

Custom mapping with strobe pin basicaly defined as:

#if KEYPAD_ENABLE
    #define KEYPAD_PORT     GPIOB
    #define KEYPAD_STROBE_PIN   7
    #define KEYPAD_STROBE_BIT   (1<<KEYPAD_STROBE_PIN)
#endif

Full headers for my setup: my_machine.txt my_machine_map.txt

Maybe I'd set mapping wrong since $pins command doesn't list keypad strobe pin? Or it shoudn't? Spindle PWM pin is also missing by the way.

$pins
[PIN:PB6,Reset]
[PIN:PB4,Feed hold]
[PIN:PB3,Cycle start]
[PIN:PA15,Probe]
[PIN:PB12,X limit min]
[PIN:PB13,Y limit min]
[PIN:PB14,Y limit min 2]
[PIN:PB15,Z limit min]
[PIN:PA1,X step]
[PIN:PA3,Y step]
[PIN:PA5,Z step]
[PIN:PB0,Y step]
[PIN:PA2,X dir]
[PIN:PA4,Y dir]
[PIN:PA6,Z dir]
[PIN:PB1,Y dir]
[PIN:PB10,Steppers enable]
[PIN:PA9,Spindle on]
[PIN:PA10,Spindle direction]
[PIN:PA7,Flood]

Also why possibly grblHAL couldn't read I2C memory chip if unpowered arduino nano is connected on I2C SDA/SCL/GND pins? error:7 - An EEPROM read failed. Auto-restoring affected EEPROM to default values. Pullups are present on SDA/SCL pins(3.3kOhm). If I disconnect nano everything is OK, if nano powered prior to blackpill everything is also OK.

[terjeio]

Maybe I'd set mapping wrong since $pins command doesn't list keypad strobe pin? Or it shoudn't?

No, it is my fault. Change: https://github.com/grblHAL/STM32F4xx/blob/3a539e6d2781c207db0c61b0cd027944cc613e26/Src/driver.c#L114-L116 to

#ifdef KEYPAD_STROBE_PIN
    { .id = Input_KeypadStrobe,   .port = KEYPAD_PORT,        .pin = KEYPAD_STROBE_PIN,    .group = PinGroup_Keypad },
#endif

Hopefully that will bring it back to life. Note that GPIO interrupt handling is a bit special for the STM32 processors so handler code may have to be changed/copied for the keypad strobe pin. I have not coded for and tested every possible combination of ports and pins, only for the current pin maps.

Spindle PWM pin is also missing by the way.

And possiby other non plain GPIO pins as well, the new $pins command is work in progress so be patient. I have a lot of drivers to add this to.

Also why possibly grblHAL couldn't read I2C memory chip if unpowered arduino nano is connected on I2C SDA/SCL/GND pins?

The unpowered nano hangs the bus? The voltage on both pins should be 3.3V or the bus is stuck.

[kfmut]

@terjeio

That didn't worked out rather well :-D Tried it with strobe on PB7 and PB15(used in generic_map.h), if those pins pulled low MCU or grblHAL locks, no reaction on ioSender commands. Added external pullup to those pins, same result. Maybe I should try PB0, I think it was used in some mapping files?

And possiby other non plain GPIO pins as well, the new $pins command is work in progress so be patient. I have a lot of drivers to add this to.

Sorry, didn't know that it is WIP, picked it up somewhere in issues or discussions. But Keypad strobe pin has appeared in $pins after correcting driver.c:

$pins
[PIN:PB6,Reset]
[PIN:PB4,Feed hold]
[PIN:PB3,Cycle start]
[PIN:PA15,Probe]
[PIN:PB15,Keypad strobe] <<<<<
[PIN:PB12,X limit min]
[PIN:PB13,Y limit min]
[PIN:PB14,Y limit min 2]
[PIN:PB7,Z limit min]
[PIN:PA1,X step]
[PIN:PA3,Y step]
[PIN:PA5,Z step]
[PIN:PB0,Y step]
[PIN:PA2,X dir]
[PIN:PA4,Y dir]
[PIN:PA6,Z dir]
[PIN:PB1,Y dir]
[PIN:PB10,Steppers enable]
[PIN:PA9,Spindle on]
[PIN:PA10,Spindle direction]
[PIN:PA7,Flood]

The unpowered nano hangs the bus? The voltage on both pins should be 3.3V or the bus is stuck.

Yep, looks like through clamping diodes on GPIO pins Nano is trying to power up itself, so SDA/SCL pins are brought down to +1.6V. Thank you for the hint!

[terjeio]

Maybe I should try PB0, I think it was used in some mapping files?

You have to check the interrupt handlers in driver.c to find out which pins are supported, seems it that pin 0, pins 9-5 and pins 10-15 are from a quick check.

When the strobe pin is pulled low a I2C read is triggered and the keypad controlles should respond by transmitting a byte containing the keycode. Does it? Or is the bus getting stuck again? Note that I have not added any timeout for the transfer so this may explain the hang.

In the next build I will add support for using UART communication for the keypad plugin as an option, this will be easier to program for but depends on having a free UART port available. I'll be busy for a while so this will not be released until later in the month at the earliest.

[kfmut]

@terjeio

You have to check the interrupt handlers in driver.c to find out which pins are supported, seems it that pin 0, pins 9-5 and pins 10-15 are from a quick check.

I'll try to look into that. Thank you!

When the strobe pin is pulled low a I2C read is triggered and the keypad controlles should respond by transmitting a byte containing the keycode. Does it? Or is the bus getting stuck again? Note that I have not added any timeout for the transfer so this may explain the hang.

Hm-m, that could be it. I've tried to change I2C-adresss on the slave device to 0x50(EEPROM) and it did get data requests from grblHAL, but if it's set to 0x49 none data requests came but my test sketch currently is quite stupid. I think I'll try to search for an I2C-bus sniffer sketch and see what is going on.

In the next build I will add support for using UART communication for the keypad plugin as an option, this will be easier to program for but depends on having a free UART port available. I'll be busy for a while so this will not be released until later in the month at the earliest.

WOW, that is really interesting! Guess it was not very wise of me to buy BlackPill instead some NUCLEO devboard for my tests, it's sooo limiting :-)

[kfmut]

@terjeio

keypad_keyclick_handler is called in interrupts handlers for pins 0, 10, 15( EXTI0_IRQHandler and EXTI15_10_IRQHandler ), tried to map strobe signal to PB15, PB0 and PA0(user key on Blackpill). Pulling down PB15 pin results in hangup, PA0/PB0 didn't result in any response on pulling them down. Never received any i2c-request on slave device, even tried to use arduino pro mini powered from +3V3 Blackpill to evade any problems with level translations.

[terjeio]

I'll check this out when I am "back in business" in a few days time.

[kfmut]

@terjeio

That would be great, thank you!

[terjeio]

PA0/PB0 has a small typo, KEYPAD_ENABLED vs. KEYPAD_ENABLE which is the correct one. My MSP430 based keypad works when this is corrected (I am using the BOARD_MORPHO_CNC map which has PB0 mapped to the strobe signal).

I will soon (later today?) commit an update that allows UART input, call keypad_enqueue_keycode() with the keycode to trigger the action, send 0x85 or 0x18 to cancel it (if it is a jog move).

[kfmut]

@terjeio

PA0/PB0 has a small typo, KEYPAD_ENABLED vs. KEYPAD_ENABLE which is the correct one. My MSP430 based keypad works when this is corrected (I am using the BOARD_MORPHO_CNC map which has PB0 mapped to the strobe signal).

Yep, it's working, bit strange but working, guess it's debounce problem with mapping to user key and me using it :-) Thank you!

I will soon (later today?) commit an update that allows UART input, call keypad_enqueue_keycode() with the keycode to trigger the action, send 0x85 or 0x18 to cancel it (if it is a jog move).

Sorry, I didn't understood later part about calling keypad_enqueue_keycode

[kfmut]

@terjeio

Hi, sorry for disturbing you again.

I've added TI's txs0104e logic levels translator to i2c-bus and to keypad strobe line on my BOB, but I'm still unable to solve problem with keypad strobe pin strange behavior. grblHAL is always requesting keycode from i2c-slave device, on pin pulled low and on pin pulled high.

Is it possible that in this pin state request grblHAL always gets that pin is pulled low?

https://github.com/grblHAL/STM32F4xx/blob/c3332e54e4c2331d6156023e771ec8ae59138919/Src/driver.c#L1994-L1995

So in this code, only I2C_GetKeycode function is always called?

https://github.com/grblHAL/Plugin_I2C_keypad/blob/4d3f3d54f86b340fdda788ce383509faa874f7c9/keypad.c#L337-L349

I've tried to change handler to this

#elif defined(KEYPAD_ENABLE) && KEYPAD_STROBE_BIT & (1<<0)
        keypad_keyclick_handler(DIGITAL_IN(KEYPAD_PORT, KEYPAD_STROBE_BIT));

ISR_CODE void keypad_keyclick_handler (uint8_t keydown)
{
    size_t bufSize = 50;
    char * buf = ( char * )malloc( bufSize );
    memset( buf, 0, bufSize );
    snprintf(buf, bufSize, "keypad_keyclick_handler >%hhu<", 1 );
    //report_message( buf, Message_Plain );
    free( buf );

    keyreleased = !(keydown == 0 );

    if(keydown == 0){
        report_message("keypad i2c request", Message_Plain);
        I2C_GetKeycode(KEYPAD_I2CADDR, i2c_enqueue_keycode);
        }
    else{
        report_message("keypad key release", Message_Plain);
        if(jogging) {
            report_message("keypad stop jogging", Message_Plain);
            jogging = false;
            protocol_enqueue_realtime_command(CMD_JOG_CANCEL);
            keybuf.tail = keybuf.head; // flush keycode buffer
            }
        }
}

And I never have seen those keypad key release messages, only keypad i2c request ones. Guess it's something simple but I don't see it.

[terjeio]

Guess it's something simple but I don't see it.

It is, a refactoring error on my part - sorry about that. The error is in this line: keypad_keyclick_handler(DIGITAL_IN(KEYPAD_PORT, KEYPAD_STROBE_BIT) == 0); it shold be like this: keypad_keyclick_handler(DIGITAL_IN(KEYPAD_PORT, KEYPAD_STROBE_PIN) == 0);

[kfmut]

@terjeio

Thanks! I've tested it with a simple back and forth routine on my router for a few hours and it's working as expected.

Do I understand correctly that for it to work 100% correctly, jog distances for the keypad should be set to some big numbers and soft limits for jogging($40 parameter) should be switched off and hard limits are must? And if the jog distance is set to something like 10mm I would need to press jog key on the keypad a few times to move further than 10mm?

[terjeio]

Do I understand correctly that for it to work 100% correctly, jog distances for the keypad should be set to some big numbers and soft limits for jogging($40 parameter) should be switched off and hard limits are must?

You can switch on $40 and set long distances, actual jog distance will then be limited to be within the machine workspace. But only when maximum travel is set correctly (with $13x) and the machine is homed.

And if the jog distance is set to something like 10mm I would need to press jog key on the keypad a few times to move further than 10mm?

Yes, but even with long jog distances configured jogging will be cut short on key release. The strobe line should be kept low as long as a jog button is pressed unlike the other buttons where the strobe line should be pulsed.

[kfmut]

@terjeio

You can switch on $40 and set long distances, actual jog distance will then be limited to be within the machine workspace. But only when maximum travel is set correctly (with $13x) and the machine is homed.

I think I've tested that configuration and jog moves from keypad device were just ignored by grblHAL, I'll try to recheck that later.

...unlike the other buttons where the strobe line should be pulsed.

Thank you for clarification, didn't know that.