С GCC плотно не работал, но звучит сомнительно. Если вы явно указываете секцию, то символ там и будет. Именно такое поведение было на компиляторах указанных выше.
На работе активно используем этот приём с компоновкой настроек через секцию линковщика, кстати это успешно реализуется и в Keil, IAR, даже в MSVC. Но тут есть нюансы. 1. Константу придётся помечать как volatile так как компилятор вполне может встроить значение константы вместо фактического чтения из ПЗУ. 2. Не гарантируется фиксированный порядок расположения констант в секции. Например если добавляется один новый uint8_t, то он может попасть где то по середине так как с учётом выравнивания линковщик старается плотнее расположить данные.
Могу подкинуть идею по поводу использования стека под каждую корутину (буду далее писать так потому что короче), давно уже витает реализовать подобное под МК, а там использовать классический менеджер памяти не комильфо. Первое - обеспечить постоянство расстояния стека от main до первого вызова корутины планировщиком. Второе - в момент первого прямого вызова корутины сохранить текущий указатель стека (типа базовое смещение). В момент разрыва синхронного выполнения (когда дальше через продолжение) - определить текущий указатель стека и вычисть с него базовое смещение, это даст размер фактического использования стека. Далее в дело вступает специальный менеджер памяти. Он может только выделять, но освобождать нет. Для каждой корутины предполагается потенциально фрагментированная кучка памяти. И вот корутина дошла до первого разрыва и просит 30 байт, предоставляется первый блок. Другая корутина после просит 40 байт, первая доходит до второго разрыва и там уже надо допом 50 байт, менеджер памяти выделяет за вторым блоком (40 байт) ещё блок в 50 байт, итого для первой корутины в сумме выделено 30 + 80 байт, но фрагментированной памяти. Но это не страшно так как пробежаться по связанному списку и скопировать стек в 80 байт в настоящий - относительно быстро. Таким образом как и с классическим стеком - появляется единственный дополнительный стек для корутин. Плюсы: 1. Теперь нужно думать только о размере одного стека. 2. Память максимально упакована и минимально используется. 3. Если прогнать все корутины по всем ветвям - легко определить сколько по факту надо. Минусы: 1. Стек копируется, от сюда просадка в производительности. Однако частенько корутины используются для прерываний на некоторую задержку или ожидание внешнего события или ввод/вывод. А это всё не нуждается в упоре на производительность. И так как сохраняется стек только локальных данных функции самой корутины - памяти много не нужно (если конечно на стеке не хранить жирные буферы).
Давным давно придумали софтовые таймеры, их может быть огромное количество и всеми ими управляет один аппаратный таймер с одним каналом сравнения. Далее все как в статье с аппаратным таймером. Всё.
В спецификации может и нет, а в трансиверах Semtech оно есть, но называется CAD — Channel Activity Detection. То есть перед передачей можно быстро проверить канал.
на Cortex-M3 с частотой 48 МГц один 16-байтный блок шифруется примерно за 100 мкс «с нуля»
На работе крутится самописный LoraWAN стек спецификации 1.0.3 класс A на STM8L с установленной частотой в 4 МГц. Даже в таких условиях ни время ни потребление на заметно на фоне передачи на DR5. Кстати, на этой архитектуре «весит» 15 КБ.
размер нагрузки в LoRaWAN всегда кратен 16 байтам
Там в конце до кратности в 16 послыка дополняется нулевыми падами.
Здесь можно провести параллель с остальной переферией например микроконтроллеров. Например указывают мол есть 10 таймеров, но первая пара идет как «advanced» или «enhanced». Другими словами первые идут как более навороченные, а остальные по проще. Тем не менее, относительно задачи, потребоваться могут все. Веду к тому, что делать всю переферию такого типа навороченной затратно и в большинстве не нужно.
С GCC плотно не работал, но звучит сомнительно. Если вы явно указываете секцию, то символ там и будет. Именно такое поведение было на компиляторах указанных выше.
На работе активно используем этот приём с компоновкой настроек через секцию линковщика, кстати это успешно реализуется и в Keil, IAR, даже в MSVC. Но тут есть нюансы. 1. Константу придётся помечать как volatile так как компилятор вполне может встроить значение константы вместо фактического чтения из ПЗУ. 2. Не гарантируется фиксированный порядок расположения констант в секции. Например если добавляется один новый uint8_t, то он может попасть где то по середине так как с учётом выравнивания линковщик старается плотнее расположить данные.
Могу подкинуть идею по поводу использования стека под каждую корутину (буду далее писать так потому что короче), давно уже витает реализовать подобное под МК, а там использовать классический менеджер памяти не комильфо. Первое - обеспечить постоянство расстояния стека от main до первого вызова корутины планировщиком. Второе - в момент первого прямого вызова корутины сохранить текущий указатель стека (типа базовое смещение). В момент разрыва синхронного выполнения (когда дальше через продолжение) - определить текущий указатель стека и вычисть с него базовое смещение, это даст размер фактического использования стека. Далее в дело вступает специальный менеджер памяти. Он может только выделять, но освобождать нет. Для каждой корутины предполагается потенциально фрагментированная кучка памяти. И вот корутина дошла до первого разрыва и просит 30 байт, предоставляется первый блок. Другая корутина после просит 40 байт, первая доходит до второго разрыва и там уже надо допом 50 байт, менеджер памяти выделяет за вторым блоком (40 байт) ещё блок в 50 байт, итого для первой корутины в сумме выделено 30 + 80 байт, но фрагментированной памяти. Но это не страшно так как пробежаться по связанному списку и скопировать стек в 80 байт в настоящий - относительно быстро. Таким образом как и с классическим стеком - появляется единственный дополнительный стек для корутин. Плюсы: 1. Теперь нужно думать только о размере одного стека. 2. Память максимально упакована и минимально используется. 3. Если прогнать все корутины по всем ветвям - легко определить сколько по факту надо. Минусы: 1. Стек копируется, от сюда просадка в производительности. Однако частенько корутины используются для прерываний на некоторую задержку или ожидание внешнего события или ввод/вывод. А это всё не нуждается в упоре на производительность. И так как сохраняется стек только локальных данных функции самой корутины - памяти много не нужно (если конечно на стеке не хранить жирные буферы).
В Embedded широко распространен Си и толковых разработчиков там днем с огнём не ссышешь.
Давным давно придумали софтовые таймеры, их может быть огромное количество и всеми ими управляет один аппаратный таймер с одним каналом сравнения. Далее все как в статье с аппаратным таймером. Всё.
На работе крутится самописный LoraWAN стек спецификации 1.0.3 класс A на STM8L с установленной частотой в 4 МГц. Даже в таких условиях ни время ни потребление на заметно на фоне передачи на DR5. Кстати, на этой архитектуре «весит» 15 КБ.
Там в конце до кратности в 16 послыка дополняется нулевыми падами.