[mdmitry 0]

Так возьмите и допишите. Это не архисложная задача - читать даташит и вписывать из него #define, она не требует знания потрохов компилятора. А чтобы другие не изобретали велосипед - поделитесь результатом своих трудов.

Есть один момент, который сильно смущает. Насколько я представляю, в gcc принята некоторая система в организации заголовочных файлов, связанных с функциональными модулями (usart и другие). Для конкретного контроллера заголовочных файлов несколько и они связаны между собой через определения доступной периферии. Имеется прецедент в виде файла gpio_5xxx.h специально для этой серии. На мой взгляд и остальная периферия получается в этом же виде (отдельные файлы hardmodulname_54xxx.h). НО это есть отклонение от изначальной системы, похоже на латание дыр для совместимости с предыдущими семействами.

Поправьте в чем не прав.

[Сергей Борщ 119]

Имеется прецедент в виде файла gpio_5xxx.h специально для этой серии. На мой взгляд и остальная периферия получается в этом же виде (отдельные файлы hardmodulname_54xxx.h).

Ну usi.h и usci.h ведь не смущают - разная периферия, разные файлы. Периферия семейства 5xxx настолько существенно отличается от предыдущих семейств, что мне показалось логичным вынести ее в отдельный файл. Может название не совсем уданое, но ничего лучше в голову не пришло.

похоже на латание дыр для совместимости с предыдущими семействами.

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

[mdmitry 0]

Ну usi.h и usci.h ведь не смущают - разная периферия, разные файлы. Периферия семейства 5xxx настолько существенно отличается от предыдущих семейств, что мне показалось логичным вынести ее в отдельный файл. Может название не совсем уданое, но ничего лучше в голову не пришло.Есть предложения как улучшить - пишите в список рассылки, там последний год оживление наблюдается.

Смущает то, что напрашивается usi_54xx.h и т.д.

ВСЁ для этого семейства специфично и плохо стыкуется с имеющейся структурой файлов. Получается, что проект с другого контроллера нельзя практически перевести на это семейство, сменив только тип контроллера в makefile (расширенная периферия для совместимости предположительно не используется). Потребуется имена включаемых файлов изменять. Если такую переносимость во внимание не принимать, то всё годится.

hardmodulename_54xx.h вполне понятное название.

Предложений по улучшению, к сожалению, нет, одни сомнения.

[Сергей Борщ 119]

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

Ой!

В проект включается только io.h. Из него, в зависимости от ключа -mmcu, автоматически включается нужный msp430fxxx.h, а уже из него тоже автоматически все необходимые файлы периферии.

[mdmitry 0]

В проект включается только io.h. Из него, в зависимости от ключа -mmcu, автоматически включается нужный msp430fxxx.h, а уже из него тоже автоматически все необходимые файлы периферии.

?????

io.h -> msp430x54xx.h ->iomacros.h ->sys/inttypes.h

msp430/wdt_a.h

msp430/sys.h

msp430/gpio_5xxx.h

msp430/mpy32.h

msp430/timera.h

msp430/unified_clock_system.h

msp430/usci.h

 

msp430/timerb.h не включен

Если оставаться в этой системе для заголовочных файлов, то в соответствующие файлы необходимо внести дополнения.

В примерах включен не только io.h.

 

В winavr точно приходилось подключать несколько файлов.

[Сергей Борщ 119]

msp430/timerb.h не включен

 

Если оставаться в этой системе для заголовочных файлов, то в соответствующие файлы необходимо внести дополнения.

Вот потому timerb.h и не включен, что дополнения в него еще не внесены. То есть явно видно - timerb.h надо править или как минимум проверить на совместимость.

В примерах включен не только io.h.

 

В winavr точно приходилось подключать несколько файлов.

Открыл наугад 10 примеров. Во всех включен только io.h. В WinAVR для подключения описания периферии достаточно подключить только io.h. В документации на avr-libc это единственный рекомендуемый способ подключения описания периферии.

[mdmitry 0]

В WinAVR для подключения описания периферии достаточно подключить только io.h.

Именно описания периферии, но не ей же единой. Хочется использовать вс,что есть (таймеры, сторожевой и т.д.).

Если говороить только о доступе к периферии, то io.h и полностью согласен с Вами.

[Сергей Борщ 119]

Хочется использовать вс,что есть (таймеры, сторожевой и т.д.).

То есть функции более высокого уровня (вроде wdt_reset()), уже написанные кем-то? Ну так их тоже можно дополнить до поддержки 5xxx.

[MrYuran 16]

Таки попробовал...

Компилятор что-то компилит.

А вот потом начинаются чудеса:

