Портятся данные в очереди

Всем привет.
Программа работает с UART на прерываниях.
Возникла проблема. Через не определённый промежуток времени, в очереди не передачу меняются данные на мусор.
При этом, из очереди в прерывании только чтение происходит.
Проводил эксперимент.
В прерывании, перед тем как прочитать из очереди, считываю все данные в буфер, а потом обратно заливаю.
И действительно, при чтении 1 символа, в очереди AT\r, при чтении 2 символа T<мусор> причём длина его разная.
По приёму такого безобразия нет. Там всё ОК.
Прямо и не знаю куда копать.
Может у кого есть какие мысли?
Буду рад любой.

0

Ваапервых, для работы в прерываниях есть "прерывательные" спец.фу-ции типа xQueueReceiveFromISR, надеюсь, вы именно ее используете или таки нет?

0

Сообщение от BusMostir Ваапервых, для работы в прерываниях есть "прерывательные" спец.фу-ции типа xQueueReceiveFromISR, надеюсь, вы именно ее используете или таки нет?

Да. Именно спец функции.
xQueueReceiveFromISR(Tx, &UART1TxBuf, &xHigherPriorityTaskWoken);
Вот что смущает.
Может такое быть, что созданную очередь надо ещё где-то объявить? Ну что это область памяти и всё такое. Потому как сильно похоже на то, что на место размещения очереди (на адреса где находятся данные) кто-то пишет.

0

Проверь все указатели, корректно ли обрабатываются. у меня такое было. не уследил за одним их указателей и случайно перетирал семафор. так что смотреть надо комплексно

0

При создании очереди, функция возвращает ее дескриптор. Он должен быть глобально объявлен и видим в вашей функции обработки прерывания.
Если у вас в эту очередь пишут несколько задач, защищайте доступ к записи очереди мьютексом, чтобы не получить данные внавалку.
При создании очереди, равно как и задачи, выделенная ей память защищена на уровне самой операционки от перезаписи. В ОЗУ выделяется блок адресов, состоящий из заголовка, блока контроля и управления и собственно стека с полезными данными. Сведения о занятом пространстве хранятся в блоке контроля и управления у каждой созданной задачи или очереди. Поэтому на уровне операционки эти данные защищены от взаимного влияния. Незащищенными остаются дескрипторы - определяемые пользователем переменные.

0

Заметил, что когда создаёшь очередь длиной 32 байта - всё работает
Но если 64 - уже нет.

0

Сообщение от ShiMox Проверь все указатели, корректно ли обрабатываются. у меня такое было. не уследил за одним их указателей и случайно перетирал семафор. так что смотреть надо комплексно

Думаю, что если бы что-то подобное было, то не работало бы стабильно.
А тут может отработать час, а может только один цикл.
Семафоров я тут не использую, т.к. они там не нужны. Посему и перетирать то там нечего. Что и обидно. Задача наипростейшая. А бодаюсь уже 3 недели.
А может очередь иметь ограничения на длину? Ибо при организации очереди на 32 байта - всё работает. А вот если на 64 - уже нет.
При этом думал что настройки фриртоса по памяти не корректны. Увеличил и кучу и стек в 10 раз. Эффекта не дало. Значит дело не в настройках.

0

Ещё дополнение.
Исследую очередь.
Пишу в таске:
for(i=0; i<BUF_SIZE*9 ; i++)
{
TMP = i & 0xff;
xQueueSend(UART1DataTx, &TMP, 0);
}

Если делать BUF_SIZE*8 - всё работает.
А вот BUF_SIZE*9 - уже нет.
Просто виснет и всё.

0

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

Сообщение от kr1047 ... Если делать BUF_SIZE*8 - всё работает. А вот BUF_SIZE*9 - уже нет. Просто виснет и всё.

это вам надо на выделение памяти посмотреть в заголовочном файле FriiRTOS_config.h, там где общий размер определяется

0

Сообщение от ShiMox Про семафоры я для примера сказал, ситуация правда похожая. в определенный момент происходила порча. Решилась нахождение ошибки при работе с соседним указателем Сообщение от kr1047 ... Если делать BUF_SIZE*8 - всё работает. А вот BUF_SIZE*9 - уже нет. Просто виснет и всё.

