Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
EbMonitor stopped working
My confidence is increasing that the problem is in EbMonitor and not in FreeRTOS. The following observations are supporting that.

In the algorithm the printf statements are used, add the following line

while(EBmonitor_kbhit() == 0);

When executing the code, the algorithm stops until something is entered on the EbMonitor console. After that everything works OK. Without that line, the EbMonitor causes a system crash.

Another strange observation. If something is entered on EbMonitor after EbMonitor buffer setups but before the algorithm starts, the system crashes in the same way as without this line.

PS. The other part of my workaround is to use delays to avoid buffer overruns. In other words, after every printf line, there is a 400 ms delay for that purpose. I did try with 300 ms delay, but it didn't work.
Cheers, Ollie
I am embarrassed to admit that - again - the problem was in my application and not in EbMonitor nor FreeRTOS. I had not allocated enough stack space for the formatting operations done in printf. OK, now I am a little bit more experienced and perhaps even wiser.
Cheers, Ollie
Once again, the physical interface can not work with several tasks simultaneously without their sharing by access.
If you are too lazy to allocate your time to differentiate access - then this can be done once in the very function of physics. To do this, the print function must be wrapped in the access control function. The algorithm is very simple - the first time the task number is read, and stored in the internal variable of the access algorithm. After data transfer is performed, zero is written to this static variable. In the case when there is a simultaneous call of a function from another thread, you will have to wait for zero in this variable, and only then transfer the data further to the print function. Simultaneous calling under such conditions will expect a free access window, but not a fixed waiting time like you.

The access function, as well as the print function that will use it - can be run from different tasks. In this case, the conflict does not happen. This is an old cheap trick, it is in a lot of examples. It's very strange that you do not know anything about him.
It is advisable to add to the demarcation function - print the task number. Then it will be easier to read the log.

Forum Jump:

Users browsing this thread: 1 Guest(s)