Проект << lcs 8051 ide >>

ну, хорошо. Начнем. :)

Имеем практически не изученный компилятор SDCC, который "теоретически" нам подходит.
Он бесплатен, лицензия позволяет создавать закрытый код.
Нужно сделать оболочку в которой было бы удобно создавать проекты для микроконтроллеров фирмы Analog Devices (серии 800) имеющих ядро Intel 8052.
В принципе, в последствии, список должен быть расширен для МК SiLabs и Atmel, также имеющих ядро процессора 8052.
Результатом работы среды программирования LCS 8051 IDE + SDCC должен быть файл в формате HEX, который будет загружаться в МК загрузчиком - по нажатию кнопки Download на панели инструментов.
Симуляторы, Эмуляторы, Дебаггеры и прочие "штучки" пока не планируем. Это в перспективе.


Верхний ряд меню закладок должен иметь вид:

1. File
2. Edit
3. Search
4. Project
5. Tool
6. Debug
7. Options
8. Window
9. Help

Я думаю имеет смысл перенести тему в раздел "Проекты участников форума".

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

Когда этот проект будет закончен, тогда можно будет туда переложить.
Сейчас он находится в разделе "Встраиваемые технологии" + "8052", что наиболее точно определяет сферу применения.
Пмсм, сейчас это наиболее правильно.
Хотя мне всеравно - можно и туда его положить сразу. Мне, так то, без разницы где он будет лежать. :)

Вот так выглядел файл конфигурации программы C Free 5, когда я подключил к нему досовский компилятор ICC8051.
Можно по аналогии сделать.


<Builder name="C51" type="8052" version="1.0">
<IncPaths>
<Path>C:\C8051\include\</Path>
<Pattern>*\include\</Pattern>
</IncPaths>
<LibPaths>
<Path>C:\C8051\lib</Path>
<Pattern>*\lib</Pattern>
</LibPaths>
<ExePaths>
<Path>C:\C8051</Path>
<Pattern>*\</Pattern>
</ExePaths>
<AutoDetect>
<Path>C:\C8051\</Path>
<Reg>\SOFTWARE\CodeBlocks|Path</Reg>
<Reg>\SOFTWARE\Microsoft\Windows\CurrentVersion\Un install\MinGW_is1|Inno Setup: App Path</Reg>
<Reg>\SOFTWARE\Microsoft\Windows\CurrentVersion\Un install\MinGW|InstallLocation</Reg>
</AutoDetect>

