You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you are using Ethernet, the Moddable SDK runtime automatically attempts to connect when launched, before your scripts are run.
365
364
366
-
When using Wi-Fi and Ethernet, both will use NTP to set the device clock, if it has not already been set, immediately after connecting. This is essential for secure network communication using TLS.
365
+
When using Wi-Fi and Ethernet, both set the device clock via NTP immediately after connecting. This is essential for secure network communication using TLS. If your device sets the time some other way, such as a Real-Time Clock peripheral, NTP clock synchronization is not done.
366
+
367
+
### Storage – Files, Key-Value Store, and Flash
368
+
369
+
@@
367
370
368
371
### Displays
369
372
If your project uses a display, typically by including `manifest_piu.json` or `manifest_commodetto.json`, the `mcdevicetree` tool automatically creates a `Screen` global for the board's display driver, if any. This allows the Piu user interface framework and Commodetto's Poco renderer to access the screen. For boards with multiple displays, the display specified in the `chosen` section of the device tree is used.
370
373
371
374
### TypeScript
372
-
Because the `device` global is different for every Zephyr board, a single TypeScript declarations file cannot precisely define the board. Instead, `mcdevicetree` generates a TypeScript declaration (a `.d.ts`file) for the board. This is automatically used when building TypeScript code for Zephyr, ensuring that your code is correctly accessing only the hardware available on your development board.
375
+
The `device` global is different for every Zephyr board, because every board has unique hardware capabiliites and confirmations. As a result, a universal TypeScript declarations file (a `.d.ts` file) cannot precisely define the `device` global for any single build. Instead, `mcdevicetree` generates the TypeScript declarations file for the board. These declarations are automatically used when building TypeScript code for Zephyr, ensuring that your code accesses only the hardware available on your development board.
373
376
374
377
<aid="debugging-native-code"></a>
375
378
## Debugging Native Code
@@ -434,46 +437,76 @@ Moddable uses .overlay files specified in the `zephyrOverlay` section of `manife
434
437
435
438
The Nordic [`nrf52840dk` device](../../build/devices/zephyr/targets/nrf52840dk/manifest.json) device manifest demonstrates:
436
439
437
-
"zephyrOverlay": [
438
-
"./analog.overlay",
439
-
"./pwm.overlay"
440
-
],
440
+
```jsonc
441
+
"zephyrOverlay": [
442
+
"./analog.overlay",
443
+
"./pwm.overlay"
444
+
],
445
+
```
441
446
442
447
### `analog`
443
448
444
449
Use `port` and `channel` to choose which analog channel to sample from. Different devices may use a different port naming schemes.
445
450
446
-
const analogInput = new device.io.Analog({
447
-
port: "adc",
448
-
channel: 0
449
-
});
451
+
```js
452
+
constanalogInput=newdevice.io.Analog({
453
+
port:"adc",
454
+
channel:0
455
+
});
456
+
```
450
457
451
458
### `digital`
452
459
453
460
Use an object with `port` and `pin` to describe the pin of a Digital object.
454
461
455
-
const led = new device.io.Digital({
456
-
...options,
457
-
pin: {port: "gpioe", pin: 1},
458
-
mode: Digital.Output,
459
-
});
462
+
```js
463
+
constled=newdevice.io.Digital({
464
+
...options,
465
+
pin: {port:"gpioe", pin:1},
466
+
mode:Digital.Output,
467
+
});
468
+
```
460
469
461
470
### `pwm`
462
471
463
472
Use `port` and `channel` to specify what zephyr configuration to use. You can also specify the frequncy by the `hz` property, and resolution (in number of bits) with the `resolution` property.
464
473
465
-
const led1 = new device.io.PWM({
466
-
port: "pwm0",
467
-
hz: "100",
468
-
resolution: "10",
469
-
channel: "0"
470
-
});
474
+
```js
475
+
constled1=newdevice.io.PWM({
476
+
port:"pwm0",
477
+
hz:"100",
478
+
resolution:"10",
479
+
channel:"0"
480
+
});
481
+
```
471
482
472
483
### `display`
473
-
474
484
Zephyr display configuration are found in shield definition files. For example, the `stm32u5a9j_dk` target's [`manifest.json`](../../build/devices/zephyr/targets/stm32u5a9j_dk/manifest.json) contains:
475
485
476
-
"zephyrShields": [
477
-
"st_lcd_dsi_mb1835"
478
-
],
486
+
```jsonc
487
+
"zephyrShields": [
488
+
"st_lcd_dsi_mb1835"
489
+
],
490
+
```
491
+
492
+
### `flash`
493
+
To access flash memory partitions, include the ECMA-419 flash module manifest `$MODDABLE/modules/io/flash/manifest.json` in your project's manifest. That creates the `device.flash.open` function to access flash partitions by name:
To access a file system, include the ECMA-419 file module manifest `$MODDABLE/modules/io/files/manifest.json` in your project's manifest. That creates the `device.files` property to access the file system. Your Zephyr Device Tree must have a valid file system defined in the Zephyr Device Tree at `root.children.fstab`.
To access the Zephyr key-value pair store (settings), include the ECMA-419 storage module manifest `$MODDABLE/modules/io/storage/manifest.json` in your project's manifest. That creates the `device.keyValue.open` function to access the key-value store. Your Zephyr Device Tree must have a valid settings subsystem defined in the Zephyr Device Tree.
0 commit comments