demiurg_spb

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

Хочу поделится очень радостной для меня новостью! Отсюда: https://github.com/elfmz/far2l собрал из исходников (по имеющейся на этой странице доке) FAR Manager под Ubuntu! Особенно радует привычный редактор с поддержкой подсветки синтаксиса и различных кодировок.

относится к openocd, а он работает практически с любыми адаптерами.

https://www.olimex.com/Products/ARM/JTAG/_r.../Manual_IAR.pdf

Да. Через openocd.

А что лениво по ссылке перейти, которую я дал и увидеть в списке Kinetis? А STM32F7XX - это cortex-m7, к слову, именно то о чём вопрошает человек в посте №13, на который я, собственно, и ответил.

Cortex-M7 is supported by J-Link Base / Plus V9 and higher J-Link Ultra+ / Pro V4 and higher Также STLINK v2 никто не отменял + http://openocd.org:

На Али за 3500. Торг?

avr-gcc 4.8 и далее имеют встроенный тип FIXED-POINT 64 разряда. IAR может работать и с double на AVR. ПС: ТС про AVR ничего не говорил...

__packed и gcc поддерживаете, но не полностью - он не отрабатывает указатели с квалификатором __packed... У меня так сделано: #if defined(__MINGW32__) # define __packed __attribute__((__gcc_struct__, __packed__, __aligned__(1))) #else # define __packed __attribute__((__packed__, __aligned__(1))) #endif Очень просто. Компилятор, видя такой указатель, сам генерирует правильные инструкции для доступа по невыровненному адресу.

Нет. Это для того чтобы из принятого буфера прочесть переменную с произвольным смещением в этом буфере. Такой вариант никто не предлагал: uint32_t __packed* p = &buff[33]; uint32_t x = *p; Около года назад в gcc эта шляпа не сработала, а в кейле работала.

В openocd есть поддержка ulink-v1 точно! Не знаю совместим ли с этим интерфейсом ulink2. Для ulink-v1 есть альтернативная прошивка OpenULINK, но она, к сожалению, не подходит для ULINK2, ULINK-ME и ULINK-PRO. PS µVision можно вызывать из командной строки - через батник! http://www.keil.com/support/man/docs/uv4/u...rogramflash.htm http://www.keil.com/support/docs/3061.htm Это ИМХО самый простой способ автоматизации для ТС.

Зато GNUшный линкер быстрый!

Может быть утилита ST-LINK utility работает и с ULINK'ом (не знаю точно - не пробовал). http://firsthand.ru/book/programmirovanie/...hika-st-link-v2 Или через штатный загрузчик можно шить. Почитайте про STM32 Flash loader demonstrator http://www.st.com/en/development-tools/flasher-stm32.html

http://openocd.org/doc-release/pdf/openocd.pdf Вот кусочек моего makefile: # common args: OOCD_ARGS = -d1 OOCD_ARGS += -f interface/olimex-arm-usb-tiny-h.cfg # OOCD_ARGS += -f interface/jlink.cfg OOCD_ARGS += -f target/stm32f1x.cfg OOCD_ARGS += -c \"adapter_khz 1000\" # program args: OOCD_ARGS_PROG = $(OOCD_ARGS) OOCD_ARGS_PROG += -c \"program $(TARGET).elf verify reset\" # reset args: OOCD_ARGS_RESET = $(OOCD_ARGS) OOCD_ARGS_RESET += -c \"reset run\" OOCD_ARGS_RESET += -c shutdown # read args: OOCD_ARGS_READ = $(OOCD_ARGS) OOCD_ARGS_READ += -c \"flash probe 0\" OOCD_ARGS_READ += -c \"dump_image $(TARGET)_dump_image.bin 0x08000000 0x20000\" OOCD_ARGS_READ += -c \"reset run\" OOCD_ARGS_READ += -c shutdown program: $(TARGET).elf echo "--- openocd: program..." echo $(OOCD_ARGS_PROG) | xargs openocd reset: echo "--- openocd: reset target..." echo $(OOCD_ARGS_RESET) | xargs openocd read: echo "--- openocd: reading flash to $(TARGET)_dump_image.bin ..." echo $(OOCD_ARGS_READ) | xargs openocd

openocd )))

Прочитал доку про --as-needed и для меня не совсем очевидно описанное ТС поведение (откидывание libm). Я понял, что линкер должен выкинуть лишь те либы на которые нет ссылок. Поясните пожалуйста, если не трудно, что я не так понимаю. Понял кажется! Если либа включена до объектиников, то на момент её линковки на неё просто ещё нет ссылок. Линкер видимо по умолчанию однопроходный. Кстати, для решения сложных циклических завязок либа от либы есть ключики --start-group --end-group -Wl,--start-group -lmy_lib -lyour_lib -lhis_lib -Wl,--end-group

Почитайте про Modbus over serial line

Я бы подcказал, но пользуюсь gcc...

Ложку дай... Читайте доку! Я не страна советов.

Читайте доки на свой компилятор и линкер. http://infocenter.arm.com/help/index.jsp?t...474e/index.html В gcc - это элементарно. Для вас тоже это не должно составить труда - поправьте scatter files.

Дальнейшее обсуждение считаю бессмысленным. Чего не знаю, того не существует - этот лозунг не для меня.

В знаете, что можно и без IDE вовсе работать. Всё с командной строки и правки править руками и исходники и файл линкера и правила сборки и стартап файл. Основная масса открытого софта именно так и реализована.

Это называется долбаные даблы. И от них никуда не деться, если принтфить флоаты. Каждый раз как об этом подумаю - злюсь... Такие же траблы были бы если выводился тип long long. Так что дело не в плавучке, а в размере используемых типов данных. Если всегда не более 4 байт - то и с выравниванием на 4 всё должно работать нормально.

Тайминги проверяли-перепроверяли? У коллеги была схожая ситуация - оказалось дело в настройках таймингов.