<CompilerOptions>
<Category name="Memory model">
<Option value="-mt" desc="Select memory model: tiny [-mt]"/>
<Option value="-ms" desc="Select memory model: small [-ms]"/>
<Option value="-mc" desc="Select memory model: compact [-mc]"/>
<Option value="-mm" desc="Select memory model: medium [-mm]"/>
<Option value="-ml" desc="Select memory model: large [-ml]"/>
<Option value="-mb" desc="Select memory model: banked [-mb]"/>
</Category>
<Category name="Debugging">
<Option value="-b" desc="Make object a library module [-b]"/>
<Option value="-P" desc="Generate PROMable code [-P]"/>
<Option value="-u" desc="Function return stack expansion [-u]"/>
<Option value="-g0" desc="Disable object code type-info [-g0]"/>
<Option value="-gA" desc="Depreaciate K&K-style function [-gA]"/>
</Category>
<Category name="Warnings">
<Option value="-e" desc="Disable warnings’ [-e]"/>
</Category>
<Category name="Optimization">
<Option value="-z" desc="optimize for size (default) [-z]"/>
<Option value="-s" desc="optimize for speed [-s]"/>
</Category>
<RawOptionsDebug enabled="1">
<Default></Default>
<User>-ml -P -i -g -x</User>
</RawOptionsDebug>
<RawOptionsRelease enabled="0">
<Default></Default>
<User>-ml -P -i -g -x</User>
</RawOptionsRelease>
</CompilerOptions>
<LinkerOptions>
<LibsDebug enabled="1">
<Default></Default>
<User><Lib>C:\C8051\lib\CL8051L.R03</Lib></User>
</LibsDebug>
<LibsRelease enabled="0">
<Default></Default>
<User><Lib></Lib></User>
</LibsRelease>
<RawOptionsDebug enabled="1">
<Default></Default>
<User>-z -x -B</User>
</RawOptionsDebug>
<RawOptionsRelease enabled="0">
<Default></Default>
<User>-z -x -B</User>
</RawOptionsRelease>
</LinkerOptions>
<Configs>
<BuildLog enabled="1">$(PrjDir)\Build.log</BuildLog>
<LibExt>r03</LibExt>
<ObjExt>r03</ObjExt>
<ResExt>hex</ResExt>
</Configs>
<Commands msghandler="Dm.mhr">
<Command name="ICC8051" io="1" rdos="0" sys="0">
<Program enabled="1">ICC8051.exe</Program>
<Parameter enabled="1"> $(CompilerOptions) $(FileName) -I$(IncPaths) -a $(ExePaths)work\dolly5.S03 -l $(Paths)dolly5.lst</Parameter>
<FileExt enabled="1">c</FileExt>
<Target>$(ExePaths)work\dolly5.s03</Target>
<TargetType>s03</TargetType>
<CurrentDir>$(FilePath)</CurrentDir>
<EnvVar></EnvVar>
<MsgID>Compiling....$(FILENAME)...#81001</MsgID>
</Command>
<Command name="A8051" io="1" rdos="0" sys="0">
<Program enabled="1">asm.bat</Program>
<Parameter enabled="0"> </Parameter>
<FileExt enabled="1">s03</FileExt>
<Target>$(ExePaths)work\dolly6.r03</Target>
<TargetType>r03</TargetType>
<CurrentDir>$(FilePath)</CurrentDir>
<EnvVar></EnvVar>
<MsgID>Asm..........#81003</MsgID>
</Command>
<Command name="Linker" io="1" rdos="0" sys="0">
<Program enabled="1">XLINK.exe</Program>
<Parameter enabled="1"> $(ExePaths)work\dolly6.r03 -f $(ExePaths)xcl\LNK8051.xcl $(LinkerOptions) -l $(ExePaths)work\dolly7.lst -o $(ExePaths)work\$(Name).hex</Parameter>
<FileExt enabled="1">r03</FileExt>
<Target>$(ExePaths)work\$(Name).hex</Target>
<TargetType>hex</TargetType>
<CurrentDir>$(FilePath)</CurrentDir>
<EnvVar></EnvVar>
<MsgID>Linking........#81004</MsgID>
</Command>
</Commands>
<Actions>
<Action name="Compile" depend="1">
<File><Command>"ICC8051"</Command></File>
<Project>
</Project>
<MsgID>Complete Compile $(FileName): $(Error) error(s), $(Warning) warning(s)\nGenerated $(Target)#81005</MsgID>
<ErrMsgID>Complete Compile $(FileName): $(Error) error(s), $(Warning) warning(s)#81006</ErrMsgID>
<PreAction></PreAction>
<PostAction con="0"></PostAction>
</Action>
<Action name="Build" depend="0">
<File> <Command>"ICC8051""A8051""Linker"</Command>
</File>
<Project>
</Project>
<MsgID>Complete Build $(TargetName): $(Error) error(s), $(Warning) warning(s)\nGenerated $(Target)#81007</MsgID>
<ErrMsgID>Complete Build $(TargetName): $(Error) error(s), $(Warning) warning(s)#81008</ErrMsgID>
<PreAction></PreAction>
<PostAction con="0"></PostAction>
</Action>
<Action name="Make" depend="1">
<File>
</File>
<Project>
<Command>"ICC8051""A8051""Linker"</Command>
</Project>
<MsgID>Complete Make $(TargetName): $(Error) error(s), $(Warning) warning(s)\nGenerated $(Target)#81009</MsgID>
<ErrMsgID>Complete Make $(TargetName): $(Error) error(s), $(Warning) warning(s)#81010</ErrMsgID>
<PreAction></PreAction>
<PostAction con="0"></PostAction>
</Action>
</Actions>
</Builder>

Так выглядели строки командных файлов (.bat) для запуска в пакетном режиме:

компилятора:
icc8051.exe -ml c:\c8051\c\dolly4.c -P -i -g -x -Ic:\c8051\include\ -a c:\c8051\work\dolly5.s03 -l c:\c8051\work\dolly5.lst

ассемблера:
a8051.exe c:\c8051\work\dolly5, c:\c8051\work\dolly6.lst, c:\c8051\work\dolly6.r03, X, F, W, S

линкера:
XLINK c:\c8051\work\dolly6.r03 -f c:\c8051\xcl\lnk8051.xcl -z -x -B -l c:\c8051\work\dolly7 -o c:\c8051\work\dolly8.hex

Поочередное выполнение файлов и ничего больше кроме этого.

Дэфис с буквой это команда (ключ) компилятора.
Если любой пакетный "инструмент" (компилятор, ассемблер, линкер) запустить с со специальным ключом, типа "-?" (могут быть разные) то сам компилятор (ассемблер, линкер) выдает распечатку свих команд в текстовом режиме.

У них у всех свой формат входных и выходных данных, которые описываются при вызове - это даже в самых самых виндовых продуктах внутри всеравно так работает.
На пример, для линкера XLINK первый параметр путь и имя файла в формате соотв. результатм работы ассемблера .r03 (c:\c8051\work\dolly6.r03)
Путь -f c:\c8051\xcl\lnk8051.xcl указывает на файл с раширением .xcl в котором лежат инструкции для линкера.

