RTOS for Web Service

[BTaylor]

I am working on a commercial project with a custom board responsible for monitoring a number of input channels (digital and analog).

The MCU on the board is a Kinetis K66.

I am looking for an RTOS+TCPIP stack (with no or low licensing costs) that will support exporting the capabilities of the board as a web service with a RESTful API. The core capabilities must also be exported via SNMP v2c.

Other requirements:

- SW updates via HTTP

- Filesystem over SD

- NTP client

Suggestions?

[mjbcswitzerland]

Hi Brandon

TCP/IPv4 and v6 on multiple networks and interfaces: http://www.utasker.com/docs/uTasker/uTaskerNetworking.pdf / http://www.utasker.com/docs/uTasker/uTaskerIPV6.PDF

Includes firmware update over HTTP PUT: http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf or http://www.utasker.com/docs/uTasker/uTasker_BM_Loader.pdf (with optional encryption)

Dynamic HTTP and AJAX: http://www.utasker.com/forum/index.php?topic=94.0 / http://www.utasker.com/forum/index.php?topic=604.msg2647#msg2647

File system integrates directly with FTP and HTTP (on SD card, internal flash, external SPI flash or USB memory stick) - http://www.utasker.com/docs/uTasker/uTasker_utFAT.PDF

SNTP and time protocol: http://www.utasker.com/docs/uTasker/uTaskerSNTP.pdf / http://www.utasker.com/docs/uTasker/uTasker_Time.pdf

SNMPv2 integrated with easy custom MIB configuration

Fully integrated solution, with simulation for simpler and more efficient development and testing. Low memory flash and RAM footprint (K66 can perform >1000 parallel HTTP operations). HTTP web server loader over TCP/IPv4 < 20k.

Options:
- Free open source on GUTHUB (link below)
- Free commercial (with more features such as security and MODBUS TCP, when no support is needed)
- Fully supported by developer of TCP/IP stack, USB stack, file system, OS and all drivers (with > 8 years of Kinetis experience on > 200 product developments in > 20 countries)

Regards

Mark

Complete Kinetis solutions for faster/more efficient professional needs, training and support: http://www.utasker.com/kinetis.html
i.MX RT project compatibility: http://www.utasker.com/iMX.html
Including FreeRTOS integration for all Kinetis parts

Kinetis K66:
- http://www.utasker.com/kinetis/TWR-K65F180M.html
- http://www.utasker.com/kinetis/FRDM-K66F.html
- http://www.utasker.com/kinetis/TEENSY_3.6.html

uTasker: supporting >1'000 registered Kinetis users get products faster and cheaper to market

Request Free emergency remote desk-top consulting at http://www.utasker.com/services.html

Open Source version at https://github.com/uTasker/uTasker-Kinetis

https://community.nxp.com/thread/512558
https://community.nxp.com/thread/352862
https://community.nxp.com/thread/498809

[BTaylor]

Thank you for your response, Mark. It looks like uTasker might be a good fit for my project. 

In performing our evaluation, we will be paying close attention to just how quickly we are able to get 'up and running' with uTasker on our custom PCB. To that end, is there any documentation (e.g. a porting guide) that describes the process for bringing up uTasker on a custom board?

Also...in developing our web service, we will need to be able to intercept and respond to HTTP POST, PUT, PATCH, and DELETE commands as well as to HTTP GET commands. Does your 'Dynamic HTTP and AJAX' support accommodate this?

Thank you.

[mjbcswitzerland]

Hi Brandon

For commercial users a custom board setup can be delivered - as explained here:
http://www.utasker.com/services.html
which ensures there is virtually no investment required for board/project bring-up as long as no HW issues are encountered.
The only potential complication tends to be when using a new Ethernet PHY type (there are various ones included and often the same one as found on eval boards are used, which are then no problem) but this is only minor since one just needs to check that any chip specific interrupt configurations and link status are adjusted.

There are otherwise some discussions about porting at http://www.utasker.com/forum/ and possibly something practical at the playlist: https://www.youtube.com/watch?v=kWNlsAoMly4&list=PLWKlVb_MqDQFZAulrUywU30v869JBYi9Q

