Message Caching historical note - unknown impact

[MichaelAtSamraksh]

Before commit 'Fixed deployment problems' 5192e45e8d526ec6150fc0a7112ac28c6b35b317 on June 3, 2014, every debugger message was cached except the Debugger_Discovery message, raw messages, Debugging_Execution_ChangeConditions message, StopOnBreakPoint message, and the Diagnostics info messages. But this commit turns off caching for all messages without explicitly stating why. I think the message caching was supposed to help debugging by keeping track of commands and replies; when a command timed out it would be re-sent; when a reply was received the command would be removed off of the stack. By never caching any message, we may have affected the reliability of debugger communication. The caching affected heap usage; I am not sure if there was a TTL mechanism that deleted forgotten messages. But disabling message caching makes a lot of dead code. Caching could help our COMM reliability. Caching also probably slightly hurt our performance because it tagged each message with the system time by calling [1]Time_GetMachineTime()-->[2]g_TimeDriver.GetMachineTime()-->[3]HAL_Time_CurrentTime() -->[4]g_Time_Driver.CurrentTime()-->[5]CurrentTicks()-->[6]VirtTimer_GetTicks(VIRT_TIMER_TIME)-->[7]CPU_Timer_CurrentTicks((UINT16)g_HardwareTimerIDs[mapperId])-->[8]g_Timer16Bit_Driver.GetCounter(g_Timer16Bit_Driver.c_SystemTimer)-->[9]TIM_GetCounter(TIM2) That is a long call sequence that might affect performance on every message; the regular STM32 port only has a call depth of 3 or 4 calls to compute Time_GetMachineTime().

So the act of disabling message caching may have saved some heap space and processor performance, but it also may have introduced unknown reliability issues that we may have since fixed by other work-arounds.

[ChrisAtSamraksh]

are you referring to: https://github.com/Samraksh/MF/commit/5192e45e8d526ec6150fc0a7112ac28c6b35b317#diff-4c92d59b268ad3c0b61e743b4dffbb22R193 return messaging->TransmitMessage( msg, false );

[MichaelAtSamraksh]

Yes, changing TransmitMessage function call's second argument from true to false effectively turned off message queueing/caching. Debugger messages use a two-part command and reply structure. There could be positive and negative aspects to turning off message caching. I have not investigated and I am not aware of any asynchronous calls that would need a queue. If we want to providing messaging over an unreliable medium (e.g. visual studio debugging over wireless), we might want to try re-enabling message caching/queueing at a future date, so I posted the note.