Путь -o c:\c8051\work\dolly8.hex это путь куда будет положен результат работы, этот формат понимает программатор и этот файл может быть загружен в МК.


Содержание файла "lnk8051.xcl":
__________________________________________________ ___________

-! -LNK8051.XCL-

Командный файл для XLINK 4.2x для использования с
компилятором Си 8051 V4.xx. Модель памяти может
быть -mt, -ms, -mc, -mm или -ml.
Запуск: XLINK <об'ектный файл(ы)> -f lnk8051
Первое: укажем ЦПУ -!

-c8051

-! Выбор банка рабочих регистров [0,8,10 or 18] -!

-D_R=0

-! Разместить сегменты "bit" (всегда с нуля, если не нужно резервировать
битовую память для других целей) -!

-Z(BIT)C_ARGB,BITVARS=0

-! Разместить сегменты "data". Начальный адрес не должен быть
меньше, чем _R+8 (адрес используемого банка рабочих регистров + 8).
Следует также оставить место, если используются функции interrupt
с атрибутом "using". Например, если _R=0 и определена функция-
прерывание "using [1]", то начальный адрес должен быть 10h. -!

-Z(DATA)C_ARGD,D_UDATA,D_IDATA=8

-! Разместить сегменты "idata" (обычно загружаются после "data") -!

-Z(IDATA)C_ARGI,I_UDATA,I_IDATA,CSTACK


-! Разместить сегменты "xdata" на начальный адрес внешнего ОЗУ данных.
Это об'явление не является ошибочным, даже если применена модель
памяти, не использующая внешнее ОЗУ данных. -!

-Z(XDATA)C_ARGX,X_UDATA,X_IDATA,ECSTR,RF_XDATA=0

-! Разместить все сегменты, находящиеся в ПЗУ памяти программ (обычно с 0) -!

-Z(CODE)INTVEC,RCODE,D_CDATA,I_CDATA,X_CDATA,C_ICAL L,C_RECFN,CSTR,CCSTR,CODE,CONST=0


-! Выбор форматизатора для функций printf/sprintf (см. приложение к
описанию компилятора Си -!

-e_small_write=_formatted_write

-! Выбор форматизатора для функций scanf/sscanf (см. приложение к
описанию компилятора Си -!

-e_medium_read=_formatted_read

-! Загрузить библиотеку, соответствующую использовавшейся при
компиляции модели памяти -!

C:\C8051\OBJ\CL8051L -! or cl8051s, cl8051c, cl8051m, cl8051t -!

-! Опция включения отладочной информации в выходной файл -!
-FMPDS-I

__________________________________________________ ______________________

Все эти настройки можно задавть в IDE с использованием "красивых кнопеней" - но результатом работы IDE всеравно будет этот файл. Потому как линкеру "начихать" - какого у вас цвета кнопки. Линкеру подавай в нужном фомате все данные. :)

Если внимательно посмотреть в файле конфигурации C Free 5, то там просто ключи вставляются вместо понятных человеку строк в нужных местах IDE.

<CompilerOptions>
<Category name="Memory model">
<Option value="-mt" desc="Select memory model: tiny [-mt]"/>
<Option value="-ms" desc="Select memory model: small [-ms]"/>
<Option value="-mc" desc="Select memory model: compact [-mc]"/>
<Option value="-mm" desc="Select memory model: medium [-mm]"/>
<Option value="-ml" desc="Select memory model: large [-ml]"/>
<Option value="-mb" desc="Select memory model: banked [-mb]"/>

Можно пока потренироваться на ICC8051, т.к. есть пример и все настроено в пакетном режиме.
В SDCC все то же самое - но возможно в качестве ключей используются другие буквы или их комбинации.
По аналогии легко перетащить все.


<Parameter enabled="1"> $(CompilerOptions) $(FileName) -I$(IncPaths) -a $(ExePaths)work\dolly5.S03 -l $(Paths)dolly5.lst</Parameter>

$(ExePaths) - также подставляется IDE путь на заданную директорию, папку где хранятся экзэшники компилятора.
$(Target) - директория куда помещается результат работы - т.е. HEX файл. $(TargetName) - имя этого файла.
$(IncPaths) - адрес директории INC где хранятся файлы конфигурации микроконтроллеров. Когда в проекте выбираем фирму изготовитель МК, то соответственно подставляется путь на папку где лежат файлы описывающие МК этой фирмы. Когда мы выбираем определенный МК, например ADUC848, то в конец этого пути прописывается имя файла "ADUC848.H" - цепь замкнулась.
Ну и так далее.
Т.е. сама по себе IDE ничего не делает - просто "тасует" то что мы выбираем и вставляет в нужные места.


Конструкция Parameter enabled="1" обозначает что эта строка применяется.
Если Parameter enabled="0" - то строка игнорируется. Это очень удобно.

В закладке File обычно бывает:

1. New Ctrl+N
2. Open Ctrl+O
3. Close Ctrl+F4
5. Save Ctrl+S
6. Save all
7. Save as...
8. Print Ctrl+P
9. Print Setup...
10. Exit

Конечно можно их тасовать и по другому называть, но функционально это должно быть.

В закладке Edit обычно бывает:

1. Undo Ctrl+Z
2. Cut Ctrl+X
3. Copy Ctrl+C
4. Paste Ctrl+V

Тут лежит описание компилятора, ассемблера, линкера - на русском языке, кстати.
http://rfcd.ru/forum/showthread.php?...FF-%CC%CA-8051

Имхо, не стоит засовывать компилятор SDCC в программу C Free 5.
(С этим продуктом китаец немного обманул нас. Хотя формально не к чему придраться.)

Нужно сразу свое IDE делать и там все известные компиляторы (которые бесплатные) подключать.
И не только для 8051 но и для ARM. Это тоже перспективно сейчас.
Что бы можно было выбирать эти компиляторы.

ОК. Не будем пеарить тут это C Free 5.

если будет АРМ, тогда название LCS 8051 IDE не правильное? Может пока временно назвать LCS_IDE?
А позже возможно придумаем другое название?
Как то его нужно называть... :)

