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
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.
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?
00 00 00 26 03 e0 00 04 c2 0c 00 20 00 01 00
00 00 00 00 00
Thank you in advance.
#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
#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.