Jump to content

    

becopt

Участник
  • Content Count

    77
  • Joined

  • Last visited

Community Reputation

0 Обычный

About becopt

  • Rank
    Частый гость

Информация

  • Город
    Array

Recent Profile Visitors

2638 profile views
  1. Я бы предложил вам что-то вроде по аналогии с реализацией хэш-таблиц. Формат записи: номер, длина, данные, чексум, флаг стертости. Вся память делится на несколько связанных списков размером минимум в три страницы памяти. Из номера записи по хэш-функции (упрощенной какой-нибудь) вычисляется индекс соответсвующего связанного списка и в него добавляется/читается/удаляется (отмечается флаг) запись. При переходе в связанном списке через ноль, он переформатируется и удаляются старые записи.
  2. Какие же вы сложные. Учитывая, что вы неправильно пишете matlab, то можно предположить, что это вакансия в "Радиофизике" на планерной. Неужели это проблемно написать? Территориальный признак очень важен, как и отзывы в интернетах.
  3. Укажите пожалуйста название предприятия.
  4. ИМХО, лучше свои все-таки нормально переименовать и/или ограничить область видимости для своих сущностей. В случае совпадения имён в подключенной библиотеке делаю что-то вроде: #define timeval cyclone_timeval #include <cyclone_tcp/core/bsd_socket.h> #undef timeval
  5. Тут вам в помощь счётный семафор. Не обязательно же чтобы на каждый вызов прерывания немедленно запускалась задача обработки, главное чтобы данные не потерялись. Подозрительно большие числа по временам, особенно на переключение контекста FreeRTOS, это сколько же у вас там задач? Было бы легче, если бы была информация о камне и его тактировании. Те же прерывания нужно оптимизировать грамотными аттрибутами на инлайнинг, оптимизацию и пр.
  6. Запрещать прерывание во время работы с буфером из основного приложения. Но это некрасиво. Разделите свой драйвер I2S на две части: обработчик прерывания и фоновый обработчик на уровне приложения. Фоновый обработчик драйвера I2S будет через небольшой буфер получать данные из обработчика прерывания, а затем формировать и передавать сообщения в вашу общую очередь, доступ к которой вы осуществляете мьютексом. Это позволит вам не блокировать прерывания (не терять данные) и разграничить доступ. Однако следует корректно рассчитать размеры буферов и очередей, а также времена блокировки обработчиков во время обращения за доступом к мьютексу.
  7. Вам предложили работать с несколькими линейными массивами и оперировать индексами массива. Более конкретно про различные методики можно почитать у Таненбаума в "Современные операционные системы", раздел 5.3.3 (Программное обеспечение ввода-вывода, не зависящее от конкретных устройств).
  8. Просто пройду мимо и плюсану тех, кто говорил про memory pool'ы (что там у вас, 15 статически аллоцированных массивов максимальной длины).
  9. ИМХО, куски кода в хедерах нужны только в случае, если код нужно инлайнить, т.е. описать как static inline и проблем быть не должно.
  10. С младшей серией тоже есть опыт работы, но без I2C. Там тоже никаких проблем и накладок не возникало. Вообще все MX'ы уже достаточно хорошо отработаны, чего не скажешь об MZ.
  11. У меня MX5xx и I2C в режиме мастера, схемотехника с подтяжками, всё работает (:
  12. Лучше всего будет, если вы реализуете <sys/time.h> под свой камень и будете этим пользоваться.
  13. Embedded Linux

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