SDCC

3.2 Command Line Options
3.2.1 Processor Selection Options
-mmcs51 Generate code for the Intel MCS51 family of processors. This is the default processor target.

3.2.2 Preprocessor Options
SDCC uses an adapted version of the GNU Compiler Collection preprocessor cpp (gcc http://gcc.gnu.
org/). If you need more dedicated options than those listed below please refer to the GCC CPP Manual at
http://www.gnu.org/software/gcc/onlinedocs/.
-I<path> The additional location where the preprocessor will look for <..h> or “..h” files.
-D<macro[=value]> Command line definition of macros. Passed to the preprocessor.
-M Tell the preprocessor to output a rule suitable for make describing the dependencies of each object file.
For each source file, the preprocessor outputs one make-rule whose target is the object file name for
that source file and whose dependencies are all the files ‘#include’d in it. This rule may be a single line
or may be continued with ‘\’-newline if it is long. The list of rules is printed on standard output instead
of the preprocessed C program. ‘-M’ implies ‘-E’.
-C Tell the preprocessor not to discard comments. Used with the ‘-E’ option.
-MM Like ‘-M’ but the output mentions only the user header files included with ‘#include “file"’. System
header files included with ‘#include <file>’ are omitted.
-Aquestion(answer) Assert the answer answer for question, in case it is tested with a preprocessor conditional
such as ‘#if #question(answer)’. ‘-A-’ disables the standard assertions that normally describe the target
machine.
-Umacro Undefine macro macro. ‘-U’ options are evaluated after all ‘-D’ options, but before any ‘-include’ and
‘-imacros’ options.
-dM Tell the preprocessor to output only a list of the macro definitions that are in effect at the end of
preprocessing. Used with the ‘-E’ option.
-dD Tell the preprocessor to pass all macro definitions into the output, in their proper sequence in the rest
of the output.
-dN Like ‘-dD’ except that the macro arguments and contents are omitted. Only ‘#define name’ is included
in the output.
-pedantic-parse-number Pedantic parse numbers so that situations like 0xfe-LO_B(3) are parsed properly and the
macro LO_B(3) gets expanded. See also #pragma pedantic_parse_number on page 60 in section3.19
Note: this functionality is not in conformance with C99 standard!
-Wp preprocessorOption[,preprocessorOption]... Pass the preprocessorOption to the preprocessor sdcpp.

3.2.3 Linker Options

