Closed mauroForlimpopoli closed 2 years ago
What is the conflict?
I connected 2 sensors. Without the module Found 2 devices. With the module I get always Found 0 devices
what is strange is that until recently it worked regularly, but after a windows update (maybe a coincidence) it no longer works
Update. In my real project, if a I add a simple .trace("hello")
sometimes it works ?!?!? So I really don't know how to check what is wrong.
Now I suppose is not a problem of conflict. It's only a coincidence my add module. In fact also if I write: const switchSkin = new Skin({ texture: allSwitchTexture }); the bus return "Found devices = 0". Could be a problem of Timing ? The free RAM is about 9000 byte and no error of stack. What can I check ?
You do have quite a large number of different hardware module in your project. Is it possible that two modules are trying to use the same RMT channels? If they overlapped in their access, that might explain the failures you see.
I haven't tried the GPIO code path in the OneWire module. Assuming that works on ESP32, perhaps it would help in isolating the problem you are seeing.
Peter, thank your for your assistance. I don't know how the RMT works, but like I wrote :
const switchSkin = new Skin({
texture: allSwitchTexture
});
or other simply code stops the reading of onewire bus. How can be explained this one ? I resolved the problem excluding some modules (like Flash or Analog), and temporary it works, but subsequently when I add other simply code the problem come again. What are the modules they use RMT? can I change the address of them ? Thank you
How can be explained this one ?
With the information available to me, I cannot. But, I am certain that the Piu Skin
constructor is not directly interfering with the OneWire module. So, we need to consider indirect interactions. Those could include failures due to low memory, differences in timing, and differences in when the garbage collector runs.
The requests above were an attempt to eliminate two variables help better understand the problem. The first was whether there might a conflict in the RMT channels used. That seems possible because the NeoPixels driver can use the RMT too. The other is whether there might a problem introduced by using the RMT, which is why I suggested trying the GPIO version of the RMT module.
How have you wired up this project? Are you using a breadboard?
I have found using onewire that it has been a hardware issue with an intermittent connection that is the problem.
I would go back to code that is just the onewire example code and test that. If that works - then flash with your current build and test that.
If you still have an issue with your current build and the sample works, to eliminate the possible RMT conflict as @phoddie suggests, first using the sample change the onewire defines to be the same as the esp: https://github.com/Moddable-OpenSource/moddable/blob/public/examples/drivers/onewire/manifest.json#L32-L34
"defines": {
"onewire": {
"driver_gpio": "GPIO"
}
}
This will then change the driver. If this works in the sample. then change in your build and see if it works.
I'm using Moddable-Two with the 2 sensors connected on pin 16 and a pullup resistor of 4,7kohm to 5 VDC. If I use the Onewire example it works, but only by changing the manifest like below, the bus doesn't find the sensors.
{
"build": {
"PARTITIONS_FILE": "./partitions.csv"
},
"include": [
"$(MODDABLE)/examples/manifest_base.json",
"$(MODDABLE)/examples/manifest_piu.json",
"$(MODULES)/input/keyboard/manifest.json",
"$(MODDABLE)/modules/files/file/manifest.json",
"$(MODULES)/pins/analog/manifest.json",
"$(MODULES)/network/wifi/manifest.json",
"$(MODDABLE)/examples/manifest_net.json",
"$(MODDABLE)/modules/network/ble/manifest_server.json",
"$(MODDABLE)/modules/io/manifest.json",
"$(MODULES)/pins/digital/manifest.json"
],
"creation":{
"stack":510,
"static": 98304,
"keys": {
"available":50
},
"chunk": {
"initial":35362,
"incremental":1024
}
},
"modules": {
"*": [
"./main",
"$(MODULES)/network/http/*",
"./funcSleep",
"$(MODULES)/network/sntp/*",
"$(MODULES)/drivers/onewire/*",
"$(MODULES)/drivers/neopixel/*",
"$(MODULES)/drivers/neopixel/esp32/*"
],
"esp32/ota": "$(MODDABLE)/build/devices/esp32/modules/ota/*"
},
"resources":{
"*-alpha": [
"$(MODDABLE)/examples/assets/fonts/OpenSans-Regular-20",
"$(MODDABLE)/examples/assets/fonts/OpenSans-Semibold-18",
"$(MODDABLE)/examples/assets/fonts/OpenSans-Light-42",
"$(MODDABLE)/examples/assets/fonts/OpenSans-Semibold-28",
"$(MODDABLE)/examples/assets/fonts/OpenSans-Regular-72",
"$(MODDABLE)/examples/assets/fonts/arc64",
"$(MODDABLE)/examples/assets/fonts/roboto32"
],
"*-image(50)": [
"$(MODDABLE)/examples/assets/images/Bluetooth-icon",
"$(MODDABLE)/examples/assets/images/Wifi-icon",
"$(MODDABLE)/examples/assets/images/unlock-icon",
"$(MODDABLE)/examples/assets/images/lock-icon",
"$(MODDABLE)/examples/assets/images/down-icon",
"$(MODDABLE)/examples/assets/images/battery-icon"
],
"*-mask": [
"$(MODDABLE)/examples/assets/images/loading-icon",
"$(MODDABLE)/examples/assets/images/thermometer-mask",
"$(MODDABLE)/examples/assets/images/battery-mask",
"$(MODDABLE)/examples/assets/images/switch-mask"
]
},
"platforms": {
"esp32": {
"config": {
"rotation": 90,
"brightness": 0,
"file": {
"root": "/mod/"
},
"onewire": {
"pin": "16"
}
},
"defines": {
"onewire": {
"driver_rmt": "RMT",
"rmt_rx_channel": "RMT_CHANNEL_2",
"rmt_tx_channel": "RMT_CHANNEL_3"
}
},
"include": [
"$(MODULES)/pins/digital/manifest.json"
],
"modules": {
"*": [
"$(MODULES)/files/flash/*",
"$(MODULES)/files/flash/esp32/*",
"$(MODULES)/drivers/onewire/esp/*"
]
}
}
},
"preload": [
"neopixel",
"http",
"sntp",
"file",
"pins/analog",
"timer",
"esp32/ota",
"ble",
"preference",
"flash",
"Resource",
"keyboard",
"time",
"timer",
"onewire",
"DS18X20",
"funcSleep"
],
"data": {
"*": [
"./mydata",
"./myWeb"
]
},"ble":{
"*": [
"./bleservices/*"
]
}
}
This is the state of Xbug
@mauroForlimpopoli, both @wilberforce and I are trying to help. @wilberforce contributed the OneWire implementation and I have some experience using it and the Moddable SDK. Both @wilberforce and I have offered suggestions. It looks like you haven't tried those. Please try to help us to help you by trying what we suggest and responding directly to what we ask. Thank you.
Sorry Peter, I didn't say you I done that you and wilberforrce told me. It is not absolutely a intermittent connection because every time I recomplile without "const switchSkin..." it works right. I also take off "NeoPixels mdule" but no result. I changed "driver_gpio": "GPIO", but nothing. Like I told before your "onewire"example works fine, but when I add all my module I have the problem. I just don't how is the right mode to change che RMT channel here to try to use another RMT channel
"rmt_rx_channel": "RMT_CHANNEL_2",
"rmt_tx_channel": "RMT_CHANNEL_3"
Let's try to understand why the search is failing. The xs_onewire_search
returns an error. We can trace that. In $MODDABLE/modules/drivers/onewire/esp/modonewire.c change line 166 from...
owb_search_first(onewire->owb, &search_state, &found);
...to....
owb_status result = owb_search_first(onewire->owb, &search_state, &found);
xsLog("owb_search_first returns %d\n", (int)result);
Maybe the error will provide some clue.
I did the change. This is the answer: owb_search_first returns 0 but I have the same answer also if a sensor is found
Interesting. Here's a variation of the xs_onewire_search
function. It shouldn't make a difference. It does log a bit more. (Note: I can't compile this right now, so you may need to adjust the C code if there's a compilation error):
void xs_onewire_search(xsMachine *the)
{
modOneWire onewire = xsmcGetHostData(xsThis);
OneWireBus_SearchState search_state = {0};
bool found = false;
int index = 0;
owb_status result = owb_search_first(onewire->owb, &search_state, &found);
xsLog("owb_search_first result = %d, found = %d\n", (int)result, (int)found);
xsmcVars(1);
xsResult = xsNewArray(10);
while (found)
{
xsmcSetArrayBuffer(xsVar(0), &search_state.rom_code.bytes, 8);
xsLog(" push result # %d\n", index);
xsmcSetIndex(xsResult, index++, xsVar(0));
owb_search_next(onewire->owb, &search_state, &found);
}
xsLog("xs_onewire_search exit\n");
}
This is the result after the change:
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
found 10
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
Found first:28f54375d0013cc9
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
Found 2nd:28a37076e0013cc9
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
owb_search_first result = 0, found = 1
push result # 0
push result # 1
xs_onewire_search exit
77
file exists
762
0 puntRecMem
calcolo ultimo rec
762 par
partizione okBT activeHello, world - sample
XS abort: memory full
The part I understand looks pretty good. It always finds two items. Does your app always see both of them in the returned array?
XS abort: memory full
@phoddie I think the last line of the output above it the clue!
Are these settings causing issues:
"creation":{
"stack":510,
"static": 98304,
"keys": {
"available":50
},
"chunk": {
"initial":35362,
"incremental":1024
}
},
Perhaps watching the intrumentation in the debugger and determing when and what is consuming memory might help?
@wilberforce - I'm not assuming the memory exhaustion is the issue here. The project @mauroForlimpopoli has been working on has been under memory pressure from the start. But, I could be wrong. There's not enough here to really say.
What is funny is that it does one search -- and maybe only looks at the results of the length returned (which was forced to 10 in my hack above). It then seems to repeat the full search, once for each of the 10 search results. But why? It got all the results in initial search.
Does your app always see both of them in the returned array? This is the array when I add my extra code
owb_search_first result = 0, found = 0
xs_onewire_search exit
found 10
owb_search_first result = 0, found = 0
xs_onewire_search exit
This is the memory state at the last instruction before the "memory full" (without extra code)
So you have moved the point at which the onewire bus search occurs in your application - and when it is first it works?
Can you leave it intialising first?
Dear wilberforce, thank you for your assistance, but I don't understand what do you mean. I initialized the bus just after the setting of main variable of my program. On my little experience, I suppose it could be something like memory exhaustion. This is because this is a simple example: If I add :
const switchSkin = new Skin({
texture: allSwitchTexture
});
the bus stop working, but if then I erase:
class alarmContainerBehavior extends Behavior {
onDisplaying(content) {
}
onTouchBegan(content) {
}
}
it become to works. If it could help
Closing, as this issue has gone cold and there's nothing actionable in the thread above.
Dear Peter,
unfortunately this issue is not resolved yet. Now I'm looking for other and I jumped this one. This situation is really abnormal. The program sometimes show the problem, but if I add some code (for anything) it disapper. Then I add other code and it come agan and so on...
Sometimes is enougth to add : trace("hello") to appear or disapper
It could be a simple syntax error that I never found, but it only a guess.
At the moment like you saw I'm looking to preload module to preserve memory. If I will not resolve it I will come back on this issue later.
Thank you for your assistance
Mauro
Il 24/09/2021 01:20 Peter Hoddie ***@***.***> ha scritto: Closing, as this issue has gone cold and there's nothing actionable in the thread above. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Moddable-OpenSource/moddable/issues/683#issuecomment-926230309 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ASV75Y6YCYUTLLTJTDNCNIDUDOY4HANCNFSM5CD776JA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .
I understand that you are seeing this problem. There's not enough to be able to investigate or diagnose the problem. When there is something new, feel free to reopen then issue.
I'm using Moddable-Two. My sample code is token from the example "https://github.com/Moddable-OpenSource/moddable/blob/public/examples/drivers/onewire/main.js" I changed the manifest.json because in my real project I need all these peripherals. So:
it works only if I take off the line "$(MODULES)/files/flash/*" and I can not include "$(MODULES)/pins/analog/manifest.json" How can I solve the problem? Regards