Page Comparison

...

Implementors may also consider lazy blocking. For example, after writing data to a non-volatile memory the memory usually goes into a busy state for a period during which it cannot accept new writes. Instead of writing and immediately blocking waiting for the write to complete the CWPortExeFileWrite() function should return without blocking. The next time the CWPortExeFileWrite()  function is called it can block conditionally only if the write operation is still in progress. Deferring the memory busy check can increase file throughput considerably.

...

Pseudocode Example

This example code is from the Windows port of the CWL.

...

Bool CWPortGetInboundFileWriteBuf (uint8_t** buf, uint16_t *bufSize)
{

    static uint8_t ftBuf[CWMSGCMD_FT_MAX_SIZE];

    CW_REQUIRE(buf != NULL);

    CW_REQUIRE(bufSize != NULL);

    *buf = ftBuf;

    *bufSize = sizeof(ftBuf);

    CW_ENSURE(*buf != NULL);

    CW_ENSURE(*bufSize >= CWMSGCMD_FT_MAX_SIZE);

    return true;

}

bool CWPortExeFileWrite (int8_t* fileStr, uint32_t offset, uint8_t* data, uint16_t dataLen)
{
    CW_REQUIRE(fileStr != NULL);
    CW_REQUIRE(data != NULL);

    CW_REQUIRE(dataLen <= CWMSGCMD_FT_MAX_SIZE);

    if (offset == 0)
    {

        if (fpWrite != NULL) fclose(fpWrite); /* Close open files */

        CW_ASSERT((fpWrite = _fsopen(fileStr, "wb+", _SH_DENYNO)) != NULL);

    }

    CW_ASSERT(fwrite(data, 1, dataLen, fpWrite) == dataLen);

    if ((dataLen < CWMSGCMD_FT_MAX_SIZE) && (fpWrite != NULL))
       { fclose(fpWrite);}

    return true;

}

...

Common Problems

1. OKE implementation expects a hardcoded file name and file uploaded to OKC doesn’t match:
   It’s commonly seen that developers hard code an expected file name for certain file types, e.g. firmware.bin, menu.json. If someone subsequently uploads a file to the OKC with a different name (e.g. firmwareV1-2-3.bin), the file will be downloaded to the OKE (and indeed the status shown in Open Kitchen will be ‘downloaded’), but it isn’t loaded into the system because of the name mismatch. We recommend avoiding this approach and to instead encode identifiable information in the file header. If not avoidable, then ensure the file uploaded to the OKC is correctly named

2. Old CWM firmware and/or CWL version: In CWM1 firmware earlier than PIC154/SPH145 and ConnectWare Library versions < 1.0.15, there was a bug in the fragmentation layer that caused messages of certain lengths to be dropped. This can cause a multitude of issues including download rewinds due to dropped fragments (ultimately ended in an aborted download), and files that do ‘successfully' download to the CWM but aren’t loaded into the OKE. If you encounter such issues, please ensure your CWM firmware and CWL versions are up to date.

3. File name + extension longer than 16 characters: the OKC now prevents this from happening, but it may still be possible to do with the simulators. The CWL has a 16 character limit on the file name including the extension. If this limit is exceeded, the CWM will download the fragments from the OKC but just throw them away. Please ensure file names are <= 16 characters including extension.

4. File Name + Version + Account ID not unique combination: Currently, there is a unique index in Open Kitchen Database that requires a combination of File Name - Version - Account ID to be unique even the uploaded file has been deleted. If Version does not have value entered by user, it will have timestamp value. However, user can enter Version for it to be used to match with equipment data for file transfer status. If this is the case, it may cause violation of unique File Name + Version + Account ID combo key. In this scenario, if a firmware file needs to be uploaded from the same Account, it needs to have unique File Name and Version (if input by user) every time it is uploaded even after it is deleted from Open Kitchen.