-L --lib-path <absolute path to additional libraries> This option is passed to the linkage editor’s additional libraries
search path. The path name must be absolute. Additional library files may be specified in the command
line. See section Compiling programs for more details.
--xram-loc <Value> The start location of the external ram, default value is 0. The value entered can be in Hexadecimal
or Decimal format, e.g.: --xram-loc 0x8000 or --xram-loc 32768.
--code-loc <Value> The start location of the code segment, default value 0. Note when this option is used the
interrupt vector table is also relocated to the given address. The value entered can be in Hexadecimal
or Decimal format, e.g.: --code-loc 0x8000 or --code-loc 32768.
--stack-loc <Value> By default the stack is placed after the data segment. Using this option the stack can be
placed anywhere in the internal memory space of the 8051. The value entered can be in Hexadecimal
or Decimal format, e.g. --stack-loc 0x20 or --stack-loc 32. Since the sp register is incremented before
a push or call, the initial sp will be set to one byte prior the provided value. The provided value should
not overlap any other memory areas such as used register banks or the data segment and with enough
space for the current application. The --pack-iram option (which is now a default setting) will override
this setting, so you should also specify the --no-pack-iram option if you need to manually place the
stack.
--xstack-loc <Value> By default the external stack is placed after the pdata segment. Using this option the xstack
can be placed anywhere in the external memory space of the 8051. The value entered can be in
Hexadecimal or Decimal format, e.g. --xstack-loc 0x8000 or --stack-loc 32768. The provided value
should not overlap any other memory areas such as the pdata or xdata segment and with enough space
for the current application.
--data-loc <Value> The start location of the internal ram data segment. The value entered can be in Hexadecimal
or Decimal format, eg. --data-loc 0x20 or --data-loc 32. (By default, the start location of the internal
ram data segment is set as low as possible in memory, taking into account the used register banks and
the bit segment at address 0x20. For example if register banks 0 and 1 are used without bit variables,
the data segment will be set, if --data-loc is not used, to location 0x10.)
--idata-loc <Value> The start location of the indirectly addressable internal ram of the 8051, default value is 0x80.
The value entered can be in Hexadecimal or Decimal format, eg. --idata-loc 0x88 or --idata-loc 136.
--bit-loc <Value> The start location of the bit addressable internal ram of the 8051. This is not implemented yet.
Instead an option can be passed directly to the linker: -Wl -bBSEG=<Value>.
--out-fmt-ihx The linker output (final object code) is in Intel Hex format. This is the default option. The format
itself is documented in the documentation of srecord.
--out-fmt-s19 The linker output (final object code) is in Motorola S19 format. The format itself is documented in
the documentation of srecord.
--out-fmt-elf The linker output (final object code) is in ELF format. (Currently only supported for the HC08 and
S08 processors)
-Wl linkOption[,linkOption]... Pass the linkOption to the linker. If a bootloader is used an option like ”-Wl -
bCSEG=0x1000” would be typical to set the start of the code segment. Either use the double quotes
around this option or use no space (e.g. -Wl-bCSEG=0x1000). See also #pragma constseg and
#pragma codeseg in section3.19. File sdcc/sdas/doc/asxhtm.html has more on linker options.

3.2.4 MCS51 Options

--model-small Generate code for Small model programs, see section Memory Models for more details. This is the
default model.
--model-medium Generate code for Medium model programs, see section Memory Models for more details. If
this option is used all source files in the project have to be compiled with this option. It must also be
used when invoking the linker.
--model-large Generate code for Large model programs, see section Memory Models for more details. If this
option is used all source files in the project have to be compiled with this option. It must also be used
when invoking the linker.
--model-huge Generate code for Huge model programs, see section Memory Models for more details. If this
option is used all source files in the project have to be compiled with this option. It must also be used
when invoking the linker.
--xstack Uses a pseudo stack in the pdata area (usually the first 256 bytes in the external ram) for allocating
variables and passing parameters. See section 3.18.1.2 External Stack for more details.
--iram-size <Value> Causes the linker to check if the internal ram usage is within limits of the given value.
--xram-size <Value> Causes the linker to check if the external ram usage is within limits of the given value.
--code-size <Value> Causes the linker to check if the code memory usage is within limits of the given value.
--stack-size <Value> Causes the linker to check if there is at minimum <Value> bytes for stack.
--pack-iram Causes the linker to use unused register banks for data variables and pack data, idata and stack
together. This is the default and this option will probably be removed along with the removal of --nopack-
iram.
--no-pack-iram (deprecated) Causes the linker to use old style for allocating memory areas. This option is now
deprecated and will be removed in future versions.
--acall-ajmp Replaces the three byte instructions lcall/ljmp with the two byte instructions acall/ajmp. Only use
this option if your code is in the same 2k block of memory. You may need to use this option for some
8051 derivatives which lack the lcall/ljmp instructions..