это вам надо на выделение памяти посмотреть в заголовочном файле FriiRTOS_config.h, там где общий размер определяется
Так я там посмотрел в первую очередь.
Увеличил памяти в куче и в стеке в 10 раз. Проблема не ушла.

0

Я использую QUBEMX, а там какой-то старый freertos. Может там были какие траблы?

0

Аа, ну так бы и сказали сразу. У вас очередь переполняется. При записи в очередь, вы должны проверять возвращаемое функцией значение. Если оно успешно (pdPASS), то всё норм, а если возвращает errQUEUE_FULL, то ждите, пока она освободится, то есть, пока на приемной стороне очереди по прерываниям произойдет чтение и хоть один элемент освободится.
Таким образом, при записи в очередь, проверяйте возвращаемое значение, и если оно errQUEUE, не пытайтесь писать в очередь следующие элементы, дождитесь освобождения и вновь запишите этот же элемент.
Либо банально увеличте размер очереди, когда ее создаете.

Еще один неплохой вариант для передачи через очередь больших объемов данных. В очередь передаем ссылку (адрес) на массив данных и размер массива. Всё. На приёмной стороне, приняв адрес массива и его размер, работаем с ним, например, отправляем вкудато. Обратная связь - по семафорам. Семафор поднят - "туалэт занят, идет процесс".

Если бы у вас не хватало памяти в куче, то при создании очереди вам бы вернулось состояние ошибки. Кстати, хорошая практика - при создании чего-либо, проверять возвращаемый результат.

Кстати, в отправке в очередь вы написали что-то такое страшное, чего я не в силах с первого раза понять... Наверно это надо под каким-то другим углом смотреть.
http://www.freertos.org/a00117.html
http://www.google.ru/url?sa=t&rct=j&q=& ... lxNx9vObOA

0

При создании очереди всё проверяю. Создалась очередь или нет - отслеживаю.
Статус отсылки, также проверяется. Т.е. если очередь переполнена, то реакция на это есть.
Собственно что я и хотел показать тем примером, какой под углом надо смотреть )), это я в цикле заполняю очередь.
Но она просто подвисает, хотя очередь не полная. Правда в данном примере не проверяется статус отправки.
А может быть такое, что где-то во фриртосе настраивается максимальная длина очереди? Ибо это бы всё объяснило.

0

Да нет, очередь явных ограничений на длину не имеет. Ее длина ограничена только доступным пространством в куче. Если она создалась и вернулось pdPASS, значит она на всю запрошенную длину.

Вот вам наглядно, состояние буфера очереди, когда она полностью заполнена. Очередь на 129 байт.
Вначале идет 72-байтный блок заголовка, затем сам буфер очереди. Первые два 4-х байтных значения в блоке загловка показывают первый и последний адреса буфера очереди. Разность между этими двумя значениями даст общую длину очереди.


<Изображение удалено>

Аналогичным образом вы можете сами проверить свою очередь. В режиме отладки посмотрите адрес, на который указывает дескриптор очереди, когда она будет создана, откройте промотрщик памяти и найдите этот адрес. После заполнения очереди посмотрите, что лежит в ней.

0

2kr1047
Выложи все исходники, ну или хотя бы файлы, где отправка в очередь и прерывание описаны.

0

Да, действительно, для общего дела было бы полезнее увидеть реализацию отправляющей в очередь задачки. Потому как непонятно, сколько это - BUF, да еще умноженный на 9. То ли это один элемент, толи там их десяток, и что такое TMP = i & 0xFF. Я честно несколько раз пытался постичь суть этих преобразований, и пришел к выводу, что вроде как пытаются отправлять в очередь последовательность цифр от 0 до 255, либо до BUF_SIZE*9.
Потому я и предложил топикстартеру способ самостоятельно увидеть, что уходит в очередь в его случае. И я там сцылочки кинул на два основополагающих документа. Один - мануал от производителя, другой - широкоизвестные статии от Курница. Хоть они и давнишние, но зато по-русски и практически не потеряли актуальности.

Например, банально для примера:
отправка текстового сообщения из буфера побайтно в очередь:
<Изображение удалено>

Как говорится, после понимания сути, допилить руками до нужной кондиции.

0