demiurg_spb

Чем раньше перейдёте с АСМ на Си тем крепче будет ваше здоровье. Не шутка.

Тут ещё extern inline не обсосали))) Помню что в стандарте это описывается. С ходу нашёл лишь https://www.ibm.com/support/knowledgecenter...ine_linkage.htm http://m68hc11.serveftp.org/inline-1.php

То, то. ИМХО внутри _Pragma(...) можно всё что угодно написать (даже "inline = forced") и задефайнить...

Немного погуглив нашёл _Pragma(...) #ifdef IAR #define NO_OPT _Pragma ("optimize=none") #endif NO_OPT void some_func(void) { … }

А в IAR разве нет атрибутов наподобие gcc и keil? У меня написан compiler.h в котором все нюансы компиляторов запрятаны. Типа #if defined(__GNUC__) # define __is_always_inline __inline__ __attribute__((__always_inline__)) #endif А пользовательский код никаких специфических вещей компиляторов не использует - только свою прослойку. static __is_always_inline void foo(void) { // do something } ИМХО прагмы в коде последнее дело...

файл .h static inline uint32_t SYSTIME_GetSystemTime(void) { //do something } и всё

Может банальное переполнение буфера? HINT: Попробуйте на snprintf заменить и в будущем только её и использовать...

Ага))) и звать её ssize_t подробнее тут

Телепатирую))) Видимо нет, т.к. хочется видеть разный вывод: size before: XXX size after: XXX

Посмотрите файлик modbus-data.c из библиотеки libmodbus.

я полагаю так: #define _svComandLine(vROW_Z) Serial2.print("\e["#vROW_Z";1H"); #define svComandLine(vROW_Z) _svComandLine(vROW_Z)

