Skip to content

Commit

Permalink
Merge branch 'main' of https://github.com/luc-github/esp3d-portfolio
Browse files Browse the repository at this point in the history
  • Loading branch information
@luc-github
luc-github committed Nov 20, 2024
2 parents d8e796d + cc96fc5 commit b561343
Show file tree
Hide file tree
Showing 28 changed files with 180 additions and 3,866 deletions.
38 changes: 2 additions & 36 deletions .cache/repo_ESP32SSDP.json
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
{
"timestamp": 1732064453.5331793,
"timestamp": 1732076975.6308625,
"data": {
"name": "ESP32SSDP",
"type": "dependency",
Expand All @@ -20,41 +20,7 @@
"date": "2024-08-24T08:13:51+00:00"
},
"protected": false,
"issues": [
{
"number": 35,
"title": "[BUG]Miss Send notify : NTS: ssdp:byebye when stopping ssdp server",
"body": "when closing should send a notification broadcast with : ` NTS: ssdp:byebye` \r\nIt is not a big issue but better fix it to clear others devices cache more quickly",
"state": "open",
"created_at": "2023-05-16T01:56:16+00:00",
"updated_at": "2023-05-16T01:56:27+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP32SSDP/issues/35",
"is_pr": false,
"labels": [
"bug"
],
"priority": "normal",
"assignee": null
},
{
"number": 9,
"title": "[FEATURE REQUEST] Respont to multiple device types or callback?",
"body": "Currently the API accepts a single device type. UPNP clients normally look for a root device then read device xml. The xml contains the real device type but the search target header is \r\n\"ST: upnp:rootdevice\"\r\n\r\nSo setting the device SSDP.setDeviceType() to say upnp:rootdevice works for discovery to start but fails because the xml device info schema will contain the wrong device type.\r\n\\<deviceType\\>upnp:rootdevice\\</deviceType\\>\r\n\r\nIn my case my actual device type is \"urn:schemas-upnp-org:device:Basic:1\" but I need to respond to \"upnp:rootdevice\" and \"ssdp:all\" also the search term reply header is supposed to be the same as the ST in the search regardless of the actual device type. \r\n\r\nMaybe this is best handled in a callback of some type? The ability to respond to multiple device types is a good feature but in most cases just one is enough provided the above rootdevice and ssdp:all are also returning a valid reply.\r\n\r\n",
"state": "open",
"created_at": "2020-02-05T03:26:28+00:00",
"updated_at": "2020-02-21T09:59:12+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP32SSDP/issues/9",
"is_pr": false,
"labels": [
"Feature request",
"Planned"
],
"priority": "normal",
"assignee": null
}
]
"issues": []
}
],
"contributors": [
Expand Down
37 changes: 2 additions & 35 deletions .cache/repo_ESP3D-Configurator.json
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
{
"timestamp": 1732064436.6253138,
"timestamp": 1732076964.2478964,
"data": {
"name": "ESP3D-Configurator",
"type": "main",
Expand All @@ -20,40 +20,7 @@
"date": "2024-11-02T15:07:21+00:00"
},
"protected": false,
"issues": [
{
"number": 16,
"title": "[FEATURE REQUEST]Web Flasher Tool",
"body": "May be use : https://esphome.github.io/esp-web-tools/",
"state": "open",
"created_at": "2023-05-18T01:28:29+00:00",
"updated_at": "2023-05-18T01:28:29+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-Configurator/issues/16",
"is_pr": false,
"labels": [],
"priority": "normal",
"assignee": null
},
{
"number": 5,
"title": "[Information]Devt status",
"body": "The configurator is now in beta state \ud83c\udf86 \r\nThe current version is compatible with ESP3D 3.0 only\r\n\r\nIt still need to get improved text content (suggestions/contributions are more than welcome) and add translations support once text is ready.\r\n \r\nThe offline behavior seems not consistent across browsers - so only online version is currently usable=> under investigation\r\n\r\nEdit: offline mode is now fixed and prebuild is available in `build` directory",
"state": "open",
"created_at": "2022-06-18T06:49:19+00:00",
"updated_at": "2022-08-18T01:28:03+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-Configurator/issues/5",
"is_pr": false,
"labels": [
"documentation",
"help wanted",
"Work in progress"
],
"priority": "normal",
"assignee": null
}
]
"issues": []
}
],
"contributors": [
Expand Down
159 changes: 2 additions & 157 deletions .cache/repo_ESP3D-TFT.json
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
{
"timestamp": 1732064389.1521347,
"timestamp": 1732076950.0976105,
"data": {
"name": "ESP3D-TFT",
"type": "main",
Expand All @@ -20,162 +20,7 @@
"date": "2024-08-14T04:19:07+00:00"
},
"protected": false,
"issues": [
{
"number": 77,
"title": "Very slow communication with connected device to usb host",
"body": "I am using ESP32-S3 DEV KIT N8R8 with esp3d-tft to communicate via wifi with my cnc 3030 prover max (with GRBL, USB port CH340) and the setting is made to communicate via USB SERIAL port. I can send and I receive data from the cnc through the USB SERIAL port.. The problem is that there is a delay of about 1 second between the sending of the command and the execution from cnc device, this is very clear visible when a file is executed, all commands are executed with a delay between each other and the whole process is interrupted. I tested with communication from my computer directly to port 23 of an esp3d-tft board the delay remains, I tested using the web interface the delay remains on sending commands or executing file. If connect the machine directly to the computer with a usb cable everything works fine.\r\n\r\nCan someone tell me if this is a bug or if I missed something when compiling the code.\r\n\r\nI apologize for my bad English.",
"state": "open",
"created_at": "2024-10-24T15:47:10+00:00",
"updated_at": "2024-11-16T09:31:54+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-TFT/issues/77",
"is_pr": false,
"labels": [
"bug",
"Under investigation"
],
"priority": "normal",
"assignee": null
},
{
"number": 76,
"title": "[FEATURE REQUEST]Add Lua interpreter support like in ESP3D",
"body": "Lua interpreter support is implemented in ESP3D https://esp3d.io/ESP3D/Version_3.X/documentation/lua/\r\n\r\nAdd same support in ESP3D-TFT\r\n",
"state": "open",
"created_at": "2024-10-13T07:48:18+00:00",
"updated_at": "2024-10-13T07:48:18+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-TFT/issues/76",
"is_pr": false,
"labels": [
"Features"
],
"priority": "normal",
"assignee": null
},
{
"number": 74,
"title": "[FEATURE REQUEST]Add BTT GCODE thumbnails",
"body": "It was raised to me that now BTT TFT support thumbnails in gcode it is even documented https://github.com/bigtreetech/BIGTREETECH-TouchScreenFirmware?tab=readme-ov-file#adding-gcode-thumbnails\r\n\r\nI think it would be fun to add this feature also if possible - it would need to add an image decoder which is not an issue in theory\r\n I need to see the impact on low memory screens, but at first sight looks possible on others ^_^ TBC\r\n ",
"state": "open",
"created_at": "2024-08-14T05:12:07+00:00",
"updated_at": "2024-08-14T05:12:28+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-TFT/issues/74",
"is_pr": false,
"labels": [
"Screen",
"Features",
"lvgl 8.x"
],
"priority": "normal",
"assignee": null
},
{
"number": 67,
"title": "[FEATURE REQUEST]Add support of macro defined by webui on screen",
"body": "Now Tft fw can read the preferences.json, so a screen listing defined macros should be available.\n\nThe question is where to display the macro button?",
"state": "open",
"created_at": "2024-04-21T04:35:12+00:00",
"updated_at": "2024-08-13T00:28:50+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-TFT/issues/67",
"is_pr": false,
"labels": [
"enhancement"
],
"priority": "normal",
"assignee": null
},
{
"number": 55,
"title": "[FEATURE REQUEST]Code review / refactoring / improvement",
"body": "This is todo list of several topic that need to be done before release:\r\n\r\n- <s>Use queue for values and process them to avoid racing conditions https://github.com/luc-github/ESP3D-TFT/blob/main/main/core/esp3d_values.cpp#L70-L72\r\nand put the pop/clear the list in display task </s> (Done :+1: ) \r\n\r\n- Design different boot logo / splash for each target ( e.g: ESP3D Logo + Target name) to know from start what is display for ",
"state": "open",
"created_at": "2024-01-19T04:45:00+00:00",
"updated_at": "2024-01-21T00:38:53+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-TFT/issues/55",
"is_pr": false,
"labels": [
"enhancement",
"help welcome",
"Planned"
],
"priority": "normal",
"assignee": null
},
{
"number": 54,
"title": "[FEATURE REQUEST]Move to lvgl 9.0",
"body": "I did some reading on migration guide and API description - the mechanism seems pretty identical, API is very close but there are a lot of renaming\r\nI plan to really start to work on it when official 9.0 release is done and move to 9.x when first bug release is out ",
"state": "open",
"created_at": "2024-01-17T10:43:01+00:00",
"updated_at": "2024-08-29T06:45:54+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-TFT/issues/54",
"is_pr": false,
"labels": [
"enhancement",
"lvgl 9.x"
],
"priority": "normal",
"assignee": null
},
{
"number": 53,
"title": "[FEATURE REQUEST]Do better snapshot code with no memory need",
"body": "Currently the lvgl snapshot API use a lot of memory because it allocate all screen in one buffer then push data to it, it crash if any animation or scrolling text is active which is really not convenient\r\n\r\nI am thinking to use my previous method for snapshot (in first 3.0 version ) that actually hook the `void esp_lv_disp_flush(lv_disp_drv_t *disp, const lv_area_t *area, lv_color_t *color_p)` function.\r\nIt did not need any buffer screen unlike the lvgl API and may just freeze the screen the time the data are saved \r\nhere the old code :\r\n```\r\n/* Display flushing */\r\nvoid esp_lv_disp_flush(lv_disp_drv_t *disp, const lv_area_t *area, lv_color_t *color_p)\r\n{\r\n //TODO: need to write version for oled with big resolution\r\n uint16_t c;\r\n esp3d_screen.startWrite(); /* Start new TFT transaction */\r\n esp3d_screen.setAddrWindow(area->x1, area->y1, (area->x2 - area->x1 + 1), (area->y2 - area->y1 + 1)); /* set the working window */\r\n for (int y = area->y1; y <= area->y2; y++) {\r\n for (int x = area->x1; x <= area->x2; x++) {\r\n c = color_p->full;\r\n esp3d_screen.writeColor(c, 1);\r\n#if defined(DISPLAY_SNAPSHOT_FEATURE)\r\n if(bSnapshot) {\r\n uint32_t data = lv_color_to32(*color_p);\r\n //to handle any write issue\r\n if (fsSnapFile.write((const uint8_t *)(&data), sizeof(uint32_t)) != sizeof(uint32_t)) {\r\n //if error we stop to dump\r\n bSnapshot = false;\r\n //raise error\r\n error_snapshot = 1;\r\n }\r\n }\r\n#endif //DISPLAY_SNAPSHOT_FEATURE\r\n color_p++;\r\n }\r\n }\r\n esp3d_screen.endWrite(); /* terminate TFT transaction */\r\n lv_disp_flush_ready(disp); /* tell lvgl that flushing is done */\r\n}\r\n\r\n\r\nbool Display::snapshot(char * filename)\r\n{\r\n bool res = false;\r\n#if defined(DISPLAY_SNAPSHOT_FEATURE)\r\n //sanity check to avoid to corrupt FS with capacity overload\r\n error_snapshot = 0;\r\n if (ESP_FileSystem::freeBytes() < SNAP_SIZE) {\r\n return false;\r\n }\r\n if(filename) {\r\n fsSnapFile = ESP_FileSystem::open(filename, ESP_FILE_WRITE);\r\n } else {\r\n fsSnapFile = ESP_FileSystem::open(SNAPFILENAME, ESP_FILE_WRITE);\r\n }\r\n if (!fsSnapFile) {\r\n return false;\r\n }\r\n\r\n bSnapshot = true;\r\n lv_obj_invalidate(lv_scr_act());\r\n lv_refr_now(lv_disp_get_default()); /* Will call our disp_drv.disp_flush function */\r\n bSnapshot = false;\r\n fsSnapFile.close();\r\n //if any snapshot error\r\n if (error_snapshot == 0) {\r\n res = true;\r\n }\r\n#endif //DISPLAY_SNAPSHOT_FEATURE\r\n return res;\r\n}\r\n```\r\n\r\nthe new lvgl API use one function only:\r\n```\r\nstatic void lv_disp_flush(lv_disp_drv_t * disp_drv, const lv_area_t * area, lv_color_t * color_p) {\r\n esp_lcd_panel_draw_bitmap(disp_panel, area->x1, area->y1, area->x2 + 1, area->y2 + 1, color_p); \r\n}\r\n```\r\nso it may be possible to redo same for snapshot - this method do a real snap what ever is displayed and even there is an animation.=> TBC ",
"state": "open",
"created_at": "2024-01-07T04:47:08+00:00",
"updated_at": "2024-01-07T04:47:09+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-TFT/issues/53",
"is_pr": false,
"labels": [
"bug",
"Features"
],
"priority": "normal",
"assignee": null
},
{
"number": 12,
"title": "[FEATURE REQUEST]WhatsApp Notification",
"body": "How to do is here https://www.callmebot.com/blog/free-api-whatsapp-messages/ - it is free and it use same way as others - so it is easy to implement\r\n",
"state": "open",
"created_at": "2023-02-20T06:58:18+00:00",
"updated_at": "2023-02-20T06:58:52+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-TFT/issues/12",
"is_pr": false,
"labels": [
"enhancement"
],
"priority": "normal",
"assignee": null
},
{
"number": 5,
"title": "[ENHANCEMENT]Add Pin interrupt support on FT5X06 when supported to save mcu time instead of doing permanent polling",
"body": "Doing permament polling on touch to see if was pressed save mcu time on some solution (WT32-SC01 New Plus), int pin for FT5X06 is available, but seems not working on my device (https://github.com/luc-github/ESP3D-TFT/discussions/1#discussioncomment-3762021), may be hardware issue ? \r\n\r\nIf anyone know how to solve this with a working solution - feedback is welcome \ud83d\ude38 ",
"state": "open",
"created_at": "2022-10-01T00:07:26+00:00",
"updated_at": "2022-10-01T00:07:26+00:00",
"closed_at": null,
"url": "https://github.com/luc-github/ESP3D-TFT/issues/5",
"is_pr": false,
"labels": [
"enhancement",
"help welcome",
"Drivers",
"Touch"
],
"priority": "normal",
"assignee": null
}
]
"issues": []
}
],
"contributors": [
Expand Down
Loading

0 comments on commit b561343

Please sign in to comment.