C:\mspgcc4\bin\msp430-gcc ./Obj/main.o ./Obj/process_MB.o ./Obj/measure.o 
./Obj/temperature.o ./Obj/utils.o ./Obj/TimerB.o ./Obj/flash.o ./Obj/gen.o ./Obj/AD7708.o 
./Obj/mb.o ./Obj/mbcrc.o ./Obj/mbrtu.o ./Obj/portevent.o ./Obj/portserial.o ./Obj/porttimer.o 
./Obj/mbfunccoils.o ./Obj/mbfuncdiag.o ./Obj/mbfuncdisc.o ./Obj/mbfuncholding.o ./Obj/mbfuncinput.o 
./Obj/mbfuncother.o ./Obj/mbutils.o ./Obj/dco.o 
-mmcu=msp430x149 -Wl,--section-start -Wl,.seg_a=0x1080 -Wl,--gc-sections 
-Wl,-Map=9010U.map,--cref -LC:\mspgcc4"\bin\lib" -LC:\mspgcc4"\msp430\lib" 
-LC:\mspgcc4"\msp430\include" -LC:\mspgcc4"\msp430\include\msp430" -Wl,-relax -lc -lm -o 9010U.elf
./Obj/mb.o: In function `abs':
mb.c:(.text.abs+0x0): multiple definition of `abs'
./Obj/TimerB.o:TimerB.c:(.text.abs+0x0): first defined here
c:\mspgcc4\bin\msp430-ld.exe: Disabling relaxation: it will not work with multiple definitions
./Obj/mb.o: In function `labs':
mb.c:(.text.labs+0x0): multiple definition of `labs'
./Obj/TimerB.o:TimerB.c:(.text.labs+0x0): first defined here
./Obj/mbrtu.o: In function `abs':
mbrtu.c:(.text.abs+0x0): multiple definition of `abs'
./Obj/TimerB.o:TimerB.c:(.text.abs+0x0): first defined here
./Obj/mbrtu.o: In function `labs':
mbrtu.c:(.text.labs+0x0): multiple definition of `labs'
./Obj/TimerB.o:TimerB.c:(.text.labs+0x0): first defined here
./Obj/mbfunccoils.o: In function `abs':
mbfunccoils.c:(.text.abs+0x0): multiple definition of `abs'
./Obj/TimerB.o:TimerB.c:(.text.abs+0x0): first defined here
./Obj/mbfunccoils.o: In function `labs':
mbfunccoils.c:(.text.labs+0x0): multiple definition of `labs'
./Obj/TimerB.o:TimerB.c:(.text.labs+0x0): first defined here
./Obj/mbfuncdisc.o: In function `abs':
mbfuncdisc.c:(.text.abs+0x0): multiple definition of `abs'
./Obj/TimerB.o:TimerB.c:(.text.abs+0x0): first defined here
./Obj/mbfuncdisc.o: In function `labs':
mbfuncdisc.c:(.text.labs+0x0): multiple definition of `labs'
./Obj
/TimerB.o:TimerB.c:(.text.labs+0x0): first defined here
./Obj/mbfuncholding.o: In function `abs':
mbfuncholding.c:(.text.abs+0x0): multiple definition of `abs'
./Obj/TimerB.o:TimerB.c:(.text.abs+0x0): first defined here
./Obj/mbfuncholding.o: In function `labs':
mbfuncholding.c:(.text.labs+0x0): multiple definition of `labs'
./Obj/TimerB.o:TimerB.c:(.text.labs+0x0): first defined here
./Obj/mbfuncinput.o: In function `abs':
mbfuncinput.c:(.text.abs+0x0): multiple definition of `abs'
./Obj/TimerB.o:TimerB.c:(.text.abs+0x0): first defined here
./Obj/mbfuncinput.o: In function `labs':
mbfuncinput.c:(.text.labs+0x0): multiple definition of `labs'
./Obj/TimerB.o:TimerB.c:(.text.labs+0x0): first defined here
./Obj/mbfuncother.o: In function `abs':
mbfuncother.c:(.text.abs+0x0): multiple definition of `abs'
./Obj/TimerB.o:TimerB.c:(.text.abs+0x0): first defined here
./Obj/mbfuncother.o: In function `labs':
mbfuncother.c:(.text.labs+0x0): multiple definition of `labs'
./Obj/TimerB.o:TimerB.c:(.text.labs+0x0): first defined here
./Obj/mbutils.o: In function `abs':
mbutils.c:(.text.abs+0x0): multiple definition of `abs'
./Obj/TimerB.o:TimerB.c:(.text.abs+0x0): first defined here
./Obj/mbutils.o: In function `labs':
mbutils.c:(.text.labs+0x0): multiple definition of `labs'
./Obj/TimerB.o:TimerB.c:(.text.labs+0x0): first defined here
collect2: ld returned 1 exit status
mingw32-make.exe: *** [9010U.elf] Error 1
Process terminated with status 2 (0 minutes, 21 seconds)