3.2.8 Optimization Options
--nogcse Will not do global subexpression elimination, this option may be used when the compiler creates
undesirably large stack/data spaces to store compiler temporaries (spill locations, sloc). A warning
message will be generated when this happens and the compiler will indicate the number of extra bytes
it allocated. It is recommended that this option NOT be used, #pragma nogcse can be used to turn off
global subexpression elimination for a given function only.
--noinvariant Will not do loop invariant optimizations, this may be turned off for reasons explained for the previous
option. For more details of loop optimizations performed see Loop Invariants in section 8.1.4. It
is recommended that this option NOT be used, #pragma noinvariant can be used to turn off invariant
optimizations for a given function only.
--noinduction Will not do loop induction optimizations, see section strength reduction for more details. It is
recommended that this option is NOT used, #pragma noinduction can be used to turn off induction
optimizations for a given function only.
--nojtbound Will not generate boundary condition check when switch statements are implemented using jumptables.
See section 8.1.7 Switch Statements for more details. It is recommended that this option is
NOT used, #pragma nojtbound can be used to turn off boundary checking for jump tables for a given
function only.
--noloopreverse Will not do loop reversal optimization.
--nolabelopt Will not optimize labels (makes the dumpfiles more readable).
--no-xinit-opt Will not memcpy initialized data from code space into xdata space. This saves a few bytes in code
space if you don’t have initialized data.
--nooverlay The compiler will not overlay parameters and local variables of any function, see section Parameters
and local variables for more details.
--no-peep Disable peep-hole optimization with built-in rules.
--peep-file <filename> This option can be used to use additional rules to be used by the peep hole optimizer. See
section 8.1.13 Peep Hole optimizations for details on how to write these rules.
--peep-asm Pass the inline assembler code through the peep hole optimizer. This can cause unexpected changes
to inline assembler code, please go through the peephole optimizer rules defined in the source file tree
’<target>/peeph.def’ before using this option.
--peep-return Let the peep hole optimizer do return optimizations. This is the default without --debug.
--no-peep-return Do not let the peep hole optimizer do return optimizations. This is the default with --debug.
--opt-code-speed The compiler will optimize code generation towards fast code, possibly at the expense of code
size.
--opt-code-size The compiler will optimize code generation towards compact code, possibly at the expense of code
speed.
--fomit-frame-pointer Frame pointer will be omitted when the function uses no local variables.

3.2.9 Other Options

