About the Sedona Palette

When working with a Sedona app, the Sedona palette becomes available in the left-side nav bar pane. The palette provides “drag and drop” access to components in the kits available to the app.

NoteIf the Sedona Palette is not in the nav bar, from the Workbench menu select Window->SideBars->Sedona Palette. Note that the contents of the palette will be “Unavailable” if your Workbench view is not within the “App” itself—for example, when viewing the Sox Manager.

Figure 16. Sedona Palette provides access to components in kits


Sedona Palette provides access to components in kits

Click the drop-down control to see the kits available for selection, as shown in Figure 16. Some of the kits may contain as few as one (or even no) component, while others will have multiple components.

Memory usage

In brackets beside every component listed in a palette is the number of bytes of memory [n] consumed by each instance of it, say when copied (dragged into) an app.

Relative to other Sedona platforms, the Sedona (Jennic) Module platform has a small amount of available memory space for apps, including kits and scode. Keep this in mind when developing for this platform.

  • Note the JennicPlatform component (from jennic kit) provides a read-only “memAvailable” slot that lists the currently available amount of memory, in bytes. In the standard demo app, see this value by expanding the app’s service folder and double-clicking on the plat named node, to display its property sheet view. The “Mem Available” value shows available bytes.

  • Also, when working with a Sedona (Jennic) Module platform such as the Dev Board, note that memory freed by deleting components is not available until after you restart the node.

Naming rules

Related to memory constraints, Sedona components have a 7-character maximum name limit, using only alphanumeric (A-Z, a-z, 0-9) and underscore (_) characters. Spaces and other punctuation are not permitted. When adding a new component, the popup Name dialog enforces this limit.

  • The first character in a name must be a letter.

  • Name must be unique for every component within the same parent container. Workbench automatically enforces this rule, say when duplicating copies of the same component, by imposing unique numeral(s) at the end of each component name.

  • Naming is case-sensitive—for example, Door_1 and door_1 are unique names.

Exploring kits in the Sedona Palette

A few of the more interesting palettes for early exploration among Sedona kits include the following:

  • sys — Components common to most apps. Several are used only once; others are often replicated.

  • basicio — Components to interface to I/O points of the SED-M0x module/dev board.

  • dbDemo — Components to interface to I/O points of the SED-M0x module/dev board.

sys

As shown in Figure 17, this contains several component types, briefly described below the figure.

Figure 17. Palette for sys contains common system components


Palette for sys contains common system components

  • App — Top level container for the entire app, holds the app name and scan period.

  • Component — Base class for all Sedona components, it has no practical application as-is.

  • Folder — Container to organize groups of child components, has a default “wire sheet” view.

  • PlatformService — (JennicPlatform) Holds the node’s wireless network configuration (Panid, channel map, router operation) and other read-only status properties, including available memory.

  • Service — Base class for all Sedona services, it has no practical application as-is.

  • User — Represents an individual app user, implemented as child of the UserService. Properties define component and provisioning permissions, along with user login credentials (password).

  • UserService— Container for all User components, provides a Sedona User Manager view to adminster (add, change, delete) individual Users.

NoteTypically, only the Folder component is useful from the sys palette when working in a demo app. This is so because each demo app already includes the one-only App and “services” components (PlatformService, UserService, found in the service folder), along with a default User “admin” under the UserService.

basicio

As shown in Figure 18, this contains several component types, briefly described below.

Figure 18. Palette for basicio contains components to interface to I/O points


Palette for basicio contains components to interface to I/O points

  • Adc — Each provides an interface to one of the four analog inputs (ADC) of the SED-M0x module.

  • AdcScanService — Must be copied into an app’s service folder to provide continuous updates of analog inputs (ADC points). If an app does not use Adc components, it is not required.

  • Dac — Each provides an interface to one of the two analog outputs (DAC) of the SED-M0x module.

  • DioIn — Each provides an interface to one of the digital inputs of the SED-M0x module. On the dev board, these correspond to pushbutton switches SW1 and SW2.

  • DioOut — Each provides an interface to one of the digital outputs of the SED-M0x module. On the dev board, these correspond to the four relay outputs (1 - 4) as well as LEDs D1 - D4.

Each basicio component has one or more properties that define which IO point (address) and often items that affect the component’s value.

dbDemo

As shown in Figure 19, this contains various component types, briefly described below.

Figure 19. Palette for dbDemo contains a variety of components


Palette for dbDemo contains a variety of components

  • And2 — A logic AND gate for boolean states (True, False) at two boolean type inputs.

  • B2P — Boolean “to pulse” conversion of single boolean input, upon False-to-True transition.

  • ConstBool — Provides a boolean out value, with right-click “Set” action to select either state.

  • ConstFloat — Provides a floating point out value, with right-click “Set” action to specify the value.

  • ConstInt — Provides an integer out value, with right-click “Set” action to specify the value.

  • Eeprom — Provides an example interface to the serial EEPROM on the dev board with actions to “write to” and “read from” the EEPROM, using a configurable memory start address.

  • F2I — Provides conversion for a floating point input to an integer output.

  • I2F — Provides conversion for an integer input to a floating point output.

  • IncDec — Provides a float value from transitions on two boolean “Inc” and “Dec” inputs, used in a specific demo app (jenDbDemo2).

  • LSeq4 — A linear sequencer for 4 boolean outputs based on received floating point input.

  • Not — A logic NOT gate to “flip” the boolean input state at the component’s out slot.

  • TickTock — Provides a boolean multivibrator with a configurable cycle period (ticks per second).

The “Const” named components provide a convenient way to link and test control logic to various other components, including output I/O types such as Dac and DioOut (found on the basicio palette).