4) 32-битный процессор читает любую переменную 8-32 бита за один такт. Определите глобальную структуру данных со своими переменными и используйте их во всех ваших файлах
Не совсем, M0+ атомарно читает любую выровненную 16/32 бит переменную.
ну так если я никаких указаний по выравниванию переменных компилятору не давал, он по умолчанию будет все выравнивать?
Для отдельной переменной будет, а со структурами нужно быть осторожным, тем более у M3 и выше уже поддержка невыровненного доступа есть и там даже если атрибут упаковки на структуру повесить все равно будет работать правильно.
jcxz, вот вопрос на счет журнала EEPROM. вы настоятельно рекомендовали применять хитрое кодирование, забыл, как называется, но у меня вопрос: зачем?! ведь если просто указывать длину записи в её первом байте, можно легко проследить всю цепочку записей, а если эта длина равна 0, значит, больше записей нет.
В смысле - нет? Как такое может быть? Вы точно поняли алгоритм, который я описывал???
в чем скрытый смысл вашего подхода и какие минусы у моего?
Подумайте - что будет при вашем способе, если в момент дозаписи в журнал очередной записи, произойдёт сбой питания? Как затем будете писать в журнал новые записи? Кодирование здесь для того же, для чего оно используется при передаче данных в системах связи - чтобы при помехе потерять один пакет, а не полностью потерять связь.
[*]для атомарного доступа есть какие-то готовые решения, или тупо использовать пару taskENTER_CRITICAL()/taskEXIT_CRITICAL()?
Непонятно что имеется в виду под атомарным доступом? Какая операция? Простые 8-/16-/32-битные чтения и записи - на ARM атомарны. С точки зрения одного ядра CPU. Но могут занимать несколько шинных операций.
[*]если я "забуфферизирую" эту переменную в потоке, где использую, примерно так uint32_t tmp = __ATOMIC_READ(ABC); - компилятор ничего не учудит с оптимизацией tmp? в том плане, что посчитает меня тупее валенка и вместо tmp продолжит использовать ABC?
Если объявите ABC с volatile - то в этом месте скопирует её в tmp и далее будет использовать tmp.
[*]или, поскольку ARM 32-битный, чтение любой переменной этого размера всегда атомарное, и достаточно просто забуфферизировать переменную?
не всегда. Зависит от множества факторов. И "атомарное" - для кого? Для самого этого CPU или для другого bus-master на шине? Или для периферийного блока?
Не совсем, M0+ атомарно читает любую выровненную 16/32 бит переменную.
Ещё более "не совсем" - даже выровненные переменные могут читаться за несколько тактов, если они расположены в памяти, подключенной шиной с разрядностью менее 32 бит. Также память может быть не zero-wait states. Тоже требует больше тактов. Даже внутренняя ОЗУ (некоторые её регионы) в некоторых ARM требует более одного такта для доступа. Также память может быть занята обращением другого bus-master. CPU тоже придётся ждать. PS: Речь не про M0+, а вообще про ARM-ы.
Почему-то после ваших ответов становится еще менее понятно, чем до...
Добавлено after 49 seconds: Атомарно - в рамках ртос. Т.е. пока одна задача читает, вторая внезапно не поменяет.
Добавлено after 6 minutes 52 seconds: Можно подумать, при вашем способе записи сбой не разрушит последнюю запись и не нарушит цепочку... Ваш способ просто разновидность байтстаффинга, причем относительно "тяжелой" реализации.
Что касается вопроса о последней записи, то я вас вообще не понимаю... Вот у нас чистый журнал, только-только после первой инициализации, и мы меняем переменную... В журнал помещена запись... Потом происходит сброс, МК начинает листать записи журнала для "восстановления" переменных - разве ему не надо знать, что в журнале единственная запись?! Вот он ее прочел, допустим, 5 байт, смотрит 6-й - э там условно EOF, значит, больше записей нет. Вот это и есть пометка последней записи, оно же начало следующей, если таковая появится. Что не так-то?!
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Атомарно - в рамках ртос. Т.е. пока одна задача читает, вторая внезапно не поменяет.
Что такое "в рамках ртос"? Контроллер DMA - он в рамках ртос или за рамками? Для контроллера DMA невыровненная запись CPU может быть неатомарной. Для самого пишущего CPU - атомарна. Для какой-то периферии или другого CPU - тоже может быть неатомарна.
EOF, значит, больше записей нет. Вот это и есть пометка последней записи
В описанном мной журнале нет и не может быть никаких EOF. Там только есть записи, и есть пространство между записями. COBS-кодирование нужно чтобы однозначно можно было отделить байты записей от байтов пространства между записями. Не обязательно COBS, можно другое кодирование, позволяющее экранировать часть символов. Но COBS - самое оптимальное.
PS: Не строчите сообщения одно за одним. Лучше потратьте это время на обдумывание. Там же всё примитивно и логически понятно что и для чего. А мы тут уже сколько жуём эту примитивщину...
в FreeRTOS есть средства работы с DMA? перестаньте отвечать на собственные вопросы, если есть желание - отвечайте только на заданные. без сферических коней в вакууме.
jcxz писал(а):
Для какой-то периферии или другого CPU - тоже может быть неатомарна.
еще раз: я написал неатомарную инструкцию a++ - где тут DMA и шины?! процессор: (1) берет значение, (2) увеличивает на 1 и (3) сохраняет значение. Между (1) и (2) и/или (2) и (3) РТОС может передать управление другому процессу, которые тоже изменяет эту переменную, и результат будет непредсказуемый. при чем тут аппаратура, строение ядра и такты шины?! если вы не понимаете, что меня волнует, лучше задайте наводящие вопросы, вместо того, чтобы улетать в заоблачные выси теории всего
jcxz писал(а):
Советую ещё раз всё обдумать.
советую еще раз объяснить
jcxz писал(а):
В описанном мной журнале нет и не может быть никаких EOF. Там только есть записи, и есть пространство между записями.
и "пространство" между записями не является признаком конца предыдущей записи, да? и как тогда ваш журнал читать, до конца всей памяти каждый раз? если нет пометки последней записи...
jcxz писал(а):
Последнюю запись - разрушит, всю цепочку - нет.
ну так и мой способ сделает ровно то же - последнюю порушит, остальные нет. если в вашем кодировании сбой изменит значение ячейки, в которой был байт, "исключенный" COBS-кодированием, ваш метод вообще неизвестно что считает из записи... в том числе и может затереть чужую память...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
А есть какие-то хитрости с подключением SWD? Странная ситуация возникла... IAR через ST-LINK не подключается к процу, говорит, таргет не найден. При этом буквально 5 секунд назад этот самый проц этим самым ST-LINK из этого самого IAR прошил. При старте прошивки вылетело окно с предупреждением об ошибке инициализации Debug-режима, дескать, Hard Fault зафиксирован, но я списал это на попытку отладить МК с пустой FLASH... МК прошился, стартанул, работает, но теперь отладчик не подключается. И таких изделий несколько, и все ведут себя одинаково - не отлаживаются, но работают...
Что происходит вообще?!
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
ARV, возможно по тому, что при работе с ST-LINK подключение "через reset" как бы само собой разумеющееся. Порой трудно сообразить, что нужно учить "дышать". Да и гуглится Ваша проблема на раз - вот Ваш случай один в один.
_________________ Платы для HLDI - установки лазерной засветки фоторезиста. ФоторезистыOrdyl Alpha 350 и AM 140. Жидкое олово для лужения плат (видео) - самое лучшее и только у меня. Паяльная маска XV501T-4 и KSM-S6189 (5 цветов). Заказ печатных плат - pcbsmac@gmail.com
всё на раз гуглится, когда знаешь, что гуглить. а когда не знаешь - получаешь такой выхлоп, в котором разбираешься по три дня, пока не поймешь, что это вообще не о том... потому и спрашиваю на форуме, но тоже эффективность не высокая.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Ну так изучите процедуру подключения отладчика. Он может подключаться под reset'ом или без него, с предварительным сбросом МК или без сброса к работающему, с "железным" сбросом или софтовым. Ещё учтите, как инициализированы ноги для подключения SWD. Не помню где попадалось, но некоторым средам если не сказать, что тебе нужен SWD, так они его ноги переведут в режим аналогового ввода. Так что вариантов не много, просто нужно проверить настройки. Ну и про защиту памяти не забываем. Кстати, Куб не всегда может подключиться с платам с Али, потому что китайцы иногда полностью блокируют доступ к МК, поэтому приходится через КубПрограмматор подключиться и сбросить защиту с очисткой памяти.
Дошел до момента, когда для новой задачи FreeRTOS перестало хватать Heap. Пытаюсь заменить задачу на обработчик прерывания таймера TIM6. При помощи куба делаю настройку: Предполагаю прерываться каждые 10 мс.
В недрах сгенерированных исходников, а именно в файле stm32l0xx_it.c добавляю вызов своей функции:
Ставлю брейкпоинт на обработчик, компилирую, запускаю - бряк не происходит. Задачи RTOS крутятся, а прерывание таймера не возникает. Естественно, куб все инициализации сам сделал, в исходники вставил, и я туда не лез. В принципе, все шаги инициализации через HAL делаются, в отладчике проследил.
Что я упускаю на этот раз?!
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
зашел и заэнейблил, уж этот уровень я преодолел... оказалось, еще надо принудительно таймер включить... это тоже теперь сделано... но прерываний нет
Добавлено after 35 minutes: причем таймер считает, значение счетчика меняется. где-то прерывания запрещены, что ли... хотя в регистре разрешения битик стоит... не понимаю...
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 21
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
мой инглиш подвел
