Strange error when generating C code from Simulink

When I tried to generate code from a recently updated Simulink model, I got "index exceeds the number of array elements. Index must not exceed 0". This error happened only during code generation, not when running the model. After spending a day, I found out that the reason was forgetting the folder separator "\" in an entry in Model Configuration Parameters > Code Generation > Custom Code > Source Code list, i.e. instead of "abc\file.cpp" the entry was "abcfile.cpp". A very unhelpful error message for such a simple error... A better error message would be "could not find file abcfile.cpp".

By the way, you can generate code from the MATLAB command line with slbuild('your_model_name').

Another error is "Invalid setting for input port dimensions of ...". If you are sure that there is no problem with port dimensions, close MATLAB, delete existing .mexw64 files, open MATLAB and regenerate them.

Finding root cause of latencies

A common issue in real-time hardware-in-the-loop simulations is latency in components that run on separate computers. These latencies can significantly degrade system performance. To differentiate between delays in component operations and network latency, you can send timestamps along with the data, log the time at reception, and record both timestamps:

Since components A and B have different clocks, you cannot directly compare the send and receive times. However, you can calculate the differences separately. If diff(timeSend) == diff(timeReceive), the latencies are likely not due to network congestion or a faulty switch/NIC but rather to delays in the operation of component A. It is highly unlikely for time differences to be the same if there is a problem with the network, it could only happen if the network was always adding a constant delay for each packet transmission.

Of course, you should perform the file saving in a separate thread to prevent blocking other operations. To minimize disk access, write to the log file periodically, for example, by flushing the log buffer to the file once per second.

Handling long operations in observer chains

If you have lengthy observer notification chains where observers notify other observers, making the trigger order unpredictable, and these chains include time-consuming operations like updating a map drawing, you can use the following approach to only update the drawing when the last observer in the chain is reached:

chatGPT 4o vs o1-preview

I normally use chatGPT 4o because it is much faster than o1-preview. Today I asked 4o the following:

Write a function that performs the following 2 byte hex to 2 byte signed int transformations:
0x801D --> -29
0x811D --> -285
0x821D --> -541
0xFF1D --> -32541
0x001D --> 29
0xAA1D --> -10781
0x101D --> 4125

It wrote a function that resulted in the following, mostly wrong, output:

-32739
-32483
-32227
-227
29
-21987
4125

I fed this output back, and it apologized and rewrote something slightly different, but the output was still wrong. I repeated the steps, and I got responses like 'I see the issue more clearly now' and 'Thank you for your patience,' but the output remained incorrect. When I fed the same prompt to o1-preview, it solved the problem in a single iteration. Here is the final python function (sign-magnitude representation):

def hex_to_signed_int(N):
    isNegative = N & 0x8000 # equivalent to "N >= 0x8000"
                            # 0x8000=1000 0000 0000 0000
    if isNegative:
        magnitude = N & 0x7FFF # 0x7FFF=0111 1111 1111 1111
        return -magnitude
    else:
        return N

test_values = [0x801D, 0x811D, 0x821D, 0xFF1D, 0x001D, 0xAA1D, 0x101D]

for val in test_values:
    print(f"0x{val:04X} --> {val:05} --> {hex_to_signed_int(val)}")

Using code from Simulink model in HIL

Steps of converting a Simulink model to code usable in Hardware-in-the-loop (HIL) simulation:

1. Checkout/pull Simulink model from repository to your local.
2. Run Simulink model and confirm it finishes as expected. If not, inform the model maintainer and ask them to commit/push the model with correct settings to repo. 
3. Confirm that C/C++ code can be generated from model. Sometimes an s-function build file (mexw64) exists but its source code is missing, which allows the model to run but prevents code generation.
4. Copy code to Visual Studio and verify that you can build and run it. There are cases where Simulink is more forgiving of errors like uninitialized variables, or missing #include <cmath> but Visual Studio cannot build the code.
5. Copy code to real time Linux PC and verify code can be build there too.
6. Commit code to its own repo.
7. Run HIL with new code and verify HIL works as expected.

Why is file hash comparison faster than byte-wise comparison

Question: Since calculating the hash of a file requires reading every byte, why is comparing hashes of two files faster than byte wise comparison of file contents?

Answer: In hash comparison, each file's hash is computed once (by reading all its bytes), and then the two hashes, which are small fixed-size values (e.g., 256-bit or 512-bit), are compared. Comparing two hashes takes constant time, regardless of file size. In a byte-wise comparison, if there are N bytes, in the worst case where files are the same, N comparisons have to be made. 

• Hash comparison = reading file + 1 comparison.
• Byte-wise comparison = reading file + N comparisons.

LONG_MAX is different for Windows 64 and Linux 64

When you generate code with Simulink (MATLAB R2023b) using ert.tlc, the default OS is Windows 64, see Configuration Parameters - Hardware Implementation - Device type. When you generate C code, the <model name>_private.h file will contain checks for ULONG_MAX and LONG_MAX.

On 64-bit Windows, the long type is typically 32 bits, which causes the LONG_MAX to be 0x7FFFFFFF. On 64-bit Linux systems, the long type is typically 64 bits, i.e. LONG_MAX is 0x7FFFFFFFFFFFFFFF. When you use code generated with the Windows 64 setting and use that on a Linux 64 OS, the check in <model name>_private.h will fail. The solution is to use the Linux 64 setting in Simulink which removes the LONG_MAX check from header file.

This checks seem to have been added after MATLAB R2022b because code generated with R2022b does not have them.