-
Notifications
You must be signed in to change notification settings - Fork 6.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zio: Introduce ft5336 touch sensor driver and integrate into LittlevGL #16119
zio: Introduce ft5336 touch sensor driver and integrate into LittlevGL #16119
Conversation
First of all, very cool that you made this, this is as far from my use case I was envisioning as I could imagine and yet I think it still works quite well here. I'm interested to know your thoughts on where to proceed next with this interface given this unique and fun use case |
|
||
config LVGL_INPUT_POINTER_DEV_NAME | ||
string "Input pointer device name" | ||
default "INPUT" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe a depends on LVGL_INPUT_POINTER
would make sense here, so that this symbol doesn't show up in the menu when LVGL_INPUT_POINTER
is disabled.
u8_t yl; | ||
u8_t reserved[2]; | ||
} touch[MAX_TOUCHES]; | ||
} __packed; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do we know which of the 5 possible touch point events are valid? Is it worth having some sort of .valid
flag to indicate that a particular record is valid, or should we be checking for 0 values to know if touch[x]
contains useful data (one finger used, three fingers, etc.)?
drivers/zio/ft5336/ft5336.c
Outdated
static const struct zio_dev_api ft5336_driver_api = { | ||
.set_attr = NULL, | ||
.get_attr = NULL, | ||
.get_attrs = NULL, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some sort of attribute may be useful to have here as a reference, even if it's something simple like exposing the driver version number. In my opinion, exposing a driver version in a standard manner might even be worth considering as a mandatory part of zio since it has little overall cost, but is a useful datapoint when debugging remote devices in the field, or reporting device information.
Alternatively, perhaps the Operation Mode
of the FT5336 could be exposed as an attribute (Active, Monitor or Hibernate looking at the DS)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where did you find the DS??? I couldn't find it, so I used the MCUXpresso SDK driver as a reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All checks are passing now. Review history of this comment for details about previous failed status. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a nice beginning
#include <zio.h> | ||
|
||
/* channel type(s) */ | ||
#define FT5336_COORD_TYPE (ZIO_CHAN_TYPES + 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these ever manipulated or retrieved separately?
const struct ft5336_config *config = dev->config->config_info; | ||
struct ft5336_data *data = dev->driver_data; | ||
struct ft5336_raw raw; | ||
struct ft5336_datum datum; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're doing some work to reformat things anyways, maybe its worthwhile just directly converting this to a stream of input event structs, if its only ever for littlevgl, then perhaps just directly converting to littlevgl events could be a simplification
e4bdd9c
to
14b8922
Compare
Adds device tree bindings and nodes for the ft5336 capacitive touch sensor to the mimxrt10{50,60,64}_evk boards. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Introduces a new zio driver for the ft5336 capacitive touch sensor. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Adds support for LittlevGL input devices using the new zio interface. This should ultimately be independent of the specific touch controller, however it is currently tied to the ft5336 due to the lack of an abstracted touch sensor data type. We also have not implemented gpio interrupts in the ft5336 driver and therefore rely on manual triggering, making the touch input appear a bit laggy in the gui. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Configures LittlevGL to use the ft5336 capacitive touch sensor input by default on the mimxrt10{50,60,64}_evk boards. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Enables the touch sensor input and adds a keyboard object to the LittlevGL sample application. This is a hack, do not merge! Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Prior to this patch, zio only supported u32_t variants. Add support for wrapping and unwrapping u8_t variants so the ft5336 driver can implement a new u8_t attribute. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Adds a read/write device attribute to the ft5336 zio driver to runtime configure the number of touches to push to the fifo. The ft5336 hardware can support up to five simultaneous touches, but some applications like LittlevGL only use a single touch. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
LittlevGL doesn't suport multitouch inputs, so use the zio attribute setter interface to configure the ft5336 driver to only push single touches to the zio fifo. Signed-off-by: Maureen Helm <maureen.helm@nxp.com>
Rebased to latest topic-sensors branch now that #16266 has been merged. Adds three new commits to implement getting and setting a device attribute. |
@MaureenHelm just a heads up but I have an outstanding PR (#17629) to introduce LVGL V6. |
@@ -37,6 +37,32 @@ void main(void) | |||
count_label = lv_label_create(lv_scr_act(), NULL); | |||
lv_obj_align(count_label, NULL, LV_ALIGN_IN_BOTTOM_MID, 0, 0); | |||
|
|||
/*Create styles for the keyboard*/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In case it is of any use I have a sample floating around that uses GPIO pins to control some switches maybe this could be extended to allow controle through the touch screen.
@MaureenHelm since |
Depends on #14008
cc: @BFrog