Может Вам пригодится... Для многих АВРок есть возможность тоглить (инвертировать) состояние GPIO путём записи в регистр PINx. Пример инверсии нулевого и седьмого бита в порту Б: PINB = (1<<7)|(1<<0); Вот список моделей для которых это можно #if defined(__AVR_AT90PWM1__) \ || defined(__AVR_AT90PWM2__) \ || defined(__AVR_AT90PWM2B__) \ || defined(__AVR_AT90PWM3__) \ || defined(__AVR_AT90PWM3B__) \ || defined(__AVR_AT90PWM216__) \ || defined(__AVR_AT90PWM316__) \ || defined(__AVR_AT90PWM81__) \ || defined(__AVR_AT90USB82__) \ || defined(__AVR_AT90USB162__) \ || defined(__AVR_ATmega8U2__) \ || defined(__AVR_ATmega16U2__) \ || defined(__AVR_ATmega32U2__) \ || defined(__AVR_ATmega16U4__) \ || defined(__AVR_ATmega32U4__) \ || defined(__AVR_ATmega32U6__) \ || defined(__AVR_AT90USB646__) \ || defined(__AVR_AT90USB647__) \ || defined(__AVR_AT90USB1286__) \ || defined(__AVR_AT90USB1287__) \ || defined(__AVR_AT90CAN32__) \ || defined(__AVR_AT90CAN64__) \ || defined(__AVR_AT90CAN128__) \ || defined(__AVR_ATmega16M1__) \ || defined(__AVR_ATmega32M1__) \ || defined(__AVR_ATmega64M1__) \ || defined(__AVR_ATmega32C1__) \ || defined(__AVR_ATmega64C1__) \ || defined(__AVR_ATmega48__) || defined(__AVR_ATmega48A__) \ || defined(__AVR_ATmega88__) || defined(__AVR_ATmega88A__) \ || defined(__AVR_ATmega168__) || defined(__AVR_ATmega168A__) \ || defined(__AVR_ATmega48P__) || defined(__AVR_ATmega48PA__) \ || defined(__AVR_ATmega88P__) || defined(__AVR_ATmega88PA__) \ || defined(__AVR_ATmega168P__) || defined(__AVR_ATmega168PA__) \ || defined(__AVR_ATmega328__) \ || defined(__AVR_ATmega328P__) \ || defined(__AVR_ATmega640__) \ || defined(__AVR_ATmega1280__) \ || defined(__AVR_ATmega1281__) \ || defined(__AVR_ATmega2560__) \ || defined(__AVR_ATmega2561__) \ || defined(__AVR_ATmega164A__) \ || defined(__AVR_ATmega164P__) || defined(__AVR_ATmega164PA__) \ || defined(__AVR_ATmega324A__) \ || defined(__AVR_ATmega324P__) || defined(__AVR_ATmega324PA__) \ || defined(__AVR_ATmega644__) || defined(__AVR_ATmega644A__) \ || defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644PA__) \ || defined(__AVR_ATmega1284P__) \ || defined(__AVR_ATmega165__) || defined(__AVR_ATmega165A__) \ || defined(__AVR_ATmega165P__) || defined(__AVR_ATmega165PA__) \ || defined(__AVR_ATmega325__) || defined(__AVR_ATmega325A__) \ || defined(__AVR_ATmega325P__) \ || defined(__AVR_ATmega3250__) \ || defined(__AVR_ATmega3250P__) \ || defined(__AVR_ATmega645__) || defined(__AVR_ATmega645A__) \ || defined(__AVR_ATmega645P__) \ || defined(__AVR_ATmega6450__) || defined(__AVR_ATmega6450A__) \ || defined(__AVR_ATmega6450P__) \ || defined(__AVR_ATmega169__) || defined(__AVR_ATmega169A__) \ || defined(__AVR_ATmega169P__) || defined(__AVR_ATmega169PA__) \ || defined(__AVR_ATmega329__) || defined(__AVR_ATmega329A__) \ || defined(__AVR_ATmega329P__) || defined(__AVR_ATmega329PA__) \ || defined(__AVR_ATmega3290__) \ || defined(__AVR_ATmega3290P__) \ || defined(__AVR_ATmega649__) || defined(__AVR_ATmega649A__) \ || defined(__AVR_ATmega6490__) || defined(__AVR_ATmega6490A__) \ || defined(__AVR_ATmega6490P__) \ || defined(__AVR_ATmega649P__) \ || defined(__AVR_ATmega406__) \ || defined(__AVR_ATmega8HVA__) \ || defined(__AVR_ATmega16HVA__) \ || defined(__AVR_ATmega16HVA2__) \ || defined(__AVR_ATmega16HVB__) \ || defined(__AVR_ATmega32HVB__) \ || defined(__AVR_ATmega64HVE__) \ || defined(__AVR_ATtiny261__) || defined(__AVR_ATtiny261A__) \ || defined(__AVR_ATtiny461__) || defined(__AVR_ATtiny461A__) \ || defined(__AVR_ATtiny861__) || defined(__AVR_ATtiny861A__) \ || defined(__AVR_ATtiny2313__) || defined(__AVR_ATtiny2313A__) \ || defined(__AVR_ATtiny4313__) \ || defined(__AVR_ATtiny13__) || defined(__AVR_ATtiny13A__) \ || defined(__AVR_ATtiny25__) \ || defined(__AVR_ATtiny45__) \ || defined(__AVR_ATtiny85__) \ || defined(__AVR_ATtiny24__) || defined(__AVR_ATtiny24A__) \ || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny44A__) \ || defined(__AVR_ATtiny84__) \ || defined(__AVR_ATtiny43U__) \ || defined(__AVR_ATtiny48__) || defined(__AVR_ATtiny88__) \ || defined(__AVR_ATtiny87__) || defined(__AVR_ATtiny167__) # define PIN_TOGGLE_BY_PIN_WRITE 1 #else # define PIN_TOGGLE_BY_PIN_WRITE 0 #endif