Essentially however one does this:
1. Choose the closest existing board target (eg. FRDM_K66F) as reference. This can be pre-configured as required to get the application framework.
2. Now add a new board define (in config.h) - eg. MY_K66 and disable FRDM_K66F.
3. Search for FRDM_K66F in the project and do a copy past for each configuration (in config.h and app_hw_kinetis.h and potentially a couple of options in application reference code) and make these conditional on your own board define.
The advantage is also that you can build for the reference board or for your new board by switching between the two defines, which is useful when something doesn't work on the new board and you want to quickly check whether it does (still) on the reference.
4. Now you can build the same for your new target (even if you haven't yet adjusted anything) - as check that all is in place.
5. Then you go through the new sections to configure things like UART and MUX used for debug output, pinout for LEDS, which PHY is used (and its address), whether its link state is polled or uses an interrupt, whether the SD card is connected via SPI or SDHC, the clock speeds used, etc. etc.

The base config-code explains much of what is going on and points to some docs and videos in some places but it is not complicated and can usually be successfully completed within a couple of hours for a fairly complicated board - as noted above, commercial users with support can request a setup if preferred.

There is a video in the playlist showing how to create custom projects in the workspace which share the framework so that no custom HW code is required over multiple projects which is very advisable to avoid the need to manage multiple code bases.

The HTTP server has various options such as
    #define SUPPORT_HTTP_POST             // support file uploads using POST command
    #define RESTRICT_POST_CONTENT_TYPE    // filter allowed posting formats
    #if defined RESTRICT_POST_CONTENT_TYPE
        #define SUPPORT_POST_BINARY
        #define SUPPORT_POST_TEXT
        #define SUPPORT_POST_GIF
        #define SUPPORT_POST_BMP
        #define SUPPORT_POST_PNG
        #define SUPPORT_POST_JPG
        #define SUPPORT_POST_PDF
    #endif
  //#define VARIABLE_PAGE_AUTHENTICATION   // support authentication on a per page basis
    #define PLAIN_TEXT_POST                // allow posting parameters
  //#define HTTP_POST_DEFINES_PAGE         // return the user file as specified by the file name in a POST, rather than special uFile name
    #define SUPPORT_HTTP_CONTINUE          // respond to Expect: 100-continue to start a posting sequence without any delay (useful when working with cURL)
    #define X_WWW_FORM_URLENCODED          // this encoding is also understood as plain text post (used in addition to PLAIN_TEXT_POST)
    #define AUTO_ASCII_PLAIN_TEXT_DECODE   // automatically decode any ASCII characters send as "%xx" - this require '%' to be avoided in post content! (suggested for use with Chrome)
    #define SUPPORT_HTTP_POST_TO_APPLICATION  // allow application to handle posted data rather than always saving to file

so GET and POST are often used (post can automatically save content to files or be parsed via the application call-back for interpretation (for form handling, for example, and which is used by the HTTP POST firmware update interface, as further example).

PUT hasn't been used but I think it just needs to be recognised by the "PUT" string rather than the "POST" string and can then be passed to the application using
fnHandleWeb(PUTTING_DATA_TO_APP, (CHAR *)ucIp_Data, http_session);
rather than
fnHandleWeb(POSTING_DATA_TO_APP, (CHAR *)ucIp_Data, http_session);
If I understand correctly the main difference is that a PUT is used to create/replace an existing file (if used for file transfer) rather than create/add to (the exact behaviour can however be controlled)

DELETE has also not been used before but in a similar fashion its string recognition would allow
fnHandleWeb(DELETING_DATA_TO_APP, (CHAR *)ucIp_Data, http_session); to be called or else a direct file system delete to be triggered.

I know less about PATCH but the recognition is equivalent, although I understand it may not include the full header but thereafter behaves as a PUT.

What is normally done is to record a reference transfer using Wireshark and then play that back through the uTasker simulator (which can load and interact with such recordings off-line to allow analysis) to verify the present behavior and any new recognition build in to verify its suitability. In the worst case user code can do the handling but I expect it will be fairly straight forward to add it in the HTTP server itself.
If you have a reference for the transfers needed you can post such a recording so that I can give a concrete answer. All parts of the project are continuously being extended so such methods can usually be added at short notice in case of such requirements.

Regards

Mark