HardFault handler M0 Опции

[toweroff]

Вот такая вот возникла потребность...
для M3 есть, когда-то давно был сделан, но для M0 не подходит
Хоть посмотреть, откуда вылетели...
Смотрел тырнеты всякие, только что-то оформленное для того же M3 и M4

Есть что-то простое, хоть PC посмотреть

[firew0rker]

Посмотрите значение указателя p_CB.

[toweroff]

Посмотрите значение указателя p_CB.

0x00000001

[Сергей Борщ]

0x00000001

И что вы ожидатете получить с таким указателем? Мало того, что он указывает на вектора прерываний, так еще и невыровнен (из-за этого и исключение). В общем ищите, откуда в него попадает такое дивное число.

[toweroff]

В общем ищите, откуда в него попадает такое дивное число.

Интересно, что вызов этой функции происходит один раз, но сразу в яблочко

Кстати, попутно вот такой вопрос:
Есть функция, через которую в юарт валится отладочная информация. Вызывать может кто угодно. Чем ее правильнее закрывать, бинарным семафором или мьютексом? По сути тоже самое

[MoskWin32]

Чем ее правильнее закрывать, бинарным семафором или мьютексом?

Как альтернатива для функции потокобезопасного вывода - блокировка планировщика(на примере FreeRTOS):

Код

void vPrintString( const char *pcString )
{
    /* Print the string, suspending the scheduler as method of mutual
    exclusion. */
    vTaskSuspendAll();
    {
        sprintf( cBuffer, "%s", pcString );
        consoleprint( cBuffer );
    }
    xTaskResumeAll();
}

[jcxz]

Как альтернатива для функции потокобезопасного вывода - блокировка планировщика(на примере FreeRTOS):
...
consoleprint( cBuffer );

...и убивается весь смысл многозадачности. Выполнение превращается в суперцикл.
Это даже уже не говоря о том что лесом идут все приоритеты задач.
Если так пишете - значит Вы не поняли зачем вообще нужна многозадачная ОС.

[MoskWin32]

...и убивается весь смысл многозадачности. Выполнение превращается в суперцикл.

Я понимаю, конечно на время вывода сообщения система "стопорится". Я использую это только для отладки чего-либо, в местах под макросом #ifdef _DEBUG_ANYTHING.
В рабочем приложении такого конечно нет.
Функция взята из учебника "FreeRTOS на Cortex-M3". Не такой уж и бред, если понимать, в каком контексте её можно использовать.

[jcxz]

Я понимаю, конечно на время вывода сообщения система "стопорится". Я использую это только для отладки чего-либо, в местах под макросом #ifdef _DEBUG_ANYTHING.
В рабочем приложении такого конечно нет.
Функция взята из учебника "FreeRTOS на Cortex-M3". Не такой уж и бред, если понимать, в каком контексте её можно использовать.

Один из главных плюсов использования ОС это: полезное использование времени процессора во время выполнения операций ввода/вывода.
Т.е. - например когда одна задача, как у вас, ждёт готовности FIFO UART-а принять очередной передаваемый байт, другая в этой время получает время CPU и выполняет полезную работу.
В суперцикле это невозможно, аналогично как и в приведённом Вами куске кода.
Плюс также - время реакции критичных по времени сервисов существенно меньше суперцикла. А у Вас, при выводе чего-то существенного в порт таким способом, все такие сервисы будут в пролёте.
Использовать такое для отладки тоже не имеет смысла, так как, при включении такой отладки, поведение программы сильно меняется (работа перестаёт быть многозадачной) и соответственно результаты отладки бессмысленны (отлаживается совсем не то ПО, которое нужно).
Если нужно корректное разделение ресурса (буфера вывода UART), то самое правильное - использовать семафор.
Можно использовать и запрет прерываний или запрет шедулера, но только на время вывода в программный буфер UART, а не на время вывода в IO-порт UART.

[MoskWin32]

jcxz, спасибо за разъяснение. Я все это понимаю, и полностью согласен.
Но если 1 тик шедулера = 1 мс, то на 115200бод/с можно успеть передать 11 символов. Если это будут сообщения типа "PING:ok" или "timeout", то ничего ведь страшного не случится?
Т.е. 1-2 тика не такой уж и криминал в этом случае? Все зависит от требований к времени реакции, конечно.
К тому же прерывания не запрещаются при блокировке шедулера и в некотором смысле многозадачность сохраняется.
По поводу защиты буфера - тогда нужно гарантировать, что все операции через UART для всех задач будут организованы только через него.
Ладно, это всё - скорее мои нелепые попытки оправдаться, знаю

Сообщение отредактировал MoskWin32 - Mar 3 2017, 17:10

[zltigo]

Но если 1 тик шедулера = 1 мс, то на 115200бод/с можно успеть передать 11 символов.

Много больше, если для передачи используется буфер, то сброс вывода в буфер просходит на порядки быстрее, чем вывод в нефифофированный порт.
Ну а за такой вывод через промежуточный буфер:

Код

sprintf( cBuffer, "%s", pcString );
        consoleprint( cBuffer );

Надо лишать права писать учебники пожизненно.