А вот листинг и мап:

9010U.zip

что за abs и labs - в упор не понимаю...

-fwhole-program вроде работает, но требует, чтобы компилятору скармливались все файла зараз, иначе потом линкер концов не находит.

 

Короче, с ходу не взлетел :(

Со старым всё компилится нормально

[MrYuran 16]

Нашёл предварительно, где копать:

stdlib.h:

 

extern __inline__ int abs(int __x) __ATTR_CONST__;
extern __inline__ int abs(int __x)
{
    return (__x < 0)  ?  -__x  :  __x;
}
         
extern __inline__ long labs(long __x) __ATTR_CONST__;
extern __inline__ long labs(long __x)
{
    return (__x < 0)  ?  -__x  :  __x;
}

 

Ну и каким местом он влезает во все модули, где есть stdlib.h ?

Посмотрел, в старой версии этот файл один-в-один

 

Таки победил :)

Пришлось extern __inline__ заменить на static __inline__

Build project 9010U - OK.

text data bss dec hex filename

20191 72 742 21005 520d 9010U.elf

msp430-gcc (MSPGCC4_r4-20100210) 4.4.3

Copyright © 2010 Free Software Foundation, Inc.

This is free software; see the source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Ну ничего себе "Better optimization. The generated code is typically 7%-10% smaller than code generated by MSPGCC-3.2.3"

- 20k против 12 от предыдущей версии!

[Сергей Борщ 119]

Ну и каким местом он влезает во все модули, где есть stdlib.h ?

Посмотрел, в старой версии этот файл один-в-один

Сочетание extern и __inline__ выглядит, мягко говоря, странным. Возможно старый и новый компиляторы трактуют __inline__ по-разному или в новых заголовочниках где-нибудь стоит строка

#define __inline__

 

20k против 12 от предыдущей версии!

Так там еще куча ключей должна была добавиться. Возможно с ними и получше будет. Пробуйте вот с этими поиграться:

#CFLAGS += -fno-ivopts
CFLAGS += -fno-tree-scev-cprop 
#CFLAGS += -fno-split-wide-types
CFLAGS += -fno-inline-small-functions
CFLAGS += -fno-inline-functions

#adjust --param inline-call-cost= to get minimal code size
CFLAGS += --param inline-call-cost=1
#CFLAGS += -fno-reorder-blocks 
#CFLAGS += -fno-reorder-blocks-and-partition 
#CFLAGS += -fno-reorder-functions 
#CFLAGS += -fno-toplevel-reorder
CFLAGS += -fno-move-loop-invariants
#CFLAGS += -fno-unroll-loops
#CFLAGS += -fno-unroll-all-loops
#CFLAGS += --param max-unroll-times=0

Очень влияет --param inline-call-cost=, причем на разных исходниках оптимум дают разные значения.

[MrYuran 16]

Сочетание extern и __inline__ выглядит, мягко говоря, странным.

Ну, не я ж это придумал!

За ключики спасибо, буду играться.

Предыдущий результат был с -O3.

-Os даёт 13к против 12.7к, опять не в пользу 4 версии :(

Так и не понял, к какому месту DWARF2 прикручивать...

Но в целом прогресс (с прошлого года) заметен.

Даже установщик кой-какой приделали.

В файлах периферии виднеются F5xx, СС430 и G2xx

 

Да, и это надо ещё на железке прогнать.

Старый компилятор, хоть и не без глюков, но собирал рабочие бинарники. Этот - пока не знаю.

[AHTOXA 14]

Ну ничего себе "Better optimization. The generated code is typically 7%-10% smaller than code generated by MSPGCC-3.2.3"

- 20k против 12 от предыдущей версии!

Это общая тенденция - 4й GCC генерит больший код, чем 3й. Хотя 20 против 12 - это явный перебор.

[MrYuran 16]

За ключики спасибо, буду играться.

Build project 9010U - OK.
   text       data        bss        dec        hex    filename
  14413         72        742      15227       3b7b    9010U.elf

Уже лучше!

Это -O2

   text       data        bss        dec        hex    filename
  13077         72        742      13891       3643    9010U.elf

-Os

Совсем тепло...

[demiurg_spb 0]

Это общая тенденция - 4й GCC генерит больший код, чем 3й. Хотя 20 против 12 - это явный перебор.

Неа. Всё же со всеми новыми способами оптимизации 4й GCC получается получше 3-его.