Biu~ Here comes another update on the key functionality series, hee hee hee hee~ In the second chapter of this series, a quick method for implementing low-level active keys was briefly mentioned, which I accidentally discovered in the ButtonParseXml.xsd file as an element tag declaration. Literally, it means triggering an event with a low level.
Upon seeing this definition, my first thought was that this definition is simple and convenient, so I quietly noted down this method. However, a dramatic scene unfolded when a customer asked how to make the key low-level active. My first solution that flashed in my mind was to change activePinFriendlyName to negatePinFriendlyName.
Done, Perfect!
“Long press effective, single click ineffective,”
When I heard the customer’s feedback, I actually rejected it because I thought, surely it wouldn’t be that problematic. But since it was my first time, I had to try it out. I can’t just say a feature is there and expect it to work perfectly; otherwise, the customer would be frustrated after trying for a long time, claiming that such a feature doesn’t exist. So I said, let me try it first.
The following content is purely my personal understanding; if there are similarities, it must be that you copied me ╭(╯^╰)╮; if there are differences, it must be your fault (￣_,￣ ); if I am wrong, you still can’t comment in the comment section (since no one comments, your comment will stand out o(╥﹏╥)o).
The event is not as simple as I thought. The negatePinFriendlyName element tag can be recognized and generate corresponding data. However, this data was not processed correctly during use.
If you want to fish, you can refer back to my second blog post to understand the relevant content of the array,
Qualcomm Bluetooth ADK (2) — Key Functionality of Multi-Press: https://www.wpgdadatong.com/cn/blog/detail?BID=B1457
If you want fish, just scroll to the end.
We know that key processing is all done in the input_event_manager.c file, and all keys are recognized and processed in the inputEventsChanged function. Let’s take a look at these processing functions one by one. First, we mentioned in the second article that x_button.buttonxml will generate an array, and we need to understand two variables in this array.
Bits indicate whether this IO is high active or low active; when high active, it is consistent with the mask variable, and low active is 0; the mask indicates which IO the triggered message is related to. This array will be referenced by its pointer during initialization (appInputEventMangerInit).
However, the variable input_event_manager_state.action_table cannot be found called anywhere else through a direct search, which can be confusing o((⊙﹏⊙))o. In fact, this is registered as a PIO processing function with the pointer variable input_event_manager_state.task.
PioMonitorRegisterTask(&input_event_manager_state.task,pio);
When the PIO changes, the iemHandler function will be called to handle it, where the variable Task is the input_event_manager_state.task that was registered at that time. So how is it used? The variable type is Task, not InputEventState_t, so why can it be used directly after a forced type conversion?
Calm down, everyone. Do you still remember that the Task type is a pointer type? It points to a pointer of TaskData type, which is the input_event_manager_state.task that registers the PIO processing function. The input_event_manager_state.task is also the first variable in the InputEventState_t structure. Once the pointer to the first variable is known, the other variables in the structure can naturally be used. After obtaining this structure, subsequent processing will continuously use this structure (named state).
-
state->pio_state saves the current PIO state.
-
calculateInputEvents function maps the physical state of the PIO to a logical state that is convenient for computation, obtaining input_event_bits, which will be saved in state->input_event_bits. By performing an XOR operation between the current state and the previously saved state, we can know which IO state has changed, and we can only process these changed IOs.
-
state->action_table is the configuration table, which is the data generated by buttonxml. By traversing it, we find the corresponding action for the changed IO and process them one by one, which is often assigned to input_action for use.
Up to this point, everything is normal because the low active part has not been used before this. The real usage score is in the various processing actions. Please pay attention to the variable input_action->bits, which is the variable that indicates high or low active. However, the processing in each action does not consider the low active part, which leads to the low active processing not achieving the expected purpose.
In singleClickAction, there is a judgment on whether the key is released.
Without looking at the variable name, from a logical understanding, it means that the previous state was valid, and now it is not a valid state, so execute this. This seems fine, but we overlook that the recorded state state->input_event_bits is not initialized at power-up, and this variable should be consistent with the physical state. In other words, when the IO is pulled high, the corresponding position of this variable should be 1, but at the beginning, it is not initialized, and the corresponding position is 0. When low active, as long as any other IO detects a change, it will also process it together, leading to the erroneous execution of the release action, and the same situation occurs in heldAction and other processing.
Therefore, this part needs to consider the low-level active situation during initialization, and here we initialize the IO initial state based on the configuration table.
Returning to singleClickAction, there are also two other variables single_press_already_detected and held_release_detected, which indicate that a single click down and a long press action have already been detected. This is to filter out some erroneous situations; only when a press action has already been detected can the release action be processed; if there is a long press action, the single click action cannot be processed. Similarly, this part will also be used in double-click. However, the recorded statement for this part uses input_action->bits for OR operation, which causes the low active to not be recorded, ￣□￣｜｜
state->single_click_tracker.long_press |= (input_action->bits);
It needs to be changed to input_action->mask to record correctly, and at the same time, when using it, if it is determined to be a low active key, it needs to be inverted. Similarly, many recording and usage places need to be changed this way.
This is the application of changing the key to low active. In fact, in the official code, low active is used together with high active to trigger messages whenever there is a key change.
That concludes this blog post. If you have any questions, please leave a comment below, or if there is anything you want to know, feel free to leave a message, and I will try to arrange it (o´ω`o)و. Thank you all for browsing, and see you next time.
For reference modifications of commonly used keys, see the attached technical document.
Click Read the original text to download the technical document and unlock over 1000 IoT, automotive, and power solutions, with over 700 technical experts online waiting for you to engage. Click “Looking” to give the author a thumbs up.