-v --version displays the sdcc version.
-c --compile-only will compile and assemble the source, but will not call the linkage editor.
--c1mode reads the preprocessed source from standard input and compiles it. The file name for the assembler
output must be specified using the -o option.
-E Run only the C preprocessor. Preprocess all the C source files specified and output the results to
standard output.
-o <path/file> The output path where everything will be placed or the file name used for all generated output
files. If the parameter is a path, it must have a trailing slash (or backslash for the Windows binaries)
to be recognized as a path. Note for Windows users: if the path contains spaces, it should be
surrounded by quotes. The trailing backslash should be doubled in order to prevent escaping the final
quote, for example: -o ”F:\Projects\test3\output 1\\” or put after the final quote, for example: -o
”F:\Projects\test3\output 1”\. The path using slashes for directory delimiters can be used too, for
example: -o ”F:/Projects/test3/output 1/”.
--stack-auto All functions in the source file will be compiled as reentrant, i.e. the parameters and local variables
will be allocated on the stack. See section 3.7 Parameters and Local Variables for more details. If
this option is used all source files in the project should be compiled with this option. It automatically
implies --int-long-reent and --float-reent.
--callee-saves function1[,function2][,function3].... The compiler by default uses a caller saves convention for
register saving across function calls, however this can cause unnecessary register pushing and popping
when calling small functions from larger functions. This option can be used to switch the register
saving convention for the function names specified. The compiler will not save registers when calling
these functions, no extra code will be generated at the entry and exit (function prologue and epilogue)
for these functions to save and restore the registers used by these functions, this can SUBSTANTIALLY
reduce code and improve run time performance of the generated code. In the future the compiler (with
inter procedural analysis) will be able to determine the appropriate scheme to use for each function
call. DO NOT use this option for built-in functions such as _mulint..., if this option is used for a library
function the appropriate library function needs to be recompiled with the same option. If the project
consists of multiple source files then all the source file should be compiled with the same --callee-saves
option string. Also see #pragma callee_saves on page 59.
--all-callee-saves Function of --callee-saves will be applied to all functions by default.
--debug When this option is used the compiler will generate debug information. The debug information collected
in a file with .cdb extension can be used with the SDCDB. For more information see documentation
for SDCDB. Another file with a .omf extension contains debug information in AOMF or AOMF51
format which is commonly used by third party tools.
-S Stop after the stage of compilation proper; do not assemble. The output is an assembler code file for
the input file specified.
--int-long-reent Integer (16 bit) and long (32 bit) libraries have been compiled as reentrant. Note by default these
libraries are compiled as non-reentrant. See section Installation for more details.
--cyclomatic This option will cause the compiler to generate an information message for each function in the
source file. The message contains some important information about the function. The number of
edges and nodes the compiler detected in the control flow graph of the function, and most importantly
the cyclomatic complexity see section on Cyclomatic Complexity for more details.
--float-reent Floating point library is compiled as reentrant. See section Installation for more details.
--funsigned-char The default signedness for every type is signed. In some embedded environments the default
signedness of char is unsigned. To set the signess for characters to unsigned, use the option --
funsigned-char. If this option is set and no signedness keyword (unsigned/signed) is given, a char will
be signed. All other types are unaffected.
--main-return This option can be used if the code generated is called by a monitor program or if the main routine
includes an endless loop. This option results in slightly smaller code and saves two bytes of stack
space. The return from the ’main’ function will return to the function calling main. The default setting
is to lock up i.e. generate a ’sjmp .’.
--nostdinc This will prevent the compiler from passing on the default include path to the preprocessor.
--nostdlib This will prevent the compiler from passing on the default library path to the linker.
--verbose Shows the various actions the compiler is performing.
-V Shows the actual commands the compiler is executing.
--no-c-code-in-asm Hides your ugly and inefficient c-code from the asm file, so you can always blame the compiler
--fverbose-asm Include code generator and peep-hole comments in the generated asm files.
--no-peep-comments Don’t include peep-hole comments in the generated asm files even if --fverbose-asm option
is specified.
--i-code-in-asm Include i-codes in the asm file. Sounds like noise but is most helpful for debugging the compiler
itself.
--less-pedantic Disable some of the more pedantic warnings. For more details, see the less_pedantic pragma on
page 59.
--disable-warning <nnnn> Disable specific warning with number <nnnn>.
--Werror Treat all warnings as errors.
--print-search-dirs Display the directories in the compiler’s search path
--vc Display errors and warnings using MSVC style, so you can use SDCC with the visual studio IDE.
With SDCC both offering a GCC-like (the default) and a MSVC-like output style, integration into
most programming editors should be straightforward.
--use-stdout Send errors and warnings to stdout instead of stderr.
-Wa asmOption[,asmOption]... Pass the asmOption to the assembler. See file sdcc/sdas/doc/asxhtm.html for
assembler options.cd
--std-sdcc89 Generally follow the C89 standard, but allow SDCC features that conflict with the standard (default).
--std-c89 Follow the C89 standard and disable SDCC features that conflict with the standard.
--std-sdcc99 Generally follow the C99 standard, but allow SDCC features that conflict with the standard (incomplete
support).
--std-c99 Follow the C99 standard and disable SDCC features that conflict with the standard (incomplete support).
--codeseg <Name> The name to be used for the code segment, default CSEG. This is useful if you need to tell the
compiler to put the code in a special segment so you can later on tell the linker to put this segment in
a special place in memory. Can be used for instance when using bank switching to put the code in a
bank.
--constseg <Name> The name to be used for the const segment, default CONST. This is useful if you need to tell
the compiler to put the const data in a special segment so you can later on tell the linker to put this
segment in a special place in memory. Can be used for instance when using bank switching to put the
const data in a bank.
--fdollars-in-identifiers Permit ’$’ as an identifier character.
--more-pedantic Actually this is not a SDCC compiler option but if you want more warnings you can use a separate
tool dedicated to syntax checking like splint http://www.splint.org. To make your source
files parseable by splint you will have to include lint.h in your source file and add brackets around extended
keywords (like ”__at (0xab)” and ”__interrupt (2)”).
Splint has an excellent on line manual at http://www.splint.org/manual/ and it’s capabilities
go beyond pure syntax checking. You’ll need to tell splint the location of SDCC’s include files so
a typical command line could look like this:
splint -I /usr/local/share/sdcc/include/mcs51/ myprogram.c
--short-is-8bits Treat short as 8-bit (for backward compatibility with older versions of compiler - see section 1.5)
--use-non-free Search / include non-free licensed libraries and header files, located under the non-free directory -
see section 2.3

3.2.10 Intermediate Dump Options

The following options are provided for the purpose of retargetting and debugging the compiler. They provide a
means to dump the intermediate code (iCode) generated by the compiler in human readable form at various stages
of the compilation process. More on iCodes see chapter 9.1 ”The anatomy of the compiler”.
--dumpraw This option will cause the compiler to dump the intermediate code into a file of named <source
filename>.dumpraw just after the intermediate code has been generated for a function, i.e. before any
optimizations are done. The basic blocks at this stage ordered in the depth first number, so they may
not be in sequence of execution.
--dumpgcse Will create a dump of iCodes, after global subexpression elimination, into a file named <source
filename>.dumpgcse.
--dumpdeadcode Will create a dump of iCodes, after deadcode elimination, into a file named <source filename>.
dumpdeadcode.
--dumploop Will create a dump of iCodes, after loop optimizations, into a file named <source filename>.
dumploop.
--dumprange Will create a dump of iCodes, after live range analysis, into a file named <source filename>.
dumprange.
--dumlrange Will dump the life ranges for all symbols.
--dumpregassign Will create a dump of iCodes, after register assignment, into a file named <source filename>.
dumprassgn.
--dumplrange Will create a dump of the live ranges of iTemp’s
--dumpall Will cause all the above mentioned dumps to be created.

