Closed Sineos closed 1 year ago
phoddie
commented
1 year ago Good morning.
This is very possible and fits into my recent work. The design of the Node (organization, UI, messages) needs to be decided. This IC² node for Raspberry Pi looks like a good starting point. I would start with its "i2c in" and "i2c out" nodes, deferring "i2c scan" for later (mostly because I remember ESP32 I²C scan begin very, very slow).
Does that node look like a good match for what you want to do?
Sineos
commented
1 year ago Thanks for your comment @phoddie I have not yet tried this contrib node but quickly installing it and having a look, indicates that it goes exactly into this direction
Guess we can very well live without the scan node, although it might have a value to verify that a device is properly wired up and actually "on the bus" instead of trying to talk to thin air.
Your work towards such is highly appreciated. Thanks.
phoddie
commented
1 year ago I have not yet tried this contrib node but quickly installing it and having a look, indicates that it goes exactly into this direction
Perfect. Thanks for taking a look.
Guess we can very well live without the scan node, although it might have a value to verify that a device is properly wired up and actually "on the bus" instead of trying to talk to thin air.
If the device isn't working, its status will be set to indicate that. A flow can trap on catch, which will even work if the sensor is removed while running. ;)
phoddie
commented
1 year ago Just a quick FYI – the I²C In and I²C Out nodes are working. They match the RPi versions as closely as my understanding allows. It isn't quite ready to try yet, but soon. The flow below is a simple test that reads the ID registers from the FocalTech touch controller on a Moddable Two. The I²C address is empty because it is set by the Inject node (dynamic address is a feature of the RPi nodes).
Sineos
commented
1 year ago Wow, awesome. Looking forward to it!
phoddie
commented
1 year ago The I² In and Out nodes are live. Check out the announcement about all the new MCU nodes.
Here's the flows for the example above, which could be useful as a starting point for explorations. If you run it, use the esp32/nodemcu host instead of esp32/moddable_two_io because the Moddable Two host takes ownership of the touch controller. which prevents the nodes from using it.
Sineos
commented
1 year ago Peter, I'm currently playing with the Moddable Two and the new I2C nodes. So far with limited success (which surely is my fault):
According to https://github.com/Moddable-OpenSource/moddable/blob/public/documentation/devices/moddable-two.md this is the I2C bus also of the display. Is it correct to use it for further peripherals? Bus name ist just "default"?
phoddie
commented
1 year ago Thanks for trying this out!
Yes, on Moddable Two the default I2C bus is on pins 21 and 22. I2C is a shared bus so several devices can be connected as long as they have different addresses. The touch sensor is connected to that bus.
You can use two other pins, if you prefer. Just don't use the SPI bus pins that are owned by the display controller.
FWIW - I suggest starting with the built-in touch sensor, to make sure all the pieces are working together. One detail: you'll need to tell the host not to use the touch controller. Do that in the config by setting touch to an empty string. In the MCU plug-in I believe that looks like {"touch": ""}.
Sineos
commented
1 year ago There seem to be a lot to learn still. So my apologies in advance, that I likely will overstress your patience Peter:
CALL "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars32.bat"
pushd %IDF_PATH%
CALL "C:\Espressif\idf_cmd_init.bat"
popd
mcconfig -m -p esp32/nodemcu sntp="fritz.box" screen="ili9341", touch="" ssid="xx" password="xx"{
"build": {
"MODULES": "C:\\Users\\souls\\Projects\\moddable\\modules",
"MCUROOT": "C:\\Users\\souls\\.node-red\\node_modules\\@ralphwetzel\\node-red-mcu-plugin\\node-red-mcu",
"REDNODES": "C:\\Users\\souls\\AppData\\Roaming\\npm\\node_modules\\node-red\\node_modules\\@node-red\\nodes"
},
"include": [
"$(MCUROOT)/manifest_runtime.json",
"C:\\Users\\souls\\.node-red\\node_modules\\@moddable-node-red\\sensor\\manifest.json",
"$(MCUROOT)/nodes/ui/manifest.json",
"$(MCUROOT)/nodes/random/manifest.json",
"$(MCUROOT)/nodes/trigger/manifest.json",
"C:\\Users\\souls\\Projects\\moddable\\modules\\drivers\\ili9341\\manifest.json"
],
"config": {
"backlight": 18
},
"defines": {
"i2c": {
"sda_pin": 21,
"scl_pin": 22
},
"spi": {
"miso_pin": 12,
"mosi_pin": 13,
"sck_pin": 14
},
"ili9341": {
"hz": 40000000,
"cs_pin": 15,
"dc_pin": 2,
"spi_port": "HSPI_HOST",
"registers_append": [
"0x36, 1, 0xF0,",
"0x21, 0,",
"0xE0, 14, 0xD0, 0x08, 0x11, 0x08, 0x0C, 0x15, 0x39, 0x33, 0x50, 0x36, 0x13, 0x14, 0x29, 0x2d,",
"0xE1, 14, 0xD0, 0x08, 0x11, 0x08, 0x06, 0x06, 0x39, 0x44, 0x51, 0x0b, 0x16, 0x14, 0x2f, 0x31,"
]
}
},
"modules": {
"*": [
"./main",
{
"source": "./flows",
"transform": "nodered2mcu"
}
],
"~": []
},
"config": {
"noderedmcu": {
"editor": true
}
}
}As the standard manifest.json of the esp32/nodemcu target did not include the Moddable Two details, I took the defines and the ili9341 include from here https://github.com/Moddable-OpenSource/moddable/blob/public/build/devices/esp32/targets/moddable_two/manifest.json (minus the touch controller)
The test flow to build is again highly sophisticated:
[{"id":"ea553c2aaebaecce","type":"tab","label":"Flow 5","disabled":false,"info":"","env":[],"_mcu":{"mcu":false}},{"id":"78b364a46514e30c","type":"sensor","z":"ea553c2aaebaecce","name":"","platform":"","module":"embedded:sensor/Touch/FT6x06","options":{"sensor":{"io":"SMBus","bus":"default","address":"0x38"}},"configuration":"{}","_mcu":{"mcu":false},"x":370,"y":180,"wires":[[]]},{"id":"ebdfa9f1ce81c2e0","type":"ui_text","z":"ea553c2aaebaecce","group":"9fd12e0c6f71cff1","order":0,"width":0,"height":0,"name":"","label":"text","format":"Hello","layout":"row-spread","className":"","_mcu":{"mcu":false},"x":530,"y":180,"wires":[]},{"id":"9fd12e0c6f71cff1","type":"ui_group","name":"mcu_dash","tab":"635ba43dc8d01298","order":3,"disp":true,"width":"6","collapse":false,"className":"","_mcu":{"mcu":false}},{"id":"635ba43dc8d01298","type":"ui_tab","name":"node_mcu","icon":"track_changes","order":1,"disabled":false,"hidden":false}]
It has built and flashed (this is already more than I'd expected) and the debugger is outputting
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:344
load:0x40078000,len:13488
load:0x40080400,len:3520
0x40080400: _init at ??:?but the screen stays dark.
Any helping hand is highly appreciated. Thanks
phoddie
commented
1 year ago As the standard manifest.json of the esp32/nodemcu target did not include the Moddable Two details...
I would just use the manifest of esp32/moddable_two. There's no need to perform surgery on manifests that way.
Your command line has a stray command after screen:
mcconfig -m -p esp32/nodemcu sntp="fritz.box" screen="ili9341", touch="" ssid="xx" password="xx"
If you use the Moddable Two target, you can just do this:
mcconfig -d -m -p esp32/moddable_two sntp="fritz.box" touch="" ssid="xx" password="xx"
Note that I added "-d" to get a debug build, so that errors will be reported in the debugger. Without that, you are creating a release build which provides no feedback about errors.
Sineos
commented
1 year ago Thanks a lot for these pointers. Brings me a step further but still it seems I have some work in front of me.
I would just use the manifest of
esp32/moddable_two
Ok, this makes things a lot easier. I was following your advice a few posts up to use the esp32/nodemcu as a basis. Likely a misunderstanding on my side.
Note that I added "-d" to get a debug build, so that errors will be reported in the debugger.
This is a very valuable pointer and I'm really good at producing errors 😄
The build succeeds but then the debugger fails with a message that the FT6206 driver cannot be found. I looked into the sources and found some hints:
The path
"$(MODDABLE)/modules/drivers/sensors/ft6x06/manifest.json"
does not exists. Replacing it with
"$(MODDABLE)/modules/drivers/ft6206/manifest.json"
Still this ends up with:
C:\Users\souls\Projects\moddable\build\tmp\esp32\moddable_two\debug\b33dc2xt18n\modules\flows.js (49) # Break: importNow: module "embedded:sensor/Touch/FT6x06" not found!Backlight turns on though. Not sure if it is correct to reference a non ECMA version here but an ECMA version of the FT6206 seems not to exists.
Unrelated but for sake of completeness: https://github.com/phoddie/node-red-mcu/blob/3f2d1a13221c9a4d536ffd55d22bc69ab9b4d788/nodes/sensor/resources/sensors.json#L549-L556
Seems like a copy-paste-mishap. I'm not sure if the GT911 was intended or the FT6206. Would have issued a PR but since I'm not sure what is correct, this makes no sense.
Sineos
commented
1 year ago Had a daft moment:
https://github.com/Moddable-OpenSource/moddable/tree/public/modules/drivers/sensors/ft6206 exists in fact, but replacing the original source:
"$(MODDABLE)/modules/drivers/sensors/ft6x06/manifest.json"
with
"$(MODDABLE)/modules/drivers/sensors/ft6206/manifest.json"
still ends up with
C:\Users\souls\Projects\moddable\build\tmp\esp32\moddable_two\debug\b33dc2xt18n\modules\flows.js (49) # Break: importNow: module "embedded:sensor/Touch/FT6x06" not found!
tve
commented
1 year ago You have an import statement somewhere of the form:
import ... from "embedded:sensor/Touch/FT6x06"The name in " " is anything you like, doesn't have to correspond to a filename or anything. However, in the manifest (or included manifests) you need to translate that name to a file/directory that has the code module you want. So somewhere you need:
modules: {
...,
"embedded:sensor/Touch/FT6x06": ["file/path/to/the/driver"}
}From the sensors.json there's "driver": "$(MODDABLE)/modules/drivers/sensors/gt911/manifest.json", so that may be the path you're looking for. But the sensors.json stuff suggests that it may be passed via a global variable (I haven't dealt with that stuff yet).
Anyway, sorry, no solution but maybe a few more pointers, hopefully useful in some way...
Sineos
commented
1 year ago @phoddie I could really use your help here please:
According to https://github.com/Moddable-OpenSource/moddable/tree/public/modules/drivers/sensors/ft6206 it should read:
"driver": "$(MODDABLE)/modules/drivers/sensors/ft6206/manifest.json"https://github.com/phoddie/node-red-mcu/blob/1b06e759fe8b6db5165964b965c2403e327098e9/nodes/sensor/resources/sensors.json#L549-L556 Seems like a mix-up between FT6206 and GT911
mcconfig -d -x localhost:5004 -m -p esp32/moddable_two sntp="fritz.box" screen="ili9341" touch="" ssid="xx" password="xx"
I tried many variants and the typical reaction of xsbug is either:
stack overflow (-1)!
XS abort: stack overflow
C:\Users\souls\Projects\moddable\xs\platforms\esp\xsPlatform.c (235) # Break: C: xsDebugger!e.g. when doing this in the builds mainfest.json
{
"build": {
"MODULES": "C:\\Users\\souls\\Projects\\moddable\\modules",
"MCUROOT": "C:\\Users\\souls\\.node-red\\node_modules\\@ralphwetzel\\node-red-mcu-plugin\\node-red-mcu",
"REDNODES": "C:\\Users\\souls\\AppData\\Roaming\\npm\\node_modules\\node-red\\node_modules\\@node-red\\nodes"
},
"include": [
"$(MCUROOT)/manifest_runtime.json",
"C:\\Users\\souls\\.node-red\\node_modules\\@moddable-node-red\\sensor\\manifest.json",
"C:\\Users\\souls\\Projects\\moddable\\modules\\drivers\\sensors\\ft6206\\manifest.json",
"$(MCUROOT)/nodes/ui/manifest.json",
"$(MCUROOT)/nodes/random/manifest.json",
"$(MCUROOT)/nodes/trigger/manifest.json"
],
"modules": {
"*": [
"./main",
{
"source": "./flows",
"transform": "nodered2mcu"
}
],
"~": [],
"embedded:sensor/Touch/FT6x06": ["$(MODDABLE)/modules/drivers/sensors/ft6206/manifest.json"]
},
"config": {
"noderedmcu": {
"editor": true
}
}
}
or
C:\Users\souls\Projects\moddable\build\tmp\esp32\moddable_two\debug\b33dc2xt18n\modules\flows.js (96) # Break: importNow: module "embedded:sensor/Touch/FT6x06" not found!Sure, I can take a look this evening.
phoddie
commented
1 year ago The typos in sensors.json are real. I've committed fixes for those. Thank you.
When using the touch sensor, you have to be careful to disable its use by Piu (the UI framework). It looks like you are doing that with touch="" on the command line.
To focus on the touch sensor, I simplified the flow without the dashboard UI nodes. Here's that flow.
The ECMA-419 FocalTech driver isn't built into Moddable Two (the original touch driver is). To add that, I added $(MODDABLE)/modules/drivers/sensors/ft6206/manifest.json to the includes array in manifest_runtime.json:
That builds and runs with:
mcconfig -d -m -p esp32/moddable_two touch=""I added back the two UI nodes and re-exported. Recall that it is necessary to export all flows, not just the current flow, when using the UI nodes. That's because the Node-RED Editor only exports the required global Dashboard node when exporting all flows. That builds and runs. Of course, the UI no longer has the touch driver, so it can draw but it cannot respond to touch events. The touch sensor output is routed to the Debug node.
Sineos
commented
1 year ago Thanks for your guidance. I have been able to partially follow it:
CALL "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Auxiliary\Build\vcvars32.bat"
pushd %IDF_PATH%
CALL "C:\Espressif\idf_cmd_init.bat"
popd
mcconfig -d -x localhost:5004 -m -p esp32/moddable_two sntp="fritz.box" touch="" ssid="xx" password="xx"As created by the Node Red plugin. Only added the FT6206 include
Wi-Fi connected to "xx"
IP address 192.168.178.165
stack overflow (-1)!
XS abort: stack overflow
C:\Users\souls\Projects\moddable\xs\platforms\esp\xsPlatform.c (235) # Break: C: xsDebugger!
In the manifest, change $(MCUROOT)/manifest_runtime.json to $(MCUROOT)/manifest_host.json. That will get you the expected JavaScript stack size and other device-specific memory settings.
Sineos
commented
1 year ago Unfortunately this ended in:
IP address 192.168.178.165
C:\Users\souls\Projects\moddable\modules\commodetto\commodettoPoco.c (72) # Break: build: no memory!The settings in Node MCU regarding the display are:
Maybe anything wrong here?
xsbug displays:
phoddie
commented
1 year ago Maybe anything wrong here?
Yes. The render buffer size is absurdly large. 232 315 2 (bytes per pixel) is over 146,000 bytes. You show about 50 KB free. It will fail.
Maybe there are too many options. There's almost never a reason to set touch count, render buffer size, display list count, or command list length. The defaults should generally be fine. Changing those without understanding them looking for trouble.
Sineos
commented
1 year ago OMG, it works! Confusing "Render Buffer Size" with Screen Resolution might not have been the smartest idea of my life. Thanks!
In the manifest, change
$(MCUROOT)/manifest_runtime.jsonto$(MCUROOT)/manifest_host.json. That will get you the expected JavaScript stack size and other device-specific memory settings.
Would you please be so kind to explain this? manifest_runtime.json is put there by the node-red-mcu-plugin
Of course, the UI no longer has the touch driver, so it can draw but it cannot respond to touch events. The touch sensor output is routed to the Debug node.
What would be the right approach to have the UI react on touch events? Remove the sensor node in flow and compile with touch="ft6206"?
phoddie
commented
1 year ago OMG, it works!
Wahoo!! Congratulations.
Confusing "Render Buffer Size" with Screen Resolution might not have been the smartest idea of my life. Thanks!
Too many options. When something doesn't work and options are available, the tendency is to adjust them. That can do more harm than good.
Would you please be so kind to explain this? manifest_runtime.json is put there by the node-red-mcu-plugin
It seems like a bug in the MCU plug-in manifest generation. It may be that the plug-in didn't fully track the changes made when Mod support was added.
What would be the right approach to have the UI react on touch events? Remove the sensor node in flow and compile with touch="ft6206"?
Yes, remove the sensor node. You don't need to set touch="ft6206. That is the default in the host for esp32/moddable_two since that is its built-in touch driver. Too many options. ;)
Sineos
commented
1 year ago Working like a charm now. Many thanks for your kind and dedicated support @phoddie
phoddie
commented
1 year ago Thanks for working through this. I look forward to seeing what you can do combining sensor and dashboard nodes.
Something between a question and feature request: Would it be possible to have a generic I2C / SPI In- and Out-Node to talk to such devices even when no dedicated support is presently available?
So, in my naive world and looking at the implementation guide of one of the sensors I'd like to use:
Would mean: Send a payload to 1 to register 0xC3 of I2C device address 0x68 (via the out-node) and get back some buffer in the in-node that contains my measurement. Unfortunately my simplistic view tends to collide with reality sometimes 🤷