Page Comparison

There are no minimum OS requirements. It is adaptable to any bare metal, RTOS, or Linux OS environment. The CWL does not directly use dynamic memory and does not directly rely on any OS task synchronization primitives.

Linux Port

The default port of the CWL is for Windows, which can be built and debugged using Visual Studio for implementors who want to experiment before starting their port.

A Linux port of the OKE simulator is available as well. To build the Linux port change directory to _OpenKitchenEquipment_OKE and run the _OpenKitchenEquipment_OKE.sh build script. The oke simulator will be created by the build process. Running the oke simulator is the same as running and using the Windows oke.exe simulator. See the Simulation section later in the document for information on how to run the oke and oke.exe simulators.

Linux versions of the CWM and OKC simulators are not available at this time. However, it is possible to run the CWM and OKC simulators on Windows and connect to the Linux oke simulator via a serial connection.

void CWPortExeReset(void);

The CWPortExeReset() function must force a full warm start of the OKE controller. The function must ensure that the serial transmit software and hardware buffers are empty before resetting. This function should not return to the caller.

It is strongly recommended that the reset function call the CW_ERROR() macro to force the reset. If the assertion handler is implemented to log the assertion, then the cause of the reset will be traceable to a deliberately commanded action rather than a spurious problem.

MSP430 Pseudocode Example

In this example port to an MSP430 platform, the CWPortExeReset() function first waits for the transmit software queue to empty, then waits 10ms for the hardware buffers to finish transmitting on the wire. Finally, an assertion is forced. The assertion handler ensures the file and line number is logged and then performs a warm reset.

Void CWPortExeReset(void)
{
    while (TxDataQueueIsEmpty() == false);
    DelayMs(10);
    CW_ERROR();
}

bool CWPortGetVersion(uint8_t index, int8_t **typeStr, int8_t **fwverStr, int8_t **hwrevStr) ;

The CWPortGetVersion() function returns platform type, software/firmware version, and hardware revision information about the OKE. The function allows the CWL to sequentially read zero or more sets of version information about the platform so that it can be reported to the OKC.

This means it is possible for a controller running the CWL to report versions for multiple components of the system. This is particularly important so the OKC can determine if firmware updates must be applied. Even when a component is not in-system upgradeable, having an inventory of the versions is critical for remote asset management. So, when in doubt report the version information of as much of the OKE system as possible.

The CWL reports version information to the OKC automatically, and calls the CWPortGetVersion() to fetch the versions. The CWL will call the CWPortGetVersion() in a loop initially passing an index of 0. If there is version information for index 0, which should always be the case, then the CWPortGetVersion() will set the parameter pointers to static strings for the type, firmware, and hardware NULL terminated strings, and then return true. It is important that the string buffers are not on the stack frame of the CWPortGetVersion() function, since they must be accessible after the function returns. Next the CWL will invoke CWPortGetVersion() again with an index of 1. If there are additional versions to report then the pointers will be updated and the function will return true, then the CWL will then ask for index 2. Else the function will return false and the CWL will know that no more version information is available. When CWPortGetVersion() returns true, all of the pointers must point to a valid NULL terminated string.

The type, software/firmware version, and hardware revisions are NULL terminated strings. The CWL does not impose any restrictions on the format of any of the version strings. However, it is recommended that implementors consider how the version information will be handled by the OKC. The goal is for the OKC to reliably detect what version is running and initiate configured firmware updates. This means the type and firmware version strings should be unambiguous and consistent across versions. In some cases, the hardware revision of a component may not be known, in this case a pointer to an empty string "" should be returned.

Pseudocode Example

In this example code the CWPortGetVersion() function returns two sets of version information. The first time the CWL calls the function with an index of 0, *typeStr is set to point to "TCHEF", *fwverStr is set to point to "1.3.42", and hwrevStr is set to point to "A1", and true is returned. The second time the CWL calls the function with an index of 1, *typeStr is set to point to "TCAB", *fwverStr is set to point to "4.2.c1", and hwrevStr is set to point to "REV3", and true is returned. The last time the CWL calls the function it returns false.

Bool CWPortGetVersion(uint8_t index, int8_t** typeStr, int8_t** fwverStr, int8_t** hwrevStr) 
{
    static const int8_t *type[] = {"TCHEF","TCAB"} ;
    static const int8_t *fwver[] = {"1.3.42","4.2.c1"} ;
    static const int8_t *hwrev[] = {"A1","REV3"} ;

    CW_REQUIRE(typeStr != NULL);
    CW_REQUIRE(fwverStr != NULL);
    CW_REQUIRE(hwrevStr != NULL);

    /* There are only 2 versions to report */
    if (index >= 2) return false;

    *typeStr = (int8_t *) type[index];
    *fwverStr = (int8_t *) fwver[index];
    *hwrevStr = (int8_t *) hwrev[index];

    CW_ENSURE(*typeStr != NULL);
    CW_ENSURE(*fwverStr != NULL);
    CW_ENSURE(*hwrevStr != NULL);

    return true;
}