![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kincajouИзобрёл очередную недо-RTOS. Вернее, она не совсем RT, потому что специфика задачи позволяет иметь задержку реакции аж в несколько секунд, но если вдруг понадобится - разогнать до "почти реального времени" не проблема.
Задача классическая, как раз для встраиваемой системы - опросить энное количество разнообразных датчиков, ответить на команды или послать сообщения, привести исполнительные устройства в соответствующие состояния и, тащемта, на этом всё. А, ну ещё лампочками помигать или дуделкой подудеть, если что. В процессе решения задачи пришлось написать собственный "шедулер" (примитивный, но всё-таки), "очередь исполнения" (FIFO с приоритетами) и прочая, прочая.
В будущем функционал будет только наращиваться, поэтому сначала написал огромную (по меркам платформы, на которой всё это крутится - 8-битный МК с 4 кБ оперативки) библиотеку, поддерживающую всё, что на плате есть (и кое-что ещё). И теперь, используя мой расчудесный шедулер и эту библиотечку, добавлять новые функции стало проще простого. Например, обнаружилось, что собственный преобразователь питания этой штуковины начинает серьёзно греться, если включить несколько нагрузок - но я мудро предусмотрел возможность подключения кулера и термодатчика. Добавил в список заданий проверку температуры (датчик приклеил прямо на чип преобразователя) и вуаля! Перегрелись выше определённого порога - включаем кулер, остыли ниже другого - отключаем, чтоб зря энергию не тратить. И автоматицки сообщаем наверх, что у нас тут жарковато.
Команды могут приходить из разных портов, все они сливаются в одну очередь и единообразно обрабатываются. Т.е. не надо путаться, откуда что пришло - структура программы такова, что ответы автоматически уходят туда, откуда был запрос.
Предстоит ещё накалякать нечто вроде DHCP - протокольчик, который автоматически пронумерует контроллеры, сидящие на одной шине и изначально про свои адреса ничего не знающие.
Задача классическая, как раз для встраиваемой системы - опросить энное количество разнообразных датчиков, ответить на команды или послать сообщения, привести исполнительные устройства в соответствующие состояния и, тащемта, на этом всё. А, ну ещё лампочками помигать или дуделкой подудеть, если что. В процессе решения задачи пришлось написать собственный "шедулер" (примитивный, но всё-таки), "очередь исполнения" (FIFO с приоритетами) и прочая, прочая.
В будущем функционал будет только наращиваться, поэтому сначала написал огромную (по меркам платформы, на которой всё это крутится - 8-битный МК с 4 кБ оперативки) библиотеку, поддерживающую всё, что на плате есть (и кое-что ещё). И теперь, используя мой расчудесный шедулер и эту библиотечку, добавлять новые функции стало проще простого. Например, обнаружилось, что собственный преобразователь питания этой штуковины начинает серьёзно греться, если включить несколько нагрузок - но я мудро предусмотрел возможность подключения кулера и термодатчика. Добавил в список заданий проверку температуры (датчик приклеил прямо на чип преобразователя) и вуаля! Перегрелись выше определённого порога - включаем кулер, остыли ниже другого - отключаем, чтоб зря энергию не тратить. И автоматицки сообщаем наверх, что у нас тут жарковато.
Команды могут приходить из разных портов, все они сливаются в одну очередь и единообразно обрабатываются. Т.е. не надо путаться, откуда что пришло - структура программы такова, что ответы автоматически уходят туда, откуда был запрос.
Предстоит ещё накалякать нечто вроде DHCP - протокольчик, который автоматически пронумерует контроллеры, сидящие на одной шине и изначально про свои адреса ничего не знающие.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2011-07-08 12:47 pm (UTC)только у меня оперативки в 4 раза меньше (собственно, та самая mega32u2). это несколько усугубляет положение, но пока, как мне кажется, её хватит.
снова бадания с компилятором, жуть, жуть, жуть. я нисколько не хочу преуменьшить достижения людей, но то, что генерит на выходе winavr, нельзя назвать хорошим, оптимизированным кодом. видимо, всё закончится переписыванием части рутин на ассемблере, потому что сил уже моих нет.