becopt

Я бы предложил вам что-то вроде по аналогии с реализацией хэш-таблиц. Формат записи: номер, длина, данные, чексум, флаг стертости. Вся память делится на несколько связанных списков размером минимум в три страницы памяти. Из номера записи по хэш-функции (упрощенной какой-нибудь) вычисляется индекс соответсвующего связанного списка и в него добавляется/читается/удаляется (отмечается флаг) запись. При переходе в связанном списке через ноль, он переформатируется и удаляются старые записи.

Какие же вы сложные. Учитывая, что вы неправильно пишете matlab, то можно предположить, что это вакансия в "Радиофизике" на планерной. Неужели это проблемно написать? Территориальный признак очень важен, как и отзывы в интернетах.

Укажите пожалуйста название предприятия.

ИМХО, лучше свои все-таки нормально переименовать и/или ограничить область видимости для своих сущностей. В случае совпадения имён в подключенной библиотеке делаю что-то вроде: #define timeval cyclone_timeval #include <cyclone_tcp/core/bsd_socket.h> #undef timeval

Тут вам в помощь счётный семафор. Не обязательно же чтобы на каждый вызов прерывания немедленно запускалась задача обработки, главное чтобы данные не потерялись. Подозрительно большие числа по временам, особенно на переключение контекста FreeRTOS, это сколько же у вас там задач? Было бы легче, если бы была информация о камне и его тактировании. Те же прерывания нужно оптимизировать грамотными аттрибутами на инлайнинг, оптимизацию и пр.

Запрещать прерывание во время работы с буфером из основного приложения. Но это некрасиво. Разделите свой драйвер I2S на две части: обработчик прерывания и фоновый обработчик на уровне приложения. Фоновый обработчик драйвера I2S будет через небольшой буфер получать данные из обработчика прерывания, а затем формировать и передавать сообщения в вашу общую очередь, доступ к которой вы осуществляете мьютексом. Это позволит вам не блокировать прерывания (не терять данные) и разграничить доступ. Однако следует корректно рассчитать размеры буферов и очередей, а также времена блокировки обработчиков во время обращения за доступом к мьютексу.

Вам предложили работать с несколькими линейными массивами и оперировать индексами массива. Более конкретно про различные методики можно почитать у Таненбаума в "Современные операционные системы", раздел 5.3.3 (Программное обеспечение ввода-вывода, не зависящее от конкретных устройств).

Просто пройду мимо и плюсану тех, кто говорил про memory pool'ы (что там у вас, 15 статически аллоцированных массивов максимальной длины).

ИМХО, куски кода в хедерах нужны только в случае, если код нужно инлайнить, т.е. описать как static inline и проблем быть не должно.

С младшей серией тоже есть опыт работы, но без I2C. Там тоже никаких проблем и накладок не возникало. Вообще все MX'ы уже достаточно хорошо отработаны, чего не скажешь об MZ.

У меня MX5xx и I2C в режиме мастера, схемотехника с подтяжками, всё работает (:

Программисты embedded вам не нужны?

Лучше всего будет, если вы реализуете <sys/time.h> под свой камень и будете этим пользоваться.

Нашёл вот такое дело: Курс на stepik

Очень плохая вакансия. Учитесь писать вилку зп, господа "не жадные" (:

Я ничего не понимаю в армах и keil компиляторе, но почему val long, а не int? (да, по документации-то они одной размерности, но компилятор может это неадекватно воспринять)

http://www.microchip.com/mplab/mplab-xpress

Насколько я знаю, начиная с крайних версий xc32 его стало гораздо сложнее "вылечить", т.к. они догадались поменять по проверки лицензии. Также, вроде как, -О1 бесплатно идет, т.к. без инлайна гармония не собирается. Без оптимизации жить можно, но проект очень быстро раздувается.

Официальны xc32 это и есть gcc с твиками под камень. Полтора кило доллара на три машины.

Еще вроде I2C мастер не работал, пришлось писать софтверную реализацию, а потом вообще менять интерефейс и переразводить. У уарта был какой-то косяк с приемом в фифо, не помню уже. Ну и общие минусы пиков: - Цена за компилятор, отдельная цена на плюсовый компилятор; - Необходимость использовать микрочиповскую иде и микрочиповский программатор (хотя вроде недавно разрешили jlink); - Достаточно громоздкий и не очень удобный фреймворк для разработки. Но, по справедливости, тоже самое у тех же ST. Вот захотите графикой от сеггера пользоваться: для микрочипа придется покупать, а для st - бесплатно. А так большинство нужных либ портированы, работать можно, ядро mips оставляет только положительные впечатления.

Вроде как пофиксили. А вроде как и не на всех чипах и не со всеми кварцами. И вроде там еще всякое веслье было с периферией другой. Работать с чипами этими можно, но вот получать удовольствие - не особо.

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

Можно попробовать проинициализировать tIM как NULL и сделать assert перед vTaskNotifyGiveFromISR. А так все выглядит адекватно действительно.

Вы хотите использовать нотифаи в качестве бинарного семафора? Тогда может быть попробовать перед записью в очередь его точно сбросить (ulTaskNotifyTake(pdTRUE, 0);) ? И без кода прерывания сложно сказать, но я думаю у вас там корректно делаются vTaskNotifyGiveFromISR и portYIELD_FROM_ISR?

Семафоры - хорошее решение. Правда я не понял зачем вам их два. Всё-таки наверное первый у вас - это мютекс? portMAX_DELAY - не лучший вариант, все-таки правильнее задать конкретное время и обработать ошибку, а то все зависнуть может. По поводу нотификейшнов проще было бы подсказать, если бы вы поделились кодом. Я бы начал с простого и проверил в конфиге configUSE_TASK_NOTIFICATIONS (: Я активно нотификейшнами пользуюсь как раз для такого типа синхронизации, по времени выходит быстрее.