контакты снаружи же

ну тогда на стенку десяток-другой емкостных датчиков

я про то и говорю

или оптических

вообще поставить на весы наврное правальнее всего

только ёмкость надо ставить на выровненную поверхность. Ну и сама она не должна быть кривой

или в дно уз датчик

народ

на канистре указан же номинальный обьем?

или пустую канистру сначала взвешиваем, или через плотность считать

или пустую канистру сначала взвешиваем, или через плотность считать

Жидкости разные же

плотность можно посчитать

думаю что она написана в доках на продукцию

Ну в целом там наверное все будет в пределах погрешности в доках указывается вес продукта

Ну точнее объем в жидких единицах flz

ye djn

ну вот

ставишь на весы и все

Вместимость литров всегда одинакова, а масса будет разная. Отношение л/кг константа для данного типа жидкости. Залили - запомнили массу которая измерилась весами. Исходя из постоянного соотношения л/кг считаешь остаток в литрах

ну, это при одинаковой температуре

В тз не сказано про температуру ничего

но и температуру скомпенсировать можно

Думаю на обьеме канистры это будут единицы миллитров если не компенсировать температуру

Кто какие параметры ставит в FreeRTOSCOnfig.h ? Интересуют эти два: #define configKERNEL_INTERRUPT_PRIORITY 255 #define configMAX_SYSCALL_INTERRUPT_PRIORITY 191 /* equivalent to 0xb0, or priority 11. */

#define configLIBRARY_LOWEST_INTERRUPT_PRIORITY 0xf #define configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 5 #define configKERNEL_INTERRUPT_PRIORITY ( configLIBRARY_LOWEST_INTERRUPT_PRIORITY « (8 - configPRIO_BITS) ) #define configMAX_SYSCALL_INTERRUPT_PRIORITY ( configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY « (8 - configPRIO_BITS) )

это STM32 ?

да

f407

Приоритет любого прерывания должен быть выше (меньше число) или ниже (выше число) configMAX_SYSCALL_INTERRUPT_PRIORITY ?

Therefore, any interrupt service routine that uses an RTOS API function must have its priority manually set to a value that is numerically equal to or greater than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting. This ensures the interrupt's logical priority is equal to or less than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting.

число выше, приоритет ниже

http://www.freertos.org/RTOS-Cortex-M3-M4.html

хм…

This ensures the interrupt's logical priority is equal to or less than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting.

Значит надо свои прерывания делать с приоритетом ниже чем configMAX_SYSCALL_INTERRUPT_PRIORITY?

т.е. число ниже 11 (12, 13 и т.д.)

блджать, там есть 2 предложения)

Therefore, any interrupt service routine that uses an RTOS API function must have its priority manually set to a value that is numerically equal to or greater than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting. This ensures the interrupt's logical priority is equal to or less than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting.

если их перевести то все понятно сразу

ну так я же то и написал - перывание должно с приоритетом ниже или равно (цифра больше или равна) onfigMAX_SYSCALL_INTERRUPT_PRIORITY

Therefore, any interrupt service routine that uses an RTOS API function must have its priority manually set to a value that is numerically equal to or greater than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting. дословно переведи это предложение

а потом дословно переведи это предложение This ensures the interrupt's logical priority is equal to or less than the configMAX_SYSCALL_INTERRUPT_PRIORITY setting.

Что я не так написал?

хотя да)

Чему не соответствует?

приоритет ниже, цифра больше

т.е. число ниже 11 (12, 13 и т.д.)

просто напрягло

Такого огорода нагородили с этими прерываниями

logical priority is equal to or less numerically equal to or greater

Интересно бы жизненный пример когда нужны эти приоритеты

Еще ни разу не видел

когда внутри прерывания нужно дернуть семафор и чтобы ничего не сломалось

пихнуть в очередь чтобы ничего не сломалось

взять мьютекс чтобы ничего не сломалось

не, я про саму суть приоритетов

без привязки к FreeRTOS

где может пригодиться более высокий приоритет?

сама суть приоритетов нужна для вложенных прерываний, когда nvic гоняет между приоритетами, но при этом не гоняет между субприоритетами

не видел примеров

для чего нужны вложенные прирывания?

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

длительное в смысле обработчик долго работает?

ERROR: S client not available

да

типа ж низя так, лучше состояниями управлять

конечный автомат, а прерывания только состояния новые выставляют

по факту можно и так и так, конечно длительные прерывания не приветствуются, но если вся логика построена на прерываниях, то почему нет

попробуй разберись потом в такой логике

плюс нетестопригодно

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

да, ос все прозрачно сделает

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

ос ни разу не прозрачно)

с синхронизацией геморроя больше

но есть ситуации когда автомата+прерываний уже не хватает. Или хватает, но получается не расширяемо

да, как раз имхо в расширяемость все и упирается обычно

Опубликовано в канале @ru_electronics_feed достуные теги: #объявление #книга #статья #каналья #ссылка

А вот например есть uart и есть системный таймер 10 мсек, таймер используется для FatFS

а через UART идет общение с SIM900

Какое прерывание лучше сделать приоритетнее, таймера или UART ?

uart скорее

можно одинаковый приоритет поставить штоб не вытесняло ничего

получается uart важнее, потому что SIM900 не будет ждать

а сыпет байтами

и надо успеть принять

ага, если не успеешь байт принять, будет оверран. Дма наше всё

а дма как принимает, задается бфер определенного размера и пока он не заполнится, принимает само?

для начала нужно убедиться что нвик настроен на вложенные прерывания, по дефолту он их не поддерживает и везде subpriority. А так для мелких прерываний это не важно, больше даже потеряется. переход с оного приоритета в другой это 7 тактов. вход в прерывание это 14 тактов. В итоге если обработка юарта например занимает 100 тактов, а прерывание таймера 50, то вместо 14 тактов на вход, 100 на обработку первого прерывания, 50 на второе, 14 тактов на выход (178). мы получим 14 на вход 50 на обработку части первого, 7 на переход во второе, 50 на обработку второго, 7 на переход обратно в первое и 50 обработки первого, потом 14 обратно (192) мы получим понядка 10% оверхеда

ага. Но можно прекращать, например по IDLE прерывание сделать

с дма выходит если редко идут данные то меньше ресурсов будет простое прерывание по приему байта, а то в случае дма надо будет периодически проверять наличие новых данных

с дма выходит если редко идут данные то меньше ресурсов будет простое прерывание по приему байта, а то в случае дма надо будет периодически проверять наличие новых данных

в стмке есть флаг IDLE у юсарта

хэй