3.2.11 Redirecting output on Windows Shells
By default SDCC writes its error messages to ”standard error”. To force all messages to ”standard output”
use --use-stdout. Additionally, if you happen to have visual studio installed in your windows machine, you
can use it to compile your sources using a custom build and the SDCC --vc option. Something like this should work:
c:\sdcc\bin\sdcc.exe --vc --model-large -c $(InputPath)
3.3 Environment variables
SDCC recognizes the following environment variables:
SDCC_LEAVE_SIGNALS SDCC installs a signal handler to be able to delete temporary files after an user break
(^C) or an exception. If this environment variable is set, SDCC won’t install the signal handler in order
to be able to debug SDCC.
TMP, TEMP, TMPDIR Path, where temporary files will be created. The order of the variables is the search order.
In a standard *nix environment these variables are not set, and there’s no need to set them. OnWindows
it’s recommended to set one of them.
SDCC_HOME Path, see section 2.2 ” Install Paths”.
SDCC_INCLUDE Path, see section 2.3 ”Search Paths”.
SDCC_LIB Path, see section 2.3 ”Search Paths”..
There are some more environment variables recognized by SDCC, but these are mainly used for debugging purposes.
They can change or disappear very quickly, and will never be documented3.

http://mcu-programming.blogspot.ru/2...-for-sdcc.html
Eclipse for SDCC
The combination of Eclipse, CDT and SDCC is an alternation tools for 8051 Microcontroller C Programming.

Если установить это "чудо", то можно посмотреть как у них сделана конфигурация компилятора SDCC (если в эклипсо код открытый).

Вот еще
MIDE-51 Studio: IDE for MCS-51
http://www.opcube.com/home.html#MIDE51

Кстати, вот эта MIDE - похоже урезанный вариант, отсутствуют "проекты" и настройки тоже обрезаны, нет многих полезных функций, но если бы они были, то вполне можно было бы пользоваться. Конфигурационных файлов нет - это тоже большой минус.
А так только игрушка.

Тут пишут про IDE фирмы СиЛабс - на русском языке.
http://www.veinik.ru/science/experim...ticle/382.html
У Силабс она не плохая, но пригодна только для МК этой фирмы. Там у них есть и файл конфигурации, в котором прописаны характеристики всех МК которые поддерживает IDE. Это удобно сделано - вот если бы этот список МК был открытый для всех типов... :)
И еще там "Интегрированный программатор" - он тоже работает только с программатором этой фирмы.

Цитата:

---

Сообщение от friendly

если будет АРМ, тогда название lcs 8051 ide не правильное? Может пока временно назвать lcs_ide?
А позже возможно придумаем другое название?
Как то его нужно называть... :)

---

ПМСМ, удобнее сделать две ide. Одну для 8051, а вторую для arm.
У меня все программы разделены для этих проектов - они по факту не взаимозаменяемые.
Ставлю на виртуальную машину весь софт только для одной платформы и никаких проблем.
Нет смысла сваливать в кучу разные платформы.

ЗЫ Возможность подключения нескольких компиляторов тоже нужно предусмотреть.
Не факт, что кто то будет одновременно использовать сразу все компиляторы. Скорее люди установят один, тот компилятор который нравится или к которому привыкли. Но возможность выбора это большой плюс.

ОК. Пусть будет две.

Вот еще IDE с компилятором - Franklin.
http://www.fsinc.com/devtools/index.htm

У них есть демо вариант позволяющий бесплатно создавать программы до 4 кБайт кода.
Это IDE тоже можно взять за основу - по общей структуре.

ЗЫ Кстати, как пишут в интернете этот продукт служил прототипом для Кейла.
Несложный в применении, при условии что правильно заданы все опции компилятора. Для простых демопроектов все будет работать при настройках проекта по "умолчанию".
Из недостатков это отстутствие файлов настроек IDE для различных микроконтроллеров - программист сам должен "помнить" об особенностях МК. Если вы работаете с небольшим количеством наименований МК одной фирмы производителя, то это "не напрягает".
Если добавить такой файл (например, как это сделано в IDE SiLabs или в Keil) то
это упростит работу для программиста.
Неплохо бы сделать гибкой систему подключения различных программаторов (например, так же как это реализовано в Keil).
Для МК 8051 фирмы Analog Devices для загрузки кода используется пограмма WSD. У этой программы есть возможность работы в пакетном режиме - управление выполняется с помощью ключей (так же как это сделано в ассемблере, компиляторе и линкере).

http://forum.rfcd.ru/showthread.php?1304-IDE-Geany
Может быть эту IDE применить и не "городить огород" (изобретать велосипед)?
Нужно почитать внимательно лицензию.

Пробую настроить CodeBlock с компилятором SDCC.
Пока не получается. Замороченная прога.

Проект закрыли по написанию ИДЕ?

Нуу, вообщем да. М.б. позже, когда нибудь.