Lora example doesn't work?

[tve]

I decided to try the LoRa example (`examples/drivers/lora). When I run it on esp32 I get an error:

/data/main.js (26) # Break: main: get device: undefined variable!

device is not imported, is it a global (newbie here, obviously)? This demo is not listed in the readme for the drivers directory, so maybe I'm missing some prerequisite?

[phoddie]

Please provide the command line you used to build the example.

[tve]

> mcconfig -d -m -p esp32/nodemcu                       
Detecting the Python interpreter                                                  
Checking "python" ...                                                             
Python 3.10.8                                                                     
"python" has been detected                                                        
Not using an unsupported version of tool xtensa-esp32-elf found in PATH: esp-2021r
2-patch3-8.4.0.                                                                   
Python requirements from /home/sw/moddable/esp-idf/requirements.txt are satisfied.
# Reconfiguring ESP-IDF...                    
...
[100%] Built target xs_esp32.elf
[100%] Built target gen_project_binary
xs_esp32.bin binary size 0x5d380 bytes. Smallest app partition is 0x390000 bytes. 
0x332c80 bytes (90%) free.
[100%] Built target app_check_size
[100%] Built target app
esptool.py esp32 -p /dev/ttyUSB1 -b 921600 --before=default_reset --after=hard_res
et write_flash --flash_mode dio --flash_freq 80m --flash_size 4MB 0x1000 bootloade
r/bootloader.bin 0x10000 xs_esp32.bin 0x8000 partition_table/partition-table.bin
esptool.py v3.3.2
Serial port /dev/ttyUSB1
...
Leaving...
Hard resetting via RTS pin...
[100%] Built target flash
 ESP32
Running make in directory /home/sw/moddable/moddable/build/tmp/esp32/nodemcu/debug/lora/xsProj-esp32/build
Executing "make -j 18 flash"...
Done

[mkellner]

I see your build target is esp32/nodemcu. That device does not support LoRa.

There is a build target esp32/heltec_lora_32 located in $MODDABLE/build/devices/esp32/targets/heltec_lora_32. It is set up for the way that device is wired.

The global device is defined in host/provider.js in that directory. That particular build target includes a device.peripheral.lora object, which is necessary for this example.

[nickthiru]

@tve Thanks for the prompt response. I am trying to get the examples\drivers\lora\ example to work with esp32/nodemcu. Here's what I did.

1. I copied the build\devices\esp32\targets\heltec_lora_32\ folder to build\devices\esp32\targets\nodemcu_lora\
2. I also wanted to keep the new target as close to build\devices\esp32\targets\nodemcu_lora\, which is why the new target folder also has the setup-target.js, which I did not modify.

3. The new target's manifest.

4. The new target's provider. I added the device.SPI.VSPI property and set the VSPI (as opposed to HSPI) pins there.

5. To the provider, I also added the property device.peripheral.lora.VSPI' with a class value that was copied from device.peripheral.lora.Default', but with the spi constructor object referencing the new VSPI object, and the select constructor object pin value set to the VSPI CS pin number.

6. In examples\drivers\lora\main.js, I updated the call to the lora initializer to the new VSPI property I created in the new target's provider.

7. Finally, I executed mcconfig -d -m -p esp32/nodemcu_lora from examples\drivers\lora\.

[tve]

Why are you creating all the duplication with VSPI instead of updating the SPI pins and being done with it?
I'm not seeing what's wrong, I assume you double-checked your wiring. One thing to try is to back down from 9Mhz SPI clock to 1Mhz or lower.

[nickthiru]

Why are you creating all the duplication with VSPI instead of updating the SPI pins and being done with it?

I did this because I may do a PR down the road with the proposal that the nodemcu_lora target I created replace the nodemcu target. In this case, creating a separate configuration for the VSPI interface would reduce the chances of breaking any code that relies on the nodemcu target as it exists now i.e. the default using HSPI pins.

I'm not seeing what's wrong, I assume you double-checked your wiring. One thing to try is to back down from 9Mhz SPI clock to 1Mhz or lower.

Yes, that's what I thought to: check the wiring. Thanks for tip to check the clock speed; I will try that as well.

[phoddie]

I've not been following this in detail, so apologies if this is off-topic. In the SPI constructor options object, the port property is important. On ESP32, it corresponds to the ESP-IDF enumeration SPI1_HOST, SPI2_HOST, SPI3_HOST. The IDF makes this a bit confusing, but for an original ESP32 (not ESP32-S2, ESP32-S3, etc), setting port to 1 in the SPI constructor selects SPI2_HOST which is HSPI_HOST. If you want to use VSPI_HOST, the port needs to be set to SPI3_HOST which is 2. (You can see all this for yourself in ESP-IDF/components/hal/include/hal/spi_types.h.)

[nickthiru]

@phoddie Thanks for the insight. I was, in fact, wondering about the purpose of the port property.

[nickthiru]

Good thing I came across this (and #991); I was about to implement the SX1276 driver for my nodemcu! Thanks @tve for asking and @mkellner for the detailed answer.

[nickthiru]

Hi,

I'm wondering how it's possible for the lora example to work (esp. accessing the device object), even when selecting esp32/heltec_lora_32 as the target, when its manifest doesn't reference, neither directly nor indirectly, modules\io\manifests\esp32\manifest.json, which is where the provider.js modules are included (specifically, within the platforms object)?

[phoddie]

• esp32/heltec_lora_32 includes $(MODDABLE)/modules/io/manifest.json
• which includes ./manifests/esp32/manifest.json
• which includes "$(BUILD)/devices/$(PLATFORM)/targets/$(SUBPLATFORM)/host/provider
• here "$(BUILD)" is $MODDABLE/build, "$(PLATFORM)" is esp32 and "$(SUBPLATFORM)" is heltec_lora_32

[nickthiru]

@phoddie Thank you. Yes, I did notice the first one but I didn't see how that manifest was being included in the build process. If I execute mcconfig from examples/drivers/lora/, that example's manifest only includes /examples/manifest_base.json, and when I followed the chain downwards, there was no connection with esp32/heltec_lora_32's manifest. I thought that the build target's manifest may be listed in the platforms.includes property of modules\io\manifests\esp32\manifest.json but there is only the modules property in the platforms object, which references the provider but not the manifest.

In relation to manifests, does the following...

...mean that it starts with manifests that are deepest in the chain and then works its way up? So, the deepest would be examples\manifest_base.json and the top-most one would be the manifest of the host or mod.

[nickthiru]

@phoddie Thank you. Yes, I did notice the first one but I didn't see how that manifest was being included in the build process. If I execute mcconfig from examples/drivers/lora/, that example's manifest only includes /examples/manifest_base.json, and when I followed the chain downwards, there was no connection with esp32/heltec_lora_32's manifest. I thought that the build target's manifest may be listed in the platforms.includes property of modules\io\manifests\esp32\manifest.json but there is only the modules property in the platforms object, which references the provider but not the manifest.

Ok, I found the link in examples\manifest_base.json

[phoddie]

Yes, exactly. That's why every host build eventually needs to include manifest_base.json, as that's what pulls in the core platform specific modules, etc.