Там два разных примера и смысл там, насколько я понимаю, такой: Первый пример - традиционный с условным переходом, где каждая ветка имеет свои уникальные инструкции, помимо общих инструкций проверки условия и условного перехода. Второй пример - линейный с использованием условного выполнения на стадии каждой инструкции и если инструкция не нужна, она трактуется как NOP и выполняется за 1 такт - чудес не бывает))). Второй лучше тем, что линейный и не требует перезагрузки конвейера, как в случае с переходом, а так же не тратит время на сам переход. Первый лучше тем, что работает на всех ARM Cortem-M, включая M0.

Используйте union

В таких система обычно весь flash без разбора копируется в ОЗУ задолго да cstartup.

Если __ramfunc, то как раз все данные должны быть только в оперативке... Например бутлоадер, который пишет во flash, не должен затрагивать данных из того-же flash. Поэтому проще было убрать в приведённом примере слово static и слово const вовсе - результат был бы такой же, а буков меньше.

В Питере http://www.npsic.ru/

Время покажет. Факт есть факт - в gcc уже реализовано и мало помалу обкатывается.

Согласен. Бываю грешен.

Пусть generic - общий. Что от это изменилось? Си он и в африке Си и теперь в нём есть часть (читай глава) затрагивающая ембед. А на gcc я ссылаюсь от того что это чуть-ли не единственный (ну может быть clang ещё) доступный, открытый и ОЧЕНЬ распространнённый компилятор для огромного количества архитектур. Люди, разрабатывающие его являются членами комитета, утверждающего и разрабатывающего стандарт Си. Чем не автортет? Не согласны - приведите свои доводы. Не нравится как я излагаю - читайте прикреплённые мной ссылки на оригиналы статей. Ради этого я их и прилагаю.

С вами бесполезно разговаривать - это Вы к AVR и flash привязались, не удосужившись прочесть представленные ссылки. Всё о чём я написал напрямую относится к GCC в общем который, если Вы не в курсе, раньше всех коммерческих продуктов реализует новые возможности языка. Мы используем в своих разработках GCC для множества архитектур, и по мере возможности делаем его и libc лучше. И мне очень странно слушать Ваши непонятные высказывания. На этом с Вами разговор считаю законченным, пребывайте в осознании своего всезнания и далее. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1275.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1005.pdf Вдогонку: OpenCL основан на С99 и тоже использует схожие принципы что и Си для ембеда в части адресных пространств. https://software.intel.com/en-us/articles/t...ce-in-opencl-20

Я не про плюсы и говорю. И ступор не в плюсах. const char __flash* const __flash names[] = { "aaa", "bbb", "ccc" }; не работает, а по всей здравой логике должно. но народ упёрся и говорит, что нарушать стандарт не будем.

Если Вы не в теме, то это не означает, что этого нет. https://gcc.gnu.org/onlinedocs/gcc-4.7.0/gc...-Address-Spaces В настоящий момент в GCC именно на этой почве случился ступор. Разработчики avr-gcc не могут сделать так, чтобы по возможности константные данные автоматом ложились во флэш именно из-за того, что стандарт в настоящее время этого не разрешает. Если интересно - скачайте стандарт c11.

Согласно стандарту языка Си константные данные обязаны лечь в основное адресное пространство - всё. А куда они лягут - об этом более нет ни слова. Кстати, задумайтесь над тем что будет если константные данные всегда будут лежать во флэш и чем это чревато для архитектуры AVR и не только... Совершенно легальный код станет невозможен: char str1[] = "xxx"; const char str2[] = "yyyy"; extern void print_str(const char* str); print_str(str1); // норм print_str(str2); // попа Или так будет делать бессмысленно: volatite const int uptime; Это я к чему - крутить параметры в скриптах линкера надо не с шашой наголо, а очень и очень вдумчиво...

Нет не должен т.к. .rodata не всегда ассоциируется с FLASH. Более того в avr-gcc нет секции .rodata http://www.nongnu.org/avr-libc/user-manual/mem_sections.html http://www.nongnu.org/avr-libc/user-manual/malloc.html