As reported by @MemphisCZ in #6:
One more suggestion about fflush(0);, in some multitask FREERTOS application this may cause task dead lock, flushing NULL pointer means flush everything. In such OS some kind of opened file descriptors could be just input streams waiting for input data and already locked with their recursive lock. Flush from different task will be waiting for ever until first task will receive something and releases the lock. Would be better to use fflush(stdout); in libswd_memap.c line 270,314,470,505,683,724,875,909. :-]
flushing each time for log output will drastically slow down the logging. Stdout for frequent flush slow as hell, as it will call OS kernel rutins. Would be better to delete it from library as user of that library can set up his stdout with something like:
setvbuf(stdout, NULL, _IONBF, 0);
this will ensure that all log messages will be outputted immediately if he needs this. Or he can use fflush himself in app region.
As reported by @MemphisCZ in #6:
One more suggestion about fflush(0);, in some multitask FREERTOS application this may cause task dead lock, flushing NULL pointer means flush everything. In such OS some kind of opened file descriptors could be just input streams waiting for input data and already locked with their recursive lock. Flush from different task will be waiting for ever until first task will receive something and releases the lock. Would be better to use fflush(stdout); in libswd_memap.c line 270,314,470,505,683,724,875,909. :-]
flushing each time for log output will drastically slow down the logging. Stdout for frequent flush slow as hell, as it will call OS kernel rutins. Would be better to delete it from library as user of that library can set up his stdout with something like:
setvbuf(stdout, NULL, _IONBF, 0);
this will ensure that all log messages will be outputted immediately if he needs this. Or he can use fflush himself in app region.