Freemaster http IoT

[Bohrfutter]

Hello

I want to access a MCU with Freemaster over the internet. The MCU communicates via CAN bus with the Freemaster host application and is traveling in a "vehicle". I already managed to connect with a second WIN PC via the Freemaster Remote HTTP Server.

Now I want to use OpenWRT + CAN bus dongle + software to replace the second WIN PC. Unfortunately I can not find any documentation about the packing of the raw Freemaster CAN messages into the HTTP POST frame. Attached you can find a wireshark log and the output of the Freemaster Communication Debug Log.

The task is to implement the Freemaster Remote HTTP Server in linux (with limited resources / target system has OpenWrt 32MB ram & 16MB flash).

Hope someone from NXP can support this or someone can help me to analyse the translation from CAN messages to HTTP

Cheers

Sebastian

[MichalH]

Dear Sebastian,

this is also a response to your comment you made at the 3.0 release announcement. The FreeMASTER Lite and use of JSON-RPC is most likely the way for your use case to be supported.

I understand that you may find the FreeMASTER Lite still too heavy to run it in an embedded Linux system. We are considering a plan to create even lighter version suitable to run directly in the MCU with Ethernet or WiFi connectivity. Such a "micro" server would support the same JSON-RPC API as the Lite (and the desktop app) so it would be accessible directly on the network.

Let's use this community thread to see how much interest this idea gets among other users.

Thanks,

Michal

[Bohrfutter]

Hello Michal,

Your proposal looks like a long path - not sure if I have that amount of time .

In the mean while maybe you can give me a hint for the decoding of the freemaster http tunnel messages. I already know most of the bytes in the HTTP POST / HTTP OK communication which are relevant for the MCU - but what are the red bytes in POST and OK message? They are not forwarded to the MCU. The 03 could be the protocol version?

HTTP POST:

00 00 00 26 03 e0 00 04 c2 0c 00 20 00 01 00

HTTP OK:

00 00 00 00 00

Thank you in advance.

Best regards

Sebastian

[MichalH]

Dear Sebastian,

here are some details about the communication. Let me know if this is enough to get you going.

HTTP POST:

00 00 00 26 03 e0 00 04 c2 0c 00 20 00 01 00

• The first four bytes (00000026) are the "client ID" assigned by the server during OPENPORT call. The client uses this number to identify all subsequent SENDRECVPACKET frames.
• The 03 is an action code:

  #define MCBHTTP_FNUM_IDENTIFY 0x00
  #define MCBHTTP_FNUM_OPENPORT 0x01
  #define MCBHTTP_FNUM_CLOSEPORT 0x02
  #define MCBHTTP_FNUM_SENDRECVPACKET 0x03
  #define MCBHTTP_FNUM_LOCKFEATURE 0x04
  #define MCBHTTP_FNUM_UNLOCKFEATURE 0x05

• The purple part is the command payload - this is passed to the board (or encapsulated to a nested protocol by the server).
• The 00 01 is the expected response length (the old protocol does not support variable-length responses, so the sender/caller must provide this information to transport layer).
• The last 00 is the feature id (00 = no feature). 

  #define MCB_FEATURE_SCOPE 0x01
  #define MCB_FEATURE_REC 0x02
  #define MCB_FEATURE_APPCMD 0x03
  #define MCB_FEATURE_FPROG 0x04
  #define MCB_FEATURE_SFIO 0x05
  #define MCB_FEATURE_PIPES 0x06

The server will only pass the feature-specific frames to the target if the feature has been locked before by this client. This feature locking is needed to prevent e.g. two clients to compete for a resource which needs locking. Plain reading variable is atomic so it does not need the lock. But e.g. Oscilloscope needs multiple frames so the access needs to be locked for one client exclusively. 

HTTP OK:

00 00 00 00 00

• The first four bytes (00000000) is the status code (MSB bit signals success/failure)
• The last 00 is the expected 1 byte of command response.